The origins of Sega's Model 2 arcade board, and, an interview with Real3D

[zyrobs]

I see. So the LaserActive Mega LD PAC had all the full components of Mega Drive.

Could it be that in 1993-1994, there simply wasn't an binary(in this case a MD software kit) or bios solution for Mega Drive ROMs to be readable on Sega's System 32 and System 24 parts or on the SH-2?

They are entirely different systems and the Saturn wasn't powerful enough to emulate them. Different software architecture, different memory mapping, different video hardware, different audio hardware, etc. They'd have to do something like dynamically translate every cpu instruction, memory operation, video operation, etc, for Saturn specific counterparts... if it had any such thing. That just wasn't suitable on such old hardware. About the only thing the Saturn actually emulated (or so they say) was a few MSX games in the Konami Antique Collection.

The Saturn didn't have System 24/32 parts, it had the VDP1 and VDP2, which share some similarities to System 32 video hardware in their internals - according to emulator authors who worked on reverse engineering them. Charles MacDonald and Haze talked about that I believe. It is entirely likely that either the same team worked on the Saturn and System32 hardware, or that the System32 video hardware was the direct ancestor of the Saturn video hardware, tweaked, enhanced, made more cost effective, etc.

I believe the line descended from the Sega arcade sprite crunchers: Space Harrier -> Out Run -> X Board (Afterburner) -> Y Board (Galaxy Force) -> System 32 -> Saturn.
However this is just a theory, and I don't have the necessary knowledge to compare the inner workings of each machine.

However this is made easier since the Xbox and 360 are based on PC architecture.

Only the original Xbox used x86, and that's one of the reasons why it is difficult to emulate. The 360 used PowerPC, a different architecture. They actually had to build emulators preconfigured for each Xbox game, similar to how playstation and n64 emulators require constant per-game setups.

[MrSega]

They are entirely different systems and the Saturn wasn't powerful enough to emulate them. Different software architecture, different memory mapping, different video hardware, different audio hardware, etc. They'd have to do something like dynamically translate every cpu instruction, memory operation, video operation, etc, for Saturn specific counterparts... if it had any such thing. That just wasn't suitable on such old hardware. About the only thing the Saturn actually emulated (or so they say) was a few MSX games in the Konami Antique Collection.

The Saturn didn't have System 24/32 parts, it had the VDP1 and VDP2, which share some similarities to System 32 video hardware in their internals - according to emulator authors who worked on reverse engineering them. Charles MacDonald and Haze talked about that I believe. It is entirely likely that either the same team worked on the Saturn and System32 hardware, or that the System32 video hardware was the direct ancestor of the Saturn video hardware, tweaked, enhanced, made more cost effective, etc.

I believe the line descended from the Sega arcade sprite crunchers: Space Harrier -> Out Run -> X Board (Afterburner) -> Y Board (Galaxy Force) -> System 32 -> Saturn.
However this is just a theory, and I don't have the necessary knowledge to compare the inner workings of each machine.


Only the original Xbox used x86, and that's one of the reasons why it is difficult to emulate. The 360 used PowerPC, a different architecture. They actually had to build emulators preconfigured for each Xbox game, similar to how playstation and n64 emulators require constant per-game setups.

Which makes since regarding the set up of Saturn's VDPs because according to Sega Retro, they had simliar assembly instructions as both the architecture to System 24 and System 32. I was asking if since they did would the SH-2 be capable of reading the coding of Mega Drive ROMs.

I've often assumed, in order to design Sonic Jam, Sonic Team just built their own emulator from the ground up using the video data and MPEG files encoded in Saturn's hardware. Though, now I'm not entirely sure what option they had.

From what it sounds like, SEGA designed the RISC set to differ completely from its older CPU lines.

[zyrobs]

Of course they could read the ROMs. Notepad can read ROMs. But they can't run any of the code in them.

Sonic Jam was recoded from the ground up. No emulation.

using the video data and MPEG files encoded in Saturn's hardware

What the hell.

