This is essentially the fundamental operation of a vector quantizer codec, which was popular in the early days of lossy video compression due to its low processing requirements. The fact that this term doesn't appear in the article means the author has independently discovered and reinvented this theory, which is itself quite impressive.
Where is the data coming from? Why does it involve playing part of SMB to start with? Besides the sprites used, what does this have to do with SMB at all? How is this different from just a custom ROM that would play this music video? Could you even fit this much data into a ROM?
I feel like there's a bunch of context you need to understand what this is about, and I clearly don't have any of it. And the "objectives" list at the top isn't helping ("1. Do a little tomfoolery 2. Execute arbitrary code..."). What are the actual parameters of this challenge, to understand what is actually being achieved?
Can anybody here help explain?
Edit: thank you so much for all the replies! Now I get why this is wild.
There's online forums for posting speed-running accomplishments and challenging others' accomplishments.
I'n this case, someone used the tools for automated speed running, to execute a glitch in SMB that allows for arbitrary code execution, then entered and ran a program that plays a Bad Apple music video, all with controller input. This is posted as a speed run with an accomplishment of playing the video.
A custom cartridge could be made to make a Bad Apple music video, but this is showing off a way to play the video using only SMB cartridges.
The data has to fit into RAM, which is much smaller than a tricky cartridge ROM. The music and graphic data is streamed as controller inputs, but the rest is done in RAM, using some data already in the SMB cartridge for video output, due to the low bitrate of controller input but also because the video processor can't display directly from RAM.
You could in theory perform this on the original SNES hardware with the original SMB game cartridge, if you can press the buttons on the gamepad fast enough and with the right timing.
This video is done by hand and explains a bit more about how and why it works: https://www.youtube.com/watch?v=hB6eY73sLV0
Controller inputs, same as if you were playing SMB yourself. This "just" presses buttons a lot faster and with more precision.
For a bit more background, this type of thing originally grew out of the game speedrunning community. Some people were interested in how much faster a speedrun could become if a "perfect" human with complete knowledge of the game state and perfect execution ran a game, and they modified games/created tools to mimic what such a run would look like, resulting in tool-assisted speedruns.
Because of this goal of showing off what might be theoretically possible, TASes are nearly universally restricted to ~the same input methods that humans would use. Where TASes differ is in how they're created, as they make use of external tools such as memory inspection (e.g., to observe RNG, player/enemy positions/speeds, etc.), frame advance/programmed input (for perfectly precise/reproducible inputs), and save states (so sections can be tried over and over again to correct mistakes, try different RNG, etc.).
> Why does it involve playing part of SMB to start with?
This is also tied to TASes showing off what is theoretically possible. Because of this, TASes pretty much always start from some "normal" state - game power-on (the normal start state for TASes submitted to tasvideos.org), a game state that is reachable by a normal human (e.g., done for one of the Ocarina of Time showcases at one of the Games Done Quick events IIRC), etc.
> Besides the sprites used, what does this have to do with SMB at all?
One of the "holy grails" of TASes is arbitrary code execution (ACE), where you manipulate a game into a state where you can get it to execute arbitrary code. This TAS shows that only using controller inputs it's possible to manipulate SMB and the game hardware into a state where ACE is possible.
> How is this different from just a custom ROM that would play this music video?
The difference is in the journey, not the destination. An analogy might be installing "plain" malware on a computer vs. finding/writing a RCE chain that gets you the same capabilities. The latter might be considered more technically impressive/interesting to certain communities.
> Could you even fit this much data into a ROM?
Not as-is in this case. Here the data is streamed in, sort of as if the controllers were serving as extended memory.
> And the "objectives" list at the top isn't helping ("1. Do a little tomfoolery 2. Execute arbitrary code..."). What are the actual parameters of this challenge, to understand what is actually being achieved?
TASes submitted to tasvideos.org come with a submitter-chosen list of objectives for the TAS since different TASes for the same game may aim to do different things. One TAS may try to finish a game as fast as possible using any possible method, another TAS may try to finish a game as fast as possible while restricting the use of some approaches, some TASes may try to finish a game as fast as possible while also getting a "true" ending or "full" completion, some TASes may just try to be entertaining without trying to be as fast as possible, etc.
Not all objectives are deemed worthwhile of official publication by tasvideos.org, but IIRC there aren't any hard-and-fast rules about what is acceptable and what isn't.
This particular TAS was submitted on April Fool's, so there's a bit of additional silliness involved.
It's not just controller inputs; it also needs a initial RAM setup, the SMB ACE happens because of out of bounds access when defeating Bowser with fireballs on level N, which is only accessible due to initial memory manipulation through another cartridge (or etc). This is in contrast to ACE on SMB3 which can happen on the title screen and is used to setup the initial RAM.
a good video that makes this tech more understandable (with explanations at the beginnimg and an amazing demo at the end) https://www.youtube.com/watch?v=PNbkv_DJ0f0
and some background https://tasvideos.org/ArbitraryCodeExecutionHowTo
Is it mentioned anywhere how big the payload is? How many button presses? Are the audio samples "streamed" or does it all fit in NES RAM?
I share the full assembly code in the tasvideos writeup: https://tasvideos.org/8991S#HereSTheAsmCode
To summarize what I put in the writeup, the 7-bit PCM audio was streamed in at approximately 25 Khz, (reading from the controller and writing to address $4011 every 71 CPU cycles.) while occasionally dipping to 9 Khz while streaming in the graphics data.
I have one question, as a general game hacker (mostly Guitar Hero/Rock Band) who also has a basic 6502 background from the C64. I wonder if there's any way to abuse input on an unmodified game to manage to poke $16 into $07fd without needing the SMB3 bootstrap. I don't know the SMB1 code well enough to find the answer to that, although I do know that games like SMW have a strong ability to use enemy X positions to get things set up just right to have the ability to install an arbitrary code and data payload into memory. But 6502 code isn't 65186 code so I'm not sure how much that matters.
Port of this to SMAS SMB1 wen :)
They use a modified ROM to set the memory state, but that could be done with SMB3 manually, apparently.
This is a video of it running on a console, though I'm uncertain how the inputs were provided
> TASBot is best described as a special R.O.B. robot outfitted with Legos to hold a custom circuit board that can exactly mimic the behavior of a video game controller. TASBot can play games on real video game consoles with superhuman abilities, usually leading to game breaking glitches in front of live audiences.
Could it run doom?
TASbot uses ACE to take over pokemon red running in a Super Nintendo Super Gameboy, then takes over the super nintendo itself, then streams twitch chat through the controllers to display on screen.
