Strange Palette Loading Issue

[hundonostudy]

I've been working through the Nerdy Nights tutorials and I've noticed a strange little bug in palette loading. I've found a work around to achieve what I want, but I would still like to know whats going on if anyone here wouldn't mind lending their thoughts.

I'm using the load palette loop specified by the tutorial to load the palettes into the PPU. Here is the loop. Pretty basic stuff.

Code: Select all

LoadPalettes:
  LDA $2002             ; read PPU status to reset the high/low latch
  LDA #$3F
  STA $2006             ; write the high byte of $3F00 address
  LDA #$00
  STA $2006             ; write the low byte of $3F00 address
  LDX #$00              ; start out at 0
LoadPalettesLoop:
  LDA palette, x        ; load data from address (palette + the value in x)
                          ; 1st time through loop it will load palette+0
                          ; 2nd time through loop it will load palette+1
                          ; 3rd time through loop it will load palette+2
                          ; etc
  STA $2007             ; write to PPU
  INX                   ; X = X + 1
  CPX #$20              ; Compare X to hex $10, decimal 16 - copying 16 bytes = 4 sprites
  BNE LoadPalettesLoop  ; Branch to LoadPalettesLoop if compare was Not Equal to zero
                        ; if compare was equal to 32, keep going down

The loop indexes into "palette", which is this series of DB statements

Code: Select all

palette:
  .db $20,$00,$10,$2d, $20,$01,$21,$31, $20,$06,$16,$26, $20,$09,$19,$29   ;;background palette
  .db $22,$1C,$15,$14, $20,$02,$38,$3C, $20,$1C,$15,$14, $20,$02,$38,$3C   ;;sprite palette

What is interesting, is that when the palette is loaded in, all of the values for background palette and sprite palette load fine except the first byte of background palette, and the first byte of sprite palette.

Instead of loading $20 for the first byte of background palette, fceux loads $22. And instead of loading $22 for the first byte of sprite palette, fceux loads $00. I can see these palettes in the PPU viewer. However, when I check the debugger and monitor the values that the loop is loading step by step, it appears to load the appropriate values. Its just the final product doesn't match what the debugger says is being loaded as palettes.

Any thoughts on this would be appreciated!

Thanks!

Hundo

[thefox]

The keyword is "palette mirroring": http://wiki.nesdev.com/w/index.php/PPU_palettes

[hundonostudy]

Thanks Fox.

That's trippy. What is the point of mirroring those addresses? Is there a functional reason that is useful for programming the NES? Is it an odd design quirk of the NES PPU?

[tokumaru]

Color 0 in sprites is transparent, so there's no reason to waste bits storing them, but the writes still have to go somewhere. I don't know the reason why each background palette has its own color 0 though, since only the first is ever displayed. Maybe they planned on using those colors at some point, like the GBC and the Master System do, but ultimately decided against it.

[Pokun]

The three color 0 entries $3F04, $3F08 and $3F0C (and their mirrors $3F14, $3F18 and $3F1C) are normally unused (I think most games write $0D, I mean $0F, to these and forget about them) but they can be used instead of the backdrop color $3F00 (and its mirror $3F10) using the background palette hack and apparently this is an intentional feature of the PPU. I don't know if it can be useful in any way normally, but it was used for a R.O.B program in Family BASIC by UglyJoe to save space. Instead of backing up the palettes like done in Gyromite, he uses these unused palette entries and the hack to preserve the palettes when flashing the screen green for the ROB commands.

fceux loads $22. And instead of loading $22 for the first byte of sprite palette, fceux loads $00. I can see these palettes in the PPU viewer.

The PPU Viewer in Fceux is strange. It always seems to display the value of color 0 of each sprite palette as $00 although it really has another value (which is the same as the color 0 of each background palette due to mirroring). Only the actual number value is wrong though, the color itself is correct. It's not really a big problem but it's an eyesore. Nintendulator's Video debugger shows the correct values though.

[rainwarrior]

I think most games write $0D to these and forget about them

Most games write the same thing there that they wrote to $3F00. I don't think "most games" would use $0D, and though innocuous in those positions it's probably not a good idea either. (There is a small number of games that probably would put $0D there, though.)

The PPU Viewer in Fceux is strange. It always seems to display the value of color 0 of each sprite palette as $00 although it really has another value (which is the same as the color 0 of each background palette due to mirroring). Only the actual number value is wrong though, the color itself is correct. It's not really a big problem but it's an eyesore.

I never noticed! I'll fix this for the next version.

[koitsu]

That FCEUX quirk has driven me batshit for years. *chuckles* I should've said something about it long ago.

[freem]

The PPU Viewer in Fceux is strange. It always seems to display the value of color 0 of each sprite palette as $00 although it really has another value

Oddly enough, I thought this behavior was intentional, even though it showed the "normal" BG color in previous versions. (can't remember which ones right now though)

[thefox]

I don't know the reason why each background palette has its own color 0 though, since only the first is ever displayed.

It's probably because of the 4 EXT pins (when in input mode). Those could be used to access all 16 colors. In NES/Famicom the pins are grounded so only the first color gets used.

From what I've seen in Visual 2C02, I personally believe that the "background palette hack" is a side effect rather than an intentional feature.

[Pokun]

I think most games write $0D to these and forget about them

Most games write the same thing there that they wrote to $3F00. I don't think "most games" would use $0D, and though innocuous in those positions it's probably not a good idea either. (There is a small number of games that probably would put $0D there, though.)

Oops! I meant $0F, not $0D! But I guess that was wrong too. It might be best to write whatever color you use as backdrop color to all color 0 entries in case the VRAM address selector happens to be pointing to one of these unused colors when using a forced blank.

The PPU Viewer in Fceux is strange. It always seems to display the value of color 0 of each sprite palette as $00 although it really has another value (which is the same as the color 0 of each background palette due to mirroring). Only the actual number value is wrong though, the color itself is correct. It's not really a big problem but it's an eyesore.

I never noticed! I'll fix this for the next version.

Great!