Jump to content
IGNORED

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


A_Gorilla

Recommended Posts

I think the free SDKs would have benefited Atari tremendously.

 

The other thing Atari should have done is given, beyond that, developers some type of incentive to code for the Jaguar, instead of tossing money after the development of the Jaguar CD. Even by that time, it was pretty apparent that add ons didn't pan out well for any company. So, it's amazing, to me, that the management of a shrinking share company would have thought a CD resurrection was possible, especially considering the ill fated attempts made by Saga, who, too, destroyed their company, while having a much larger market share.

 

Making the CD an add-on was the biggest mistake, everything else about it was a 'win' , CD gave much more memory than carts for a far far lower price, and the logistics were way better.

A free SDK wouldn't have helped much - developers tend to want working tools in the first place , it's not their job to rewrite things from scratch. ( The Sega CD was a lot more popular than the Jaguar - the 32x seemed to be the big mistake )

Link to comment
Share on other sites

I think the free SDKs would have benefited Atari tremendously.

 

The other thing Atari should have done is given, beyond that, developers some type of incentive to code for the Jaguar, instead of tossing money after the development of the Jaguar CD. Even by that time, it was pretty apparent that add ons didn't pan out well for any company. So, it's amazing, to me, that the management of a shrinking share company would have thought a CD resurrection was possible, especially considering the ill fated attempts made by Saga, who, too, destroyed their company, while having a much larger market share.

 

Making the CD an add-on was the biggest mistake, everything else about it was a 'win' , CD gave much more memory than carts for a far far lower price, and the logistics were way better.

A free SDK wouldn't have helped much - developers tend to want working tools in the first place , it's not their job to rewrite things from scratch. ( The Sega CD was a lot more popular than the Jaguar - the 32x seemed to be the big mistake )

 

The initial point still remains, the Sega CD was a failure for Sega. Like I said, Atari should have keyed off of that and known a CD add on was a huge mistake. They should have taken the money they wasted on that development and attempted to lure developers to their console. I'd say they should have went as far as buying out an upcoming development team, in order to secure a future franchise that would have differentiated themselves from the flock.

Link to comment
Share on other sites

"The problem is the stupid idea to use a 16 bit host like the 68k. Lay off

the host and the system will perfrom worthy of 64 bits. "

 

 

 

I guess that is what I was reffering to, to squeeze down the 64 bit data through the 68k was essentially to have a 16 bit machine, sure the chips could process at 64, but to send it down the datapath to the 68k so much stuff has to be truncated that it's almost a waste...

 

At any rate, still think some true 3D hardware accel would've been the tipping edge there, didn't have to be the the voodoo chipset, which was the more expensive one, by 93 PowerVR had a one chip solution so did Rendition, which both were finished in 91 actually, even with those "subpar" 3D hardware, combined with the existing JAG hardware, it would've trully been revolutionary and would set the bar so high that Sony would have to play catch up!!

 

Of course, all the other issues already discussed would have had to be dealt with as well :)

Edited by marvio
Link to comment
Share on other sites

I took the MIPs figures from wikipedia

 

 

Wikipedia? :lolblue: I could just assuredly ignore the rest of this post based

on that alone...not to mention everything else you have posted in the past....it's

all making sense now. :lolblue: ...but seriously folks....

 

 

and extrapolated the gpu figures , 0.5Mips/Mhz is kind of what I'd expect, with the stalls and redundant move instructions that are often needed.

 

You extrapolated horribly wrong then and I can do much better than 0.7 MIPS/MHZ by hand.

If you are using a ton of movei's you should probably stick to 68k. There are other ways

to obtain immediate data with the GPU.

 

 

I definitely picked a lower figure though, you're right that a tight hand tuned loop could be better - but that's not likely to occur with C compiled code.

 

This entire statement is ridiculous simply based on the fact that there is no C compiler

for the GPU/DSP ( one that is worth bothering with that is) since assembly is the only

route to go with the two RISC's.

 

Hand tuned assembly should be the only way you bother coding the Jaguar RISC's until

someone actually writes a real optimized compiler.

 

How much would a 27MHz 68020 have cost in 1983? Even a 13MHz 68ec020 would be a lot more than the 68000?

 

In bulk, I doubt very much more at all. I belive a 25 mhz EC020 would have been more but

in a half million units, very reasonable. My Jaguar would cost $349, admited but be worth

every last penny in comparison. Still a much better deal over the 3DO and still much cheaper

