Palette starting address' in CGRAM

gompertz · Post by **gompertz** » Fri Dec 17, 2010 10:08 pm

Hi all, I'm new to the forum and pretty new to programming on the snes. I just had a quick question I'm having a tough time solving despite raking through the docs online plenty of times.

In Mode 0 with 2-bit color, I don't really understand why for BG2 the starting color in CGRAM is "32"... though really I guess it'd be "33" as the transparency from color "0" should be carried to color 32 (err right?). I understand not all BG1/2/3/4 will share the 4-color pallete starting at color 0 because each BG can have unique 4-color schemes, but why does BG2 start at 32 and not 5?

Hopefully I make some sense, thanks to anyone who can help me!

mic_ · Post by **mic_** » Sat Dec 18, 2010 2:27 am

No, that didn't make a whole lot of sense

Each 16-bit word that you store in a BG map to specify which tile to draw at the corresponding screen location also contains 3 bits (d12:d10) for specifying which palette to use.

If you have a BG that uses 2 bpp tiles, then each palette as seen by that BG is 4 colors. So if a tile on that BG has the palette index set to 6 then it will use colors 24..27 in the palette (24 = 6*4). On a 4 bpp BG a tile with pallete index 6 would use colors 96..111.

Post by **tepples** » Sat Dec 18, 2010 5:00 am

mic_ wrote:If you have a BG that uses 2 bpp tiles, then each palette as seen by that BG is 4 colors. So if a tile on that BG has the palette index set to 6 then it will use colors 24..27 in the palette (24 = 6*4). On a 4 bpp BG a tile with pallete index 6 would use colors 96..111.

Does each subpalette have its own backdrop color (e.g. 24 or 96) like on Game Boy Color, or do they all share one like on NES and Game Boy Advance?

mic_ · Post by **mic_** » Sat Dec 18, 2010 6:38 am

I think a pixel with the value 0 is always transparent, so you can set all CGRAM entries to whatever you want and not have problems when subpalettes overlap. There's only one backdrop color IIRC.

Bregalad · Post by **Bregalad** » Sat Dec 18, 2010 9:40 am

Yeah, there is only one background color, exactly like on the NES.
Read my transparency FAQ on romhacking.net for more info about how layers are handled on the SNES.

gompertz · Post by **gompertz** » Sat Dec 18, 2010 3:49 pm

mic_ wrote:No, that didn't make a whole lot of sense

Each 16-bit word that you store in a BG map to specify which tile to draw at the corresponding screen location also contains 3 bits (d12:d10) for specifying which palette to use.

If you have a BG that uses 2 bpp tiles, then each palette as seen by that BG is 4 colors. So if a tile on that BG has the palette index set to 6 then it will use colors 24..27 in the palette (24 = 6*4). On a 4 bpp BG a tile with pallete index 6 would use colors 96..111.

Thanks for the response, I know the three bits (ppp) you are referring to for palette selection. I have found however that my BG1 and BG2 map data, even if they both use palette 0 (ppp=000) I have to rewrite the palette low/high color bytes at colors 32 onwards in CGRAM for BG2 to show properly. (Even though BG2 has been written to $2118 with ppp set to 0.... is this odd?).

I have some sample code I've been working with if this sounds fishy.

Thanks!

tomaitheous · Post by **tomaitheous** » Sat Dec 18, 2010 8:59 pm

Thanks for the response, I know the three bits (ppp) you are referring to for palette selection. I have found however that my BG1 and BG2 map data, even if they both use palette 0 (ppp=000) I have to rewrite the palette low/high color bytes at colors 32 onwards in CGRAM for BG2 to show properly. (Even though BG2 has been written to $2118 with ppp set to 0.... is this odd?).

Not really odd at all. Each BG layer is assigned to a different section of the CRAM, that way it's optimized for color usage. And Tile pixel color #0 should always be transparent regardless of the layer or the value in CRAM for it (think of BG color #0 as its own layer).

mic_ · Post by **mic_** » Sat Dec 18, 2010 10:33 pm

Each BG layer is assigned to a different section of the CRAM, that way it's optimized for color usage.

Huh, what do you mean by layers being assigned sections of CRAM?

Different tiles on the same BG can use different subpalettes. And tiles on different BGs can use the same subpalettes, or subpalettes that overlap in the case of different bitcounts.

d4s · Post by **d4s** » Sun Dec 19, 2010 6:02 am

gompertz wrote:I have found however that my BG1 and BG2 map data, even if they both use palette 0 (ppp=000) I have to rewrite the palette low/high color bytes at colors 32 onwards in CGRAM for BG2 to show properly. (Even though BG2 has been written to $2118 with ppp set to 0.... is this odd?).

I have some sample code I've been working with if this sounds fishy.

My assumption is that you have a bug somehwere in there.
It is of course perfectly possible to assign palette entries 0 onwards to any background.
VSNES, a savestate viewer, comes in pretty handy when figuring out display-related problems.
Bsnes also has a VRAM and palette viewer in its debugger.

Post by **tepples** » Sun Dec 19, 2010 6:28 am

mic_ wrote:
Each BG layer is assigned to a different section of the CRAM, that way it's optimized for color usage.
Huh, what do you mean by layers being assigned sections of CRAM?

As I understand it, the four layers of mode 0 (but not other modes) use separate subpalettes in entries 0-31, 32-63, 64-95, and 96-127.

d4s · Post by **d4s** » Sun Dec 19, 2010 7:18 am

d4s wrote: My assumption is that you have a bug somehwere in there.
It is of course perfectly possible to assign palette entries 0 onwards to any background.
VSNES, a savestate viewer, comes in pretty handy when figuring out display-related problems.
Bsnes also has a VRAM and palette viewer in its debugger.

Oops, forget that.
I've never used mode0 and just assumed it worked like the other modes.
Here's how it should work according to anomies register reference:

In Mode 0, you have 4 BGs of 4 colors each. To calculate the starting palette
entry for a particular tile, you calculate:
ppp*4 + (BG#-1)*32

Sorry about that.
tomaitheous and tepples got it right.

gompertz · Post by **gompertz** » Sun Dec 19, 2010 11:51 am

tepples wrote: As I understand it, the four layers of mode 0 (but not other modes) use separate subpalettes in entries 0-31, 32-63, 64-95, and 96-127.

Yeah that was my understanding to... but given I'm in mode 0 which allows for 4 colors per palette I guess essentially each BG has enough room for 8 palettes of 4 colors to choose from via the ppp bits.

I guess I don't get why snes made it this way, perhaps they wanted to allow for many choices of palettes in any given BG and nothing more; and I was simply looking into it too much. i.e.

BG1 w/bits ppp=000 is entries 0-3
BG1 w/bits ppp=001 is entries 4-7
BG1 w/bits ppp=010 is entries 8-11
BG1 w/bits ppp=011 is entries 12-15
BG1 w/bits ppp=100 is entries 16-19
BG1 w/bits ppp=101 is entries 20-23
BG1 w/bits ppp=110 is entires 24-27
BG1 w/bits ppp=111 is entires 28-31

and then for BG2 ppp resets to 0 and resumes at 32...

BG2 w/bits ppp=000 is entries 32-35
BG2 w/bits ppp=001 is entries 36-39
BG2 w/bits ppp=010 is entries 40-43
etc etc

d4s wrote: I've never used mode0 and just assumed it worked like the other modes.

I did too, I should have read further down the snippet from the doc you pasted (read it before, but not close enough).

Anyways thanks everyone, good to have confirmation on this stuff