Page 2 of 2

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Mon Apr 17, 2017 12:19 am
by 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.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Mon Apr 17, 2017 3:46 pm
by 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.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Thu Mar 15, 2018 3:11 pm
by 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?

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Thu Mar 15, 2018 3:19 pm
by 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.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Thu Mar 15, 2018 3:33 pm
by 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.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Thu Mar 15, 2018 5:06 pm
by tokumaru
What about Super Cars? It's definitely trying to time a border at the top of the screen via $2004 reads.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Fri Mar 16, 2018 12:44 am
by thefox
tokumaru wrote: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.)

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Fri Mar 16, 2018 9:09 pm
by tokumaru
Well that's disappointing.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Sat Nov 24, 2018 10:20 pm
by 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.

Re: PAL NES, sprite evaluation and $2004 reads/writes

Posted: Sun Nov 25, 2018 12:00 am
by thefox
Fiskbit wrote: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.