than a CD ROM drive built in.

 

Even still, an EC020 under the 13 mhz clock would still be a grave improvment over the

already obsolete, bus choking 68k . So no matter how you slice it the 020 in any for is

a mjor leap over the out of place 68k.

 

 

The reason why I dont favour a 68020 is that fixing gpu/dsp would give 32 bit risc code running from main

memory for no cost ( as in a perfect world the bug would not have occurred in the first place )

 

Agreed if the tools were there to deal with it.

With that a no stall write back register file....true 26.59 mips.

Bigger Local on the GPU and no MMU bug causing the main hiccups.

Also a dual buffer blitter reg file. No more GPU wating on the

Blitter and in reverse.

 

Fix the DSP UART issues, the OPL and interrupt system bugs and we can agree.

Edited by Gorf
Link to comment
Share on other sites

Making the CD an add-on was the biggest mistake, everything else about it was a 'win' , CD gave much

more memory than carts for a far far lower price, and the logistics were way better.

 

the carts yes...the system however would have cost you $400.

 

A free SDK wouldn't have helped much - developers tend to want working tools in the first place , it's not their job to rewrite things from scratch. ( The Sega CD was a lot more popular than the Jaguar - the 32x seemed to be the big mistake )

 

Agreed on the tools except for an SDK with the sources.

 

32-X was Sega's 'operation spoiled sport" until the got

the Saturn out the door.

Link to comment
Share on other sites

I guess that is what I was reffering to, to squeeze down the 64 bit data through the 68k was essentially to have a 16 bit machine, sure the chips could process at 64, but to send it down the datapath to the 68k so much stuff has to be truncated that it's almost a waste...

 

The machine would only be choked by using the 68k in a game's loop. The entire bus structure is 64 bits

wide. The 68k did not squeeze the bus down, it choked it.

 

At any rate, still think some true 3D hardware accel would've been the tipping edge there, didn't have to be the the voodoo chipset, which was the more expensive one, by 93 PowerVR had a one chip solution so did Rendition, which both were finished in 91 actually, even with those "subpar" 3D hardware, combined with the existing JAG hardware, it would've trully been revolutionary and would set the bar so high that Sony would have to play catch up!!

 

An 020 instead of a 68k would have given Sony problems. sure the Sony would still be a bit

more robust in terms of poly count but the game logic and AI as well as many other features

on the Jag would be superior. REAL 3D hardware back then would make the Jaguar cost $500 or

more dollars. Still better than the 3DO but hardly a power without the price offering.

 

Of course, all the other issues already discussed would have had to be dealt with as well :)

 

Someone other than the Tramiels at the helm might have seen the REAL beauty of the T&J chipset

and designed a much more efficient system around them....even with a 68k...one with a seperate

bus with it's own 64k of RAM to keep it off the main bus most of the time while the REAL work

horses(J-RISCS, BLitter and OPL) could have the bus most of the time.)

 

Shit...Let the 68k stay with a seprate bus where only the blitter need to write to it and the

Jag would have been a much better system. The 68k then could run in parallel doing AI and game

logic, writing to a specific area that the blitter could grab for the J-RISC to operate off of.

 

As it stands, everything comes to a screaching halt while that blasted host CPU is running.

Sorry indeed.

Edited by Gorf
Link to comment
Share on other sites

I love the Jag, I am on my seventh and hope to keep this one! I think Atari actually pioneered video game marketing by placing in-game graphics on the front of thier packages! The black and red logo are also a great combo!!!! Kudos and thanks for the fun!

 

I'm almost certain you're confusing Atari boxes with Activision. Activision had the little window on the front of boxes (and cartridges) sisplaying an in-game screenshot. Atari boxes had artwark usually (sometimes artwork that was superimposed over graphics I think), and either plain text on the carts (early on) or a similar immage to the box art on the cartridge label.

 

I was not aware! Thanks for the clarification, I wish all game companies placed in game screen shots on front! :)

Link to comment
Share on other sites

I took the MIPs figures from wikipedia

 

 

Wikipedia? :lolblue: I could just assuredly ignore the rest of this post based

on that alone...not to mention everything else you have posted in the past....it's

all making sense now. :lolblue: ...but seriously folks....

 

I haven't even seen MIPS ratings for the 020/030 at all... Anyway, I seem to recall that the 020 was more like .4 MIPS/MHz with the 030 being similar. (with the added advantage of the data cache of course)

 

