DULLES, Va. – Regular viewers of the annual Awesome Games Done Quick (AGDQ) video game speedrun marathon are probably well acquainted with the power of TASBot (short for tool-assisted speedrun robot). Two years ago, the emulator-driven bot used its controller-port interface to write a simple version of it Pong and Snake running on top Super Mario World cartridge. Last year TASBot outdid itself by using a copy of Pokemon Red and a Super Game Boy to force a live IRC-based Twitch chat through an unmodified Super Game Boy.
By now it just started to feel a bit predictable to just take over a game and replace it with a brand new app. So this year TASBot decided to show off a new skill. During the AGDQ marathon, the bot went out to edit new features in a game that is still active in active memory. TASBot also wanted to be magnanimous with its new capabilities, giving human players (and livestream viewers) the chance to edit the game on the fly.
But how did TASBot – and the team of programmers behind it – plan to make an old game of Super Mario Worldruns on a standard SNES, in a heavily editable game of Super Mario Creator? Fortunately, we had a behind-the-scenes invite to the event and the opportunity to find out.
The archived Twitch video of TASBot’s SNES “Super Mario Maker” exploit looks like magic; or at least something that requires a hacked ROM or memory manipulation via a Game Genie-like device. But it’s important to remember that, as in the past, everything TASBot does is technically possible on standard classic gaming hardware and software. That is, it is possible provided that you have the superhuman ability to input precisely timed controller inputs 60 times per second.
The first step to hacking a level editor on top Super Mario World has become an old hat for TASBot. The robot takes “total control” of the system through mysterious in-game glitches. It then juggles items of pixel-perfect positioning and timing in a fraction of a second to effectively write and execute a piece of assembly code through the system’s active sprite management memory.
This year’s acquisition uses a slightly different total control method than those used in years past. The new route uses precise pausing and resuming after being hit by a mole enemy to line up some in-game timers just right to display that crucial memory code. The end result is the same: TASBot tells the game to start reading controller input as raw, binary programming code at a rate of about 3.8KB/s.
From there, it’s relatively easy for TASBot to use precisely timed button presses to essentially write a new program that gives it “total control” of the SNES. The details include first writing a block loader to a small, “safe” area of memory, then executing that block loader to continuously sample the controller input for new data (the process is described in much greater detail in this 2015 article). Pokémon Red/Super Game Boy Exploit).
The overall control process was made easier for the TASBot team this time by a handy Lua script that can recode arbitrary PC files into the correct controller inputs. “Before ‘Pokemon Plays Twitch’, when we wanted to test a new version of the payload, we depended on Ilari to create a new movie file,” TASBot organizer Allan Cecil (who goes through DwangoAC online) told Ars. “For this release, Ilari has created a handy ‘script kiddie’ Lua script that allows us to specify a binary file to write to a particular location in memory based on its file name.”
Hidden in the SRAM
In previous demonstrations, after TASBot took full control of a system, it would ditch the existing game and code the software it wanted instead:Pong, Super Mario Bros.Twitch chat, etc. This year, the level editing script the team was building would be on top of the still active Super Mario World code already in memory. That way, instead of recoding an entire Mario engine, the code could simply call existing functions for everything from block placement to screen scrolling to Mario physics. As Cecil put it, “Hey, why write something new if you don’t have to?”
As you can imagine, keeping the real thing Mario code in active memory while writing a level editor requires a much lighter touch and much more delicate memory management than in the past. “There’s not much head [SNES] memory once left Super Mario World finished gobbling it up,” said Cecil.
As it stands, TASBot can only overwrite a few small, “safe” portions of the system’s 128KB of main RAM without destroying the copy of Super Mario World already loaded there. Plus, that secure RAM is divided into small, scattered slots that are difficult to access contiguously (and the much larger ROM chips on the cartridge itself can’t be overwritten at all).
The TASBot team briefly considered trying to write and run the level editor on the RAM allocated to the SNES sound chip, but Cecil said that idea was quickly discarded. The sound system is designed to run completely independently of the graphics and logic systems that power the rest of the SNES, so trying to hardcode and run executable logic on it “goes against everything the SNES is supposed to do” (even more so than everything else TASBot apparently does). “Access [the audio RAM] is just so actively risky and dangerous. You’re just asking for trouble,” he said.
The safest place to store TASBot’s embedded code, it turned out, was on the game cartridge itself. Specifically, the little bit of rewritable SRAM that many SNES games include for storing battery-backed save games. Overwriting would ruin any saved progress on the cart itself, but it wouldn’t change how it behaves Super Mario World not encode at all.
While the original Super Mario World cart only has 2 KB of SRAM to work with, Nintendo later released an extended cartridge that included the Super Mario All Stars compilation and Super Mario World in one package. The extensive Super Mario All Stars + Super Mario World (SMAS+W) cartridge has a whopping 8 KB of SRAM to store save files for all those games. TASBot would eventually need almost all of that extensive space to write its level editor.