Its 1993, you're in charge of the Jag, what do you do?

[kool kitty89]

I remember renting that game back in the day (Steller Fire)... It sort of reminded me of Silpheed but it was more free roming, but not as detailed as Silpheed. I think Cybermorph and PhaseZero really shows off the Jag and I also thing the Sega CD could've seen a little bit more 3D action, but I understand that back in those days 3D probably wasn't consider to have been feasable or profitable for the Sega CD at that time... "Racing Aces" for the Sega CD showed a lot of promise though.

 

Stellar Fire was based on the PC game Stellar 7 btw. From what I've heard from Sega CD programmers/tinkerers, you could probably get polygon based games running ~3x faster than on the Genesis alone (so 3x faster than F-22 or Hard Drivin' level 3D), the dual CPUs and faster 68k in CD (if used properly) should allow this, but there were added features the CD's ASIC added, one being the ability to draw vector lines (but not fully rasterize polygons), and more importantly could handel some Affine texture mapping. (all 15/16-color of course) Which would be intresting for both polygonal and raycasting type games. We're way off topic now, but here's the recent Sega-16 thread on this: http://sega-16.com/forum/showthread.php?t=8689&page=2

[kool kitty89]

Do you really think it would have been $499 - I'm not so sure, after all the CD32 was $399 , and the Sega CD had launched at $299 ( as far as I can remember ). I'm sure that Atari would have priced cheaper than just the sum of the jag+jagCD if it had been a dedicated unit at launch.

( I'd have expected a single speed CD as well in 1993 - as that would be way cheaper than a 2x drive )

 

 

I've been thinking about this more, the CD32 has a 2x speed drive, though I think Commodore used their own CD-ROM controler (which should have saved a bit), 2MB of RAM like the Jaguar, a much larger motherboard with more expansion connections and output jacks. (individual Composite and stereo RCA jacks, S-Vidoe port, amplified headphone jack, plus expansion for MPEG module and other upgrades)

I doubt Commodore was in much better of a financial condition than Atari at this point, but they managed to release the CD32 at the equivalent of $399 USD in mid 1993. Putting at least some perspective on what the Jag might have cost.

 

I'm not sure how much commodore saved on development costs (being almost a direct conversion of the A1200 hardware) compared to the Jaguar, or how the cost of Tom+Jerry+68k compare to the AGA chipset and 68EC020FG16 (16.7 MHz rated, and should be cheapest 68020 available), or how that might compare if the Jag had that same CPU as the host.

Edited October 10, 2009 by kool kitty89

[Crazyace]

Yes - the CD32 had a dual speed drive, but used the components from the a1200 ( which launched at $599 - though I guess that included a good profit margin )

The jaguar should have been cheaper eventually, with almost everything in Tom/Jerry , but I'd assume that it would launch with a single speed CD drive ( as the prices might be a lot cheaper )

I noticed that the TurboDuo also launched at $299 in 1992 as well - so that would have been a 'target' price for a CD console.

 

As Gorf said - the GPU( and DSP I guess ) can run code from main memory now ( with the restrictions he has documented ), and it was always designed to run code anywhere - so I expect that the main memory bug could have been fixed if it were more of a priority for Atari at the time. ( ie- If they had decided to support C on DSP/GPU and lose the 68000 )

 

The key would be having the gpu C compiler, as the reliance on the familiar 68000 would be less important if you were writing C code from day one. Of course for real performance optimised loops would have to be hand tuned assembly , but that's always been the case - even for modern consoles.

[wozencl]

This thread has been amazingly informative, though a lot of the technical stuff has gone completely over my head.

 

I think I'd have to agree with CrazyAce et al. that the most important thing Atari could have done was create some decent development tools. The Jaguar, even in it's released state, was a very capable system it simply wasn't exploited to it's full potential. IMO it suffered mainly from poor support from third party developers, hardly surprising given their treatment by Atari and lackluster dev tools, which led to a small library of games - many of which offered little more than those available on the 16-bit systems of the time.

 

I think it's a little harsh to call the developers lazy - I doubt many of them had time or inclination to think of, and then develop, workarounds for the hardware's various bugs. I seem to recall reading an interview with Faran Thomason where he said that Atari was constantly trying to get software developed cheaply and a result development teams were often under-skilled and working with unrealistic deadlines.

 

I've been looking through some of the sources the Curt kindly posted recently and have noticed that there are files relating to a CD drive of sorts from as early as Oct 1993 (The copyright on one file is 1992, 1993). Did Atari consider releasing the Jag CD much earlier than it arrived? I take it by 1993 it was too late to release the Jag as CD based system?

[The_Laird]

The Jag CD was originally meant to be released a few months after the core system. Lack of software being ready on time held up its release, in fact many of the titles announced as "release" titles for the Jag CD never even saw the light of day!!!

[Gorf]

I think it's a little harsh to call the developers lazy - I doubt many of them had time or inclination to think of, and then develop, workarounds for the hardware's various bugs. I seem to recall reading an interview with Faran Thomason where he said that Atari was constantly trying to get software developed cheaply and a result development teams were often under-skilled and working with unrealistic deadlines.

 

 

It's either lazy or High level spoiled....take your pick. Atari is certainly in part to blame. They insisted on dev teams using the GPU DSP combo

and not relying on the 68k(which should have been an 020 and I stand by that till death) but never supplied tools worth the shit.

 

I've been looking through some of the sources the Curt kindly posted recently and have noticed that there are files relating to a CD drive of sorts from as early as Oct 1993 (The copyright on one file is 1992, 1993). Did Atari consider releasing the Jag CD much earlier than it arrived? I take it by 1993 it was too late to release the Jag as CD based system?

 

It was rushed out the door as their thinking was it's now or never....never would have saved everyone a lot of heart ache to be quite honest.

[Gorf]

I remember renting that game back in the day (Steller Fire)... It sort of reminded me of Silpheed but it was more free roming, but not as detailed as Silpheed. I think Cybermorph and PhaseZero really shows off the Jag and I also thing the Sega CD could've seen a little bit more 3D action, but I understand that back in those days 3D probably wasn't consider to have been feasable or profitable for the Sega CD at that time... "Racing Aces" for the Sega CD showed a lot of promise though.

 

Stellar Fire was based on the PC game Stellar 7 btw. From what I've heard from Sega CD programmers/tinkerers, you could probably get polygon based games running ~3x faster than on the Genesis alone (so 3x faster than F-22 or Hard Drivin' level 3D), the dual CPUs and faster 68k in CD (if used properly) should allow this, but there were added features the CD's ASIC added, one being the ability to draw vector lines (but not fully rasterize polygons), and more importantly could handel some Affine texture mapping. (all 15/16-color of course) Which would be intresting for both polygonal and raycasting type games. We're way off topic now, but here's the recent Sega-16 thread on this: http://sega-16.com/forum/showthread.php?t=8689&page=2

 

