Zepper wrote:
1. Quote
from the wiki:
The sprite zero flag is automatically set to 0 at dot 1 of the pre-render line.- So, what's that???
The "pre-render line" comes after the last (20th) scanline of VBLANK. During that scanline, the PPU starts fetching background tiles and evaluating sprites, but it doesn't actually draw anything to the screen - its sole purpose is to fetch the first two background tiles for the next scanline so it can prefill the render pipeline.
Zepper wrote:
2. From Nintendulator:
if Sprite address is not zero at the beginning of the pre-render scanline, then copy the contents of its 8-byte page into the first 8 bytes
- Is this on the wiki??? Could someone explain it?
I can't locate it on the wiki, but it's something like this:
1. Sprite RAM slowly decays over time when it's not being accessed, since it's implemented using DRAM
2. Sprite RAM reads are done during two phases: precharge (where the bit lines are briefly exposed to +5V) and I/O (where the precharged bit lines are then connected to actual bits in memory, which also serves to refresh those particular bits)
3. When the PPU starts rendering, it zeroes out the sprite address during the I/O phase (when the address is incremented normally, it happens during the precharge phase)
4. Sprite RAM is internally divided into 8-byte pages (due to the row/column addressing)
5. During the 20 scanlines of VBLANK, Sprite RAM can decay enough that step #2 can cause data from the "old" sprite RAM page (which is being continually refreshed) to leak into the "new" sprite RAM page (if the sprite address is already zero, then nothing happens)
The same thing can happen when manually writing to $2003, which is why the standard procedure is to only use DMA ($4014) for updating sprites.
More details can be found
here.