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

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

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

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.

While the same essential glitch should be possible on a number of other games that use DPCM sampling, the actual implementation depends on precisely how each title accounts for the glitch. Micro500 says that Zelda II: the Adventures of Link probably can't be exploited in the same way because the game is smarter about how it handles the game-locking input loop. But Kirby's Adventure seems like it might be ripe for exploitation, according to dwangoAC.

A split community

The SMB3 run is an impressive technical achievement, but it's not without its controversy in the TAS community. "Subframe input... is seen by some as undermining the last decade of work [in tool-assisted speedruns]," dwangoAC told Ars. "In particular, some view this class of interaction with the console as impure in some way because it does not align with the strictly held dogma of aligning input with the edge of a frame, while others are simply concerned that this will only produce runs that simply skip to the end credits in the first seconds of the game."

Adelikat, who runs the TAS clearinghouse TASVideos.org, put it bluntly in the #TASVideos IRC chat room. "I'm not enthusiastic... There's an artistic value that is gone. The sportingness is gone, and the entertainment value is of course gone, after the first one... For me it ruins the fun."

A quick poll of some other members of #TASVideos highlights the controversy. "For me personally, I love the technical achievement of it," Fog_TAS said, "but I question the entertainment value of it to non-technical people who watch. If it's possible on multiple games, it kind of takes away the magic of the glitch." Marysia worries that "it will not take long until every TAS ends in a flash, or at least such ending will be considered the ultimate goal of TASing. Personally, I think TASing is more about perfect input rather than breaking games."

"Personally, knowing that it's a thing and roughly why it happens is satisfying enough on its own," added Scum. "I don't feel a need to see it applied to every game it might work on or to see video proof of it in action."

Whatever the effect on the TAS community, it's still incredible just how well a team of hobbyists armed with a game-playing robot can exploit small glitches in decades-old NES hardware and software. We can't wait to see what they come up with next.