It looks like you're doing what I did and debugging the emulator itself, but not the game. This isn't a bad approach (I've done plenty of nice work this way), but you have to be able to translate between the emulator's execution and the game's by keeping track of the game's Program Counter.
Emulators will always store variables like the program counter and other registers SOMEWHERE in the RAM. There a number of ways to find the PC, one of which is to abuse the ASM of the game that you DO know to write bogus plug in ASM that reads from an address without actually doing anything with that data.
If the address is one the game doesn't even use (and it should be) then you set a watch point for reads of that address with a guarantee that only the result you want will appear.
From there, set a break point on the emulator's instruction that handles that read, and then use a cheat search to search for PCs equal to or at least near (sometimes the PC isn't exactly equal to that of the instruction being emulated, when using dynamic recompiling cores, like you are) the address of the instruction you wrote to read that address. Keep in mind that I'm talking about the PC of the game, and not the emulator.
Doing the above just twice should give you just a handful of possible addresses, and likely only one of those addresses will be changing as often as the actual PC would be. That's your PC.
From then on, if you set a break point on say, that nop you found, checking the PC should bring you very close to the actual MIPS instruction (MIPS for N64, since you're using Mupen) that you're looking for.
I personally prefer to debug things using Project 64, and have a good set of instructions on how to do this with a program called Cheat Engine here.
|
