Page 1 of 1
Problem with nametable writes
Posted: Mon Aug 21, 2006 7:48 am
by visy
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: Select all
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?
Posted: Mon Aug 21, 2006 8:17 am
by Quietust
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.
Posted: Mon Aug 21, 2006 9:12 am
by visy
Thanks for the tip, works perfectly now, just a tiny bug left:
http://img162.imageshack.us/my.php?imag ... 072ic1.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).
Posted: Mon Aug 21, 2006 9:57 am
by Quietust
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.
Posted: Mon Aug 21, 2006 12:57 pm
by blargg
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)?
Posted: Mon Aug 21, 2006 1:58 pm
by Quietust
blargg wrote: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.
Posted: Mon Aug 21, 2006 6:06 pm
by tepples
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.
