PPU timing problem

I just fake it and assume that any instruction reading or writing to or from a hardware register is one of the 4 CPU cycle instructions, and that the read/write will happen at the end of the fourth cycle of that instruction. That's good enough to pass blargg's tests, since they just use 16-bit absolute addressing at the registers in question.

Obviously that's incorrect if it's one of the indexed instructions, but I've never seen any game access the PPU or Mapper IRQ instructions with an indexed instruction.


Here's something to think about when you emulate events that happen in the future, such as Interrupts and the like:

I'll use something on the Gameboy as an example, but I'm sure there are also NES games that do things like this.

The ROM repeatedly reads from the Interrupt Flag to see if an interrupt happens. Then the interrupt would happen. The CPU enters the interrupt handler, which acknowledges (clears) the interrupt. Then it returns to the code that's polling for interrupts.

On hardware, the interrupt would happen some time after the Interrupt Flag read instruction starts to execute. So when it reads the flag, it will read that an interrupt has taken place.

On some kinds of emulators, this would be an infinite loop, since it reads the emulated interrupt flag, then the cycles remaining runs out, then it triggers the interrupt event, so the game code polling the interrupt flag never sees anything happen.

If you don't want to simulate the CPU cycle by cycle and find when in time the reads and writes are within each instruction, there's something else you can do.

Have a 'Pre-Event' happen before the real event happens.

For example, you have a 'Interrupt is going to happen in 4 CPU cycles' event happen before the Interrupt event in your emulator code. The "Interrupt is going to happen soon" event will change the emulator's Interrupt Flag value, so the instruction that polls it will finally get a different value.
This also lets you create correct "Point of no return" situations, where you have a write to a "Disable Interrupts" register executing, but there are 3 CPU cycles left. The Naive approach would run the code that disables interrupts run, then see that there are -1 cycles remaining, so trigger the interrupt. But we just disabled interrupts, so that won't happen. That's not correct.
You hit the 'point of no return' 4 CPU cycles before the interrupt happens, so the code to disable interrupts will still run, but the interrupt will still happen as well.