This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

How does the PPU exactly draw the graphics?

How does the PPU exactly draw the graphics?
by on (#129739)
The PPU: a neat little chip that displays all those colorful graphics on the screen. I have a few questions regarding it.
First of all, does the PPU have it's own crystal oscillator? I suppose it does to process all the data, but what is it's clock rate? Is it 1.79Mhz like the CPU?
Another question I have is about the pixels themselves. Is every pixel addressable in the PPU? Are there special addresses, containing the color data for every pixel? I've been working on a project regarding 8-bit computers and when I got to the PPU, I couldn't figure out if this was the case. The PPU shares RAM with the CPU. Obviously, the PPU portion contains data for the current nametable and how the tiles are placed on screen. But how does the PPU process the pixels themselves? If there are, say, 192 bytes, dedicated to each tile, it'll be easy to place them in the proper addresses. But sprites are a completely different story. They are not bound to the 8x8 grid, they can go wherever they want. So how does the PPU exactly move them? If there are 3 bytes for every pixel in the PPU RAM, this means the PPU would have to move them all pixel by pixel and that would really slow down the process, especially with only 1.79Mhz. I hope someone can give me a proper answer, because I really can't figure this out. :(
Re: How does the PPU exactly draw the graphics?
by on (#129741)
Quote:
First of all, does the PPU have it's own crystal oscillator? I suppose it does to process all the data, but what is it's clock rate? Is it 1.79Mhz like the CPU?

No and no.
There's only 1 crystal oscillator, and it's frequency is divided to create clocks for the CPU and PPU. The exact ratio are details you could look up easily in the wiki, but basically the PPU is clocked 3 times or 3.2 times faster than the CPU for NTSC and PAL respectively.

Quote:
Another question I have is about the pixels themselves. Is every pixel addressable in the PPU?

No, the NES uses tile maps ("name tables") and character patterns ("pattern tables") to draw it's graphics.

Quote:
The PPU shares RAM with the CPU

No, it does not.
Quote:
But sprites are a completely different story. They are not bound to the 8x8 grid, they can go wherever they want. So how does the PPU exactly move them? [...] his means the PPU would have to move them all pixel by pixel and that would really slow down the process

No, the PPU doesn't "move them" at all. It just displays them where specified. When outputing pixels, there is a counter counting how many pixels are being rendered, and if it's in the sprite's range, then it has to be drawn.

The exact details are in this excellent doccument, it contains all the details you want to know and even more.
Re: How does the PPU exactly draw the graphics?
by on (#129743)
AlienX wrote:
Is every pixel addressable in the PPU?

In most cases, no. The NES background is organized into tiles. For example, both R's in "MARIO ... WORLD TIME" are the same tile used in different places. Some games (Qix, Hatris, Elite, 3D Block, Faxanadu, Super Bat Puncher, Action 53 menu, RHDE, and several games with Chinese text) organize the tiles into a somewhat bitmap-like arrangement, but this is usually limited to small areas of the screen. A handful of games (Videomation, Oeka Kids) have extra-large CHR RAM to assign a different pattern for each tile.

Quote:
Are there special addresses, containing the color data for every pixel?

There's one set of PPU addresses containing the color data for each tile (the pattern table, $0000-$1FFF) and a second set of special addresses containing how the tiles are arranged on the screen (the nametable, $2000-$2FFF).

Quote:
I've been working on a project regarding 8-bit computers

NES video is very much like ColecoVision or MSX video.

Quote:
The PPU shares RAM with the CPU.

True of ZX Spectrum, C64, and Apple II. Not true of MSX or NES, which have a separate block of memory dedicated to the PPU's use. This difference in architecture tripped up developers of quick-and-dirty ports from the Spectrum to the MSX.

Quote:
If there are, say, 192 bytes, dedicated to each tile, it'll be easy to place them in the proper addresses.

There are 16 bytes for each 8x8 pixel tile, 2 bits per pixel. There are also 1 byte in the nametable to tell which tile to use for each 8x8 pixel area of the screen, and 2 bits in the nametable to tell which color set to assign to each 16x16 pixel (2x2 tile) area. Finally, there is a separate area of memory inside the PPU called the "palette" ($3F00-$3F1F) that maps combinations of pixels and color sets to actual color signals in the NTSC picture.

Quote:
But sprites are a completely different story. They are not bound to the 8x8 grid, they can go wherever they want. So how does the PPU exactly move them?

On each scanline, the PPU subtracts the current scanline number from all 64 sprites' Y coordinates. Then it keeps up to 8 sprites where the result is less than the height of one sprite. Finally, it loads the patterns for the kept sprites and uses the X coordinate to count down how many pixels to draw before drawing the sprite.

See PPU on NESdev Wiki for more info.
Re: How does the PPU exactly draw the graphics?
by on (#129773)
No frame buffer. Just 2 tile buffers with tile patterns being swapped in and out on the fly, and 8 sprite buffers being fetched during h-blank and rendered over each other with pipelining.
Re: How does the PPU exactly draw the graphics?
by on (#129776)
Rather than it being a framebuffer, it's actually two "layers" of graphics that the PPU draws at the same time. The first layer is the tilemap, and the second layer is the sprite data. There are only 8 hardware sprites, and the sprites are 8x1. During each scanline, the PPU is scanning the sprite table to look for the first 8 sprites that appear on the next scanline (the first 8 in the table, not the first 8 on the scanline itself). Then on the next scanline, it draws those 8 sprites as it's drawing the background, while also simultaneously scanning the sprite table for the next scanline.

When there's both a pixel of background and a pixel of sprite data, the PPU selects which one to draw based on the priority bit of said sprite. The priority bit is just whether the sprite is "behind the background" or not.