From what it sounds like, SEGA designed the RISC set to differ completely from its older CPU lines.

Sega didn't design CPUs. They used Motorola, NEC, Hitachi, Zilog, etc. off the shelf CPUs.

What they designed, and what put them ahead of the competition, was unique video hardware.

[parallaxscroll]

By the time System 32 debuted in 1992, its tech just wasn't powerful enough to justify a powerhouse console. SEGA probably wasn't entirely sure what Nintendo's project Reality would entail, I believe even in Spring 1993, SEGA probably figured Reality would be a step ahead of NEC Turbo Force/PCFX. Did they seriously believe that by 1994, System 32's tech would still be viable? I don't think we'll ever be sure.

Sega's System 32 board was almost certainly completed in 1990, because the first game to use it, Rad Mobile, came out in the first half of 1991.

Is it also possible, that Mars would have never seen light of day had Model 3 been developed in 1993? I believe so. Model 3's development itself came in 1994, and SEGA already had finished Saturn.

Not sure exactly when Model 3 development began (probably 1994) but it was supposed to arrive sometime around mid-late 1995. It suffered from delays. Model 3 and a demo of VF3 was first shown in early 1996. VF3 was not released in Japanese arcades until late summer or fall 1996.

[kool kitty89]

A more powerful, more user friendly 32x, with good support and a long lifeline, would've been a viable upgrade path on it's own. On it's own. Not next to the Saturn.

Yeah, except, it would have made much more sense to design a NEW system with MD and CD backwards compatibility and optimize use of old hardware efficiently rather than tacking stuff on. (and a 1x CD limitation) Without the MCD, there's more logic to this, but even then the trade-offs are bad. (a standalone MD compatible console could have better enhanced old hardware to maximize overall system cost effectiveness)
An add-on of that caliber just didn't make sense, no matter how many provisions were added for expansion. (it's similar to the threshold for a PC where you'd want to upgrade the whole motherboard and CPU and graphics card and RAM rather than adding on to an old system -trade-offs vary by motherboard and CPU platforms in general, but the similar would apply to consoles, except generally more constrained and fixed due to the nature of the consumer market they cater to)

The Saturn wasn't designed with any of that in mind, it was a fresh start (a design choice which has its own merits), and the whole topic of backwards compatible designs is an argument of its own. Albeit, given the complexity of the actual Saturn, some of that "clean all new design" advantage is kind of missing compared to alternatives including backwards compatibility. (cost effectiveness being one of the biggest arguments for dropping compatibility) Actually, the overall complexity of the Saturn kind of compromised 2 major advantages of an incompatible new design: cost effectiveness of a streamlined system (no hold from compatibility) AND easier programming from streamlined, unified hardware. (granted, newer hardware was fundamentally going to increase in complexity, but considering the practical possibilities for a cost-effective Saturn-competitive MD-compatible console, there seems to be a lot that would have reasonably matched cost/performance and programmability overall -from a practical standpoint, if not a raw, ideal technical one)

And in the context of wanting simultaneous release of high and low end next-gen hardware, dropping CD wasn't as good of an option as offering a stripped-down next-gen CD system and a high-end counterpart that the former could be upgraded to . . . that, or just start with the cheaper one and later introduce upgrades (and integrate those into later models). RAM would be the most practical to target. (and something that modern consoles neglect to offer expansion for, but it really is the key element for any mass-storage based platform . . . even many "closed architecture" home computers have at least offered RAM expansion, even if CPU and graphics were non-upgradable -and in cases where no 1st party RAM expansion exited, 3rd party RAM upgrade options were often among the first and most significant expansion options available)

But the Saturn doesn't need all of those fast ram expansions. It had the VDP2 external background pins mapped to the cart. That means it was invincible. It could have a Xbox on-a-cart plugged into it, sending digital video feed directly into the machine.

