Nemu64
Originally released on December 11, 1998, discontinued March 2003, Nemu64 (Developed by Lac and Lemmy: Creator of LemASM) was, and still is the best Nintendo 64 emulator as far as debugging capabilities go. It has a minimum resolution of 320x240 and a maximum resolution of 1600x1200. A lot of individuals struggle with properly emulating ROMS with it's default plugin Nemu64 Graphics (which was created by Lemmy), but a simple install of Rice Video should solve most, if not all of such issues as long as your computer is capable of running such emulation and you have properly installed your graphics driver. A con with using the default plugin is lack of compatibility with some Nintendo 64 titles Together and miscellaneous graphical errors. There are however pros to using the default plugin if you're interested in speedrunning: logging keystrokes into a file, frame-by-frame emulation, etc. Among the listed pros above, I'll cover the debugging tools later on down the page. With that said, Nemu64 is not a viable alternative for Project 64 on older computers due to it's CPU usage requirement and is noticeably slower. Like most other N64 emulators, it also supports netplay.
Nemu64 can also change graphics settings on-the-fly with the use of "active pause" in the "Rom" menu, take screenshots as well as demos/replays that can only be viewed by Nemu64 while the same game is loaded. With the default video plugin you can disable texture cache (you sacrifice speed, but this can be used to fix inaccurate texture loading), force Z clear (can be used to counter many of the graphical glitches you may come across), force Z buffer, CMIG tracing (can be used to fix flickering issues with Paper Mario) and export 3D models (while running a game) into the VRML format just to name a few. In the "Debugging features" category/section, I'll further elaborate on advantages of the default graphical plugin in their respective tool section. One quick note before I continue is that if you like hacking by comparing savestates, they are zlib compressed, but of course that wouldn't be too difficult to decompress. Nemu64 is also an HLE (High-Level Emulator) emulator, but can also be ran as a LLE (Low-Level Emulator). I will go over their differences as well as advantages and disadvantages later down the page (including how to enable LLE). It is also worth noting that Nemu doesn't support the Game Boy adaptor that is used with games like Pokemon Stadium, etc.
Tutorials
Making codes with Nemu64
Typed out version of the above
An Easier Way Of Finding "MTCO" Type Enablers with Nemu
Stepping through memory with Nemu and Renegade64 with the all mighty wareya
Debugging features
Plugins
Show Combine Modes
Only works with the default graphics plugin. It generates a list of the combiner settings read during ucode processing and lets you view and fiddle with them. Note, most combine modes weren't emulated back then and you essentially need hardware reference to know what you're doing.
Free Camera Movement
Also only works with the default plugin. It allows you to move the viewpoint used for rendering. Basically, a parlor trick (platform magic). Depending on how much scene there is, you can do silly tricks like looking around corners at inaccessible things.
Show Rom Info
Displays some information extracted from the ROM's internal header. Go here for false entry points.
Rom Settings
Special notes are stored here for games that may have problems as well as information as to get around said problems. You can also mess with the HLE settings in the ROM database file.
Debugger: Commands
Rather than viewing data as Base16 like that of the "Debugger: Memory" window, you are able to see the individual instructions for addresses and possesses very useful features. If you're using the dynamic recompiler, you can set break-on-execute (BPX) breakpoints here by clicking next in the gutter next to the desired address. If you're using the built-in LLE video instead of the HLE plugin, you can also set RSP and RDP breakpoints and view the code those are running, but the code is not always 100% accurate. The CPU tab looks at RDRAM addresses, the RSP tab looks at SP IMEM addresses, and the RDP tab displays the RDP's display list commands. In the "Debug" menu, you can clear all PC breakpoints. The Symbols menus allow you to put text labels on specific addresses. You can also hook to a program called LFE (with the required illegal library file) and locate OS functions and definition signatures in the compiled binary. The .cod files LFE generates contain the OS functions and their locations in RAM. "Bookmarks" is discussed later.
Debugger: Memory
The "Debugger: Memory" window views an addresses instruction/contents in Base16 (hexadecimal) rather than in MIPS like that of the "Debugger: Command" window. Not only that, but you can also click on "Predefined" in it's menu to navigate to anywhere on the memory map and edit the data found at whatever desired location allowing you do see whatever is at a particular hardware or virtual address, and this includes the Stack. An important note is that upon selecting a memory region, the start address is not copied correctly into the "Address" box. In addition, you can set "Read" and "Write" linebreaks on an address's data, view text in ASCII and see how large numbers are with "Words, Halfwords, Bytes." Just for a quick noob rundown: In MIPS, every instruction is a fixed size of 32-bits wide (4 bytes) (that is a word: WW XX YY ZZ e.g. 1FC007C0). As you can see, there are 4 addresses to a row.
So if you're looking at address 800AD324, and with knowing every addresses contents are 32-bits wide (4 bytes), all you would do to count what address
is which while simultaneously looking in the "Commands" window is know that the furthest most column is equal to the second furthest most column of
addresses, and from there, you simply add four bytes. This creates a simplified memory model (the instructions being a static 32-bits/4 bytes). Take a
look at the following:
Current Address +4 bytes +4 bytes +4 bytes
| | | | |
Address 800AD324-800AD328 - 800AD32C-800AD324
| | | | |
V V V V V
800AD324: WWXXYYZZ WWXXYYZZ - WWXXYYZZ WWXXYYZZ
800AD334-800AD338 - 800AD33C-800AD350
800AD334: WWXXYYZZ WWXXYYZZ - WWXXYYZZ WWXXYYZZ
This has got to be the most straight forward example.
You will also notice the "Search" and "Dump memory" options here as well, and we will go over them later down the "Plugins" menu.
Debugger: Registers
This window allows you to view some (but not all) hardware registers. This is partly due to not being emulated (certain COP0 and RI registers), partly because of how HLE skips writebacks, etc. that renders those registers useless (like AI registers).
- General Purpose registers are your CPU regs, and the registers used by the current opcode in the "Commands" window will be highlighted. You can edit these with the exception of the HI LO registers (how-to is discussed in the notes). To note, most usually just change the PC address from the "Command" window with a simple right-click rather than in this one. The registers on the left side (R0-T7) are volatile, meaning they can be changed without consequence, the registers on the right side (S0-T9) are considered non-volatile (unless you know exactly what you're doing), while the lower right side (K0-RA) are system registers.
- COP0 are the R4300i's own registers. They aren't all emulated, and not all the ones listed are used during emulation either. As an example, the Watch exception wasn't implemented so despite the registers being readable and writable, you can't trigger the interrupt. To learn more about their purpose.
- COP1 are the floating-point unit's (FPU) registers. It allows viewing values in the FPU's own registers a number of ways. The control register is read-only; not sure if the mode that allows 32, 64-bit floats is implemented or not.
- RCP registers: The MI, SP, DP, VI, SI, PI, RSP Vector, and RSP Hidden registers are all read-only .However, in LLE video mode the RSP General Purpose registers can be edited and used alongisde the "Commands" window. Otherwise, HLE bypasses RSP and RDP altogether. Also note, while the RCP registers are read-only, you can think of those sections as a reference point for what value they're currently holding rather than needing to navigate to their respective memory locations. From there, you can of course implement them in your assembly gs codes with the exact same method of loading an address that would be found in RAM, if need be.
Debugger: Bookmarks
This feature is quite handy. It lets you save multiple, collapsible, labeled addresses, and breakpoints to reload on each run, and is also accessible via the "Memory" editor and "Command" windows. An example that can be downloaded
Debugger Opcode Breaks
As the name suggests, lets you stop execution when a certain kind of opcode is found. One practical use is setting one for DMULTU to change it to DMULT via the "Commands" window. Certain games (GoldenEye, The Duke Nukem games, etc) will not function correctly due to DMULTU being implemented identical to MULTU. Switching the opcodes corrects this issue for the most part. Another handy use is when dealing with opcodes that aren't emulated (all the TRAP ones, for instance) when working with libdragon homebrew or catching SYSCALL in Banjo Tooie to catch the exception they throw to load unloaded files. A Trap is a type of exception (along with faults and aborts) that switches to kernel mode by invoking a kernel sub-routine (any system call), a SYSCALL is synchronous and planned user process to kernel mode. Catching BREAKs can be a good idea also, since this exception also isn't caught by most HLE emulators, but is usually caused by bad floating-point math such as division by zero, undefined opcode, etc.
Debugger: Break on Register Change
This allegedly should stop execution when a read or write operation is performed with the value in the given register. Not sure if it only catches LW/SW of if it ignores anything when interrupts are disabled. It never seems to work right.
Debugger: Dump Memory
As discussed above, we'd eventually get to this. "Dump memory" allows you to dump either straight hex, disassembled assembly, as seen in the "Commands" window, or "terrifying" hex text to a file. When outputting the PC with it, you can override the address to start at with the field in the window, and is also accessible from the "Memory" editor window.
Debugger: Search
This allows you to search from anywhere in RAM up to 0x1FFFFFFF. Physical addresses would be the same as the ones you see in the PI tab of the "Memory" editor window. Binary searches are aligned 8, 16 or 32-bit values. Searching for 0x7852 would give you a hit on '78524320' or '65427852', but not on '55785231'. Text searches don't need to be aligned and seemingly only allows ASCII. The algorithm for the "Fast" option might have made a big difference back in the day, but doesn't appear to give any different results on more modern computers. JAL searches take a virtual address such as 80000400. It converts this to a JAL opcode and searches for it. Effectively the same as a 32-bit search for 0xC000000 | ((addr >> 2) & 0x3FFFFFF). Note it only catches JAL, so you'll still have to do the math for a J search (same as above using 08000000 instead).
Note: The single ampersand in this instance is the bitwise operator "AND." For further information, a simple Google will suffice.
Debugger: Statistics
This is just benchmarking (to compare it to other emulators) for Nemu's recompiler. It monitors how many times a specific opcode and register was called, as well as how many times blocks are called, amount of seconds spent on(?) and percent of CPU usage.
Debugger: Image Viewer
It lets you view a given rdram address as a 4i, 8i, or 16i image. VRML output is only enabled for the Nemu64 Graphics plugin (as noted above), and will put the dumped/extracted models in a folder called "VRML" in your root directory (Be sure to create the folder yourself, and you might have to play with permissions on it with post-winXP OSes).
Show Profiler
Only works with the dynamic recompiler and it's display usage is pretty self explanatory as it's showing what is primary being used assumably for development purposes.
Debug
A few near tools here, but mostly utilities LaC and Lemmy used during development and neglected to remove for whatever reason.
Logging
This logs printf() function instances and dumps their contents (the text they contain) to stdout.txt in Nemu's directory. stdout is just the console output of any application.
Cheat DP Interrupt
A "hack." It changes the way the emulator fires the RDP interrupt to indicate it's done running commands.
Reset Dynrec
As the name suggests, resets the dynamic recompiler when it's being used. Unless you set the thing to run in 'interpret' mode for something that otherwise won't run. The dynamic recompiler generates PC instructions based on the R4300i code it's reading. This is the backbone of HLE, offering a significant enough speed boost that games can run faster than MEME or Cen64! You'd use this if the thing suddenly had no idea what it's doing. It then restarts from current PC. In the case of 64DD cart conversions, it could dynarec at the wrong address and mess everything up.
Show Compiler Stats
Used when developing Nemu.
Show Clock Cycles
Used when developing Nemu.
Reset Clock Cycles
Used when developing Nemu.
Cheat Count Increase
Another hack that changes the way HLE adds to the Count when fuding cycles. Something the ROM Settings window will have notes on how changing the count increment can get certain games to boot. It's a cheap way to implement the necessary delay for some games that require accurate timing for PI DMA.
Reset Block Profiling and Write Block Profiling to bprof.stats
Both of these are profilers: Profilers are tools that analyze the dynamic behavior of your program: how fast, how often and, sometimes, when the parts of its code are executed when the program is run.
Test Pre-NMI
This is to be used with the "Command" window. There's a pre-non-maskable exception that fires when you press reset. This triggers that, causing the game to execute code to stop execution and reset the system. It doesn't reset it though, effectively, this does what happens when you hold the reset button, so pretty sure you can use it to do the black hole animation in Tetrisphere. (One of the reset types spoken about in the ROM's internal header (PC counter).
Disable Exception
As the name suggests, prevents exceptions from occurring. Mostly used as a toggle when working with the "Commands" window.
Disable Video HLE (1)
This puts Nemu into LLE graphics mode. It now processes RSP and RDP code, and you can use the "Commands," "Memory" editor, and "Registers" windows to view/tamper with execution. It's not perfect though.
Force CFB
I think it forces using a constant frame buffer, so maybe to freeze the game on a single screen so you can get a screenshot.
Disable Audio HLE (2)
This ignores the audio plugin and uses LLE audio processing. Unlike video LLE, this can run at a reasonable rate. This is usually processed by the RSP and can use the "Commands," "Memory" editor, and "Registers" to view/tamper with the processing. A tab for the AI isn't added to the "Registers" window, but you can view the registers via the "Memory" editor at 0xA4500000. Of them, the only one that seems correct is A4500004 (the current position in the audio passed to output).