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