Sat. Feb 4th, 2023

Watch TASBot beat SMB3 in less than a second.

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

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

Exploiting a decades-old hardware bug

The graphical glitches here are the result of some bits of memory that <i>SMB3</i> does not initialize at the beginning of the game.” src=”https://cdn.arstechnica.net/wp-content/uploads/2016/07/tassmb3-640×363.jpg” width=”640″ height=”363″ srcset =”https://cdn.arstechnica.net/wp-content/uploads/2016/07/tassmb3-1280×726.jpg 2x”/><figcaption class=
Enlarge / The graphical glitches here are the result of some bits of memory that SMB3 does not initialize at the beginning of the game.

TASBot’s latest breakthrough magic is based on the vagaries of the NES’s DPCM (differential pulse code modulation) sound channel. This one-bit data stream was used to play extremely simple audio clips in selected games, including Super Mario Bros. 3.

It turns out that the NES hardware itself has a small bug such that reading sound data from this channel sometimes causes the CPU to make an extra “read” request from one of the controller inputs. Uncorrected, this hardware quirk would lead to a lot of “phantom input”, registering a button press when none had happened.

In front of Super Mario Bros. 3, the developers solved 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 thinks the repeated input is a “real input” rather than a phantom of the DPCM glitch and passes it off as the real button pressed for that frame.

All TASBot has to do is make sure the game never sees the same input twice in a row when polling the controller within a frame. When that happens, the game goes into an idle loop, constantly looking for input until it sees an unmaskable interrupt call asking for the next frame. At that point, an issue with the screen-splitting grid interrupt causes the game to start reading instructions from the very beginning of RAM.

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

From theory to practice

The custom TASLink hardware that allows TASBot to flood the NES with thousands of inputs per second.
Enlarge / The custom TASLink hardware that allows TASBot to flood the NES with thousands of inputs per second.

TASBot developer micro500 (one of a number of TASers who mostly isolate themselves online) tells Ars that exploiting this DPCM glitch requires hardware that can flood the NES’s input thread at a whopping 7,984 inputs per second. That’s clearly beyond the realm of a human’s capabilities, and it went even beyond the limited hardware TASBot used in previous speedrun tournaments. However, for this year’s SGDQ, micro500 developed a new TASLink board that could handle the massive amount of data required.

With the hardware and theory in place, micro500 began discussing the idea online last Thursday with fellow TAS makers total_, ais523 and TASBot manager dureoAC, while SGDQ was already well underway. Then the TASBot team discovered that the current NES emulation couldn’t handle the new wave of subframe input they wanted to send out. Any existing NES emulator really only checks for new input once per frame, since the game itself usually can’t update any faster anyway. To get around this limitation, total_ essentially had to rewrite the FCEUX emulator (via Lua script), forcing it to recognize thousands of inputs every second.

On Thursday evening, however, there was a first test that worked on real hardware. On Friday, an optimized version worked on micro500’s NES, but not on duress’s TASBot hardware. The difference, it turns out, was in a memory area that SMB3 fails to initialize at the start of the game. This usually has no effect on how the game works, but with TASBot’s hack, that unresolved memory can be read as confusing machine code depending on which game was previously run.

While the same essential glitch should be possible in a number of other games that use DPCM sampling, the actual implementation will depend on how exactly each title explains the glitch. Micro500 says so Zelda II: The Adventures of Link probably can’t be leveraged in the same way, as the game is smarter in how it handles the game-locking input loop. But Kirby’s Adventure seems ripe for exploitation, according to duress AC.

A split community

The SMB3 run is an impressive technical feat, but it’s not without controversy in the TAS community. “Subframe input…is seen by some as undermining the work of the past decade [in tool-assisted speedruns]dureoAC told Ars. “Some consider this class of interaction with the console to be somehow impure because it doesn’t conform to the rigidly held dogma of aligning input to the edge of a frame, while others are just concerned that this only yields runs that just go to the credits in the first seconds of the game.

Adelikat, who runs the TAS clearinghouse TASVideos.org, outright posted it in the #TASVideos IRC chat room. “I’m not thrilled… There’s an artistic value that’s gone. The sportsmanship is gone, and the entertainment value is gone, of course, after the first one… It ruins the fun for me.”

A quick poll of some other members of #TASVideos highlights the controversy. “For me personally, I love the technical achievement of it,” said Fog_TAS, “but I question its entertainment value for non-technical people watching. If it’s possible in multiple games, it takes the magic out of the hiccup.” Marysia worries that “it won’t be long before every TAS ends in a flash, or at least such an ending will be considered TASing’s ultimate goal. Personally, I think TASing is more about perfect entry than breaking of games.”

“Personally, knowing it’s a thing and roughly why it’s happening is satisfying enough in itself,” Scum added. “I have no desire to see it applied to every game it might work on or see video evidence of it in action.”

Whatever the effect on the TAS community, it’s still amazing how well a team of hobbyists armed with a gaming robot can exploit minor flaws in decades-old NES hardware and software. We can’t wait to see what they come up with next.

By akfire1

Leave a Reply

Your email address will not be published.