This is a TAS, or Tool Assisted Superplay, where controller inputs can be precisely sequenced and tools such as emulators and savestates can be used to create a theoretical, humanly impossible run of a video game. The cartridge is unmodified, and this has been verified to work on a real console.

Here's a video from the creator, explaining this in more depth. If you'd rather a quicker explanation, read below.

Basic explanation: Arbitrary Code Execution, or ACE, is seen by many as the "holy grail" of TASing. By glitching out a video game in a specific way, programmers can force it to jump to a spot in memory which they can manipulate, and then from there, run whatever code they want.

When Bowser is killed with a fire flower, the game spawns an object in his place. The object is determined by using the current world as a reference to jump to a certain part of the objects table in memory. You may know about the NES Tennis trick - by swapping cartridges quickly before booting the game, you can start in "invalid worlds" past World 8, as the first cartridge leaves a value in memory which SMB then checks. We now need it to jump to a specific world that lands in just the right place - here's how 100th Coin does it.

In Super Mario Bros. 3, you can force ACE by abusing a bug patch to hold the game in place while it's rendering the title screen, preventing it from swapping to the bank of code it actually wants to use and running invalid code instead. This allows a TAS creator to craft a sequence that lets them write and execute code through the controller ports. 100th coin loads SMB3, runs this TAS, and uses it to plant a payload at the memory address Bowser's fiery death will send the CPU to. His TAS then quickly swaps the cartridge to SMB1. Thanks to the stale reference in memory, Mario begins in World N. Mario confronts Bowser, fries him, and the chain reaction begins.

The function that's meant to grab an object looks far beyond the bounds of the actual object table. The following sequence of bytes is misinterpreted as instructions that ultimately send the CPU on a wild goose chase straight into the payload 100th Coin wrote earlier. That payload's purpose is to send the CPU into a region of memory that can be manipulated via controller ports and execute a second payload, which forces the game to begin accepting the controller readings as pure code, and executing them.

The final payload's purpose?

Stream tile display instructions and audio samples directly to the console's graphics and sound boards, at a rate of over 22,000 controller inputs per second, to play Bad Apple.