As I hear from enhacklopedia, Nemu is the only n64 emulator with a decent debugger... is this true? A debugger in Mupen64plus would be ideal, but there doesn't seem to be one.
Unfortunately I'm having a slight issue with Nemu's debugger. For the most part it works well, but memory access breakpoints (which I consider essential) don't always work. I was trying to track down code that handles loading text in the ocarina of time: master quest, and I found the text in RAM (in the 80XXXXXX region). I put a read/write access breakpoint on it, but it only stops when reading the data. The data can be changed without triggering the breakpoint. On the other hand, write breakpoints worked for one-ups in Super Mario 64...
I'm new to n64-specific hacking. Enhacklopedia had a note on TLB mapping:
Unfortunately I'm having a slight issue with Nemu's debugger. For the most part it works well, but memory access breakpoints (which I consider essential) don't always work. I was trying to track down code that handles loading text in the ocarina of time: master quest, and I found the text in RAM (in the 80XXXXXX region). I put a read/write access breakpoint on it, but it only stops when reading the data. The data can be changed without triggering the breakpoint. On the other hand, write breakpoints worked for one-ups in Super Mario 64...
I'm new to n64-specific hacking. Enhacklopedia had a note on TLB mapping:
But I don't understand how it affects me. Could this be interfering with the breakpoints? Thanks for any help.Some games are difficult to ASM hack because they use virtual addresses. The virtual addresses are mapped to physical addresses through the translation lookaside buffer (TLB). Currently, the only way to work around the TLB is to view the mapped address in the memory viewer (Nemu)/RAM Edit (GSCC) to get the 32-bit hex value of the instruction where the break occurred while the game is still halted. Then search for it in the memory, checking each result in the memory viewer against the surrounding bytes at the TLB mapped address until the routine is found. Keep in mind this won't work on Goldeneye, because the physical location of most of the assembly changes randomly each time a level is loaded.