PPU and tile rendering confusion

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
NewDietCoke248903
Posts: 7
Joined: Sun Apr 26, 2015 8:16 am

PPU and tile rendering confusion

Post by NewDietCoke248903 »

(Note, please correct me if I'm wrong anywhere as I'm trying to reiterate what I read in the wiki)

I'm reading through the line-by-line timing (http://wiki.nesdev.com/w/index.php/PPU_rendering) but I'm a little confused interpreting some of the data on there:

Four memory accesses need to be performed for each tile:
1. Nametable byte
2. Attribute table byte
3. Tile bitmap low
4. Tile bitmap high (+8 bytes from tile bitmap low)
This takes 2 PPU cycles for each, totaling 8 PPU cycles.

So 8 PPU cycles later, we have everything we need to render a tile.

Each tile is 8x8 pixels. When we're rendering a tile, we're also performing the four memory accesses above so that we can render the next tile when we're done with the one working on.

When we are in the pre-render scanline (-1, 261), we are preparing to render some tiles. From the wiki:
This is a dummy scanline, whose sole purpose is to fill the shift registers with the data for the first two tiles of the next scanline.
My question is this:

Since this prerender scanline is several tiles long, do we only perform 16 memory reads (two tiles worth) and then do nothing until the first tile (visible scanline 0) when we can start performing memory accesses for the third tile?

This would imply that we are always doing the four memory accesses for the 2nd tile after the one we're currently drawing, NOT the next one we're about to draw.

For example, if we're drawing tile 0, we are simultaneously doing the memory accesses to draw tile 2, NOT the next tile (NOT tile 1).

Is any of this remotely correct?
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: PPU and tile rendering confusion

Post by Drag »

Yes, all the fetches are for the tile that's 2 tiles ahead of what the PPU is currently sending to the screen.

The prerender scanline still contains all the fetches of a regular scanline though, so 32 bg fetches, 8 sprite fetches, and then the 2 first tiles for the first visible scanline.

As for the fetches themselves, the first 40 are likely unpredictable, because only the horizontal BG rendering position is initialized, vertical isn't initialized until just before the final two fetches, and sprite evaluation seems to be inactive during the prerender scanline, meaning the secondary OAM is also likely to be uninitialized. The final two fetches are valid obviously.
Post Reply