Page 1 of 1
RAMBO-1 IRQ timing
Posted: Sat Aug 31, 2013 10:25 am
by James
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:
Code: Select all
Short Long
ns (cycles)
761 (4.1) 947 (5.1)
621 (3.3) 812 (4.3)
900 (4.8) 1088 (5.8)
582 (3.1) 950 (5.1)
Alignment 1:
Alignment 2:
Alignment 3:
Alignment 4:
Edit: Revised CPU cycle-based IRQ info below.
Re: RAMBO-1 IRQ timing
Posted: Sun Sep 01, 2013 10:49 am
by infiniteneslives
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.
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 3:49 pm
by James
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):
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 4:17 pm
by infiniteneslives
James wrote: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?
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 5:00 pm
by James
That's correct. Similar to RAMBO-1's scanline counter mode.
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 7:31 pm
by ulfalizer
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.
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 7:46 pm
by 3gengames
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.
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 7:50 pm
by ulfalizer
3gengames wrote: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..."
Re: RAMBO-1 IRQ timing
Posted: Mon Sep 02, 2013 11:53 pm
by infiniteneslives
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.