How much would a 27MHz 68020 have cost in 1983? Even a 13MHz 68ec020 would be a lot more than the 68000?

 

In bulk, I doubt very much more at all. I belive a 25 mhz EC020 would have been more but

in a half million units, very reasonable. My Jaguar would cost $349, admited but be worth

every last penny in comparison. Still a much better deal over the 3DO and still much cheaper

than a CD ROM drive built in.

That price is gettting a bit steep though, the 16.7 MHz rated EC020 would be OK though.

 

Even still, an EC020 under the 13 mhz clock would still be a grave improvment over the

already obsolete, bus choking 68k . So no matter how you slice it the 020 in any for is

a mjor leap over the out of place 68k.

Exactly, it still adds the cache and 32-bit bus, the most important features (keeping it off the bus and widening Jerry to 32-bits)

 

 

 

 

The initial point still remains, the Sega CD was a failure for Sega. Like I said, Atari should have keyed off of that and known a CD add on was a huge mistake. They should have taken the money they wasted on that development and attempted to lure developers to their console. I'd say they should have went as far as buying out an upcoming development team, in order to secure a future franchise that would have differentiated themselves from the flock.

I disagree, it wasn't a major success, but also wan't a failure for Sega, at least not until combined with various unfortunate decisions made from ~1993 onward and the genneral problems between the American and Japanese management. Nothing like the PE Engine CD in Japan, which outstripped the card based unit and gaave serious competition to the SNES.

 

32-X was Sega's 'operation spoiled sport" until the got

the Saturn out the door.

I think it's a good deal more complex than that. The 32x started as an in-between system proposed by Nakayma (CEO of SoJ), originally as a standalone unit, enhancing the Genesis hardware (apparently in a similar manner as NEC's supergrafx) long story short, Japan handed to project to the American branch who though an add-on would be much more parctical and went from there. Any possbilityof reasonable success was killed by the Saturn's early release in Japan and then US the following year. This is all tied in with confusing problems between the Japanese and western branches of Sega, alternate Saturn hardware getting scrapped in 1993 to compete against Sony's hardware specs, among other things. (I personally think the rushed development of the Saturn, expensive, non-developer-freindly hardware, and especially the horrible early/pre-release in sprin og 1995 in the US were Sega's biggest mistakes overall)

 

This is all well beyond th escope of this discussion though.

Edited by kool kitty89
Link to comment
Share on other sites

I'd suggest that quite a lot of Jag RISC code runs at about 16-18MIPS

 

Would that also include code running from main memory? - My point ( before Gorf became totally emotional about it ) was more that the GPU/DSP running general purpose code from main memory in a fixed system ( rather than the bugged one we have ) would be better than a 68020 ( at 13MHz - I don't think a 26MHz 68020 would have been practical for the jaguar price - even the falcon and Amiga1200 only had slower speed cpu's )

 

( Losing the CPU gives the 32 bit path to Jerry for free as well :) )

Link to comment
Share on other sites

I took the MIPs figures from wikipedia

 

 

Wikipedia? :lolblue: I could just assuredly ignore the rest of this post based

on that alone...not to mention everything else you have posted in the past....it's

all making sense now. :lolblue: ...but seriously folks....

 

 

Well I could have quoted an architecture reference manual, or even some benchmark figures - but I thought I'd give you a reference you could read. ( Maybe I should have taken the PR numbers from motorola for the chips )

 

and extrapolated the gpu figures , 0.5Mips/Mhz is kind of what I'd expect, with the stalls and redundant move instructions that are often needed.

 

You extrapolated horribly wrong then and I can do much better than 0.7 MIPS/MHZ by hand.

If you are using a ton of movei's you should probably stick to 68k. There are other ways

to obtain immediate data with the GPU.

Please read my post - movei wasn't mentioned, ( maybe you should also read up on 2 operand vs 3 operand architectures as well )

I'm glad you can do better that 0.7MIPS/MHZ by hand - it's not really relevant to the original point though. ( And would that be >0.7MIPS across your entire codebase, or just a small optimised loop )

 

 

I definitely picked a lower figure though, you're right that a tight hand tuned loop could be better - but that's not likely to occur with C compiled code.

 

This entire statement is ridiculous simply based on the fact that there is no C compiler

for the GPU/DSP ( one that is worth bothering with that is) since assembly is the only

route to go with the two RISC's.

 

Hand tuned assembly should be the only way you bother coding the Jaguar RISC's until

