So these are internal to the PPU, but have their own address space? Yet I see the palettes listed on the main VRAM memory map ($3F00-$3F1F) and not the OAM. What's the actual underlying physical arrangement? Both the Wiki and other documentation I've perused are unclear.Two separate, smaller address spaces hold a palette, which controls which colors are associated to various indices, and OAM (Object Attribute Memory), which stores the position, orientation, shape, and color of the sprites, or independent moving objects. These are internal to the PPU itself and use dynamic memory (which will slowly decay if the PPU is not rendering data).
Clarification on OAM and palette locations
Moderator: Moderators
Clarification on OAM and palette locations
From the Wiki:
I agree, "internal to the PPU itself" may not be clear.
I think it means that the memory is physically inside the PPU chip, and directly connected to the circuitry that needs it, instead of being an external RAM chip connected to the PPU via the bus.
However, the PPU can still provide access to this internal memory, and it does: $2006/2007 at address $3Fxx to access the palette, and $2003/2004 to access the OAM.
I think the OAM is a separate register to make the sprite DMA a little less complicated (all it does is write to $2004 256 times. It doesn't need to set addresses or anything, as far as I know). However, they could've put the OAM into the address map, or moved the palette out of the address map and into separate registers like the OAM. Having the palette be accessed by its own separate registers would've made mid-screen palette changes a heck of a lot easier!
I think it means that the memory is physically inside the PPU chip, and directly connected to the circuitry that needs it, instead of being an external RAM chip connected to the PPU via the bus.
However, the PPU can still provide access to this internal memory, and it does: $2006/2007 at address $3Fxx to access the palette, and $2003/2004 to access the OAM.
I think the OAM is a separate register to make the sprite DMA a little less complicated (all it does is write to $2004 256 times. It doesn't need to set addresses or anything, as far as I know). However, they could've put the OAM into the address map, or moved the palette out of the address map and into separate registers like the OAM. Having the palette be accessed by its own separate registers would've made mid-screen palette changes a heck of a lot easier!
I can only speak from a software perspective. If you are looking for answers as to how the hardware is physically layed out, I can't help with that. Below answers are conceptual only and may or may not be how the actual hardware is layed out.
Oam is in a separate block of memory and is accessed through it's own bus. This bus is [indirectly] accessed by the CPU via $2003 (A bits) and $2004 (D bits)
Palettes afaik do not have a bus and are totally internal to the PPU (possibly they're just a series of registers).
The PPU sort of "hijacks" address $3Fxx to put palettes there. But it's sort of like a special case, and isn't without side-effects (palettes are read differently when you try to read them via $2007)
The key difference is that for oam/nt/chr reads, the ppu has to perform a read on the appropriate bus. But the palettes are immediately available for direct access so they can be accessed much more quickly.
EDIT: also waddup Drag!
Oam is in a separate block of memory and is accessed through it's own bus. This bus is [indirectly] accessed by the CPU via $2003 (A bits) and $2004 (D bits)
Palettes afaik do not have a bus and are totally internal to the PPU (possibly they're just a series of registers).
The PPU sort of "hijacks" address $3Fxx to put palettes there. But it's sort of like a special case, and isn't without side-effects (palettes are read differently when you try to read them via $2007)
The key difference is that for oam/nt/chr reads, the ppu has to perform a read on the appropriate bus. But the palettes are immediately available for direct access so they can be accessed much more quickly.
EDIT: also waddup Drag!
Thanks! I'm still not sure if that clarified the matter or further confused me.
So is it technically correct to say that OAM is part of the PPU but not part of VRAM, since it has its own bus and memory map, while the palette is both part of the PPU and VRAM?
To be clear, I understand how they operate and are accessed - I'm just curious about their proper 'home.' (And the subsequent wording in the wiki.)
So is it technically correct to say that OAM is part of the PPU but not part of VRAM, since it has its own bus and memory map, while the palette is both part of the PPU and VRAM?
To be clear, I understand how they operate and are accessed - I'm just curious about their proper 'home.' (And the subsequent wording in the wiki.)
By "home" you mean physical location, correct?
Have you ever programmed for the Game Boy, Super NES, or Game Boy Advance? If so, I might be able to explain by analogy to those.
- OAM (Object Attribute Memory, 256 bytes) is internal to the PPU and in a separate address space. It tells which sprites are placed where on the screen.
- CGRAM (Color Generator RAM, 28 bytes) is internal to the PPU and on a separate bus while rendering is turned on, but it's hooked up "in front" of the video memory bus while rendering is turned off and the VRAM address is in $3Fxx.
- CIRAM (Character Internal RAM, 2048 bytes) is outside the PPU but on the NES motherboard and connected to the video memory bus. It stores the nametables, which tell which background tiles are placed where on the screen.
- CHR ROM/CHR RAM (8192 bytes) is on the cartridge and connected to the video memory bus. It stores the actual shapes of the tiles.
Have you ever programmed for the Game Boy, Super NES, or Game Boy Advance? If so, I might be able to explain by analogy to those.
Palette is part of the PPU's memory map, it's addressed just like any other PPU memory. But it is not on a separate chip, it's part of the PPU itself.
OAM is separate from the PPU's memory map. It's 256 bytes (some bits missing) of internal memory for the sprites, and is only accessed through the two registers that manipulate it (and the "sprite DMA" feature the CPU provides).
There's also "secondary OAM" where it stores information for the 8 sprites it found that were in range. It's used by the PPU itself when it does its sprite evaluation logic, and when it draws sprites. It is completely inaccessible to the programmer.
OAM is separate from the PPU's memory map. It's 256 bytes (some bits missing) of internal memory for the sprites, and is only accessed through the two registers that manipulate it (and the "sprite DMA" feature the CPU provides).
There's also "secondary OAM" where it stores information for the 8 sprites it found that were in range. It's used by the PPU itself when it does its sprite evaluation logic, and when it draws sprites. It is completely inaccessible to the programmer.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
I'm comfortable with that first statement.noattack wrote:So is it technically correct to say that OAM is part of the PPU but not part of VRAM, since it has its own bus and memory map, while the palette is both part of the PPU and VRAM?
That second statement, I wouldn't say the palette is part of VRAM, because the palette isn't actually stored in the VRAM itself. It's part of the memory map, yes, but it isn't actually stored in any VRAM that you may connect to the PPU; instead, they are seperate registers in the PPU itself.
Edit: Just for clarification, the reason I don't consider the palette to be part of VRAM is because the palette does not depend on any memory you can connect to the PPU; those bytes at PPU$3F00-$3FFF are always there, and they're completely internal to the PPU; the cartridge cannot manipulate them in any way, aside from having the software itself change them via $2006/$2007.