As part of the tool-assisted speedrun (TAS) block at Summer Games Done Quick, competitor ais523 used a newly found glitch for his robot to beat Super Mario Bros. 3 in JUST two seconds. Not content with ending human civilisation, it seems the cyborgs are dominating our video games too!

So how the hell was this pulled off? Put simply, the bot was pressing buttons really fast – 6,000 times a second to be specific. Games of the 90s don’t expect this kind of high speed input, which essentially breaks the game by turning simple controller inputs into memory-manipulating code that can be influenced.

Many games react in many different ways to this glitch, and it turns out Super Mario Bros. 3 reacts by taking you straight to the winning final screen.

In more detail from the Reddit comment ais523 posted:

I actually started looking into the basic glitch behind that a few days ago (I had the idea months ago but forgot to investigate it or tell anyone about it), and let the TASvideos community know about it. I realised that such a thing would be possible in many games as a result of reading NES documentation ( this is the page that got me thinking along those lines); if you're reading the controller repeatedly until you get two values the same (in order to work around the DPCM/controller conflict), then if the controller reads a different output each time (because you're mashing the controller really fast), it's going to get stuck in a loop, potentially allowing for the code that handles the start of a frame running recursively. If the game isn't designed to expect that to happen (and if the code in question isn't really laggy, why would it?), bad things happen, and it was a case of finding a game in which the bad things in question would happen to let us win instantly.

total_ did a lot of work in getting the glitch in question to work on SMB3; I had no idea which games it would work in, and was happy to see it working in such a well-known game. I'm not that clear on the details of how it works in the exact case of SMB3, except that the game somehow naturally starts running the controller ports, so you can hold a combination of inputs that (when interpreted as code) jump to the credits.

All this happened while SGDQ was running, and the TASbot schedule got changed in order to add the run in because it's such a mindblowing thing to watch. As a fun fact, we pretty much needed TASbot in order to test out the glitch; very few emulators are capable of handling it correctly, so much of the testing was done on an actual NES by getting TASbot to test out our ideas.