Correct me if I'm mistaken, but a write to $03f0 should change the 'transparent' color (background color), correct? I mean, I thought this was incredibly intuitive and obvious and just assumed it would work, but...in writing to $03f0, there is no change. I tried changing the number in the palette ram, and figured maybe it was being changed somewhere else in code...but all the other values, when changed, change as expected...
I'm just making sure there's not something I'm missing conceptually, and this should work..for instance, if I write #$01 to $03f0, the background should be blue, correct?
I thought this was a fairly basic thing...so making sure that something in my code is the culprit and not my understanding.
Thanks!
A write to $3f00 of the PPU (or $3f10, a mirror of $3f00) will change the BG color.
Code:
lda #$3f
Sta $2006 ;PPU address, high byte
Lda #$00
Sta $2006 ;PPU address, low byte
Lda #$11 ;medium shade of blue
Sta $2007
Yep, the PPU and CPU each have their own
address spaces and the PPU address space is accessed via
PPU registers.
Right - ok there is a gremlin somewhere then...I shall find it! Thanks for letting me know I wasn't crazy
$03f0 is byte 1 of graphics data of tile 63. $3f00 would be BG color just as others have said.
And just to be clear: the NES has two addressing spaces, CPU and PPU, each with its own memory. There's $03f0 in CPU memory, and $03f0 in PPU memory, and they are completely unrelated. To write something in CPU memory you do:
Code:
lda #$01
sta $03f0
And to write to PPU memory you do:
Code:
lda #$03
sta $2006
lda #$f0
sta $2006
lda #$01
sta $2007
This will change the first byte of the 64th tile in the pattern tables, like 43110 pointed out. The palette is actually at PPU $3f00-$3f1f.
Right that was just a mistype into here. Im loading palette variable from a series of Ram
variables during the NMI. It's working fine. I routinely have the palette changing, but to this point, bck has always been $0f. For a new palette I was attempting to change the bck color, but changes to the RAM variable that should be written to that place doesn't change it from black. Makes no sense, so I just wanted to make absolute sure it was a thing before dissecting why it could be. The entire rest of the palette changes exactly as expected.
Time for debugging.
**Solution**
My NMI was running a routine for loading background palettes from RAM variables, then immediately following, sprite palette from RAM variables.
I was writing bck from #3f00-$3f0F, then writing sprite from $3f10-$3f1f...meaning my background color was being 're-written' when writing the first color of the sprite palette (which was black). All I had to do was skip the write to that value in the NMI and everything worked as expected.
Ah, glad you found the problem. The mirroring that goes on with the palette can indeed be a bit confusing... The PPU has 28 bytes of palette RAM, but only 25 colors can actually be seen during rendering. Even though each of the 4 background palettes is 4 bytes, the PPU always displays color 0 as color 0 of the first palette, for whatever reason. From what I hear, the GBC does show each palette's color 0, and it would've been nice if the NES did too. On the NES, the only way to show the colors at $3f04, $3f08 and $3f0c is to disable rendering and make the VRAM address register point to those locations.
Sprite palettes, however, don't have a color 0 at all, and any attempt to write to those 4 memory locations ($3f10, $3f14, $3f18, $3f1c) will overwrite the values in the background palettes.
This is why I prefer to treat colors in my programs as 1 global background color + 8 3-color palettes. That way I avoid wasting memory (ROM and RAM) with non-existent or unrenderable colors.
tokumaru wrote:
This is why I prefer to treat colors in my programs as 1 global background color + 8 3-color palettes. That way I avoid wasting memory (ROM and RAM) with non-existent or unrenderable colors.
Can't you actually use those colors though if you have a scanline counter available to make one of those line-based sky gradient backgrounds? You'd know when to rewrite the VRAM address and when to finally enable rendering, from which point on the 13 BG colors would be used as usual?
za909 wrote:
Can't you actually use those colors though if you have a scanline counter available to make one of those line-based sky gradient backgrounds? You'd know when to rewrite the VRAM address and when to finally enable rendering, from which point on the 13 BG colors would be used as usual?
Yeah, but there's little reason to do that... since rendering has to be disabled anyway, you could very well just overwrite color 0 with new values to create the gradient, finishing with the color that will be used for the rest of the frame. This is clearly a better option for gradients, since you can have way more than 4 colors in your gradient.
The Family BASIC ROB program uses the three unused colour 0 entries in order to flash the screen screen green (for ROB commands) without having to backup the rest of the palette.