I think you're right that a GBC like strategy for the Genesis might have worked. The Genesis was going strong in North America for awhile and probably could have pulled that off. It did well in Europe too didn't it?
AFAIK it was even bigger in Europe than in the USA, because Sega owned the market with the SMS in the 80s When you get down to it the real problem of the Genesis was it's shitty video out, you couldn't get around the color problem with chip like in the Snes because of this blottleneck One thing I don't understand is why they went with that crazy video scheme with the 32X? why not cancel the video-out from the Genesis, use 32X's instead and make the add-on use the Genesis for offloading other tasks to the 68k Another good strategy for a transition would have been making the Saturn compatible by giving it a Genesis cart slot but emulating the games to cut-down on hardware costs. I remember a few years ago some guys were trying to port the DC Genesis emu to Saturn and had a lot of troubles getting it to run full-speed, but my guess is a dedicated engineering team working full time would have been able to do it, so the Saturn would have launched with a Genesis emu on a CD: pop the lid, boot to the emu, insert the cart and play I think at the end the problem is that both Sega and Nintendo were selling tons of gimmicky shit, but the difference is Nintendo realized they were going too far and decided to cut down on it, while Sega kept going.
Hey, the biannual Neptune thread is already here. Few months ago i found a blog from a guy who is recreating the neptune top shell and indeed using the Megadrive 2 bottom for it. http://www.porlzilla.com/2012/04/quick-neptune-case-update.html
The only way to solve the colors issue would be bypassing the Genesis' video out and give the SegaCD one of its own
The Genesis was doing well in America and Europe, but was not doing well in Japan, which I guess is the reason they were more interested in add-ons (SegaCD to compete with NEC, for example, since PC Engine was doing better business than the Megadrive). Sega of Japan actually wanted to announce an upgraded Genesis with more colors at a trade event in America, but Sega of America actually fought hard to prevent that and ended convincing Japan of turning that into an add-on. It was the best choice between two bad choices. An upgraded Genesis would divide the userbase and would not add anything really new, and it was already doing well on sales here and in Europe. Plus, they know the 16 bit market was very much alive, and was going to last more years, even with the Saturn being so close to release. At the end, America designed the hardware and Japan was supposed to provide the software, which to be honest, they did not deliver in either quantity or quality (Virtua Racing and Fighter being the exception I feel). Developers choose to focus on the Saturn, and Sega of Japan, still in a hurry to leave the Megadrive in the past, pretty much killed software support for the still active 16 bit market, missing significant sales in America en Europe, since consumers were not ready to jump to a new expensive plataform yet. So yeah, a Genesis with more colors was in the cards. One bit of gossip that even EGM got right (they called it "the Super Genesis", I think) For years I thought that rumor was just wishful thinking.
I'm not aware of the technical design of the Genesis, but if you could DMA to the cartridge bus, as I'm sure you could DMA from so why not to, I don't see any reason why actually having a new VDP/replacement wouldn't work there. Although you would still need to do the 32X's tapping the console VDP signal since old games wouldn't be programmed to use the new VDP. But they could have done something like that I suppose. And while you're at it then you could add sound expansion and more work ram if you wanted. The 32X was too late and tried to do too much and couldn't deliver, or atleast didn't deliver. The Sega CD could have done this. Yes the scaling feature it had I guess was neat but it did not equal the possible improvement to all parts of a game by having more colors available at once. The scaling rotating is just an effect that can only be used for certain things. You didn't need or could benefit from it like you could having more color palettes.
I wonder if the SCD actually could display more colors without any special VDPs but it was limited by the Genesis a/v out alone If thats the case then fuck! I remember the consensus was that Sega wanted the SCD to support more colors but the extra chips made it way more expensive.
Ofcourse it can't. The Sega CD *could* have been designed to fix the color problem. But the way it was designed it doesn't and can't. First off, there is no getting around it, you have to have a 32X style Video cable. The Genesis VDP video RGB signal isn't available anywhere but the AV port. I'm pretty sure you'd have to do it like I suggested earlier, you'd need to have circuitry to take both the Genesis VDP signal and a new VDP signal and be able to switch between them in software, but by default have the Genesis VDP enabled to maintain backwards compatibility. Although with more thinking I'm not so sure you could use DMA (which is critical) to a VDP on the cartridge bus. The DMA controller probably connects directly to the VRAM chip. I think you'd be able to get around it by adding a DMA controller in the new VDP on the cartridge bus that could DMA between newly mapped RAM in the new VDP available to the CPU. But then I don't know about the cartridge ROM which would be an issue. I'm not extremely hardware savvy but if such details could be worked out, then you could 32X style upgrade the system. But it may be that going SuperGrafx style would have been the way to go if a plug in upgrade just isn't feasible.
The SegaCD didn't really add anything to the Mega Drive hardware in terms of graphics. The scaling hardware was designed to assist in generating rotated graphics tiles, but that's all it added on the graphics front. Apart from that, it was just really the PCM chip and the CD drive itself that it added in terms of new features, with of course the word ram being useful. The 32x is what improved the graphical capabilities. In terms of the Mega Drive itself, the VDP hardware supported an external colour palette, but the Mega Drive didn't provide one. Potentially, you could increase the colour depth from 9-bit (512 colours) to 12-bit (4096 colours) with very little additional hardware by adding an external colour palette. Games could have been written to work with the extended colour palette, with the VDP automatically dropping the colour depth to 9-bit on older hardware without the extended colour palette. You'd still be limited to a 4x16 colour palette, but the increased colour depth would have been useful. I think it highly likely that a "Mega Drive 3" or the like would have added this extended palette if the 16-bit era had lasted a few more years.
Don't forget the Sega CD added a second 68000 cpu clocked at a higher speed. All the things it did do added to its already high cost. I think the PC-Engine handled the CD-ROM add-on better by going a bit more bare bones. I do believe it did add a ADPCM/voice channel, but other than that just CD-ROM interface with a system card. Sega CD having the scaling rotating graphics bit, second 68000 cpu, and built in/non-expandable memory were all kind of bad things. While they did put the scaling and the second 68000 cpu to use in some games, the mass storage and redbook audio combined with a VDP improvement on colors and sprites on screen would have been better in my opinion.
While in theory it's true that the MegaCD adds a second M68000, the reality is the usefulness of that processor is severely limited. The second M68000 in the MegaCD is there to drive the CD system itself, not to add processing power for games. If you actually use the CD drive, that processor will spend a lot of its time running the MegaCD sub-cpu bios and your own sub-cpu loader, responding to drive seek/read requests and handling interrupts from the drive. That processor is also virtually sandboxed from the rest of the system. It can't talk directly to any hardware that's not actually in the MegaCD itself. The M68000 processor in the Mega Drive has to communicate with it through communication flags or the word RAM, and the sub-cpu can't generate any kind of interrupt event for the main CPU, so if the Mega Drive wanted to use the sub-cpu to accelerate processing, it would have to spin around polling for when the work has been completed. I'm sure the sub-cpu could be used to acclerate processing in particular situations, but it would be hard to make use of, and may actually end up being slower if the data has to be shuffled from work-ram to some other device, like the VDP. Sega didn't intend the sub-cpu to be used in this way, but rather, it's simply there to drive and load data from the CD-ROM, so that the ADPCM chip and CD drive could be used without the M68000 in the Mega Drive having to spend any extra time to handle them.
That was a very well explained and technical post, theres no way I could enter a tech discussion here, but are you really sure the M68K was intended just for that? A lot of devs over on Sega-16 have suggested the Sega/Mega-CD M68k is far more useful than that, and I'm quite sure a lot of games use it more than just for streaming PCM samples and Redbook audio. If they really wanted to offload CD-ROM duties from the Megadrives main M68K, the SEGA/MEGA-CD's 68K is absoloute overkill, a cheap MCU chip could have been used in its place. I think Sega really intended the Mega-CD to be a full system upgrade rather than just a simple Media delivery upgrade path. There was a lot of rumour and discussion in gaming magazines before the Sega-Cd's release of some other video interface chips perhaps another VDP that could handle more colours, that where removed due to cost concerns. Also how does the PC-Engines single CPU handle the cd-rom drive, if the overhead of dealing with a CD-ROM drive is so high that Megadrive had to have an entire M68K clocked higher than the megadrives own processor? No doubt the MEGA-CD M68K deals with CD-ROM housekeeping but its not that CPU intensive. I doubt it was intended to be just a glorified redbook player. I'm happy to be corrected of course.
That is a good point that the main cpu is what is hooked up to important devices (joypads, z80 cpu, VDP) and the second 68000 doesn't have access to them directly. I'm not sure about how limited or messed up the setup is but I do recall reading that the faster 68000 has 512kb of memory to itself. And then there is 256kb of memory shared with the main cpu. That certainly seems backwards if the main cpu is doing most of the work. Ofcourse in general I think having two cpus at all like that seems rather silly. As TVC stated the PC-Engine and its CDROM didn't need to shoehorn a second processor. I don't think you need a second CPU to worry about reading from the drive, the only way that does make sense is for the really shitty FMV games. In that case it makes sense to have the second 68000 constantly getting more frame data for the terrible movie games. Such a waste.
I'm not sure of the original intent of the hardware designers. It is possible that they planned the MegaCD hardware to provide many more features than the final product added. I do know a lot about the Mega Drive hardware though, and what I can see from the final design is that the M68000 processor in the MegaCD, while in theory being a fast and powerful processor, has a lot of barriers in the way of making effective use of it. There is definitely spare time available on that processor which could be spent doing other work, but the number of "hoops" you have to jump through in order to effectively offload that work to the processor and read the results back, then pass them on to some other component in the system, means there's a fairly large overhead in trying to use it in this manner. Basically, all I'm saying, is you'd really really have to need the extra processing power in order to even bother trying to leverage it. The biggest problem the hardware designers would have faced when building the MegaCD addon is the fact that there's no way for an external addon device to the Mega Drive to generate any interrupts for the main CPU, since the interrupt lines are never exposed over either the cartridge connector or expansion port. If interrupts had been provided, it would have been possible to do without adding another CPU, and run everything from the existing M68000 CPU. Without interrupt support however, they absolutely would have needed a second processor, otherwise the existing M68000 processor would have had to spend almost all its time polling the CD hardware for data just in order to prevent choppy audio playback, leaving it with no time to do anything else. Not knowing anything about the PC-Engine, I'd say that console didn't have this design limitation. The MegaCD designers might have chosen an M68000 CPU for the task instead of the alternatives simply because it was a processor which both they, and other developers for the Mega Drive, were already familiar with and already had development tools to support. Introducing a different architecture of processor for the MegaCD would have meant there were now 3 different architectures being employed (M68000, Z80, and something else), which is not something they would have wanted, since it would have driven away developers. The Z80 was only really there in the first place to provide backwards compatibility with the Master System. In fact, a lot of the worst design points with the Mega Drive hardware came as a consequence of the Master System hardware backwards compatibility (and the same goes for every other system that's attempted hardware-level backwards compatibility since). There's 512KB of program memory available to the MegaCD 68000, true, but that's partially used by the CD bios before you load any code, and then that's effectively all you have to use for program space and RAM. Admittedly though, in reality, this does still leave a lot of free space. Why did the hardware designers provide so much memory internally in the MegaCD? I have no idea. It would have been far better to make the word RAM 512KB, and the program RAM 256KB. When you're loading purely from a CD, with no cartridge, like every MegaCD game does, the 256KB of shared word-ram memory is the only buffer space you have to load anything into in order to send to the rest of the system, including code for the M68000 processor in the Mega Drive, and any data you want to load. It would have been much better to increase the size of the word RAM, and leave a smaller program RAM space. Ideally, we'd have a 1MB word-ram buffer. As it is, a lot of MegaCD games suffer graphically simply because they can't buffer enough graphical data, and you can't load it on the fly without interrupting audio playback. Agreed. The real design flaw was with the original Mega Drive hardware though, not exposing interrupt lines over the expansion port. There were free pins available on the connector, and it would have been relatively easy to do too, so it's a real shame they didn't do it. It would have given the MegaCD hardware designers a lot more options. Exposing the bus request/grant lines would have been extremely useful too, although the expansion connector would have also needed all the address lines to make proper use of that. Still, we're only talking about a few extra traces on the board and at most, a handful of extra pins on the expansion connector. It would have cost virtually nothing.
Well everything you are saying seems to fit a pattern of dumb choices. =) I definitely wonder why they gave the second CPU the bigger chunk of RAM. Clearly the main CPU needed it more. I do wonder what you mean about choppy audio playback. Are you talking about the added sound channel or redbook audio playback? I'd think that playing the redbook audio would just be a matter of sending CD player type commands. Either way I guess they were under various constraints and somehow made the monster they did. I don't know how anyone couldn't have forseen the need for as much memory as possible to the "game processor" when playing games off a CD-ROM compared to a cartridge ROM.
I don't think you can play redbook audio on either Sega CD or Saturn and load data at the same time. However other formats of audio might support buffering. I would imagine that Sega CD FMV games have something like that. Infact I wonder if the reason that the second 68000 gets 512kb of RAM is related to FMV games. If this is so, what a tragic miss-allocation of resources. They really should have given the shared RAM area the bigger chunk of RAM.
