Ocarina of Time Crooked Cartridge - Error without Crash
WARNING!
The Crooked Cartridge trick can delete your saved games, ruin the game cartridge, or even render your Nintendo 64 useless! Use this trick at your own risk!
Instructions
- Go to Lon-Lon Ranch.
- Head inside the house, talk to Talon, and agree to play his super Cucco game.
- Successfully complete the Cucco game.
- The screen will fade to white. As soon as it begins to fade back in, quickly do the Crooked Cartridge trick.
Result
Talon will give you your prize of milk, but there will be no sound, at all. If you look in the top left corner you can see the debug line flickering there, enter the debug code then rapidly press the 'A' button to see the debug pages, they'll show that a "TLB exception on load" error has occurred, but the game hasn't crashed!
After some testing I've found out that this works anywhere in the game. As the screen is fading in after going from one area to another, or after reloading the area, you can do this. The only thing is that in most areas it is extremely difficult to do without freezing the game. I think the smaller size of the house's interior makes it it less likely to freeze.
The error has to do with sound. You can leave the house, go anywhere you want, and the sound won't come back. Taking out your Ocarina usually freezes the game; if it doesn't, you'll be able to play a song, but as soon as you do the game freezes. If you try to listen to one of the songs on the Quest Status subscreen, the game will lock up.
dvdmth explains:
Every individual process that happens during gameplay is its own thread and exists independently of all others, thus allowing for several things to happen simultaneously. When a thread "faults" (i.e. crashes), it is halted as well as any other threads that are depending on it (some fancy UNIX signals go around and such), and the N64 Debugger is invoked if enabled. Since some threads can crash without affecting others, it's possible for a thread to fault without taking down the system as long as nothing else is expecting the thread to be doing something. In your "error w/o crash" trick, the audio playback thread is crashing, but since audio isn't required for gameplay (for the most part), everything else goes on fine. The debugger, having been invoked, is operating asynchronously with all non-faulted threads, allowing the user to control both the debugger and the game simultaneously. It isn't until the game starts depending on the audio playing thread (i.e. when playing the Ocarina) that the system can potentially crash as a whole. The debugger responds only to the first thread fault, so the fact that others faulted as well is ignored. Not that this is important or anything, but it is something I found interesting. (BTW I have reason to believe "Thread 4" may be a default thread ID used if the developers don't specify one. According to a source, this ID number only serves debugging purposes and is in no way used by the game itself for any operations.)
