I'll bet you a nickel something screwy is going on with the JMP Indirect logic. If it helps, Super Mario Bros. for the NES has been disassembled with wonderful comments and labels:
This calculates an address based on the current game mode, and then jumps there. When the player performs any action that changes the level, this mode cycles a few times while the game code blanks the screen, switches gears, and loads in new data. The indirect jump and branching logic that drive the game's mode switching are tricky to get right, and if they're wrong, this little kernel will break in surprising ways.
When I was troubleshooting my branching routines, I had my emulator pause on SMB's first indirect jump, then found that position in the disassembled code and followed along. I mean, you can achieve similar results by unit testing or working to pass all of blargg's tests, but I found it much more fun to trace the emulator in a live environment, running "production" code.
> I'll bet you a nickel something screwy is going on with the JMP Indirect logic.
You've lost a nickel! It was a problem with my signed-offset branch function where a bad cast was allowing 0x80 (-128) to overflow. It was really fun trying to troubleshoot by hooking certain memory accesses and subroutines, but what wound up fixing it was investigating the crash of Blargg's `instr_test-v5/rom_singles/11-stack.nes`. Thank you for your help!
> I'll bet you a nickel something screwy is going on with the JMP Indirect logic
I think we're on the same page, except that you sound like you actually know what you're talking about and I'm just following my gut, also known as `guessing`.
https://gist.github.com/1wErt3r/4048722
At some point during every frame, shortly after the NMI routine completes, the game ends up on this particular line of code:
https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L929
This calculates an address based on the current game mode, and then jumps there. When the player performs any action that changes the level, this mode cycles a few times while the game code blanks the screen, switches gears, and loads in new data. The indirect jump and branching logic that drive the game's mode switching are tricky to get right, and if they're wrong, this little kernel will break in surprising ways.
When I was troubleshooting my branching routines, I had my emulator pause on SMB's first indirect jump, then found that position in the disassembled code and followed along. I mean, you can achieve similar results by unit testing or working to pass all of blargg's tests, but I found it much more fun to trace the emulator in a live environment, running "production" code.