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

[sheath]

It's interesting to hear about VF and Panzer being completely in assembly - was this mentioned in interviews at the time? I dont think you can blame Sony for building their own standard though - as 3DO had C based development, and PC's had moved over to C, and even some Genesis games had begun to use C.

I guess it's dangerous to blindly quote figures if you fail to understand where they come from sheath , otherwise you can end up miscomparing things ( which is sometimes what the PR people want ) the 64 bits of the Jaguar is a great example of that.
Given how homebrew is on all retro platforms now it should be easy to find polygon and fillrate tests for all 3 platforms that would be definitive and believable by all.

Which is why I resisted the comparison in the first place, especially since all of the top Saturn software uses VDP2 floors. All I was pointing out is that Sony's figures even on the PS1 were always bloated and unrealistic. I would be interested to know how they can be extrapolated from the hardware though, and I will hold firm that if it is just the theoretical limit of the GPU or GTE then it is not a realistic number. If either system could do 500,000 flat non-shaded polys per second I would absolutely have loved to play games that pushed the systems that way.

By the way, my Jaguar crack was in regard to a present conversation over at Atari age and not directed at you at all. Yes the Jaguar was more than competitive with the 3DO and 32X, and with voxel engines it could have carved out its own slice of technical pie among the PS1 and Saturn too.

[Chilly Willy]

For the VDP1 tests it shouldn't be difficult - you can build a sprite list in C and time how long it takes to run. Have you got Saturn dev running Chilly? It's not something I have tried, although I could write a test, validate it on a emulator, and then see if anyrun can check the results on real hardware.
32X and Jaguar start to blur the lines more to software - but to test 3D0/Saturn/PSX should be easy.

