Hm, I found it:
http://www.rainbow-software.org/uniflash/but I never learned Pascal and don't yet have a copy of Turbo Pascal on hand...
Let's see if I can summarize what things I believe are true with the new data:
* Pins 12, 13, 15, 19 are
known exactly* Pins 17 and 18 are "latched value of D1 and D0 on writes to $8004"
* Pin 16 seems to be "become high on write to $C008; become low on write to $C00C; otherwise retain state"
* Pin 14 (/IRQ) seems to be "become high on write to $C004 or $C00C; become low when ((Cnt&86)==86); otherwise retain state"
So I think we can describe exactly what's going on now?
Mask: $C00C
- Writes to $8000, $8008, $800C, $C000: ignored
- Writes to $8004:
same as last time- Writes to $C004: Acknowledge IRQ
- Writes to $C008: Allow counter to run
- Writes to $C00C: Acknowledge IRQ and hold counter at 0
Counter counts PPU A13
falling edges; after 86 (two scanlines) it automatically zeroes its counter and asserts /IRQ.
This style of IRQ means that the program could explicitly choose an X coordinate (within 8 pixel granularity) where to get IRQs by clocking it a few times in vblank (
ldx #$FF / stx $2006 / stx $2006 / bit $2007) before rendering starts. There should be no X drift due to IRQ latency.
Does this sound right to the other people looking?