Home Page Forums Other Emulator Message Boards Nestopia Sprite RAM (Object Attribute Memory) Access

Before you go on reading please note that this is a very low level technical question. I am recreating the NES in hardware using pure HDL. I have a question regarding access to the PPU's object attribute memory (OAM) via $2003 and $2004. There is very conflicting information on these registers from various documentation sources. For example:

- 2C02 Tech Reference by Brady Taylor states register $2004 is read/write and either a read or a write will increment the address stored in $2003.

- http://nesdevwiki.org/wiki/NES_PPU states register $2004 is read/write but _only_ writes will increment the address in $2003.

- Still other documentation (e.g. NEStech by Jeremy Chadwick) states that $2004 is write-only and cannot be read from at all!

- I tested some code in NEStopia and it clearly increments the address in $2003 only on writes and _not_ on reads.

- I tested the same code in VirtuaNES and it clearly increments on writes and reads!

- I tested the same code on the FCEUX and JNES emulators and I don't think they even allow you to read from sprite RAM as far as I can tell.

Seeing as how there are so many different implementations in the software emulator world I'm beginning to wonder if there are any games out there that actually care about this. Haha.

But does anyone *KNOW* what a real NES does to $2003 when reading from $2004? Or have a way that they can test it on a real NES for me to find out?? I would like my NES implementation to be as accurate as possible. If I don't get any responses then I will go with the way that NEStopia implements it (i.e. increment $2003 on writes but not on reads).

THANKS IN ADVANCE!!

Personally, I'd suggest taking a look at the USB CopyNES device. If you're going to be doing low level reverse engineering, you may want to remeasure as many assumptions as you can on REAL HARDWARE for perfection; this particular question of yours shows that there are definite issues with existing NES documentation.

Not unexpected, really, considering the nature of the work done. They're still fine-tuning major aspects of what we know for pretty much anything NES or newer. The SNES certainly isn't perfected just yet.

You can find the thing here: http://www.retrousb.com/product_info.php?products_id=36

Way cool!! This should be able to answer tons of my low-level questions. I'm going to buy right after I submit this post!

Thanks soooo much!!

Also, Nestopia is considered to be the de facto accurate emulator. At the risk of offending, screw any other emulator, and screw ancient documentation.

If you don't trust Nestopia (why wouldn't you?), sure, go with a CopyNES system.

Also iirc nintendulator implements the proper sprite seek/retrieval system (complete with sprite overflow flag bug as the real console has).
The sprite overflow flag bug is caused by a mistake in the state machine that controls the sprites (i.e. once 8 enabled sprites with correct y coordinates are hit, rather than disabling the minor (2 low bits) and major (6 high bits) oam address counters, setting the flag for overflow and doing nothing, the oam unit instead enables BOTH COUNTERS AT ONCE (which should never happen normally) and continues doing Y compares, etc on values which are not even y coordinates! Kevtris knows more about this.)

LN

Which is the other point - NST and Nintendulator are the only two software emulators you should even consider if you want to figure out what hardware does.

This question should be asked on the nesdev.parodius.com forums. None of the responses given here even remotely answer the OP's question.

I'm from nesdev. Here per request from koitsu.

how it works:

1) writes to $2004 increment $2003

2) read from $2004 do not increment $2003

3) $4014 simply reads from the given address and copies the data to $2004. It does this 256 times. So any side-effects of $2004 writes apply to $4014 as well.

4) during rendering, $2003 is changed by the PPU in order to fetch OAM (much like how the PPU address [$2006] is changed during rendering to fetch tiles). To my knowledge no emulators accurately simulate this, as exact details are not yet fully known.

5) Since $2003 is changed by the PPU during rendering -- at the end of rendering (provided the PPU was not disabled via $2001), $2003 finds its way back to $00. Some games (Akira comes to mind) rely on this.

6) If you turn off the PPU during rendering, $2003 will be scrambled (due to it being in whatever state the PPU was last using it as).

7) writing to $2004 during rendering "screws up". Exact results are unknown/unreliable, but probably result in OAM corruption and possibly mangling of $2003 resulting in incorrect sprites being rendered on the next scanline.

8) reading from $2004 during rendering exposes internal OAM fetches (this is outlined on the nesdev wiki). Some commercial games rely on this to find HBlank.

9) I'm not sure what happens when writing to $2003 during rendering. I'd wager it either the write has no effect (somewhat unlikely) or it jumbles up sprites for the next scanline (more likely).


I can't guarantee I'll come back to this thread for followups. I agree with koitsu -- if you want to ask questions like this you should really sign up on nesdev (not to detract from this forum's userbase -- I'm just saying that nesdev specializes on this kind of thing).

Oh, I agree. NESdev is definitely where to ask this stuff. (And unsurprisingly that behavior isn't far off the SNES's).

You guys rock! Thanks for all the info!!! I actually have another low-level question but I will be a good boy and ask on NESdev like you all said too.

Thanks again!!

P.S. I'm REALLY sorry for taking so long to reply to the other comments that people provided. I can't figure out how to set my preferences so that it sends me an e-mail when someone replies. LOL. Anyone know? :P