Earlier this year, we shared the story of how a classic NES Tetris player hit the game’s “kill screen” for the first time, activating a crash after an incredible 40-minute, 1,511-line performance. Now, some players are using that kill screen—and some complicated memory manipulation it enables—to code new behaviors into versions of Tetris running on unmodified hardware and cartridges.
We’ve covered similar “arbitrary code execution” glitches in games like Super Mario World, Paper Mario, and The Legend of Zelda: Ocarina of Time in the past. And the basic method for introducing outside code into NES Tetris has been publicly theorized since at least 2021 when players were investigating the game’s decompiled code. (HydrantDude, who has gone deep on Tetris crashes in the past, also says the community has long had a privately known method for how to take full control of Tetris‘ RAM.)
But a recent video from Displaced Gamers takes the idea from private theory to public execution, going into painstaking detail on how to get NES Tetris to start reading the game’s high-score tables as machine code instructions.
Fun With Controller Ports
Taking over a copy of NES Tetris is possible mostly due to the specific way the game crashes. Without going into too much detail, a crash in NES Tetris happens when the game’s score handler takes too long to calculate a new score between frames, which can happen after level 155. When this delay occurs, a portion of the control code gets interrupted by the new frame-writing routine, causing it to jump to an unintended portion of the game’s RAM to look for the next instruction.
Usually, this unexpected interrupt leads the code to jump to address the very beginning of RAM, where garbage data gets read as code and often leads to a quick crash. But players can manipulate this jump thanks to a little-known vagary in how Tetris handles potential inputs when running on the Japanese version of the console, the Famicom.
Unlike the American Nintendo Entertainment System, the Japanese Famicom featured two controllers hardwired to the unit. Players who wanted to use third-party controllers could plug them in through an expansion port on the front of the system. The Tetris game code reads the inputs from this “extra” controller port, which can include two additional standard NES controllers through the use of an adapter (this is true even though the Famicom got a completely different version of Tetris from Bullet-Proof Software).
As it happens, the area of RAM that Tetris uses to process this extra controller input is also used for the memory location of that jump routine we discussed earlier. Thus, when that jump routine gets interrupted by a crash, that RAM will be holding data representing the buttons being pushed on those controllers. This gives players a potential way to control precisely where the game code goes after the crash is triggered.
Coding in the High-Score Table
For Displaced Gamers’ jump-control method, the player has to hold down “up” on the third controller and right, left, and down on the fourth controller (that latter combination requires some controller fiddling to allow for simultaneous left and right directional input). Doing so sends the jump code to an area of RAM that holds the names and scores for the game’s high-score listing, giving an even larger surface of RAM that can be manipulated directly by the player.
By putting “(G” in the targeted portion of the B-Type high-score table, we can force the game to jump to another area of the high-score table, where it will start reading the names and scores sequentially as what Displaced Gamers calls “bare metal” code, with the letters and numbers representing opcodes for the NES CPU.
Unfortunately, there are only 43 possible symbols that can be used in the name entry area and 10 different digits that can be part of a high score. That means only a small portion of the NES’s available opcode instructions can be “coded” into the high-score table using the available attack surface.