Except that sort of expansion is pointless and extremely impractical. What you want expansion support to be optimized for is adding things that offer significant performance boost at relatively modest cost and produce a minimum of waste with existing system hardware. RAM upgrades and specific coprocessors that fill niches of specific system bottlenecks would apply here. A full GPU upgrade on the Saturn would be pretty wasteful and costly . . . and RAM expansion would be the most useful, both main RAM and graphics. (having more VDP1 texture RAM is great, especially at full-speed -which historical RAM carts did NOT do . . . I'm pretty sure they also had to copy into texture RAM and couldn't be directly addressed by VDP1, but I forget exactly how bus B is configured)

Again, there comes a point where a distinct new system simply becomes more attractive, and that both goes for cost and complexity -the latter affecting programming and cost, again.
The PC Engine, for example, easily could have had Super Grafx as an add-on, as stated above, and wouldn't have made any cost compromises. (hence the SGX NOT being an add-on was rather silly)
OTOH, something as complex as the PC-FX, while mostly possible as a PCE add-on, would have been so costly and cumbersome that it simply wouldn't have made sense to do as such. (price difference between add-on and all-in-one unit being too similar . . . dropping PCE compatibility was rather silly though - the HC6280 CPU is all that's missing -the 128 kB VRAM for each VDP also couldn't have been done as an add-on, since the base VDP has no RAM expansion lines connected to the exp port . . . could have 128k for one and 64k for the other, though)

The MD on the other hand, was missing tons of things. VDP had a 128k VRAM mode, external palette input, both unused. And it had no viable upgrade path either

True, but adding VRAM expansion would have been another ~30 some pins on the expansion port, and 10 pins for the digital pixel bus. The latter CAN be used for external color expansion, but it's not "external palette input" as such, but a pixel bus that can be fed into an external RAMDAC (containing CRAM and video DACs), and with the MD VDP's existing CRAM format used, there's provisions for up to 8 15 color palettes of up to 12-bit color depth, going beyond that would mean more complex added hardware to the external RAMDAC chip, which would be possible but more expensive, and more difficult to integrate later-on.

With the added VRAM expansion, that too would give some interesting possibilities, including configuring multiple 64kB banks of added VRAM and potentially eliminating the DMA conflicts for VRAM updates.
However, you'd retain some of the bottlenecks that limited ASIC rendering and FMV quality, namely the 15 color per character problem, and 4 palettes for BG. (so the only color imporvements for FMV cutscenes would be 12 bit over 9-bit) You'd still need a 2nd VDP with higher color pixel support to go beyond that . . . and designing the ASIC around rendering to THAT instead of the MD tiles could have boosted performance there too (linear framebuffer vs tile rendering). That's something that's possible with or without added expansion, but including the external pixel bus would have made it cheap to add that AND expand the base MD VDP color too. (add the extended CRAM into the framebuffer VDP and have the MD graphics mixed digitally with the framebuffer -also more priority control potential with the pixel data flags over analog mixing-)

That-said, there's still a strong argument that the lack of expansion didn't strangle things that much, since opting for a separate new platform STILL has advantages over expansion when you get to something that elaborate, or as elaborate as the existing MCD. There's always going to be a big chunk of the hardware that's not going to be expandable, and always attractions to an enhanced backeards-compatible design over an add-on (aside from a totally new and distinct design). Things like using a faster 68k and Z80, fixing a few internal flaws/quirks of the internal system (lack of Z80 timer interrupts, limited priority control over the 68k bus, etc) that would have merited a non-addon style approach.

If Sega had wanted something more on par with the PCE CD or Super CD, that would have made sense as an add-on, and including the pixel bus there could have helped. (external RAMDAC not being too costly) But with all the stuff they DID cram into the MCD, Sega was going in a different direction overall.

- the extension port was literally a floppy connector (it is even marked as son on the schematics!), and there wasn't a proper way to mix in the Sega CD and 32x a/v either, without extra cables.

It's not a floppy connector . . . it's a general purpose parallel expansion port similar to the cart slot (but missing some of the address lines and adding a couple other signals). The cart slot is the best expansion port on the MD, though.

