issue with mmc3 mapper irq callback

[monkeysoop]

When I was testing my own emulator with Wario's Woods the mushrooms that you have to pick up/place wasn't rendering at all, also Mega Man 3 had problems with Gemini man level and most obvious was Jurassic Park which had many obvious glitches even at the loading screen.

The problem was that in mmc3 when writing to $E000 and $E001 it actually changes the internal cpu status register's flag and that is important because the irq does nothing if irq disable flag is set.

Source: https://www.nesdev.org/wiki/IRQ

[amhndu]

The problem was that in mmc3 when writing to $E000 and $E001 it actually changes the internal cpu status register's flag and that is important because the irq does nothing if irq disable flag is set. Source: https://www.nesdev.org/wiki/IRQ

My interpretation is that there are two ways of generating a interrupt, an instruction or the IRQ line. Both can be enabled/disabled based on the cpu status flag, which is a CPU register and thus can be set ONLY using SEI/CLI, the CPU doesn't expose it to the cartridge any other way. However, since MMC3 has an interrupt counter that uses the IRQ line, this specific mechanism can be enabled/disabled.

Writing to $E001 will simply allow the MMC3 to generate IRQs - the counter remains unaffected.

I suspect it might due to misaligned timing, see https://www.nesdev.org/wiki/MMC3#IRQ_Specifics

When using 8x8 sprites, if the BG uses $1000, and the sprites use $0000, the IRQ counter should decrement on PPU cycle 324 of the previous scanline (as in, right before the target scanline is about to be drawn). However, the 2C02's pre-render scanline will decrement the counter twice every other vertical redraw, so the IRQ will shake one scanline. This is visible in Wario's Woods: with some PPU-CPU reset alignments the bottom line of the green grass of the play area may flicker black on the rightmost ~48 pixels, due to an extra count firing the IRQ one line earlier than expected.