No joy with the irq: jmp irq. The stack is still corrupt on entry. This is definitely being caused by a BRK, according to the LoopyNes debugger, but I can't trace it back to where the BRK occurs!

Can BRK occur in other instances besides a brk instruction, such as a stack over/underflow, etc., either on the hardware itself, or in the LoopyNes emulator? I'm thinking the 6502 is probably pretty lenient on its bounds checking, i.e, no abnormal state indicated on stack over/underflow, but I figured I'd ask anyway. I don't have much experience with 6502, but I've done x86 asm before, program for a living, and pick up these things like nothing. In fact, I've come from playing with a SMB level editor with little knowledge of NES hardware to where I am now in 1 week, just by digesting every tech doc I can find, and making small demos to test the parts that are unclear.

The demos I've made include walking through the tutorial from Just Another Vision Studios, and enhancing it to include a static background and collision detection with the edges of the "playfield", and some menuing demos that doubled as testbeds for rom bankswitching for MMC's 1, 3, and 5, which I used to fill in the gaps in the tech docs I've found on those mappers. I even got the backgrounds stable on LoopyNES! This BRK problem is the first thing I've needed to go outside my own research for.

BTW, the NESDev site has been a great resource for all this learning!
Maybe I'll dig into my assembly listing for SMB and try to find a nice routine in $e000-$ffff that can be moved into my $9cc4-$9fff range, trying your other suggestion...