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:
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:
In conclusion:
Further tests would be needed to figure out how long the OAM refresh is and exactly where it occurs.
I wrote this test ROM:
Attachment:
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:
Attachment:
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.