Comparison of 4th generation ("8/16-bit") system hardware

[tomaitheous]

Bottom line, if the Genesis VDP was going to have more available palettes on screen simultaneously it would need more Color RAM than it has. I have seen lively debate that the cost could be made up by eliminating Master System compatibility, but cost is a main reason why the Genesis is limited to four 15 color palettes.

Might argument in that debate was dropping the z80 and z80 ram. That would drop the cost much more than needed for some simple additional internal VDP 64x9bit static ram. But in the long run of things, and assuming still internal ram VS external ram for color use (as stated doable for the VDP), the cost couldn't have been.... what, maybe $5 at most? If even that high. I honestly think they felt what they had was adequate. The Genesis is already complex enough, and the 68k processor was definitely more expensive than any custom core 65x variant at the time, etc.

Also regarding the MegaCD in Japan, I do think a simple video buffer + dac output would have worked well and worth whatever additional cost. Yes, you'd still need the Genesis video processor for tilemap and/or sprite overlay (and a pass through cable setup like the 32x) - so it'd still be dependent on the Megadrive (for FM sound too). I'd say it'd be more important than the Ricoh chip (maybe a simple 2 channel ADPCM controller in its place), if costs needed to be cut. And probably get away with a cheaper cpu than the 68k sub-cpu.

[Sik]

Considering how most Japanese developers used it, they could have gotten away with just the CD drive and the Ricoh chip (well, and extra RAM for obvious reasons). It seems that the only thing Japan really cared about was voice acting, only a few games bothered with trying better graphics.

[Black_Tiger]

All the MD needed in the Mega-CD was the same deal as the PCE-CD, just a CD-ROM and the ability to stream and play sampled audio clips. The difference in cost between that and the MCD hardware we got, should have been spent on ram. Even 12megs should've been enough to future proof it and allow quality arcade ports of Neo Geo and CPS1/2 games.

[Sik]

Um, the hardware Sega went with already has more RAM than the PCE-CD =/ 768KB should be good enough to host an individual stage, really. And that's not counting PCM's own RAM (yeah, the Ricoh chip has its own RAM too).

[kool kitty89]

Considering how most Japanese developers used it, they could have gotten away with just the CD drive and the Ricoh chip (well, and extra RAM for obvious reasons). It seems that the only thing Japan really cared about was voice acting, only a few games bothered with trying better graphics.

