This is not the nicest code ever, but did the job. I would like to post the robot that I used to crawl through the SH2 code, so I could make a map of all the instructions that were executed. This is what made possible to play games with a dead cart.
As you remember, I compiled a special version of MAME that was outputting a file that was indeed a table of the instructions that were executed by the SH2, then that file needed to be processed. You could play more and more the game, find new combos, in general do whatever you could to execute new parts of the code. The resulting new file would be OR'ed all the time with the previous one, trying to complete the table. But that was not enought. There were parts of the code that were never executed or were very hard to find.
The reason why we needed to know what is an instruction and what is code, is that a dead cart has encription enabled for instructions but not for data, so you cant just decrypt the whole 16Mbytes of program rom, you have to decrypt ONLY what you are 100% sure that is an instruction and leave data unchanged. The table that MAME generated had a fix size of 1Mbyte and each bit represents one instruction (2 bytes), which is the total size of the program rom memory map (16 Mbytes) , being a bit 1 an instruction and a 0 data.
The tool is basically a recurrent tree, where you ignore the instructions that are marked as data, and inspect those that are marked as code. You examinate all the instructions that you find one by one and if it's a non-branch instruction, you just add it, and continue executing code. If it's a regular branch, you just change the PC, if it's a conditional branch, then you open 2 new subroutines and each one will continue crawling through the soubroutine until you hit a Return instruction.
There were a lot of jumps and branches to soubrutines and you need to detect them all. Some of the Jumps were referencing registers, so the destination address of the Jump was uncertain. In most cases I was able to find the value of the register, just looking a few instructions back. If that was not the case, then I printed a warning, so I could have a look manually at them later.
Code is not clean and was intended for internal use, so it can contain unused code or lack references. It's shared as it is and It's completely to use at your own risk. I take no responsibility.
I hope this can be useful for someone if they need to do something similar in the future.
Enjoy!
As you remember, I compiled a special version of MAME that was outputting a file that was indeed a table of the instructions that were executed by the SH2, then that file needed to be processed. You could play more and more the game, find new combos, in general do whatever you could to execute new parts of the code. The resulting new file would be OR'ed all the time with the previous one, trying to complete the table. But that was not enought. There were parts of the code that were never executed or were very hard to find.
The reason why we needed to know what is an instruction and what is code, is that a dead cart has encription enabled for instructions but not for data, so you cant just decrypt the whole 16Mbytes of program rom, you have to decrypt ONLY what you are 100% sure that is an instruction and leave data unchanged. The table that MAME generated had a fix size of 1Mbyte and each bit represents one instruction (2 bytes), which is the total size of the program rom memory map (16 Mbytes) , being a bit 1 an instruction and a 0 data.
The tool is basically a recurrent tree, where you ignore the instructions that are marked as data, and inspect those that are marked as code. You examinate all the instructions that you find one by one and if it's a non-branch instruction, you just add it, and continue executing code. If it's a regular branch, you just change the PC, if it's a conditional branch, then you open 2 new subroutines and each one will continue crawling through the soubroutine until you hit a Return instruction.
There were a lot of jumps and branches to soubrutines and you need to detect them all. Some of the Jumps were referencing registers, so the destination address of the Jump was uncertain. In most cases I was able to find the value of the register, just looking a few instructions back. If that was not the case, then I printed a warning, so I could have a look manually at them later.
Code is not clean and was intended for internal use, so it can contain unused code or lack references. It's shared as it is and It's completely to use at your own risk. I take no responsibility.
I hope this can be useful for someone if they need to do something similar in the future.
Enjoy!
Last edited: