It is currently Wed Mar 29, 2017 9:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sat Jan 14, 2017 8:50 am 
Offline

Joined: Sat Jan 14, 2017 8:40 am
Posts: 23
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:
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:
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


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 9:24 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2780
Location: Tampere, Finland
The keyword is "palette mirroring": http://wiki.nesdev.com/w/index.php/PPU_palettes

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 10:44 am 
Offline

Joined: Sat Jan 14, 2017 8:40 am
Posts: 23
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?


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 11:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9429
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 12:49 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 512
Location: Sweden
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.

hundonostudy wrote:
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.


Last edited by Pokun on Sun Jan 15, 2017 2:53 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 2:20 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 4921
Location: Canada
Pokun wrote:
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.)

Pokun wrote:
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.


Last edited by rainwarrior on Sat Jan 14, 2017 2:51 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 2:27 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
That FCEUX quirk has driven me batshit for years. *chuckles* I should've said something about it long ago.


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 2:51 pm 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 145
Location: freemland (NTSC-U)
Pokun wrote:
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)


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 2:59 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2780
Location: Tampere, Finland
tokumaru wrote:
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 3:08 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 512
Location: Sweden
rainwarrior wrote:
Pokun wrote:
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.

rainwarrior wrote:
Pokun wrote:
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! :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group