search

notaz / picodrive

Fast MegaDrive/MegaCD/32X emulator
Other
291 stars 165 forks source link

Mars Check Program (32X) causes emulator to abort during testing #96

Closed dilworks closed 5 years ago

dilworks commented 5 years ago

ROM SHA1SUM / common filename: 7654c6d3cf2883c30df51cf38d723ab7902280c4 Mars Check Program Version 1.0 (Japan, USA) (SDK Build) (Set 1).32x

There are not many 32X hardware test ROMs out there. But there is a very notable one out there which is as old as the 32X itself, because Sega made it, and that one is the (in)famous Mars Check Program, Version 1.0. This ROM runs 161 tests, covering pretty much everything on the console, and emulators traditionally have choked to death with this one, at some point in history leading people to believe that this ROM doesn't even run properly on the real thing (it has been reported elsewhere[1] that all tests indeed do pass on the real thing). In fact, Kega Fusion gets a clean pass as of version 3.63.

What's my surprise that, when testing PicoDrive with my existing 32X ROM set, and already quite impressed at the results (for starters: it can run the Brazil-exclusive 32X CD release of Surgical Strike, a game that not even Fusion manages to boot), I got the emulator to unexpectedly quit during the runtime of said test ROM. It doesn't crash, instead it aborts with the following message:

invalid PC, aborting: 700181e0

This "check program" ROM tries to run test 123 (it's one of the SH2 DMA tests), causing the emulator to abort. Tested with the standalone UI on both x86 flavors (32 and 64 bit), on different releases of Debian (the 32-bit is current Debian Stable / Stretch, while the 64-bit is still running the oldstable Jessie), and in all cases the abort message is exactly the same, down to the value reported (which I assume to be an invalid program counter address?). This error message seems to be coming from the SH2 recompiler (cpu/sh2/compiler.c): https://github.com/notaz/picodrive/blob/7ddd8501a72bd53a98083e7137a2e26f7d615a7f/cpu/sh2/compiler.c#L1471

I'm no emudev or ROM hacker, so I don't have a clue on which is causing this lame test ROM to upset PicoDrive's SH2 recompiler so bad it decides to pick up its toys and go home :/

[1] http://gendev.spritesmind.net/forum/viewtopic.php?t=593

notaz commented 5 years ago

This ROM runs 161 tests, covering pretty much everything on the console

Not really, emulating it is not enough to emulate the actual games.

As for the problem, it's a bug it the actual ROM. In some of the tests, it unintentionally overwrites the program code with garbage, which causes the emulated program to jump to an invalid memory location. It works on the real hardware because the test code stays in CPU's cache, even if corresponding RAM was overwritten with garbage. It's possible to emulate all that, but it would introduce lots of complexity in the recompiler, and probably would have some performance cost. If there was at least some game relying on cache, it would make sense implementing this, but I'm really reluctant to do it just for this Mars test thing (not that I have resources such projects these days anyway).

BTW it's possible to patch the ROM to fix this bug (or is it cache testing feature?) by replacing all occurances of "06 02 00 00 00 00 80 00" with "06 02 00 00 00 00 40 00".

dilworks commented 5 years ago

Oh, thanks for the explanation!

Guess this is a WONTFIX for now then, and your reasoning is sound. But I wanted to point it anyway, as there has been so much misinformation spread around this test ROM for decades. Basically it works by sheer chance (inadvertently exploiting a CPU feature?)... just like everything on the 32X :D