It is currently Sun Oct 22, 2017 7:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: OAM reading on PAL NES
PostPosted: Sun Feb 23, 2014 11:06 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
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:
Attachment:
oam-decay-test.nes [24.02 KiB]
Downloaded 102 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:
Attachment:
oam_read_vbl_wait.nes [40.02 KiB]
Downloaded 97 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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Last edited by thefox on Tue Feb 03, 2015 11:25 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Feb 23, 2014 12:57 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 930
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.

_________________
.


Top
 Profile  
 
PostPosted: Tue Mar 25, 2014 3:36 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10066
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Tue Mar 25, 2014 4:36 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1026
Location: Minneapolis, MN
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?


Top
 Profile  
 
PostPosted: Tue Mar 25, 2014 5:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
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...


Top
 Profile  
 
PostPosted: Wed Mar 26, 2014 12:21 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Mar 26, 2014 10:09 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group