Comparison of 5th generation ("32/64-bit") game console hardware

[Team Andromeda]

They'd probably settled on using a SuperH chip by mid 1993

In September of 1993 both SEGA and Hitachi went public to confirm the Saturn would be using a SH-2 and that Hitachi staff would also be based in SEGA HQ. In fact I think in some of the early Saturn credits you'll see Hitachi staff credited in area's like the programming too

I think that's just rumor mill, or only an early throw-away idea

More rummor and going on the fact, that System 32 used the CPU

The entire mythos about the PS1 and Sony's grand entry into the video game industry is wrapped up in "catching Sega with their pants down".

Well lots were caught out not least SEGA who in early 1993 were doing deals with SONY on games like Ground Zero Texas I doubt that would have happened if SEGA really thought SONY would go it alone . What caught everyone out was the spec's that SONY were quoting

1,5000,000 polygons/sec plain

500,000 polygons/sec textured

Typical SONY bullshit hype , but it worked and for sure SEGA (added a 2nd CPU) and NCL had to rethink some of their plains (there was even rumors of an split between SGI and NCL) . That's what got a people of people off-guard was the spec's of the machine, more than the fact SONY made its own console

[kool kitty89]

It doesn't bother - it's all just pixels to VDP1. All CLUT pixels are copied straight into the frame buffer. Shading/blending/alpha/etc is only possible on RGB pixels. In effect, VDP1 only understands two things: 8 or 16 bit pixel width, and RGB or non-RGB format. Everything else is up to VDP2 during compositing.

Sorry, I meant CLUT for expanding 4/8-bit textures. (the CLUT for the palettized 8/16-bit framebuffer modes is obviously on VDP2's end) Though, given Crazyace's explanation, it doesn't sound like it supports 8-bit indexed textures . . . (just 4-bit indexed and direct 8/16-bit textures). Which would be a disadvantage compared to the PSX.

The entire mythos about the PS1 and Sony's grand entry into the video game industry is wrapped up in "catching Sega with their pants down". If that isn't true the whole presentation unravels.

Whether or not they "caught Sega with their pants down" is really immaterial in many respects aside from story telling. Well, it's important to note from a historical perspective too as far as noting what decisions were influenced by Sony's PSX announcements. (and what mistakes were directly related to that -like similar rash actions which were tied to the 1993/94 US slump and perceived threats from the 3DO and Jaguar)

Hmm, actually, if Sega didn't rush things and make mistakes because of Sony, that actually puts them in a worse light in some respects. (management running scared and making mistakes is one thing -still bad since they should be staying cool and planning things logically- . . . but making all those mistakes without being rushed/worried shows far greater incompetence -hardware design inefficiencies, especially in cost effectiveness, doccumentaiton/tool support, release dates, software planning, release/support for the 32x, rushed release of the Saturn, etc, etc -and the related mess with MD/CD/GG support)

Even in the context of the Saturn being modified last-minute . . . the most likely design changes (CPU(s) and low-RAM) don't amount to the major areas of poor cost effectiveness in the overall system. (that issue is tied to things like the substantial use of SDRAM -new and expensive at the time, even if Sega got nice deals from Hitachi- the many, many buses used and large number of large chips -SCU, VDPS, SCSP, etc, super-deluxe -unnecessary/wasteful- CD-ROM subsystem, powerful/deluxe sound subsystem ripe with high-end features -something that always tends to be underutilized- while ironically lacking hardware assist/support for sample decompression . . . and then the mis-matched feature set and programming complexity on top of all that)

The biggest design issue of the Saturn was the total lack of concern on cost to performance ratio . . . lack of foresight for the feature set and programming/documentation issues are more excusable, but the poor (arcade-like) level of cost to performance makes very little sense for a home console design. (the polar opposite of the Atari Jaguar in that respect -the PSX and 3DO being more in-between . . . and also relatively comparable to the likes of the NES/SNES/MD/etc -designed for reasonable cost effectiveness, but not extremely tightly engineered/optimized in terms of cost-performance -and cases like Sony and NEC also deflated manufacturing costs substantially though vertical integration . . . and software too in NEC's case -there's a reason no one else was using ROMs anywhere near as fast as the PCE at the time, or indeed even by the mid 90s -32x, jaguar, and SNES games were still using ROMs 2-2.5 times slower, and early N64 games may still been slower too)

And the Saturn wasn't a rushed last-minute design, but should have been a well-though-out long-term, heavily invested engineering project. (by comparison, the 32x was obviously very rushed and limited to ~6 months development time . . . so it's hard to fault the design trade-offs made in that context -though pushing such a short design cycle at all is more questionable, especially for a relatively hefty piece of hardware -ie not like the SVP or SNES enhancement chips)


