So, I made a random benchmarking ROM for determining how accurate are Mega Drive emulators. It just loops and increases a counter for 10 frames, so as you can guess, the results differ between NTSC and PAL - which doesn't matter really, as the CPUs have different clock speeds there anyways. Whatever, here's the ROM: Binary: http://srb2town.sepwich.com/junk/68kbench.bin Source*: http://srb2town.sepwich.com/junk/68kbench.7z By the way, these are the results I got so far (yes, the counter is in hexadecimal XD): Gens-2.15.5-gs-m6-win32 NTSC: between 00008AAE and 00008AAF PAL: between 0000A4D0 and 0000A4D1 Fusion 3.61 NTSC: between 00008A1B and 00008A1C PAL: between 0000A500 and 0000A501 Regen 0.96 NTSC: between 00008AAE and 00008AAF PAL: 0000A5AF (stable value) Tiido, please test the ROM in real hardware =P Also feel free to test in other emulators and post the results here if you want. Later I'll make modifications to the ROM for specific instruction benchmarking. EDIT: updated ROM for emulators that don't have region change support and is impossible to determine the current refresh rate. It should show blue for 60Hz and red for 50Hz. Unless the emulator is too shitty. Then it'll show blue most likely, or crash ;P (seriously, the code isn't doing anything weird, it doesn't even touch RAM, so WTF o_O). The background color is set when booting up, not if you change the region while it's already running. ---------------------------------------- *Before somebody annoys me with licenses, I'm giving it out as public domain >_>
The ones that are the exact same as real hardware. Of course, we don't know these "best" results yet, since the ROM hasn't been tested on real hardware yet; once the results of that test come back, we can see which emulator is the most accurate in terms of speed. =P
I tried it on several emulators on my PDA. Unfornatelly, they even haven't an option to change region, so I can't tell what region is emulated. For PicoDrive value is 0000B3F0, stable. On GenPP value is 0000A4D2, also stable. On SmartGear it just shows a clean blue screen. EDIT: On the new ROM color on PicoDrive is red, on GenPP also. Value hasn't changed. SmartGear continues to show a clean blue screen.
All done on Intel Mac OS X. Generator 0.4.4 Note: I had to manually pad the ROM to a reasonable size (the size of Sonic & Knuckles). NTSC - 00008AF1 (consistent) PAL - 0000A55A (consistent) Genesis Plus 1.3.0 NTSC - 00009458 (consistent) PAL - No PAL emulation. Kega Fusion 3.52i Same as Sik's 3.61 results.
Redownload ROM and try again. I changed it so the background is blue on NTSC and red in PAL... assuming the emulator isn't being shitty >_> (it checks a bit in the VDP). Remember to reset the program when changing the speed for the background to change. BTW, some emulators need the ROM to be padded Fuck it.
PicoDrive 1.45a between 8AAD and 8AAE St0rm (on DOSBox) between B5xx and B9xx (I think NTSC) It varies very much, so "xx" means any value. GenEm 0.19 (on DOSBox) 6580 (both NTSC and PAL) RetroDrive Release 5 Between 8AAC and 8AAD Xega 0.10 8A66 Dgen 1.21 90A0 Exodus 0.1a F734
Model 2 Genesis, running from Multi Game Doctor 2- 000088AD for about 3.5 seconds, 000088AE for about .25 seconds, repeat
What. The. Fuck. I was expecting different values, but I wasn't expecting the oscillation to be like that o_O EDIT: for the sake of it Code (Text): <djohe> DGEN 1.7: <djohe> 8a66 USA/JPN Performance <djohe> 9287 USA/JPN Normal <djohe> 9bac 9bad PAL Performance <djohe> a4d4 PAL Normal <djohe> PSPGenesis 0.18c <djohe> 8Af1 (this emulator has no country setting it seems) <djohe> PICODRIVE 1.51 <djohe> A527 PAL / JAP PAL <djohe> 8aad 8aae USA / JAP NTSC Also shouldn't this ROM be posted on SpritesMind as well? =P
This may be a bit more useful for you - http://stealth.hapisan.com/Junk/68kBen...k_From_MGD2.avi Also, I made a change to have it run from RAM, with different results: http://stealth.hapisan.com/Junk/68kBen...rk_From_RAM.avi http://stealth.hapisan.com/Junk/68kBenchmark/68kram.bin http://stealth.hapisan.com/Junk/68kBenchmark/68kram.rar I'm guessing that there may be different access time on different cartridge-port devices, too, which would probably produce different results.. It might be worth having it tested on other stuff like SMD and tototek Edit - Wrong URL :/
Something to remark: Tiido once told me that there's a clock for RAM. Basically, if the 68k attempts to access RAM, it has to wait until the next cycle of this other clock. Normally it isn't much of a trouble because most instructions take several cycles and that pretty much makes it line up, but it's still the same issue. On different cartridges giving different speeds: I guess it's time to make a header for ROMs =/ EDIT: er, right, the RAM is static RAM so it shouldn't need clocking... but yeah, it's something like a bus clock or similar. Remember, everything is slower than the 68k except the VDP (which is about double the speed, depending if it's in H40 or H32 mode). Whatever, that clocking adds some unexpected delays that you probably wouldn't think in.
Here is the results for jEnesisDS, the results are NTSC only due to the emulators inability to run PAL games at 50fps. It osculates between 008A64 and 008A65 every... 0.25 seconds on a unmodified Nintendo DSi running in DS mode. The results are the same for a late 2005 model Nintendo DS phat anyway so that shouldn't matter. Edit: The emulators revision is 0.7.4. Its important because the emulator literally becomes faster and more efficient with stuff becoming properly emulated every day. I'll give it two years before 3D games and rastering actually work properly.
Sure the revision is important now? Because considering the values, it looks like the emulator is actually attempting to match the speed of the 68k in real hardware. I doubt it's just coincidence.
For kicks I've decided to measure the engine used in HackTube =P 00008CA8 stable, NTSC. It's more accurate than many emulators >_>
and when I try to run this on my MDs I'll get black screen.... and then starts the tedious debugging process to find an error in less than 100 lines of code :P I'll get some real HW numbers tomorrow, techincally today, but I have to sleep, work tomorrow...
Yet Stealth could run the original ROM-based one on real hardware without touching it, so there must be something wrong in your end =/ And it's 289 lines according to asm68k (although many of these are either blank lines or comments...). Also if it crashes in a black screen, it must be crashing before setting the background, so if there's a bug, it must be before that... and that pretty much 21 lines of code ¯\(º_o)/¯ EDIT: http://srb2town.sepwich.com/junk/hacktubefail.PNG It didn't just fail the tests, it even failed to write the text
lol, I only said what might happen in worst case scenario, hehe after 4 hours I'll be having some real HW results, then I get home from work