someone actually writes a real optimized compiler.

There was a C compiler for the GPU's - and if the bug was fixed allowing main code execution then it would be a lot more practical.

With C the entire codebase for a game would run on GPU/DSP ( I'd guess DSP - with sound running as an interrupt ) and development would be a lot quicker.

Then the real bottleneck routines could be rewritten in ASM to get the final speed up.

If the GPU ISA was the only target Atari could spend resources on improving the C compiler ( or if Jaguar were more successful then other tools companies could )

Link to comment
Share on other sites

Making the CD an add-on was the biggest mistake, everything else about it was a 'win' , CD gave much

more memory than carts for a far far lower price, and the logistics were way better.

 

the carts yes...the system however would have cost you $400.

 

 

Rubbish... You've got no proof for that.

The Mega CD was $300 a year earlier - and in some ways that had more components than the Jaguar :)

I'd expect Atari to reach $299 for launch - helped mainly by the removal of the pack in game cart and 68000 offsetting the cost of the CD mechanism. ( Also I'd expect there to be no 'butch' chip as the CD control would be part of Jerry )

Improved profits from game sales ( more of the royalty would be profit rather than the cost of manufacturing cartridges ) would also help Atari keep the initial cost down.

Link to comment
Share on other sites

I'd suggest that quite a lot of Jag RISC code runs at about 16-18MIPS

 

Would that also include code running from main memory? - My point ( before Gorf became totally emotional about it ) was more that the GPU/DSP running general purpose code from main memory in a fixed system ( rather than the bugged one we have ) would be better than a 68020 ( at 13MHz - I don't think a 26MHz 68020 would have been practical for the jaguar price - even the falcon and Amiga1200 only had slower speed cpu's )

 

( Losing the CPU gives the 32 bit path to Jerry for free as well :) )

 

No that would not include code running from main memory - thats more in the region of 5-15MIPS depending on the kind of code running. Which is why the important frequently called loops still need to be run from local.

Link to comment
Share on other sites

/me wonders out loud how hard it would be to retrofit a jag with a '020....

 

It would be better to just take a T&J and redesign the system around it. But if you were going to bother

just get an 030/040 or even better an 060 instead and then kick the clock of the T&J to 32 mhz.

PS1 would get a serious ass whooping. It's would still do more polies but the Jag would then kick

its tail in special effects...which the Jag already does .Sure the poly counts are lower but the quality

is much more able due to the flexibility of the Bliter and not being hardwired to do a few things

well...like the PS1's GPU....it is what it is and to escape that it then needs to use the MIPS to

cover for the lack of the abilities of the GPU.

what about lifting the existing 68k and adding some local cache (like the 16 MHz ST accelerators did)?

Link to comment
Share on other sites

I was just thinking that the only part of the system that really efficiently uses the 64 bit bus is the OP. Sure the blitter is ok for clears and copies to/from internal memories. But for general memory copies the page breaks end up limiting the process.

It might have been quicker to actually only use 32 bit memory, but have 2 banks - so that blit's wouldn't page break all the time.

That would also free up pins on tom to allow a seperate data bus for 68k/jerry and the dram.

Interestingly OP heavy games could have the 68k( or GPU/DSP ) running on a seperate bank to the OP.

Link to comment
Share on other sites

There was a C compiler for the GPU's - and if the bug was fixed allowing main code execution then it would be a lot more practical.

With C the entire codebase for a game would run on GPU/DSP ( I'd guess DSP - with sound running as an interrupt ) and development would be a lot quicker.

 

Yes there was a c compiler and running from main was the very least of it's problems. Clearly you never bothered to use it or you'd know just how absolutely horrible it was.

 

As far as using the 68k at all versus movei's....I'l take the movei's anyday even out in main.

 

Then the real bottleneck routines could be rewritten in ASM to get the final speed up.

If the GPU ISA was the only target Atari could spend resources on improving the C compiler

( or if Jaguar were more successful then other tools companies could )

 

Yeah but the 020 which would run off the bus already had tools therefore not costing Atari any

money in dev time.

Edited by Gorf
Link to comment
Share on other sites

I was just thinking that the only part of the system that really efficiently uses the 64 bit bus is the OP. Sure the blitter is ok for clears and copies to/from internal memories. But for general memory copies the page breaks end up limiting the process.

 

Then you obviously do not understand the blitter very well either. Even with a DRAM page breaks

its a much more efficient means of moving data even externally.

 

It might have been quicker to actually only use 32 bit memory, but have 2 banks - so that blit's wouldn't page break all the time.

 

Hardly. The blitter's is a much more able chip than you obviously know.

Link to comment
Share on other sites

Rubbish... You've got no proof for that.

 

No rubbish is you forgetting me showing you the price of a 2x CD rom back then was at best

a $99 dollar cost to Atari (and that is being very consevative) since they went for $199.

 

The Mega CD was $300 a year earlier - and in some ways that had more components than the Jaguar :)

 

