Color counts per screen

[ob1]

It wraps at 0x7f because CRAM size is 128 bytes (0x80) to hold 64 (16x4) color values , each taking 16-bits in memory (as CRAM bus is 16-bits wide) so 0x40-0x7F region IS used by colors 32-63 . There is no wasted memory in CRAM other that those unused bits in each word but still, you could never have fit two 9-bits color value in one 16-bits word... ouch, my head hurts :oops:

Hello Eke (Bongourlr cong, Touulouuse ! ;D)
Are we sure of this ? (And I really don't know the answer)

64 9-bit wide color registers

The VDP has 64x9 bits of on-chip color RAM

There are spare parts that can hold 9-bits, instead of usual 8, 16, 32 or more bits : Motorola MCM67D709 for example.
The N64 itself has a 9-bit (including one for parity IIRC) data bus.
So, even if, on the Genesis, the CRAM is "accessed as a 16-bits word through the Data Port", I think it's embedded, in the VDP, as mere 9-bits words.

If the CRAM is actually 64 9-bits words (and appears to be 16-bits only through the Data Port), then, Tom' and Charles are right and the address has no reason to wrap above 7Fh : it could wrap above 3Fh. And the address bus leaves enough room (not to mention hints) for another 64 9-bits words.

BUT

Since CRAM is word-wide, address bit zero has no effect

If CRAM was actually 64 9-bits words, there would be no need to connect the CPU/Address/Comm Port A0 to the internal CRAM A0. It would be more effective to connect CPU/Address/Comm Port A1 to internal CRAM A0, and warn the developpers of this :

Beware ! CRAM being 9-bits wide internally, address color is color number. The address is thus 0-3Fh, and the data is accessed through the 16-bits data bus. That is,
CRAM@offset 0 will bring 9-bits wide color #0, left-padded with 0s on the 16-bits data bus,
CRAM@offset 1 will bring 9-bits wide color #1, left-padded with 0s on the 16-bits data bus,
... and so on.

And they didn't (obviously ! :D)

Edit : Stef is much clearer (and faster) that I am ! :D

[tomaitheous]

Something that never really came up, was that the original VDP (and on a few models after the first), that the VDP had serial output. A digital bus. 10bits IIRC because it has S/H status bits. Anyway, you can also easily detect sprite pixels from BG pixels on the bus - by checking the corresponding bit is set or not. Sega uses this method in their arcade boards too. PC-Engine in fact does exactly this to get a separate 256x9bit color palette ram just for sprites. So, that was another option.

actually, the color bus is already limited:

/Y1 : 0= Transparent pixel, 1= Opaque pixel
SPA/B : 0= Sprite pixel, 1= Non-sprite pixel
VD7 : Hilight effect (0= not applied, 1= applied)
VD6 : Shadow effect (0= not applied, 1= applied)
VD5 : Palette, bit 1
VD4 : Palette, bit 0
VD3 : Pixel, bit 3
VD2 : Pixel, bit 2
VD1 : Pixel, bit 1
VD0 : Pixel, bit 0

still there are only 2 palette encoding bits per tile available in the 2 word (16-bits) pattern description , this would have required a whole revamped VDP logic I think. They could have dropped shadow/highlight bits for 2 additional palette bits but still you need the extra hardware for the color bus decoding, CRAM access from CPU, etc. The idea was probably to produce a mass product, not a boosted arcade system.

No no, you take whats already on the digital bus. No revamp in VDP logic is needed. Everything you need is right there. Sprite pixel bit is (would be) used to direct which multiplexed palette bits and the indirect color bits, would go to which corresponding divide half of palette ram (which set of 64 entries). I.e. the sprite bit would be the most significant bit in the index to palette ram, before going to clocked DAC. Everything is external. Not additional logic or setup is needed inside the VDP. Everything exist as is to do it now if someone wanted to mod their system. Though you'd have to access palette ram externally by the CPU. IIRC, Charles actually said the VDP actually has previsions for accessing external palette ram through the VDP itself (it facilitates this). So I guess that would make that even less than an issue. As for S/H, bits. Keep it and setup a larger palette for it, or throw it away/ignore it. The current VDP dot clock (output) is already there to clock/trigger the DAC latch. This is why I mention the PCE and Sega arcade systems. Because they do just that. They determine by the digital pixel bus, which section of palette ram goes to what - based on the status of the sprite pixel bit.

From Charles Macdonald's genvdp.txt doc. I think there was some patent reference stuff too, but I don't clearly remember all the details (this was discussed much over a year ago between him and me). Anyway, the idea was that if it wrapped at 0x7f and not 0x3f, then why would they do that if they had no plans on using ram in the 0x40-0x7f region (i.e. you only need 0x3f WORDs. WORDs being 9bit in length on chip). That was the question that lead to the discussion. And I believe there was talk here about this too.

It wraps at 0x7f because CRAM size is 128 bytes (0x80) to hold 64 (16x4) color values , each taking 16-bits in memory (as CRAM bus is 16-bits wide) so 0x40-0x7F region IS used by colors 32-63 . There is no wasted memory in CRAM other that those unused bits in each word but still, you could never have fit two 9-bits color value in one 16-bits word... ouch, my head hurts

It was the question that originally brought up the discussion, is what I was saying (the discussion of the whole sprite having their own subpalette thing, between Charles and I). And obviously you can't fit two 9bit value in a single 16bit word length. And I think someone already tested those unused bits in palette ram too. Random or weird patterned values returned. Sounded like open bus to me.

If the CRAM is actually 64 9-bits words (and appears to be 16-bits only through the Data Port), then, Tom' and Charles are right and the address has no reason to wrap above 7Fh : it could wrap above 3Fh. And the address bus leaves enough room (not to mention hints) for another 64 9-bits words.

Ob1, no. It was my miss understanding when I was originally starting Genesis coding. I was just saying, that it lead to the discussion of sprite having their own subpalettes. Having already code PCE (EVERYTHING is 16BIT WORD base on the graphics processor, so my mind was still stuck in WORD addressing from left over PCE coding). Him being the guru of PCE like he was for Genesis. Always talking about ways to do tricks, things developers could have done, etc. He told me about the digital pixel bus, etc. And the part about the patents, must have been the part where the VDP can facilitate access to external ram. Sega 16bit arcade boards seem to be his favorite arcade system. So any cross compatibility or technology between the home and the arcade systems, comes up quite a bit on IRC. Blah-blah, etc.

[Eke]

oops, I was wrong about CRAM size, didn't know 9-bits memory existed, thanks for clearing that up. Strange thing is the data format when writing from CPU, why would you need to write zeros between 3-bits pixels values, maybe it's 12-bits, not 9 ?

Still, what I wanted to say is that the reason why address "wraps" at 0x7F is because there is a common address register shared for CRAM and VRAM access. In the case of CRAM, it's very likely only A1-A6 are used for address decoding (so address register does not really "wraps", it's just that some bits are ignored), I don't think it means anything about possible "plans" to use 128 word extended CRAM, though, as you (and Charles) mentionned, external CRAM would definitively have been a viable option.