And Sega easily could have added a 32x-style framebuffer to the CD . . . it would have added to cost (though they could have cut other things to facilitate that). Having the pixel bus there wouldn't have cut costs too much (analog genlock vs digital pixel mixing), but it would have added more potential for features beyond what the 32x VDP could do. (expand the MD VDP palette and have priority control at the sprite/BG layer level rather than just the MD and 32x layers)

Similarly, they could have added other types of VDPs than the 32x set-up too. (something like the Object Processor Atari was developing for the Saturn would have been interesting -powerful and flexible scaled sprite engine capable of scanning a framebuffer as a sprite)

[kool kitty89]

How would Jupiter not have problems being compatible with Genesis cartridges if all it is is a Saturn with no CD-ROM drive? It would still have the massive issue of not having any Genesis hardware to use for compatibility. At that point your looking into needing an adapter with the Genesis hardware built in, which could have been done on the Saturn just as easily.

No, there wouldn't be compatibility, but that's the nature of the Saturn chipset . . . had Sega designed the Saturn around compatibility, the Jupiter would have basically been like a Neptune (form factor and compatibility wise) but a hell of a lot more powerful and Saturn-compatible.
That wasn't an option by 1994 though, the Saturn design was pretty cut and dry by that point. (ie BEFORE the 32x design began)

I also think a cart design wouldn't be ideal in general due to the limitations of that medium, and a better option would have been a generally lower cost CD-based Saturn design (which could have been MD compatible -if they wanted) in the first place (either launched alongside a high-end -compatible- counterpart, or just with expansion provisions -as I already touched on before). Things like a cheaper/simpler sound subsystem, no VDP2, single SH2 CPU, simpler/cheaper cd-ROM subsystem, and less overall RAM all could have come into play (compared to the existing Saturn; or more complex considerations for a MD+CD compatible one) along with provisions for further expansion externally. (more RAM, 2nd SH2 or an even faster 2nd CPU, faster matrix coprocessor for 3D geometry -possibly floating point based, etc, etc)

Much of that was impossible by the time the 32x's design began though, and at best, they could have cut back on RAM and the CPU . . . maybe cut the custom sound system in favor of software mixed DMA sound (but they'd already invested in R&D for that, so you'd be writing that off in favor of manufacturing cost -unless they made it an upgrade option). Same thing for VDP2 . . . though maybe you could swap that for a simple video output chip connecting to VDP1 (and again, potentially make VDP2 an expansion option -or a module with the SCSP and VDP2).

So, yeah, that would have been an interesting possibility to some extent, but only if SoJ was willing to change plans and actually go in that direction (lower-cost Saturn, or low-end counterpart to launch alongside Saturn).

That's NOT the line of thinking that surrounded the 32x though, and hence the Jupiter would be a more direct counterpart to that, and mesh much better alongside Saturn. (plus, if they launched a stripped-down Saturn with missing features but luanched the full version at the same time, that would complicate programming much more than having a cart based Saturn that was otherwise identical in features -you'd have to program games around practical ROM size constraints, but you wouldn't need to program for totally missing features . . . the 32x had both those problems and more so since it was completely different and "missing" features rather than "missing" ones)

In theory, I think it would've been possible to make a Saturn cart that provided backwards compatibility. It would have had the entire MD hardware inside though. If it could syphon enough power from the Saturn cart slot, it could probably work. You know, when the Saturn cart port was working.

Horribly cost ineffective, bulky, and sloppy. Again, if Sega had cared about backwards compatibility, they would have designed the Saturn to handle that natively . . . and (ideally) make efficient use of the old hardware in general. (ie at least as well as the MD does with the SMS hardware -which is fare, but not really stupendous)

It's like the Famicom adapters for the SFC or the 2600 adapter for the 5200 . . . a big waste.

[TrekkiesUnite118]

Horribly cost ineffective, bulky, and sloppy. Again, if Sega had cared about backwards compatibility, they would have designed the Saturn to handle that natively . . . and (ideally) make efficient use of the old hardware in general. (ie at least as well as the MD does with the SMS hardware -which is fare, but not really stupendous)

