A hardware bug causes the NES to misread inputs sometimes (losing 1bit), if music is playing.
To work around the bug, the game only accepts inputs if the same key is pressed for two consecutive input cycles (an input cycle is much shorter than one frame)
If the inputs don't match, the game loops and tries again.
This loop has no hard coded limit, so if you spam changing inputs fast enough for long enough (using a computer; your fingers aren't fast enough), the game keeps trying to read inputs until it's time for next frame to be drawn to screen.
The NES clock sends an interrupt to prompt the drawing code to run.
The input code and the drawing code use overlapping areas of memory, and the game didn't do what it needs to do (at a low level in memory) to be ready draw the frame properly, and ends up reading drawing instructions from input bytes instead of what the game was designed to put into that area of memory.
(This part is where the real dirty magic is; it requires understanding of assembler and interrupts to properly explain how it works. Basically one function interrupts another and starts running before the first one finished, and the functions use different invocation logic, so the second function ends up exiting "the wrong way" and the program jumps to a wrong return location when it's done.)
Thus the attacker can write run semi-arbitrary code that makes the game jump to the instruction that starts playing the ending/credits scenes.
A hardware bug causes the NES to misread inputs sometimes (losing 1bit), if music is playing.
To work around the bug, the game only accepts inputs if the same key is pressed for two consecutive input cycles (an input cycle is much shorter than one frame)
If the inputs don't match, the game loops and tries again.
This loop has no hard coded limit, so if you spam changing inputs fast enough for long enough (using a computer; your fingers aren't fast enough), the game keeps trying to read inputs until it's time for next frame to be drawn to screen.
The NES clock sends an interrupt to prompt the drawing code to run.
The input code and the drawing code use overlapping areas of memory, and the game didn't do what it needs to do (at a low level in memory) to be ready draw the frame properly, and ends up reading drawing instructions from input bytes instead of what the game was designed to put into that area of memory.
(This part is where the real dirty magic is; it requires understanding of assembler and interrupts to properly explain how it works. Basically one function interrupts another and starts running before the first one finished, and the functions use different invocation logic, so the second function ends up exiting "the wrong way" and the program jumps to a wrong return location when it's done.)
Thus the attacker can write run semi-arbitrary code that makes the game jump to the instruction that starts playing the ending/credits scenes.