The Legend of Zelda: Majora's Mask/Crash Debugger

Majora's Mask contains a crash debugger just like Ocarina of Time does. It was used by the game developers to diagnose crashes that occur, and is expanded a lot compared to OoT's crash debugger.

It is present in all N64 versions of the game. To trigger it, you first need to crash the game in some way, either by using Crooked Cartridge or with one of the game's various glitches. The screen will now, after a while, switch to the last cutscene you saw since the game started (most of the time it will be the Song of Soaring cutscene, but others can also occur), except if you haven't watched any cutscene in which case the screen will be pitch black instead. Also, a red bar should appear in the upper left corner of the screen. Now, you need to type in the following key combination:

D-Pad Left + C-Right + L + R + Start.

That's it. No finger breaking is necessary, unlike in OoT.

Due to the differences between the N64 and the GCN the crash debugger does not work on the GCN version of MM. It does not work on emulators either, because they don't redraw the screen after the game has crashed.



Both OoT and MM use the same first screen. This is the most important one, as it provides the most basic information concerning the status of the system at the time of the crash. Most (if not all) of the information shown comes from a register, either on the System Control Processor (top), the main CPU, or the Floating-Point Unit (bottom).

Majora's Mask has a more complex debugger and shows more stuff. This perhaps is due to MM's more complicated design and/or its use of the Expansion Pak.



STACK TRACE #1 - This is a more genuine trace. It keeps track of that the Stack Pointer (SP) is at various times during the game's operation. It also keeps track of what the PC was at that time (i.e. what line of code was running when the Stack was at that point). The first row shows the current SP and PC at the time of the crash. The farther down you go, the farther back in time you're looking. I have no idea what the last column is for.

In general, the smaller the SP value, the larger the Stack (the more stuff that's on it). This isn't 100% true, however. Once I saw the SP jump from $801xxxxx to $807xxxxx. (This probably happened because the Stack was getting too big for where it was, so the new data was placed on the Expansion Pak where it could fit.)

The number of lines on this screen vary, for reasons beyond my comprehension.



HUNGUP - This screen is uncommon but can appear. (I've only seen it after a crash in the defective Snowhead Temple with Epona.) The screen shows a second thread ID (usually 2, for some reason), as well as the source code filename responsible (such as "../z_std_dma.c"). This screen probably appears if the program crashed in a piece of code that had debug information embedded in it. I know from experience that if I have debug labels turned on when compiling and my program crashes, a debugger will report the filename and/or subroutine responsible for the crash.



ACTOR LIST #1 - This is similar to the second-to-last screen of the OoT debugger. This one, however, can potentially scroll onto additional screens (as many as three, perhaps more).



ACTOR LIST #2 - A shorter version of the prior list. Its format is slightly different as well.



SCREENSHOTS - At this point, the debugger takes a moment to show two screenshots from the moments leading up to the crash. The last two frames drawn to the screen are displayed, with the most recent coming last. (The two are often the same image, with maybe a slight difference in one of the icons on the screen.)



VERSION INFO - No debugger is complete without this, it seems. During development, there may be several different builds going around at once, so having a specific version dated can sometimes be helpful. Also on the screen is something labeled "SP_STATUS" (I have no idea what this is, but it obviously has something to do with the Stack).



SCHEDULING INFO - This screen's a mystery to me. There are always two lines, GRAPH and AUDIO. However, sometimes another block of information appears, called RSPTask. What bugs me is that this last bit of information not only doesn't always appear, but sometimes decides to appear randomly during the same debug session! In other words, I'll visit this screen and not see it, then scroll through all other screens, coming back, and lo and behold it's there!

This screen probably relates to thread/task scheduling (GRAPH(ics) and AUDIO being two task names).



DUMP - This is the generalized version of the two dump screens of the OoT debugger. Here, you can examine anything that's stored in RAM. Here are the controls for the dump screen:


 * Up, Down = scroll one line, or $10 (16 bytes)
 * "A" + Up, Down = scroll a distance of $100 (256 bytes)
 * "B" + Up, Down = scroll a distance of $1000 (4096 bytes, or 4KB)
 * "A" + "B" + Up, Down = scroll a distance of $10000 (65536 bytes, or 64KB)
 * C Down = Jump to the Stack (stack dump)
 * C Up = Jump to the section of code that caused the crash (PC dump)
 * C Left, C Right = scroll to $80000000 (start of RAM)
 * START = exit the Dump screen

STACK TRACE #2 - This is pretty much identical to the first Stack Trace, only the final column is different. On the first screen, in my tests, the third column was always "????????." However, on this screen, the ? marks were gone, and occasionally a different number appeared over here (in the range $8080xxxx, which isn't even part of RAM). I'm not sure why this happens or what the values mean, if anything.



CONGRATURATIONS - Of course, the debugger has to provide some congrats for anyone serious enough to actually mess around with these screens. Notice how the word congratulations is misspelled. Was that intentional? After all, it is a debugger, so why should everything be perfect?