I bet we will never know why this option was neglected (time ? cost ? VDP limitation ?)

[Mask of Destiny]

oops, I was wrong about CRAM size, didn't know 9-bits memory existed, thanks for clearing that up. Strange thing is the data format when writing from CPU, why would you need to write zeros between 3-bits pixels values, maybe it's 12-bits, not 9 ?

Perhaps to make porting from arcade hardware with 12-bit color resolution easier? If you're converting from a 12-bit palette entry to a 9-bit one you generally want to just lop off the least significant bit of each channel, so arranging the bits as they did makes it easy to re-use palette data from hardware with 12-bit palette entries. It also makes it easier to specify palette entries in hex since each channel is in a separate nibble.

Anyway, I'm of the opinion that going up to 8 palettes wouldn't be worth the cost unless they had used 12-bit palette entries. 4 palettes can be limiting, particularly when you're porting a game rather than designing the art from scratch with the limitations and strengths of the hardware in mind, but there are only so many colors in a 9-bit space that go well together and you can work around the palette limitation more effectively than you can the 9-bit color space.

In hindsight, I think it's clear that the transistors spent on SMS compatibility would have been better spent on more color capacity and/or better support for PCM playback, but it was a reasonable tradeoff at the time. The SMS may have been almost completely unknown here in the US, but I get the impression it did okay in some parts of the world and it when the Megadrive was released, the Nintendo had a stranglehold on a lot of 3rd party developers. It wasn't at all clear they would be able to get many of them to jump ship so having that existing software base to fall back on was a bit of insurance.

[MottZilla]

