For an arcade system, having a Z80 doing nothing by managing audio made some sense (since Arcade boards tend to have relatively wide cost constraints -hence the considerable use of discrete logic, numerous buses, large boards, large/fast ROMs, etc), but doing that on a mass-market home console is more questionable. (and if it hadn't been for SMS compatibility, it really wouldn't have made any sense to do . . . except even there it's pretty questionable -especially as they didn't bother to re-use/re-map the SMS cart slot for direct compatibility rather than needing an adapter -most MD games only need 50 pins or less, so the rest could have been done more like the 7800/SNES/Jaguar/16-bit ISA/etc with outboard pins)
The later SMPS Z80 addressed the halting music issue, though still proved to be much less foolproof than its 68k counterparts (PCM playback on SMPS68k was more even in many, many cases)
68k drivers also made up some of the best sounding sound drivers on the system, like Vapor Trail's engine (also in Atomic Runner). Though that doesn't mean they were totally foolproof, as Capcom clearly demonstrated. (in that case, the distorted PCM actually seems to be caused by use of the 68k, with the 68k spending too much time accessing the Z80 bus -for PSG/YM updates- and thus inducing numerous timing errors on the Z80 -the Z80 is halted while the 68k is on its bus)
Remember, it's not just the component costs of the Z80+RAM that would go away, but also the logic needed to interface the Z80 bus with the 68k bus and the associated pins/traces added to various chips and to the board itself.
Now, in the MD's specific case, the Z80 was critical as it was the ONLY option for programmers to do any sort of PCM playback in-game, but was way overkill as a simple sound controller. (and there were aspects that made it hard to use even in that role . . . YM timer interrupts would have made timing much easier -and much less intensive than polling- and allowing the Z80 to have priority over the VDP on the 68k bus would have avoided DMA conflicts with little impact on VDP bandwidth)
A simple DMA sound circuit would have been a much, much more cost effective option (and if not embedded in a system ASIC from day 1, certainly in one of the early revisions thereafter)
There's also nothing intrinsically advantageous for the Z80+68k to be coupled either . . . and, in fact, it would probably make a lot more sense to use a 650x or 680x processor instead. (the 68k natively supports interfacing to a 650x/680x style bus, and the 650x tended to be cheaper than Z80s -and more easily licensed- while still excellent as a controller/coprocessor as such . . . and that's in the context of a 650x CPU at 1/2 the clock speed of a Z80 -at the same clock speed, the 650x would have a LOT better performance)
Atari Games standard sound CPU of choice was the 6502 for their 68000 based arcade boards. (usually controlling a YM2151 and often a PCM/ADPCM chip as well -POKEYs were often present too, though usually slaved for their timer/interrupt capabilities, sort of like what Sega did with Yamha FM chips in the Model 1 and Model 2)
A 6502 would also be particularly advantageous for the MD's case if the YM interrupt line had been connected, since 650x interrupts are exceptionally fast. (hence why they're a good option to use for PCM on the PC Engine -7 kHz playback takes only 5% CPU time with a good interrupt routine)
Yes, except there are very few good examples of add-ons: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.
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)
Had Sega added the external pixel/color bus to the cart slot, a relatively simple add-on could have included a RAMDAC to dramatically improve color (ie 8 palettes of 15/16/18/24-bit color)
Washed out colors wasn't so much the problem as way too high contrast/poor shades.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.
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)
However, going with external CRAM (or an entirely separate RAMDAC more like the PCE) would have certainly been a nice option too . . . especially with cost savings in other areas. (and should have been something able to be consolidated into later VDP ASICs fairly early in the MD's life -or at very least by the time of the VA7)
Using external CRAM (more so for a RAMDAC) would have actually reduced the VDP's chip space by a significant margin, either allowing a smaller ASIC to be used, or allowing some other functionality to be added. (I wonder how hard it would be to add simple 1/2 transparency . . . though that not only would have required adders for blending, but also wider line/pixel buffers -as wide as the output colorspace rather than the input . . . so 12-bit at least -9-bit would tend to blend so poorly that dithering would be better in almost every case . . . though, for that matter, offering simple hardware dithering -skipping drawing every other pixel- might have bee useful
Hmm, given how much space wider line/pixel buffers likely would have taken, it might have been more realistic to add hardware scaling support . . . or even just H-scaling, since leaving only v-scaling to handle in software would still speed things up a lot)
Not sure, but there certainly seems to be only 17 address lines:And how does the system address all 4MB there? The 68000 doesn't see any bank switching =/