> I'd also love to see a similar explanation of the mario pong/snake glitch. It seems it goes even further and is able to actually input large amounts of arbitrary code.

The video showed how to use sprite positions and similar to construct a small amount of code, and then the bug in Yoshi's eating to jump to that code. As hinted at in the video, there's a jump table for what happens when Yoshi eats various things, and if you eat something you "shouldn't" be able to, you jump to an unexpected location, which with care can be used to jump to the code you wrote in the sprite table.

In the video, this is used to write to a state value that determines what the game is doing, jumping directly to the last bit of the credits. That requires quite a bit of precision, but with enough practice, a player can do it in real-time, just as players can learn to perform tricks that require frame-precise inputs.

For the arbitrary-code variant, as with other "total control" hacks (exploiting a game to execute arbitrary code), the goal is to code a tiny loop that rapidly reads controller input into memory and then executes it. Sometimes the initial read-and-execute loop is simplified and only reads a few bits from the controller at a time, but is then used to bootstrap a more complex loop that can input code from the controller(s) more rapidly. For instance, SNES total control hacks often bootstrap into a loop that reads from 8 controllers (two multitaps of four controllers each) simultaneously, once per frame.

In the case of the TAS you mentioned, that input loop reads and executes code implementing games of Pong and Snake using sprites already available in memory, which minimizes the amount of data required. The original Total Control hack, for Pokémon Yellow (https://www.youtube.com/watch?v=p5T81yHkHtI), took a while because it read in an image and music, input 8 bits at a time using the single Gameboy controller (four directions, start, select, A, and B, for 8 bits). To improve entertainment value, it bootstrapped into a loop that displayed values as they were read, as well as reading an appropriate message from the original game first ("It's the game program! Messing with it could bug out the game!").

See https://www.youtube.com/watch?v=p5T81yHkHtI#t=10m25s to skip to the point where it starts entering code via the controller, and notice the displayed controller inputs at the bottom inputting a byte at a time. If you watch carefully after the code starts being displayed, you'll notice that the inputs match the displayed code, such as all the buttons being pressed or released at once to input FF or 00.

And the use of an image and music from something that didn't exist at the time Pokémon Yellow was released made the magnitude of the original Total Control hack clearer even to non-programmers: brand new data was being input into the game.

A more recent hack for Super Mario World put a faithful recreation of the original NES Super Mario Bros into memory and executed it, which you could actually play. (It input and used the graphics from Super Mario Bros, but reused sounds such as jumping and collecting coins from Super Mario World, both to reduce the "download" size and to simplify the code, since the sound hardware on the SNES is drastically different.)

All total control hacks for current games follow the same general pattern: find a way to jump to any user-controlled data that can be formed into useful machine-code instructions (an item list with item indexes and quantities, character stats, sprite positions, etc), use those (possibly constrained) instructions to read controller input into memory and jump to it, bootstrap into a more efficient (and entertaining) read-and-execute loop if necessary, read piles of arbitrary code into memory, and jump to it.