Very few polies and very low frame rates. There is no way in hell the Sega Cd would be doing anything useful with polygons. If it were so

you'd never have seen the 32X. Sega would have urged developers to do this to beat on the Jaguar. Wishful thinking at best...not unlike

this thread actually.

[kool kitty89]

As Gorf said - the GPU( and DSP I guess ) can run code from main memory now ( with the restrictions he has documented ), and it was always designed to run code anywhere - so I expect that the main memory bug could have been fixed if it were more of a priority for Atari at the time. ( ie- If they had decided to support C on DSP/GPU and lose the 68000 )

 

The key would be having the gpu C compiler, as the reliance on the familiar 68000 would be less important if you were writing C code from day one. Of course for real performance optimised loops would have to be hand tuned assembly , but that's always been the case - even for modern consoles.

 

Having Tom+Jerry with no additional host apparently had never been a serious consideration by Flare though. I'm not sure why they hard coded the DSP for the 6-cycle delay... At least the lack of cache on the RISCs makes sense given their constraints. (time and possibly funding)

 

Having the 020 in place of th e68k would definitely be useful regardless, and definitely a good insurence policy in case of any snafus with getting good tools out.

 

Ideally, youd have the RISCs working mosly in local (maybe some main with the GPU), the 020 working in cache, leaving as much bandwidth as possible for the OPL+Blitter.

 

 

I've been looking through some of the sources the Curt kindly posted recently and have noticed that there are files relating to a CD drive of sorts from as early as Oct 1993 (The copyright on one file is 1992, 1993). Did Atari consider releasing the Jag CD much earlier than it arrived? I take it by 1993 it was too late to release the Jag as CD based system?

 

Well as long as you made changes before things were finalized, some quicker changes should be possible. They wouldn't have been able to make their own CD-ROM controller by that point, just off the shelf (and 1x to keep a reasonable price), changing to the 68EC020 should be very simple in those terms.

 

I think it's a little harsh to call the developers lazy - I doubt many of them had time or inclination to think of, and then develop, workarounds for the hardware's various bugs. I seem to recall reading an interview with Faran Thomason where he said that Atari was constantly trying to get software developed cheaply and a result development teams were often under-skilled and working with unrealistic deadlines.

 

 

It's either lazy or High level spoiled....take your pick. Atari is certainly in part to blame. They insisted on dev teams using the GPU DSP combo

and not relying on the 68k(which should have been an 020 and I stand by that till death) but never supplied tools worth the shit.

 

Yeah, you couldn't have time to wade through things getting around bugs and working all in assemler with the kind of deadlines often being applied... The 020 should have certainly opened things up for this (and made games relying on the 68k far better). Even if Atari never came out with good tools, at least develpers would have something useful to work with, and some serious programmers could eventually get some real power out of it. I beleive id was even developing their own compiler for the RISCs, intended to be used for some later games like Quake, but not being ready for Doom. (which used C for 68k and all assembly for RISC I beleive) Hell, maybe if id had been successful with this Atari could have licenced it to distribute to other developers.

 

I've been looking through some of the sources the Curt kindly posted recently and have noticed that there are files relating to a CD drive of sorts from as early as Oct 1993 (The copyright on one file is 1992, 1993). Did Atari consider releasing the Jag CD much earlier than it arrived? I take it by 1993 it was too late to release the Jag as CD based system?

 

It was rushed out the door as their thinking was it's now or never....never would have saved everyone a lot of heart ache to be quite honest.

 

Yeah, unless the Tramiels had been willing to personally fund things for a while to get it all worked out reasonably for a decent launch... Not even "bet the farm" necessarily, but put a little more on the line, mostly for getting th ehardware settled and have a decent number of launch titles with timely flow of subsequent releases, maybe investing a bit into hyping things up more while leading up to the launch.

[Crazyace]

As Gorf said - the GPU( and DSP I guess ) can run code from main memory now ( with the restrictions he has documented ), and it was always designed to run code anywhere - so I expect that the main memory bug could have been fixed if it were more of a priority for Atari at the time. ( ie- If they had decided to support C on DSP/GPU and lose the 68000 )

 

The key would be having the gpu C compiler, as the reliance on the familiar 68000 would be less important if you were writing C code from day one. Of course for real performance optimised loops would have to be hand tuned assembly , but that's always been the case - even for modern consoles.

 

