PAL NES, sprite evaluation and $2004 reads/writes

[thefox]

I adapted a new notation below, hopefully it's self explanatory. Basically, 24-, * = "24 -, rest *".

PalRendOff1_v3.nes
- 24-, *
- I'm quite sure I got a 24-, 46*, - pattern when the first few times I tried this, but after the 24-, * first appeared it always appeared, over MANY tries (powerons/resets). (I may have been running a wrong test by accident the first few times, who knows.)

PalRendOff2_v3.nes
- 80-, *
- Not really consistent with results from PalRendOff1_v3.

PalRendOn1_v3.nes
- This worked as expected: 24-, *

PalRendOn2_v3.nes
- *
- Certainly not expected, looks like something goes wrong while it tries to read during VBL.

Good news is that the results were consistent across resets/powerons (discounting the first test, but that could've been my mistake). Unfortunately they don't line up with previous results.

[Sour]

Well, that's... confusing. I'm not really quite sure what to make of those results.

blargg's framework is able to print the values of registers on the screen, so I'll try to come up with a slightly different test that displays the values actually read from OAM - maybe it'll help figure out what's actually going on.

[dougeff]

Sorry for reviving a dead topic.

Question. Reading from 2004 and Micro Machines?

why?

And could it be used as a second "sprite zero" style midscreen hit?

[lidnariq]

See - https://forums.nesdev.com/viewtopic.php ... 01#p142001

If you can guarantee that a specific byte occurs exactly once in OAM, and not as the Y coordinate, and the value is not the $FF "empty" value, then ... I think you might be able to poll reads from $2004 to find out when that sprite is being drawn?

Or maybe not; the rate at which the CPU can poll may well just be simply too slow to catch the exact moment that the right byte shows up in OAM evaluation.

[thefox]

What Micro Machines does: viewtopic.php?p=67668#p67668

It's just a simple +1/+0 CPU cycle adjustment based on what value is returned by PPU. I actually did the exact same thing in a demo I did once (before I knew what Micro Machines did...), although I don't think I ever released it in any form.

[tokumaru]

What about Super Cars? It's definitely trying to time a border at the top of the screen via $2004 reads.

[thefox]

What about Super Cars? It's definitely trying to time a border at the top of the screen via $2004 reads.

As far as I can tell, it's polling $2004 to wait for the start of pre-render line, then uses a timed loop to go the rest of the way. (They could have polled for sprite 0 hit flag to be cleared instead, had they known about that.)

[tokumaru]

Well that's disappointing.

[Fiskbit]

Sorry for the additional bump, but I'm trying to get a better understanding of the PAL timings indicated by these results compared to prior testing referenced in the wiki. On the errata page, the wiki says OAM is inaccessible from scanlines 21 through 70, but these results seem to contradict that, showing that the actual region is 25 through 70. The valid 24 scanline region is larger than the NTSC's 20 scanlines, 2557.5 cycles (= 24 * 106 9/16) vs 2273.3 (= 20 * 113 2/3). I take this to mean that if sprite DMA can finish within vblank on NTSC, it should also be safe on a PAL system. Is this all correct?

I ask because while I'd like sprite DMA done last during vblank to use the guaranteed even cycle for quickly reading input on NTSC, I've seen frequent mention that sprite DMA should be done first on PAL and would prefer to avoid special-casing it if I can.

Edit: Fixed some typos.

[thefox]

Sorry for the additional bump, but I'm trying to get a better understanding of the PAL timings indicated by these results compared to prior testing referenced in the wiki. On the errata page, the wiki says OAM is inaccessible from scanlines 21 through 70, but these results seem to contradict that, showing that the actual region is 25 through 70. The valid 24 scanline region is larger than the NTSC's 20 scanlines, 2557.5 cycles (= 28 * 106 9/16) vs 2273.3 (= 20 * 113 2/3). I take this to mean that if sprite DMA can finish within vblank on NTSC, it should also be safe on a PAL system. Is this all correct?

The wiki information is likely not accurate down to a single scanline in this case. It's just roughly correct, PAL PPU does (has to) do something like this during vblank because of DRAM decay. What you said seems like a fair assumption (in fact, it would make sense from Nintendo's point of view to ensure that NTSC code stays compatible with PAL in this manner). So I'm fairly sure if your OAM DMA fits within vblank on NTSC, it should also work on PAL, regardless of where you do it.

[Quietust]

A bit of a large bump, but some important things happened recently - back in mid-August, I got a hold of decapped+delayered RP2C07A images (from a chip which suffered catastrophic failure), and since then I've been tracing them, putting together a half-working simulator, fixing bugs (and tracing errors), and finally getting Visual 2C07 into a state where things are mostly working (but still not fully polished).

Here is what I found:

During scanlines 265-310, the PAL PPU does not perform sprite evaluation at all - instead, it simply increments the OAM address register every 2 pixels (at x=2, x=4, x=6, x=8, ..., x=334, x=336, x=338, and x=340, but not at x=0).

At the beginning of scanline 311 (the pre-render line), forced refreshing ends and the sprite engine starts behaving the same as on the NTSC PPU. When I turn off rendering during scanline 311 or 0-239, the sprite engine goes completely silent, which means that OAM decay ought to happen if you leave rendering turned off for an entire frame, unless 266 scanlines is just barely short enough to preserve the contents until forced refreshing starts again (which seems unlikely, because supposedly it decays much faster than that on the NTSC PPU).