Okay, I'll try and summarize p4plus2's analysis, even if I don't fully understand it. (Later, I'll ask him if he would mind posting to cover things I missed/understood wrongly).
OAM does not change the game mode. The lag frames you see in the movie (where he pauses, and executes button input on three controllers) are all BRKs. He sets up OAM so it jumps to $014219, which is the SNES registers for input (See here
). Then he uses the lag frames to construct opcodes via 3 controllers of input, which then change the game mode. The reason being that regular controller RAM could never be accessed during lag frames, as the game does not poll input. But the SNES registers don't work this way.
So basically, Snes9x is emulating things incorrectly. In particular this part:
014219 brk #$00 A:01f5 X:0006 Y:00f5 S:01f4 D:0000 DB:01 NvMXdizc V:227
01421a brk #$00 A:01f5 X:0006 Y:00f5 S:01f5 D:0000 DB:01 NvMXdizc V:227
The stack pointer (S:****) isn't working correctly. p4 thinks that in Snes9x, values are allocated randomly on the stack, whereas on real console or BSNES, the values are pushed to the stack.
This is as far as his analysis is so far. I wish language barrier was not so much an issue. :(
The good news is, p4 thinks he can replicate the glitch with legitimate means, similar to how the old run works, by manipulating OAM in a different way I guess. I hope so. :p