THIS POST MIGHT CONTAIN A WALL OF TEXT.
MrSandman wrote:Hi leonardoliveira,
could you please explain what you mean by "Mitchell and Choko stuff"?
It's more like "Mitchell stuf"... idc asked me to decrypt Mighty Pang, which I did. It was one of the first games I completely disassembled for obtaining the map of what is encrypted and not encrypted within the ROM. Because of that, I decrypted Janpai Puzzle Choko out of a spite, followed by Puzzloop 2. That's what I meant by "Mitchell stuff".
As for listing problematic Phoenix ROMs, I've not had any experience any so far - I only know of problems from reading threads here and there (IIRC SFZ3 and SSF2X some winning quote text mess-ups in English settings).
I remember that Raz rom for Pocket Fighter/Super Gem Fighter have some odd quirk with the AI. Turned out it was just one single wrongly decoded word somewhere in the middle of the data.
There's two ways of decrypting the games. One is XOR CLASH two revisions of the game with exact same program code and the other is completely disassemble the game on an interactive disassembler. The two ways are prone to errors but the automated way (XOR CLASH) leaves you with a extra trouble of finding where the mistakes are. I found a solution for that issue, which almost perfected the method. Issues with disassembling the game could happen from overlooks, mis disassemblies or plain traps set up by CAPCOM within the code. Anyway, I had Rockman working correctly after I finished disassembling it. I had very minor glitches in Quiz Nanairo Dreams, which came to be from overlooking instuctions somewhere.
Vampire the Night warriors was done through disassembly method.
I had three crashes in it:
- At Gallon stage the props that break at the background would cause address errors. -> This one was a set of data that was supposed to be treated as not encrypted data was left by me in the state it is after run through the encryption.
- One move from ZabelZarock would cause a illegal instruction exception. -> Sometimes the borderline of where data and instructions are laid up on the ROM are quite cloudy.
They like to use small jump table patterns within the code branches to change what the game will do. The data with the relative offsets for the jumptables are aways envrypted at it's read relative to the program counter. Stuff that is read from fixed addresses using the address registers for indexing are read in the exact way they are stored in the EPROM chip. Also since the CRC check code reads the whole rom using either a program counter relative instruction or a normal instruction, the act of decrypting the ROM causes the CRC to change. So it will aways fail the CRC check after decrypted ...
So an overlook on knowing what region is code or data may cause either illegal instruction exception (as it jumps somewhere it was supposed to have a instruction but there's a chunk of corrupted data) or a wrong pointer causes it to jump to a wrong place or try to read a word or long word at an odd address causing a address error. Anyway if it's just reading data, the address is even but it's a wrong address, you have other odd kinds of glitches (perhaps this is what happens with the Super Street Fighter 2 ROM that supposedly has text glitches or show characters check boxes during game play...) which are pretty tough to trace/debug.
- An odd behavior on the game over screen with Vampire the Night Warriors (read above about data words being read from wrong addresses... An pointer was being fetched from a wrong address because the routine that reads the data would do so using a pointer fetched by another routine that ran before it... ) the game would not show "GAME OVER" after the continue counter expired.
Problems with data that trigger no exceptions or errors are particularly nasty to find, but to figure out where exactly it is at I use NEBULA or any other emulator which still use XORs to make certain regions of the ROM be what they were like when they were still envrypted. I test the game and see where I replace the data with the original encrypted data fixes the issue. When I find the exact offending offset I disassemble it and study how it works in detail.
That brings me another problem: Know if there is any glitches to check ...
And that's where testing helps a ton. Having lots of smart, interested people test these games would help big time.
Would testing the ROMs in MAME suffice (wouldn't know how and where to start)?
No, because some behaviors of MAME do not match the real board. For example writes from the RAM TEST code or from the RAM CLEAR that is done after the RAM TEST to the CPS2 sprite layer control register (0x400000 region on normal battery clad boards, 0xFFFFF0 at dead boards) cause an exception which freezes the real board. That does not happen on MAME. I suspect that's intentional and was meant to confuse anyone who eventually managed to decrypt a game as a last effort to make the hacker give up from hacking (lol).
That's exactly what idc was talking about when he said "we just have some final testing on hardware to do (testing on MAME alone is not enough - CPS2 hardware is actually far less tolerant to bugs than MAME)"...
We tried to run Ultimate Ecology and while it worked on MAME just fine, it would crash on his board. I burnt the game on EPROMs to test and found the exact same fault (It would freeze after displaying the region of use warning). Turns out it was still writting to the CPS2 sprite control register when it was clearing the ram before start the main game loop.
It was a 5 minutes fix. There's a huge loop routine that cleans 16 bytes per loop. Patched the main counter to make it loop a couple times less and game was booting perfectly. Played it several times and no glitches to be seen.
Still, MAME is the core tool on this process.
When debugging the games, do you also look at the code, i.e. how the AI was programmed or how much of the same code is being reused for different games (say how much code is borrowed between the different fighting games or puzzle games etc).
The CPS2 games seem to be coded in either C# or CPP so the code look like a big construction of .... LEGOS !
Unfortunately you have no labels on a assembly listing done through reverse engineering and to get that much information from a game engine you would easily pour down a year of your life in such a project. So, no I only look deeply at code that is causing trouble and only when I have a good idea where the problem is at (see the text above about using NEBULA as debugging tool).
Also I aways enable CAPCOM's debugger on any ROMs I deal with. Mitchell games have no debugger (well Puzzloop 2 does but I didn't bother using it, the game worked outright. Simple code on Mitchell's stuff was easy enough)..