nesdev.org

ok, maybe this is a stupid question, but i'm a bit confused about the DMA and the OAM, so i'm asking this just to be sure.

the values written to $2004 are written into the SPR-RAM, wich is a 256 bytes memory space internal to PPU. ok, thats easy, but this where i get confused:

extracted from qeed's doc (also the same lines are written in the wiki):

* On even cycles, data is read from (primary) OAM
* On odd cycles, data is written to secondary OAM

is that "primary OAM" the SPR-RAM? and if it is, what's that "secondary OAM" that the doc refers to? is it a fast register inside the PPU? in that case, if both primary and secondary OAM are internal to the PPU, why the PPU needs two DMA registers? i mean, if both registers have the same purpose, why are there two of them and not just one?

thanks in advance for any reply

Secondary OAM is where the sprites go when it gathers the first 8 sprites which are in range of the current scanline. So then it can draw them on the next scanline.

Yes, secondary OAM is a set of fast temporary registers that are filled each scanline during rendering. You can't access them directly.

Dwedit wrote:Secondary OAM is where the sprites go when it gathers the first 8 sprites which are in range of the current scanline. So then it can draw them on the next scanline.

thanks Dwedit, that explains it all

also, i'll make another question just to be sure i'm understanding the whole thing.
since the SPR-RAM (aka "primary OAM") is 256 bytes long and the OAM (aka "secondary OAM") is 32 bytes long, then it's obvious that only the data from the 8 sprites of each scanline are copied into the OAM. by this, i assume that between scanlines i should be keeping trace of where is the last byte read from the SPR-RAM, in order to not be rendering always the same 8 sprites. i'm saying this because otherwise it would be stupid to have 256 bytes of SPR-RAM if only the first 32 of them are effective. am i correct?

blargg wrote:Yes, secondary OAM is a set of fast temporary registers that are filled each scanline during rendering. You can't access them directly.

ok, thanks Blargg, so i guess i didn't missunderstood the doc. probably the two-DMAs-thing is just a hardware issue, one for writing (for programmer's purpose) and the other for reading (for PPU's purpose).[/quote]

ehguacho wrote:by this, i assume that between scanlines i should be keeping trace of where is the last byte read from the SPR-RAM, in order to not be rendering always the same 8 sprites.

Between scanlines you have to check which sprites are in range (i.e. have parts that should appear in the next scanline) and only those that do are copied to secondary OAM. It's not gonna be always the same 8 because the sprites are only 8 or 16 lines tall, so different sprites will be in range as the screen renders.