What parts of the world would that be? Europe and Brazil are the only regions I'm aware of that Master System might be considered a success. I would think that their target markets were more so Japan and North America for the new console, both regions didn't exactly eat up the Master System, they were Famicom Town and NES Town.

It'll a valid point to make but I think it was a poor reasoning behind the decision to waste resources on it. Say that you did up the Color RAM to 128 colors, 64 for BG, 64 for Sprites, and up the color to 12-bit as suggested. You'd have a pretty good looking system in exchange presumably for cutting out some or all Master System legacy resources.

Tomaitheous, never finished Contra but I saw you did. I would have but somehow I got in to other things. Only so many hours in the day.

[Mask of Destiny]

What parts of the world would that be? Europe and Brazil are the only regions I'm aware of that Master System might be considered a success. I would think that their target markets were more so Japan and North America for the new console, both regions didn't exactly eat up the Master System, they were Famicom Town and NES Town.

Europe was mainly what I'm thinking of. It may not have been their main target, but throwing a bone to your existing user base in case things don't work out in the market you're trying to expand into gives you a backup plan in case things don't work out like you hope.

It'll a valid point to make but I think it was a poor reasoning behind the decision to waste resources on it. Say that you did up the Color RAM to 128 colors, 64 for BG, 64 for Sprites, and up the color to 12-bit as suggested. You'd have a pretty good looking system in exchange presumably for cutting out some or all Master System legacy resources.

Again, in hindsight, I agree with you completely. They would have been better off ditching Mode 4 to free up transistors for more CRAM and getting rid of the Z80 and PSG to allow for at least some simple PCM hardware so you could play samples back without tying up the CPU.

But in hindsight, we have the Super Famicom/SNES to compare to which didn't come out until 2 years after the Megadrive. When the Megadrive was released it's competition was the NES and the TG16 and in most respects it was superior to both. It certainly did better in the marketplace than the TG16 and it challenged the NES enough to get Nintendo to finally come out with new hardware. Sure they would have been better off in the long run ditching backwards compatibility in favor of beefier hardware, but the tradeoffs they made were reasonable given the info they had at the time.

[MottZilla]

That's true. Competing against NES and TG16 games before the release of the SNES, Genesis looked pretty good. So it seems really the choice of design may have been influenced by uncertainty of success and short sightedness. If they were more confident it would succeed perhaps they wouldn't have wasted resources on BC. And if they had realized the life-span expected from the Genesis and what the SNES would bring to the table, perhaps then Color RAM would have been more important to them. I just think that it would be reasonable to say that given the information available to them at the time, they should have known or suspected that 64 colors was not going to be enough in the long run. At the very least, while I have no idea what it would cost, making Color RAM expandable either by the cartridge port or the expansion port would have been a good idea. Just think how much different we would view the Sega CD if it had been able to boost Color RAM to 128 Colors.

[Chilly Willy]

At the very least, while I have no idea what it would cost, making Color RAM expandable either by the cartridge port or the expansion port would have been a good idea. Just think how much different we would view the Sega CD if it had been able to boost Color RAM to 128 Colors.

The simplest/cheapest thing to do would have been put RGB input lines from the expansion port to the MD, and mix the VDP RGB with them. Then the SEGA CD could have had a simple framebuffer just like the 32X. Think about it - the SCD had "word ram" as two banks of 128KB, or 1 bank of 256KB. The two banks of 128KB is just like the frame buffer in the 32X. A 12.5MHz 68000 with 512KB of program ram writing to a double-buffered 128KB framebuffer (with an ASIC as well!) would have been killer! That SCD would have had good support and lasted longer.

[sheath]

I think the "inexcusable" argument holds a lot more weight in the Sega CD launch frame than it does in the Megadrive's. I have tried to be clear on this matter, more colors *is* better. I think it would have been better if Sega had, somehow, added more CRAM to the Megadrive/Genesis while not limiting the system in any way (including SMS compatibility). The series of facts of the hardware that I have listed make it reasonable to have done otherwise in certain circumstances.

With the Sega CD, given that they did in fact create more available colors via overlay graphics with the 32X, I can't see as many justifications for keeping the same limitation to onscreen colors. Speaking of bias, the Sega CD is easily in my top five systems of all time (right up there with the SNES and Genesis). I still felt immediate disappointment in the lack of new colors and more color diversity as I had seen on the SNES by then. Nonetheless, even here there are some facts that may eventually justify Sega's decision.

