Transcription

You may have seen the speedrun of Super Mario Bros. 3 that completes the game in just about 11 minutes. The general route is pretty simple, gather two warp whistles from these two stages in world 1, use them together to go directly to world 8, then get through that world and defeat Bowser. But even a straight line isn't always the shortest path. Sometimes, the shortest path is through a wormhole. On August 1st, 2020, Zekubi achieved the seemingly impossible feat of beating the game in 3 minutes and 2 seconds. This is the Super Mario Bros. 3 Any% speedrun explained. The first two minutes are very similar to the Any% No-Wrong Warp run by MinchFlowerPower. Zekubi gathers P-Speed early in this level and blasts through it with ease. Notice how the Hammer Brother moves only once at the end of the stage. This will be the case for all four Hammer Brother movements in the run. This optimal pattern, which only has a 3% chance of happening, is required to get such a good time. But the first Hammer Brother movement was actually manipulated. This game's random number generation function runs on every frame and always goes through the same sequence of numbers. As a result, any random element can be manipulated by having it happen on a specific frame. By waiting on the title screen until this exact time, Zekubi set up the Hammer Brother to move by only one tile as long as he finished 1-1 within a 5-frame window. After that, it becomes too difficult to finish levels with this kind of accuracy, so the remaining movements are essentially random. This does bring up the chance of optimal movements from 3% to 6%, assuming the manipulation is done right. Quick side note, in my previous video, I made a mistake with the odds of each direction at a T-shaped intersection. All of the percentages in this video have been corrected to reflect the actual odds. In this level, he does the same strategy of reaching P-Speed on the pipe, then tries to get Mario to run down slopes as much as possible. Mario runs about 5% faster down slopes with a speed of up to 59 compared to 56 on flat ground. Over the course of the level, running down slopes saves about 3 or 4 frames. Here, the strategy is again identical to the no-wrong-warp run. Zekubi needs a mushroom to get the Super Leaf in the next level, and he needs to wait 4 seconds on this block to reach the secret exit and get the first warp whistle. Now, all Zekubi needs is the second warp whistle from this fortress' secret exit, which he flies up to using the Super Leaf. Here though, he doesn't go into World 8. Instead, he goes into World 2, then warps to World 7. Why do such a thing? Well, let's see what happens. So, what happened? In short, Mario hit a glitched node block and the game crashed in the perfect way to make it immediately load the ending sequence. To help better understand why, I painstakingly recreated the run frame by frame on emulator. The result very closely matches the original and will let us analyze all the variables at play. First, Mario hit the side of this pipe and entered it in the wrong direction. With enough speed, Mario can sometimes move into solid blocks. He can usually only stay inside of the block for a single frame, after which he's pushed out. But by clipping inside of the pipe at this spot, he's also standing on a pipe exit tile. Normally, because pipe exits are always connected to a pipe, Mario can only go in them from one direction, so nothing was made to specifically prevent Mario from entering them the wrong way. So, by pressing down against the top of the pipe exit tile, Mario goes down into it instead of up. When Mario's traveling in a pipe, he simply moves along the pipe until he reaches another exit tile at the other end. However, in this case, there's no other end, so Mario keeps going down this glitched pipe until he leaves the bounds of the level map. So, where does he end up? Well, this is where it gets complicated. The level data is divided into up to 16 screens ordered from top to bottom in vertical levels. The game uses a table as sort of a reference sheet. For any given screen, the table holds the memory address of where the level data for this screen is located. When Mario reaches the 17th screen, there's no more level data, so the game starts to look beyond the table to find the memory address. The address found is garbage data, which is a value used for a completely unrelated purpose that makes no sense when used as a memory address for level data. The game then goes to the wrong place and finds more garbage data that it interprets as if it was level data, so the end result is a garbled mess. To make things worse, tiles are drawn on screen through a separate process that also goes horribly wrong, so the garbage on the screen is different from the garbage that is actually there. Mario keeps going through this mess until luckily, at the top of the 19th screen, the garbage data happens to line up so that there's a tile that acts like a pipe exit and frees Mario from the glitched pipe. On the right edge is the culprit for the whole game crash, an invisible note block. The animation when Mario bumps a block is more complicated than it looks. Blocks are background tiles which are generally incapable of being animated in this way. To get around this limitation, the background tile is removed during the animation and replaced with a sprite. That removal is what causes the crash. Super Mario Bros 3's ROM is eight times larger than what the NES can load. Instead of loading it all at once, the ROM is subdivided into 32 banks that can be swapped in and out of memory so that only four of them are loaded at any given time. The memory address for the 19th screen happens to point to a location that's normally used to control which banks need to be loaded. Normally, only the middle two are ever swapped out. The first one is always bank 30 and the last one is always bank 31. But when the game attempts to remove the note block tile for the bumping animation, it swaps out these two banks instead, replacing the very code it's currently running for a different part of the ROM. This causes one of the key elements of the NES processor to fail, the stack. Instructions in the code are organized into multiple layers of routines and subroutines so that any given basic function has its associated routine that can be called from any point in the code. When jumping around between subroutines, the processor needs to remember where it came from so that it can go back there after it's done. This is what the stack is used for. The stack is essentially a list of return addresses in reverse chronological order. Whenever a subroutine is called, the memory address where the call was made is added to the stack, and when a subroutine is done, the processor returns to the address at the top of the stack to go back where it came from. Typically, the number of return addresses in the stack matches the number of layers in the subroutines the processor is currently in. However, in this case, because a different part of the ROM was suddenly loaded in, this balance is thrown out of the window. After swapping out the ROM banks, the processor starts running code from inside a subroutine, at the end of which is an instruction called RETURN FROM SUBROUTINE. So, the processor looks at the stack and finds only one return address, so it goes back to that address, clears it from the stack, and resumes executing code from there. But because the ROM bank was swapped for a new one, the return address no longer points to where it was supposed to. Instead, it points to yet another subroutine, which ends in the same instruction, RETURN FROM SUBROUTINE. The problem is, there's nothing in this stack to return to anymore. This is called a stack underflow. As it tries to find a return address, the processor loops back around to the other end of the stack. Super Mario Bros 3 doesn't make use of all 128 entries in the stack, so the last entry is instead used for other purposes. Specifically, it's made up of two variables, one for the status bar mode and one for the level mode. For a vertical stage, they take up values 00 and 80. This means that 0080 is used as a return address to continue executing code. This leads directly into these variables. When executed like code, they're ordered in this way. The first byte is a code number for an instruction, and the next two bytes are parameters given to that instruction, usually a memory address. Let's look at this instruction. It's made up of the horizontal position of enemy slots 3, 4, and 5. This is interesting, because all three variables can be manipulated to any value we want as long as the right enemies are placed at the right location. This means that any code instruction can be executed here as long as the enemies are in the correct horizontal position. But surely, you can't have three different enemies move into pixel-perfect positions, right? Yes you can, because that's exactly what Zekubi did. First, the enemy slots were manipulated by killing the Piranha Plants while moving up in the level, and loading the enemies in the correct order so that slots 3, 4, and 5 are taken up by these three Koopas. Zekubi kills the Koopa in slot 4 on this block, which puts it at position E3. Next, he flips the Koopa in slot 3 and goes down the pipe when it's at position 20. This pipe entry has a two-frame window for the position to be correct. It's interesting to note that this part did not go as intended. Zekubi turned around slightly too early here, which threw off his usual method of timing the pipe entry right. To compensate, he did a turn back to avoid overshooting the pipe and winged it for the timing. Luckily for him, it worked, and the shell was correctly stopped at position 20. Finally, he carries with him the Koopa in slot 5 all the way down to the 19th screen where he throws it to the left. On the frame where its position is at 9,5, Zekubi jumps, activating the crash and leading the code to read the instruction 20 E3 8F. 20 is the code for a jump to subroutine instruction. This instruction essentially makes execution jump to the address specified by the next two bytes. So execution moves to 8F E3, which would normally be the function that loads the ending sequence. But remember, after the ROM bank was unintentionally swapped for another, the ending sequence can no longer be found at 8F E3. Except, very conveniently for us, one of the things that this instruction does is to swap the ROM banks back to their intended positions, which means that the ending sequence is put back in its place just in time to be jumped to. So after all of these unintended hoops and hurdles, the game finally jumps to the end and Princess Peach is rescued. Many things can go wrong though. Before reaching the jump instruction, the code runs through other variables so they need to have values that translate into code that doesn't crash or derail execution. For example, the horizontal position of this Koopa is used as an instruction as well. In this run, Zekubi was fast enough so that the Koopa deloaded with a horizontal position of 7,4. If he had been two frames slower, the Koopa would have had a position of 7,2 instead, which translates into an instruction that instantly stops execution. 5 of the 11 most common Koopa positions would result in the trick failing. On top of that, the sound engine also runs into its own issues. In short, the sudden jump to the end sequence deletes the music data that the sound engine was reading, which causes it to get caught in the loop. Depending on where the music was before the jump, the processor can eventually exit the loop and play this glitched sound, or it can get stuck for longer and delay the ending, or even worse, eventually hit an instruction that tells it to quit all execution. Here's a quick recap. Mario clips partially inside of this pipe which allowed him to take it down instead of up. This glitched pipe has no exit so Mario goes down until he's beyond the bounds of the level and into garbage data where a note block can be found. Interacting with an out-of-bounds note block causes the game to go through a series of unintended jumps in its code that eventually leads it to read the horizontal position of enemies as if they were instructions of game code. Through careful manipulation, the receptive values which translate into a simple instruction that tells the game to load the end screen, so that's what it does, and the game is beaten this way. The run itself is so close to perfect that with this current strategy, even a seems very unlikely. Zekubi only lost 11 frames on the overworld, a few frames entering the secret door in the fortress, and a couple more in 7-1. Keep in mind though that improving a stage by a frame or two most likely would cause the Hammer Brother to go the wrong way. Because of that, there are only a few select frames where a stage can be completed to get optimal patterns, making slight improvements even harder to come by. The tool-assisted speedrun uses a completely different and faster setup that makes use of a piranha plant to replace one of the Koopa shells, but good luck replicating that with a controller. As of right now, as close as it is, a time of sub 3 minutes looks to be humanly impossible to achieve. If you want more in-depth information about what goes on in the game's code during the wrong warp, please watch this video by Retro Game Mechanics Explained. Although slightly outdated by now, it was the most vital piece of information I had when making this video and a lot of the visualizations were based on Isofreeze's incredible work, so I want to thank him for making it as well as helping me troubleshoot a few things. Also, more detailed explanations of the sound glitch and other internal mechanics written by Cab Audio can be found in the video description. Thanks for watching.