I can compile stuff for the Saturn, but I need decent CDRs for testing on my Saturn. I have some CDRs coming from NewEgg since every damn store in town now only carries that Memorex crap. Memorex barely works on my DC (and I don't like using it since it makes the DC work extra hard retrying reads), and doesn't work on my Saturn or SCDs... it doesn't even work for plain CDDA audio discs.

[TVC 15]

Virtua Fighter on Saturn is 8MB once you strip away all the CD Audio and redundant data. That kind of seems like it fits the bill for a program coded in assembly, linked C files are surely always going to be larger in size (though not massive by any stretch), and most of the Saturn libs were just a twinkle in the Sega's eye when VF was first coded. Most of the early titles are pretty much written to the metal, since dev tools where very underdeveloped, Sega Rally was mostly in assembly.

Of course I'm happily open to criticism, I'm no coder.

I think it will be interesting to see some home brew tests on the Saturn, I don't think the SH-2's are really that slow at 3D math surely? There certainly much faster than the comparable MIPS used in the PSX, though not as fast as the GTE where the bulk of 3D rendering takes place. Of course in the case of the Saturn carefully orchestrating in a multiprocessor setup will always bring headaches sub-dividing code etc. The VDP1 sounds like the biggest bottle neck when rendering anything, you can see it struggling to draw the scenery in Nights, yet a lot of unverified rumors on the net suggest its pushing a lot polygons.

The SCU DSP by the sounds of discussion over the past few pages seems incredibly slow and unwieldly, if theirs anything that should have been removed as a redundant part it this.

Question, could some basic game logic be run on it? Since its so slow at 3D Math? It's inclusion does point that it was left as part of any older designs, before the Saturn was beefed up (which is still open for debate).

[Chilly Willy]

The SCU DSP by the sounds of discussion over the past few pages seems incredibly slow and unwieldly, if theirs anything that should have been removed as a redundant part it this.

Question, could some basic game logic be run on it? Since its so slow at 3D Math? It's inclusion does point that it was left as part of any older designs, before the Saturn was beefed up (which is still open for debate).

The DSP is a pretty typical DSP, but it has a DMA channel for getting data, and one for storing the results, so all you'd have to do is point the DMA to the start of your data and let it churn through it all. Yet another thing you can make asynchronous to the main CPU running the game logic. Good Saturn programming is all about splitting off whatever you can to the available hardware so that everyone shares the load. That may mean a lot of rewriting for game ports. The best Saturn games used engines built from scratch specifically for the Saturn.

[Team Andromeda]

Reiko was running live from a prototype PS2 devkit

I think it was confirmed by NAMCO that it was indeed CGI being played back and was only meant to give a indication of what was possible . Mind you we listen to Phil and SONY killzone II and Motostorm at E3 2005 were real time .

It's interesting to hear about VF and Panzer being completely in assembly - was this mentioned in interviews at the time?

Yes Here's AM#2 and Yu Suzuki in 1994

In AM~2 we use C for the 1st few steps and assembly afterwards. We managed to get the twin CPU's running at 1.8 times the speed of a single chip- that would have been impossible using C

Which is why I resisted the comparison in the first place, especially since all of the top Saturn software uses VDP2 floors

Bar the likes of SEGA Rally and the likes of Daytona USA CE - Which hardly use the VDP2 in any way to aid the pokygons and its all Saturn VDP1 grunt and yet SEGA Rally is pushing loads of polygons at a rock solid 30 fps. Shutokou Battle '97 Drift King also looks amazing and makes full use of the VDP1 polygons

The VDP1 sounds like the biggest bottle neck when rendering anything, you can see it struggling to draw the scenery in Nights, yet a lot of unverified rumors on the net suggest its pushing a lot polygons.

To be fair it was their 1st effort and you could see improvements in the engine Christmas Nights . Omega Boost was meant to push a lot of polygons and yet has terrible draw in on the ground and floor . I did read that Dark Savour on the Saturn is pushing way over 100,000 polygons too and Tomb Raider its self must be pushing quite a few and is really impressive for a 1st generation game and coming from a tiny corp like CORE made it all the more impressive

[kool kitty89]

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.

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

I understand that . . . I meant inflated as in taken out of context by marketing (like the jaguar's 851 million pixel/s spec).

And on the issue of the SCU DSP . . . they also couldn't easily have removed it from the design on short notice (even if the 2nd SH2 rendered it largely redundant) since it was embedded in the SCU DSP. (albeit it may not have taken that much silicon, and might have made a decent addition to overall performance -beyond 3D math, it could have been useful for sound processing to assist the 68k without SH2 overhead -especially for sample decompression)

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 )

Maybe I got the wrong impression from all those discussion with Kskunk, but his explanations (of hardware design decisions/tradeoffs for cost/performance/time/programmability/etc -in general and some comments specific to the Saturn) point to the design route taken by the Saturn to be extremely costly for the performance it provides. (the multiple independent buses being one of the fundamental cost-performance problems -more traces, pins, RAM chips, etc; bad for initial cost and also bad for scaling the design later on)

For example, here's some pertinent (truncated) quotes from him:
http://www.atariage.com/forums/topic...2#entry1887582

[snip]
The final problem is cost. You probably want a 32-bit bus (since this is the width of the scratchpads). 16-bits would halve performance again. A separate 32-bit bus is going to want around 60 pins. Chip packages with a lot of pins are expensive -- the number of pins is a major percentage of the cost in custom chips. Also, while transistors get cheaper every year (thanks to Moore's law), pins cost the same, so having a lot of extra pins for extra busses means you can't cost reduce very well in the future. And of course a 32-bit bus means you need at least 2 extra DRAM chips, which makes your PCB larger which trickles into other costs such as case size and packaging and so on...

Next thing you know you have a Saturn, which is NOT a cost effective console. (But man it has a cool looking motherboard.

From a simplicity, performance, and cost perspective, scratchpad SRAMs are hard to beat!

http://www.atariage.com/forums/topic...5#entry1751375

All of these options are pretty expensive. Twin buses or exotic stuff like VRAM are 4-5x more expensive than commodities like small SRAMs and slow DRAMs. Unified RAM is a great way to save money. (That's one reason the cheaper XBox 360 has a more unified memory design than the pricier PS3.)

Engineers always try to add more capacity if they can. When you see these kinds of limits, it is always due to cost reduction enforced my management.

Small increases in component costs translate into big decreases in profits, especially when you are selling consumer electronics with razor thin profit margins in profit-hungry stores. I don't want this to be a lesson in the economics of mass production, but a $10 component increase often translates into a $50 price increase to the customer.

http://www.atariage.com/forums/topic...7#entry2004127

Again the weak spot we're all talking about is "texture mapping" and/or rotated sprites -- it's really the same feature, copying from sprite/texture memory to framebuffer memory. For standard and scaled sprites you can use the OP. For smooth shading and/or z-buffering you can use the blitter. (Crazyace didn't mention this but it's the main intended use case for the blitter and it's REALLY fast.) In both cases the bus utilization is very good -- these are the cases the designers focused on and they work close to optimally.

If you were designing the Jaguar and you knew texture mapping would be important, there are endless ways to rearrange the architecture to support it. Going to dual buses is one brute-force approach, this is exactly how the 3DO handled it. Using small on-chip buffers with the Jaguar's unified 64-bit bus is another approach that is cheaper/faster/more flexible but requires more design work.

(I find this one a bit interesting given Kskunk uses "brute force" in the exact opposite context that you did -multiple narrow buses being the less R&D-intensive "brute force" approach vs a wider unified bus with on-chip buffering being the more R&D-intensive but more cost-effective approach)

And this is from a PM discussion we had that ended up touching on some of Sega's engineering choices. (in this specific case in the context of the 53.7 MHz oscillator used in the MD -and the 50 MHz one in the MCD- along with a comment on the MD's use of PSRAM)

As for Sega's oscillators, you're right that it's probably a convenience thing. Using a clock that gets divided down makes circuit design much easier - that's why, for example, the old 8080 divided its clock by 4 and the 6502 was considered "clever" for using a single clock. The Jaguar is likewise "clever".

It's like Sega's use of PSRAM. Not cheap or efficient, but a lot easier to design in. I like Atari because their design style is like mine - pour more money into design and get a cheaper/easier to source product!

- KS

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.

And what I was saying was, even if they were planning on using the SH2, it would still make sense that they were working with SH1s in early prototypes (until late 1993 at the very least). The SH2 didn't even exist as a physical chip until October of 1993 (and test samples would have been available slightly later -full production probably not for several more months), and on top of that, Sega could have kept the SH1 as a fall-back option if there were problems/delays with the SH2. (if first silicon was bad, it could mean several months more before they got it right, and longer still until it reached full production, and even if first silicon wasn't delayed, there would have been problems with ramping up production)

On top of that, there's the specific description with the SH7032 (an SH1 with 8k scratchpad) is interesting supporting evidence of that. (I don't like going by tech information in most articles like that -and it certainly could be wrong here too- but quoting a specific model number like that is atypical of the usual vague/misinterpreted tech specs in such articles)

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 .

Well, the tech specs weren't lies either . . . they were/are genuine performance specs for the PS1, but the issue (as happens with many companies) is marketing taking them out of context. (same thing happened with many other consoles, CPUs, video cards, etc -peak/ideal performance specs/benchmarks that look nice but say little about the real-world performance -and even less than that to the layman)

SEGA used off the shelf chipsets that always makes your hardware prone to some faults.

Sega didn't use off the shelf chipsets until the Dreamcast, and it's the off the shelf parts of the Saturn (namely the CPUs) that were the least problematic.
Off the shelf hardware is usually more foolproof in general since it's an existing mass-produced product with existing tools/support/documentation provided by the manufacturer (and usually used in a variety of other products as well).

Custom parts OTOH are at the whim of internal engineering and management, but the advantage is (potentially) to have a more optimized/cost effective design than is available off the shelf while also avoiding licensing/royalty overhead of using a 3rd party design. (and the freedom to scale/consolidate the custom hardware as desired to cost reduce later models -something also possible with some off the shelf/outsourced parts, but depending on the specific contracts/licensing agreements made -ie the Xbox didn't do that, but the PS3/360/Wii did)
The more limited and costly the off the shelf options are, the more attractive custom parts become. (and, since the mid/late 90s, outsourcing/off the shelf parts have become increasingly competitive)

I just love your double standards.

No double standards, just different arguments from different points of view. (and the PS2 and PS3 are not directly comparable to the Saturn in the ways you imply)

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.

The PSX came out at a time where all competition was screwing up substantially and/or was too inherently weak (3DO, Atari, NEC, Commodore, Nintendo, and Sega all made massive mistakes).
Sony was the only one who didn't have botched hardware and/or management and/or business model and/or funding and/or PR at the time. (again, it was a perfect storm for them, sort of like Nintendo with the NES)

So, yes, the Saturn would have been the best next-gen option at the time since everything else was even worse in one way or another. (or more than one)
The Saturn would still have been just as problematic technically (perhaps less so management/marketing wise due to lack of Sony), and probably even more expensive (without Sony to drive down the price), but it still would have been better than anything else. (assuming the lack of Sony would have kept NEC from rushing the PCFX out and they'd waited a bit longer and released a complete system with 3D hardware included)

The Jaguar and 3DO could have been real threats if Atari and 3DO had had the resources/marketing/management to pull that off. (the hardware was weaker, but also much cheaper/cleaner -much, much cheaper in the Jaguar's case) Atari obviously had massive funding/management/PR problems, but 3DO's main problem was just their business model.

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

It goes a lot deeper than that, but that's already been covered above . . . and elsewhere many times before.

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

Correction, according to your EDGE article, it was a 27 MHz SH1 in early 1993 . . . and it couldn't have been even 1 SH2 until late 1993 (first silicon wasn't until October), though it's quite possible that they'd planned to switch to dual CPUs around the same time they switched to the SH2. (technically, if the SH1 was originally there in the CD-ROM subsystem on top of the main SH1, that too could have been considered dual CPU -though the way the final Saturn was configured didn't allow use of the CD SH1 in that manner -or at least Sega never provided documentation for that)

It's also, again, quite possible that they'd planned on switching to the SH2 when it became available, but used the SH1 in the interim. (and, again, may have switched to dual CPUs close to the time the SH2 did become available in late 1993)

[kool kitty89]

Actually, it's more flexible than that - the framebuffer doesn't restrict you to one type of pixel. You can have 16-bit paletted pixels in the same frame buffer as 16-bit direct RGB. It all depends on the source... a paletted texture will produce paletted pixels in the frame buffer, while a direct RGB texture will produce RGB pixels in the frame buffer. The most significant bit is used to distinguish between the two.

If a bit is reserved for that, then how can you have another bit available for priority and still have 15-bits left for RGB? (or does that mode drop per-pixel priority -or use 5-5-4 RGB?)

Yes - the saturn docs are way 'lower level' than the PS1 docs. But I would struggle to think of a complete game on either platform that didn't have the majority of it's code written in C. If anything, the low level access would allow the talented developers to get to grips with the saturn more than they were allowed to with the PS1.

Didn't Sony eventually provide full low-level documentation for the PSX? (opposed to the 3DO which only ever supported library-level programming -andonly using 3DO's libraries)

Having good high-level tools along with comprehensive low-level documentation offers the best of both worlds, albeit still within the fundamental performance limits.
Sony made a mistake not doing that for the PS2 like they had for the PS1. (and the far more advanced/complex -and flexible- architecture made it particularly difficult for 3rd parties to develop efficent in-house libraries -or resort to laborious low-level coding)

The Dreamcast did that right . . . and did so in spite of using the often-scorned "difficult" PowerVR architecture. (also notrious for meciocre drivers on PCs -albeit that seems to have been a pretty common complaint leveled at many cards of the mid/late 90s -including most of S3s cards and even many of ATis)

It seems pretty clear that the PS1 GPU is about 10-20% faster than the VDP1 based purely on fillrate. It also seems obvious that the Saturn outclasses the PS1 in overall processing capability.

That's only for sustained texture mapping and gouraud shading. (33M peak) Cached textures and flat shaded polygons are 66 Mpix/s. (also interesting to note that the jaguar's peak fillrate for flat or g-shading is 53.2 Mpix/s)

And while the Saturn has more general-purpose (CPU-style) resources, it still falls well behind the PSX's GTE for crunching 3D math.

The main issue for these systems reputations is how easy developing games on the PS1 using C libraries was compared to hand coding Saturn games in Assembly. I think the last two generations have proven well enough that assembly optimized platforms can still eventually reach their peak if they see a full life cycle. Most folks are still going to say that doesn't apply to the Saturn though, and some of those will then go on to say that the Jaguar was really competitive but misunderstood.

As alluded to below, the PSX also used a lot of assembly language optimization.
Both had C and assembly support for C programming (roughly equal), the major difference in programming was:
A. optimizing for dual CPUs and
B. (much more importantly) the PSX having a graphics API out of the box vs hand-coding VDP commands for the Saturn . . . and limited (initial) documentation on top of that. (documenation eventually got better and API support materialized too, but it took quite a while -and even longer for the API to be reasonably efficient . . . and even then porting games was tougher due to the feature-set mismatch with PC/PSX/N64 standards by that time)

By the way, my Jaguar crack was in regard to a present conversation over at Atari age and not directed at you at all. Yes the Jaguar was more than competitive with the 3DO and 32X, and with voxel engines it could have carved out its own slice of technical pie among the PS1 and Saturn too.

Compared to the 3DO (ease of programming aside), the Jaguar wouldn't hold up too well when texture mapped polygon games are concerned. (3DO hardware is much less flexible, but optimized pretty well for doing polygonal 3D -dedicated matrix coprocessor, fast texture mapping, hardware quad rendering vs the Jaguar doing rasterization in software with the GPU+blitter, having slow texture mapping, and needing the GPU or DSP to handle the 3D math as well -the Jag fares far better when used for gouraud shaded polygon games, or pseudo-3D games taking advantage of its flexibility -the 3DO coprocessor wouldn't be useful for doing ray-casting type games, and the Cel Engine isn't particularly useful for accelerating column renderers either -and the CPU is pretty weak compared to the Jaguar RISCs . . . which could even come into play for some polygonal games with particularly complex game logic/AI and relatively simple graphics)

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).

Yes, but catering to PR in such ways is extremely wasteful and counter-productive to profitability. (market analysts criticized Nintendo for milking the NES too long and then again with the SNES, but both cases were extremely healthy business decisions)

Hell, it's even good from a consumer perspective. (more software for a system you already have without shelling out for add-ons or a replacement, and more software for prospective buyers of said platform)

The issue is pushing PR in other areas for marketing/consumers as well as investors/analysts. (like pointing out profitability and viability on the market)
5 to 6 years is the normal turn-around time for a healthy/successful console with 7 years being the upper limit in a few cases like the Famicom.
Pushing hardware out more often than that reduces profits and stability (as a company and with consumers) and is normally only done if the preceding platform is a failure (or relatively limited success) as with the SG-1000 or Master System.
It's actually a bit ironic that Sega didn't do that with the Saturn/Dreamcast. (in fact, the gap from Saturn to Dramcast is the longest Sega ever went without releasing a new console or substantial add-on, nearly 4 solid years -vs 3 years from Mk.III to MD, MD to MCD, and MCD to 32x/Saturn and only 2 years from SG-1000 to Mk.III)

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.

The SH2s were off the shelf parts (and relatively large/complex parts at that -several hundred thousand transistors each), so Sega would have needed to commission Hitachi to make a custom dual-core version . . . costly and probably not worth it compared to sticking with 2 SH2s. (economies of scale and such -but perhaps cost-effective very late in the Saturn's life)

Then there's the bigger issue of the Saturn's many independent buses (there's the SH1/CD-ROM buffer bus- 16-bits, main CPU bus- 32bits, 3 VDP1 buses of 16-bits each, vdp2 at 32-bits, sound bus at 16-bits, and then the shared communication bus A and B on top of that). And remember, not only do you have the data lines to consider, but separate address lines for all of those buses too (and even with the multiplexed direct-DRAM mapping for the VDPs, that's still a significant number of added pins). The only other console close to that many external buses (ie not on-chip) is the CD32 if you count that as a console.

And having so many separate buses means that there's far, far less gain in efficiency when consolidating chips. (many, many fewer redundant/shared pins/traces that can be eliminated) On top of that, there's more hardware dedicated to interfacing and managing communication between all those buses (especially the shared communication buses -where the massive SCU comes into play -the highest pin count of any on the board at 208 pins . . . as many as the entire TOM chip on the Jaguar or ATi's RAGE I/II/Pro or S3's VIRGE, and unlike the Jaguar, the SCU is just one among many large/high pin-count chips on the board).
So pins and traces are a huge amount of the cost, and so is the necessity of independent RAM chips of specific sizes to fit into those buses. (so limited/no options for switching to higher density RAM chips later on)

The extreme opposite would be a unified bus system (like the N64/Jaguar/2600/A8/C64/7800/Xbox/360/ST/etc) which has the potential for massive savings when consolidating components (or very low cost from the start if already integrated -like the N64 and Jaguar) since everything shares a common bus and thus a huge number of traces/pins will be eliminated from the ASICs and PCB when consolidating things. (if JERRY were merged into TOM, the pin-count increase would be a small fraction of the 144 pins of JERRY alone, similar case if the N64 had the RSP and CPU merged)

The PSX's design is a bit in-between (more like the MD, PCE, Dreamcast, GC, PS2, etc) with 3 buses (2 32-bit and I believe 16-bit for sound) as well as using more common EDO DRAM for main RAM (albeit not as cheap/common as the FPM DRAM in the Jaguar/3DO/CD32) and only using exotic SGRAM for video. Plus investing the engineering resources to allow for highly integrated ASICs from the start (even early models used just 2 main ASICs for CPU/IO/GTE and GPU -with the rest of the board populated by a few small support chips, discrete components -caps/resistors/diodes/etc, and RAM chips)

Sony could also afford to push a more costly design due to their vertical integration and massive resources to invest in high volumes early on. (and also better able to afford selling at lower margins/higher losses)
Had they taken a more aggressive and cost-conscious design route (closer to the Jaguar in spirit -but more like the JagII in performance), the PSX's price could have been even more aggressive than it was.

The 3DO also falls in that in-between category, though it's actually a bit more cost-conservative than the PSX. (even from a 1993 vs 1994 perspective -only 2 buses, much more common/mainstream RAM -though the VRAM was still fairly costly- and a very simple/cheap CPU)

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.

I'm going by a generalized common-sense evaluation of the hardware design from the general engineering understanding I have (and comments on the subject from people active in that field).

At launch in Japan, Sony almost certainly was selling at considerably higher margins than Sega, even in Japan . . . they had significantly simpler/better integrated (and thus lower cost) hardware as well as a massive vertical integration advantage for manufacturing and (especially) CD-ROM royalties. (iirc they also used newer/denser 3.3V .5 micron ASICs from day 1, and while that may have incurred some added manufacturing overhead in 1994 -being so new- it also meant a savings on silicon -compared to larger/older processes- as well as power consumption and heat -smaller power supply and no need for cooling and higher clock speeds too- and set them up for even greater savings as .5 micron parts got cheap/common a little later on)

Sega either chose to limit the price of the Saturn (in spite of the cost) from day 1, or Sony's pricing was already coming into play even at the Japanese launch. (ie the Saturn may have been significantly higher priced if released without lower-priced competition on the horizon)

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 Saturn's raw performance capabilities are pretty impressive for the time. (even in 3D alone) That was never my argument.
The issue is the toll the hardware manufacturing cost took to accomplish that in the way Sega engineers chose.

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.

"Well thought out" is a matter of context I suppose. (in terms of cost-performance, it's not particularly good though)

[Crazyace]

I think it was confirmed by NAMCO that it was indeed CGI being played back and was only meant to give a indication of what was possible . Mind you we listen to Phil and SONY killzone II and Motostorm at E3 2005 were real time .

By CGI being played back it was the polygon rendering in realtime on the GS - just no 3D transformation of the geometry. You can actually see the aliasing that shows it's not a offline rendered movie.
( No comment on the PS3 stuff )

Yes Here's AM#2 and Yu Suzuki in 1994

"In AM~2 we use C for the 1st few steps and assembly afterwards. We managed to get the twin CPU's running at 1.8 times the speed of a single chip- that would have been impossible using C "

I actually read that as them writing the game in C and then optimising using assembly as needed ( like any games programmer does ) - but they are pretty hardcore at AM2

[Team Andromeda]

The SH2 didn't even exist as a physical chip until October of 1993 (and test samples would have been available slightly later -full production probably not for several more months), and on top of that, Sega could have kept the SH1 as a fall-back option if there were problems/delays with the SH2

? Why is that so different from other companies ? I'm pretty sure when SONY said Cell would be inside the PS3 it wasn't in full production . Its always a risk when developing a console that components will not be ready in time. You always go on about the N64 and SGI - when they 1st announced the deal I seriously doubt they had put all that silicon from a Indy into a tiny chipset that could run in a tiny console -given the company you had faith they could do it and I bet SEGA Japan had that same faith in Hitachi

Well, the tech specs weren't lies either . . . they were/are genuine performance specs for the PS1, but the issue

500,000 textures polygons a sec is making the PS sound way more powerful than even Model 2- SONY spun the truth and it totally lied about the PS3 being able to had dual 1080p displays and the laughable comment that the PS3 was so powerful is could handle games at 120 fps . SONY are like 3DO and Trip Hawkins when in comes to consoles.. born bullshits and spinners and where nobody does it better.

Sega didn't use off the shelf chipsets until the Dreamcast, and it's the off the shelf parts of the Saturn (namely the CPUs) that were the least problematic

The SH-4 and Power VR 2 were already on retail - Yes there were teaks here and then but they weren't developed only for the DC .

and the PS2 and PS3 are not directly comparable to the Saturn in the ways you imply

Of course they are. They're console and ones that just like the Saturn used chipsets that weren't friendly to developers , had poor lauches (in terms of ready software) and were a mess inside in terms of motherboards . But like usual you just
focus on the Saturn ...

Sony was the only one who didn't have botched hardware and/or management and/or business model and/or funding and/or PR at the time

SONY was a new boy and when you enter a markert for the 1st time you come in with no baggage and no bad habits. Now compare the clean low cost design of the PS its great tools and how it easy it was for developers to that of the PS 2 and PS3 . That's what happens when you're in the marker for a while and pick up bad habits. I'm betting MS will make a few mistakes with the 720/360 II - like if it even tries to make Kinect standard

The Saturn would still have been just as problematic technically

Like the PS 2 showed and even the N64 (a machine harder to code than the Saturn or so a lot of developers like Warp and Treasure ect made out) - That counts for sweet FA if you get market share you'll get development support.

The Jaguar and 3DO could have been real threats if Atari and 3DO had had the resources/marketing/management to pull that off.

Are you serious the jaguar was a joke with poor games and poor 3D graphics. It sounded great until one saw the games and then it was a complete and utter joke . 3DO would have been a serious threat if not for its laughable price point -its shame 3DO was a great console with in its short life some great games.

Correction, according to your EDGE article, it was a 27 MHz SH1 in early 1993

In the 1st issue of EDGE 1993 and in issues of Mean Machines SEGA , SEGA Pro and Mega in was just a 32bit RISC CPU running at 27 Mhz and being able to handle 16,000 to 32,000 polygons per sec

the use of SH only came into play mid 1994 onwards . Like I say the constants were the speed of the CPU, the fact that the Saturn could handle 5 playfields/backrounds and the 32 channels of sound

I actually read that as them writing the game in C and then optimising using assembly as needed ( like any games programmer does ) - but they are pretty hardcore at AM2

Nah there other interviews with AM#2 and it was all 100% assemble. There was also a interview with Mel vivid image and the Street Racer team and they all said Assembly was the way to go on the Saturn , when they tried to code Street Racer in C is was a complete disaster in terms of frame rate.

By CGI being played back it was the polygon rendering in realtime on the GS - just no 3D transformation of the geometry. You can actually see the aliasing that shows it's not a offline rendered movie

I though that was FF 8 PS2 footage . I'm sure Namco said in a interview it was running at all on a PS2 or development kit. The GT 3 and the fromSoftware demo's were real for sure

[Thenewguy]

Sega either chose to limit the price of the Saturn (in spite of the cost) from day 1, or Sony's pricing was already coming into play even at the Japanese launch. (ie the Saturn may have been significantly higher priced if released without lower-priced competition on the horizon)

Its worth noting that the Saturn was not cheaper in Japan, both systems were more expensive. Going by EDGE magazine's purchases at launch of both systems, the PS1 was launched for the equivalent of ~$400 and the Saturn was launched for the equivalent of ~$450

The Japanese seem happier to pay more for hardware than countries in the west, the pricing may have been based on surveys, and what Sony/Sega felt they could get away with.

Outside of the list prices EDGE notes that many stores were doing discounts on Playstation pretty much immediately after launch, EDGE themselves state their Playstation was ~$370. There's no mention of discounts on Saturn, but being that the system was selling like hot cakes and there was huge demand I don't see that heavy discounts were that likely.

[Crazyace]

500,000 textures polygons a sec is making the PS sound way more powerful than even Model 2- SONY spun the truth and it totally lied about the PS3 being able to had dual 1080p displays and the laughable comment that the PS3 was so powerful is could handle games at 120 fps . SONY are like 3DO and Trip Hawkins when in comes to consoles.. born bullshits and spinners and where nobody does it better.

The Playstation strengh actually came from lighting the polygons as well - this is why the specs for transform are so high, when you add lighting the figures drop. I'll stick with figures rather than hyperbole.

Nah there other interviews with AM#2 and it was all 100% assemble. There was also a interview with Mel vivid image and the Street Racer team and they all said Assembly was the way to go on the Saturn , when they tried to code Street Racer in C is was a complete disaster in terms of frame rate.

Street Racer did look pretty nice on the Saturn. - I think the PS1 version had slightly better track/scenery ( not just flat floors ) - but the sprites just weren't as big.

I though that was FF 8 PS2 footage . I'm sure Namco said in a interview it was running at all on a PS2 or development kit. The GT 3 and the fromSoftware demo's were real for sure

Everything was realtime - just some demos were also controllable, rather than just playing back gpu commands. ( Devkits - even the early gpu only ones had a lot more normal memory than the final PS2 )

[Crazyace]

Maybe I got the wrong impression from all those discussion with Kskunk, but his explanations (of hardware design decisions/tradeoffs for cost/performance/time/programmability/etc -in general and some comments specific to the Saturn) point to the design route taken by the Saturn to be extremely costly for the performance it provides. (the multiple independent buses being one of the fundamental cost-performance problems -more traces, pins, RAM chips, etc; bad for initial cost and also bad for scaling the design later on)

The thing is that to get the performance of the saturn without the seperate buses ( which are really just single chips rather than buses ) you would need to use much more expensive components - which may not have been available at the design phase anyway. So it's not as easy as saying 'just add a wider bus and some caches' - the pixel writes ( and simultaneous pixel reads for rotated scanout ) aren't in cache friendly patterns.

(I find this one a bit interesting given Kskunk uses "brute force" in the exact opposite context that you did -multiple narrow buses being the less R&D-intensive "brute force" approach vs a wider unified bus with on-chip buffering being the more R&D-intensive but more cost-effective approach)

I consider widening the buses and wasting the bandwidth to be brute force - also from R&D (for Sega) building on the succesfull designs you already have is less brute force than throwing everything away.
Another comparision would be to look at how you would match VDP2 on the Jaguar ( it has the bandwidth after all ) - it has no simple h/w solution for charmaps , and even if it did you would be incuring a lot of page breaks or less efficient fetches without adding a lot of extra caches to the ODP.

[Chilly Willy]

If a bit is reserved for that, then how can you have another bit available for priority and still have 15-bits left for RGB? (or does that mode drop per-pixel priority -or use 5-5-4 RGB?)

The msb of RGB pixels is NOT used for priority on the Saturn - it is ONLY used to distinguish RGB from paletted pixels. RGB pixels use a per-screen priority set in a register. If you wish per-pixel priority, you MUST use paletted pixels. It's actually illegal to use RGB values without the msb set when drawing to the frame buffer... other than 0x0000 - that is the transparent pixel for RGB mode since those pixels won't be stored to the frame buffer. All other RGB values MUST have the msb set. So to write black to the frame buffer, you must write 0x8000.

Didn't Sony eventually provide full low-level documentation for the PSX? (opposed to the 3DO which only ever supported library-level programming -andonly using 3DO's libraries)

Yes, when they did their Yarouse program, they released the docs on the PSX hardware. They did a similar thing when they released linux for the PS2, then providing docs on the PS2 hardware.

The Dreamcast did that right . . . and did so in spite of using the often-scorned "difficult" PowerVR architecture. (also notrious for meciocre drivers on PCs -albeit that seems to have been a pretty common complaint leveled at many cards of the mid/late 90s -including most of S3s cards and even many of ATis)

No, SEGA never posted docs for ANY of their hardware. Over the years, we've had LEAKS of the MK3/SMS/Genesis/CD/32X/Saturn docs. What came out for the DC was the already public SH4 and PVR2 docs. There is still no available docs for most of the rest of the DC hardware. Devs would particularly love to see docs on the AICA sound chip for the DC.

That's only for sustained texture mapping and gouraud shading. (33M peak) Cached textures and flat shaded polygons are 66 Mpix/s. (also interesting to note that the jaguar's peak fillrate for flat or g-shading is 53.2 Mpix/s)

Fill rates are particularly misleading. If you are interested, the peak theoretical fill rate for the 32X is 7 Mpix/s (for 256 color mode). If you crunch the numbers, that means you can completely redraw the entire display almost 100 times every second!!

[Team Andromeda]

Its worth noting that the Saturn was not cheaper in Japan, both systems were more expensive. Going by EDGE magazine's purchases at launch of both systems, the PS1 was launched for the equivalent of ~$400 and the Saturn was launched for the equivalent of ~$450

The Japanese seem happier to pay more for hardware than countries in the west, the pricing may have been based on surveys, and what Sony/Sega felt they could get away with.

Outside of the list prices EDGE notes that many stores were doing discounts on Playstation pretty much immediately after launch, EDGE themselves state their Playstation was ~$370. There's no mention of discounts on Saturn, but being that the system was selling like hot cakes and there was huge demand I don't see that heavy discounts were that likely.

The Mega CD and even Neo Geo CD cost more than the Saturn on their launches in Japan , but that was the price you paid for CD-ROM and Ram at the time , even the PC Eng FX cost 49,800 yen. So SEGA Saturn was always going to be expensive more so given it used a double speed drive and had the most RAM out of all the consoles bar the Neo CD (at the time). early 1990's CD based machines weren't cheap and while the Saturn came in at 44,800 Vs the PS 39,800 you have to bare in mind to save on a PS game you had to buy a £30 memory card , which people just don't factor in , same for the Western Saturn... where not only did you not have to buy a memory card to save, you even got a free game (virtual Fighter) and if in pal Land you got a £20 free Scart lead included too (along with a free game)

e the Saturn may have been significantly higher priced if released without lower-priced competition on the horizon)

Yes it was always going to come in at 40,000 to 44,000 Yen and SEGA made no secret of that that price was 1st talked about before we even knew the SH-2 connection. You need to remember SEGA not only gave a launch date before anyone had seen the PS. SEGA were the 1st to gave a actual street date and street Price too.

this is why the specs for transform are so high, when you add lighting the figures drop

Everything was realtime - just some demos were also controllable, rather than just playing back gpu commands. ( Devkits - even the early gpu only ones had a lot more normal memory than the final PS2 )

Which why they're bullshit . MS may very well claimed the 2001 X-Box can handle over 100 million polygons or that the Rave tech demo was real time and only using 25% of the X-Box total power, most will know those facts and fig's are meaningless and no game will ever use close to 100,000 polygons in game. I'm sure Namco said in a PS mag (for a bit of inorny) that no the RR PS2 tech demo was no running on any PS2 hardware as they simply didn't have the time or the experience of the Hardware to make a demo of that quality on unfinished hardware. Don't get me wrong too I know SEGA played the same game its self and well remember SOA showing off VF running on Model 1 and trying to pass it off as Saturn code, or that all DC games would run at 60 fps . They all play the game, but nobody does it better than SONY or 3D0 does or did.

Yes, when they did their Yarouse program, they released the docs on the PSX hardware

SEGA also did it's Yaroze copy for the Saturn in Japan . Are you sure they never was any docs to go with that . I can't remember for life of me what SEGA Japan called it, only that they did it and it lasted not very long

Street Racer did look pretty nice on the Saturn. - I think the PS1 version had slightly better track/scenery ( not just flat floors ) - but the sprites just weren't as big.

Street racer is running at a higher res mode, features full 3D sky, transparencies and reflections and is running at a near rock solid 60fps - In almost every area its looks way better and more impressive than the PS version. Plus of course you had a 8 player mode on the Saturn version

[kool kitty89]

The msb of RGB pixels is NOT used for priority on the Saturn - it is ONLY used to distinguish RGB from paletted pixels. RGB pixels use a per-screen priority set in a register. If you wish per-pixel priority, you MUST use paletted pixels. It's actually illegal to use RGB values without the msb set when drawing to the frame buffer... other than 0x0000 - that is the transparent pixel for RGB mode since those pixels won't be stored to the frame buffer. All other RGB values MUST have the msb set. So to write black to the frame buffer, you must write 0x8000.

Hmm, then I must have been wrong about how Sonic R's translucency effects work (since you couldn't do VDP1 pixel priority like that -to set in-front or behind translucent VDP2 layers on a pixel basis . . . I wonder how that effect is done then)

