Problem with nametable writes

Problem with nametable writes
by visy on 2006-08-21 (#16401)

I'm doing a 16x16 font routine, which itself works well.

However, I was thinking of offsetting the letters in vertical direction with changing $2006 address:

Code:

lda #$20
sta $2006
lda #$40
sta $2006

... writes to $2007 etc.

This doesn't work as I expected. The text itself doesn't move, but zeroes appear from the bottom of the screen (because my chr #0 is "0").

How do I offset the writes to the nametable properly, or do I have to use scrolling?

by Quietust on 2006-08-21 (#16402)

You aren't initializing your scrolling parameters after writing to VRAM - one write to $2000 and two writes to $2005 must be done before the PPU starts rendering.

by visy on 2006-08-21 (#16405)

Thanks for the tip, works perfectly now, just a tiny bug left:

http://img162.imageshack.us/my.php?image=21082006072ic1.jpg

I'm writing 0 to both attribute table 0 and 1 (just to be paranoid enough). This effect only shows on a real NES. (Nestopia & Nintendulator both show it correctly, only gray colors).

by Quietust on 2006-08-21 (#16408)

Sounds like you might be spilling outside of VBLANK. Nintendulator initializes all RAM to zeros, but the RAM chips inside the NES tend to contain mostly $FF - if your code is running outside of VBLANK, the remaining writes will land in semi-random memory locations (and possibly have no apparent effect) and fail to update the attribute tables.

by blargg on 2006-08-21 (#16416)

Quote:
Nintendulator initializes all RAM to zeros

Considering that Nintendulator is used by many to test code, is there any reason why it doesn't try to initialize RAM to what a NES does (even just an option to do this)?

by Quietust on 2006-08-21 (#16421)

blargg wrote:
Quote:
Nintendulator initializes all RAM to zeros

Considering that Nintendulator is used by many to test code, is there any reason why it doesn't try to initialize RAM to what a NES does (even just an option to do this)?

Mainly because the "initialize to zero" was in there before I knew what the NES RAM was really initialized to, and adding it in now would cause some backwards compatibility issues with savestates (which I try to avoid wherever possible).

I suppose now would be as good a time as any to shift it over to initializing to 0xFF - the few random bits that occasionally turn up as 0 on real RAM chips can be written off as manufacturing variations (which will never be the same twice).

Random initial memory wouldn't work quite as nicely, since it would bloat savestates a bit, and it would also hurt the "record movie" option by forcing movies to always contain a savestate even when recording from hard reset.

by tepples on 2006-08-21 (#16430)

Quietust wrote:
it would also hurt the "record movie" option by forcing movies to always contain a savestate even when recording from hard reset.

Initial save states in movies aren't so big when they're run-length encoded.