Talk:PPU OAM: Difference between revisions
m (Another observation) |
m (misrecognized that bit...) |
||
| Line 1: | Line 1: | ||
An observation from a [http://uxul.org/~noname/chips/rp2c02-0-9g5-14/stitched/ PPU die image] - the 2 large blocks at the upper-right (the horizontal strip between them | An observation from a [http://uxul.org/~noname/chips/rp2c02-0-9g5-14/stitched/ 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 [[PPU sprite evaluation|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. --[[User:Quietust|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)... --[[User:Quietust|Quietust]] 18:29, 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)... --[[User:Quietust|Quietust]] 18:29, 11 January 2011 (UTC) | ||
Revision as of 18:34, 11 January 2011
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)
