I'm rewriting my background rendering, but the wiki description is quite confusing. It brings nothing regarding the vram address, or about the pixel output (that diagram isn't clear).
Could someone help me? Like...
- Fetching the first two tiles from dot 320, when is the first pixel rendered? Using which scroll settings: on fetching OR when it outputs, at dot zero?
All fetching is done from the "current" vram address. The tiles fetched on dot 320 are fetched after the X scroll reset, so they will be fetching the left-most tiles of the next scanline.
actual pixels are rendered on dots 0-255. The vram address does not matter at all for outputting pixels. All that matters is the fine X scroll and the previously fetched tile data.
The tile fetched on dots 320-327 will be rendered on dots 0-7 of the next scanline (assuming fine X scroll = 0)
0: set render address to fetch a tile from background
1: fetch tile byte
2: set render address to fetch an attribute byte
3: fetch byte from attribute table
4: set render address to fetch pattern table byte
5: fetch the byte
6: set render address to fetch pattern table byte #2
7: fetch the byte
"vram address" (scrolling) is used in step 0, and step 2.
Render address (what the MMC3 sees) is set by all steps 0, 2, 4, and 6.
Cycles 336-340 are dummy cycles where "nothing happens". On cycle 336 and 338, render address is set the same way as step 0.
Nintendulator's source code helps here, easy to see what happens when.
Mind you to explain 2, the attribute byte fetching?
I assume it's the attribute byte that corresponds to the first tile of the next scanline. This is the same byte you'd fetch in cycles 322-323.
"VRAM Address" (the scroll value) is made up of these bits:
yyyNNYYYYYXXXXX (yyy = fine Y, NN = nametable selection, YYYYY = tile Y, XXXXX = tile X) (edited typo, thanks cpow)
At step 0, when it fetches the tile, it uses these bits:
010NNYYYYYXXXXX
According to Nintendulator's code, at the end of step 1, after it fetches the tile byte, it computes the address of the graphics for that tile. It multiplies the tile number by 16, adds Fine Y, and adds the background pattern table selection from register 2000. These are "locked in" at this point. Changing any of these (fine Y, pattern table selection bit) has no effect until the next time it reaches step 1.
If a write to 2000 would finish during at step 1, I think it would be too late to affect what tile graphics address gets used, but I'm not completely sure.
When it fetches the two bytes for the graphics of the tile, it just adds 8 to get the address of the second byte.
At step 2, when it fetches an attribute, it fetches from the last 64 bytes of the nametable, so it looks like this:
010NN1111YYYXXX (highest 3 bits of tile Y and tile X)
Dwedit wrote:
vvvNNYYYYYXXXXX (yyy = fine Y, NN = nametable selection, YYYYY = tile Y, XXXXX = tile X)
You mean yyyNNYYYYYXXXXX, right?