Problem with mapper 66 on emulators or everdrive n8?

My Ghostbusters romhack uses mapper 66. It always worked fine on all emulators and also on my krikzz everdrive n8. At some point there was a modification to the rom that broke compatibility with the everdrive and virtuanes: the game won't boot up (gray screen). Only now I've noticed it.

The rom was expanded from 2 PRG banks to 4. So, rom addresses 0x0000-0x7FFF in the original to 0x0000-0xFFFF in the new one for PRG. This was working on all emulators and the everdrive. But a modification on the end of the final bank seems to be causing trouble with the everdrive and with virtuanes, even though fceux tells me that code isn't run at startup at all. So, either the everdrive and virtuanes isn't implementing the mapper correctly, or all other emulators aren't. Any idea?

Works:


Won't work (though fceux insists this isn't even run/read at boot up):


Just wanted to share. I'll try modifying the code so it stays in the same address. I'm guessing it must be more likely that the mapper 66 implementation on everdrive isn't perfect and it's starting on the wrong bank or something, and out of chance it was working before.

I'd double check Unknown Initial Bank State, and Bus Conflicts.

Unknown Initial State: Make sure all banks will lead to valid bootup code at their reset vector. For the secondary banks, you'd want to switch to the first bank and run the normal boot code (try copying a small write and jump into RAM).
Bus conflicts: When writing to the ROM area of a cartridge (mapper registers), make sure the value in ROM at that address matches.

I suspect this is the hard-wired/fixed bank in the ROM (I cannot be bothered to look up mapper 66 to verify). Assuming it is, the answer becomes semi-obvious:

Original and modified:

$FFFA = NMI vector, points to $FFF2
$FFFC = RESET vector, points to $FFF2
$FFFE = IRQ/BRK vector, points to $FFF2

For whatever reason, you've chosen to omit the code at $FFF2 in the modified version ("won't work"). I suspect that byte is not $EA (nop), and even more so strongly suspect that it's a byte of an instruction (either valid or invalid opcode) that has operand bytes associated with it. Let's pretend the byte at $FFF2 happens to be $AD (lda absolute). The code executed then becomes this:


In other words: your vectors (especially RESET) are now wrong -- off by one byte -- and thus the code executed does not match what you think will happen.

Thanks guys, I think I got it working. It seems indeed that virtuanes and the everdrive are starting with banks 2-3 active. And yeah, my vectors on bank 3 were blatantly wrong! I also fixed the bank 3 reset vector so it won't result in bus conflicts. Thank you!