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

[kool kitty89]

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

Yes, but it's not enough of a hassle to merit the cost of a Z80+RAM just to act as a sound controller . . . if it wasn't for the PCM issue (ie if they'd just added a simple DMA sound circuit -say something like the Mac had), using the 68k to manage the sound registers should have been perfectly fine.

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)

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.

Except Revenge of Shinobi was one of the earliest games to use the 68k based pre-SMPS engine rather than Z80 . . . the early Z80 drivers had to halt music to play PCM (like Golden Axe, Space Harrier II, and Altered Beast), but the 68k drivers had the 68k handling all the FM/PSG updates and the Z80 being slaved as a glorified PCM circuit.
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)

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.

Arcade hardware is well known for doing lots of things that are way overkill for modest performance gains (relative to added cost/complexity). Many, many things that sane, mass market home console designs wouldn't do in a million years. (like the Neo Geo's massive multi-bus carts with massive amounts of ROM employed)

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)

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)

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)

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)

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)

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

[Sik]

Yuzo Koshiro probably doesn't even know it, but he popped into existence when the need for his Z80 based sound engine arose.

Except he isn't a programmer...

[TmEE]

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

That is only for comms between 2 sides

[sheath]

Except he isn't a programmer...

I was going exclusively on this, if that's not true then I will post the scanners pic again.

http://archive.videogamesdaily.com/f...v_oct05_p2.asp

Kikizo: What sort of programming languages did those consoles use for the music programs?
Koshiro: For Bare Knuckle specifically, I used the NEC PC-88 computer and an original programming language I developed myself. The original was called MML, Music Macro Language. It's based on the NEC's basic program, but I modified it heavily. It was more a BASIC-style language at first, but I modified it to be something more like Assembly. I called it "Music Love." [laughs] I used it for all the Bare Knuckle Games.

Kikizo: Did you use it for SFC games, as well?
Koshiro: No, I couldn't. The language used in the SFC was completely different. The chip was a Sony sound chip, and the system used for music programming was called NEWS (?), based on a UNIX system. Some company made a special system for it, so I just input the scores I had composed into it. "

[Chilly Willy]

The memory map for the MCD depends on which CPU you are talking about. If you are talking about the 68000 in the MD, the expansion port only addresses 128 KWords, with three regions that can be accessed. One is the word ram, which appears to the MD as a block of 256KB, or a block of 128KB. The Program ram always appears to the MD as four banks of 128KB. The last region is of course the hardware registers. So the MCD program ram is the only bank selected memory as far as the MD 68000 is concerned.

To the MCD 68000, none of the regions are bank selected since the memory and hardware is all directly connected to the CPU. However, NOTHING inside the MD appears to the MCD 68000 - not the MD work ram, not the cart, not even the CD BIOS! The MD 68000 runs the CD BIOS, copies the code the CD needs into the CD program ram, then allows the CD CPU to run from that copied code.

[kool kitty89]

Thinking about Sik's comments about Sega being better off without add-ons (a topic which has obviously come up before -there's at least 1 long-winded thread dedicated to those issues MCD and 32x on Sega-16 . . . not to mention off-topic tangents in other threads) . . . but one thing that isn't pointed out that often is this:
no add-ons (or only very simple/logical add-ons -that fit/integrate well with the base hardware) would mean much more flexibility (and likelihood) for a backwards compatible successor/next-gen console . . . but the MCD alone throws a ton of problems into that. (especially with the large number of separate buses the MD+MCD employ -ie difficult to consolidate/scale, unlike chips shading a common bus -the fewer buses, the more you can later cram into the same ASIC with fewer pins -you could do a single ASIC in either case, but a shared bus means removing many, many more pins/traces with such consolidation vs retaining many separate buses connected to said ASIC)

A very simple/basic CD-add-on, closer to what NEC did, (while still naturally expensive) would avoid most such foreward compatibility issues . . . as would simple RAM expansion, or external RAMDACs (had Sega added those VDP lines to the cart slot or exp port). And in that respect, a fairly general purpose DSP coprocessor probably would have worked fairly well too. (something that could be cheap to embed, yet potentially useful as a component in the next-gen followup)

Albeit, with the design route Sega took with the existing Saturn, this argument is rather moot. (since the Saturn has even more buses than the MD+MCD . . . or even with the 32x on top of that)

[Sik]

no add-ons (or only very simple/logical add-ons -that fit/integrate well with the base hardware) would mean much more flexibility (and likelihood) for a backwards compatible successor/next-gen console . . . but the MCD alone throws a ton of problems into that.

