3 ms·

Unbelievable. I had watched the glitch itself too many times to count. But seeing it explained makes it even more impressive. I would love to hear the story o

Unbelievable. I had watched the glitch itself too many times to count. But seeing it explained makes it even more impressive. I would love to hear the story of who figured out how to do this and how much trial/error it took. 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. http://www.polygon.com/2014/1/14/5309662/bizarre-super-mario-world-hack-turns-the-game-into-pong-snake http://www.polygon.com/2014/1/14/5309662/bizarre-super-mario...

steckerbrett 11y ago
Probably not as awful as it sounds on the surface, with an emulator you can sit and stare at the current state of the machine quite handily. It would be essentially impossible to work this sort of thing out without the aid of tools.
- haberman 11y ago
  Totally, but even with an emulator, the number of obscure glitches that have to be strung together in just the right way to make this work is staggering.
  - Mahn 11y ago
    I would guess the games are disassembled and dissected first in order to identify potential exploit paths/bugs.
JoshTriplett 11y ago
> 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 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 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.
- striking 11y ago
  IIRC, the sound sample thing was just a happy accident. They had no intention of adding sound, but they left in the sound playing code and discovered that Nintendo used the exact same sound lookup table. Which is perhaps even cooler.
  - Mahn 11y ago
    Thereby proving that Super Mario World was built off the original Super Mario Bros. Neat.
chinpokomon 11y ago
For the Pong and Snake games, the code that is written is a bootstrap to read values from the controllers and write them to memory. Then it jumps to those routines. It uses similar techniques to write code to different locations of memory, just like this game credit warp. After the bootstrap code is written, Yoshi eats another Chuck, and the code executes the bootstrap. At this time, the NES reads from the controllers. The controls aren't just your typical controller, as I recall, they are actually multiplexed controller cables plugged in, allowing more bits to be read and thereby written. The code at this point can be anything. Including this [https://youtu.be/bu4Z_-1K_Gw https://youtu.be/bu4Z_-1K_Gw].

steckerbrett 11y ago

Probably not as awful as it sounds on the surface, with an emulator you can sit and stare at the current state of the machine quite handily. It would be essentially impossible to work this sort of thing out without the aid of tools.

haberman 11y ago
Totally, but even with an emulator, the number of obscure glitches that have to be strung together in just the right way to make this work is staggering.
- Mahn 11y ago
  I would guess the games are disassembled and dissected first in order to identify potential exploit paths/bugs.

JoshTriplett 11y ago

> 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 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 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.

striking 11y ago
IIRC, the sound sample thing was just a happy accident. They had no intention of adding sound, but they left in the sound playing code and discovered that Nintendo used the exact same sound lookup table. Which is perhaps even cooler.
- Mahn 11y ago
  Thereby proving that Super Mario World was built off the original Super Mario Bros. Neat.

chinpokomon 11y ago

For the Pong and Snake games, the code that is written is a bootstrap to read values from the controllers and write them to memory. Then it jumps to those routines. It uses similar techniques to write code to different locations of memory, just like this game credit warp. After the bootstrap code is written, Yoshi eats another Chuck, and the code executes the bootstrap. At this time, the NES reads from the controllers. The controls aren't just your typical controller, as I recall, they are actually multiplexed controller cables plugged in, allowing more bits to be read and thereby written. The code at this point can be anything. Including this [https://youtu.be/bu4Z_-1K_Gw https://youtu.be/bu4Z_-1K_Gw].