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