Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.
I have some confusing questions related to the PPU
1- As far as I understood , the output which is 4 bits and equivalent to a pixel , the 4 bits are ( 2 from pattern table and 2 from attribute table ) to be concatenated forming 4 bits which is an index to a color in the palette memory
Is what I understood true ?
2- If I am true , I think there must be another memory fetch taking the above 4 bits which are index to colour to fetch the colour it self
the diagram is showing the BG buffer , My question is why there are 4 registers ? isn't two enough for the 2 pattern tile ?
what are the other two is doing ?
I hope some one answer me quickly
Thank's in advance.
I have some confusing questions related to the PPU
1- As far as I understood , the output which is 4 bits and equivalent to a pixel , the 4 bits are ( 2 from pattern table and 2 from attribute table ) to be concatenated forming 4 bits which is an index to a color in the palette memory
Is what I understood true ?
Close. Knowing the contents of the color palette RAM, 5 bits fully construct a pixel color index. There are four palettes for sprites, as well as four for the backdrop. What you describe is correct for the backdrop output generator, before sprite data is multiplexed in.
Muhammad_R4 wrote:1- As far as I understood , the output which is 4 bits and equivalent to a pixel , the 4 bits are ( 2 from pattern table and 2 from attribute table ) to be concatenated forming 4 bits which is an index to a color in the palette memory
Is what I understood true ?
Yes.
2- If I am true , I think there must be another memory fetch taking the above 4 bits which are index to colour to fetch the colour it self
from the palette memory
Like OAM, palette memory (also called Color Generator Random Access Memory, or CGRAM) is on a separate bus. The eight fetches from CGRAM happen in parallel to the fetches from video memory, one for each pixel.
the diagram is showing the BG buffer , My question is why there are 4 registers ? isn't two enough for the 2 pattern tile ?
what are the other two is doing ?
There are a total of six 8-bit shift registers:
A parallel-in, serial-out (PISO) shift register for pattern data bit plane 0, to extract individual pixel values from the bytes
A PISO shift register for pattern data bit plane 1, to extract individual pixel values from the bytes
A serial-in, parallel-out (SIPO) shift register fed by shift register A, to delay bit 0 of pixel data for fine scrolling
A SIPO shift register fed by shift register B, to delay bit 1 of pixel data for fine scrolling
A SIPO shift register fed by attribute bit 0, to delay bit 2 of pixel data for fine scrolling
A SIPO shift register fed by attribute bit 1, to delay bit 3 of pixel data for fine scrolling
Pattern data fetched from CHR ROM or CHR RAM is fed into shift registers A and B. These in turn feed into C and D, while the attribute data feeds into E and F. Together, shift registers C, D, E, and F act as a delay line, feeding a set of four 8 to 1 multiplexers (or "muxes" for short) that select a pixel from the shift registers based on the fine horizontal (X) scroll value interpreted as a delay amount.
Together, the pattern_bitmap_one line represents what I call registers A and C, and the pattern_bitmap_two line represents what I call registers B and D. This makes palette_data_one equivalent to E and palette_data_two analogous to F. The palette_data_one and palette_data_two registers are 16-bit in the cited diagram, but they really only need to be 9-bit (1 bit of source and 8 bits of shift register), as a single value applies to all eight pixels of an 8x1 pixel background sliver.
Like OAM, palette memory (also called Color Generator Random Access Memory, or CGRAM) is on a separate bus. The eight fetches from CGRAM happen in parallel to the fetches from video memory, one for each pixel.
So can I understand from this that after the 4 bits are fetched they are used again to address CGRAM which is on a separate bus and all this before going to the buffer ?
If so , Why in the documentation they considered the palette ram as a part of the VRAM ? -( memory mapping section in nesdev )
c.A serial-in, parallel-out (SIPO) shift register fed by shift register A, to delay bit 0 of pixel data for fine scrolling
d.A SIPO shift register fed by shift register B, to delay bit 1 of pixel data for fine scrolling
e.A SIPO shift register fed by attribute bit 0, to delay bit 2 of pixel data for fine scrolling
f.A SIPO shift register fed by attribute bit 1, to delay bit 3 of pixel data for fine scrolling
Pattern data fetched from CHR ROM or CHR RAM is fed into shift registers A and B. These in turn feed into C and D, while the attribute data feeds into E and F. Together, shift registers C, D, E, and F act as a delay line, feeding a set of four 8 to 1 multiplexers (or "muxes" for short) that select a pixel from the shift registers based on the fine horizontal (X) scroll value interpreted as a delay amount.
Can I understand why I want a delay
why it is not like the sprite rendering , output going out of the shift registers ?
Muhammad_R4 wrote:Why in the documentation they considered the palette ram as a part of the VRAM ? -( memory mapping section in nesdev )
Though video memory and CGRAM are separate areas of memory, they are both accessed through the PPU data ports. Writes to $3F00-$3FFF go to CGRAM; writes anywhere else (that is, $0000-$3EFF) go to video memory.
Can I understand why I want a delay
The delay is how the PPU performs fine horizontal scrolling. When you set the horizontal scroll position to 0, 1, 2, 3, 4, 5, 6, or 7, you're actually delaying the pixel output by 7, 6, 5, 4, 3, 2, 1, or 0 pixels. More delay = move to the right; less delay = move to the left.
The pattern slivers are always fetched on 8 pixel boundaries. Without the SIPO/mux, you would be able to scroll horizontally only at multiples of 8 pixels.
Please give us more details on your requests for "more details". What parts of the post did you understand, and what parts of the post did you not understand? If you are unable to express what parts of the posts you did and did not understand, I will have to break up the explanation into smaller posts, as if this were a chat room instead of a forum, and ask you whether you understood each part. Here goes:
I understand this and how data in pattern tables and attributes are translated into sprites , this is not what confusing me
I drew this to illustrate what I am thinking in
here , we have 4 of 8 bit SIPO shift registers , loaded with the data during the fetch phases
and the SIPO should provide the appropriate delay
I haven't understood when you said
The pattern slivers are always fetched on 8 pixel boundaries. Without the SIPO/mux, you would be able to scroll horizontally only at multiples of 8 pixels.
Now let's feed it into the SIPOs. Here I show the contents of the shift register while it receives the 16 pixels from above. In reality, there are four shift registers, each containing one bit plane of the pixels. But for the sake of pedagogical clarity, I will show them as a single shifter containing pixels. I will use the symbol x to represent a "don't care" value, meaning a pixel that appears before (to the left of) or after (to the right of) the 16 pixels from above.
I have traced it and I understand how those values come and manipulated through the example
but still I cant connect this with how they are rendered
Did you understand this so far? If not, how did you think fine scrolling (by distances less than 8 pixels) would be accomplished?
answering your question , I think there is a counter ( name it : pxl counter 4 bit and rolls over when = 256 )
this counter toggles the PISO loadad with the data ( say : 13023310)
1st clock 0 comes out
2nd clock 1 comes out
3rd clock 3 comes out
and so on
There must be a problem I can't see in the above idea , So I want to know it + how the SIPO solves the problem
and I really appreciate you are still helping me
[edit : Is this related to the fact that the tile is fetched 16 clk cycles before being rendered on the screen ? ]
Pixels are loaded into the PISO only once every eight pixels. And all pixels loaded into the PISO at one time must come from one pair of bytes. The PPU cannot fetch, say, pixels 1-8 into the PISO because they cross two pair of bytes: the pair of bytes containing pixels 0-7 and the pair of bytes containing pixels 8-15.
If you set the horizontal scroll position to 0, 1, 2, 3, 4, 5, 6, or 7, the PPU will begin by making the following background pattern fetches:
At x=321-328, fetch the pixels at horizontal positions 0-7 of the background
At x=329-336, fetch the pixels at horizontal positions 8-15 of the background
At x=1-8, fetch the pixels at horizontal positions 16-23 of the background
At x=9-16, fetch the pixels at horizontal positions 24-31 of the background
At x=17-24, fetch the pixels at horizontal positions 32-39 of the background
At x=25-32, fetch the pixels at horizontal positions 40-47 of the background
[More fetches for later pixels on the same line omitted]
If you set the horizontal scroll position to 8, 9, 10, 11, 12, 13, 14, or 15, the PPU will begin by making the following background pattern fetches:
At x=321-328, fetch the pixels at horizontal positions 8-15 of the background
At x=329-336, fetch the pixels at horizontal positions 16-23 of the background
At x=1-8, fetch the pixels at horizontal positions 24-31 of the background
At x=9-16, fetch the pixels at horizontal positions 32-39 of the background
At x=17-24, fetch the pixels at horizontal positions 40-47 of the background
At x=25-32, fetch the pixels at horizontal positions 48-55 of the background
[More fetches for later pixels on the same line omitted]
If you set the horizontal scroll position to 16, 17, 18, 19, 20, 21, 22, or 23, the PPU will begin by making the following background pattern fetches:
At x=321-328, fetch the pixels at horizontal positions 16-23 of the background
At x=329-336, fetch the pixels at horizontal positions 24-31 of the background
At x=1-8, fetch the pixels at horizontal positions 32-39 of the background
At x=9-16, fetch the pixels at horizontal positions 40-47 of the background
At x=17-24, fetch the pixels at horizontal positions 48-55 of the background
At x=25-32, fetch the pixels at horizontal positions 56-63 of the background
[More fetches for later pixels on the same line omitted]
Do you understand the above? If you do, I will try to continue to bridge this explanation to the SIPO.
