RAMBO-1 IRQ timing

Here's the results of my analysis of RAMBO-1 IRQ timing.

For MMC3-style IRQs, RAMBO-1 checks A12 on falling edges of M2. When it's time to do so, IRQ is asserted on the next falling edge of M2 (plus about 20ns). Since there are 4 possible CPU/PPU alignments, there are 4 variations of IRQ timing. Furthermore, since odd frames are 1 PPU cycle short, there are two different delays for each variation. Here's the IRQ assertion time, relative to the rising edge of A12, for each alignment:



Alignment 1:



Alignment 2:



Alignment 3:



Alignment 4:



Edit: Revised CPU cycle-based IRQ info below.

Awesome work James! That's an interesting approach they took and now makes complete sense on the wide range of delays seen by the RAMBO-1. Thanks for taking the time to get that chip to spill it's guts.

We need to make sure this gets updated in the wiki and Disch docs.

I took a closer look at CPU cycle-based IRQs today:

The IRQ counter reload is set to 0x74 (116) so, once IRQs are enabled, the next IRQ should occur 464 (116*4) CPU cycles later (or about 259.25us later):


IRQs are enabled by writing to 0xE001 at D. The IRQ counter starts counting down on the next falling edge of M2 (E):


The IRQ counter reaches 0 at F (as predicted, 259.25us after E) then, like MMC3-style IRQs, IRQ is asserted on the next falling edge of M2 (G):

Good stuff,

So just to clarify, when you say 'like MMC3 style IRQs', you mean 'like RAMBO-1's CHR-A12 scanline counter' (which is similar to the MMC3 but different in delay amongst possible other things). Not 'like Nintendo's MMC3'. Correct?

That's correct. Similar to RAMBO-1's scanline counter mode.

Thanks for the investigation.

Another thing I'm curious about is the precise circumstances where MMC1 ignores writes. thefox implied it's not as simple as all writes but the first always being ignored for consecutive writes (can't remember where he said that though). Emulating it like that fixes Bill and Ted's Excellent Adventure but breaks the polynes3 demo.

Isn't it consecutive writes the first one is the only one that takes effect? At least that's what I thought was determined from all tests, ever.

Yeah, that was what I meant - "...all writes but the first always being ignored..."

I verified the MMC1's double write cycle protection was based on what appears to be latching of PRG R/W with M2 as a clock. I verified that by leaving M2 low while writing to the mapper and every write was accepted or blocked based on the status of PRG R/W for the most recent latch.