A sprite OAM table is a 256-byte RAM buffer holding the current data for NES sprites. It stores four bytes for each of 64 8×8 sprites: X and Y position plus appearance attributes such as color and pattern. Because this table is in CPU memory, game code can change it whenever needed. section 5.7
Changing the RAM buffer does not immediately change the displayed sprites. During the NMI routine, usually once per vBlank, the buffer is copied to the PPU’s sprite data area. This separates preparing sprite state in game code from presenting that state on screen. section 5.7 section 5.13
Set up and transfer the table in small steps:
- Reserve 256 bytes in an OAM memory segment and give the buffer a label such as oam. section 5.7 section 6.4
- Write each sprite’s position and appearance values into the CPU-memory buffer. section 5.7
- At the start of an NMI update, set the sprite RAM address to zero, load the high byte of the buffer address, and store it in the sprite DMA register. section 5.13
- Let DMA copy all 256 bytes to the PPU sprite area; the transfer can run every rendering NMI even when no sprite values changed. section 5.13
A buffer at $0200
With oam located at $0200, the high byte is $02. Loading #>oam places $02 in the 8-bit A register; storing it to SPRITE_DMA triggers transfer of the full 256-byte OAM buffer. The low-byte form, <oam, would instead produce $00. section 5.13
Listing 5.20 Transferring the sprite table to video memory (example.s)
#1
ldx #0
stx PPU_SPRRAM_ADDRESS
lda #>oam
sta SPRITE_DMA
This short NMI sequence resets the PPU sprite-RAM address, then uses the OAM buffer’s high address byte to start DMA. section 5.13
