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

[Crazyace]

What I'm commenting on are more hack-ish options . . . a "perfect" example would be far, far better and more in line with the jaguar 2's design philosophy. (but within practical 1993/1994 limitations . . . well Atari's funding/resources limited that a lot more anyway)

I think that adding a seperate bus on to the Jaguar was way more than a hack. Just fixing the known h/w bugs would have improved things ( like the gpu/dsp running code out of main memory, and the dsp running slow bus cycles ) - and I still think that the only thing that really stopped the jaguar being more succesfull was not having a CD at the start.
Cartridges were way more expensive, and a CD at the start would allow publishers to support Atari with less risk.

In the JagII manual they have a intersting timing breakdown for texturing 4 pixels on the original Jaguar.

4 x ( rowchange + read + r/wbuschange + rowchange + write )

4 x ( 3 + 2 + 1 + 3 + 2 )

This gives 44 cycles for 4 pixels ( 11 cycles per pixel )

Using a 2 pass renderer the bus activity per 4 pixels would be 3 + ( 4 x 2) + 3 + (1 x 2) ignoring the blitter setup , so 16 cycles ( 4 per pixel ). If texturing a 16 pixel span the bus cost would be less than 3 cycles per pixel - which is a lot faster than 11, without any hardware changes.

[saturndual32]

So, Crazyace, there was quiet a bit more untapped potential on the Jag for texture mapping, without any hardware revisions. Having stuff like Skyhammer at say... 4 extra frames per second would make quiet a diference to me.

[Crazyace]

I dont know - I think that the later games were using faster texture mapping routines already. Nothing really would make the Jaguar match the Saturn for texture mapping, let alone the PSX or N64.

[kool kitty89]

I think that adding a seperate bus on to the Jaguar was way more than a hack.

How about an external cache a la MSTE? (at least if that was cheaper than using a 68EC020 or 486SLC . . . well, actually a 26.6 MHz 386SX probably would have been a lot better than the 68k -and facilitate PC ports to some degree as well, though limit Amiga/MD ports)

But how hard would it have been to configure a local bus for the 68k? (not a 2nd system bus, but memory only mapped/interfaced to the 68k itself, outside the address range of the main system . . . though since the 68k is limited to 24-bits of space, so you'd probably end up using a bank switching mechanism to page between the Jaguar and local bus/map)
I think flare's notes in the Slipstream documentation also mentioned plans to include a local bus for the 8086 and avoid contention (when not accessing Slipstream memory).

And technically the CoJag DID add a separate bus to the Jag via the 2nd port of the VRAM bank (unless both ports were mapped to the main bus, which sort of defeats the purpose of VRAM).

But again, a local 68k bus (or external cache) might have ended up more expensive than better CPU options on the main bus alone. (especially if RAM1 was implemented to reduce contention overhead -namely for page breaks)

Just fixing the known h/w bugs would have improved things ( like the gpu/dsp running code out of main memory, and the dsp running slow bus cycles )

Obviously that would have been best for cost/performance, so would have been making the system self-booting (and with bug-free J-RISCs, even with no cache, the assembler would be fine and good compilers would be much more forthcoming).
However, that's a lot of wishful thinking that they could have addressed all those bugs, even if they'd kept the hardware design going into 1993 (rather than freezing it in mid/late 1992) and pushed the release back to fall of 1994. (and that definitely would have required more risk of private funds or loans at unfavorable rates -the 1993 jag text market hype drummed up investor interest and boosted PR/stock value, so they'd have to compensate for that in other ways to hold out for a single launch in mid/late '94 . . . well, since that hype generation focus was part of dropping the ST/Falcon and reducing Lynx emphasis, they might have gotten by by continuing ST/Falcon support and marketing -at low budget/low key levels- in Europe and pushed the Lynx more, at least in Europe -1993 might have been time for a 3rd major revision of the Lynx . . . reflective color LCDs might have been reasonably acceptable at that point too -making for a huge possibility for a "Lynx Jr" with unlit screen, lower price, smaller form factor, and much better battery life)

The only totally open options without any hacks at all as the design was in 1993 would have been a different CPU (given the flexible nature of the host processor interface) and varying RAM configurations within the 2x 4MB RAM1/0 banks. (well, that and more potential for PCB design, like adding a general purpose expansion port including addressing for RAM1/0 and direct full-speed 75 ns system RAM expansion or extend the cart slot's addressing/signals to facilitate expansion there . . . though you'd be limited to 32-bits without a major increase in pin count)

and I still think that the only thing that really stopped the jaguar being more succesfull was not having a CD at the start.

Cartridges were way more expensive, and a CD at the start would allow publishers to support Atari with less risk.

Yes, that is definitely true, though the RAM made for compressed carts too.
And such lower risk would mainly have garnered more support with low quality ports/multiplatform games, or stronger support from small/budget developers on the better side of things.

Though the multimedia support is undeniable . . . Atari REALLY should have had an analog audio mixing line of the cart slot though, having to stream CD-DA as PCM to the DSP was unnecessary (though rather modest) hit to the main bus. (Sega CD did CD-DA totally analog -CD chipset did the decoding to internal DAC then mixed it with MD analog audio . . . as did pretty much every other system supporting CD-DA -any other streaming audio couldn't be decoded by the CD chipset though, so lower quality PCM, ADPCM, etc would need to be decoded and played by other hardware in the system, though in the MCD and PCE CD's cases, that hardware sound output is also mixed on the analog end with the PCE/MD sound )


For sheer low-cost, 1.44 MB floppies might be a decent option (technically more expensive than CD-ROM, but much cheaper due to volumes and competition -CD-ROM would take a bit longer to get really competitive with aggressive pricing and low margins), but then there'd be the piracy threat too. (they could have offered a cart slot too, for developers wanting to avoid such threat and who could afford the risk of ROM -better still if the cart slot was made flexible for RAM expansion)
OTOH, the computer game market was booming in spite of Piracy, and 1993 just started to see major CD-ROM releases on PC. (with floppy versions of most games for a while longer, not to mention Europe's computer market)

The lack of CD was a pure cost issue, though that itself was a conflict (low cost media vs low cost base unit), but floppy drives were much more affordable at the time and definitely would have been a smart move for catering to a low-cost oriented console. (and would have made many computer game ports a lot more realistic without heavy cuts or very large ROM sizes -RAM limits would still force trade-offs though)
One problem with that is that a floppy drive would be needed for backwards compatibility when CD became supported, though that might also make for a great low-cost memory card option at much higher capacities than anything pre-PS2.

Konix was going the floppy disk route (880k Amiga format was planned) in 1989, it would have been interesting to see how that played out. (or if Atari had licensed the Slipstream and scrapped the Panther in 1989 -it would be interesting to know if Brennan ever tried to pitch that to Atari, the Slipstream was a non-exclusive license to Konix after all)





However, I disagree that it could have saved them if management/marketing wasn't any better (let alone existing PR) . . . those factors are far more important than hardware in most cases, and in 1993 the cost of CD was still a huge issue (Nintendo's decision with the N64 with planned 1995/96 release was just stupid though), but 1993 (especially with Atari's limits) would be a major trade-off.

And on the marketing/management end, Atari's options were limited. Well, for management, it just seemed to be poor in some areas in general (exacerbated by limited funds too), and the options on the funding end would have been risking large amounts of private funds and/or heavily deficit spending with investors/creditors (Sega did both the Dreamcast, and it DID pay off in the US market as far as good PR, good support -hardware/tools helped there a lot too, very good sales -especially considering the bad PR from Sega's mid 90s mess, but also a lot of short-term dept that would only have been recouped with long-term success of the DC -and it went nowhere fast in Japan and got botched in Europe, so a primarily US market crippled that further -one could argue it might have worked in the long run, but Sega obviously chose to cut their losses rather than taking that risk -of course, that decision alone also meant a massive hit to PR and stock prices, so there were risks either way)

Atari's lack of PR (or notice in general) in the US market would have meant Dreamcast (or Genesis) level spending/marketing to get a realistic position in the US. (and poor management of that marketing budget would ruin them . . . Sega had a massive budget with the SMS, initially ahead of Nintendo and always far head of Atari -by more than an order of magnitude at times iirc- but they failed to manage that marketing effectively in the US and lagged well behind Atari in US market share up to late 1989 . . . which also shows a major potential loss in a potential 4th gen console release around 1989/1990)

EDIT:
. . . It was stuff that happened before the Jaguar (declining computer market and lack of a 4th gen game console were both massive issues -the latter probably the most important factor in the US). They really needed a decent (if not great) 4th gen console offering, even the Panther (as it was) would probably have been a lot better than nothing (an ST derived console might have been more developer/port friendly, though probably with less raw 2D power than the Panther), the Slipstream would have been an interesting option (decent and flexible 2D and very interesting 3D potential), or pushing for a late 4th gen console prior to the jaguar. (like pushing Flare to design a more conservative, short term design in line with some of the jaguar concept -and intended to be forwards compatible- but feasibly ready for market by late 1991 . . . be it just a simpler all-new design with similar Slipstream+Panther conceptual basis, or heavier bias of the older design(s) depending on what was faster/cleaner -or using part of the older design(s) more directly along with new hardware, like a slower clocked jaguar aiming at .8 micron tech without the GPU or DSP but perhaps with a tweaked and up-clocked derivative of the Flare DSP for 3D/coprocessing support)
And then there's the offer in 1988 to distribute the MegaDrive in North America that Tramiel couldn't agree on (with some understandable reasons -the main one being that they'd have no direct input on the European market . . . and given the huge ST market in Europe in '88, that's quite a conflict of interests, plus Atari's in-house console projects -of course, none of which amounted to a 4th gen entrance in the end), and the mounting management problems under Sam Tramiel. (Katz leaving in early 1989 compounded that issue)


However, even if Atari didn't risk any more funds, but did manage some smarter management, they might have had a chance as a niche market in the US, but far more possibility for a real mass market position in Europe due to much better PR and brand recognition, much lower cost of marketing for that region (and effective viral marketing), great EU software support, etc.
They'd have no chance in hell for Japan unless they licensed it to a label who could sell it in Japan. (it was a hell of a lot better than the PC-FX too, but licensing it to NEC would have been iffy, but cool to think about -maybe they could have gotten a good deal on the V810 CPU and NEC CD drives as well )

In the JagII manual they have a intersting timing breakdown for texturing 4 pixels on the original Jaguar.

4 x ( rowchange + read + r/wbuschange + rowchange + write )

4 x ( 3 + 2 + 1 + 3 + 2 )

This gives 44 cycles for 4 pixels ( 11 cycles per pixel )

Using a 2 pass renderer the bus activity per 4 pixels would be 3 + ( 4 x 2) + 3 + (1 x 2) ignoring the blitter setup , so 16 cycles ( 4 per pixel ). If texturing a 16 pixel span the bus cost would be less than 3 cycles per pixel - which is a lot faster than 11, without any hardware changes.

Neat, that sounds like it would be approaching the Saturn's peak VDP1 bandwidth too. (especially for 26.6 MHz VDP mode)
I'm not sure on the exact timing, but it shouldn't be faster than 2 clocks per pixel (and only when you avoid page penalties).

Of course, for actual 3D stuff the jag has to deal with GPU+blitter cooperation vs hardware quads on the Saturn (and more resource for vertex plotting -DSP and both CPUs). And even if you did do apples to apples with a CPU assisted line by line triangle rasterizer on the Saturn, you'd be able to do much easier multitasking due to the ability to buffer lists of drawing commands into VDP1 RAM. (if you got the GPU working in main, you could buffer blitter lists in local and have more parllel work too)


There was also an interesting possibility for a triangle (or warped quad) rasterizer other than line by line rendering via scaling/rotation based 2D blitter hardware mentioned here:

If you're using the ASIC you may as well just try textured polygons =P

Go and try the 3D globe widget for Opera. Technically it's just a ZIP with HTML and javascript code inside, so it should run on any browser if you unpack it (EDIT: well, any browser that supports 2D canvas). Look at the way it stores textures and you'll see how it'd be possible to do textured triangles with the ASIC.

and more:
http://www.sega-16.com/forum/showthr...phics&p=367072

I dont know - I think that the later games were using faster texture mapping routines already. Nothing really would make the Jaguar match the Saturn for texture mapping, let alone the PSX or N64.

The more untapped potential is for flexible rendering of 3D/pseudo 3D, including voxel engines (and height maps in general). Sparing use of polygons with even more sparing use of textures (optimization for gouraud shading and CRY in general), heavy use of scaled sprites, and mixed use of Doom/duke 3D style textured height maps and voxel stuff.
Amok would have been interesting to see done on the jag.
It's a bit of a shame that there was no Commanche port or emphasis on height map engines in general. (Cybermorph using Commanche style voxels -let alone Phaze Zero type interpolated stuff- would have looked pretty awesome and probably run faster too -that game really needed nice 2D backgrounds though)

I wonder if doom type column rendering would be faster via GPU+blitter using software assisted texture mapping, or using the blitter's scaling/rotation feature and rendering columns as lines (probably as chunks into a buffer in local RAM) and then rotating 90 degrees and plotting to the framebuffer (and doing the floor/ceiling as a fine pass). I was talking about doing this on the Sega CD with Chilly Willy.
Or maybe you could even do walls with each column being a separate scaled OPL object.

I wonder how Carmak did it.


Another possibility is doing what Chilly Willy has with the 32x Yetti 3D demo (large screen size, but low resolution and blocky pixels), except better on the jag since it can do true low-res frame buffers (and flexible res in general) due to the object processor, while 32x is fixed at 6.7 MHz dot clock and 320 pixels. (the line table allows variable vertical resolution, but not horizontal . . . and a 1/2 res mode would have been great for some things, especially use of the 16bpp mode -which is what Yetti uses, though you could do pseudo 1/2 res 16bpp with dithered pairs of paletted 8bpp stuff)


Actually, given the number of rather choppy Jag games, dropping resolution probably should have been pushed much more often. Doom definitely made the sacrifice, and AvP definitely should have (not only easing fillrate, but halving the rays to cast), or variable detail options could be used. (which could include variable screen size as well as resolution)
Lower res would obviously also take less framebuffer space.

3DO Doom had variable screen size, but oddly forced high detail mode . . . given that low detail should have roughly doubled the framerate at a given screen size, that would have been a huge boost to performance. (probably bringing it close to 32x levels)

[kool kitty89]

Not sure if you saw my last edit (crazyace, I saw you tagged as viewing the thread), so I added "EDIT" in bold to mark the added paragraph.

[Crazyace]

I think that fixing bugs is way more believable than adding extra buses, or caches, or different processors, and in 1993 I also think that a single speed CD ( like those found on the Sega CD and PC engine CD ) would be cheaper than a 1.44MB floppy - especially as Atari didn't use a CD-rom controller, just an audio CD -controller.

Regarding the speed comparision with Saturn for the 'best case' texture mapping - don't forget that the object processor would steal cycles from the blitting, and there would be gpu overhead for both the blitter setup, and also the 3D transforms.

[TVC 15]

Sorry if I'm derailing a Jag centric discussion, just have a quick question about the Saturn (another one, sorry!).

Whats the most limiting factor in the Saturn overall 3d performance. Is it using a general use processor in the case of SH-2's for 3D math, lacking a dedicated 3D transform engine that limits its overall performance. Though arguably some very tight coding could use both cpus for geometry transforms, the Shenmue tech demo probably uses both for its cutscene engine when game logic and A.I are not needed.

Or is it the VDP1. It has been mentioned (not sure if it was Chilly or Kool Kitty) that overall the PSX GPU (NOT GTE) has a much higher overall bandwidth and pixel throughput, regarding overall best case scenarios of MegaPixels per second.

And, what overall would have been the best way to solve some of these problems and limitations depending on the Saturns biggest fault. This is also not from a theoretical perspective, i.e altering the Saturns chipset, but through actual real coding practice, i.e with culling methods for example. Or is their only so much that could be done, if the Saturn really was lacking.

[kool kitty89]

I think that fixing bugs is way more believable than adding extra buses, or caches, or different processors

External cache (and added bus moreso), perhaps, but changing the CPU used should have been very straightforward on the engineering end since the design was inherently meant to be flexible for different CPUs (intended to accept any x86 or 68k arch chip given Kskunk's comments . . . and by extension, also had little problems adapting to most other processors on the market sine most used x86 or 68k-like bus interfaces or a combination of the 2).

The issues with changing the CPU would be component cost (for a more expensive CPU), associated negotiation for a good high-volume price, possible added cost to the motherboard (namely if a 32-bit CPU bas was used, meaning at least 16 more traces for the CPU and 16 more for JERRY -and obvious performance improvements), and deviation from the set-up established for the early dev tools and documentation going out in early 1992. (though a 68k architecture chip would be less problematic on that end) The BIOS would need to be modified too. (and of their options, the cheapest next step up would probably be a 386 SX, 68EC020 -preferable, maybe x86 SLC chip, or maybe an ARM60 or ARM2/ARM3 if embedded versions of the ARM2/3 were available similar to the cacheless ARM60 -AM386DX, let alone DLC was probably still to competitive in the mid range to consider for a low-cost embedded option, though maybe they could get a good deal, as would probably any RISC with a cache or 68EC030 -maybe the SH-1 would be cheap enough; a lot is up to marketing and margins rather than actual manufacturing costs, especially for chips being used in midrange desktop computers)

Changing things after the mass production tooling was set-up would obviously be extremely wasteful and force a lot of unnecessary overhead. (but that's beyond "last minute" in the way I meant it)


Changing the RAM configuration would have similar trade-offs. The chips already supported up to 8 MB of 64-bit FPM DRAM in 2 banks, so anything within that should have been an option. (cost being the main factor to consider) Switching to 8 128kx8-bit DRAMs for a 1M 64-bit bank and a 2nd 16 or 32-bit bank (whatever the CPU bus width was) with 2 256kx16-bit chips or 2 512kx8-bit chips. (unless they dropped below 2 MB)


Neither of those things would require bug fixes, and (assuming the change in plans was done before any mass production board design or tooling was set down), shouldn't have significantly delayed things either. (just added to component and possibly manufacturing costs)
I believe the CoJag made its changes without modifications to the custom chips either.


OTOH, bug fixes wouldn't have added to component costs, but would have necessitated extended development time. (and Atari would have had to find another way to hang on in the short run -obviously, if they COULD address all the major bugs on top of a strong launch lineup for fall 1994, they'd have been a lot better off, but they'd need to do things differently to hold on that long -again, probably some degree of private investment, and probably pushing the ST/Falcon longer in Europe as well as maintaining/expanding the Lynx)
That, or changing decisions/management much earlier on than mid 1992. (things that would have avoided the steep decline of their European computer market and near absence in the game console market from 1990 onward) But that's another topic and one I already started drifting off to earlier.

[quote]and in 1993 I also think that a single speed CD ( like those found on the Sega CD and PC engine CD ) would be cheaper than a 1.44MB floppy - especially as Atari didn't use a CD-rom controller, just an audio CD -controller.[quote]
CD-ROM drives were obviously fundamentally cheaper to manufacture than floppy drives (as kskunk mentioned -with the exception being basic low density floppy drives), but the question is whether the actual pricing was lower due to high margins on a premium product, heavy licensing/royalty overhead, and limited competition.

In the long run, CD would obviously be a winner, but, as it was, Atari couldn't afford to overlook the short run . . . at least not without risking a ton more than they did. (private funding and/or much heavier investment spending)
Well, if the margins were kept the same and just the price went up, then they wouldn't risk that either. (just risk going further and further out from the $150 price point goal . . . though the attractive CD media -from content and cost/price perspective of users and developers would be huge)

But yeah, if they could get basic, cheap 1x CD drives for as little (or less) than DS 3.5" floppy drives an HD controllers (like in the STe/TT/MSTe/Falcon), even in 1993, then that would definitely be preferable by far. (unless an existing stock from the ST would have offset that initially)
They definitely shouldn't have bothered with the expense of licensing a CD-ROM chipset, at least not until later on (once sales had proved strong and they had the revenue and favorable investor interest to better afford such investments), just buy off the shelf audio CD drives and chips for early models. (not sure if Sega licnesed theirs or not)

Another thing would be the need for interface logic to communicate with the super low-level CD controller (the Jag CD used an in-house ASIC for that, so more R&D unless off the shelf logic was used for early models). Sega used super low level CD-ROM interfaces too (on the Sega CD and Saturn) with the Sub CPU and SH1 handling CD-ROM data transfers and managing the cache/buffer. (slaving the jag's 68k for that purpose might have been sensible . . . even without a separate bus like the Saturn/MCD -though the CD-ROM cache/buffer would be off the main bus in any case-, offloading to the 68k might be quite useful since it's a CPU time/resource intensive issue and not really a bus intensive one -or not so much intensive either, but difficult to multitask with)

The Sega CD used an off the shelf Sanyo LC89515K CD-ROM/CDi error correction and host interface LSI, so Atari could have opted for something like that rather than going custom. (custom is cheaper in the long run, but less foolproof and can be costly in the short run -I wonder if the use of dense .5 micron ASICs really paid off for the volumes Atari was working with, and obviously didn't pay off nearly as much as it could have with million sales volumes -ie at least in the rage of the 7800 in the US or ST/Lynx in Europe)


Of course, there's still all the funding/management/software R&D/licensing/marketing issues aside from the tech stuff. (and more tech+management issues too, like investing more in good development tools -in hindsight, commissioning id probably would have been one of the best options given Carmak was one of the few if not only jag developers toput together a real tool set with reasonable compiler support for the RISCs -not sure if he implemented a main code workaround or not)

Regarding the speed comparision with Saturn for the 'best case' texture mapping - don't forget that the object processor would steal cycles from the blitting, and there would be gpu overhead for both the blitter setup, and also the 3D transforms.

If you wanted to do a true triangle rasterizer on the Saturn, you'd also have that set-up overhead . . . but have the VDP on a separate bus you could buffer drawing command lists into and keep a lot more parallel work than the jag. (for Quad engines the Saturn is obviously much better . . . though the DSP would be easier to use with triangles -or SH2s for that matter, though the software floating point support was pretty decent and the option taken by some developers to ease the use of quads)

But yes, having the separate frambuffer scanning bus (a la VDP2) frees things up more too, on top of other advantages. (totally different design cost though, and arguing cost to performance ratio is another thing entirely)

[Crazyace]

In some ways I was thinking not of 'bug fixes' - which would involve more time , but instead 'not having those bugs' ie having the chipset work.
If the gpu/dsp could run code from main memory as designed, then having a better processor than the 68k wouldn't be necessary ( and even having a 68k at all would be questionable ) - devs could run game code on the dsp ( freeing up the gpu for blitter control and 3D work from local ) in main memory, with audio running as interupt driven from the dsp local memory.

For true triangle rasterising on the saturn it just involves setting 2 coords to the same point, so it's not really a massive overhead in setup ( performance and texture prewarping are other issues )

[Crazyace]

Whats the most limiting factor in the Saturn overall 3d performance. Is it using a general use processor in the case of SH-2's for 3D math, lacking a dedicated 3D transform engine that limits its overall performance. Though arguably some very tight coding could use both cpus for geometry transforms, the Shenmue tech demo probably uses both for its cutscene engine when game logic and A.I are not needed.

Or is it the VDP1. It has been mentioned (not sure if it was Chilly or Kool Kitty) that overall the PSX GPU (NOT GTE) has a much higher overall bandwidth and pixel throughput, regarding overall best case scenarios of MegaPixels per second.

And, what overall would have been the best way to solve some of these problems and limitations depending on the Saturns biggest fault. This is also not from a theoretical perspective, i.e altering the Saturns chipset, but through actual real coding practice, i.e with culling methods for example. Or is their only so much that could be done, if the Saturn really was lacking.

I think the biggest limitations for the saturn were the transparencies and dithering for 3D. Everything else was just performance , and even the quad rendering was a mixed blessing as a lot of subdivision methods worked on quads anyway, and heightfields would decompose to quads as well. Only having 8bits in high res for VDP1 was also an issue ( although it didn't affect VF2 )

[kool kitty89]

In some ways I was thinking not of 'bug fixes' - which would involve more time , but instead 'not having those bugs' ie having the chipset work.
If the gpu/dsp could run code from main memory as designed, then having a better processor than the 68k wouldn't be necessary ( and even having a 68k at all would be questionable ) - devs could run game code on the dsp ( freeing up the gpu for blitter control and 3D work from local ) in main memory, with audio running as interupt driven from the dsp local memory.

Yes, but best laid plans and all that. :P

Though better R&D funding might have made for faster/smoother development in general . . . and may have given Flare the confidence to fundamentally design the system around their custom RISC architecture as the only general purpose (CPU, etc) processors used at all. (aiming at a cache would be nice too, but obviously more work and more possible bugs . . . though with just TOM and JERRY, they might have pushed a bit more into JERRY and enlarged the scratchpad a bit with a total die size closer to TOM's -I was of the impression that JERRY is about 20% smaller than Tom)

Even then, you couldn't totally be foolproof against bugs and delays. Maybe if just 1 J-RISC was used you might manage a bug-free set-up, maybe even with a cache. (actually, if you did that and put the RISC on its own ASIC and graphics stuff on another, you could have the RISC working without contention for the scratchpad and potentially more space to cram other things in either ASIC -given the general size of the RISC, moving the UART and other I/O stuff to the video ASIC would make more sense, probably with a significantly larger local for video too, and maybe a moderately larger one than JERRY had for the RISC if not a cache -having the on-chip DACs working properly and adding DMA PCM support, or at least FIFO buffers -especially with interrupt for full/empty rather than just flags like the 32x- would have been a lot more useful than the bare DACs JERRY got)

For true triangle rasterising on the saturn it just involves setting 2 coords to the same point, so it's not really a massive overhead in setup ( performance and texture prewarping are other issues )

If you wanted to avoid overdraw and texture prewarping (let alone make use of gouraud shading), line by line rasterization could make more sense, but require more CPU overhead, obviously.

On another note, rasterizing Jaguar style should also work around the transparency bug (as it only occurs for warped drawing modes and you'd be drawing in the scaled/rotated 2D mode, like the jaguar or Sega CD).

I think the biggest limitations for the saturn were the transparencies and dithering for 3D. Everything else was just performance , and even the quad rendering was a mixed blessing as a lot of subdivision methods worked on quads anyway, and heightfields would decompose to quads as well. Only having 8bits in high res for VDP1 was also an issue ( although it didn't affect VF2 )

Yes, the actual difficulties, but the performance differences would be significant to compare as well.
The drawing bandwidth of VDP1 vs the PSX GPU seems to have been a major bottleneck for 3D games, with CPU resource being less of an issue. (even with 1 CPU was near maxed with 3D math -if the DSP wasn't used for that, you wouldn't be too far from the PSX in CPU grunt, but actual graphics bandwidth is a separate issue . . . and you also get less texture RAM for average games compared to the PSX . . . though you could shuffle around things in other memory for added textures, maybe even un-used framebuffer space)

The Saturn was OK in pure performance nevertheless, certainly adequate for the generation, but Sega's management issues (including shaky development tool support), and the cost effectiveness of the hardware were another story. (made worse still by Sony's shockingly low pricing of the PSX on top of their somewhat cheaper hardware and vertical integration on top of that)




And with the 8-bit comment, do you mean that VDP1 could only do 8-bit reads/writes in 256 color mode? (so no improvement in pixel rate over 16-bit mode -not even plain 16-bit block copy/fill support, let alone read/write buffers for scaling/rotation/warped stuff)

Does the 3DO have any buffering to make use of the 32-bit bus while texture mapping? (or for plain 2D blits for that matter)

[Crazyace]

Yes, but best laid plans and all that. :P

Though better R&D funding might have made for faster/smoother development in general . . . and may have given Flare the confidence to fundamentally design the system around their custom RISC architecture as the only general purpose (CPU, etc) processors used at all. (aiming at a cache would be nice too, but obviously more work and more possible bugs . . . though with just TOM and JERRY, they might have pushed a bit more into JERRY and enlarged the scratchpad a bit with a total die size closer to TOM's -I was of the impression that JERRY is about 20% smaller than Tom)

Even then, you couldn't totally be foolproof against bugs and delays. Maybe if just 1 J-RISC was used you might manage a bug-free set-up, maybe even with a cache. (actually, if you did that and put the RISC on its own ASIC and graphics stuff on another, you could have the RISC working without contention for the scratchpad and potentially more space to cram other things in either ASIC -given the general size of the RISC, moving the UART and other I/O stuff to the video ASIC would make more sense, probably with a significantly larger local for video too, and maybe a moderately larger one than JERRY had for the RISC if not a cache -having the on-chip DACs working properly and adding DMA PCM support, or at least FIFO buffers -especially with interrupt for full/empty rather than just flags like the 32x- would have been a lot more useful than the bare DACs JERRY got)

I think having the 68k was important at the time for getting ports done - fixing the onboard DAC would have saved money as well, but I'm not as bothered as you are about the need for DMA PCM. After all a lot of the reasoning behind the DSP was to synth sounds rather than just playback PCM.

If you wanted to avoid overdraw and texture prewarping (let alone make use of gouraud shading), line by line rasterization could make more sense, but require more CPU overhead, obviously.

On another note, rasterizing Jaguar style should also work around the transparency bug (as it only occurs for warped drawing modes and you'd be drawing in the scaled/rotated 2D mode, like the jaguar or Sega CD).

True - but the VDP1 drawing control blocks take a lot of memory, and line by line might hit limits there.

Yes, the actual difficulties, but the performance differences would be significant to compare as well.
The drawing bandwidth of VDP1 vs the PSX GPU seems to have been a major bottleneck for 3D games, with CPU resource being less of an issue. (even with 1 CPU was near maxed with 3D math -if the DSP wasn't used for that, you wouldn't be too far from the PSX in CPU grunt, but actual graphics bandwidth is a separate issue . . . and you also get less texture RAM for average games compared to the PSX . . . though you could shuffle around things in other memory for added textures, maybe even un-used framebuffer space)

The Saturn was OK in pure performance nevertheless, certainly adequate for the generation, but Sega's management issues (including shaky development tool support), and the cost effectiveness of the hardware were another story. (made worse still by Sony's shockingly low pricing of the PSX on top of their somewhat cheaper hardware and vertical integration on top of that)

I assume that, as the saturn forward textures it breaks a page with every pixel write ( although a Morten ordering on the write addresses might have helped ) - which is comparable to the Jaguar reads breaking pages. ( The PSX would be worse if every read was a texture cache miss ) and that is the limit for texturing

And with the 8-bit comment, do you mean that VDP1 could only do 8-bit reads/writes in 256 color mode? (so no improvement in pixel rate over 16-bit mode -not even plain 16-bit block copy/fill support, let alone read/write buffers for scaling/rotation/warped stuff)

Does the 3DO have any buffering to make use of the 32-bit bus while texture mapping? (or for plain 2D blits for that matter)

[/QUOTE]
I was just commenting on the fact that in highres (640etc) modes VDP1 doesn't support 16 bit pixels, only 8 bit - so no gourard shading or lighting on highres without a lot of hacks.
Not sure about the 3D0 , although there was a sport library to allow fast copies/clears using the vram line buffer.

[kool kitty89]

I think having the 68k was important at the time for getting ports done - fixing the onboard DAC would have saved money as well, but I'm not as bothered as you are about the need for DMA PCM. After all a lot of the reasoning behind the DSP was to synth sounds rather than just playback PCM.

They should have realized by the early 90s how dominant sample synth was becoming . . . but DSP-like capabilities were still important there too for fast decompression (and doing that in software meant using any format you wanted from CVDS to 2-bit ADPCM to 4-bit to mulaw, etc), mixing, interpolation, etc. As well as potential for wavetable synth type stuff, or FM, or various other synths or combinations thereof. (FM would be much cheaper to accomplish on a Yamaha synth chip though, and much better supported on the developer end for standard functionality)

And DMA (or FIFO) support would be important in general for FM stuff as well, since you could synth and mix the channels (and possibly PCM along with it) into a buffer that's DMA'd independently and in parallel with the DSP rather than resorting to carefully timed loops (frustrating efficient multitasking and hardly foolproof as the Genesis saw -or maybe just an issue with developers not caring to put resources into decent Z80 coders) or using interrupts for a lot more overhead and performance loss. (something that wasn't an option on the MD due to the odd decision to not connect the YM interrupt signal to the Z80, though obviously inefficient compared to good cycle timed code, it would have been far better than many of the crappy playback schemes being used, especially at common sample rates)
And I mean DMA from the scratchpad, not main (to keep overhead down and put emphasis on the DSP scratchpad for the mixing buffer -even more important due to the very slow DSP writes to main), or FIFO for the same purpose. (and a FIFO cue should be pretty low overhead too, and with interrupts driving that, you'd need a much lower frequency interrupt scheme and thus far, far less overhead for the DSP)



In hindsight, not only was the synth support of the DSP rarely used (and rather poorly used when it was suppored), but the majority of sound/music was done with basic MOD formatted stuff, often basic 4 channel fixed stereo amiga type stuff at that (not even 8 channel with dynamic stereo), not sure if compression was used at least, but not even trying to emulate SNES level stuff. (which it would have been much more flexible for too due to DMA to main RAM/ROM and lack of forced filtering and interpolation -and higly variable compression possibilities)




Flare did the same thing for the Flare 1 (though I think the PWM DACs were working), and even in 1989, developers them were pushing PCM to a huge extent already, though there was a fair amount of use for the FM synth driver as well. (especially important due to the very memory available in the Multisystem -and no ROM to boost that)
Albeit the emphasis on synth made a lot more sense back then with the heavier memory limits. (though with the contention for DSP use in 3D games, it might have made sense to add a cheap discrete sound chip as well -the super cut down YM2413 was the super chip option in Yamaha's lineup and one of only 2 that integrated the DAC -the YM2612 was the only other, albeit the external DACs were pretty small/cheap anyway)

Though this comment is rather odd:
Brian Pollock of software publisher Logotron highlighted the limitations caused by the shortage of RAM (kept low to keep prices down), “My only concern is memory, or lack of it. For instance, in the game that I'm writing I am using six-channel FM synthesized sound. Now that takes up a hell of a lot of memory. I couldn't usefully fit any more samples, and that's sad.”[4]

FM shouldn't take up a lot of memory . . . unless his "FM" driver is actually a sample based engine using sampled FM.

True - but the VDP1 drawing control blocks take a lot of memory, and line by line might hit limits there.

OK, though there's still that interesting alternative method I liked to above:

If you're using the ASIC you may as well just try textured polygons =P

Go and try the 3D globe widget for Opera. Technically it's just a ZIP with HTML and javascript code inside, so it should run on any browser if you unpack it (EDIT: well, any browser that supports 2D canvas). Look at the way it stores textures and you'll see how it'd be possible to do textured triangles with the ASIC.

and more:
http://www.sega-16.com/forum/showthr...phics&p=367072

I assume that, as the saturn forward textures it breaks a page with every pixel write ( although a Morten ordering on the write addresses might have helped ) - which is comparable to the Jaguar reads breaking pages. ( The PSX would be worse if every read was a texture cache miss ) and that is the limit for texturing

Given the speed of the Saturn's RAM, a break would probably force 3 wait states (4 cycles per write), so a pretty big hit.

Does the PSX have any added buffering for working out of cache (namely phrase buffers for source or, more importantly, destination), or does it rely solely on the cache for that functionality as well? (though even for cache operations, it really would at least need 32-bit source and destination buffers for efficient bandwidth use)

IIRC, the "sprite mode" also generally draws at close to the max texture fillrate (much closer than most 3D polygon stuff), so something must be going on there. (efficient pipelining for 2D drawing operations both inside and outside of caching, or very heavy optimized use of cache)

I was just commenting on the fact that in highres (640etc) modes VDP1 doesn't support 16 bit pixels, only 8 bit - so no gourard shading or lighting on highres without a lot of hacks.

16bpp is supported up to 512x256, correct? And 8bpp up to 512x512?

Actually, this is something I've been a bit confused about before, since several games indeed appear to be using 640x480 or 714x480 in 256 colors with polygons exceeding the 512 wide boundary (ie not just VDP2 stuff in that added space), but that should be impossible for the framebuffer to fit. (and even if you could fit it into the framebuffer -or do things like use each framebuffer for a separate interlaced field at the expense of single buffering- that would necessitate VDP1 being able to exceed 512 wide pixel addressing in general)


It's also a bit ironic that the Saturn got that 8bpp support when, if the PSX GPU had gotten it, there could have been far greater advantage (and flexibility) to using it due to the direct contention for framebuffer/VRAM space (while saturn framebuffer space is of limited use for anything but the framebuffer), and the support for hardware dithered interpolation making potential for dithered shading and transparencies in 8bpp, especially for high res stuff where dithering works better. (granted, you'd need some sort of programmable look up table for such a mode since the color palette would be variable . . . or only allow support for those features if a special fixed 256 color palette was used -with programmable palettes disabling dithering and hardware shading, requiring software look-up instead)

Had the Saturn at least supported a hardware shading LUT in VDP1, you could have had PC VGA style shading/lighting effects rather than just flat shading. (granted, it would be worse looking than the few PC games that supported dithered shading -like Tie Fighter- unless hardware dithering was added to VDP1, but most PC games just used simple look-up based shading gradients -sometimes used for limited, posterized, translucency as well- Like Doom, Quake, and Tomb Raider) It's smooth shading, but with a lot more limited color (so posterized/banded like highcolor stuff, but worse -more or less depending on how optimized the palette is and how diverse the texture colors are -ie if you had all textures limited to a single 16 color palette, shading could actually be smoother than most highcolor stuff ). It definitely looks better than just flat shading stuff, especially with higher contrast light sourcing. (giving flat shaded stuff an extremely faceted look, one of the shortcomings of Sega's model 2 board vs contemporaries like the System 22 -it oddly had spectral reclection, but not gouraud shading; albeit with light sourcing disabled, the faceting is far less visble and textures can be set at optimal shades for the smoothest look)

[Crazyace]

They should have realized by the early 90s how dominant sample synth was becoming . . . but DSP-like capabilities were still important there too for fast decompression (and doing that in software meant using any format you wanted from CVDS to 2-bit ADPCM to 4-bit to mulaw, etc), mixing, interpolation, etc. As well as potential for wavetable synth type stuff, or FM, or various other synths or combinations thereof. (FM would be much cheaper to accomplish on a Yamaha synth chip though, and much better supported on the developer end for standard functionality)

The DSP was cheaper ( no royalties ) - and supported all of that plus reverb/effects as it was completely programmable.

And DMA (or FIFO) support would be important in general for FM stuff as well, since you could synth and mix the channels (and possibly PCM along with it) into a buffer that's DMA'd independently and in parallel with the DSP rather than resorting to carefully timed loops (frustrating efficient multitasking and hardly foolproof as the Genesis saw -or maybe just an issue with developers not caring to put resources into decent Z80 coders) or using interrupts for a lot more overhead and performance loss. (something that wasn't an option on the MD due to the odd decision to not connect the YM interrupt signal to the Z80, though obviously inefficient compared to good cycle timed code, it would have been far better than many of the crappy playback schemes being used, especially at common sample rates)
And I mean DMA from the scratchpad, not main (to keep overhead down and put emphasis on the DSP scratchpad for the mixing buffer -even more important due to the very slow DSP writes to main), or FIFO for the same purpose. (and a FIFO cue should be pretty low overhead too, and with interrupts driving that, you'd need a much lower frequency interrupt scheme and thus far, far less overhead for the DSP)

I disagree - the interupt overhead was pretty low, and keeping everything in software made things more flexible. - The slow DSP read/writes were another bug that shouldn't have been there
Dont compare with the MD/Z80 - this was a system designed around feeding a DAC in real time.

In hindsight, not only was the synth support of the DSP rarely used (and rather poorly used when it was suppored), but the majority of sound/music was done with basic MOD formatted stuff, often basic 4 channel fixed stereo amiga type stuff at that (not even 8 channel with dynamic stereo), not sure if compression was used at least, but not even trying to emulate SNES level stuff. (which it would have been much more flexible for too due to DMA to main RAM/ROM and lack of forced filtering and interpolation -and higly variable compression possibilities)

Part of that maybe the software libs, or the fact that the system never sold that many units

Flare did the same thing for the Flare 1 (though I think the PWM DACs were working), and even in 1989, developers them were pushing PCM to a huge extent already, though there was a fair amount of use for the FM synth driver as well. (especially important due to the very memory available in the Multisystem -and no ROM to boost that)
Albeit the emphasis on synth made a lot more sense back then with the heavier memory limits. (though with the contention for DSP use in 3D games, it might have made sense to add a cheap discrete sound chip as well -the super cut down YM2413 was the super chip option in Yamaha's lineup and one of only 2 that integrated the DAC -the YM2612 was the only other, albeit the external DACs were pretty small/cheap anyway)

Though this comment is rather odd:
Brian Pollock of software publisher Logotron highlighted the limitations caused by the shortage of RAM (kept low to keep prices down), “My only concern is memory, or lack of it. For instance, in the game that I'm writing I am using six-channel FM synthesized sound. Now that takes up a hell of a lot of memory. I couldn't usefully fit any more samples, and that's sad.”[4]

FM shouldn't take up a lot of memory . . . unless his "FM" driver is actually a sample based engine using sampled FM.

I guess 6 channels with 4 ops would need memory for all of the phase accum. and the other channel info - and maybe he had small waveform tables rather than just generating sinewaves. ( and there's the program code as well )

OK, though there's still that interesting alternative method I liked to above:


and more:
http://www.sega-16.com/forum/showthr...phics&p=367072

Have you looked at the setup code - acos calls? It seems a little heavy in terms of calculation? I think I'd stick with stiching planar triangles into quads with saturn.

Given the speed of the Saturn's RAM, a break would probably force 3 wait states (4 cycles per write), so a pretty big hit.

Does the PSX have any added buffering for working out of cache (namely phrase buffers for source or, more importantly, destination), or does it rely solely on the cache for that functionality as well? (though even for cache operations, it really would at least need 32-bit source and destination buffers for efficient bandwidth use)

IIRC, the "sprite mode" also generally draws at close to the max texture fillrate (much closer than most 3D polygon stuff), so something must be going on there. (efficient pipelining for 2D drawing operations both inside and outside of caching, or very heavy optimized use of cache)

I guess the cache - and the wider ram

[Crazyace]

16bpp is supported up to 512x256, correct? And 8bpp up to 512x512?

Actually, this is something I've been a bit confused about before, since several games indeed appear to be using 640x480 or 714x480 in 256 colors with polygons exceeding the 512 wide boundary (ie not just VDP2 stuff in that added space), but that should be impossible for the framebuffer to fit. (and even if you could fit it into the framebuffer -or do things like use each framebuffer for a separate interlaced field at the expense of single buffering- that would necessitate VDP1 being able to exceed 512 wide pixel addressing in general)

Have to check the docs - not got anything here with me

It's also a bit ironic that the Saturn got that 8bpp support when, if the PSX GPU had gotten it, there could have been far greater advantage (and flexibility) to using it due to the direct contention for framebuffer/VRAM space (while saturn framebuffer space is of limited use for anything but the framebuffer), and the support for hardware dithered interpolation making potential for dithered shading and transparencies in 8bpp, especially for high res stuff where dithering works better. (granted, you'd need some sort of programmable look up table for such a mode since the color palette would be variable . . . or only allow support for those features if a special fixed 256 color palette was used -with programmable palettes disabling dithering and hardware shading, requiring software look-up instead)

8 bit support on PSX would have been a terrible idea - after all you have full ( even 24 bit support ) already up to 640x and there is no vdp2 equiv to perform pallette lookup on the 8 bit pixels.

Had the Saturn at least supported a hardware shading LUT in VDP1, you could have had PC VGA style shading/lighting effects rather than just flat shading. (granted, it would be worse looking than the few PC games that supported dithered shading -like Tie Fighter- unless hardware dithering was added to VDP1, but most PC games just used simple look-up based shading gradients -sometimes used for limited, posterized, translucency as well- Like Doom, Quake, and Tomb Raider) It's smooth shading, but with a lot more limited color (so posterized/banded like highcolor stuff, but worse -more or less depending on how optimized the palette is and how diverse the texture colors are -ie if you had all textures limited to a single 16 color palette, shading could actually be smoother than most highcolor stuff ). It definitely looks better than just flat shading stuff, especially with higher contrast light sourcing. (giving flat shaded stuff an extremely faceted look, one of the shortcomings of Sega's model 2 board vs contemporaries like the System 22 -it oddly had spectral reclection, but not gouraud shading; albeit with light sourcing disabled, the faceting is far less visble and textures can be set at optimal shades for the smoothest look)

It would be better to just support 16 bit in high res on the saturn ( maybe a mode where the memory was organised as 640x200 ). Though in the end most games ran at 320x on both Saturn and PSX - and the Saturn games that did run at high res didn't seeem to be penalised for not having lighting ( VF2 etc )