Perhaps overly complicating the installation of the Sega CD simply ruined the Sega CD's viability as an add-on. The Sega CD - Genesis is already affectionately referred to as the "frankenconsole" by fans. Two AC Adapters, and cables running to or from at least four locations caused that on its own. We are actually talking about commercially viable products here, not stuff you and I could hamstring together with a tutorial and a soldering iron.

Secondly, I was so excited about the prospect of actually upgrading my Genesis, that I bought a Sega CD 1 at launch in 1992 for $300. That was a ton of money, so much so that I had to sell certain consoles I owned at the time to private buyers to make the total. I won't mention which ones since that is apparently so touchy that I get personally attacked for even suggesting the qualitative differences between systems. Nonetheless, I found the $300 Sega CD a good value proposition at launch and did what it took to get it.

If the Sega CD had been $50 or $100 more expensive I simply would not have been able to, and most consumers chose not to anyway. So, until we know how much this additional cost would have cost Sega in 1991-92 we *still* cannot claim the decisions made were <insert expletive here>.

[MottZilla]

You may feel their decisions were justified but that is your opinion which you are entitled. I think with the Sega CD again they could have cut down on the features and focused on what really mattered.

While I'm not that aware of the Sega CD's technical specs, I know it had some sort of sprite zooming, it had another 68000 at 12mhz or so, a bunch of different pieces of RAM, some additional sound channels I think too. The way I see it, boosting the Color palette, perhaps with a 32X style video output overlay or plain replacement was more important than sprite zooming or another 68000. I really think PC-Engine and TurboGrafx got the CD-ROM add-on just right. No extra bells and whistles. Just a CD-ROM and a System Cartridge containing BIOS and RAM which could be upgraded as RAM prices fell. Ofcourse in the case of the Sega Genesis I think they would have been wise to do the minimal approach but throw in a new VDP or if they had thought about it when designing the MD, have made a connection for extra Color RAM on the expansion connector so the Sega CD would have been able to easily contain a Color RAM upgrade.

Twice the Colors, massive CD-ROM storage, CD music, and an upgradable System Cartridge would have made the Sega CD a totally different beast. Seeing how the TG16 failed to catch on here, perhaps the Sega CD could have been like the PCE CD was in Japan, if they did it as I suggested might have been a better way to go.

That's sort of a trend I've noticed is that some systems really are silly when you realize there is no provision to add more valuable RAM. It certainly makes sense to do this since RAM has always fallen in price over time. Ofcourse these days it no longer makes much sense.

[sheath]

I feel their decisions *may have been* justified. Without more facts I can't know for sure, I can only imagine what might have factored in to the decision.

You do see that there is some argument to the fact that consumers didn't see what we are seeing right? It is also not established that more colors "really mattered" more than any other feature.

RAM of the same type has tended to fall in price over time, and then raise again exponentially when its production levels drop. Newer types of RAM have always ensured that the window for cheap older RAM is small.

[MottZilla]

While you can't say as a fact that colors "really mattered" it is fair to point out all the publications that cited the color issues particularly between SNES and Genesis multi-platform games that were written during the day.

I respect that you think their choices may have been justified. That's fine. They may have had a good reason to you. But from my perspective I don't believe they have a solid reason to excuse their palette RAM issue.

[tomaitheous]

oops, I was wrong about CRAM size, didn't know 9-bits memory existed, thanks for clearing that up. Strange thing is the data format when writing from CPU, why would you need to write zeros between 3-bits pixels values, maybe it's 12-bits, not 9 ?

From a developer stand point, that's easy. It's easier to manipulate palette effects (though mostly fade up/down/in/out) in that format. You have direct nibble access. Compare that with the PCE's packed 9bit format. The VCE also uses 9bit ram (even though it's a 16bit data bus to the VCE), but it's compact into (G_3bit<<6)+(R_3bit<<3)+(B_3bit). If I wanted to do an effect on the master palette (which I would have a local copy in ram), I have do more work. I have to isolate the 3bits from that WORD with shifting and such for the upper colors. I could keep it in the Genesis format (and in fact I do), but I still have to convert it back to packed format. The Genesis format/version is just a little nicer/cleaner to work worth IMO.

Still, what I wanted to say is that the reason why address "wraps" at 0x7F is because there is a common address register shared for CRAM and VRAM access. In the case of CRAM, it's very likely only A1-A6 are used for address decoding (so address register does not really "wraps", it's just that some bits are ignored), I don't think it means anything about possible "plans" to use 128 word extended CRAM, though, as you (and Charles) mentionned, external CRAM would definitively have been a viable option.

