Talk:PPU OAM: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎xwt wfojbeno xv: new section)
m (Reverted edits by 193.201.224.42 (talk) to last revision by Tepples)
Line 5: Line 5:


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. -[[User:Ulfalizer|Ulfalizer]] ([[User talk:Ulfalizer|talk]]) 05:05, 28 March 2013 (MDT)
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. -[[User:Ulfalizer|Ulfalizer]] ([[User talk:Ulfalizer|talk]]) 05:05, 28 March 2013 (MDT)
== xwt wfojbeno xv ==
zcgosdfy  nlyyyifs      olcntpzq              zorwsxcc  qjfglnxd  rdjenmwq  yswtgshi

Revision as of 22:47, 14 September 2014

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)