PAL NES, sprite evaluation and $2004 reads/writes

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

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

Post by thefox » Mon Apr 17, 2017 12:19 am

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

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

Post by Sour » Mon Apr 17, 2017 3:46 pm

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.

User avatar
dougeff
Posts: 2778
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

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

Post by dougeff » Thu Mar 15, 2018 3:11 pm

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?
nesdoug.com -- blog/tutorial on programming for the NES

lidnariq
Posts: 9880
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Thu Mar 15, 2018 3:19 pm

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.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

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

Post by thefox » Thu Mar 15, 2018 3:33 pm

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
tokumaru
Posts: 11909
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru » Thu Mar 15, 2018 5:06 pm

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

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

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

Post by thefox » Fri Mar 16, 2018 12:44 am

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.)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
tokumaru
Posts: 11909
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru » Fri Mar 16, 2018 9:09 pm

Well that's disappointing.

Fiskbit
Posts: 202
Joined: Sat Nov 18, 2017 9:15 pm

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

Post by Fiskbit » Sat Nov 24, 2018 10:20 pm

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.
Last edited by Fiskbit on Sun Nov 25, 2018 2:09 pm, edited 1 time in total.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

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

Post by thefox » Sun Nov 25, 2018 12:00 am

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Post Reply