It's like the Famicom adapters for the SFC or the 2600 adapter for the 5200 . . . a big waste.

Hence why I think if they were to do it as an add-on, it would have been better as something to go in the MPEG slot if they could get it down to that size. That way all you would need would be a more streamlined cart adapter and the Genesis hardware would be out of sight.

[MrSega]

Sega's System 32 board was almost certainly completed in 1990, because the first game to use it, Rad Mobile, came out in the first half of 1991.




Not sure exactly when Model 3 development began (probably 1994) but it was supposed to arrive sometime around mid-late 1995. It suffered from delays. Model 3 and a demo of VF3 was first shown in early 1996. VF3 was not released in Japanese arcades until late summer or fall 1996.

1990 would likewise be the date that System 32's prototype hardware was completed. Since SegaSonic Arcade started development late in 1991 shortly after Sonic 1's release and around the time Waku Waku Sonic was released.

As for Model 1 and 2, I do know that Model 1 was completed and finalized in early 1992 and that Model 2's design was test ready by late that fall. The first Model 2 unveiling occurred at JAMMA 1993 in August.

Likewise, I believe SEGA should have been clearly focused entirely on Jupiter and Aurora in late '92. Mars and even the GigaDrive idea were nothing more than distractions away from Away27's more ambitious projects. HAD they been focused on 3D then, Saturn would have certainly used cheap silicon and parts with power similar to Model 2.

"So, yeah, that would have been an interesting possibility to some extent, but only if SoJ was willing to change plans and actually go in that direction (lower-cost Saturn, or low-end counterpart to launch alongside Saturn)."

@koolkitty. I seriously feel that SOJ wasted alot of time on Mars in 1992 before shifting back to Jupiter and Saturn in 1993. Mars and the SOA 32X design were uneeded. The best option would have been for SOJ to use the Jupiter design(which ended up as the beta build for Sega Netpune"Mars/32X stand alone of course) and launch it outside of Japan in Fall 1994 only and THEN launch Saturn exactly one year later. Saturn only needed to launch in Japan and Jupiter was pretty useless for domestic aesthetics. Jupiter was the stronger western solution but Sega of America probably had more influence getting Japan to go forward with the Genesis 32X idea instead.

[kool kitty89]

Hence why I think if they were to do it as an add-on, it would have been better as something to go in the MPEG slot if they could get it down to that size. That way all you would need would be a more streamlined cart adapter and the Genesis hardware would be out of sight.

It's still a big waste in hardware . . . and IMO not worth it in general. Compatibility has its advantages from a marketing standpoint, but I don't think investing in a tacked-on adapter for MD games on the Saturn would have been worth it . . . and Sega CD wouldn't have worked either. (I'm assuming they didn't release 32x in this context)

Tactfully designing a system with similar capabilities to Saturn with direct compatibility with MD and MCD would have been very doable . . . it could have been even more cost effective (or at least cheaper) than the Saturn if they'd made a few compromises. (could have saved R&D costs too in some areas -like re-using the CD-ROM interface from the MCD but configured with a 2x speed drive mechanism -chipset already has a 2x data mode iirc) In terms of actual hardware design, there's a huge range of possibilities from making minimal changes to old hardware and adding new graphics/etc (more like existing Saturn hardware), to expanding/enhancing old MD+MCD hardware directly. (and mixes of both)

And, again, the topic of backwards compatibility is separate from the one regarding a lower-cost 5th gen sega platform in general. (in place of, or complementing the "high end" Saturn) And apart from arguments of different design choices Sega could/should have made. (and apart from the point that Sega's management/marketing decisions were bigger problems than the hardware itself they were putting out . . . except the 2 issues have some relation)

That, and a big chunk of this side-discussion was addressed here:
http://www.sega-16.com/forum/showthr...ke-Sense/page4 (the 32x/Jupiter side of things at least, not so much the Saturn with backwards compatibility thing . . . )