Why is the SNES on screen color pallete so small?

Although there probably isn't an exact reason, I really just do not understand why the SNES has a huge 32,768 color master palette and has only 256 colors to choose from. Unless there are two nearly identical colors are side by side, which there probably won't be 256 colors, it is really hard to see a difference in color. Even the Turbografx could display 512 colors at once, even if it didn't have nearly as much color fidelity. Would it really have cost that much more money just to add another 512 bytes of cgram? It would seem more wise just to take some memory from the main ram or vram and turn it into cgram, although I'm sure it wouldn't be as simple as that. Sorry for the dumb post. Oh, by the way, I already know that the Sega Genesis had it way worse with only 64 colors (how did anyone manage with that? ).

8 bit data buses, as 8 bits gives you 256 colors to choose from. Going bigger would mean you'd have to have that much more RAM for displaying them, that much more RAM for storing them, and more speed to process them in some cases. 256 isn't a little though, NES only has up to 19 on screen at once normally.

Here's a better question: why does it matter?

If you've created a time machine and plan on going back in time to give Nintendo hardware designers a piece of mind, please let us (or at least me) know, as I'd like to tag along so that I can relive some of my childhood happiness.

The PPU needs to have access to the VRAM and CGRAM at the same time: VRAM to fetch background tiles and CGRAM to read their color. Turning VRAM into CGRAM would require far faster VRAM than was affordable in 1990.

It matters because understanding the design constraints helps one understand how to create efficient software.

Consider yourself lucky the SNES even has a pure 256-colour mode at all. The majority of arcade & console games in the '80s had 4-bit character graphics with 16 colours per tile -- Namco System 1 in the arcade being a notable exception -- the main difference between all the systems being how many total tile palettes they had (The SMS: 2; SNES: 8 (for BG); Turbo: 16, etc.)

Plus the SFC was designed in 1986-87, so it's about at parity with the latest console tech at that time. Nintendo didn't update much (except for the Main RAM capacity) between that time and the SFC's launch in 1990. That's the bigger crime.

Where did you get 19 from? It's actually 1 bg color + 4 * 3 (12) background colors + 4 * 3 (12) sprite colors = 25 colors.

Considering the fact that the original MCGA could at most display 256 simultaneous colours out of a master palette of 262,144 (applies to other VGA modes too, before high- or true- colour are possible on domestic cards), and that the Mega Drive could normally only display 64 colours(well, I think it's 61 if you care about stuff like this) out of 512, I don't see how the on screen palette of a SFC could be considered small.

Moreover, the SFC has transparency effects on backgrounds (more "real" than those highlight/shadow effects on the Mega Drive at least), in which case much more colours can be shown at once.

whoops, it's not 3 palettes per layer, heh. You can tell I haven't actually done any NES programming in a bit.

I'd say that the color capabilities of the SNES were perfectly adequate for the time. Much better than its main rival... IMO this was *the* feature that gave the SNES the biggest advantage during the 16-bit wars (audiophiles will probably say something about the sound, but I honestly don't care much for the muffled sound of the SNES)... Genesis games struggled really hard with dithering, raster effects and the like in order to keep the graphics interesting when compared to its nemesis.

I agree, I can't see how anyone would think this wasn't enough. The MegaDrive/Genesis is the system that could be known for it's lack of color/palettes. I'm not sure what Espozo meant by the 32K color space and comparing it to the 256 colors available at a time. I don't think there is anything wrong with that.

The SNES was already a fairly expensive console so adding more would have pushed that price up. If I was to complain about the SNES, the upgrade I would have wanted to see is a faster CPU. After that, DMA to the SPC-RAM would have been nice too, Street Fighter Alpha 2 is a case for that.

The Genesis however, the #1 upgrade I'd want is most definitely more palettes for more colors on screen at once. Four palettes is pretty limiting. One example I usually think about is a typical fighting game like Mortal Kombat or Street Fighter II. With only four palettes, you instantly lose two for each fighter. That leaves you only 2 more palettes for everything else on the screen. You're going to have the status bars taking up some of that, and then you have the entire background too. If characters shoot projectiles you're going to hope the projectiles can be colored with that character's own palette. Mortal Kombat does this with Cage throwing a gray force ball which is supposed to be green.

With that in mind, I think the Genesis wouldn't have been seen as far inferior in that aspect if they had added 4 more palettes. Even if it was as simple as giving the BG and Sprites separate four palette banks. It would probably have been the easiest method to add it since it wouldn't require any extra attribute bits. Just the extra Color RAM and logic to switch between banks for if a sprite or bg pixel is going to be rendered. With this total of eight palettes, my fighting game example no longer has the severe limitations.

The hardware actually differentiates sprite and BG colors, but you need external RAMDAC to use that, and some arcade boards that use the MD VDP actually do it. You can also use Shadow/highlight status bits to add more palettes. The digital color bus must be explicitly enabled by software though and it is also only present on the non-integrated version of the VDP.
I imagine all the limits come from the SMS compatibility, that stuff is almost entirely incompatible with how MD side works, only same thing is the register access and that's basically it. Cut the SMS stuff and there's plenty of realestate for the extra CRAM and DAC bits.

Dunno, the debug register seems to imply that plane A in mode 5 is actually the same thing as the tilemap in mode 4, and there's also the fact some mode 5 settings still affect mode 4 even when they shouldn't (e.g. the screen resolution), so I presume there's actually quite a lot more shared than one would expect.

Really we won't ever know until the VDP is decapped, but for some reason people insisted that decapping the YM2612 was way more important >_> (and that wasn't even delayered, so we don't even know for sure that we actually understand the circuits) I mention this because when I looked at the 68000 die shots it turned out to be completely different to what I thought - about 1/3 was the ALU, most of the rest of the die was memory of some sort (the registers, the microcode, etc.) and the actual processing stuff actually took up very little of the die space.

Those are minor things, stuff like how sprites and tilemaps etc only share the basic idea but have completely incompatible imprementation are what matter more. Same deal with TMS modes in SMS VDP, they are night and day, you can have data of both coexist in VRAM and switch between the modes without affecting each other.

My point was that we won't even know for sure until we decap the thing and actually see how much space does each thing take up. There's also the fact that ASIC also hosts the PSG and all the control logic (and basically anything that isn't the CPUs, the YM2612 or the KB-sized RAMs).