There's also the non-technical issues of Sega's (SoJ+SoA+SoE) overall management/marketing/support issues. (from software planning/direction on the Saturn to release dates, marketing, pricing, etc . . . and issues with supporting/positioning the MD, CD, 32x, and GG at the same time -and all of that compromising the MD's late-gen profitability and transition into a solid position on the budget market . . . and not allowing the GG to be more competitive)

In September of 1993 both SEGA and Hitachi went public to confirm the Saturn would be using a SH-2 and that Hitachi staff would also be based in SEGA HQ. In fact I think in some of the early Saturn credits you'll see Hitachi staff credited in area's like the programming too

Are you absolutely positive that they specifically announced use of the SH2 and not just a general SH/SuperH CPU?

The SH2 had not even reached first silicon until October of 1993, so Sega or Hitachi couldn't be sure of it being ready in time (and in volumes) until a bit after that. (ie after testing had been completed on the prototype chips and after production had started ramping up -ensuring the necessary volumes/yields would be available)

So it would indeed make sense that Sega was working with the SH1 in the interim (for prototyping and such) as well as a possible fall-back if the SH2 ran into development/manufacturing problems. (and EDGE quoting a specific SH1 model by name and number is pretty interesting too -details beyond typical vague rumor mill speculation . . . it's also NOT the model Sega ended up using for the CD-ROM subsystem in the Saturn, but a version with a larger scratchpad -8 kB SRAM- and no on-chip ROM . . . the most suitable model for use as a general-purpose CPU rather than an MCU)

Well lots were caught out not least SEGA who in early 1993 were doing deals with SONY on games like Ground Zero Texas I doubt that would have happened if SEGA really thought SONY would go it alone . What caught everyone out was the spec's that SONY were quoting

1,5000,000 polygons/sec plain

500,000 polygons/sec textured

Typical SONY bullshit hype , but it worked and for sure SEGA (added a 2nd CPU) and NCL had to rethink some of their plains (there was even rumors of an split between SGI and NCL) . That's what got a people of people off-guard was the spec's of the machine, more than the fact SONY made its own console

Sony's hype went WAY beyond those simple/vague (and obviously inflated) tech specs . . . the software was a huge part of that (and the massive efforts to interest 3rd parties to the system -as well as developing an excellent SDK on top of the relatively straightforward hardware, and obviously further investing in exclusive licenses for certain games).

Sony managed things brilliantly, and (in many respects) learned from previous market successes. (their US marketing campaigns in particular mirrored what SoA had
done with the Genesis)

Sony got almost everything right on the marketing end as well as strong relationships with 3rd party publishers (and attractive hardware to develop for), with tons of cache to back that up too.
And at the same time, you had the competition making massive mistakes, Sega, NEC, Nintendo all made major screw-ups. (NEC rushing out dated/shelved hardware that was no longer competitive, Sega . . . , Nintendo with their continued stubbornness and proprietary nature leading to use of carts on the N64 and perpetuated ill-will towards 3rd party publishers -and it finally catching up with them in Japan)

[Chilly Willy]

Sorry, I meant CLUT for expanding 4/8-bit textures. (the CLUT for the palettized 8/16-bit framebuffer modes is obviously on VDP2's end) Though, given Crazyace's explanation, it doesn't sound like it supports 8-bit indexed textures . . . (just 4-bit indexed and direct 8/16-bit textures). Which would be a disadvantage compared to the PSX.

Actually, it's just the way I said it was: you can have 16, 64, 128, or 256 color paletted textures. 16 color textures use two pixels per byte, and the other three use one pixel per byte. You might then ask why bother with 64 or 128 if it still uses a byte? Because while the VDP1 is drawing the pixels, it combines the code part (4, 6, 7, or 8 bits) from the texture pixels with a color bank register to form the full indexed pixel, which is stored as 8 or 16 bits in the frame buffer. So the texture might be 16 color, saving a lot of space, then it gets drawn as 16 bit with 16 colors and 12 bits worth of extra info such as CLUT offset, priority, blending, etc. So it's VERY flexible about paletted textures. Note that all those extra bits are for the whole poly, but stored per pixel. So that's where the 64 or 128 color textures come in - you get more bits for priority/blending/whatever for textures that don't have as many colors, but more than 16 colors. Why waste 2 bits on a 256 olor texture that only uses 62 colors... make it a 64 color texture and put those extra 2 bits to better use.

But that's why there's no shading/etc on 16/64/128/256 color textures: the color is NOT looked up in the CLUT and changed to RGB, it's left as an index into the CLUT and the rest of the pixel is filled with extra info to pass along to VDP2, which then uses the color tables in vram to translate the indexed color into RGB.

there's a reason no one else was using ROMs anywhere near as fast as the PCE at the time, or indeed even by the mid 90s -32x, jaguar, and SNES games were still using ROMs 2-2.5 times slower, and early N64 games may still been slower too)

The default speed the N64 uses for the cart is ridiculously slow... the MD is probably three to four times as fast. However, you can change the bus speed on the N64 for the cart, which was apparently routine.

[Black_Tiger]

Well lots were caught out not least SEGA who in early 1993 were doing deals with SONY on games like Ground Zero Texas I doubt that would have happened if SEGA really thought SONY would go it alone . What caught everyone out was the spec's that SONY were quoting

1,5000,000 polygons/sec plain

500,000 polygons/sec textured

Typical SONY bullshit hype , but it worked and for sure SEGA (added a 2nd CPU) and NCL had to rethink some of their plains (there was even rumors of an split between SGI and NCL) . That's what got a people of people off-guard was the spec's of the machine, more than the fact SONY made its own console

I remember that magazines also printed a bunch of pre-rendered cgi screen shots that they said were real-time Playstation graphics and talked about how they showed how the PSX could push a huge amount of polygons and do unbelievable effects.

[sheath]

Well lots were caught out not least SEGA who in early 1993 were doing deals with SONY on games like Ground Zero Texas I doubt that would have happened if SEGA really thought SONY would go it alone . What caught everyone out was the spec's that SONY were quoting

1,5000,000 polygons/sec plain

500,000 polygons/sec textured

Typical SONY bullshit hype , but it worked and for sure SEGA (added a 2nd CPU) and NCL had to rethink some of their plains (there was even rumors of an split between SGI and NCL) . That's what got a people of people off-guard was the spec's of the machine, more than the fact SONY made its own console

This is where I expect to find any evidence of a Saturn redesign. I have narrowed Sony's PS1 spec sheet announcement to summer of 1993, so if there was a reaction by Sega it began then. As near as I can tell both SH2's were included in the Saturn by the end of 1993 at the latest. The PS1 wasn't exactly finished any earlier than that.

Whether or not they "caught Sega with their pants down" is really immaterial in many respects aside from story telling. Well, it's important to note from a historical perspective too as far as noting what decisions were influenced by Sony's PSX announcements. (and what mistakes were directly related to that -like similar rash actions which were tied to the 1993/94 US slump and perceived threats from the 3DO and Jaguar)

I am only speaking to the established story, the one that Sony has propagated for two console generations and published in their own book "Revolutionaries at Sony". If in actuality Sega reacted at all to Sony's PS1 specs and revised the Saturn we still lack any details to what that reaction entailed.

Hmm, actually, if Sega didn't rush things and make mistakes because of Sony, that actually puts them in a worse light in some respects. (management running scared and making mistakes is one thing -still bad since they should be staying cool and planning things logically- . . . but making all those mistakes without being rushed/worried shows far greater incompetence -hardware design inefficiencies, especially in cost effectiveness, doccumentaiton/tool support, release dates, software planning, release/support for the 32x, rushed release of the Saturn, etc, etc -and the related mess with MD/CD/GG support)

The only measurable mistakes I can find on Sega's part are the early launch of the Saturn in the West, and perhaps the belated nature of PS1 style Saturn development kits. While I am at it though, I should fault Sega for not having as much money and notoriety as Sony going into the 32-bit console war.

Even in the context of the Saturn being modified last-minute . . . the most likely design changes (CPU(s) and low-RAM) don't amount to the major areas of poor cost effectiveness in the overall system. (that issue is tied to things like the substantial use of SDRAM -new and expensive at the time, even if Sega got nice deals from Hitachi- the many, many buses used and large number of large chips -SCU, VDPS, SCSP, etc, super-deluxe -unnecessary/wasteful- CD-ROM subsystem, powerful/deluxe sound subsystem ripe with high-end features -something that always tends to be underutilized- while ironically lacking hardware assist/support for sample decompression . . . and then the mis-matched feature set and programming complexity on top of all that)

I don't think it is a foregone conclusion that "good" engineering would include obvious planning for scalability back then. This is actually a huge assumption.

The biggest design issue of the Saturn was the total lack of concern on cost to performance ratio . . . lack of foresight for the feature set and programming/documentation issues are more excusable, but the poor (arcade-like) level of cost to performance makes very little sense for a home console design. (the polar opposite of the Atari Jaguar in that respect -the PSX and 3DO being more in-between . . . and also relatively comparable to the likes of the NES/SNES/MD/etc -designed for reasonable cost effectiveness, but not extremely tightly engineered/optimized in terms of cost-performance -and cases like Sony and NEC also deflated manufacturing costs substantially though vertical integration . . . and software too in NEC's case -there's a reason no one else was using ROMs anywhere near as fast as the PCE at the time, or indeed even by the mid 90s -32x, jaguar, and SNES games were still using ROMs 2-2.5 times slower, and early N64 games may still been slower too)

It's almost as if they took six years of increasingly negative press and decided to pull off all of the stops against any future criticism in the same areas.

And the Saturn wasn't a rushed last-minute design, but should have been a well-though-out long-term, heavily invested engineering project. (by comparison, the 32x was obviously very rushed and limited to ~6 months development time . . . so it's hard to fault the design trade-offs made in that context -though pushing such a short design cycle at all is more questionable, especially for a relatively hefty piece of hardware -ie not like the SVP or SNES enhancement chips)

Since the 32X was based on the Saturn and based on the Genesis, I would hardly call the engineering poorly thought out overall. Limited certainly, but it is derivative of two full blown console designs.

[Crazyace]

What caught everyone out was the spec's that SONY were quoting

1,5000,000 polygons/sec plain

500,000 polygons/sec textured

Typical SONY bullshit hype , but it worked and for sure SEGA (added a 2nd CPU) and NCL had to rethink some of their plains (there was even rumors of an split between SGI and NCL) . That's what got a people of people off-guard was the spec's of the machine, more than the fact SONY made its own console

Actually in engineering terms this wasn't bullshit hype - those are the peak transform numbers for the GTE - the gpu ( drawing numbers ) were tagged as 360k/180k , and shown in sample code. The SC DSP on the saturn would be a least 3x slower just handling the matrix multiplication, without adding the perspective divide.
So I guess you could suggest the extra SH2 is there to beef up the geometry processing - as the Sega engineers may have been happier about the comparision of VDP1 ( +VDP2 ) to the PSX GPU.

[Crazyace]

Some of the PSX numbers probably come from the patents ( like the one here: http://www.patents.com/us-6816972.html )

[Team Andromeda]

Are you absolutely positive that they specifically announced use of the SH2 and not just a general SH/SuperH CPU

Hitachi said it was to be using their next generation in the SH range , so that rules out the SH-1 and its pretty obvious that they were on about the SH-2 .

Sony's hype went WAY beyond those simple/vague (and obviously inflated) tech specs . . . the software was a huge part of that (and the massive efforts to interest 3rd parties to the system -as well as developing an excellent SDK on top of the relatively straightforward hardware, and obviously further investing in exclusive licenses for certain games).

This was very early 1993 when a lot of 3rd parties were caught off guard them self's - What got people talking was the spec's and because it came from SONY nobody doubted them at all . But this is SONY after all the one that likes to claim all the Tech demo for the PS2 were real, the PSP could do PS2 beating graphics , that the PS3 was so powerful forget being able to handle 1080p, it was so powerful it could output and handle dual 1080p and even now likes to claim VITA is a PS3 in your hand and its never questioned .

SEGA claims DC can handle more Polygons that model 3 and everyone in the press questions those facts and says its not true .

but making all those mistakes without being rushed/worried shows far greater incompetence -hardware design inefficiencies, especially in cost effectiveness, doccumentaiton/tool support, release dates, software planning, release/support for the 32x, rushed release of the Saturn, etc, etc -and the related mess with MD/CD/GG support)

SEGA used off the shelf chipsets that always makes your hardware prone to some faults . What's SONY excuse for the PS2 coming off the then best selling home console ever made in the history of videogames ? and then what's SONY excuse for the PS3 coming off the best selling console in the history of videogames (still) . In both cases cost effectiveness went out the window, their motherboards were a mess, the launch tools utter crap and games (especially for the PS2) utterly horrible and yet no issues from you, always about the Saturn....

I just love your double standards .

Not if you want to get back to reality, if there was no PS the Saturn would have been by a long way the most power console available by a massive margin and that wouldn't have changed for 2 years and SEGA would have had the 32Bit market all to its self for those 2 years . It would have been a very different picture and I'll there would have been no issues from 3rd parties about tools or the Hardware, they'll be looking at Marketshare and saying we must support it , end off.

SEGA made 2 royal cock ups really... It let SOA/SOE push ahead with the 32X and SOJ never made sure it had a Sonic game ready early in, or any serious plans to make a full on 32bit Sonic game either - In both cases total and utter cock ups

As near as I can tell both SH2's were included in the Saturn by the end of 1993 at the latest. The PS1 wasn't exactly finished any earlier than that

In early 1993 it was only one CPU running at 27 Mhz , at the end of 1993 it was dual CPU. That is what one would call a reaction . The only constant parts of the Saturn that stayed the same was the VDP II, the SH-2 running at 27mhz and the Sound chip which were pretty spot on for the early leaked spec's to the final design. In early 1993 it was said the Saturn could only handle 16,000 to 32,000 polygons So that would lead one to assume the VDP 1 its self was beefed up quite a lot too


Oh and going through some of the old mag's , Lets set the record straight on SEGA profits once and for all

In the financial year of 1993 SEGA posted world wide profits of £250 million and on the back of those results SEGA jumped over 20 places in Japanese ranked corporations

In the financial year of 1997 SEGA posted world wide profits of £27 Million

So it wasn't until late 1997 that SEGA went into the RED

[Crazyace]

Even in the context of the Saturn being modified last-minute . . . the most likely design changes (CPU(s) and low-RAM) don't amount to the major areas of poor cost effectiveness in the overall system. (that issue is tied to things like the substantial use of SDRAM -new and expensive at the time, even if Sega got nice deals from Hitachi- the many, many buses used and large number of large chips -SCU, VDPS, SCSP, etc, super-deluxe -unnecessary/wasteful- CD-ROM subsystem, powerful/deluxe sound subsystem ripe with high-end features -something that always tends to be underutilized- while ironically lacking hardware assist/support for sample decompression . . . and then the mis-matched feature set and programming complexity on top of all that)

I dont know why you keep claiming that the Saturn design is poor and wastefull. The use of components is actually pretty elegant ( in some ways much better than the bruteforce bus widening on the Jaguar ).

VDP2 maximises the bandwidth of it's RAM by explicitly exposing the 4 possible open banks ( A0/A1/B0/B1 ) to maximise the amount of independant data read per cycle.
VDP1 builds on the RAM chip capacities ( 16bits per chip ) by driving them seperately ( it's not really even a 'bus' but instead a single chip directly connected ) allowing 'vram' effects without more expensive ram chips. ( Clear and scanout of a 320x224 buffer otherwise would need 8.6 million accesses per second - even without page changes that is a sizeable amount of the total 28.6 million , with it the performance could be crippled )

Sony's hype went WAY beyond those simple/vague (and obviously inflated) tech specs . . .

Those are actually accurate techspecs, not inflated. However people tend to misread them beyound their benchmarking/engineering contexts

[kool kitty89]

Actually, it's just the way I said it was: you can have 16, 64, 128, or 256 color paletted textures. 16 color textures use two pixels per byte, and the other three use one pixel per byte. You might then ask why bother with 64 or 128 if it still uses a byte? Because while the VDP1 is drawing the pixels, it combines the code part (4, 6, 7, or 8 bits) from the texture pixels with a color bank register to form the full indexed pixel, which is stored as 8 or 16 bits in the frame buffer. So the texture might be 16 color, saving a lot of space, then it gets drawn as 16 bit with 16 colors and 12 bits worth of extra info such as CLUT offset, priority, blending, etc. So it's VERY flexible about paletted textures. Note that all those extra bits are for the whole poly, but stored per pixel. So that's where the 64 or 128 color textures come in - you get more bits for priority/blending/whatever for textures that don't have as many colors, but more than 16 colors. Why waste 2 bits on a 256 olor texture that only uses 62 colors... make it a 64 color texture and put those extra 2 bits to better use.

But that's why there's no shading/etc on 16/64/128/256 color textures: the color is NOT looked up in the CLUT and changed to RGB, it's left as an index into the CLUT and the rest of the pixel is filled with extra info to pass along to VDP2, which then uses the color tables in vram to translate the indexed color into RGB.

Ah, so only 16-bit direct color textures (taking lots of memory) can be shaded/lit -even flat shaded? (that would be a major disadvantage compared to the PSX or N64 . . for 2D and 3D stuff)

This would also only for for paletted framebuffer modes? (direct color framebuffer modes would be limited to direct color textures)

Is it possible to do any shading in paletted modes? (perhaps if you specifically organized the palette to allow for several banks of different shades -like 16 colors by 16 shades in 8-bit mode, or other possibilities in 16-bit mode) Or does VDP1's shading logic fixed to 5-bit boundaries? (for 5-5-5 RGB only . . . and you'd need 4 bits for the 4-4 color/shade idea to work -interesting that the Jaguar's shading logic is designed to work with 4 and 8-bit boundaries -due to CRY using those widths)

If you could use such an 8-bit colorspace, you'd be mainly limited to 8-bit textures (using offsets would mean odd transitions between colors/shades in the custom colorspace -or using 16 colors of a common shade . . . so limited in use), but that's still 1/2 the space over 16-bit textures. Plus, a custom 256 color palette could allow proper linear (multiplicative-style) light levels (not possible in 15-bit RGB on the Saturn). The disadvantages would obviously be no translucent sprites blended into the framebuffer and being limited to 256 colors. (though also indexed from 24-bit RGB -and the usual full-screen palette swapping effects would apply, though look-up table based effects would be far less attractive than with software renderers)

The default speed the N64 uses for the cart is ridiculously slow... the MD is probably three to four times as fast. However, you can change the bus speed on the N64 for the cart, which was apparently routine.

Maybe slower than 32x ROMs (and maybe some late gen MD ROMs), but I doubt it's slower than early MD ROMs. (ie the ones just barely fast enough for the 68k -around 520 ns cycle timing- . . . and the same games that tend to crash with the CPU overclocked)
Given even the low-end ROMs commonly used in the Jaguar were 375 ns (like early SNES games), it's hard to believe the N64 used ROMs significantly slower than that. (and later SNES games used 280 ns ROMs)

Well . . . maybe the minimum ROM speed supported would be very slow (with that as the default), but with all actually games running much faster than that. (t would make sense that early N64 games were using similar -or only slightly faster- speeds than late gen SNES games -and thus far slower than the PCE's ROMs, but significantly faster than the Jaguar's)

I am only speaking to the established story, the one that Sony has propagated for two console generations and published in their own book "Revolutionaries at Sony". If in actuality Sega reacted at all to Sony's PS1 specs and revised the Saturn we still lack any details to what that reaction entailed.

It's unlikely that any such redesign was fueled by the PSX hardware alone . . . there's many other events/tech that happened around that time (late 1993) that could have spurred "beefing up" the system's resources.

The only measurable mistakes I can find on Sega's part are the early launch of the Saturn in the West, and perhaps the belated nature of PS1 style Saturn development kits. While I am at it though, I should fault Sega for not having as much money and notoriety as Sony going into the 32-bit console war.

I really disagree here. Sega had made many, many mistakes prior to that point (that was a nasty one, but still just one among many -most of which were due to their fundamental management/communication/cooperation issues).

There's many significant problems/mistakes to list from 1991 onward (starting with the Sega CD -ignoring the problems with the SMS prior to that), and I've commented on several of those in some other recent discussions, but sticking to the 5th gen tech-specific topic, I'll roll this into my response on to this next comment.

I don't think it is a foregone conclusion that "good" engineering would include obvious planning for scalability back then. This is actually a huge assumption.

"back then" is a pretty odd statement . . . those sort of design/engineering trade-offs were significant/important from pretty much day 1 in the industry (or the consumer electronics industry in general). Albeit, scalability is only important for a product intended to be on the market for an extended period and in high volumes.

However, the overall issue here if cost to performance ratio (cost effectiveness) and scalability is only one facet of that (specifically a facent from the long-run perspective), and there's a number of other general areas to consider.
There's initial cost for manufacture, and you can split further into initial cost at low volumes and after economies of scale kick in (ie high volumes).
You're also limited by available technology, obviously, and ASICs of available/practical die sizes/processes/pin-counts, and off the shelf parts in volume production. (or negotiations for custom derivatives of off the shelf parts)

Some engineering choices can favor both low-cost in the short run and further savings in the long run. (ie highly integrated chipset using few, relatively dense ASICs on few/1 buses would favor low initial manufacturing cost as well as further cost reduction due to Moore's law -silicon gets cheaper- and further savings with die shrinks on newer processes -less silicon, and more still by further integration of the ASICs -less pins/traces/packages/board space)

There's many examples of aggressively low-cost optimized designs in the game market, several of which also have proportionally high performance (albeit some just low-cost/low-performance). The Atari 2600 would be among the better early examples of a very low-cost specific design that retained a good amount of raw performance as well. (it took very tight programming to take advantage of, but that ended up catering well to the market of the time -lots of coders willing to push hard and also inherently limitations of relatively small programs -so you're at least not writing massive amounts of extremely tight code . . . though some late gen VCS games would be getting closer to that -the several 32k+ carts from the late 80s/early 90s)
Looking at the VCS, you have a very simple chipset of the low-cost 6507, RIOT, and custom TIA sound/video/IO chip all on a common bus, and a small 24-pin cart slot (and quite small PCBs for most carts) . . . the simple design (and use of easily licensed MOS chips) also gave potential for further consolidation (though probably not something intended originally -given the relatively short lifespan expected), but that was later taken advantage of in 1983 with the JAN chip. (though delayed due to Atair's problems -and stockpiles of older VCS chips- and the single-chip VCS was finally implemented around 1986 -early model 2600 Jrs still used the old chipset, but later models used the single chip version)

The MD wasn't the most cost-optimized console out there (SMS compatibility compromising some things, VRAM+PSRAM+SRAM, etc), but it was fairly reasonable overall (at least in price point, if not cost-performance), and (intentional or not), it ended up scaling very well. (from merging I/O chips, to integrated all I/O and the YM2612 into the VDP ASIC, to merging the Z80+RAM into the ASIC -also cutting the system down to 2 external buses, and merging the 68k into the ASIC, to switching to a single 16-bit bus anda single SDRAM chip)

I'm not really sure how to summarize the issues with the Saturn without ending up rambling and giving multiple examples for comparison (like I already start to have) . . . but overall:

There's many different engineering trade-offs that can be made durring a system's design like: lower cost, shorter development time, lower R&D investment, more raw power/resource, larger feature set, greater flexibility, ease of programmability, etc. (the Jaguar, for example, sacrificed ease of programmability in favor of an earlier release, low cost, and lots of raw power -and also relatively limited R&D resources in terms of funding and personnel, though the few they did have were amazingly skilled enginners)

The Saturn wasn't just problematic in 1 area, but many: it had a high initial cost (and relatively poor cost to performance ratio), scaled poorly, and had a complex feature-rich architecture that catered relatively poorly to mainstream performance needs (particularly problematic due to tools/documentation -and not just graphics, but sound, CD-ROM management, etc).
It's basically a high-performance high-cost system rather like many arcade boards (ie not catering to practical mainstream consumer product requirements). Not to be confused with the likes of the 3DO, which was high-priced but inflated massively due to the market model used. (if sold similarly to the Saturn/PSX, it almost certainly would have undercut the PSX's launch price by a significant margin by mid 1995 -only 2 buses, 2MB cheap FPM DRAM for main RAM and 1MB relatively slow VRAM -far cheaper than the EDO DRAM/SGRAM/SDRAM the PSX or Saturn were using . . . and the 3DO probably would have had 256k or 512k VRAM had it been aimed as a game console like the PSX -rather than a high-end multimedia platform, but I digress)

So, the Saturn had unreasonably high cost/price and less than amazing performance to show for that cost on top of that. (albeit, even a more efficient high-cost super-high performance system would have had trouble on the market due to impractically high pricing -OTOH, a low-cost mediocre performance/efficiency system at least would have fit the mainstream cost/price range)
And, on top of that, the feature set included was largely wasted by the market at hand, so nominally even less cost effective and more wasteful. (again, not just the graphics, but also the CD-ROM and sound subsystems)

And this is with no personal bias against the Saturn at all, mind you. (whether or not I like a system -or its software- personally is an issue I try my best to keep separate )

And honestly, most of this perspective was gained in a long on-and-off discussion about the Jaguar hardware design on Atariage, particularly with comments and information from Kskunk (and some related threads with added info, again, often from him -he's one of the best on that site to put hardware/engineering design aspects into perspective). Those discussions branched off into a lot of areas, but overall the important thing was a general understanding of many of the fundamental cost and performance related engineering trade-offs. (as well as the general issue of R&D invesment into an aggressively efficient high-performance/low-cost system or chip)
This thread actually: http://www.atariage.com/forums/topic.../page__st__100

And then, as I learned more an more specifics about other designs/systems, I applied that knowledge andmade comparisons . . . and asked more qestions on the topic (in several discussions with several people).
And really, looking at all the other major consoles released (and even many minor ones), it's hard to find anythign like the engineering/cost/performance trade-offs madein the Saturn. (feature-set mis-matches, sure, overkill/wasted features, sure, generally mediocre cost effectiveness, sure, but never the mess of high-cost+cost/performance+feature-set problems as in the Saturn) The Neo Geo wouldn't really be a good comparison (given it was never intended as a mainstream consumer product), and the CD32x doesn't really count either (not a stanalone console design, but a hacked-together set of hardware limited by the MD's interfacing/speed -so not like the Saturn, and also not the makings of a realistic/mainstream console ).
The 3DO was high priced, but the actual design/cost wasn't reflected in that, and even the PS3 isn't really a good example. (still more cost effective, and not quite as unreasonably priced initially -$499 in 2006 vs $399 in 1995 . . . and at least not nearly as mis-matched for the market as the Saturn's feature set)

Since the 32X was based on the Saturn and based on the Genesis, I would hardly call the engineering poorly thought out overall. Limited certainly, but it is derivative of two full blown console designs.

The 32x's design was basic/bare-bones and rushed. Poorly thought out for a realistic mainstream platform, but not bad at all in the context of being designed in half a year.
Being a MD add-on alone made it practically limited in cost effectiveness compared to a standalone design, and the general lack of hardware acceleration certainly hurt cost-performance significantly. (software rendering is certainly flexible, but hardly favors agood cost-performance ratio)

I'm tempted to summarize a hypothetical simalarly low-cost alternative as a comparison, but I'll stop here. (I've already done that at length before, and I tend to just end up rambling too much)

[sheath]

Actually in engineering terms this wasn't bullshit hype - those are the peak transform numbers for the GTE - the gpu ( drawing numbers ) were tagged as 360k/180k , and shown in sample code. The SC DSP on the saturn would be a least 3x slower just handling the matrix multiplication, without adding the perspective divide.
So I guess you could suggest the extra SH2 is there to beef up the geometry processing - as the Sega engineers may have been happier about the comparision of VDP1 ( +VDP2 ) to the PSX GPU.

It may be the engineering specs of the GTE but the specs have no practical bearing on the PS1 itself. Ezra Dreisbach went on about how fast the GTE was in one of his interviews but then admitted that the PS1 CPU bottlenecked the hardware. I think he said something to the effect that he could have gotten the opening scene of Quake running at 60FPS if it weren't for the CPU holding it below 30FPS.

If hypothetically the VDP1 or the DSP could do enough calculations in a vacuum for 1 million polys per second I would still call that false advertising if Sega had publicized it. I think Sega's Saturn specs were 200,000 Texture Mapped non-shaded and 500,000 flat non shaded polygons per second though. But that is an apples to oranges comparison with Sony's 360k/180k even without considering VDP2 floors.

[sheath]

I really disagree here. Sega had made many, many mistakes prior to that point (that was a nasty one, but still just one among many -most of which were due to their fundamental management/communication/cooperation issues).

There's many significant problems/mistakes to list from 1991 onward (starting with the Sega CD -ignoring the problems with the SMS prior to that), and I've commented on several of those in some other recent discussions, but sticking to the 5th gen tech-specific topic, I'll roll this into my response on to this next comment.

Your equation needs to include whether or not the Sega CD's existence boosted Sega's reputation in the short term. Without the Sega CD would the Genesis have been called "aging tech" earlier than 1993? I think with how much hype the SNES received and how the magazines consistently praised its colors, audio and mode 7 effects that Sega needed something to avoid a decline. I know this might launch you into a flurry of hypothetical alternatives to the real world Sega CD, but I am only talking about real world PR and hype generated by the add-on in 1991 and 1992 (which was significant and positive).

"back then" is a pretty odd statement . . . those sort of design/engineering trade-offs were significant/important from pretty much day 1 in the industry (or the consumer electronics industry in general). Albeit, scalability is only important for a product intended to be on the market for an extended period and in high volumes.

That is what I mean, also I have no idea why the SH-2's, VDPs, Sound Subsystem, etc. couldn't have eventually been shrunk over time. The Saturn barely made it long enough to make one board revision, I see no reason not to expect more if it lasted five years, much less ten.

However, the overall issue here if cost to performance ratio (cost effectiveness) and scalability is only one facet of that (specifically a facent from the long-run perspective), and there's a number of other general areas to consider....

Some engineering choices can favor both low-cost in the short run and further savings in the long run. ...

The MD wasn't the most cost-optimized console out there ..., but it was fairly reasonable overall ..., and (intentional or not), it ended up scaling very well. ...
...
The Saturn wasn't just problematic in 1 area, but many: it had a high initial cost (and relatively poor cost to performance ratio), scaled poorly, and had a complex feature-rich architecture that catered relatively poorly to mainstream performance needs (particularly problematic due to tools/documentation -and not just graphics, but sound, CD-ROM management, etc).
It's basically a high-performance high-cost system rather like many arcade boards (ie not catering to practical mainstream consumer product requirements).

How are you measuring cost/performance ratio for the Saturn versus PS1? I think looking at the hardware costs as we understand it, and based on the Japanese launch prices, the Saturn and PS1 were similar (within $50) in cost. That is especially significant since the Saturn obviously has higher quality CD-ROM drives than the PS1 does. The Saturn had a design that would require more development time to squeeze every drop of performance out, but that also meant that the Saturn would outperform the PS1 in the long run. People frequently get that mixed up, developer complaints about the Saturn are about getting every ounce of performance from the system, not getting PS1 level graphics. Games that would push the PS1's polygon performance to the max were done on the Saturn with a combination of VDP2 floors and VDP1 3D characters (See Fighting Vipers, Fighters' Megamix, Shining the Holy Arc, Shining Force III, Panzer Dragoon Saga and Sonic R).

Obviously the PS1 and Saturn excelled at different things, but I don't get how the Saturn had a poor cost/performance ratio in comparison.

Not to be confused with the likes of the 3DO, which was high-priced but inflated massively due to the market model used. ...

So, the Saturn had unreasonably high cost/price and less than amazing performance to show for that cost on top of that. ...
And, on top of that, the feature set included was largely wasted by the market at hand, so nominally even less cost effective and more wasteful. ...

And this is with no personal bias against the Saturn at all, mind you. ...

I think the only way to support these assertions is to rely on anecedotes of people being "less than amazed" by the Saturn's capabilities. Even in 1995 the system had 2-player split screen racers, Wing Arms had way longer draw distance and texture quality than Warhawk or Air Combat, and then there is Virtua Fighter 2 besting Tekken in every conceivable way (save what, lighting?) technically. I think this is a highly subjective argument against the Saturn.

The 32x's design was basic/bare-bones and rushed. Poorly thought out for a realistic mainstream platform, but not bad at all in the context of being designed in half a year.
Being a MD add-on alone made it practically limited in cost effectiveness compared to a standalone design, and the general lack of hardware acceleration certainly hurt cost-performance significantly. (software rendering is certainly flexible, but hardly favors agood cost-performance ratio)

I'm tempted to summarize a hypothetical simalarly low-cost alternative as a comparison, but I'll stop here. (I've already done that at length before, and I tend to just end up rambling too much)

The 32X uses the CPUs of Sega's next generation platform and depends on the Genesis as its sub system. I think that is a fairly well thought out design, and the cost of the add-on was bound to drop dramatically as 32X and Saturn sold.

[Crazyace]

It has every practical bearing - just like any other spec. ( clock speed, resolution ) - After all it means that if you ran 50% of the time as game code and 50% as 'transform' the PSX would be able to transform 750k polys/second.

Where are the specs for 200k TM and 500k flat poly's second - they are higher than the PSX numbers ( which are taken from one of the sdk samples ) yet the same Ezra Dreisbach interview you mention above talks about how much faster the PSX gpu is compared to VDP1.

Surely someone has benchmarked these figures for VDP1 here?

[sheath]

The 200k/500k is the Saturn's box specs, and repeated on Usenet and online since its release. I would assume it is created by means of benchmarking both SH2s and the VDP1 at the very least.

[TrekkiesUnite118]

That is what I mean, also I have no idea why the SH-2's, VDPs, Sound Subsystem, etc. couldn't have eventually been shrunk over time. The Saturn barely made it long enough to make one board revision, I see no reason not to expect more if it lasted five years, much less ten.

I know there are at least 3 different board revisions of the Saturn, though most of them have to do with minor things such as putting the controller ports on the main board (Early models had them on a small separate board), changing the jumper locations and arrangement, various CD-Rom board revisions, etc.

As for the rushed design, didn't we come to the conclusion a while ago that the tacked on 2nd CPU was referring to VDP1 and not the 2nd SH-2?

As for the specs, they are also in the official manual for the system. I uploaded a scan of it a few years ago for SegaSaturn.co.uk if anyone is interested.