PPU questions
Moderator: Moderators
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
PPU questions
Hello NES developers
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
from the palette memory
3- In this PDF (page 39) http://web.mit.edu/6.111/www/f2004/proj ... report.pdf
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 ?
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
3- In this PDF (page 39) http://web.mit.edu/6.111/www/f2004/proj ... report.pdf
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.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: PPU questions
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:Hello NES developers
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 ?
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
can you please explain in much detail ? telling me if I am right or not and thank's
Re: PPU questions
Yes.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 ?
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.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
There are a total of six 8-bit shift registers:3- In this PDF (page 39) http://web.mit.edu/6.111/www/f2004/proj ... report.pdf
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 ?
- 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
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.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
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 ?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.
If so , Why in the documentation they considered the palette ram as a part of the VRAM ? -( memory mapping section in nesdev )
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
Can I understand why I want a delayc.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.
why it is not like the sprite rendering , output going out of the shift registers ?
Sorry I didn't get this part
Re: PPU questions
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.Muhammad_R4 wrote:Why in the documentation they considered the palette ram as a part of the VRAM ? -( memory mapping section in nesdev )
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.Can I understand why I want a delay
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
I know this but why it can't go as follows :
I fetch the pattern bit , attributes bit ( both for 8 pixels ) , put them in a shift register then output
why all of the other registers are found ? ( specially SIPO why I would need a parallel output ? )
Sorry I didn't get it again
I fetch the pattern bit , attributes bit ( both for 8 pixels ) , put them in a shift register then output
why all of the other registers are found ? ( specially SIPO why I would need a parallel output ? )
Sorry I didn't get it again
Re: PPU questions
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.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
I am sorry again but I did not get it
Could you explain why but in much details ?
Could you explain why but in much details ?
Re: PPU questions
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:
Consider the following pixel values:
They are encoded into bit planes as follows:
Did you understand this so far?
Consider the following pixel values:
Code: Select all
0100200303300330
Code: Select all
01000001 01100110 = $41 $66 (bit plane 0)
00001001 01100110 = $09 $66 (bit plane 1)
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
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
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.
Re: PPU questions
The SIPOs are used as a delay line to delay the decoded pixel data by 0 to 7 pixels.
Let's say you get the following pixel stream out of the PISOs:
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.
Notice how lines B-H appear to be scrolled to the left compared to line A.
Did you understand this so far? If not, how did you think fine scrolling (by distances less than 8 pixels) would be accomplished?
Let's say you get the following pixel stream out of the PISOs:
Code: Select all
0100200303300330
Code: Select all
.----- Contents of SIPO
|
,++++++. ,- Output from PISO stage
|||||||| |
xxxxxxxx 0 "Preroll" fetches at end of
xxxxxxx0 1 previous line's horizontal
xxxxxx01 0 blanking period. These
xxxxx010 0 pixels are not rendered.
xxxx0100 2
xxx01002 0
xx010020 0
x0100200 3
01002003 0 Active display starts here
10020030 3
00200303 3
02003033 0
20030330 0
00303300 3
03033003 3
30330033 0
03300330 x
3300330x x
300330xx x
00330xxx x
0330xxxx x
330xxxxx x
30xxxxxx x
0xxxxxxx x
^^^^^^^^
ABCDEFGH
A: 0100200303300330
B: 100200303300330x
C: 00200303300330xx
D: 0200303300330xxx
E: 200303300330xxxx
F: 00303300330xxxxx
G: 0303300330xxxxxx
H: 303300330xxxxxxx
Did you understand this so far? If not, how did you think fine scrolling (by distances less than 8 pixels) would be accomplished?
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: PPU questions
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
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 ? ]
but still I cant connect this with how they are rendered
answering your question , I think there is a counter ( name it : pxl counter 4 bit and rolls over when = 256 )Did you understand this so far? If not, how did you think fine scrolling (by distances less than 8 pixels) would be accomplished?
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 ? ]
Re: PPU questions
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.
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.