No, SEGA never posted docs for ANY of their hardware. Over the years, we've had LEAKS of the MK3/SMS/Genesis/CD/32X/Saturn docs. What came out for the DC was the already public SH4 and PVR2 docs. There is still no available docs for most of the rest of the DC hardware. Devs would particularly love to see docs on the AICA sound chip for the DC.

How did developers program for the older systems in that case? (wouldn't documentation be needed to handle low-level access . . . plus there was EA's reverse-engineering of the hardware to build their own tools and go unlicensed -before Katz talked them out of it)

I'm not talking publicly released documentation, mind you, but what officially licensed publishers/developers would have had access to.

Fill rates are particularly misleading. If you are interested, the peak theoretical fill rate for the 32X is 7 Mpix/s (for 256 color mode). If you crunch the numbers, that means you can completely redraw the entire display almost 100 times every second!!

Oh, I know that . . . the blitter fillrate isn't the limiting factor for 3D on the Jaguar by a wide margin. (rasterization is the biggest limiting factor for polygonal 3D -vertex computation is a big factor too, especially since the GPU would have to stop rasterizing to handle that -unless you used the DSP . . . and that's got the choked 8.8 MB/s bus limitation to consider -and then there's game logic overhead for the GPU on top of that . . . or choking the system if using the 68k for that)

Its worth noting that the Saturn was not cheaper in Japan, both systems were more expensive. Going by EDGE magazine's purchases at launch of both systems, the PS1 was launched for the equivalent of ~$400 and the Saturn was launched for the equivalent of ~$450

The Japanese seem happier to pay more for hardware than countries in the west, the pricing may have been based on surveys, and what Sony/Sega felt they could get away with.

Outside of the list prices EDGE notes that many stores were doing discounts on Playstation pretty much immediately after launch, EDGE themselves state their Playstation was ~$370. There's no mention of discounts on Saturn, but being that the system was selling like hot cakes and there was huge demand I don't see that heavy discounts were that likely.

I was talking about those prices though. The $400 PSX vs $450 Saturn is a much smaller gap than the hardware (and especially Sony's vertical integration) would imply, so it's almost certain that Sega was selling at lower margins than Sony to achieve that.