Video GamerX's Code

Like the Beta Quest, there have been tons of goodies that the programmers left behind, and this code ranks second on the list, Beta Quest being first. This code was used when the programmers were debugging the game, and whenever it froze the programmers just entered in the code and voila! All of the addresses called, the stack and heap, the error, floating point values, everything they needed.  How useful this information was depended on the kind of crash you had, since most programming errors won't set off any alarms until it's already too late.  Nonetheless, many games incorporate debug "dump" functions, though the number that are compiled with these features still usable remains relatively low.

Thanks to DVDMTH, a Zelda fan and computer sciences major, we now have the accurate description of these screens.  Fortunately, I wasn't too far off.... err... well, not too far.  Just a little.... some.... stop looking at me like that!!

This procedure is also the most accurate way of finding out which version of Zelda 64 you have.

Okay, first we need the game to freeze. The easiest way to do this is to do the crooked cartridge trick (slowly pull on the left side of the cartridge until it freezes, then shove it back in). Then look in the upper-lefthand corner. If you see a small yellow line, then it worked. If you can't see the line, then either your TV has cut it off or you didn't do it right (try again). Once you see the yellow line, grab your controller and enter in:

If it worked, then the majority of the screen should be covered by a black box (sometimes it shows a small box that says "RCP has hung up... oh MY GOD!" or something like that). If you have a Gameshark or have worked with codes then you'll recognize the hexadecimal addresses listed, and at the top a variety of error messages show up:

0: Interrupt - A very rare message, since interrupts are not usually considered errors.  Interrupts are commands used to grab the processor's attention, such as a key press or a click on the mouse.  Since almost all interrupts are handled by the software, this should never cause the game to crash.

1: TLB Modification Exception - Also very rare, in this case.  TLB stands for Translation Look-Aside Buffer, which is how the processor accesses virtual memory.  In this case, the program tried to change an address that was stored in either a ROM chip or was otherwise protected.

2: Error on Loading TLB - This means that one of the type libraries that was supposed to be compiled into Zelda 64 is either missing or modified. This normally happens with the Beta Quest, and definitely sounds suspicious. Unfortunately, if the TLB wasn't compiled into the game, then it's nearly impossible to "fix" it.
UPDATE: Heh... okay, I was wrong.  The TLB definition I had used was for C++, where TLB stands for Type Library Build.  However, this is CPU talk, so we're using the TLB definition we had above.  Here's the actual explanation: In this case, the game tried to access an address (normally a variable or function call) that wasn't in the virtual memory or in the cartridge's compiled data.  This isn't too far from my explanation, since the error could be caused by a missing data type.  However, it could also be triggered by attempting to read a command when it wanted a variable, or vice versa, or even by trying to load a texture, arena, or character mesh (which is technically just more variables).

3: Error on Saving TLB - This means that one of the type libraries was modified and the game attempted to save it, but it didn't work. This could also mean that it created a TLB in memory and attempted to save onto either the cartridge or a fixed disk drive that used to be there, but isn't there anymore.
UPDATE: Same mistake here, and again not too far from the truth.  What actually happens is that the game attempted to write into an address that didn't exist.  This could be anything from trying to save to a nonexistent file to trying to change a variable in virtual memory that was never initialized.

4: Error on Address Load - This means that when the game attempted to read an address in the memory, the address was either too high or it was not what the game expected and caused the freeze. This normally happens when you try to use the "nameless" items (check the item modifier code for more information).
UPDATE: According to DVDMTH, this error only occurs when the game tries to access a RAM address illegally (a 00?? address, or byte address, that was an odd number, or a ???? address, or word address, that wasn't divisible by four), or when it tries to access a RAM address that was reserved for a different process (unlikely, since the processor is only running the Zelda process).  Also, a process is another word for a program.
UPDATE 2: A little wiser now, address errors can also occur when the game tries to access a variable outside of its current scope, which is a common problem with any computer program.

5: Error on Address Save - This means that the game attempted to save onto an address, but either the address was part of the ROM, or it did not work correctly. This also happens when you try the "nameless" items, as well as the Beta Quest. Because it attempts to write onto the ROM, the N64 may try to transfer the save to a different address, which could cause complications (in other words, it could erase files).
UPDATE: Apparently, this error can be caused only by the above reasons as well, though it is still possible that the game will try to transfer the save to an "unused" address.

11: RCP is Hung Up - The Reality Co-Processor is vitally important when the N64 works its 3-D wonders, and when it freezes, so does the N64. If you get this message, then the stack and heap dump screens, object ID, and arena screens will not show.
UPDATE: This error is normally extremely rare.  However, because Crooked Cartridge can create thousands, if not millions, of faulty commands in milliseconds, the co-processor can easily become inundated and prevent it from functioning.

[Filename]... - The debug tool was intended for the programmers, who could access the actual C++ files used in making the game. So they made sure the debug screen was smart enough to know the filenames. Well the filenames are still stored in the debug screen (you can see them if you use Gameshark's View Code command), and whenever the screen mentions one of them, then you crashed the game itself, which is somewhat difficult to do.

15: Floating Point Exception - The Floating Point Unit (a piece of hardware specially designed to handle numbers with fractional values) couldn't make heads or tails out of the last instruction it was given, was told to divide by zero (which is impossible), the number was too big, or the number was too small.  Usually it says "Invalid Operation," which means that it was totally confused. (Note: most of the time it will say "inexact operation," which simply means that the fraction is longer than the FPU can hold.  This almost always results in rounding, so it is not considered a crash.)

Here's a more detailed description of each screen: