Scud Japan
Posted: Sat Jan 01, 2022 10:50 amThis is probably one of the last major bugs left in the emulator. The japanese version looks like this
At first I thought it could be a problem with our tilegen or 2d rendering code. But mame has the exact same bug and their implementation is very different to ours, so it seems unlikely. I tried flipping the colours to 4bit and 8bit but it wasn't that.
The pattern data is there, but the palette data is wrong. I compared the japanese version to the regular version and logged all the writes to the tilegen chip when the level loads in both versions. The regular version of scud loads like 50% more data at the start of the level. Since the versions are so similar i checked the entire palette for colours I knew should be in memory, and it turns out they simply aren't there. So my conclusion is for whatever reason the japanese version just doesn't load up the data into the tilegen chip.
Nuexzz actually used a game cheat program artmoney? to hack the emulator itself and managed to work out (how I've no f-ing idea) the bytes that needed to be flipped to get the game to work. Here is a screenshot.
Basically a 2 byte value was changed from 0 to 1. After that the emulator seems to upload the missing data. Here is a larger screenshot of me trying this.
You can still see the time at the top left hasn't got the correct palette loaded but everything else looks correct.
Virtua fighter 3 team battle also seems to have a few of these same issues. I'm pretty sure the sky is not to meant to look like this
Link to save state
https://www.mediafire.com/file/w6yu9g1e ... 3.zip/file
So what is going on? I'm not really sure. Maybe one of those unknown video IRQs needs to be fired to get this missing data to upload? Maybe it's some value the hardware is supposed to be returning that isn't. I'm not sure, but this is as far as I got with debugging. I don't think it's a bad ROM, as in the case of scud japan it passes the self CRC check at least. I assume it's accurate enough to detect 1 bit flip.
At first I thought it could be a problem with our tilegen or 2d rendering code. But mame has the exact same bug and their implementation is very different to ours, so it seems unlikely. I tried flipping the colours to 4bit and 8bit but it wasn't that.
The pattern data is there, but the palette data is wrong. I compared the japanese version to the regular version and logged all the writes to the tilegen chip when the level loads in both versions. The regular version of scud loads like 50% more data at the start of the level. Since the versions are so similar i checked the entire palette for colours I knew should be in memory, and it turns out they simply aren't there. So my conclusion is for whatever reason the japanese version just doesn't load up the data into the tilegen chip.
Nuexzz actually used a game cheat program artmoney? to hack the emulator itself and managed to work out (how I've no f-ing idea) the bytes that needed to be flipped to get the game to work. Here is a screenshot.
Basically a 2 byte value was changed from 0 to 1. After that the emulator seems to upload the missing data. Here is a larger screenshot of me trying this.
You can still see the time at the top left hasn't got the correct palette loaded but everything else looks correct.
Virtua fighter 3 team battle also seems to have a few of these same issues. I'm pretty sure the sky is not to meant to look like this
Link to save state
https://www.mediafire.com/file/w6yu9g1e ... 3.zip/file
So what is going on? I'm not really sure. Maybe one of those unknown video IRQs needs to be fired to get this missing data to upload? Maybe it's some value the hardware is supposed to be returning that isn't. I'm not sure, but this is as far as I got with debugging. I don't think it's a bad ROM, as in the case of scud japan it passes the self CRC check at least. I assume it's accurate enough to detect 1 bit flip.
