nesdev.org

Old version was a bit misleading. The sprite tile vram fetches still occur on the pre-render line. Added a note about sprite evaluation instead.

Here's a new version that includes the OAM clears. Spot any errors?

Removed the shift reg note as well, since it was a bit ambiguous and confusing.

Edit: Fixed a minor error on the 'Visible scanlines' line around h=279-305.

The output is determined by fine_x I think, which acts as a pointer into the left/top shift reg. That's why you need 16 bits - to make sure you never "run out" of pixels even if fine_x is set to 7. Yeah, it's a tad weird though, since the value of fine_x really determines bit (15 - fine_x...

As opposed to the NES PPU interface that imposes a timing penalty on all accesses? Touche. EDIT: Ulfalizer, I believe the shift registers are left-shift, with carry from bit 15 being used for output. Then every 8 clocks, the bottom 8 bits are loaded in with the most recently fetched data. That's wh...

Here's a new version with some clarifying notes about rendering.

One thing that still isn't clear to me is how the idle ticks at the beginning of the scanlines affect rendering. Will there be a black column on the far left on the display, or does the timing work out differently somehow? There wouldn't be a black column because the rendering pipeline is initializ...

Here's an updated diagram with the skip location fixed and the lines renumbered to reflect how the PPU views things. One thing that still isn't clear to me is how the idle ticks at the beginning of the scanlines affect rendering. Will there be a black column on the far left on the display, or does t...

Makes sense. Instead of the last cycle of pre-render, the first cycle of raster 0 can be skipped. I noticed some possible Visual2C02 bugginess, if you look at the AB for the tile fetches at the end of pre-render (happens on all lines, though): 321: $2000 <- name 1/2 322: $2000 <- name 2/2 .. 329: $...

Here's a log around the end of the prerender line on even frames (no skipped tick): hpos vpos vramaddr_t vramaddr_v io_db io_ab io_rw io_ce rd wr ab ale db vbl_flag spr0_hit spr_overflow 153 105 0000 0002 1e 1 0 1 1 1 2002 1 02 0 0 0 153 105 0000 0002 1e 1 0 1 1 1 2002 1 02 0 0 0 153 105 0000 0002 1...

Did more tracing in visual 2c02 and figured out some more stuff: - The starting frame is an even frame, with the prerender scanline being 341 ticks long. (The simulation starts on the prerender scanline - the last line of the frame.) - The next frame is an odd frame, with the skipped tick being at t...

Did some tracing with beannich in visual2c02, and it looks like the vblank flag goes high on v/h:241/1 (note: h = 1, not 0), and low on v/h:261/1 (exactly 20 scanlines later). Here's a trace around the beginning of v:241 (cycle, hpos, vpos, various stuff, and then vbl_flag at the end): 330088 000 0f...

From Quietust's post it looks like the visible scanlines should be first, so the numbering is still off in that respect in my diagram. I'm guessing that's based on how the PPU counts scanlines internally. As far as I've understood, the proper NTSC vblank is 22 scanlines long and includes the prerend...

Beannaich noted that the two dummy nametable fetches are both proper nametable fetches (since they're the same fetch as at the beginning of the next scanline), so the last one shouldn't be labeled "AT". Fixed.

I'll separate secondary OAM clear and sprite evaluation, but I have a question first:

Is sprite evaluation done at all on the prerender scanline, or just the OAM clear? If it's done, then what prevents it from finding sprites on the first visible scanline?

Should be an idle cycle at the beginning of sprite evaluation (I lump secondary OAM clear in with it ATM). Fixed.