I bet we will never know why this option was neglected (time ? cost ? VDP limitation ?)

If it was time (or even being too late), there was always the option of the external method. For the address bits of VRAM, there's enough bits to do more CRAM entries. Someone else mentioned plane A and B having their own palette entries. 4+4+4 would be VERY nice. Could even extend that the "window" map too. Although, that's not worth the cost IMO - but still an option.

Anyway, I'm of the opinion that going up to 8 palettes wouldn't be worth the cost unless they had used 12-bit palette entries. 4 palettes can be limiting, particularly when you're porting a game rather than designing the art from scratch with the limitations and strengths of the hardware in mind, but there are only so many colors in a 9-bit space that go well together and you can work around the palette limitation more effectively than you can the 9-bit color space.

The (homebrew) developer in me would have to strongly disagree. 9bit master palette still has its strengths. The difference from 9bit to 12bit isn't that great in most situations. There are plenty of examples of 9bit color being exceptionally well off for its time (and some examples I've already posted here in this thread). I do agree you can hit some limitations with 9bit color, but Genesis is kinda far off from that wall in a lot of circumstances (from my experience and just looking at Genesis titles in general). On the PCE with 32 subpalettes, I definitely run into this problem. On the Genesis, I find myself running into totally different problems. Look at a lot of Genesis/Megadrive games that try to extend the range of color in a level/area/shot/window. You almost see one of two things; High contrast differences between shades and colors because there's not enough subpalette to hold explicit combinations and so the first to go is either "shades" and/or least important colors, and the other side which is almost the same thing - except the developers choice low/dim color choices because they aren't as contrast-y and blend better. But the result is still a lack of range in colors AND you tend to get drab and/or muddy looking graphics ontop of that. Add that with dithering and composite/rf out, and it's like looking at a muddy image with vaseline on your glasses (not that I wear glasses, but if I did).

In hindsight, I think it's clear that the transistors spent on SMS compatibility would have been better spent on more color capacity and/or better support for PCM playback, but it was a reasonable tradeoff at the time. The SMS may have been almost completely unknown here in the US, but I get the impression it did okay in some parts of the world and it when the Megadrive was released, the Nintendo had a stranglehold on a lot of 3rd party developers. It wasn't at all clear they would be able to get many of them to jump ship so having that existing software base to fall back on was a bit of insurance.

