How can tilting a N64 cartridge cause such subtle glitches?

Question

When the N64 cartridge is tilted in Super Mario 64, it reliably produces glitches such as this. Mario's limbs disappear, he rotates 90° and sinks into the floor, and the music gets messed up (usually it goes faster).

What surprises me about this glitch is two things:

1. It's a very specific and subtle kind of behavior. I would have thought that tilting a cartridge would produce glitches more like "absolutely nothing works because everything's messed up, the game crashes", not "this specific 3d model will be rotated by precisely 90°". I mean, what, is there a special "rotate mario" pin in the cartridge?

2. This specific behavior can be reliably reproduced. These exact symptoms have been documented online. You can find videos on YouTube of this glitch happening to other people.

How could it possibly be that something as "brute force" as tilting the cartridge could reliably produce such a specific result without just making the whole game crash? This seems to me like dropping a typewriter down a flight of stairs and finding that it's typed out a novel.

I'm not necessarily asking about this specific glitch, I'm just trying to get some kind of a reading on how it's possible for cartridge tilting to reliably produce symptoms like this. Ideally, assume that I have at most basic knowledge about computers, roughly equivalent to a 101 textbook on computer circuitry and some programming experience, although explanations at any level are welcome.

Answer 1

The main point to understand is that the console is limited. RAM on the console itself is faster than memory on the cartridge (and the cartridge memory was usually read only, with a little non volatile for user data).

So the game designers had to carefully consider how to use the precious, but faster, ram on the console, vs the slower rom on the cartridge.

The stuff put into RAM was usually the graphics routines - the programming code that decided what pixels went where - and the cartridge was relied on to provide data when needed - a map's boundaries, object orientations and locations, etc. Things that consumed a small amount of space and so didn't take long to look up inside the cartridge while the console spent most of its time drawing on the screen using the code, textures, and other pieces needed much more frequently and quickly.

So what a cartridge tilt does is it damages or disables access to these lesser important, but still important, pieces of data that the game doesn't want to waste ram on. This results in humorous mistakes as the program tries to use bad data to act on the good data stored in ram.

Answer 2

I wouldn't say "It's a very specific and subtle kind of behavior." I really think this is the case of undefined behavior that has been reproduced so many times from N64 launch to now that users have seen repeat behavior. In fact, sometimes cartridge tilting can actually delete your game save (Donkey Kong 64), and not just mess with the graphics (Goldeneye's "Get Down" glitch).

On a high level, cartridge tilting limits or blocks data flow from the cartridge to the console. Many "How To" guides state that to accomplish the tilt properly, keep the right side of the cartridge pushed down while slowly lifting up the left side. This is because the power pins and ground are located on the right side of the cartridge, while the data stream (and some 64 DD) pins are on the left side. Note that I think the cartridge would sit with the label facing the arrow/triangle.

Image courtesy of Bungle's 27/28 pin N64 wiring guide.

I couldn't find a full wiring diagram or explanation on what all of these wires do, nor am I an EE expert. I would love it if someone could provide an in-depth analysis of the Nintendo 64's cartridge I/O.

Different games show different behavior due to different engines and programing.

I would also argue against your claim that "This specific behavior can be reliably reproduced." Have you ever tried to perform any of the cartridge tilting glitches listed online or shown in YouTube videos? They are incredibly hard to reproduce, even in ideal environments. After years of attempting I've only done this successfully one time on Mario Kart, and have lost save data and broken several cartridges. We don't know how many attempts it took users who were recording to reproduce "ideal" tilt glitches.

Answer 3

This is the pinout of a Nintendo 64 cartridge (from here). The Nintendo 64 used a multiplexed address/data bus with a three-stage access protocol: write the high word of the address you want to access, write the low word, then read the data, all going across the same 16 pins.

This indirect access method means that program code needs to be run from the console's RAM, but the high speed of access means that programmers generally treated the cartridge as additional data-only RAM, reading data on an as-needed basis (as opposed to disk-based systems, where programmers would try to preload as much data as possible).

If you tilt the cartridge, you disconnect AD pins 0, 1, 2, 13, 14, and 15. These disconnected lines take on default values based on the wiring techniques in use, restricting which parts of the cartridge ROM the console can access, and what values can be read from them. Since most games read their code during startup rather than during gameplay, this doesn't (usually) cause crashes, but instead, highly-repeatable glitches.

Answer 4

The Gist

Games on the N64 typically did not have a lot of memory to use. Instead of keeping all code and data loaded onto the cartridge at one time, it would typically keep some necessary game code loaded into memory, and would only load temporary game code or data when needed.

This is seen with cartridge tilting on "The Legend of Zelda: Ocarina of Time"

Cartridge tilting on that game does not crash, since the code necessary to run is always loaded (in a file called "code"; it takes up about 1/3rd of memory at a time). However, the graphics appear very messed up. This is because the graphics for the game are loaded only when needed to save space, and interfering with the connection between the console and the cartridge loads garbage data instead of the actual data.

How?

How does the N64 interact with the cartridge? As an N64 hacker, this is my understanding;

1. Boot code from the beginning of the ROM is loaded into memory and executed
2. The boot code sets up threading and loads some code to get the game "running"
3. Any time the game needs data from the cartridge, it services the console's "DMA read function" by writing to 0xA4600000.

The DMA read function tells the console to load from the cartridge. When the console receives a write to the DMA read memory, it looks for the file that is wanted to be loaded. How does it know which file? It looks in the "DMA Table" of the cartridge, which points to where in ROM the file is located.

In response to LawrenceC

I'm sorry, but this is not correct. The PC points to instructions specifically in RAM, not in ROM; However, when the N64 wants to execute code from the ROM it just services a DMA Read.

Hope I could help.

Answer 5

First, if you go to The Cutting Room Floor and browse awhile, you will discover that the binary images of many old ROM and cartridge based games have often have test code, unused code, debug code, partially overwritten code, and in some cases even messages and text-based source code. Why this code is not deleted and instead "skipped over" is beyond me - it's most likely the programming of the final master EEPROM did not erase what was previously there. It's really common in a lot of 70's, 80's and early 90's games.

All CPUs have an "Instruction Pointer" or "Program Counter" that contains an address of the instruction it's currently "working on."

A CPU in an endless loop reads the data in this cartridge (which is mapped in the CPU's address space) from this address, increments the program counter (sometimes more than once to get additional data needed by the instruction), executes the instruction, and repeats. Certain instructions called "jumps" or "branches" can "set" this register to a different value.

When you partially remove a cartridge, you are interfering with the address and data pins of the cartridge. This means the CPU is reading wrong data from the cartridge and will execute an unintended instruction, or an existing instruction with unintended operands or data.

It's also possible that interfering with the communication between the cartridge and the computer in 16-bit and later systems causes bus errors which trigger CPU exceptions, which might activate debug or test code in the cartridge.

This can cause the CPU to jump to spots in the binary image of the cartridge that it normally wouldn't, and if there is some unused test or old code that does something weird, it might get called and if conditions are right, it might actually work.

You used to be able to "fry" Atari 2600 games fairly easily by rocking the power switch on and off quickly. It would cause the CPU to not completely initialize and I always suspected that the Atari would start the cartridge at some point other than the beginning. Many games had weird glitches, yet were still playable. But there is not a lot of room in 2k or 4k byte Atari cartridges for unused code, so you usually didn't activate hidden functionality.