N64 Debuggers

[Drenn]

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:

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.

But I don't understand how it affects me. Could this be interfering with the breakpoints? Thanks for any help.

 

[microdev]

As I hear from enhacklopedia, Nemu is the only n64 emulator with a decent debugger... is this true?

The JavaScript version of Daedalus features a quite advanced debugger with some unique features.

 

[Drenn]

I wasn't able to get n64js working on my linux box, and I'm starting to get the hang of nemu64... so thanks anyway. I managed to make the code I wanted, increasing OoT's text speed, although some breakpoints aren't triggered, particularly read breakpoints in the rom. I await the day mupen64plus gets a debugger.

 

[zoinkity]

Matters too on the data. DMA won't trigger it for instance, which it really shouldn't since it's hardware moving data, not software, and those are technically software breakpoints. I believe Zelda's engine directly copies strings from ROM in most cases (or at least later iterations of the engine did), so that's why you aren't seeing writes. Copies, yes. Writes, not so much.

Zelda doesn't use TLB in that way, and probably only uses the basic C0- mirror. It has an entirely different memory management system based on converting literal ROM addresses to rdram ones.
GE aliases rdram to 70xxxxxx and uses 7Fxxxxxx to dynamically load and map ASM from ROM via dynamic memory. So, to breakpoint anything in the standard library you'd have to change the lead byte of the address from 8 to 7, and to be honest it's easier to just use a table to find the dynamic stuff.

Still, that can be awfully annoying since it can make something, such as data linked to microcode, seem unused if you don't realize what's going on.

If the first read you're getting is from a copier, look at the PI Interrupt tab on the registers debugger. Chances are it was just read from ROM using the PI thread, so the most recent values there will be the target address, ROM source, and length. You really don't want to backtrace across threads if you don't absolutely have to.