And single speed and garbage to boot. I dont care how many more components it had it would

not come close to performing as well as the Cd add-on did.

 

I'd expect Atari to reach $299 for launch - helped mainly by the removal of the pack in game cart and 68000 offsetting the cost of the CD mechanism. ( Also I'd expect there to be no 'butch' chip as the CD control would be part of Jerry )

Improved profits from game sales ( more of the royalty would be profit rather than the cost of manufacturing cartridges ) would also help Atari keep the initial cost down.

 

Yes making the DSP cost that much more to produce so either was you still are looking at $400.

Link to comment
Share on other sites

Would that also include code running from main memory?

 

No because eiher way you are dealing with DRAM. So one way would not be any much beter than the other

way running from main.

 

- My point ( before Gorf became totally emotional about it ) was more that the GPU/DSP running general purpose code from main memory in a fixed system ( rather than the bugged one we have ) would be better than a 68020 ( at 13MHz - I don't think a 26MHz 68020 would have been practical for the jaguar price - even the falcon and Amiga1200 only had slower speed cpu's )

 

And like I said a 13 mhz EC020 woudl still be better than a GPU doing both rendering

and game logic and AI. At least with the 020 you will be off the bus most of the time

and would have no need for a seperate bus on the 020 thanks to the 020's cache which

for some strange reason you think is useless.

 

Three processors running in parallel OFF THE BUS is always better than two trying to

handle everything...even in paralelle off the bus.

 

( Losing the CPU gives the 32 bit path to Jerry for free as well :) )incorrectly I might add.

 

And puts the burden on two risc's where an 020 with two risc's all capable of staying off the bus

most of the time would be far better. Three heads are better than two.

 

 

Again...it's not that the 68k is a bad prcessor but because it MUST take over the bus when

operating, it completely chokes the system. A 68k with a 64k private RAM would have been

a great idea since the blitter would only need to pump in data to it rarely, keeping it off

the bus. It's not about which processor so much but which processor has the ability to stay

off the bus...the 68k dont, and 020 would and a dual risc only system would not be nearly as

efficient as three processors that could stay off the bus while running in parallel most of

the time...not matter how you slice it the 020 would have been the cheapest and best alternative

allowing a large jump in performance in both dev time and poly counts and no need to waste the

two RISC for AI and game logic. At best you could use the DSP for nice fast floats and still

maintain a rockin sound system, allowing the 020 to simply use the DSP here and ther for some

floating point results.

Edited by Gorf
Link to comment
Share on other sites

Just had an idea...seeming as though you lot are talking in terms of 'souping up' the jaggie

 

Why don't some of you get friendly with a soldering iron and using OTS components only, start over souping the jaggies performance (esp. in the processor, video and sound dept)

 

And perhaps there should be a prize for the most over souped jaguar

Edited by carmel_andrews
Link to comment
Share on other sites

I was just thinking that the only part of the system that really efficiently uses the 64 bit bus is the OP. Sure the blitter is ok for clears and copies to/from internal memories. But for general memory copies the page breaks end up limiting the process.

 

Then you obviously do not understand the blitter very well either. Even with a DRAM page breaks

its a much more efficient means of moving data even externally.

 

It might have been quicker to actually only use 32 bit memory, but have 2 banks - so that blit's wouldn't page break all the time.

 

Hardly. The blitter's is a much more able chip than you obviously know.

 

What are you talking about? The blitter would still be there - it would just run 32 bits instead of 64 bits.

A fast page access is 2 cycles - a page break is 5 cycles - so blitting from memory to memory is 2 page breaks ( one read / one write ) - 10 cycles for 64 bits in phrase mode. With 2 pages it would be 2+2 read for 32 bits - 8 cycles per phrase.

For pixel writes ( texture mapping ) it would be better - 4 cycles compared to 10.

 

The OP would be way less efficient with a 32 bit bus though.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...