Again, even the ricoh chip was probably overkill . . . Amiga style DMA sound should have been fine (or even simpler Soundblaster/STe/Mac type sound) and should also have made streaming PCM off CD simpler. (and obviously would have been more flexible than the PCE's mono ADPCM channel -cheaper, simpler, and practical for software mixing -and software decoding of other formats)

As for JP developers . . . yes (aside from Game Arts) the system was pretty poorly used . . . though the bigger issue was the limited software it got in general. (a cheaper/simpler -possibly earlier- system might have helped popularity though, and given the PCE CD's popularity, having relatively similar features would mean simpler cross-platform development -while the MD could still retain some notable advantages at much lower cost . . . and ones simple enough for many developers to exploit -like RAM and PCM capable of software mixing)

FMV wouldn't have been as good (as far as Cinepak class formats at least), but the 68k alone should have allowed for some decent compression. (at least for cutscenes . . . though in-game stuff would suffer more contention for CPU resource)
A rudimentary blitter with simple block-copy would help a lot with video decompression though. (and potentially for some sprite/tile compression formats too -and some realtime rendering, obviously)

Might argument in that debate was dropping the z80 and z80 ram. That would drop the cost much more than needed for some simple additional internal VDP 64x9bit static ram. But in the long run of things, and assuming still internal ram VS external ram for color use (as stated doable for the VDP), the cost couldn't have been.... what, maybe $5 at most? If even that high. I honestly think they felt what they had was adequate. The Genesis is already complex enough, and the 68k processor was definitely more expensive than any custom core 65x variant at the time, etc.

If they did scrap the Z80, they really would have needed some sort of PCM hardware to make up for that . . . though a very basic DMA sound circuit (even like that of the Mac) should have been adequate. (and nominally better than most existing PCM drivers )

On the VDP end, another trade-off that could have been made is removing the shadow/HL logic . . . which also may have gotten the system closer to making 12-bit RGB practical on top of the added palettes.

Also regarding the MegaCD in Japan, I do think a simple video buffer + dac output would have worked well and worth whatever additional cost. Yes, you'd still need the Genesis video processor for tilemap and/or sprite overlay (and a pass through cable setup like the 32x) - so it'd still be dependent on the Megadrive (for FM sound too). I'd say it'd be more important than the Ricoh chip (maybe a simple 2 channel ADPCM controller in its place), if costs needed to be cut. And probably get away with a cheaper cpu than the 68k sub-cpu.

That's assuming the added cost/complexity of a blitter+VCD+DAC (and genlock hardware) was even worth it. (ie developers would take major interest and consumers would be captivated by it)

There's a big argument for doing more like the Super CD (ie just CD+RAM+sampled sound -and cheaper/simpler Amiga-like DMA PCM would have been cheaper than the PCE's ADPCM chip or the Ricoh one -simpler/embedded/custom chip working in shared memory- and also easier to use for streaming PCM -since you'd just DMA it to program RAM rather than having to copy/buffer to wave RAM).

OTOH, they also could have done both as 2 separate add-ons . . . a potential mess, but not without significant advantages:
Say a graphics add-on via the cart slot (intended for cart and CD games) and the simpler CD add-on on the expansion port (sort of like the idea of making the SGX and add-on -and making a duo system that combined all of that).

In particular, if one add-on ended up taking off while the other didn't, support could be pushed for the stronger one . . . or it might have ended up as a regional split. (ie the cart system may have been bigger in the US with CD bigger in Japan, or any number of possibilities)

Plus, with the way the MD is set-up, you'd need to use the cart slot for video expansion regardless. (though a more compact, cart-mounted MCD design would have worked there too -though FCC compliance may have been a problem)


And, on another note: if Sega had simply added the VDP pixel/color bus to the cart slot or expansion port, a simple external RAMDAC could have been used to increase the palettes/color depth after the fact . . . and an added bitmap layer could be more flexible as well. (in terms of priority between the MD VDP layers and possibly using simpler circuitry to mix the video digitally and avoiding the analog genlock issues) They could have made a single ASIC that carried the enhanced RAMDAC and bitmap VDC logic (or perhaps embedded that in the same chip as the MCD memory interface+graphics ASIC -or, obviously consolidated that later-on)

And another note on the MCD's cost/complexity:
aside from removing features across the board, they could have just aimed at system aimed more around a unified bus shared with the MCD (or at least keeping additional buses as few as possible), thus cutting initial cost for board/chips/interface logic, and potentially much more so in the long run. (fewer buses meaning more chips that can be consolidated efficiently with common external I/O lines -since they're sharing the same bus)

No sub-CPU, DMA sound, and the graphics ASIC all working on a shared bus with the 68k would have saved a lot . . . though with the VDP DMA contention issues, that may have been somewhat problematic. (probably to the extent that you'd want at least 1 added bus, unless that contention was dealt with in other ways -at very least you'd need to be able to avoid choppy PCM, so either an added buffer that was filled only in active display or perhaps just relying on segmented V-DMA to avoid excessive contention -and result in only modest PCM artifacts) Albeit you could also explicitly restrict VRAM copies to CPU block transfers instead and avoid contention that way. (in either case, you definitely would want to avoid DMA in active display if the framebuffer shared the 68k bus -otherwise you wouldn't be able to scan the framebuffer at all . . . though using DMA in active display is terribly inefficient in general, horribly taxing on the 68k bus for very limited bandwidth)

On the blitter/framebuffer end, there's a lot of options for getting good bandwidth on a shared bus, including Amiga/ST style interleaved accessing (slow, but still useful) and features more specific to using FPM DRAM accesses be it interleaved (via multiple banks with a DRAM controller capable of holding pages open in each bank) or on-chip phrase/line buffers to allow blocks of data to be read/written in a serial manner. (in the latter case, obviously needing the 68k to be halted some of the time -and also meaning larger ASICs to facilitate the buffers . . . so the multi-bank method alone would probably make more sense, though it still needs some added board space and pin count for the multiple banks -still sharing a common address/data bus, but each bank would need separate DRAM chips . . . though obviously it would at least make sense to use word buffers for efficient use of the 16-bit bus width)

And on the note of removing the sub-CPU, another, cheaper option for coprocessing might have been a low-cost embedded DSP. (for sound decompression/mixing, graphics decompression, and general coprocessing -ie for 3D stuff)

All the MD needed in the Mega-CD was the same deal as the PCE-CD, just a CD-ROM and the ability to stream and play sampled audio clips. The difference in cost between that and the MCD hardware we got, should have been spent on ram. Even 12megs should've been enough to future proof it and allow quality arcade ports of Neo Geo and CPS1/2 games.

RAM is expensive . . . 12 Mbits would have been too for the time . . . 8 Mbits would have really been pushing it in 1991 (even with the cost cuts of a shared bus) though not too bad by 1992. (still a major chunk of the component costs, so 4-6 Mbits would have been quite reasonable for the time)
Or, in the context of a system a bit earlier (to cut into NEC's market a bit better), 2-4 Mbits wouldn't have been bad either. (a lot more than the original PCE CD was offering and similar to the Super CD, or a hell of a lot better if 4 Mbits was used)

The MD expansion port actually only addresses up to 256 kB (2 Mbits), and anything beyond that would be bank-switched anyway . . . though doing 256k on the initial release and RAM carts offered after the fact (mapping the MD's normal cart space) would have allowed more flexibility without the trade-offs of bank-switching and initial high cost. (mass market DRAM prices hit a low in 1992 and stagnated until 1996, so any RAM expansion released by '92 wouldn't cost much different than in '95, and might actually be cheaper in '92 -though economies of scale would have an impact too)

See: http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm (and remember that raw component costs get inflated substantially by the time you get to retail with a completed product)

[Sik]

Again, even the ricoh chip was probably overkill . . . Amiga style DMA sound should have been fine (or even simpler Soundblaster/STe/Mac type sound) and should also have made streaming PCM off CD simpler. (and obviously would have been more flexible than the PCE's mono ADPCM channel -cheaper, simpler, and practical for software mixing -and software decoding of other formats)

*looks at Mega CD software* Nope, it wasn't, especially in some games. Take into account that some developers decided to use the Ricoh chip for all sound (and Audio CD), and that it's possible to use it to output all audio without having to cope with the MD side (especially important if it's doing full screen DMAs).

though the bigger issue was the limited software it got in general. (a cheaper/simpler -possibly earlier- system might have helped popularity though, and given the PCE CD's popularity, having relatively similar features would mean simpler cross-platform development

Or, you know, not making an expensive add-on that additionally required an expensive console to work (the MD was still expensive back then).

FMV wouldn't have been as good (as far as Cinepak class formats at least), but the 68k alone should have allowed for some decent compression. (at least for cutscenes . . . though in-game stuff would suffer more contention for CPU resource)

How many PCE CD games did FMV anyways? (and I mean proper FMVs, not cutscenes) The problem there was the amount of RAM though, not decompression performance.

On the VDP end, another trade-off that could have been made is removing the shadow/HL logic . . . which also may have gotten the system closer to making 12-bit RGB practical on top of the added palettes.

Using 12-bit RGB wouldn't have helped much considering the main bottleneck was the amount of available colors, and removing S/H wouldn't have added enough space to increase CRAM in a significant way. Seriously, the only way to add CRAM without removing a good chunk of the functionality or going with a more expensive chip is external CRAM.

The MD expansion port actually only addresses up to 256 kB (2 Mbits), and anything beyond that would be bank-switched anyway . . .

Um, no, both slots address up to 4MB each, in fact the MCD uses up all the address space for its slot =/

[Black_Tiger]

Um, the hardware Sega went with already has more RAM than the PCE-CD =/ 768KB should be good enough to host an individual stage, really. And that's not counting PCM's own RAM (yeah, the Ricoh chip has its own RAM too).

The PCE used system cards that they increased in size. If 2 to 6 megs was enough, then why did they make the jump to 18? Do the Arcade Card Neo Geo ports really use so little of that space?

Mega-CD games can be competitive with many types of cart games, but Neo Geo/CPS1+/arcade quality variety of art and animation would have supported more popular styles of games and ports.

I was implying that the audio would have separate ram like the PCE CD-ROM.

[kool kitty89]

The PCE used system cards that they increased in size. If 2 to 6 megs was enough, then why did they make the jump to 18? Do the Arcade Card Neo Geo ports really use so little of that space?

Mega-CD games can be competitive with many types of cart games, but Neo Geo/CPS1+/arcade quality variety of art and animation would have supported more popular styles of games and ports.

The Arcade CD didn't come until 1994 and was really expensive . . . 2/2.25 MB was a huge chunk of memory at the time. (and again, prices weren't really better than they'd been in '92)

What is odd and unfortnate though, is that NEC was so skimpy with RAM with the PCE CD (64k) and Super CD (256k) when DRAM prices would have allowed a fair bit more than that at realistic prices. (128k -if not more- should have been reasonable in '88, and 512k in '91 . . . especially with NEC's vertical integration advantage)

*looks at Mega CD software* Nope, it wasn't, especially in some games. Take into account that some developers decided to use the Ricoh chip for all sound (and Audio CD), and that it's possible to use it to output all audio without having to cope with the MD side (especially important if it's doing full screen DMAs).

Yes, but compare the value of the Ricoh chip with simpler DMA sound. (either simple mono/stereo -with software mixing for added channels/notes/etc- or Amiga-style DMA sounds with several DMA channels of variable sample rates)

And that was in the context of said hypotetical MCD having a single shared bus (rather than several additional buses on the MCD end) . . . just a block of expanded program/work RAM for the MD CPU (and VDP) to access, plus DMA sound and the CD-ROM cache/DMA interface. (though, again, there's the issue of contention in vblank that could screw things up for a Paula-like sound interface . . . except ST/Amiga style interleaved accesses should avoid such contention and be transparent to the 68k/VDP)

But, for that matter, how many games actually used the ricoh chip in a really useful manner: ie not just for SFX or drums (both among the simplest things to use software mixing for), but as a full 8 channel sampled sound/music system? (most that did seem to do that were nonlinear FMV games that couldn't use streaming audio, and a few others that did it seems to be rather pointless since streaming audio could have been used instead -for cases where CD-DA would take too much space, then streaming lower-bitrate PCM could be employed instead, but the cases where speech/soundtracks were that extensive were also relatively few and far between . . . and many FMV games using synth soundtracks used the YM2612 more than the Ricoh chip . . . or used FM exclusively -like Sewer Shark and Loadstar)

And even then, of the cases it was used rather well, how many of those would be unreasonably degraded if a simpler 8 channel Amiga-like sound circuit was used in its place? (ie 8 8-bit PCM channels with variable sample rates reading from shared DRAM, simple analog filtering, per-channel volume control, and hard-pan stereo -at least give it that over the hardwired L/R of Paula )
No oversampling, no digital filtering, no 4-bit stereo panning . . . and almost certainly using conventional signed PCM (maybe unsigned, but probably not sign-magnitude).

Or, you know, not making an expensive add-on that additionally required an expensive console to work (the MD was still expensive back then).

A. that's what I already addressed a few pots back (on how close the MCD already was to a standalone console)
B. a duo would also address the single-console aspect of that (albeit be less cost effective than a non-add-on/standalone system outright -especially given the bottlenecks of the MD/CD interfacing . . . compared to, say, the SuperGrafx, which easily could have been a cost-effective add-on for the PCE)

Or you could argue they shouldn't have released a CD unit at all due to the inherent cost issues of the time. (and the time not being right for a full successor either)
However, that would still leave a simpler, RAM/coprocessor/video enhancing add-on as a more marketable possibility. (ie more like the 32x . . . except something practical for '92/93 or earlier . . . and preferably simple enough to embed in the main system at low cost later on)

How many PCE CD games did FMV anyways? (and I mean proper FMVs, not cutscenes) The problem there was the amount of RAM though, not decompression performance.

Doing uncompressed FMV (wolf team/Sonic CD/night trap/etc style) shouldn't have been difficult, at least on the Super CD. (especially since the CPU could copy directly into VRAM rather than having to wait for vblank)

Some custom tailored compression formats may have worked OK too within the Super CD RAM limits (at least for cutscenes), especially since tile data could be written right to VRAM rather than held in a separate buffer.

Using 12-bit RGB wouldn't have helped much considering the main bottleneck was the amount of available colors, and removing S/H wouldn't have added enough space to increase CRAM in a significant way. Seriously, the only way to add CRAM without removing a good chunk of the functionality or going with a more expensive chip is external CRAM.

There's a lot of cases where 12-bit RGB should have helped too though, even with only 4 palettes.

And in the case of external CRAM vs larger ASIC, it would make a lot of sense to use external CRAM (or an entirely separate RAMDAC -more like the PCE) initially and plan to consolidate that later-on. (as larger/denser ASICs got cheap enough to be preferable over the 2-chip solution)

Um, no, both slots address up to 4MB each, in fact the MCD uses up all the address space for its slot =/

No, I wasn't talking about the block of the main 68k's memory map the expansion bus employs, but the physical address lines available on the expansion slot. (of which there are only 17, so only 128k 16-bit words addressable without bank switching)

And iirc, the cart slot actually addresses 10 MB, but 6 MB of that is reserved for other things. (4 MB being used for the MCD and 2 by the 32x)

[Sik]

Yes, but compare the value of the Ricoh chip with simpler DMA sound. (either simple mono/stereo -with software mixing for added channels/notes/etc- or Amiga-style DMA sounds with several DMA channels of variable sample rates)

The Ricoh chip isn't much different from that, really... The only difference would be that it has its own RAM, but if it was made to read from main RAM then it'd severely hurt the CPU performance (remember we'd be talking about over 250,000 accesses per second, at the sample rate the chip plays - that's like one access every 30 cycles of the MD CPU).

a few others that did it seems to be rather pointless since streaming audio could have been used instead

Except that usually doesn't play nicely with looping, especially from media like CDs where seeking carries a huge penalty =/ (and caching the end of the loop isn't very helpful since timing needs to be perfect for that to work)

simple analog filtering

The Ricoh chip doesn't provide any filtering besides the obvious one to prevent waveforms from being square waves on steroids during playback =P (i.e. inter-sample interpolation) That's probably one thing you should tick off from the list.

Or you could argue they shouldn't have released a CD unit at all due to the inherent cost issues of the time. (and the time not being right for a full successor either)

And honestly they shouldn't have =|

However, that would still leave a simpler, RAM/coprocessor/video enhancing add-on as a more marketable possibility. (ie more like the 32x . . . except something practical for '92/93 or earlier . . . and preferably simple enough to embed in the main system at low cost later on)

That would have worked just as badly as the 32X did...

If there's one thing Nintendo got right probably, is having the coprocessors in the cartridges. Granted, that made the cartridges more expensive, but at least people didn't perceive them as add-ons but rather just more software for the system.

Doing uncompressed FMV (wolf team/Sonic CD/night trap/etc style) shouldn't have been difficult, at least on the Super CD. (especially since the CPU could copy directly into VRAM rather than having to wait for vblank)

That's another problem... how do you load from CD straight into VRAM, without the data having to go through RAM?

There's a lot of cases where 12-bit RGB should have helped too though, even with only 4 palettes.

The biggest issue of "washed out colors" though comes from the lack of palettes. RGB resolution usually didn't do much in this sense, having to cram as many colors as possible into the limited palettes was more of an issue.

So yes, more CRAM would have helped a lot more than 12-bit RGB. And even then, I doubt that removing S/H would have given enough space for that... I mean, you're pretty much increasing CRAM by 1/3, and you need to add more resolution to the color DAC, which in itself probably already would take up the space freed by the S/H circuit.

No, I wasn't talking about the block of the main 68k's memory map the expansion bus employs, but the physical address lines available on the expansion slot. (of which there are only 17, so only 128k 16-bit words addressable without bank switching)

And how does the system address all 4MB there? The 68000 doesn't see any bank switching =/

And iirc, the cart slot actually addresses 10 MB, but 6 MB of that is reserved for other things. (4 MB being used for the MCD and 2 by the 32x)

Technically it can address all 16MB =P

[sheath]

As a launch Sega CD buyer I was very disappointed with the games for the first six months. I played the hell out of them anyway, but I was still very disappointed. They actually were made as though the Sega CD was just a Genesis with a CD-ROM attachment, little to no use of the Ricoh or Graphics Co-Processor occurred before Batman Returns. I literally spent hours studying the one screenshot on the back of the Sega CD box because the games didn't have anything like it.

I was a die hard Sega nut back then, if the Sega CD had ended up like the Turbo CD I would have been as pissed at Sega as the media always tells me I should be. As it stands, while it took too long to get good Sega CD titles that took advantage of the hardware in any way, we did get those and 1993-95 were years where I played and now own probably two Sega CD games for every one Genesis game, which would mean three Sega games per every one SNES title that caught my eye. In that respect, the Sega CD worked as intended and marketed on me. I would have had a SNES by 1992 in addition to a Genesis if it were not for the Sega CD, and the Sega CD had to have enhancements that made it at least arguably better in every way to what SNES games were doing.

Might argument in that debate was dropping the z80 and z80 ram. That would drop the cost much more than needed for some simple additional internal VDP 64x9bit static ram. But in the long run of things, and assuming still internal ram VS external ram for color use (as stated doable for the VDP), the cost couldn't have been.... what, maybe $5 at most? If even that high. I honestly think they felt what they had was adequate. The Genesis is already complex enough, and the 68k processor was definitely more expensive than any custom core 65x variant at the time, etc.

Also regarding the MegaCD in Japan, I do think a simple video buffer + dac output would have worked well and worth whatever additional cost. Yes, you'd still need the Genesis video processor for tilemap and/or sprite overlay (and a pass through cable setup like the 32x) - so it'd still be dependent on the Megadrive (for FM sound too). I'd say it'd be more important than the Ricoh chip (maybe a simple 2 channel ADPCM controller in its place), if costs needed to be cut. And probably get away with a cheaper cpu than the 68k sub-cpu.

If $5 is all that stood between Sega and all of the low color flack the MD/Genesis has taken over the years then it was indeed a bad decision. I just always assumed that there was some intrinsic value to the 68k+Z80 combo since many or most Arcade hardware never separated the two. Plus, without the Z80 Yuzo Koshiro would not have existed and good games would have dried up a decade earlier than they actually did.

[kool kitty89]

The Ricoh chip isn't much different from that, really... The only difference would be that it has its own RAM, but if it was made to read from main RAM then it'd severely hurt the CPU performance (remember we'd be talking about over 250,000 accesses per second, at the sample rate the chip plays - that's like one access every 30 cycles of the MD CPU).

That's the whole point of using interleaved DMA . . . not contention with the CPU. (and the MD CPu is certainly slow enough for that to work -just as it does on the ST and Amiga)

That would have worked just as badly as the 32X did...

If there's one thing Nintendo got right probably, is having the coprocessors in the cartridges. Granted, that made the cartridges more expensive, but at least people didn't perceive them as add-ons but rather just more software for the system.

Again, I generally disagree on the add-on issue. It's just that almost every add-on has either been mismanaged, poorly marketed, poorly funded, mismatched to the market at hand, and/or poorly timed.

In the 32x's case, it was mostly just poor timing, though also sheer cost, and cost to performance ratio. (there's also fitting into the market, but that's more of a timing issue)
Something similar in concept (cart slot based RAM/sound/video enhancement), but much earlier counterpart that was much more tempered for cost effectiveness (both in initial cost/price point and in terms of long-term scalability/cost reduction) along with being well marketed and managed (without major conflict between different regional branches) may very well have worked out exceptionally well.

Add-ons are inherently more efficient than embedded coprocessors (aside from extremely cheap simple coprocessors), but it's more a matter of getting consumers to truly recognize that . . . and the more trouble the add-on/module is (be it price, bulk, installation overhead, etc), the harder it will be to market (and the greater the perceived value/benefit it would need)

And on the simpler side of things, I was thinking in terms of something like an SVP lock-on cart (or similar DSP/DSP-like coprocessor+RAM set-up), perhaps with internal DACs added. (though as it is, you could do some workarounds using the Z80+DAC -ie using the DSP for mixing/etc and buffering into a 32k bank the Z80 reads from)


On that note though: had Sega added the VDP pixel/color bus, a low cost add-on with a RAMDAC could have dramatically boosted color capabilities. (like 8 palettes from 15/16/18/24-bit RGB)

That's another problem... how do you load from CD straight into VRAM, without the data having to go through RAM?

You'd have to buffer things to some extent, but you shouldn't need to buffer an entire frame's worth of data. (at least in the case of uncompressed tile data being streamed)
Lack of a CD-ROM cache/buffer makes that a bit more fiddly too.

The biggest issue of "washed out colors" though comes from the lack of palettes. RGB resolution usually didn't do much in this sense, having to cram as many colors as possible into the limited palettes was more of an issue.

Washed out colors isn't usually the issue, but more too high contrast/gaudy/ugly colors with coarse shading. (hance why some GG games have better color in some respects than similar MD games, in spite of having 1/2 the palettes)

I'd forgotten another option for enhancing palettes without increasing CRAM use:
using offets in CRAM rather than strict palettes. (and getting a lot more milage out of a limited set of indexed colors, like the Saturn, Jaguar -and Panther for that matter)
Except the way the tiles and sprites are set-up, you only get 2-bit resolution for palette selection, so you'd have a maximum of 4 steps within CRAM (unless other bits were sacrificed for added palette selection)
If you had 4-bits, that would easily facilitate 16 linear steps within 32 CRAM entries . . . or rather 16 steps within 30 CRAM entries, with 0 always being transparent. (with the offset allowing entries 0-14 up to 15-29 to be selected).

But with only 4 steps for the offset, and 32 CRAM entries used (CRAM split between tiles and sprites), you'd have to use coarser offsets instead. (like 0-14, 6-20, 11-25, 17-31)

That would take some more tactful palette optimization to use well, but it should still be a nice boost in flexibility over 4 fixed/independent palettes. (though better if it was programmable to be used as the normal 4 palettes or 2 CRAM banks with offset defined palettes)
Obviously, higher resolution offsets would be more useful, but that would require other changes to the tilemap and sprite systems.

Hmm, actually, with the exact amount of CRAM already used in the MD (ie 576 bits), that could be used as 48 12-bit entries . . . or 2 24-bit banks with 4 offsets for each. (ie 0-14, 3-17, 6-20, 9-23)
Though there's still the issue of the 4 4-bit DACs vs 3-bit. (removing S/H might have been enough to facilitate that though)
That or you could specifically use the SH/HL color functionality coupled with 11-bit CRAM (for 3-3-3-1-1 RGBSH), which would allow some 52 total CRAM entries. (or 2 banks of 26 entries each with offsets allowing 0-14, 4-18, 8-22, 11-25)

And how does the system address all 4MB there? The 68000 doesn't see any bank switching =/

I assumed the 4 MB was mirrored (like 68k work RAM is mirrored across 2 MB), but as to not seeing any bank switching, I'm not sure. (iirc Chilly Willy mentioned that word RAM could be addressed as 2 128k banks or 1 256k bank and program RAM as 2 256k banks)

In any case, it must be limited to 17-bit addressing, unless the pinout data is wrong:
http://www.gamesx.com/cartouts/gennyport.htm

[kool kitty89]

The Ricoh chip isn't much different from that, really... The only difference would be that it has its own RAM, but if it was made to read from main RAM then it'd severely hurt the CPU performance (remember we'd be talking about over 250,000 accesses per second, at the sample rate the chip plays - that's like one access every 30 cycles of the MD CPU).

What about using interleaved accesses a la ST/Amiga?

That would have worked just as badly as the 32X did...

If there's one thing Nintendo got right probably, is having the coprocessors in the cartridges. Granted, that made the cartridges more expensive, but at least people didn't perceive them as add-ons but rather just more software for the system.

Yes, except there are very few good examples of add-ons:
most were either ill-conceived, mismarketed, mismanaged, underfunded, or just a mis-match for the market at the time.

Add-ons are inherently more cost effective than embedded enhancements (aside from super simple/cheap embedded coprocessors), but it's more a matter of making consumers realize that and be willing to put up with the initial investment. (and the higher the price, greater the bulk, installation overhead, etc, the less attractive that will be)

In the 32x's specific case, it came too late and was in direct conflict with the Saturn (and also didn't really fit with the genesis's late-gen/budget market sector). However, something in a similar vein (cart-based RAM+coprocessors) could have made much more sense if done early enough to matter . . . especially with a moderate price point and design facilitating good scalability/cost reduction later on. (or, especially, a design that was efficient to embed within the base MD system itself for later models)

Say something somewhat like the MCD ASIC+word RAM and ricoh chip+RAM sans the program RAM and sub-CPU and mounted as a lock-on cart module. (or something more like the SVP+RAM -and maybe embedded audio DACs)

The biggest issue of "washed out colors" though comes from the lack of palettes. RGB resolution usually didn't do much in this sense, having to cram as many colors as possible into the limited palettes was more of an issue.

Washed out colors wasn't so much the problem as way too high contrast/poor shades.
It depends on the specific case, but there's some examples where the GG's 12-bit palette looks nicer than similar examples on the MD. (in spite of fewer colors)

Another interesting option for boosting palette efficiency would be using offsets in CRAM rather than fully segmented palettes. (like the Saturn and Jaguar used . . . and panther for that matter) ie 2 32 entry CRAM banks with offsets defining which 15 colors within that are used. (that would be nicer with a 4 or 5-bit offset to use, but 2-bits leaves that rather coarse/low res) Making it programmable as 4 palettes or 2 banks with offsets would also be nice.

Another interesting possibility, without even enhancing the color DACs, would be using 11-bit CRAM with 2 bits controlling HL/SH . . . though (without increasing CRAM) that would limit things to 52 CRAM entries . . . or 2 26 entry banks with offsets.

Also interesting to note that the Panther actually has the same amount of CRAM as the MD, but organized as 32 18-bit entries rather than 64 9-bit ones. (and using an 8-bit offset to expand 1/2/4-bit pixels, or use 8-bits for all 32 colors -zero being transparent in all cases)

And how does the system address all 4MB there? The 68000 doesn't see any bank switching =/

Not sure, but there certainly seems to be only 17 address lines:
http://www.gamesx.com/cartouts/gennyport.htm

[Kamahl]

I just always assumed that there was some intrinsic value to the 68k+Z80 combo since many or most Arcade hardware never separated the two.

The YM2612 is SLOOOOW, so there is an advantage in using that setup, frees the processor to do other things.

Plus, without the Z80 Yuzo Koshiro would not have existed and good games would have dried up a decade earlier than they actually did.

I don't see why that is.

[sheath]

Yuzo Koshiro probably doesn't even know it, but he popped into existence when the need for his Z80 based sound engine arose. The universe needed Revenge of Shinobi and Streets of Rage to sound unbelievably cool, so it came up with the Z80 driver and then Yuzo Koshiro so as not to draw too much attention.

[Kamahl]

Yuzo Koshiro probably doesn't even know it, but he popped into existence when the need for his Z80 based sound engine arose. The universe needed Revenge of Shinobi and Streets of Rage to sound unbelievably cool, so it came up with the Z80 driver and then Yuzo Koshiro so as not to draw too much attention.

Seems legit.

I still think Revenge of Shinobi has the best instruments (besides drums) on the genesis (on "china town" and "the shinobi", other songs don't sound that great).
I'd love to hear that OST with some vapor trail drums XD.