If you look at SMS support in 1987-88, I think the emerging markets like EU/UK/BR were still in their infancy at the time. SMS never did good in Japan. Not only the FC to compete with, but also the ever popular MSX line and very popular Japanese PCs. The Japanese small home computer and PC market was more like EU than US. Here in the US, home computers definitely weren't as popular as the NES and later systems. And the plain jane PC here couldn't handle even NES stuff at the time, so you tended to get totally different genre of games for the computer market. But back the SMS. I think it's clear to me that Sega thought they needed every bit help they could get - thus SMS compatibility. Hindsight obviously being 20/20 and given how the system turned out unexpectedly popular across the sea/foreign markets, we CAN point out that in the end, it was a poor decision given the only real weakness of the Genesis... is the subpalette issue. While some gamers/people don't care for FM, I think it's a totally viable, comparable, and capable sound setup for that era (for a number of reasons we don't need to get into). Having said that (because some gamers actually list it as a weakness and I don't necessarily agree with that), the Genesis really only has that one weakness in its whole setup. It's just that it's a pretty BIG weakness. Are there exceptions? Sure. But exceptions are just that, exceptions. And the number of exceptions is too small IMO. (Gaiares FTW! That game is so beautiful even to this day. Earthworm Jim is also an impressive exception.)

Actually, I'm wrong. PCM was a weakness of the Genesis/Megadrive. But that was fixable via the cart. A simple DAC with a tiny buffer would have done the job. In relative prospective, Famicom did way more than just that type of setup - for audio upgrades via cart. But putting all things into prospective, the poor PCM examples in Genesis games weren't that big of a deal or much of a weakness IMO. Maybe near the end of the systems life when more games were using digitized samples, but again - they could have fixed that issue via cart if they really felt the need to. Maybe they didn't because they wanted there to exist a difference and reason to buying a SegaCD? Pure speculation, but I wouldn't put it past companies to do something like that. I mean, Sega sure did sink a pretty penny into the SegaCD.

Speaking of SegaCD. Opinions seem to be all over the place on what should have been done on this addon (on many forums). I sat down and thought about it. Comes down to colors again. This time, much later in the 16bit generation game. One could argue the inexcusability of Sega's choice on the matter the first time around, but the second time around is pretty hard not to argue otherwise. What mattered most to me, was the expansion of existing cart games. And by that I mean, more detail, more cinemas, more story, better/more realistic music, better sound FX, speach, etc. Scaling and rotation are nice, but given all the games that I loved BITD, only a very small amount even had that. And the one that did, weren't necessarily tied to it. I would have been fine without it. A new VDP that overlaid with the existing VDP, would have been fantastic. It didn't have to be much. 1 more BG layer and 1 more SPRITE layer, with an effective amount of subpalettes and appropriate master palette for the time. And maybe a 256 color bitmap mode for it (if it at least had 64k, it would be very doable). Bitmap logic has got to be the most simplest logic for setting up a graphics device. Anyway, that would help for point and click or RPG or other parts of games, with little additional cost (the bitmap mode). I don't need the ASIC and there's nothing to say that Sega NEEDED to make 10 times the money back on the cost of such a VDP.

I was hyped about the MegaCD, already having experienced TGCD games. About 6 months out, before the SegaCD hit US shores, I had a chance to see and play the MegaCD from a friend of a friend at the time. I was very disappointed. I held off getting one on release day. My brother actually bought the TG Duo on release (I was holding out) and once I played GOT, I was blown away. It was amazing. It wasn't grainy FMV or lame stuff like Wonder Dog or Willy Bemish. My best friend who ended up getting a SegaCD that week of launch, came over to play this new shooter. He was immediately pissed off at his purchase of the SegaCD and borrowed money from his parents to purchase a Duo. My brother took back the Duo a couple of weeks later. And So I just spent the money to buy one myself right after that. Given everything that was comming out and did come out over the time, I was glad I didn't waste my money. We both ended up ordering lots of imports for the Duo. I think the only time I was really excited for the SegaCD, was when Final Fight CD came out. I didn't have a car at the time and my friend didn't have a working bike, I took his money and rode 10 miles at 8pm at night just to get that game. Music? Fantastic. Number of enemies and everything from the arcade included? Fantastic. Graphics? Ouu. Not so fantastic. I had an RGB monitor from a left over Amiga setup. But we played the SegaCD over at his house and the graphics were very muddy looking at the time. I know I missed a few gems that did come out on the SegaCD, but overall I'm glad I didn't spend the money on it. Instead, I imported games for the Duo and kept on buying new Genesis games (and used games that I had missed over the years for it). My brother mostly bought the SNES stuff, but I still played them.

I think with the Sega CD again they could have cut down on the features and focused on what really mattered.

Exactly. Even with the scaling/rotation of the ASIC, it still has large hole of inefficiency. There's no direct interfacing with the Genesis VDP. You don't have smooth full screen 60hz scaline/rotation because there isn't enough bandwidth to transfer that much data to the VDP in a single frame. The other problem is cell color limitation. The very reason why Nintendo went with 256 pixel mode for cells for mode 7. On the SegaCD, you're limited to 16 colors for the BG layer for the most part. There is one trick you can do to expand on that, but it really limits what you can do scaling wise and definitely doesn't work for rotation. And using multiple planes to increase colors, really kills your frame rate (again, you only have like 7k per frame to transfer and that's assuming you do nothing during vblank. Then there's the matter of vram. If for some reason you even had the bandwidth to transfer a full layer, left a lone 2 or 2+sprite layer, you don't have enough vram to double buffer any of that. You don't even have enough vram to double buffer a single BG layer - unless you don't want any room for sprites). The ASIC is wasted on the Genesis VDP. The ASIC would be much-much-much better paired up with a bitmap system on the SegaCD attachment side, like Chilly Willy said.

Even with all its limitations as is, the biggest nail in the coffin is the games. So many awesome titles that could have been done, but soo many crappy titles that came out instead. I rather not talk about the SegaCD. It makes me sad

Stef: I posted a bunch of pics in this thread already and I think they show off 9bit color fairly well. Just look back at the SNES shots that are converted from 15bit color to 9bit color.

Here are a few that show off 9bit color in general:
<- Arcade 12bit color
<-9bit color
<- SegaCD shot for comparison (still 9bit color). You can clearly see the Genesis doesn't reach the 9bit color limitations. Not even close in that shot.