Having Tom+Jerry with no additional host apparently had never been a serious consideration by Flare though. I'm not sure why they hard coded the DSP for the 6-cycle delay... At least the lack of cache on the RISCs makes sense given their constraints. (time and possibly funding)

 

Having the 020 in place of th e68k would definitely be useful regardless, and definitely a good insurence policy in case of any snafus with getting good tools out.

 

Ideally, youd have the RISCs working mosly in local (maybe some main with the GPU), the 020 working in cache, leaving as much bandwidth as possible for the OPL+Blitter.

 

 

I think an 020 would be a pointless expense - especially as GPU/DSP not working from main is a bug. Atari already supplied a C compiler for gpu, and without a 68k in the system they could have concentrated on having gdb work with gpu/dsp. The DSP would run it's audio interupts ( and CD reads ) via interrupts in it's local memory - and it could handle game code running in main memory ( as it could be 32 bit instead of 16 at the moment ) leaving the gpu to be used pretty much as it was in most jaguar games , for 3D and blitter driving.

 

( This is all my view though - as I'd want to save money on other components to offset the cost of having the CD drive part of a $299 jaguar at launch )

[Atari_Owl]

I think it's a little harsh to call the developers lazy - I doubt many of them had time or inclination to think of, and then develop, workarounds for the hardware's various bugs. I seem to recall reading an interview with Faran Thomason where he said that Atari was constantly trying to get software developed cheaply and a result development teams were often under-skilled and working with unrealistic deadlines.

 

 

It's either lazy or High level spoiled....take your pick. Atari is certainly in part to blame. They insisted on dev teams using the GPU DSP combo

and not relying on the 68k(which should have been an 020 and I stand by that till death) but never supplied tools worth the shit.

 

I think wozencl has a point here too though - a lot of the dev was done very much on the cheap by very inexperienced under-skilled teams simply because experienced teams cost too much and also knew that Atari could not be trusted.

[Gorf]

I think wozencl has a point here too though - a lot of the dev was done very much on the cheap by very inexperienced under-skilled teams simply because experienced teams cost too much and also knew that Atari could not be trusted.

 

 

Yes unexperience would most definitely = High level language spoiled.

[Gorf]

I think an 020 would be a pointless expense - especially as GPU/DSP not working from main is a bug. Atari already supplied a C compiler for gpu, and without a 68k in the system they could have concentrated on having gdb work with gpu/dsp. The DSP would run it's audio interupts ( and CD reads ) via interrupts in it's local memory - and it could handle game code running in main memory ( as it could be 32 bit instead of 16 at the moment ) leaving the gpu to be used pretty much as it was in most jaguar games , for 3D and blitter driving.

 

( This is all my view though - as I'd want to save money on other components to offset the cost of having the CD drive part of a $299 jaguar at launch )

 

The 020 would be anything but pointless.... A CD player would do nothing for the systems performance. An 02 would greatly enhance the systems

performance. The Cd would have made the Jaguar in 93 cost at least $399 and added nothing to help the systems bottlenecks. an 020 on the other

hand would greatly boost the ability of Tom&Jerry having the bus to itself most of the time. The Cd would in fact slow things down based on

access times alone. To me the Cd would have been pointless in a million way outside of larger media. The 020 woudl do the following:

 

Keep itself off the bus 90% of the time.

Run more than twice as fast due to its much higher efficiency

Access the bus twice as wide when it did access the bus and do so more efficiently.

Allow the DSP to run fully 32 bits and no need for a delay( at least not 6 cycles).

Allow the Blitter and OPL much more bus time per frame.

Allow for much better development tools as the 020 would certainly have a C compiler, runing C in the 020 being worlds more efficient that 68k C.

A couple years later release a CD add on at a much lower cost.

Jag with an 020 would have cost $299.

 

 

The CD unit would do the following:

Greatly incease the cost of the unit.

Slow data access down greatly.

Do nothing for better tools or the amature developers as they would have had to either learn assembler or keep pumping out 68 C slow games.

It's only plus would have been more data...not needed even for games like Wolf 3D and Doom.

Jag with a CD would have cost $399.

 

The 020 is much more intellegent an idea all around.

[Crazyace]

 

The 020 would be anything but pointless.... A CD player would do nothing for the systems performance. An 02 would greatly enhance the systems

performance. The Cd would have made the Jaguar in 93 cost at least $399 and added nothing to help the systems bottlenecks. an 020 on the other

hand would greatly boost the ability of Tom&Jerry having the bus to itself most of the time. The Cd would in fact slow things down based on

access times alone. To me the Cd would have been pointless in a million way outside of larger media. The 020 woudl do the following:

 

Keep itself off the bus 90% of the time.

Run more than twice as fast due to its much higher efficiency

Access the bus twice as wide when it did access the bus and do so more efficiently.

Allow the DSP to run fully 32 bits and no need for a delay( at least not 6 cycles).

Allow the Blitter and OPL much more bus time per frame.

Allow for much better development tools as the 020 would certainly have a C compiler, runing C in the 020 being worlds more efficient that 68k C.

A couple years later release a CD add on at a much lower cost.

Jag with an 020 would have cost $299.

 

An 020 would run 32 bits, but I'm not convinced that it would really change things that much - it's still lowest priority, so it wouldn't affect the blitter/OPL that much.

In a couple of years a 68020 jag would be as dead as the normal jag though... After all - the best games on the jaguar were pretty amazing anyway, and the titles that were criticised as being no better than SNES/Amiga were mainly limited graphically rather than by cpu.

 

Fixing the gpu/dsp main code bugs would allow them to run C code - and they would be faster than a 13MHz 020 - ( unless you're suggesting a full speed 020 - which would be a lot more expensive, and even then the RISC's would be faster )

That's why I'd prefer no 68k chip at all - and fix the main code bug - in that situation the DSP would also run 32 bit.

 

 

 

The CD unit would do the following:

Greatly incease the cost of the unit.

Slow data access down greatly.

Do nothing for better tools or the amature developers as they would have had to either learn assembler or keep pumping out 68 C slow games.

It's only plus would have been more data...not needed even for games like Wolf 3D and Doom.

Jag with a CD would have cost $399.

The CD unit would make it cheaper to publish games - increasing Atari's software profit. It would also ensure a single market, rather than the split market later.

It would raise the profile of the machine - as being a true 'next gen' machine at that time.

Also it would improve the audio side of games, as even for simple games the soundtrack could be CD audio. ( Allowing better music to be used whilst mixing SFX using the DSP )

FMV quality would be amazing compared to the crap shown by the Sega MegaCD - not really game related, but something that could boost sales.

 

The CPU improvements would come from never having any 68k code - just GPU or DSP risc code running from C. Atari supplied a C compiler for GPU - with a HW fix it would be used by the developers.

Even looking at something like Trevor McFur , the backgrounds could be streamed in as highres JPG images, ( as could the enemy animations ) - giving much more varied visuals, rather than everything coming from the single 2MB cartridge.

It would slow the data access though compared to a cartridge - but many games used carts as file backing anyway and decompressed into ram.

I disagree on the price - I think no 68k, and single speed CD could be achieved for $299. Packing a 'demo cd' rather than the full Cybermorph game would allow Atari to make profits on Cybermorph as well.

 

The 020 is much more intellegent an idea all around.

 

I have to disagree there. After all there's no data cache on a 68020 - If you really wanted a 68k off the bus why not go for the 030.

[Crazyace]

As both GPU and DSP have 4 instruction deep queues they could take advantage of the 64 bit bus - ( ie IQ load from GPU acting almost like a loadp instruction , and the dsp load acting as a split 64 bit transfer ( 6 cycles read 64bit memory, bottom 32 to DSP , and 1 or 2 cycles write upper 32 bits to DSP ) without changing all of the other peripheral timings - After all some minimal changes to Tom/Jerry would be made if the decision to not have a host cpu were taken.

[Gorf]

An 020 would run 32 bits, but I'm not convinced that it would really change things that much - it's still lowest priority, so it wouldn't affect the blitter/OPL that much.

 

In a couple of years a 68020 jag would be as dead as the normal jag though... After all - the best games on the jaguar were pretty amazing anyway, and the titles that were criticised as being no better than SNES/Amiga were mainly limited graphically rather than by cpu.

 

Fixing the gpu/dsp main code bugs would allow them to run C code - and they would be faster than a 13MHz 020 - ( unless you're suggesting a full speed 020 - which would be a lot more expensive, and even then the RISC's would be faster )

That's why I'd prefer no 68k chip at all - and fix the main code bug - in that situation the DSP would also run 32 bit.

 

The Blitter and OPL would have been helped greatly where as a CD would be a detriment as it would be another bus hog

loding in spooled music as you suggest. The Blitter and the OPL and the DSP and the GPU would have all greatly benefited

by an 020 where the CD would not have helped any of theseat all other than to add to their burden.

 

The CD unit would make it cheaper to publish games - increasing Atari's software profit. It would also ensure a single market, rather than the split market later.

It would raise the profile of the machine - as being a true 'next gen' machine at that time.

Also it would improve the audio side of games, as even for simple games the soundtrack could be CD audio. ( Allowing better music to be used whilst mixing SFX using the DSP )

FMV quality would be amazing compared to the crap shown by the Sega MegaCD - not really game related, but something that could boost sales.

 

CD would make the unit even further out of the already expensive cost of the console. It does nothing to help the bottlenecks what so ever

and using your own argument, would not help the games other than FMV and maybe a few more levels.

FMV is not a game. It's a movie....therefore boring. Music in games might be one other good argument but again the CD would not and could address the

real issues of the console. Faster games due to three processor actually running in parallel with little to no bus contentions. Music though adding to the atmosphere slighty would have no effect of frame rate other than to slow it down further.

 

It would not raise the profile of the machine. It would have been looked upon as a very expensive machine that did no better than

the Jaguar as it stood. Atari would profit more on software titles and lose big on number of units sold. It would not attract any more

differing developers either. They would still be inexperienced and the CD would not be of any use to make the tool chain better. The

only winner here is Atari and its profits and not even as the machine would have sold less at a much higher price and no better games on

the horizon. Most folks I know that bought a Jaguar waited till it was under $150.

 

Tell Nintendo that a CD unit for the N64 lessened its status as a true next gen machine. The Jaguar at release was considered and raved as

a true next gen until the lousy slow frame rate games came out for it...something the Cd would not help one bit. Trying to get coders to

use only a GPU/DSP that no one ever coded before is silly...if this were the case the current Jaguar is more than capable of operating

without a 68k during the game loop. Name three developers that did so.....good luck on that one. Shit just name one besides us.

 

The CPU improvements would come from never having any 68k code - just GPU or DSP risc code running from C. Atari supplied a C compiler for GPU - with a HW fix it would be used by the developers.

/

 

No the C compiler was absolute garbage and if it were'nt it would have ben used. Instead the few developers worth anything wrote C for the 68k or re wrote

their own compiler( I think that was two developers).

 

Even looking at something like Trevor McFur , the backgrounds could be streamed in as highres JPG images, ( as could the enemy animations ) - giving much more varied visuals, rather than everything coming from the single 2MB cartridge.

It would slow the data access though compared to a cartridge - but many games used carts as file backing anyway and decompressed into ram.

I disagree on the price - I think no 68k, and single speed CD could be achieved for $299. Packing a 'demo cd' rather than the full Cybermorph game would allow Atari to make profits on Cybermorph as well.

 

It would be a lousy single speed in 1993 and it would not help becasue the tools were garbage.

Treavor Sucked regarless of its gfx showcasing. Dc would only let it have more suckiness(word?..it is now.. ).

Streaming in data off the bus would have further choked said bus. No other console at the time could handle as

much data as the Jag's cart port save 3DO which died before the Jagur did.

 

 

The 020 is much more intellegent an idea all around.

 

I have to disagree there. After all there's no data cache on a 68020 - If you really wanted a 68k off the bus why not go for the 030.

 

Of course as you have ignored every valid reason for its inclusion and offered nothing to show why the CD would have made things

better other than FMV, spooled music and higher cost. None of which really add to game play outside of the music.

 

You dont need a data cache for AI. The CD would not have helped in adding a data or instruction cache either.

Again the 020 would have done worlds more than any CD drive. It would have greatly enhanced the machines abilities

exponetially. The CD would not have and in 1993 would have had to have been single speed to keep it under $400.

A single speed CD would be piss poor helping spooled sound and FMV to boot.

[Gorf]

As both GPU and DSP have 4 instruction deep queues they could take advantage of the 64 bit bus - ( ie IQ load from GPU acting almost like a loadp instruction , and the dsp load acting as a split 64 bit transfer ( 6 cycles read 64bit memory, bottom 32 to DSP , and 1 or 2 cycles write upper 32 bits to DSP ) without changing all of the other peripheral timings - After all some minimal changes to Tom/Jerry would be made if the decision to not have a host cpu were taken.

 

The 020 would also have the same advantage as it has a 256 byte TRUE cache unlike the GPU/DSP.

A CD would not help this feature in any way shape or form and again would be yet another unit

to contend for the bus...and make the unit cost $399. Adding the GPU/DSP enhancements to make

this happen are no zero cost either.

 

Pound for pound the 020 is the much more sensible choice, no matter how you slice it. Add

a standard IDE interfacewhich cost nothing back then and let the user add his own CD. Solves

the split market too. Oh...I just priced a Cd rom single speed from 1993...199 to 249.

There goes your dream price of $299. Even if Atari could get these in bulk at $99 it's still

$349 for the Jaguar with a single speed CD rom.

Edited October 12, 2009 by Gorf

[kool kitty89]

I think an 020 would be a pointless expense - especially as GPU/DSP not working from main is a bug. Atari already supplied a C compiler for gpu, and without a 68k in the system they could have concentrated on having gdb work with gpu/dsp. The DSP would run it's audio interupts ( and CD reads ) via interrupts in it's local memory - and it could handle game code running in main memory ( as it could be 32 bit instead of 16 at the moment ) leaving the gpu to be used pretty much as it was in most jaguar games , for 3D and blitter driving.

 

( This is all my view though - as I'd want to save money on other components to offset the cost of having the CD drive part of a $299 jaguar at launch )

As both GPU and DSP have 4 instruction deep queues they could take advantage of the 64 bit bus - ( ie IQ load from GPU acting almost like a loadp instruction , and the dsp load acting as a split 64 bit transfer ( 6 cycles read 64bit memory, bottom 32 to DSP , and 1 or 2 cycles write upper 32 bits to DSP ) without changing all of the other peripheral timings - After all some minimal changes to Tom/Jerry would be made if the decision to not have a host cpu were taken.

 

Well, in that case you're suggesting that Flare take a different design philosophy from the start, and focus on a system based around Tom+Jerry alone... Which isn't a bad idea at all, but also would make the design even more vulnerable if they didn't smooth the hardware out and supply useful software tools. (although it should be a lot easier to make good tools for bug-free software)

Cache still probably wouldn't be practical given time constraints and limited resources (although it would have been great), just keep the locals and it's probably best to just focus on making sure the basic hardware is done right. The first thing (with no added host) would be make the GBU boot the system, also getting Jerry up to 32-bit bus width, get rid of that 6-cycle access delay on Jerry as well (have it more or less the same as the GPU but with all the added audio circuitry and larger scratchpad in place of the blitter and OP) Obviously the bugs would be addressed (DSP writes, GPU and DSP running code in main, and fix the MMU) and on top of that add double buffering for the blitter registers.

 

On top of that maybe knock the system speed up to ~33 MHz (40 MHz was intended for the chipset I beleive, but that would have made RAM too expensive at the time), 32-33 MHz would knock RAM costs up a bit as well, but probably still be reasonable. (or maybe something small, like ~28.6 MHz, which should mean cheaper 70 ns timing on RAM rather than 60 ns, with the Jag currently having 75 ns I believe)

 

With no cache, you'd still have bus contention, except for anything you can fit onto the scratchpads, so that would still be limiting. (one thing the 020 would still be good for: contributing with very little hits to main)

 

Keep itself off the bus 90% of the time.

Run more than twice as fast due to its much higher efficiency

Access the bus twice as wide when it did access the bus and do so more efficiently.

Allow the DSP to run fully 32 bits and no need for a delay( at least not 6 cycles).

Allow the Blitter and OPL much more bus time per frame.

Allow for much better development tools as the 020 would certainly have a C compiler, runing C in the 020 being worlds more efficient that 68k C.

A couple years later release a CD add on at a much lower cost.

Jag with an 020 would have cost $299.

I think he's talking about a change in the original design concept of the Jaguar, similar chipset, but never intend for an additional host to be used at all. So the DSP would be at full 32-bits and should have the same bandwidth as GPU now, with bugs addressed on both, plus the MMU, blitter, and preferably with added buffering on the blitter. (as I mentioned above)

Along with that would be a decent C compiler for the RISCs. (which should be facilitated by the lack of bugs)

 

The CD unit would do the following:

Greatly incease the cost of the unit.

Slow data access down greatly.

Do nothing for better tools or the amature developers as they would have had to either learn assembler or keep pumping out 68 C slow games.

It's only plus would have been more data...not needed even for games like Wolf 3D and Doom.

Jag with a CD would have cost $399.

 

The 020 is much more intellegent an idea all around.

 

True, but there are substantial advantages to CD as well, especially from a developer's standpoint. Low cost of media (less risk) and large capacity, plus the ability to use CD audio and streaming video. (for cutsecenes, transitions, and sometimes integral gameplay, not just Dragon's Lair-esque interactive movie games, but others like NovaStorm or Myst, plus high profie games like Wing Commander III coming out)

One added bonus of streaming audio would be less work for Jerry for that, mainly just sfx mixing. (so better for other tasks like calculating 3D transformations or additional game logic, or just keeping off the bus more often)

 

A 1x speed drive would be the most practical in cost terms, loading times would be longer and video would by 1/2 the bitrate, but at least you wouldn't be splitting the market with an add-on. (you could upgrade to a 2x drive later on, but that would only really help with static load times, any streaming video or on the fly loading would need to be kept compatible with the earlier 1x speed models)

 

 

 

However, for the original premise of this discussion, we're in 1993, which is much too late to rework the Jaguar as much as Crazyace is suggesting. The best quick fix would probably be the 020 first, then work out as many bugs (maybe add the blitter buffering) as possible, maybe improve the tools, and maybe increase the system speed. (the EC020 would be good for anything up to 16.7 MHz, and anything more than that would probably push RAM cost too high anyway)

In either case, go CD from the start, or wait until Jag II so as not to split the market. (if you go with a 1x drive and get good deals on both the EC020 and the drive and maybe push launch back a couple months, like spring of '94 -especially to have a better lineup of games- the price could probably still be around $400, more than competitive with contemporaries and should drop to a competitive price by the time Saturn and PlayStation come out)

 

In Crazyace's ideal case though, it should be cheaper than that, with the lack of the 020 (or 68k even), maybe even enough to launch with a 2x CD drive. Ideally Atari would have been developing their own CD-ROM controller and interface in parallel, which would save a lot on the drive (just paying for the mechanism. That should have made a 2x speed drive practical at launch, maybe even for 1993. (like the CD32)

Edited October 12, 2009 by kool kitty89

[Gorf]

Well, in that case you're suggesting that Flare take a different design philosophy from the start, and focus on a system based around Tom+Jerry alone... Which isn't a bad idea at all, but also would make the design even more vulnerable if they didn't smooth the hardware out and supply useful software tools. (although it should be a lot easier to make good tools for bug-free software)

 

Cache still probably wouldn't be practical given time constraints and limited resources (although it would have been great), just keep the locals and it's probably best to just focus on making sure the basic hardware is done right. The first thing (with no added host) would be make the GBU boot the system, also getting Jerry up to 32-bit bus width, get rid of that 6-cycle access delay on Jerry as well (have it more or less the same as the GPU but with all the added audio circuitry and larger scratchpad in place of the blitter and OP) Obviously the bugs would be addressed (DSP writes, GPU and DSP running code in main, and fix the MMU) and on top of that add double buffering for the blitter registers.

 

Also adding to the cost of the chips....dont forget this.

 

On top of that maybe knock the system speed up to ~33 MHz (40 MHz was intended for the chipset I beleive, but that would have made RAM too expensive at the time), 32-33 MHz would knock RAM costs up a bit as well, but probably still be reasonable. (or maybe something moderate, like ~28.6 MHz, which should mean cheaper 70 ns timing on RAM rather than 60 ns, with the Jag currently having 75 ns I believe)

 

 

The higher speed RAm necessary would GREATLY increse the price alone.

Pound for pound and dollar for Dollar the 020 is by far the best approach hands down.

[Crazyace]

The Blitter and OPL would have been helped greatly where as a CD would be a detriment as it would be another bus hog

loding in spooled music as you suggest. The Blitter and the OPL and the DSP and the GPU would have all greatly benefited

by an 020 where the CD would not have helped any of theseat all other than to add to their burden.

 

I think a fixed GPU/DSP would help more than a 68020, and they would cost less in the long run. ( Maybe another respin of the chip to fix the bug , but that's a one off cost )

My reasons for adding a CD are not related to system power though, but why would it be a detriment - single speed is only 150k/second , that's not going to saturate the bus at all ( 3k per frame at 60Hz

 

CD would make the unit even further out of the already expensive cost of the console. It does nothing to help the bottlenecks what so ever

and using your own argument, would not help the games other than FMV and maybe a few more levels.

FMV is not a game. It's a movie....therefore boring. Music in games might be one other good argument but again the CD would not and could address the

real issues of the console. Faster games due to three processor actually running in parallel with little to no bus contentions. Music though adding to the atmosphere slighty would have no effect of frame rate other than to slow it down further.

 

CD would add to the cost - but it would pay for itself by improving the profit on the games. I agree that FMV just for the sake of it is pretty sucky - but in 1993 people were lapping it up.

Also if the GPU/DSP were running from main ( and both 32 bit ) wouldn't that be faster than games running on the 68000 - I know you say that even with your workarounds that GPU from main ram is better than 68000.

 

 

It would not raise the profile of the machine. It would have been looked upon as a very expensive machine that did no better than

the Jaguar as it stood. Atari would profit more on software titles and lose big on number of units sold. It would not attract any more

differing developers either. They would still be inexperienced and the CD would not be of any use to make the tool chain better. The

only winner here is Atari and its profits and not even as the machine would have sold less at a much higher price and no better games on

the horizon. Most folks I know that bought a Jaguar waited till it was under $150.

 

Atari sold very poorly as it was - My hope would be that more people would pick up the unit because of the CD. Also Atari never made any profit from the pack in game - so it was basically an additional cost in the $250 , a demo CD would have cost almost nothing.

I expect that eventually the Jaguar price would have had to drop, even with a CD - maybe most of the folks you know would have bought a Jag with CD for $199

 

Tell Nintendo that a CD unit for the N64 lessened its status as a true next gen machine. The Jaguar at release was considered and raved as

a true next gen until the lousy slow frame rate games came out for it...something the Cd would not help one bit. Trying to get coders to

use only a GPU/DSP that no one ever coded before is silly...if this were the case the current Jaguar is more than capable of operating

without a 68k during the game loop. Name three developers that did so.....good luck on that one. Shit just name one besides us.

 

Tell Sony that a CD unit for the playstation lessened it status as a true next gen machine. Nintendo were in a completely different situation from Atari. For me the CD unit is a business win in terms of profit, not really a technical win.

With main memory working, coders would write C for the Jag. This is a completely different situation to the current jaguar, where the bug stopped nearly everyone except you and AtariOwl from using the GPU in main. Instead all of the 'poor/underfunded/timestrapped' teams would write C. ( And at least this C would be Risc C - allowing further optimisation, rather than just 68k ) It's no more silly than the SH-2's in the Saturn really.

 

No the C compiler was absolute garbage and if it were'nt it would have ben used. Instead the few developers worth anything wrote C for the 68k or re wrote

their own compiler( I think that was two developers).

The C compiler was mainly garbage because you couldn't write main memory programs with it , and the overheads really added up in local memory.

 

It would be a lousy single speed in 1993 and it would not help becasue the tools were garbage.

Treavor Sucked regarless of its gfx showcasing. Dc would only let it have more suckiness(word?..it is now.. ).

Streaming in data off the bus would have further choked said bus. No other console at the time could handle as

much data as the Jag's cart port save 3DO which died before the Jagur did.

Lousy single speed is the same as all the previous consoles, and I dont think 150kB/s chokes the bus.

Trevor may have been a poor example though , not much could have saved it

 

 

Of course as you have ignored every valid reason for its inclusion and offered nothing to show why the CD would have made things

better other than FMV, spooled music and higher cost. None of which really add to game play outside of the music.

 

You dont need a data cache for AI. The CD would not have helped in adding a data or instruction cache either.

Again the 020 would have done worlds more than any CD drive. It would have greatly enhanced the machines abilities

exponetially. The CD would not have and in 1993 would have had to have been single speed to keep it under $400.

A single speed CD would be piss poor helping spooled sound and FMV to boot.

 

A CD would have made more profits for Atari , and allowed more titles to be published at lower risk. It would be a higher component cost - but I think a single speed, not PC CD-ROM style drive would have cost Atari far less than you expect.

Single speed drives seem ok for watching VideoCD at 30fps , I've not looked at what quicktime would look like though - but it's bound to be better than the Sega MegaCd.

 

..

Separate to the CD issue - what do you think of the idea of GPU and DSP being able to run code from main memory perfectly at the start, and the C compiler not being constrained by the local memory size. Wouldn't that work as well as a 13MHz 68020?

[Crazyace]

As both GPU and DSP have 4 instruction deep queues they could take advantage of the 64 bit bus - ( ie IQ load from GPU acting almost like a loadp instruction , and the dsp load acting as a split 64 bit transfer ( 6 cycles read 64bit memory, bottom 32 to DSP , and 1 or 2 cycles write upper 32 bits to DSP ) without changing all of the other peripheral timings - After all some minimal changes to Tom/Jerry would be made if the decision to not have a host cpu were taken.

 

The 020 would also have the same advantage as it has a 256 byte TRUE cache unlike the GPU/DSP.

A CD would not help this feature in any way shape or form and again would be yet another unit

to contend for the bus...and make the unit cost $399. Adding the GPU/DSP enhancements to make

this happen are no zero cost either.

 

Pound for pound the 020 is the much more sensible choice, no matter how you slice it. Add

a standard IDE interfacewhich cost nothing back then and let the user add his own CD. Solves

the split market too. Oh...I just priced a Cd rom single speed from 1993...199 to 249.

There goes your dream price of $299. Even if Atari could get these in bulk at $99 it's still

$349 for the Jaguar with a single speed CD rom.

 

I think you're really a bit hung up on the 020. Add an IDE interface? That's not a good console choice - the reason I want a CD in 93 is to unify the market. ( The CD32 launched in 93 with a double speed CD rom drive for $399 , and I'm expecting Atari to be more aggressive in pricing than that )

Only an idiot would launch a console with an 'add your own CD' - you'd have no idea how many people actually used CD's - so you'd have to keep the cartridge ports. I want CD and no cartridges - something simple for users and profitable for Atari.

 

Before you start with any 'blah blah 68020 better' arguments again I'm not denying that a 68020 would speed up games written in 68000 code. I just dont think adding a 68020 would have changed the fate of the machine. The only reason I argue about removing the 68k completely is reduce costs so that the CD could be added.

[kool kitty89]

Lousy single speed is the same as all the previous consoles, and I dont think 150kB/s chokes the bus.

Trevor may have been a poor example though , not much could have saved it

 

Well "all previous consoles" doesn't exactly encompass very many consoles, pretty much just PC Engine CD (in various forms), Sega Mega CD, FM Towns Marty, and CD-i. 3DO and CD32 were the first to have 2x speed drives.

 

A CD would have made more profits for Atari , and allowed more titles to be published at lower risk. It would be a higher component cost - but I think a single speed, not PC CD-ROM style drive would have cost Atari far less than you expect.

Single speed drives seem ok for watching VideoCD at 30fps , I've not looked at what quicktime would look like though - but it's bound to be better than the Sega MegaCd.

 

Yeah, a top loading CD drive should be a good bit cheaper, and comparing the cost of portable audio CD player's drives whouldn't be a good comparison either, as they'd be more expsnive from maintaining the compact size. (a big reason why Sega's CDX/Multimega was so expensive)

 

As for video, VCDs use far higher compression than would be possible in software on one of these consoles, hence the VCD MPEG modules available for a number of them.

I assume by "Quicktime" you mean Cinepak, which was used on the Jag CD, 3DO, Saturn, and Sega CD (any video with close to full screen and decent framerate, other videos used uncompressed digital video -like Sonic CD). Of course you'd have 1/2 the data rate of the other 3, and Cinepak isn't particularly good compression either, but shoudl definitely look a lot better than anything on Sega CD, maybe closer to CD-32x though. (sound might be better)

 

Ideally you would use a custom codec that was optimized for the Jag. It can do better than cinepak (especially in one of these hypothetical configurations with bugless tom+Jerry and/or an 020), something optimizedto take full advantage of the processors, maybe someting closer to Indeo or a software MPEG-1/H.261 decoding. (not to VCD standards of course, I do beleive the Saturn had something like this later in its life) Cinepak would be the baseline available before a custom codec was ready, and would probably also be used for in-game video (for FMV games or games using video generated BGs, like NovaStar or Area 51) due to th eless processing intensive nature. (maybe even have a lower quality cinepak specif for in-game to allow sufficent resourses for the game, and maybe a coresponding custom, optimized codec for the same purpose)

 

Edit:

With main memory working, coders would write C for the Jag. This is a completely different situation to the current jaguar, where the bug stopped nearly everyone except you and AtariOwl from using the GPU in main. Instead all of the 'poor/underfunded/timestrapped' teams would write C. ( And at least this C would be Risc C - allowing further optimisation, rather than just 68k ) It's no more silly than the SH-2's in the Saturn really.

 

Except that the SH2s in the Saturn have 4 kB of cache each, although only one can actually work in cache at any time and only 2 KB of th ecache can be used as a scratchpad for the other. (plus th emulti bus design of the Saturn and the 1 MB of fast SDRAM)

Edited October 12, 2009 by kool kitty89

[Crazyace]

Sorry , Cinepak - not Quicktime

 

The Sh-2 comment was about the instruction set being new to programmers. My feeling is that it's not important if there's a working C compiler.

[kool kitty89]

The Sh-2 comment was about the instruction set being new to programmers. My feeling is that it's not important if there's a working C compiler.

 

Well I think at worst the SH2s were still a good deal better in that respect than the Jag's RISC processors. The Super H architicture was new, but not brand new when Sega came out with the 32x and Saturn, and they were commercial chips produced by Hitachi, with similarly available commercial programming tools. (not familiar to programmers like MIPS or ARM, let alone 68k architectures of course)

 

I'd say Argonaut Software's custom RISC MARIO or "Super FX" processor developed for Nintendo would be more along those lines, with the exception that programmers working on the SNES would be doning things in assembly anyway, and the most prominant games using the Super FX and Super FX 2 were eaither produced by Nentendo themselves or Argonaut. (Argonaut did go on to create a commercail line of RISC processors as well,and form Argonaut RISC Core International- ARC)

Edited October 12, 2009 by kool kitty89

[superjudge3]

I wonder if the guys from Flare ever read this kind of stuff. LOL

[kskunk]

I wonder if the guys from Flare ever read this kind of stuff. LOL

Hard to say. Some people get nostalgic about past projects they worked on, but personally I get allergic to them. After all the stress and burn-out and loss they suffered they might not revel in revisiting the past.

 

However, John M of Flare did a pretty good Jaguar post-mortem interview many years ago, where he addressed all the usual talking points:

 

1) They wanted to a CD unit but it was simply too expensive. So instead they designed the console to support a cheap CD add-on and released it as quickly as they could. Remember that the Jaguar was supposed to be $199 -- the $249 price was a last minute change. Sure, the CD32 had a CD at $399 -- twice the target price! Atari did not think they could sell such an expensive console.

 

2) They didn't realize 3D texture mapping was going to be important. It was considered an occasional special effect and not a core feature -- they believed smooth shading would be the main effect for 3D graphics. Other consoles (such as the 3DO, and of course the Playstation) made texture mapping their primary emphasis. John said they could have shifted the resources of Tom around to support texture mapping but thought it was a waste of time for what they saw as a gimmick.

 

3) They didn't realize game programmers would want to use the 68K or the C programming language. They assumed game programs would be written primarily in assembly language (as they had been) and not in higher level languages. They didn't grasp the increasing complexity of game programs, and saw that contemporary (circa 1990) games were short and simple -- without realizing that by 1995 game programs would be far more complex. The 68K was only there to facilitate quick ports, and again John mentioned that he could have shifted resources in the JagRISC to support C if they had only realized it was a requirement.

 

Hindsight is 20/20. I'm sure the Flare guys could do better than any of us if only they knew then what we do now.

 

- KS

Edited October 13, 2009 by kskunk