Old Nintendo "Golf" is using this code in the vertical blank:
Code:
00:C880:A9 20 LDA #$20
00:C882:8D 06 20 STA $2006 = #$00
00:C885:A9 00 LDA #$00
00:C887:8D 06 20 STA $2006 = #$00
00:C88A:8D 05 20 STA $2005 = #$00
00:C88D:A9 FF LDA #$FF
00:C88F:8D 05 20 STA $2005 = #$00
00:C892:A5 01 LDA $0001 = #$1A
00:C894:8D 01 20 STA $2001 = #$1A
Seems like it's setting vertical scrolling to $FF without no reason (as far as I can see).? Or what's the purpose?
Probably to compensate for the 1-scanline delay the sprites have. If the background is pushed one scanline down, sprite and background coordinates align perfectly. A few old games are known to do this.
Is it actually a problem? Should be valid to do, at least on any system you can't see the first line of garbage it produces (attributes as tiles). I kinda wonder if you could see it on PAL systems.
There's a little note about this kind of thing on the Wiki's PPU scrolling page:
http://wiki.nesdev.com/w/index.php/PPU_scrolling#Y_increment
rainwarrior wrote:
Is it actually a problem?
I don't know... Maybe the fact that this causes attribute data to be treated as name table data makes things worse? I mean, you could achieve the same result by using a vertical scroll of 239 and the contents of the first scanline would maybe look less glitchy.
Negative scrolling is used by several games. Yes, it draws the attribute table as if it was tiles. Slalom, Teenage Mutant Ninja Turtles, and Super Mario 3 also use negative scrolling.
I can understand this being used in games that don't scroll vertically, but it seems completely unnecessary in something like SMB3. With a proper camera system, to find the screen coordinates of an object you have to subtract the camera's coordinates from the object's coordinates, and you can use this opportunity to clear the carry before subtracting the Y coordinate (instead of setting the carry, the normal for subtractions), to subtract one extra unit, effectively compensating for the 1-scanline delay.