Patrick FR wrote:
It deos both writing in PPU_ADDRESS and WritePPUReg1. It enters in the routine at the UpdateScreen label.
Code:
lda Mirror_PPU_CTRL_REG1 ;load mirror of $2000,
ora #%00000100 ;set ppu to increment by 32 by default
bcs SetupWrites ;if d7 of third byte was clear, ppu will
and #%11111011 ;only increment by 1
SetupWrites: jsr WritePPUReg1 ;write to register <----------------- It writes $11 or $15 here
; [snipped several lines]
lda #$3f ;sets vram address to $3f00
sta PPU_ADDRESS
lda #$00
sta PPU_ADDRESS
sta PPU_ADDRESS ;then reinitializes it for some reason
sta PPU_ADDRESS
We have the "reinitializes it for some reason" which looks dubious.
The going theory is that a programmer saw that leaving rendering off with the VRAM address pointed at $3F01-$3F1F caused that color to be sent to the composite output block instead of the color at $3F00. The programmer internalized a (wrong but close enough) model of the hardware in which the CGRAM had a separate address pointer, and writing $3F00 then $0000 initialized both the CGRAM address and the VRAM address, just as it (actually) has separate OAM and VRAM pointers.
In 1999, loopy discovered
the skinny on why the last two writes on $2006 keep the status bar from flickering. Let me summarize:
Bits 1-0 of the value written to $2000 get copied into bits 11-10 of
t, the top-left corner address. This address is used to reset vertical parts of
v, the VRAM address, during the pre-render line's hsync pulse and the horizontal parts of
v at the start of hblank. But a pair of writes to $2006 overwrites both
t and
v. Here, writing $0000 clears both
t and
v to 0, causing the PPU to read from the first nametable.