Talk:PPU OAM
An observation from a PPU die image - the 2 large blocks at the upper-right (the horizontal strip between them is the address decoder) are the PPU OAM. It is arranged in 8 groups, one hooked up to each CPU data bit (i.e. the ones used for $2000-$2007 - the actual pins are along the upper-right corner of the die). The groups hooked up to D0/D1/D5/D6/D7 are 9 bits wide, while the ones hooked up to D2/D3/D4 are only 7 bits wide. One row in each group appears to be used for secondary OAM, while the other pairs of rows store the actual sprite data - since the flags byte does not contain any actual data in D2-D4, the corresponding rows are absent (and thus contain only 3 pairs of rows instead of 4 pairs); indeed, what appears to be a 4->9 decoder at the top of the die (just to the left of CPU D7) looks to convert the bottom 3 bits of the SPR-RAM address (and possibly the top 9th bit) into enables for offsets 0-7 and secondary OAM (for 8-15), and the enables for offsets 2 and 6 are not connected to D2-D4. --Quietust 18:23, 11 January 2011 (UTC)
- In fact, the 4->9 decoder at the top also explains behavior I've seen elsewhere, where setting $2003 to a nonzero value would use the value of the upper 5 bits (instead of all 0s) to fetch the first two sprites (and cause the first one to trigger sprite #0 hit)... --Quietust 18:29, 11 January 2011 (UTC)
Perhaps this page could be renamed to something like "Sprites" and have some of the priority and evaluation stuff merged into it. A separate page just for the memory area seems a bit arbitrary to me. -Ulfalizer (talk) 05:05, 28 March 2013 (MDT)
One part of it says "It has not been determined whether the PPU actually drives these bits low or whether this is the effect of data bus capacitance from reading the last byte of the instruction (LDA $2004, which assembles to AD 04 20). "
This is not factual information and adds noise to the page. Has it been determined since this was edited in? Bregalad (talk) 08:19, 20 May 2015 (MDT)
