[GrantMoyer]

I'm not the author, but these video-in-game projects typically work with a few phases:

1. Get the game into a specific state by performing specific actions, moving to specific positions, performing specific inputs, etc. so that a portion of the game state in RAM happens to be an executable program.

2. Jump to that executable code such as by corrupting the return address in the stack with a buffer overflow

3. (optional) The program from 1 may be a simple "bootstrap" program which lets the player directly write a new, larger program using controller inputs then jumps to the new program.

4. The program reads the video and audio from the stream of controller inputs, decodes them, and displays them. The encoding is usually an ad-hoc scheme designed to take advantage of the available hardware. The stream of replayed inputs is computed directly from the media files.

[LocalH]

Specifically, this TAS abuses the fact that SMB doesn't clear RAM on bootup to use SMB3 to write $16 to the "continue world" RAM location, and then hotswaps to SMB1 to start the game in World N-1 which makes the rest of the TAS possible. If you download the TAS and use it with SMB1 on an emulator, the included base savestate will already have $16 in that RAM location, for convenience. The main HN link for this submission has the full technical writeup.