OAM reading on PAL NES

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

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

OAM reading on PAL NES

Post by thefox » Sun Feb 23, 2014 11:06 am

Some years ago we tested OAM reading on PAL NES (viewtopic.php?p=62137#p62137) and concluded that it didn't seem to be working reliably. Today I briefly became interested in finding out how OAM decay works. Specifically, does OAM decay to all ones, or all zeroes, or is it random (and how long it takes for it to decay).

I wrote this test ROM:
oam-decay-test.nes
(24.02 KiB) Downloaded 398 times
It uploads a bunch of sprites to OAM and enables rendering. When A is held down, rendering is kept disabled, which presumably should cause OAM to decay. However, on my PAL NES I wasn't able to make OAM decay no matter how long I kept the button pressed, the sprites always came back pristine. The ROM was tested on NTSC NES as well (thanks to Pasky), and there it functioned as expected (sprites started disappearing, which must mean that the bits tended towards ones (EDIT: or zeroes, if TV/capture card wasn't displaying the top 8 pixels).

The only explanation I can think of is that PAL NES must be doing OAM refresh even when rendering is disabled. And in fact, this would make a lot of sense given some earlier results I got from testing OAM DMA (doing OAM DMA more than 20 scanlines into VBlank corrupted the entire transfer: viewtopic.php?p=81695#p81695).

Then I figured that the oam_read test from the previous thread probably also expects to be able to do the OAM reads at any time during forced blanking, which would fail on PAL NES. So I modified the test ROM to wait for VBlank every 16 OAM reads/writes to make sure it never accesses OAM more than 20ish scanlines into the VBlank, and since then the test ROM has passed every time I've tried it.

Modified oam_read test is here:
oam_read_vbl_wait.nes
(40.02 KiB) Downloaded 384 times
In conclusion:
  • OAM decay doesn't seem to occur on PAL NES
  • OAM reading seems to be reliable on PAL NES as long as the reads are done within a correct time window
Further tests would be needed to figure out how long the OAM refresh is and exactly where it occurs.
Last edited by thefox on Tue Feb 03, 2015 11:25 pm, edited 1 time in total.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

zzo38
Posts: 1059
Joined: Mon Feb 07, 2011 12:46 pm

Re: OAM reading on PAL NES

Post by zzo38 » Sun Feb 23, 2014 12:57 pm

That is good thing to know. But, I too would like to know the timing for the OAM decay (I think it isn't always the same, due to temperature and so on), and would help to make emulators to warn about such thing, as well as programs that do unusual things with the rendering timing.
[url=gopher://zzo38computer.org/].[/url]

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

Re: OAM reading on PAL NES

Post by tokumaru » Tue Mar 25, 2014 3:36 pm

thefox wrote:doing OAM DMA more than 20 scanlines into VBlank corrupted the entire transfer
I don't know how I missed this... This is a very important detail about the PAL NES! One of the very first things I do in my NMI handlers is the sprite DMA anyway, but now I have a reason to keep doing it like this.

User avatar
cpow
NESICIDE developer
Posts: 1092
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: OAM reading on PAL NES

Post by cpow » Tue Mar 25, 2014 4:36 pm

thefox wrote: which must mean that the bits tended towards ones
Really? Was it tested on a CRT where the sprites could have disappeared into the bezel at the top of the screen?

User avatar
rainwarrior
Posts: 7716
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: OAM reading on PAL NES

Post by rainwarrior » Tue Mar 25, 2014 5:25 pm

On my own tests with an NTSC NES, I have seen a tendency for the sprites to shift down and to the right as they decay, so I think there's some credibility to the idea that they might have a tendency to decay to 1s more often than 0s. I'm not sure if they'll also decay to 0s sometimes though, maybe we should do a test specifically for this...

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

Re: OAM reading on PAL NES

Post by thefox » Wed Mar 26, 2014 12:21 am

cpow wrote:
thefox wrote: which must mean that the bits tended towards ones
Really? Was it tested on a CRT where the sprites could have disappeared into the bezel at the top of the screen?
Good point. Can't say for sure, especially since I didn't test it myself (on NTSC), only saw a video footage.

My main motivation for testing this was the fact that I had an OAM DMA in my init code (to initialize all sprites to $FF), and I started wondering whether I can credibly make a claim that the sprites will be invisible when the main routine is called.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Quietust
Posts: 1500
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: OAM reading on PAL NES

Post by Quietust » Wed Mar 26, 2014 10:09 am

The most straightforward way of answering this question would be to get a PAL PPU decapped+delayered, photographed, traced, and simulated (getting the die shots tends to be an exercise in patience, but once I have them I'd probably be able to get to a working simulator within a week or two).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Post Reply