http://wayofthepixel.net/index.php?topic=5118.0http://nintendoage.com/forum/messagevie ... adid=67596And a lot of site of palette that kept saying SNES palette is 15 bit that can be found on Wikipedia.
Quote:
The palettes you linked are shown/used here:
https://en.wikipedia.org/wiki/List_of_m ... B_palettes
The SNES, from a software perspective, is 15-bit RGB -- 5 bits for R, G, and B separately. The above wiki page states this clearly and I can confirm it does support that.
These values define the "range of colours" the console supports, not necessary simultaneously (it's probably possible but only with some custom scanline-based hacks/code and I'm not completely sure).
So if you're trying to display a raw 15-bit picture on the SNES, that's not going to be possible without a lot of familiarity with the console.
The closest you'll be able to get is mode 3, which supports up to 256 colours ("indexes") on a single background (BG0) and an additional 16 colours on a second background (BG1). For now just focus on one background (BG0). A colour or "index" is defined by a 15-bit RGB definition (5 bits per R, G, and B).
So on-screen you can have 256 different colours, but the *range* of each of those colours varies depending on what you choose for the R/G/B values.
Make sense now?
It's very similar to the IBM PC's classic VGA mode (320x200x256, a.k.a. segment 0xA000) -- think old MS-DOS games -- except the PC supported 18-bit colour (6 bits per R/G/B), but still with a 256-colour limitation.
(and me, blah, blah, blah..)
I'm saying you can display up to 256 unique colours in mode 3 on a single background. (Mode 3 only offers two BGs -- BG0 = 256 colours, BG1 = 16 colours).
Of those 256 unique colours, you can define the R/G/B values for all 256. The bitdepth of each colour is 15-bit (5 bits per R, G, and B).
Think of it like this, in programming speak:
Code:
palette[0] = rgb(0,0,0); // black
palette[1] = rgb(r,g,b);
palette[2] = rgb(a,b,c);
...
palette[254] = rgb(d,e,f);
palette[255] = rgb(g,h,i);
Hence: 256 colours (256 palette entries), but the "range" of colour each palette entry has is 15-bit (5 bits for red, 5 bits for green, 5 bits for blue).
This is not a "per-game" or "per cartridge" setting -- the SNES lets you use different video modes (called "modes") that support different capabilities. The one with the most colours that you can use the easiest is mode 3.
Those "chart pictures" you have can't be displayed on the SNES because of what I just described above.
I think maybe you should post your question on the SNESdev board...
Okay, I understand what he said, but...I'll be honest, when it comes to questions, I tend to repeat the questions with small changes until I finally figured it out, and I am still little nervous about asking questions publicly, so, here.
I have visit many sites to find the SNES palette, and the only answers I saw was http://en.wikipedia.org/wiki/List_of_mo ... 15-bit_RGB (The 15-bit monochrome and RGB Palette) I gaved up and accept it, so I was using it for a while, but I noticed differences on there.
There is color #70d030 , a type of grassy green from a game, so I went on GIMP to see if this color can be in there, so I did the Select-By-Color tool, and no results is shown at all. On other colors selected, it's just shown AROUND it. (I mean, it selected 20 colors...I know it's part of program, but I did the color-picker tool, and no color is exact to the colors from SNES snapshot on it
...I felt like it could've been 18-bit, but I asked my friend and he saided it's 15-bit...and a lot more he mentioned on the quote above.
I keep having feeling 256 is the REAL limit of SNES usable color, and then it shows here http://img.photobucket.com/albums/v455/ ... fstuff.png , which is the editor for SNES color, which shown to be 496. (Well....I think there's repetitive colors as I see it again..)
I know, the Wiki (Don't always believe anything on Wiki.) says "has a 15-bit RGB (32,768 colors) palette, with up to 256 simultaneous colors." but still, I can't get the feeling if it's 256 colors FROM the color chart, (like "you can only choose up to 256 colors from the system capacities of colors") or it's a HANDICAPPED palette, that it CANNOT show any colors from 32,768 colors, only selected 256 colors, or something.
Here's my questions (that I feel I'll receive negative response) :
-If it IS limited to 256 colors, not 32,768, then what is the REAL palette of SNES colors?
-If they are equal colors, like the system IS capable to full 32.7k sprites, then does it mean that the system "shows the little different" colors to the "chart pictures", like the NES palette difference where brown is colored red in a selected emulator/system (http://www.chrismcovell.com/images/Fami ... erence.jpg if your wondering.), or it's something else?
-Just wondering, if it were limited, how did they pull higher color differences? Did they use "mode" or layers to make it colored "dark/bright" to make it different?
*If anyone is wondering, it does matter, because I feel a lot comfortable if I use the colors EXACT from SNES, it's in my mental feeling where using SNES colors would comfort and calm me a lot. I don't feel like it if it was not SNES colors...You know what I mean?*
Using GIMP? Try converting your image to RGB, posterizing to 32 levels per channel, and optionally converting back. That'll give you 15-bit color, because 32 = 2^5, and 5 bits per channel * 3 channels (red, green, and blue) = 15 bits.
Which emulator gave you the value #70d030? That sounds like it'd be possible from an emulator that uses #F8F8F8 as white, where the color would be specified as RGB(14, 26, 6) in Super NES or Nintendo DS source code.
tepples wrote:
Using GIMP? Try converting your image to RGB, posterizing to 32 levels per channel, and optionally converting back. That'll give you 15-bit color, because 32 = 2^5, and 5 bits per channel * 3 channels (red, green, and blue) = 15 bits.
Which emulator gave you the value #70d030?
Uhh....
It was already set to RGB..do I go on Mode+Assign Color Profile..."?
ZSNES V1.36 WIN version?
VIP Mario 5 : From this:
Attachment:
image7.png [ 25.61 KiB | Viewed 10982 times ]
Just for readers: the large quote in the initial post is from a private conversation caramelpuffpuff and I were having, and I am comfortable with that conversation being disclosed publicly.
The part that, I believe, caramelpuffpuff is having trouble understanding -- and it's very hard for me to rephrase it to make sense to someone -- is what the term "colours" really represents here.
Using mode 3 as an example: you have two backgrounds available, one which supports up to 256 colours (i.e. 256 entries in a palette), and another which supports only 16.
Of those 256 colours (256 palette entries), each colour/entry is a 15-bit value -- 5 bits of green, 5 bits of red, and 5 bits of blue.
The "colour chart" on Wikipedia is showing what the total range of usable colour is on the SNES, i.e. what all those R/G/B combinations are and what they look like -- not how many colours can be shown simultaneously** on the screen at one time.
Wording/phrasing this is very hard given language barriers and so on. If someone here who speaks fluent Spanish (I know there's many of you) can explain the concept of palettes vs. colour depth in Spanish, I'd be grateful.
** -- Except for cases where some programmer has gotten clever and maybe manipulated the PPU per-scanline and is somehow changing palettes/etc. on-the-fly to exceed the limitation set forth by mode 3. But this is an extremely advanced technique and is not "normal" in the sense of "this is easy for a beginner to do".
SNES has R5G5B5 palette, which is 32768 unique colors. How many of these is possible to display at once is a different matter, normally up to 256, but it could be less in some (most) modes, or more (with tricks), but it does not change the main palette.
ZSNES is one of the least accurate SNES emulators.
koitsu wrote:
Just for readers: the large quote in the initial post is from a private conversation caramelpuffpuff and I were having, and I am comfortable with that conversation being disclosed publicly.
Sorry.
Shiru wrote:
SNES has R5G5B5 palette, which is 32768 unique colors. How many of these is possible to display at once is a different matter, normally up to 256, but it could be less in some (most) modes, or more (with tricks), but it does not change the main palette.
ZSNES is one of the least accurate SNES emulators.
O_O.....So, the "chart pictures from Wikipedia" is the MOST accurate colors for SNES? and 256 is actually how many it CAN SHOW on the screen?
And I know off topic, but what is the most accurate SNES emulators?
The most accurate Super NES emulator is bsnes, part of higan. I will warn you that it doesn't run anywhere near full speed on old (pre-Core) or severely battery-constrained (Atom) processors.
It should be possible to increase the number of displayable colors using color math.
And as I suspected, the screenshot you posted uses #F8F8F8 as white, confirming my suspicion of RGB(14, 26, 6).
tepples wrote:
The most accurate Super NES emulator is bsnes, part of higan. I will warn you that it doesn't run anywhere near full speed on old (pre-Core) or severely battery-constrained (Atom) architectures.
It should be possible to increase the number of displayable colors using color math.
And as I suspected, the screenshot you posted uses #F8F8F8 as white, confirming my suspicion of RGB(14, 26, 6).
O-kaaay? But simple question: color chart pictures 15 bit RBG from wiki = SNES color capacity? Or no?
Simple answer is yes.
However, TV settings and color encoding can affect this; TV artifacts could create extra 'ghost' colors. This is not related to SNES hardware, it is just what a TV does for every console.
Shiru wrote:
Simple answer is yes.
However, TV settings and color encoding can affect this; TV artifacts could create extra 'ghost' colors. This is not related to SNES hardware, it is just what a TV does for every console.
OH, THANK, CAKE-ING, GOODNESS!!! THANK YOU SO MUCH!!!
I LOVE YOU!!! ...^^;
It finally makes sense to me now!
*And a little interest with "ghost" colors*
Best example of ghost colors is the 'artifacting' on Atari 8-bit range computers. Google for 'atari artifacting' for details, there are plenty articles on this.
On the SNES there is pseudo high res mode (512 pixels horizonally, instead of 256) that interpolates colors of two adjanced pixels. This is hardware feature of the SNES. However, TV itself can create such effect for images that has high X resolution, colors of adjanced pixels blends and looks like some other color.
Even without artifacts non-linear mappings mean that one 15-bit RGB color space doesn't necessarily match another 15-bit RGB color space, and that each can represent colors that the other can't do accurately. E.g. if one used a straight linear mapping to brightness, while the other used one where more of the range represented more subtle variations in the dark end, while less of the upper range represented the brighter shades with less precision.
Hopefully this isn't too confusing.
I remember ZSNES not actually using 15-bit color.
I think the new renderer uses 16-bit color (R5 G6 B5) at some stage, before it gets converted to whatever is needed by the display surface.
The back and forth hue shift between adjacent gradient colors in F-Zero gets to be irritating, for me anyways. All due to that extra green bit ZSNES somehow uses.
I also remember byuu obsessing about the proper way to scale RGB555 to RGB888 so that the brightest value was 255 (#FFFFFF), not 248 (#F8F8F8).
Increasing resolution from x bits to x+n bits is just scaling by (2^n)*(1+1/(2^x)), that is, (orig<<n)+(orig>>(x-n)). So for 5 to 8 bits, you get 00000000, 00001000 ... 00011000, 00100001 ... 11011110, 11100111, 11101111, 11110111, 11111111. There is an error of +/-1/16 step, which is eliminated by just shifting left when n<x.
255 / 31 = 8.2258...
0,8,16,25,33,41,49,58, 66,74,82,90,99,107,115,123, 132,140,148,156,165,173,181,189, 197,206,214,222,230,239,247,255
Good enough...
Proper color scaling is easy.
Code:
//call this for each color channel, obviously it won't work on a packed pixel
uint64_t normalize(uint64_t color, unsigned sourceDepth, unsigned targetDepth) {
while(sourceDepth < targetDepth) {
color = (color << sourceDepth) | color;
sourceDepth += sourceDepth;
}
if(targetDepth < sourceDepth) color >>= (sourceDepth - targetDepth);
return color;
}
Or in other words: keep repeating the bits until you've filled in all of your new bits. 5-bit ABCDE becomes 8-bit ABCDE-ABC. 00000 -> 00000 000. 11111 -> 11111 111.
ZSNES, from my testing, was using an RGB55 (or 565, I forget) surface with DirectDraw, which did not compensate for this. So a solid white screen in that emulator appears as #f8f8f8 (very slightly gray), not #ffffff. They no doubt chose to use a 16-bit surface anyway because it was marginally faster than copying a 32-bit surface. But comparing that slight inaccuracy against the flat-out completely wrong gamma is kind of silly. Images are blindingly bright if you don't correct the gamma difference between a TV and LCD monitor.
Fun side-tangent: SNES brightness register is a luminance adjust, not an RGB555 adjust. As such, it's technically possible to choose from more than 32768 color shades. But good luck computing exactly how many (certainly there's bound to be a lot of overlap between the different luma settings.)
byuu wrote:
Images are blindingly bright if you don't correct the gamma difference between a TV and LCD monitor.
My
Vizio VX32L TV is an LCD monitor, you insensitive clod!
But seriously, how do actual, correctly calibrated TVs differ noticeably from the sRGB color space that computer monitor interfaces tend to assume?
byuu wrote:
Fun side-tangent: SNES brightness register is a luminance adjust, not an RGB555 adjust. As such, it's technically possible to choose from more than 32768 color shades. But good luck computing exactly how many (certainly there's bound to be a lot of overlap between the different luma settings.)
...It works in analog domain ? The "Shadow/Highlight" function in MD is something that works in analog domain.
> But seriously, how do actual, correctly calibrated TVs differ noticeably from the sRGB color space that computer monitor interfaces tend to assume?
Assuming you have a correctly calibrated monitor at 50%+ brightness (eg Spyder ICC profile on an IPS panel), the left is what the image looks like if you assume 1:1 RGB, and the right is what the image looks like on your standard CRT TV.
If your monitor settings are too far off, then the left may look more like your TV. But with a properly calibrated desktop monitor, the left looks like the image is covered in a hazy fog. The right is clear and shows the vibrancy of colors you see on a CRT TV. At least, the right matches my PVM-2030 RGB monitor at stock settings much closer.
> ...It works in analog domain ? The "Shadow/Highlight" function in MD is something that works in analog domain.
It is most likely analog, yes. That's the only way I have to explain the psychotic behavior of luma=0. Instead of being absolute black, it's like 99% black. Much like how you mute a cheap old TV and you can still barely hear it if you put your ears closer. It was cheaper to just reuse the existing analog scaler and hammer the value down as much as possible than to have an actual switch to completely disable the signal.
Am I crazy for liking the washed out colors (left) better? =)
Probably not.
It's like MP3. People have listened to compressed-to-hell music for so long that they have grown to like the artifacts it causes.
People have been using overly washed out palettes in SNES emulators for the past 16 years, so it's what people are used to seeing.
The gamma-adjusted version can obscure some really dark details, too. But they tend to be on TVs as well. It's a bit like how I used to cheat in Ultima Online by maxing out my monitor brightness inside caves, rather than using night vision items. You were supposed to not be able to see things that well, but with insane brightness, you could see all of the details anyway.
It's an option in my emulator, so you can use either mode. Obviously, as that's how I took those screenshots.
I wonder if it has something to do with the 7.5 IRE "setup" in NTSC outside Japan, where RGB(0, 0, 0) is actually 0 IRE and RGB(2, 2, 2) = 6.5 IRE is the closest to true black.
Could it be due to the fact that the image can be brighter on a TV (as far as I know)? The left ones look better as dim images simply because you can see things more easily than the dark right ones.
tepples wrote:
I wonder if it has something to do with the 7.5 IRE "setup" in NTSC outside Japan, where RGB(0, 0, 0) is actually 0 IRE and RGB(2, 2, 2) = 6.5 IRE is the closest to true black.
No. You can make out the image being displayed if you max out your TV brightness. It's like the color range was reduced by 99%. You can't really simulate it in 24-bit color mode. I output the colors at 48-bit (16-bits per channel), which ends up displayed on my monitor at 30-bit (10-bits per channel.)
Quote:
Could it be due to the fact that the image can be brighter on a TV (as far as I know)?
You can do that, sure. But I am matching the colors of my stock PVM-2030, and before that, a regular CRT I had previously (don't remember the brand.)
I'm frankly stunned that anyone can look at the left images and like them more (the left outside area looks like broad daylight during a thunderstorm), but to each their own.
Back when my workplace had CRTs still, the right did look way too dark, but that was due to the brightness being turned down pretty low. For which I also have a brightness adjustment setting.
byuu wrote:
Back when my workplace had CRTs still, the right did look way too dark, but that was due to the brightness being turned down pretty low. For which I also have a brightness adjustment setting.
Surely you're using calibrated monitors, lest all this effort be lost in that stage...
My primary development monitor is an HP ZR-30w, 30" IPS panel. This is a $1300 professional monitor, which was factory calibrated, and I've had it for about a year now. It's been long enough that I should recalibrate it, but I do not own a Spyder.
The gamma correction is also based on standard gamma differences between PC LCDs and CRT TVs.
But anyway, you have full control over this gamma adjustment, and additional brightness/contrast/gamma/hue/saturation adjustment settings. So you can tweak the colors to match your own TV by hand if you like. It's well worth the effort.
Side-note - I have an 8-bit IPS RGB LCD panel. When I am adjusting levels of R,G,B, and the gamma curve, etc. are these adjustments done in the 8-bit digital domain, or are they done with finer granularity? If it is the former, it seems like everything other than output-RGB = input-RGB would decrease usable color depth. I know often the "contrast" control works this way and will result in details being missing / at levels out of proportion with surrounding details.
If you're not referring to my software, then I have absolutely no idea, that's up to them. But if you are:
Colors are all mixed internally at 16-bits-per-channel. The final output is then reduced to your monitor's color depth. For nearly everyone, that will be 8-bits-per-channel.
Pixel shaders allow the shader to decide between 8-bit (per channel), 10-bit, 12-bit, 16-bit, and single and double-precision floating point. They sometimes sacrifice precision for performance reasons.
byuu wrote:
If you're not referring to my software, then I have absolutely no idea, that's up to them. But if you are:
Colors are all mixed internally at 16-bits-per-channel. The final output is then reduced to your monitor's color depth. For nearly everyone, that will be 8-bits-per-channel.
Pixel shaders allow the shader to decide between 8-bit (per channel), 10-bit, 12-bit, 16-bit, and single and double-precision floating point. They sometimes sacrifice precision for performance reasons.
I was referring to (most) monitors. I've used some that do it inside 8 bits per channel and introduce banding, which is the source of concern.
Your way of doing it is (to me) the only correct way, doing it with much higher depth then reducing it to the output depth.
I've been wondering...
Is the SNES palette limited to 13 for EACH sprite? Or 8 colors each 8x8 squares? I am kind of lost on it:
-As 256 is the limited of colors can be shown on SNES,what's the limit of colors each sprite (normal size)? And around 8x8 one sprite (smallest sprite possible)? Some of them seems 12 or 13, while other is 13 different colors on
it, but I got confused, if it's possible to combine the sprite togather, that may use 26 colors, etc.
- So there's no "shaded/grayed" colors at all, all of them are deep hued? The colors that seems brighter than usual is actually television? I may not explain right, but I need to make sure I don't get confused at all.
There are 15 colors in a sprite palette on the Super NES. Up to eight different palettes may be used at any time. Each sprite may have only one palette, but a single character may be made of more than one sprite each with its own palette.
Colors are specified in an RGB space, with each component's value ranging from 0 (least intensity) to 31 (greatest intensity). You get colors closer to gray if the components' values are close together. For example, (24, 16, 8) is a brownish gray (██████), while (31, 16, 0) is a brighter orange (██████).
tepples wrote:
There are 15 colors in a sprite palette on the Super NES. Up to eight different palettes may be used at any time. Each sprite may have only one palette, but a single character may be made of more than one sprite each with its own palette.
Colors are specified in an RGB space, with each component's value ranging from 0 (least intensity) to 31 (greatest intensity). You get colors closer to gray if the components' values are close together. For example, (24, 16, 8) is a brownish gray (██████), while (31, 16, 0) is a brighter orange (██████).
You get colors closer to gray if the components' values are close together. For example, (24, 16, 8) is a brownish gray (██████), while (31, 16, 0) is a brighter orange (██████).Example where I get confused easily.
So, there's more colors that it's not viewable in raw palette? Or, so the gray-colors mixed with other colors is PART of the entire SNES palette?
caramelpuffpuff wrote:
Example where I get confused easily. So, there's more colors that it's not viewable in raw palette? Or, so the gray-colors mixed with other colors is PART of the entire SNES palette?
The SNES, as well as many more modern computers, directly produces video in RGB. The
"saturation" of a color is related to the difference between the highest number and lowest number of the three numbers that specify an RGB color. The lower the saturation, the more grayish the color is.
lidnariq wrote:
caramelpuffpuff wrote:
Example where I get confused easily. So, there's more colors that it's not viewable in raw palette? Or, so the gray-colors mixed with other colors is PART of the entire SNES palette?
The SNES, as well as many more modern computers, directly produces video in RGB. The
"saturation" of a color is related to the difference between the highest number and lowest number of the three numbers that specify an RGB color. The lower the saturation, the more grayish the color is.
Oh. so the SNES 20000+ palette is in purest form, with saturation ability in them?
caramelpuffpuff wrote:
Oh. so the SNES 20000+ palette is in purest form, with saturation ability in them?
Right. The SNES provides three numbers from 0 to 31, and the three numbers correspond to
red,
green, and
blue brightness respectively. Maybe
wikipedia's article on computer palettes is helpful?
koitsu wrote:
Using mode 3 as an example: you have two backgrounds available, one which supports up to 256 colours (i.e. 256 entries in a palette), and another which supports only 16.
Hello all!
Could someone can explain to me how you can use 256 colors palette entries in mode 3 when the PPP tile map index is 3 bits only?
SNES doesn't use the 8bpp RGB color value rather palette entries?
Thanks you for any explanation.
In a 256-color-mode, the tile data for every pixel is 8 bits wide and indexes across the entire palette. Therefore PPP has no effect (except in Direct Color mode).
I just want to point out, the Wikipedia palette isn't perfectly accurate. I've played around with it with GIMP and I noticed it's not linear RGB. It might be Byuu's CRT palette but I don't know.
Anyway, I find it funny how much people criticize SNES games for having "washed out pastel colors" when they were meant to be played on a CRT.
Really? I think the SNES colors look great on just about any type of display.
creaothceann wrote:
In a 256-color-mode, the tile data for every pixel is 8 bits wide and indexes across the entire palette. Therefore PPP has no effect (except in Direct Color mode).
Great!! Thank you for your answer!
Hello!
In mode 3, I must use an unique 256 colors palette for the two backgrounds (256 and 16 colors) or can I use 2 differents palettes?
Thanks!
Peperocket wrote:
Hello!
In mode 3, I must use an unique 256 colors palette for the two backgrounds (256 and 16 colors) or can I use 2 differents palettes?
Thanks!
The 256 color background has to share colors with sprites and BG2. Of course not
every color has to be used, but the 256 colors you can use for BG1 would include BG2 and sprite colors.
Unless, very specifically, the 8-bit layer uses
the hardware R3G3B2 palette. Then you can have a different palette for the 4bpp layer and for sprites from the 8bpp layer.
psycopathicteen wrote:
Peperocket wrote:
Hello!
In mode 3, I must use an unique 256 colors palette for the two backgrounds (256 and 16 colors) or can I use 2 differents palettes?
Thanks!
The 256 color background has to share colors with sprites and BG2. Of course not
every color has to be used, but the 256 colors you can use for BG1 would include BG2 and sprite colors.
Thank you for your answer. However, I don't understand this diagram:
MODE # of BGs Max Colors/Tile Palettes Colors Total
3 2 BG1:256 BG2:16 BG1:1 BG2:8 BG1:256 BG2:128It indicated BG2 is 16 colors but talk about 8 palettes for 128 colors. Is it a mistake or must I understand BG2 can display 16 colors from the 8 first palettes?
Thanks by advance for your help.
You almost have it.
The 4-bit-per-pixel (4bpp) backgrounds are are BG1 in modes 1, 2, 5, 6, and BG2 in modes 1, 2, and 3. They can display up to 120 colors from CGRAM indices 1-15, 17-31, 33-47, ..., 113-127. Each of these eight sets of 15 colors is one palette. Each map entry sets which of these eight palettes is used for that entry's pixels, allowing one tile to be reused in multiple places with different palettes. Colors 16, 32, 48, ..., and 112 are not usable on a 4bpp background, as they show the layer behind it if any, and color 0 is the backdrop.
Have you programmed NES, TG16, Genesis, Game Boy Color, or Game Boy Advance?
I've already programmed the tgx16 and I've had some difficulties with the graphical mode soon I tried to display a picture larger than 16 colors ...
Thank you for explanation.
It's essentially the same concept. On the TurboGrafx-16, each 8x8-pixel space can use one of sixteen 15-color palettes. A 4bpp background on Super NES has half that (eight palettes).
The common problem between the TGX16 and SNES is the lack of tools or maybe to know how to use it in my case.
For example, I use GFX2SNES (based on pcx2snes) and SIXPACK for converting image. My problem is how to generate a 16 pictures colors with a 256 colors palette.
I succeed to display the bg1. I can look the bg2 behind the bg1's transparency, but seems to have a palette issue since there is no color on it.
Edit : After watching into no$sns debugger, the BG2's details indicated palette 0 for the whole second layer pixels.
Maybe the PPP bits used for the second 16 colors tiles map are not set don't you think?