MMC3 A12 change to IRQ assertion delay?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#115979)
Has anyone ever investigated if there's any (meaningful) delay from the point where A12 rises and decrements the scanline counter to zero to where the IRQ is asserted?
Re: MMC3 A12 change to IRQ assertion delay?
by Dwedit on 2013-08-02 (#115982)
If it isn't enough to jitter it by at least 1 CPU cycle, it's not significant.
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#115983)
Dwedit wrote:
If it isn't enough to jitter it by at least 1 CPU cycle, it's not significant.


It could be significant even if it's shorter than that, if the delay pushes it across the CPU's polling point for the interrupt lines (or makes the assertion period before the polling point too short for the CPU to see the interrupt at that point).
Re: MMC3 A12 change to IRQ assertion delay?
by tepples on 2013-08-02 (#115985)
In that case, it'd be one of the many "alignment-dependent" phenomena.
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#115992)
tepples wrote:
In that case, it'd be one of the many "alignment-dependent" phenomena.


Yeah, alignment would probably influence it. It might not be as obscure as you'd think though, as a delay of a single PPU tick could mean the interrupt is acted on after the next instruction instead of the current one, which is significant for eliminating the shakes in some games.

By the way, does anyone have Incredible Crash Test Dummies and a real MMC3 (i.e., not PowerPak)? Would be interesting to know if a flickering glitch shows up on the right-hand-side of the screen on the title screen. (The timing on it is pretty tight, and PowerPak produces the flickering glitch while Everdrive shakes instead.)
Re: MMC3 A12 change to IRQ assertion delay?
by lidnariq on 2013-08-02 (#115993)
I recorded these scope traces from SMB3 (with an MMC3B inside). Upper trace is PPU A12. Bottom trace is /IRQ. Both were tapped on the mainboard, so I haven't accounted for propagation time from the PPU to the MMC3 (however tiny that may be).

We don't know the process technology used to make the MMC3B (do we?), so I don't know whether assuming CMOS or TTL thresholds is appropriate. However, the 'scope traces show approximately 69ns (I measured with the horizontal timebase set to 10ns) from the first time PPU A12 rises to 2.4V until /IRQ falls to 1.0V. That's approximately 1/3 of a pixel, or 3/2 oscillations of the 21.5MHz xtal. So that should be enough.

Not shown: SMB3 acknowledges the IRQ just over one scanline later.
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#115995)
lidnariq wrote:
...


Thanks!

That should be mostly negligible I think.
Re: MMC3 A12 change to IRQ assertion delay?
by lidnariq on 2013-08-02 (#115996)
Shouldn't it mean that for one of the four alignments the IRQ could be acted on one instruction later?
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#115998)
lidnariq wrote:
Shouldn't it mean that for one of the four alignments the IRQ could be acted on one instruction later?


Hmm, yeah, it actually might. There's also the question of how far into the PPU tick A12 changes.

For reference, here's a simple overview of the different clock alignments I made. The PPU is clocked on low-to-high transitions of the master clock while the CPU is clocked on high-to-low transitions, so that's not an error in the diagram (this would be nice to have confirmed btw - I've only checked it in the simulators).

The extra "M2" blocks for the CPU shows where M2 goes high (it has a 5/8 duty cycle), while the solid line is the 50%/50% phase used internally by the CPU.

Code:
Alignments:

Master clock:
┐  ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐   ┌───┐
│  │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │
└──┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───┘   └───
PPU clock: |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
(pclk0 high|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
while low) |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
───┐   |   |   |   ┌───────────────┐   |   |   |   ┌───────────────┐   |   |   |   ┌───────────────┐   |   |   |   ┌───────────────┐   |   |   |   ┌───────────────┐   |
   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |   |   |   │   |
   └───────────────┘   |   |   |   └───────────────┘   |   |   |   └───────────────┘   |   |   |   └───────────────┘   |   |   |   └───────────────┘   |   |   |   └───────
   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |     
CPU clock (alignment 1)|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |       
───────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────────────────────────────────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────────────
   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   |   |   |   |   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   |   |   
   |   └───────────────────────────────────────────────┘   |   |   |   |   |   |   |   |   |   |   |   └───────────────────────────────────────────────┘   |   |   |   |   
CPU clock (alignment 2)|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |       
───────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────────────────────────────────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────
   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   |   |   |   |   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   
   |   |   |   └───────────────────────────────────────────────┘   |   |   |   |   |   |   |   |   |   |   |   └───────────────────────────────────────────────┘   |   |   
CPU clock (alignment 3)|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |       
───────────────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────────────────────────────────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───
   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   |   |   |   |   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   
   |   |   |   |   |   └───────────────────────────────────────────────┘   |   |   |   |   |   |   |   |   |   |   |   └───────────────────────────────────────────────┘   
CPU clock (alignment 4)|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   
───────────────────────────────┐   |   |   |   |   |   |   |   |   ┌-----------┌───────────────────────────────────────────────┐   |   |   |   |   |   |   |   |   ┌-------
   |   |   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2     │   |   |   |   |   |   |   |   |   |   |   |   │   |   |   |   |   |   |   |   |   |    M2
   |   |   |   |   |   |   |   └───────────────────────────────────────────────┘   |   |   |   |   |   |   |   |   |   |   |   └───────────────────────────────────────────
Re: MMC3 A12 change to IRQ assertion delay?
by lidnariq on 2013-08-02 (#116001)
ulfalizer wrote:
There's also the question of how far into the PPU tick A12 changes.
ALE, /RD, and A12 all seem to start rising about the same time, but due to the load of the MMC3, ALE beats A12 to 2.0V by about 42ns, or about one master clock cycle. (/RD beats A12 by about 26ns)
A12 seems to take a significant portion of a 21.5MHz cycle to rise. (About 30ns) Both of these transitions seem to be more or less centered on the low half period of the 21.5MHz master clock.
A13, on the other hand, isn't appreciably loaded, and transitions at about the same time and same speed as /RD. ALE is a little slower than A13 (13ns).

Quote:
The PPU is clocked on low-to-high transitions of the master clock while the CPU is clocked on high-to-low transitions, so that's not an error in the diagram (this would be nice to have confirmed btw - I've only checked it in the simulators).
I've only got a 1GS/s 60MHz scope, and the master clock is already somewhat non-square, so it's a little hard to tell exactly where this changes. But, just poking a few things on the oscilloscope:
* I do see a rising edge on the 21.5MHz clock at the same time I see /RD fall.
* The 21.5MHz signal arrives at the CPU a smidge earlier than the PPU, by about 4ns. (I'm not certain how much I trust that)
* I do see a falling edge on the 21.5MHz clock at the same time I see M2 fall or rise.
* I do see a transition on M2 in the opposite direction as on the 21.5MHz clock. M2 is high for ~359ns, low for ~199ns.
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-02 (#116002)
lidnariq wrote:
* I do see a falling edge on the 21.5MHz clock at the same time I see M2 fall or rise.


That's odd. I would only have expected a falling edge on the 21.5MHz clock when M2 falls (and not when it rises), given the duty cycle.
Re: MMC3 A12 change to IRQ assertion delay?
by infiniteneslives on 2013-08-02 (#116003)
The extra loading on A12 is due to the 220pF capacitor mostly. Most flash carts neglect this capacitor. If I were to make an educated guess about the delay between A12 rising and /IRQ going low it's entirely attributable to analog effects. Vih on the heavily loaded A12 line, the M2 filtering logic, counter logic, and /IRQ output delay. If that's true then PVT will affect the exact delay so it's not something exact.

Additionally, there are several delays in the IRQ sensing of the CPU, so that increases the chances of the CPU sensing the scanline one PPU tick late.

I've got an original MMC3 I've used as a devboard. Although I seem to recall it wasn't working last time I played around with it. That could have been due to something I connected wrong though. I'll see if I can get crash dummies running on it to see how it looks.
Re: MMC3 A12 change to IRQ assertion delay?
by lidnariq on 2013-08-02 (#116004)
ulfalizer wrote:
That's odd. I would only have expected a falling edge on the 21.5MHz clock when M2 falls (and not when it rises), given the duty cycle.
Sloppy of me. Re-measured and fixed.
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-03 (#116008)
lidnariq wrote:
* I do see a transition on M2 in the opposite direction as on the 21.5MHz clock. M2 is high for ~359ns, low for ~199ns.


That's also a bit weird. It's not in the same direction?
Re: MMC3 A12 change to IRQ assertion delay?
by lidnariq on 2013-08-04 (#116018)
Top trace is M2 (or at least CPU pin 31). Bottom trace is the 21.5MHz clock (or at least CPU pin 29).
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-04 (#116020)
Ok, not sure what to make of that. At least ~359ns/~199ns is pretty close to 349ns/210ns, the predicted duty cycle...
Re: MMC3 A12 change to IRQ assertion delay?
by ulfalizer on 2013-08-04 (#116021)
Did anyone get around to trying a real Crash Test Dummies btw?

The tricky part is that it turns off rendering right around the end of the scanline, near the vertical increment of v. It seems to assume that the increment will happen (i.e., that rendering is disabled after the increment point), because otherwise the topmost line of the scrolling text gets messed up.

On PowerPak you both get glitching, indicating rendering is turned off before the v increment, and unglitched scrolling text, which is weird. Hence why I'm curious.