<-15 bit color
<- 9bit color.
<-15bit
<- 9bit
<- 15bit
<- 9bit
<- 15bit
<- 9bit (with some hand optimizations by me)
<-12bit
<-9bit
(top=12bit,2nd=9bit,3rd=12bit,4th=9bit)
(top=12bit,2nd=9bit,3rd=12bit,4th=9bit)
9bit as above but with dithering (had the pic left over form years ago)
<-12bit
<-9bit
<-12bit
<-9bit
<12bit (15bit SNES, but it's a port of Neo Geo game)
<9bit


Some comparisons between 9bit colors shots themselves.





A quick few general examples of 9bit color put to average/good/typical use, though (all PCE because only three systems use 9bit color, MD, PCE, ST, it's the only one 'lax enough in color restrictions.):






Ok, I'm getting tired of uploading and copying pics, so I cut the above and below supply of pics short.










(nice and big, so it's up close and personal)

Above pics are for two games made specifically for the Genesis hardware. The 9bit palette really didn't play any part in limitations in those shots. The enemies look near NES quality and that's definitely not because of the 9bit master palette. There are plenty of other examples on the Genesis with softs made specifically for the system, in that even with that type of advantage, the restricted number of subpalettes is the primary reason - not the 9bit master palette. I'm tired of posting pics. And I think the above examples need no explaining/pointing out. But I would like to point out, like in those above games, many Genesis games resort to restricting enemies to 5-7 colors in order to make due with said palette limitations.

Anyway, all those pics are supposed to show - that all the inherent problems with a restricted number of subpalettes, isn't going to be "fixed
with a larger master palette. If anything, you'd get the "Amiga" effect. You still have the original problem of color range (or the lack thereof) and you don't get the advantage of a bitmap system like the Amiga. Bigger master palette isn't going to solve anything in almost all cases marred to only 4 subpalettes. At least Sega *didn't* mess up and restrict sprites to only two separate subpalettes and BG to two separate subpalettes. That's about the only good thing I can say.

Edit: Fixed some typos.

[ob1]

The way I see it, boosting the Color palette, perhaps with a 32X style video output overlay or plain replacement was more important than sprite zooming or another 68000.

Back in these - good - old days, SNES was impressive thanks to its mode 7. Early 3D was all the rage. Let's remember that the SNES was released with F-Zero (and Pilotwings, one month later).
It was only later (~93) that color clearly began to be an issue with the Genesis. I've recently re-read - french - magazines (Joypad, Consoles+, great abandonware-magazines.org) from this time, and you can see some baffling comments about it.

I think Sega will was double, back then. Invest on the tomorrow technology of tomorrow, and get back on Nintendo that started the SNES.

Yet, looking at accomplishement, and now that time has passed, we can ask ourselves : was it worth it ?
Because, regarding Sega early 3D, there have been Sylpheed (MegaCD, 1993), Virtua Racing (SVP, 1994) and ... that's pretty all we have. Who even remembers Sewer shark or Microcosm ? And what's your favorite Sonic ? Sonic2/3 ... or Sonic CD ?
Today, we can say that those Sega bets (MegaCD, 32X, Saturn) were a miss ; and I completely agree with you Mott'.
But every business, and especially console industry, is a bet. Playstation was a bet, N64 was a bet (regarding cartridge), DS was a bet, Wii was a bet ...
iMac was a bet, iPod was a bet, iPhone was a bet ... iPad is a - seized - bet (Yes, I love Apple too !)

And here, my just little very own feeling : Sega bet, lost and finally died. And that's a great pity.

[mic_]

IMO mode 7 was never that impressive, even back then. The key strengths of the SNES PPU compared to the Genesis VDP were to me the larger number of colors, more background layers, more sprites, and color special effects. Of course, in the end what really matters is the games, and that's where the SNES really shone. I mean, the SNES was launched with Super-f'ing-Mario-World! The best 2D platform game of all time (along with New Super Mario Bros Wii).

The 32X was a huge blunder, even if it's a system I like to code for
The Saturn was way too complicated, had an underpowered VDP1 which couldn't keep up with the PlayStation's 3D capabilities, and a large part of the good Saturn titles only saw a japanese release.

With the Dreamcast they corrected most of these problems and released a good console with a strong software library. But in the end it didn't sell well enough, and they decided to get out of the hardware business.