How to beat Super Mario Bros. 3 in less than a second

Watch as TASBot beats SMB3 in less than a second.

It has been a full two-and-a-half years now since we first saw the game-playing TASBot (short for tool-assisted speedrun robot) take full control of a Super Mario World cartridge. In that time, you would think we would have gotten tired of seeing the machine mangle classic games using nothing but data sent through the controller ports on actual gaming hardware.

Then last week’s Summer Games Done Quick speedrunning marathon came along, and on Saturday, TASBot showed off its newfound ability to beat Super Mario Bros. 3 in less than a second (the marathon run had some padding, so it’s actually visible to the audience). Our jaws were on the floor once again. There must be some sort of trick. How in the world is this possible?

Exploiting a decades-old hardware bug

The graphical glitches here are a result of some bits of memory that SMB3 fails to initialize at the beginning of the game.

TASBot’s newest bit of game-breaking magic relies on the vagaries of the NES’ DPCM (differential pulse code modulation) sound channel. This one-bit data stream was used to play extremely basic audio samples in select games, including Super Mario Bros. 3.

As it turns out, the NES hardware itself has a small bug, such that reading sound data from this channel results in the CPU sometimes making an extra “read” request from one of the controller inputs. Uncorrected, this hardware vagary would lead to a lot of “phantom inputs,” where a button press would register when none had occurred.

For Super Mario Bros. 3, the developers accounted for this problem by simply polling the controller input multiple times per frame, until the system sees the same input twice in a row. At that point, it figures the repeated input is a “true input” rather than a phantom from the DPCM glitch and passes that along as the real button being pressed for that frame.

All TASBot has to do, then, is ensure that the game never sees the same input twice in a row when polling the controller within a frame. If that happens, the game will go into an idle loop, constantly polling for input until it sees a non-maskable interrupt call asking for the next frame. At that point, an issue with the game’s screen-splitting raster interrupt causes it to start reading instructions from the very beginning of the RAM.

A few frames later, the game advances to the part of memory where controller inputs are stored, letting TASBot essentially enter machine code instructions using careful combinations of inputs. Enter the appropriate code to jump to the game’s ending animation, and voila, you’ve beaten Super Mario Bros. 3 in less than a second!

From theory to practice

The custom-made TASLink hardware that lets TASBot flood the NES with thousands of inputs per second.

TASBot developer micro500 (one of a number of TASers that primarily go by their handles online) tells Ars that exploiting this DPCM glitch requires hardware that can flood the NES’ input wire with a full 7,984 inputs per second. That’s obviously out of the realm of possibility for a human, and it was even beyond the limited hardware TASBot used in previous speedrun tournaments. For this year’s SGDQ, though, micro500 developed a new TASLink board that could handle the vast flow of data necessary.

With the hardware and the theory in place, micro500 started discussing the idea online with fellow TAS-makers total_, ais523, and TASBot manager dwangoAC last Thursday, with SGDQ already in full swing. That’s when the TASBot team found that current NES emulation couldn’t handle the new wave of subframe inputs they wanted to send. Every NES emulator in existence actually only looks for new input once per frame, since the game itself usually can’t update faster than that anyway. To get around this limitation, total_ had to essentially rewrite the FCEUX emulator (via Lua script), forcing it to recognize thousands of inputs every second.

By Thursday night, though, there was an initial test working on actual hardware. By Friday, an optimized version was working on micro500’s NES, but not on dwangoAC’s actual TASBot hardware. The difference, it turns out, was in an area of memory that SMB3 neglects to initialize at the beginning of the game. This usually has no effect on how the game works, but with TASBot’s hack, that uncleared memory could be read as confounding machine code, depending on which game was run previously.