Or just leave the expansion slot and keep treating the MCD as a separate add-on =P Although yeah, removing support for even that would have already reduced the complexity of the PCB (probably not much, but it's still something)

And in that respect, a fairly general purpose DSP coprocessor probably would have worked fairly well too. (something that could be cheap to embed, yet potentially useful as a component in the next-gen followup)

I think this is what Sega tried to do with the SVP, but we know how that ended up... Guess Nintendo had it easier (then again, they were doing it from the very beginning, since they removed one important part of the SNES late in development and it had to be readded as a DSP in the Pilotwings cartridge to prevent it from getting delayed too much).

[kool kitty89]

I think this is what Sega tried to do with the SVP, but we know how that ended up... Guess Nintendo had it easier (then again, they were doing it from the very beginning, since they removed one important part of the SNES late in development and it had to be readded as a DSP in the Pilotwings cartridge to prevent it from getting delayed too much).

Yes, but the SVP was way too late . . . I was thinking more ~1992/93 (if not earlier) with a DSP (or other useful math/logic coprocessor), added RAM (probably DRAM with an embedded controller), and maybe a DMA sound circuit of some type. (and perhaps a RAMDAC if Sega had included those VDP lines on the cart slot -or expansion port . . . and beyond enhanced palettes, a bit more could be pushed than that, like pixel accumulation support for 1/2 res 8bpp modes -quite useful for software/coprocessor rendering and a few other things)

Though to really make an external RAMDAC attractive, you'd also want analog RGB lines on the cart slot (and/or expansion port) to avoid the cost/clumsiness of external mixing cables (and video encoders, RF modulators, etc).


That, and the context that there was no MCD, and with long-term support/viability in mind. (including potential design considerations for a next-gen console with backwards compatibility -depending on the specific coprocessor in question, it may have been useful in the next-gen system for 3D math and/or sound processing/etc -especially if an enhanced derivative were used with boosted clock speed, larger scratchpad, added instructions, etc)

If said coprocessor was custom/in-house, that would further save on cost (cost/royalties for licensed/off the shelf hardware) and have potentially more flexibility over extending the features/architecture. (Flare did that with the DSP in the splipstream and the -far more advanced/impressive, and CPU-like- RISC core used in the Jaguar's GPU and DSP, and of course Nintendo/Argonaut did that with the Super FX chip -actually engineered by Ben Cheese, who also did the Slipstream DSP, though he wasn't directly involved in the Jaguar's design -that was mainly done by the other 2 original Flare members: John Mathieson and Martin Brennan)

Granted, some licensed designs can be very cheap/attractive too (like the 650x chips), and doing that can still include custom/in-house additions/enhancements/tweaks. (and certain off the shelf parts that might be negotiated for exceptionally attractive prices . . . )

From that perspective an SH1 may have been pretty attractive for the 1993 timeframe . . . available by late 1992 (at least in limited quantities -so enough for prototyping and initial dev units) and very low-cost optimized fast chip with embedded DRAM controller . . . though no cache, so careful coding to make good use of the scratchpad would be necessary for good performance.


And, on the issue of DRAM, again, mass-market bulk (average) RAM prices hit a low in 1992 (for then-common 1 and 4 Mbit densities) and stagnated until 1996. (actually moderately increasing in cost into 1995)
So, any add-on released in '92/93, would have similar DRAM costs as one in '94/95. (aside from very fast/exotic RAM, which wouldn't be represented by the mass-market averages -ie commodity FPM DRAM, with EDO DRAM still being rather niche/high end in the early 90s let alone SDRAM -or specialized things like VRAM, PSRAM -ie, fast/high end RAM would be much more expensive in '92 than the average, but -unlike the mass market chips- should still be dropping in price significantly from '92-95 -with EDO DRAM falling into the mainstream/mid-range by the tail-end of that period) And, of course, Sega had a good relationship with Hitachi.

http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm



Hmm, in the context of the 1988 MD (as-is), but with no MCD or other add-ons up to ~1993:
perhaps something like 2 64kx16-bit DRAM chips (as 256 kB on a 32-bit bus) with an SH1, plus a small ASIC to handle the interfacing to the MD bus and DMA sound would have been a nice option. Maybe even mounted on the expansion port, but the cart slot would be much more flexible (SH1+ASIC could directly access cart ROM).
A simple, relatively low-cost embedded add-on with considerable performance and also a fair amount of possibilities for working into a full successor. (preferably in a more useful role than the SH1 in the Saturn )

And, obviously, a RAMDAC (or a bit more -ie 8bpp modes, etc) would be extremely attractive in addition to that if Sega had added the necessary lines. (or, don't release such a powerful add-on at all, but an simpler DRAM+RAMDAC+DMA sound add-on around 1991/92, and possibly embedding that as standard in later models . . . maybe a really simple embedded DSP on top of that -like the cheap off the shelf NEC parts Nintendo was using for their DSP-1 chips, or the rather simplistic/limited Flare DSP, or just a fast 16-bit multiply unit)

[Sik]

Yes, but the SVP was way too late . . .

It was made to compete against the SuperFX technically, and nothing else =/ Virtua Racing is pretty much the only MD game that needs help from a coprocessor (add-ons aside), the main reason for coprocessors in SNES games is that developers didn't trust the 65816 to be fast enough to do anything complex (yet they didn't seem to have issues with the 68000?).

[Kamahl]

the main reason for coprocessors in SNES games is that developers didn't trust the 65816 to be fast enough to do anything complex (yet they didn't seem to have issues with the 68000?).

Dude, need I remind you that the genesis has a Model 5 Blast Processing(TM) EX chip inside? No need for addon chips.

[Sik]

Dude, need I remind you that the genesis has a Model 5 Blast Processing(TM) EX chip inside? No need for addon chips.

Sadly, the Blast Processing chip was never used by developers, out of fear to accidentally cause a natural disaster due to a silly bug in a game. Remember that quake in Washington not long ago? Somebody reported the earthquake started right when he reached the part where Marble Garden 2 started crumbling apart. Looks like there was some unused rumble feature in Sonic 3 that was probably disabled out of safety concerns, but somehow it got accidentally enabled by some unusual bug.

(EDIT: yes, the report was real...)

[Kamahl]

Those are all excuses, developers simply didn't understand how to use it. Well, it's understandable, 782 registers is a bit too much. Specially when you have registers like BLSTRNDR which writes to another random register, and it's the only way to write to half of the registers, one of which is BLSTCBST which causes the genesis to spontaneously combust.

[sheath]

I can't believe you yahoos actually believe in the blast processor. Really people, don't believe everything you read. Don't you know that Nintendo started that rumor in a fake editorial? Yeesh, I'd think all of you code heads would know whether or not an entire processor existed. This makes me doubt that any of you even exist.

[Kamahl]

Tell that to my spontaneously combusted mega drive.

[sheath]

Hah, how'd that happen? I might have just killed a client's cruddy Acer laptop while trying to replace the power jack (pads came out too).