OAM reading on PAL NES

[thefox]

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 627 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 606 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.

[zzo38]

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.

[tokumaru]

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.

[cpow]

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?

[rainwarrior]

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...

[thefox]

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.

[Quietust]

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).