# How can tilting a N64 cartridge cause such subtle glitches?

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).

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.

• One brainstorm: interrupting that connection causes Mario to miss an animation update, after which the animation system (which was not programmed with an unreliable connection in mind) never recovers, and he's stuck in a zero-rotation state (which could be laying on the ground if his model was created in that orientation for some reason). This is all purely speculation, but there are lots of reasons that any sort of weirdness could happen. I once had a Windows PC that insisted its network drivers were missing, and in the end it ended up being a faulty ethernet cable and nothing else. – GrandOpener Nov 2 '16 at 19:27
• +1 for the "special "rotate mario" pin" :-D – KlaymenDK Nov 3 '16 at 12:38
• If you tilt the cartridge the characters get dizzy and lose their balance – Hack-R Nov 5 '16 at 16:02
• Theory: Nintendo was already dipping their toes on motion control waters. The next iteration even included a handle for easier experimentation! – xDaizu Feb 6 '18 at 16:45
• A short explanation that "tilting" means pulling out the cartridge mid-game might be in order; it suer had me confused for a bit. – SQB May 4 '18 at 8:04

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.

• +1 This is really much more of answer to the question. The game doesn't crash because certain, not quite as vital information is no longer available. The game's core that renders everything is already in memory, so the game can continue. It probably also has something to do with not so great error checking/handling (so it the game uses garbage responses instead of exploding), too, if I had to guess. – jpmc26 Nov 3 '16 at 23:17

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.

• Alright, maybe not reliably, but the fact that it's happened more than once is already surprising enough for me. – Jack M Nov 1 '16 at 16:29
• @JackM It's not surprising. You are basically removing a component from a working system. If you would do this to some other system, it would also fail in somewhat reliable way: eg removing wheels from a car in motion always causes it to skid for a while and then stop. Now, there are some conditions you're taking for granted: if you'll do it on exactly same spot on the road, at same speed, etc (same state of the game), you'll get very similar results. But if you'd do this just before a tight mountain turn, the car would fall over a cliff - again with decent repeatability. – Agent_L Nov 2 '16 at 12:58
• @Agent_L Exactly - the car stops, it doesn't suddenly start translating the talk radio into Chinese. Where the threshold is is subjective, but there's clearly a point beyond which the ratio of "complexity of outcome" to "simplicity of input" becomes surprising. – Jack M Nov 3 '16 at 20:13
• @JackM Removing the wheels of a moving car is a good analogy. The only difference is that you understand the system of physics at play that causes the car to stop after removing the wheels. I'm sure someone who understands the system of an N64 cartridge would say "well of course the data gets corrupted in a particular way". – Abion47 Nov 3 '16 at 21:01
• @JackM It doesn't just stop. It produces lots of visual glitches (sparks), complex audio patterns (screeching and crumbling), damage to the road and the vehicle, and if it falls over a cliff, it will also make a nice little dance. And I'm not even talking about what happens to the driver :) Just because the situation doesn't seem complex to you doesn't make it simple. Human brains are just wired that way - they still have this nagging feeling that explaining thunderstorms by a human-level-intelligence-agent-in-the-skies is simpler than this whole complicated electromagnetism thing. – Luaan Nov 4 '16 at 8:44

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.

• Also notice that this kind of data bus is not "aware" of the fact it has been temporarily disconnected - the host device gets nonsensical data but no signal that will tell it the cartridge was pulled. – rackandboneman Nov 3 '16 at 11:01

## 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.

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.

• The reason why that extra unused code is not deleted is most probably because it was being used to debug the game, and once it's been established that it worked well enough with that specific data on the cartridge, that's what they were gonna ship to customers. Just guessing from coding experience though, no hard info. – user1306322 Nov 5 '16 at 15:29