We just reached 25,000 articles on this wiki! 🥳
If you appreciate the work done within the wiki, please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!

The Legend of Zelda: Ocarina of Time/Crash Debugger

From The Cutting Room Floor
Jump to navigation Jump to search

This is a sub-page of The Legend of Zelda: Ocarina of Time.

The crash debugger is a tool that was used by the developers to figure out what, exactly, had gone wrong when the game crashed. As such, it contains several pages of information detailing what was going on at the time of the crash.

Two versions of the debugger are known to exist. The first version is present and functional in all versions of Ocarina of Time released on the Nintendo 64. This version of the debugger also exists in the Wii Virtual Console releases, but is inaccessible with the code below due to the emulator not mapping D-Pad Left, Down, or Right input to the controller. The second iteration of the debugger is based on the one used in Majora's Mask, and appears in the GameCube versions of Ocarina of Time and Master Quest, however due to a bug (null pointer dereference), the crash debugger crashes as soon as it is launched in these versions, causing a red bar to be displayed. The iQue version has a similar problem.

Additionally, the debugger does not function on most emulators, as they don't redraw the screen after the game has crashed.

Accessing the Debugger

To trigger the crash debugger, you must first cause the game to trigger a fatal exception. This can be done by exploiting one of Ocarina of Time's various glitches, or by gradually lifting up the left side of the cartridge. Be forewarned, however, as the latter method may damage your game or system. The video below demonstrates how it can be done with that method.

ZeldaOoT CrashYellowBar.png

Or, one could choose the more sensible option. When the game crashes, a red or yellow bar will appear in the upper left corner of the screen. A red bar seems to mean that the system is unable to execute the debugger. When you see a yellow bar, input the following key combinations, line by line. Despite popular belief, the input code isn't timed.

  1. L + R, then while holding both press Z.
  2. D-Up
  3. C-Down
  4. C-Up
  5. D-Down
  6. D-Left
  7. C-Left
  8. C-Right
  9. D-Right
  10. A + B, then while holding both press Start.
(Source: Original Crash Debug Display Code - T-Dogg. Improved code - mzxrules)

Page 0 - HungUp Cause

ZeldaOOT OhMYGOD.png

This page of the debugger is only displayed for certain exceptions. It seems this screen is displayed when a fatal exception occurs, but the faulting thread is not immediately halted. Because of this, the Registers, Stack Dump, and PC Dump pages are not displayed.

Page 1 - Registers

It looks like you just kicked your N64 out of fit of frustration, mate!

Page 1 provides register information for the System Control Processor (top lines), the main CPU (middle line), and the Floating-Point Unit (bottom lines).

Both Ocarina of Time and Majora's Mask display the same information on the first page of their crash debuggers.

MIPS Register Name in crash handler Notes
R1 AT Reserved for assembler
R2-R3 V0-V1 Stores results
R4-R7 A0-A3 Stores arguments
R8-R15 T0-T7 Temporary registers
R16-R23 S0-S7 Saved registers
R24-R25 T8-T9 More temporary registers
R28 GP Global pointer
R29 SP Stack pointer
R31 RA Return address

Page 2 - Segment Map

Segmented like an earthworm.

Page 2 shows a table used only by the CPU for the purposes of generating display list tasks for the RCP to consume. The Nintendo 64's GPU, the RCP, uses a segment address system to reference data in RAM. The way it works is that the CPU will begin an RCP task by initializing one of the 16 segment addresses to reference some base location on RDRAM, then use a segment offset to refer to data relative to the start of the base address. In Ocarina of Time's case, each segment corresponds to the start address of some file as it's located in RAM. This list does not keep track of all segment addresses, just the ones relevant to the CPU.

Segment Identification
2 Stores the offset to the data of the current scene file in RAM.
3 Stores the offset to the data of the current map file in RAM.
4 Stores the offset to the gameplay_keep file in RAM.
5 Stores the offset to the gameplay_field_keep file (when in the overworld) or gameplay_dangeon_keep (when inside dungeons) file in RAM.
6 Stores the offset to the current object being processed by the game engine.

Page 3 - ROM Debug

You get 0 out of 0 for crashing the game

In the retail versions of Ocarina of Time, the values on page 3 are always set to zero.

During testing, however, the developers may have set these values to reflect the content of certain variables during gameplay. This way, when the game crashed, they may have been able to figure out what went wrong by referring to these variable settings.

Page 4 - Stack Dump

ZeldaOoT-CrashDebug-004.png ZeldaOoT-CrashDebug-005.png ZeldaOoT-CrashDebug-006.png

Page 4 displays the contents of the crashed thread's stack, a section of memory used to hold temporary data.

The first entry on the far left column shows the current address in memory, while the columns beside it show the information contained at that address. The next most-recent address in memory and its contents are displayed on the line below, and so on and so forth.

Page 5 - PC Dump

ZeldaOoT-CrashDebug-007.png ZeldaOoT-CrashDebug-008.png ZeldaOoT-CrashDebug-006.png

Page 5 shows which code was being executed at the time of the crash. Somewhere on the screen is the instruction that failed, as indicated by the Exception Program Counter. Executed code appears at the top of the screen, followed by the faulting code somewhere near the top middle (800DA704 in the above image), with the remaining code being the next sequence to execute.

Page 6 - Actor Overlay List

Who crashed the game? Fun debug action from ages 00 to FF.

Page 6 displays a list of actor overlay files currently in memory. Actor overlay files include all dynamic entities that are not structurally part of a map, such as characters, enemies, moving platforms, and any objects Link can interact with.

No. RamStart-RamEnd Offset
Actor number in decimal. Where the actor file starts and ends in RAM. The ROM offset of the actor file.

Page 7 - Version Info

Wi-W-Wi-Wi- Wild Copper‎! I love you! (If you don't get the reference then watch the Wild Copper Megalo demo for Amiga.)

Page 7 is the most famous screen from the debugger, thanks to its declaration of love to the tester. It also displays the date that the ROM was compiled, which is helpful in determining which version of the game you have. Below are the known compilation dates, and which game versions they correspond to:

Date Time Version
98-10-21 04:56:31 1.0 (J), (U)
98-10-26 10:58:45 1.1 (J), (U)
98-11-10 14:34:22 1.0 (E)
98-11-12 18:17:03 1.2 (J), (U)
98-11-18 17:36:49 1.1 (E)