A few more PPU questions

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
A few more PPU questions
by on (#53468)
Sorry for multiple forum posts but I really don't know where else to ask these kinds of questions. This question is in reference to the below text:
Code:
At the start of a new tile fetch phase (every 8 cc's), both latched pattern
table bitmaps are loaded into the upper 8-bits of 2- 16-bit shift registers
(which both shift right every clock cycle). The palette select data is also
transfered into another latch during this time (which feeds the serial
inputs of 2 8-bit right shift registers shifted every clock). The pixel data
is fed into these extra shift registers in order to implement fine
horizontal scrolling, since the periods when the PPU fetch tile data is
fixed.


I completely understand the table bitmap section. What I'm confused about is the palette select data, and how that is handled. Each tile fetch phase has 4 parts:

    Name table byte fetch
    Attribute table byte fetch
    Pattern table bitmap #0 fetch
    Pattern table bitmap #1 fetch


That of course is the full 8cc cycle for each tile. When is the PPU supposed to be doing this palette select thing? I know I've read in a doc that says the PPU never makes a fetch for palette data on the address bus, which would obviously mean that the fetch is internal during rendering. Does it simply do this while doing the other 4 fetches?


My other question is really two combined..
The first fetched tile is really the 3rd tile in the scanline. I also noticed that since the pattern data is being put at the end of 16-bit shift registers, they will only be usable for 8 cycles (the time it takes to fetch another tile). Does this mean that while the PPU is reading in these values, it is also acting on the bit0 values of the four latches and actively rendering to something? If it rendered like this, I would expect it to start rendering tile 2 on the scanline first, not tile three.

Hopefully someone can help me clear these questions up. Thanks again!
Re: A few more PPU questions
by on (#53480)
essial wrote:
I know I've read in a doc that says the PPU never makes a fetch for palette data on the address bus, which would obviously mean that the fetch is internal during rendering. Does it simply do this while doing the other 4 fetches?


I don't think this detail was ever discovered.

Given that any pixel can output one of ~32 colors, it makes sense to me that the pallets are fetched as each individual pixel is being output. Pre-fetching the BG pallet wouldn't make much sense since a sprite pixel might be output and vice versa.

Quote:
Does this mean that while the PPU is reading in these values, it is also acting on the bit0 values of the four latches and actively rendering to something?


Yeah.. at least if I'm understanding your question right. Which 4 latches are you referring to?

Although it doesn't always pull from bit 0 of the pattern table shifters. It can pull from any one of 8 bits, depending on the fine X scroll.

Quote:
If it rendered like this, I would expect it to start rendering tile 2 on the scanline first, not tile three.


The shift reg is sort of like the drawing queue. The tiles in it are the next tiles to be drawn. It slowly empties -- 1 bit per cc. And after every 8 ccs, it gets another 8 bits added to it for the next fetched tile.

Tiles 1 and 2 are in the shift register at the start of the scanline, since they were prefetched at the end of the previous scanline.

Every cc, one of the 8 high bits (determined by fine X scroll -- 0 would be the highest bit, 1 the next highest and so on) is output. The shift reg is then shifted left by 1.

Once this has been done 8 times, the next tile has been fully fetched, and it gets loaded into the low 8 bits of the shift reg, which puts it next in line to be rendered.
Re: A few more PPU questions
by on (#53500)
Disch wrote:
essial wrote:
I know I've read in a doc that says the PPU never makes a fetch for palette data on the address bus, which would obviously mean that the fetch is internal during rendering. Does it simply do this while doing the other 4 fetches?


I don't think this detail was ever discovered.

Given that any pixel can output one of ~32 colors, it makes sense to me that the pallets are fetched as each individual pixel is being output. Pre-fetching the BG pallet wouldn't make much sense since a sprite pixel might be output and vice versa.


Isn't the palette data held in memory kept within the PPU? So this would mean, that during rendering the palette data doesn't need to be adressed via the adress bus.

Afaik the internal palette is consulted once per pixel, either the playfield palette or the object palette, depending on the outcome of the multiplexer. This is described in detail in Brad Taylors PPU document.