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

[Gorf]

I agree with just about everyting you said Spiff, except the MIPS.

Another GPU Core would have made all code movable anywhere

in the system and would have made things a lot eaiser.That with the

right tools. In the Oberon, the RGPU is exactly this. IT also is tuned

for high level languages such as C and C++.

 

The first jag as it was would have been plenty if they put true dual port

writebacks in the RISC's...no stalls. That is another 5 MIPS right there.

 

The best you can hope for is 18 MIPS from the GPU. That is with very

careful interleaved coding.

 

A double buffer on the Blitter registers.

 

Fix the MMU so code in main does not have to be hand fugded in mutliple passes.

 

A lock on the 68k after boot to force coders to grow a pair and code the RISC's.

 

 

 

These alone would have made the Jag very simply to code for. and it would have

performed very close to the PSX.....Ask John Carmack. He felt just the double

buffered blitter regs would have been enough to give the PSX a run for its money.

[Crazyace]

Maybe a good 'quick fix' might have been to feed the 68k via a single 64bit latch, so that it would only take cycles away one in every four access - It might not help load/stores that much, but the bus use on inline instruction decoding could have been reduced.

 

I'm not sure I agree with you ( or even with John Carmack ) - especially as the PSX was limited to library only access to it's hardware for quite a long time.

 

How much time do you save with the double buffered blitter registers? By my simple back of an envelope calculation I could restart the blitter in 6 cycles.. ( It is nice to have the luxury, but is it saving you that much time )

 

I think I tend to see more stalls in C style GPU code from indexed loads ( or the arithmetic needed to generate addresses ) than the rewrite ports ( being able to access 64k of data with a single cycle load/store was nice on the MIPs )

[Gorf]

Maybe a good 'quick fix' might have been to feed the 68k via a single 64bit latch, so that it would only take cycles away one in every four access - It might not help load/stores that much, but the bus use on inline instruction decoding could have been reduced.

 

A lock on the 68k after boot. that would have worked best. That and a good set of tools.

 

How much time do you save with the double buffered blitter registers?

I'm not sure I agree with you ( or even with John Carmack ) - especially as the PSX was limited to library only access to it's hardware for quite a long time.

 

I can fake this in software and it makes a difference but you need to do some interrupt stuff...the speed is

do to the fact that the GPU doe snot wait for the blitter. Every cycle counts my friend. You dont have to agree

but it is true. Two command set registers would free the GPU up significantly.

 

 

By my simple back of an envelope calculation I could restart the blitter in 6 cycles.. ( It is nice to have the luxury, but is it saving you that much time )

 

Yes and anything that keeps the GPU moving makes a difference. You would be quite suprised the amount of

cycles wasted per frame on the GPU waiting. It does not have to now and it would be much smoother with

double buffering the command register.

 

 

I think I tend to see more stalls in C style GPU code from indexed loads

( or the arithmetic needed to generate addresses ) than the rewrite ports

 

that is not how the sytem works though. the stalls are a result of waiting on

a previous result because there is nowher else to put them, regardless of

the extra cycles required for siad indexed loads. The trick with indexed loads

and stores is to make sure you use enough diferent regs before reusing the

sames ones....about 6 7 load/stores in a row and then you can repeat them

without stepping horribly on the pipe.

 

Otherwise you cause the pipe to stall horrendously. There are many ways to

defeat the stalls but you wont get much better that 18 mips per RISC on a good

day.

[triverse]

I don't know much about programming but I would like to say thank you to everyone that has posted in this thread. You all have made me sit here and read through all 5 pages of it in one sitting and I enjoyed every minute of it. Thank you.

[DracIsBack]

What a wonderful thread for all armchair Chief Executive Officers and Chief Technology Officers in us all!

[Gorf]

What a wonderful thread for all armchair Chief Executive Officers and Chief Technology Officers in us all!

 

True but 'if only' threads can still be fun.

[Gorf]

I don't know much about programming but I would like to say thank you to everyone that has posted in this thread. You all have made me sit here and read through all 5 pages of it in one sitting and I enjoyed every minute of it. Thank you.

 

 

Glad you enjoyed it.

[Video]

First-I don't know if exclusivity was done back then, but one thing I would have done as Atari, is get some exclusive things, likie Doom, Rayman stuff like that, but especially doom. People who actually saw doom for the jag pretty much agree, it's the best version by far, but it was also released for every 16+ bit system ever made.

 

At least keep it a while.

 

Second-Push more public adds for sure, the only add I ever saw, was a vague mention in a hunting magazine in the early 90's...a friggin hunting magazine, I'd have had it plastered on everything I could have, after all, if you can sell the system, the adds will pay for themselves. Seriously, I don't know how many people who see the thing, or I tell about it who have NO Idea that it even existed. To bad to, it was a kick ass system, flaws and all. If word had gotten out, it would have amassed quiet a following.

 

Third, I would have pushed a LOT more games that showedd what the system could do, rather than keeping up with the "me too's" that plagued the system.

 

And last bbut not least, as soon as the CD came out, I would have gotten a packin deal, ore released the Jagduo, eat the cost, or most of it and just push it.

 

I don't believe the Jaguar wouldn't have competed with the PSX/64, but with what I'd have done it might have been the Playstation of te early to mid 90's and escentually floated on to the next system, and therre would have likely been a next system.

[carmel_andrews]

I wouldn't have done anything different as, if i tried to Tramiel and his son's would have pissed all over my ideas FROM A GREAT HEIGHT

 

Remember, they were running atari, i'd merely be another number

 

Yes, i accpet that Tramiel kept atari going for as long as he did, but that was only because the europeans took to atari's hardware in the masses that they did, if tramiel's atari relied on it's core market (the US) atari would have gone under years before atari released the jaguar

 

If the jaguar had been released by a non tramiel owned company it might have stood a chance, but you would have had to have had some cunning marketing strategies that cost zero bucks/quid to implement to counter act the checkbook marketing that sony and nintendo were snowing us with (either that or the non tramiel owning company with the jaguar having a backer like bill gates/warren buffett or that ilk to furnish the jaguar with funds for marketing)

Edited May 19, 2009 by carmel_andrews

[swapd0]

The Jaguar was designed to be cheap so i won't say a 68020 or a R3000 CPU neither more memory, here is my list (* mandatory items)

 

* Fix bugs

* Include a small cache on blitter with a write buffer, so it'll work always in phrase mode

* Small cache on GPU/DSP, but keep the internal RAM

- RGB pack/unpack opcodes on GPU

- RGB lighting on blitter

* Pixel expand on blitter, so you can have a 4bit textures as input and write a 16bit pixels (just to save memory), using internal CLUT (not OP CLUT)

- 32bit data bus on DSP

- Bigger CLUT on Object processor, but keep the 8bit bitmap object as limit.

* CDROM instead of cartridges

- 256kb or less for the 68000

* Better development tools

* Make work Object processor in inverse mode, one pixel is written only once (just like a 1bit zbuffer)

- A second GPU will be great to use it as a programable graphics processor

- Some kind of memory card to save big game states

Edited May 19, 2009 by swapd0

[snakes3425]

Some of the things I would have done.

 

1. Fire Sam Tramiel

 

2. Delay the release of the Jaguar for at least a year until the technology is perfected and a decent launch library is ready, including a Killer App title.

 

3. Remove the Keypad from the Controller

 

4. Launch the Jaguar with a six button controller

 

5. Make sure Game Programmers are taking full advantage of the Jaguar's capabilities

 

6. Make the Jaguar a CD based console right from the start as opposed to a cartridge based console that requires a CD-Add on (Sega tried the same thing with the Sega CD, and we all know the result of that)

 

7. Better Advertising

[kool kitty89]

Gorf,

defenitely a great thrad, I foundit a little while back, and have been reading through bits of it (Ithink I've got most of it). I considdered posing something new, but a few newer threads ended up going in this direction (my Jag SF III one, this one http://www.atariage.com/forums/index.php?s...43757&st=50 the new Atari Panther one, ect)

 

However, there are a few questions/comments (some mentioned in the other threads already), that would fit better here.

 

You've menthined this before (including a couple times in this thread) but recently here: (see my comments in bold)

 

No I do understand that thought process but to be 64 bit before anyone else was smart.

It was the execution of that plan that was the real blunder here.

 

 

The 64-bit bus was needed to get the necessary bandwidth for the GPU/Blitter/Object Processor, correct. This came up about the Panther too, it's "Panther" object processor was related (predicessor) to the Jag's and required high memory speed, the Panther used a 32-bit bus with faster SRAM to acheive this, but this meant limiting memory to 32 kB due to the high cost of SRAM. And the 68k had to share that same RAM which the OP would be hogging. (the only cool thing about the Jag is that it seems to have been pretty capable of doing scaling sprite effects, sogood for some psudo 3D games like AfterBurner and similar games, though no rotation effects)

 

You can't expect next gen looking games without the right tools and support

of your developers. Clearly the contracts with Atari at the time were apparently

rather loose or nonexsistant to allow Sony and Nintendo to beable to come buy

them all out from under them.

 

Also one of the problems Sega had with the Saturn, rushed with limited Dev tools, not as bad as the Jag, and I think they eventually released better tools, but the execution of that console was a mess too. (and with some hardware complexity issues like the Jag, compounded by the dev tool issues, again not as bad as atari though)

 

Buggy hardware that could have waited another 6 months and made a big differenece.

put a private 64k RAM on the 68k. Let the GPU and DSP hog the main bus. Then the

68k would have not gotten in the way just to do AI. It would have ran fine in it's own

private ram, only allowing the Blitter access to it so it can copy data from the AI and

game logic in a simple blit op.

 

The DSP should have had its own 1 meg of RAM and the GPU with its own 1 meg.

The fact is that after you get sound and graphics data in the RAM it usually takes

up about the same in each. The blitter would be the only other system to be able

to access the other three gen purps memory for data sharing.

 

What the designers wanted was no 68k at all and a 2k unified cache between

the GPU and the DSP. However Atari wanted a warm and fuzzy processor in

there to make it easy on developers. That warm and fuzzy was a hugh part

as to why we are now soaked and left out in the cold.

 

So basicly reserve the 2MB for Tom and Jerry. (and no more RAM would need to be added with Tom and Jerry each using a MB? just the added 64k for 68k's game logic+AI?) I ask this because adding more ram would have dramatically effected the cost, in fact based on these prices http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm in '94 you really couldn't afford to add much more. (and with 3x 1M chips, the cost would be about the sam as a 4M one at that time) Or are you saying, TOM and Jerry should each have their own dedicated busses with 1 MB each, in addition of the 2 MB of main? (which would seem impractical cost wise and a considerable design change)

 

A question on the system's design though: I understand that that unified cache idea was planned for the hardware so that's undersatdable, but what kind of changes would be required to have used the 68k on it's on bus with 64 kB, would the system have supported it, with the 68k communicating through the unified cache you mention would have been added? (and prsumably in all cases Jerry would be hooked to the bus like Tom, with the full 64-bits)

 

You also mantion possibly adding a 3rd JRISC chip, like TOM but without the Blitter or OP, and 16 kB cache to act as the CPU and perform game logic and other necessary work (possibly free up Jerry to do more audio work), but how much would you need to modify the system for this? Though you did mention this really isn't necessary, particularly with the bugs and problems fixed on the other chips. (GPU RISC not bogged down by blitter, MMU issues resolved, both RISC's running at 40 MHz, etc) And this wouldn't address the "warm and fuzzy" thing either. (though with the large cache it would have a lot more room to work off the bus than the other RISC's, and would be better off in that respect than an 020/030 running on the main bus with their tiny cache)

 

Obviously a better "warm and fuzzy" could be satisfied by an 020 or 030 rather than the 68k, probably an EC020 (albeit 24-bit addressing) or EC030, though they'd still limit the system as they don't have much cache to work off the bus with (need to dig into main) if it was hooked up like the 68k (and if it had a dedicated bus like you mention, just stick with the 68k). The EC020 would be cheapest, and was used on the COJAG, but with the system up to 40 MHz you couldn't run it at the same speed, so you'd either be stuck at 1/2 (20 MHz), use a master clock able to be mutiplied or devided to desired speeds for both, or clock the JRISC's down to 33 MHz. You can go all the way to 40 MHz with the EC030 though, but that's going to drive up costs a bit. (and obviously the faster versions will cost more)

 

A MIPS R-3000 series like in the COJAG also could go up to 40 MHz, bu I think this is with the fastest, more expensive "speed-bumped" version (the PSX using the slower 33 MHz one), and that would be more expensive than the 68k series to begin with, albeit much more powerful as well. And it will have the familiarity aspect as well, not as much as the 68k archetecture though. The 64 kB cache would allow it to easily do game logic an dAI work without digging into main though.

 

 

With the bug fixes (including full 40 MHz) and a good SDK you wouldn't really need the "warm and fuzzy" processor though, as long as programmers have good tools to get the system working togeter, you don't need to add the extra "easy way out" which just adds unnecessary cost (albeit not too much) and invites underutilization of the system. (though, honestly it was the tools that did that, w.out tools or the 68k the library would probably have been virtually nonexistant)

The added 64 kB for the 68k to work with is a nice option though, wouldn't add much cost, makes coding easier on programmers (and porting from other systems simpler), and takes the burden of handling game logic and AI off of Tom or Jerry. (this would apear to be the ideal layout)

 

While simply switching to the EC020 (while fixing the major hardware bugs, probably not increasing speed), would probably be the quickest solution, and definitely helped a lot. (the SDK issue still being paramount though)

 

However, with the 68k like this (and presumably connected with that unified cache), would the memory addressing limitations change at all? (ie more than 6 MB for game ROM, thoug anything more than 12 MB really wouldn't be economically practical even by '96) ANd with the system at 40 MHz, would the main bus be any faster?

 

And is there any way the system could have been set up to allow for external RAM expansion? (other than using the slow cartridge bus like the Saturn did) And with the 64k dedicated for game logic, giving Tom and Jerry full use of the 2 MB of main, how limited would this make the system memory wise compared to the configurations used in the PSX, Saturn, 3DO, or N64? (the latter, of course also having consolidated memory, albeit using fast RBRAM on 9-bit bus)

Edited May 20, 2009 by kool kitty89

[kool kitty89]

A not on my previous post, the Panther was mainly flawed in similar ways as the 7800, very limited (fast) SRAM shared by the CPU and video processor. A video processor that is bus hungry and doen't use character modes or a framebuffer, thus making it difficult to program for. (and very difficult to port games) puting the OP on a dedicated video bus (which needed SRAM inless it got a 64-bit bus) and adding something like 256 kB of DRAM for main would have helped things, but not in terms of porting games over to it, and making these changes would add to cost.

Using a 64-bit bus would allow the OP to use DRAM (rather than the limited ant costle 32 kB SRAM), but I don't know how that what that would have cost, and would still having the bus hogging issues if shared. (I suppose you could give 256k to the OP and another 256k to the 68k on a seperate 16-bit bus) But this is getting really far in and belongs in the Panther thread. -a 256 k DRAM is 1/2 the cost in '91 of 1M in 93. (so ram would be 1/2 the Jag's cost)

 

 

 

The Jaguar was designed to be cheap so i won't say a 68020 or a R3000 CPU neither more memory, here is my list (* mandatory items)

 

- 32bit data bus on DSP

 

* CDROM instead of cartridges

- 256kb or less for the 68000

* Better development tools

 

- Some kind of memory card to save big game states

 

Could Jerry have been connected to the full 64-bits of the bus, or was it only configured for 32-bits in its current form?

 

Giving the 68k it's own bus would denfinitely help a lot, and with the RAM prices of the time http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm a 256 kB DRAM would on'y colst very slightly more than a 64 kB one. (actually it cuts off at '92 for 64 kB, but judging by the rest in 93-94 the price wouldn't have gone down)

 

CD-ROM would be nice, but only if they could get a good deal for it (and a 1x speed drive would probably be agonizing), otherwise you'd have to (initially) elliminate it to keep the launch price down.

 

Dev tools are definitely important, even more important than the hardware bugs. (though they kind of go hand in hand)

 

You know there already was the "Memory Track" memory cartridge for the Jag CD with 128 kB of EEPROM. (same as a standard PSX card or the Sega CD memory cart; though the saturn had a 512 kB one).

 

 

3. Remove the Keypad from the Controller

 

4. Launch the Jaguar with a six button controller

 

6. Make the Jaguar a CD based console right from the start as opposed to a cartridge based console that requires a CD-Add on (Sega tried the same thing with the Sega CD, and we all know the result of that)

 

7. Better Advertising

 

See above for the CD issue, only do it if it's cheap, otherwise release the add-on and jagduo when it is cheap enough. (and avoid a 1x speed drive like the Sega CD)

 

The sega CD wasn't really that bad, it was an interesting console that was a bit too expensive, sold fairly well (better than the Saturn outsie Japan or 3DO) but the main problem was with the western market's emphesis on promoting the interactive movie "FMV" titles, that were very popular and sold well, but lust like their 1980's arcade Laserdisc counterparts, failed due to riding a short lived fad. They should have deversified it a bit more (it had sime really nice scaling, audio, and even some simple polygon power), and they still probably could have pulled it out after the FMV fallout with some slick marketing. However, Sega of Japan killed the Sega Genesis, CD, and 32x (which was doing pretty well up to this point too) when the jumped the gun with the Saturn, didn't keep SoA in the loop (they probably would have canned the 32x had they known), and discontinued support for the Genesis+CD+32X simultaneously with no overlap to transition to the Saturn. (which was rushed, complex, and have poor development tools at this point)

And of course SoJ also rejected SoA's proposition to use the (N64) SGI MIPS chipset instead of the Saturn, and later partnership with Sony for the PSX.

 

 

And I like the idea of a pro controller with no keypad, but add one thing: a 2nd function button for the face buttons, effectively adding 6 more butons. (albeit still one less than with all 12 keys)

 

Some of the advertizing was cool, like Doom and AvP, and a few were down the middle, thoug the Cybermorph and Kasumi Ninja, and Doo the Math! ones were poor. (I've heard that odd time slots were also chosen)

I kind of like their early slogan: "Get Bit By Jaguar" a lot better than Do the Math! (that doesn't sound fun to most people...) though that "64-bits of mega power" thing was lame.

I was thinking on this and something like "Get 64Bit by Jaguar" or "Get Bit by 64-bit" would have been really cool and catchy IMO. (particularly the second one)

Edited May 20, 2009 by kool kitty89

[Gorf]

The 64-bit bus was needed to get the necessary bandwidth for the GPU/Blitter/Object Processor, correct. This came up about the Panther too, it's "Panther" object processor was related (predicessor) to the Jag's and required high memory speed, the Panther used a 32-bit bus with faster SRAM to acheive this, but this meant limiting memory to 32 kB due to the high cost of SRAM. And the 68k had to share that same RAM which the OP would be hogging. (the only cool thing about the Jag is that it seems to have been pretty capable of doing scaling sprite effects, sogood for some psudo 3D games like AfterBurner and similar games, though no rotation effects)

 

What I know about the Panther tells me it would have not been all that special in comparison. In fact,

I think it would have been a disaster and the only chance of it having any hope would be astounding

software better than Neo Geo....With only 32 k ram I doubt it would have been able to compete much

more over the Genny.

 

They should have not even bothered with the Panther to begin with and just have gone directly with

the 64 bit leap. The system design would have been started earlier and the money from panther would

be spent on the Jaguar instead and with the few bug fixes made Atari would have saved a lot of that

Panther dev cash for Jaguar's release instead of its development. We are talking like a handful of

registers making a giant difference. The 68k was by far the biggest blunder in the design. It should

have been an 020 or another RISC core on a seperate AI/game Logic Bus. Double buffer the blitter

registers. Fix the blitter clipping, phrase mode texture writes to pop up 4, 16 bit cry pixels instead of

one at a time. That means it would have texture/shaded the same amount of polies as it did in Gshaded

mode. Imagine all the current Jag games fully textured running at no less than 30 FPS...easily.

 

As far as rotation goes, no console in that generation (before PSX and Saturn) can rotate like the Jag can.

I point to the game over screen in Tempest 2000....that is several iterations of that image being rotated

every frame. The Sony as powerful a poly pusher, it was no pixel pusher like the JAguar. Saturn was much

better at this but the Jag is king of pixel and line and sprite primitives. You see the lack of pixel and line

gfx in the PS1 Tempest which uses polygon explosions but the Saturn does use pixel blasts and such but

only about half as intense.

 

Tempest:

 

1 ) Jag version

2 ) Saturn version

3 ) Sony Version

 

Also one of the problems Sega had with the Saturn, rushed with limited Dev tools, not as bad as the Jag, and I think they eventually released better tools, but the execution of that console was a mess too. (and with some hardware complexity issues like the Jag, compounded by the dev tool issues, again not as bad as atari though)

 

Not even close. You at least had C compliers for the sh2's with the Saturn. SH series chips were already popular and plenty of good tools for them,

where as no one had ever seen a J-RISC before. The assembler supplied was all you had. There was a C compiler for the J-RISC's but it was so

buggy it was completely useless for anything practical.

 

Devkits:

1 ) Sony(hands down and miles above)

2 ) Saturn could have been much better.

3 ) Jaguar ...just plain awful.

 

This includes the needed software and hardware (SMASM/ALPINE and whatver Sony had) too.

 

So basicly reserve the 2MB for Tom and Jerry. (and no more RAM would need to be added with Tom and Jerry each using a MB? just the added 64k for 68k's game logic+AI?) I ask this because adding more ram would have dramatically effected the cost, in fact based on these prices http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm in '94 you really couldn't afford to add much more. (and with 3x 1M chips, the cost would be about the sam as a 4M one at that time) Or are you saying, TOM and Jerry should each have their own dedicated busses with 1 MB each, in addition of the 2 MB of main? (which would seem impractical cost wise and a considerable design change)

 

One 64k dynamic RAM would have added a bit to the cost. Probably the same amount that stupid A/D converter

chip cost that they never used and ended up removing later anyway. That would be plenty to run gam logic on

and the cart could hold more data the Blitter could pop in if need be. Again the Blitter should be the only processor

to touch the entire system memory chain. That means the 68k, TOM and Jerry, have its own private busess. The blitter

can talk to any ovf those busses and swiftly transfer data between each sub system. Yes the design would be different

but no more expensive to design that way. This way you do not need a unified cache between the processors as this

would be the blitters job. However, this can't compare to an 020 or J-RISC in the 68k's place.

 

 

Obviously a better "warm and fuzzy" could be satisfied by an 020 or 030 rather than the 68k, probably an EC020 (albeit 24-bit addressing) or EC030, though they'd still limit the system as they don't have much cache to work off the bus with (need to dig into main) if it was hooked up like the 68k (and if it had a dedicated bus like you mention, just stick with the 68k). The EC020 would be cheapest, and was used on the COJAG, but with the system up to 40 MHz you couldn't run it at the same speed, so you'd either be stuck at 1/2 (20 MHz), use a master clock able to be mutiplied or devided to desired speeds for both, or clock the JRISC's down to 33 MHz. You can go all the way to 40 MHz with the EC030 though, but that's going to drive up costs a bit. (and obviously the faster versions will cost more)

 

 

No, the EC020 can run up to 33 mhz. Then you could run the J-RISC's at 33 mhz. There is no need to half the 020's clock

in this case. Atari did this because the 68k could only go up to 16mhz so they ran it at half the 27 @ 13.5 MHZ.

the coJag did run at a full 27 mhz on all processors, 020 included.

 

You also forget you just opened the 16 bit data bottleneck to a true 32 bit bus, on not only the host but now the DSP.

You just greatly reduced two bottlenecks with the 020. The 256 byte internal cache of the 020, as small as it sounds would

have saved a ton of bus cycles and with 6 mhz more speed per second, I can't see how it's not a win/win/win/win.

 

32 bit data host

32 bit data DSP

6 more MHZ

256 byte cache would provide plenty of extra bus relief to the main bus.

 

Again, the blitter wired to be the only chip allowed to access an other processors memory.

This easily blows away the 68k setup no matter how you set it up...simply blows it away.

 

I say to hell with warm and fuzzy bullshit. This was nothing more than an excuse to penny

pinch. Spend the money and have a proper compiler built for it. No need for warm and fuzzy

anymore....that has to be one of the biggest crocks of bullshit I've seen to date. With Pc's

using C compilers for their games, this should have been priority in the Jaguar dev cycle.

 

Imagine all the ported TOP games of that day being moved over to the Jaguar QUICKLY.

Sony had the insight to see this. If atari had bone this way Sony would have had to work

much harder to achive what they did by the time they released PS1.

 

A MIPS R-3000 series like in the COJAG also could go up to 40 MHz, bu I think this is with the fastest, more expensive "speed-bumped" version (the PSX using the slower 33 MHz one), and that would be more expensive than the 68k series to begin with, albeit much more powerful as well. And it will have the familiarity aspect as well, not as much as the 68k archetecture though. The 64 kB cache would allow it to easily do game logic an dAI work without digging into main though.

 

The PSX bus sytem is brilliant. If Tom and Jerry were put onto a similar set up it would have been as brilliant using

the 020/J-RISC and the seperate memory busses. Of course I would put 256k on the 020/J-RISC and 768k on the

DSP which is plenty for sound. The blitter is the communications master between them. The cart port needed to be

full speed and then the blitter could pop data and code in and out when needed right off the cart.

The 68k even properly setup would have suffered in comparison.

 

 

With the bug fixes (including full 40 MHz) and a good SDK you wouldn't really need the "warm and fuzzy" processor though, as long as programmers have good tools to get the system working togeter, you don't need to add the extra "easy way out" which just adds unnecessary cost (albeit not too much) and invites underutilization of the system. (though, honestly it was the tools that did that, w.out tools or the 68k the library would probably have been virtually nonexistant)

The added 64 kB for the 68k to work with is a nice option though, wouldn't add much cost, makes coding easier on programmers (and porting from other systems simpler), and takes the burden of handling game logic and AI off of Tom or Jerry. (this would apear to be the ideal layout)

While simply switching to the EC020 (while fixing the major hardware bugs, probably not increasing speed), would probably be the quickest solution, and definitely helped a lot. (the SDK issue still being paramount though)

 

No, with the 020 in the described setup, the SDK would not have mattered as the C compilers for 020 were more than

robust and so was the chip over its predecessor. The 020 would now be the AI processor and at 32 bits in its own RAM

would have been monster. It's just such a way better choice over the 68k in very aspect. Small assembler renderers

for the GPU would have been plenty. The DSP now can pull 16 bit stereo data in at one read cycle instead of two. If you use 8

bit like most games did to save space, you could even do dual stereo reads. That save tons of cycles right there.

 

To show you that 768k on the DSP would be plenty, Gorf classic probably has more individual samples tahn just about any

Jaguar game.

 

To give you an idea of the portions of Gorf classic...all the sound samples which include all sfx and one for each and every

sentence Gorf spoke came to about 750k. The rest of the game was logic and gfx. Tons of samples and plenty of room.

 

 

However, with the 68k like this (and presumably connected with that unified cache), would the memory addressing limitations change at all? (ie more than 6 MB for game ROM, thoug anything more than 12 MB really wouldn't be economically practical even by '96) ANd with the system at 40 MHz, would the main bus be any faster?

 

And is there any way the system could have been set up to allow for external RAM expansion? (other than using the slow cartridge bus like the Saturn did) And with the 64k dedicated for game logic, giving Tom and Jerry full use of the 2 MB of main, how limited would this make the system memory wise compared to the configurations used in the PSX, Saturn, 3DO, or N64? (the latter, of course also having consolidated memory, albeit using fast RBRAM on 9-bit bus)

 

Yes, the bus would be faster if you used the 33mhz setup with the 020 triple the efficiency, easy.

The J-RISC even better than that.

 

You can add ram to the cart. That is how the Alpine works. The cart port should have been allowed full speed access.

 

Again replace the 020 with another J-RISC core would be just as good as long as there was a decent

tool set for it. Actually it would be much better as the one cycle execution and pipline along woth a 4k

local...fugeddaboudit! I would easily have preferred the J-RISC core over either the 68k or 020 setup.

[otaku]

I think they should have:

 

Went CD to begin with (cheaper game costs-better sound etc oh and less hardware for buyers to get)

hold back a year to polish games more, try to make development easier. Making development stuff (SDK?) more easily available to developers

Redesign the damn controller all those extra keys are useless the damn thing is too big!

[kool kitty89]

Thanks for clearing that up Gorf. -so at 33 MHz the bus speed would be up to 132 MB/s? (and 160 MB/s at 40MHz?)

 

Would it be worth it to use an EC030 then to get 40 MHz rather than 33 MHz 020? (and would the 24-bit address bus of the EC020 really limit things that much considering ROM costs- or coult more of the address apace be dedicated to ROM -only 2 of the 8 MB of RAM address space was used)

 

Or would it be cheaper to switch to another JRISC rather than an 030? (it being a custom in-house chip rather than having to be purchased) With a JRISC it would also simplify the Jaguar II design. (no need for a 68k series compatible for backwards compatibility)

 

And what do you think about the CD drive, just do kind of like they did with the Add-on and later release the JagDuo, or go CD from the start? (the disadvantage being a significant price increase at launch, but the cheaper, high data capacity CD's would be attractive to developers and allow cheaper games with more profit)

 

And do you think they could have afforded to wait the necessary time for a proper release? (not in terms of competition, but rather considering Atari's financial situation, as they seem to have been in trouble up to the profitable court settlement in 94 -at least as kskunk describes it) I suppose thare were other options in the intrim though, and as you mention, the Jag could have gone faster had the Panther been dropped sooner. (though as I posted in #113 the Panther may have been able to be salvaged, but it would still have been dificult to port software to) They could possibly have gotten away with just the Lynx (maybe a smaller unlit cost-reduced version), and support for their home computers a bit longer. (or maybe release an earlier home console Derived from one of their computer designs)

Edited May 20, 2009 by kool kitty89

[kskunk]

so at 33 MHz the bus speed would be up to 132 MB/s? (and 160 MB/s at 40MHz?)

 

Bus speed affects cost of course. 133MB/second requires 62ns CAS time which is doable but a little more expensive than the Jaguar's actual 75ns CAS time. Remember that 70ns FPM chips were much cheaper than 60ns. And 160MB/second requires EDO DRAM which was quite expensive in 1993 (but got cheap fast).

 

Or would it be cheaper to switch to another JRISC rather than an 030?

 

Gorf is right when he says cache is necessary to use the JRISC as a general processor. Cache is not easy to design or verify. I'm sure they considered cache in Jag I but didn't have time to finish it without a delay. That's why cache had to wait for Jag II.

 

- KS

Edited May 20, 2009 by kskunk

[doctorclu]

It's 1993, I own Atari, which has already released the 68030 TT and Falcon computers in the ST line.

 

The Falcon has good colors, and a great selection of games.

 

Me, I would have refined the Falcon, given it a speed boost, sold a game system (if that is the direction we wanted to go) and sell it with a keyboard module later down the road.

 

Granted this is what Amiga did with the CD32, but it just seems like a logical progression.

[kool kitty89]

so at 33 MHz the bus speed would be up to 132 MB/s? (and 160 MB/s at 40MHz?)

 

Bus speed affects cost of course. 133MB/second requires 62ns CAS time which is doable but a little more expensive than the Jaguar's actual 75ns CAS time. Remember that 70ns FPM chips were much cheaper than 60ns. And 160MB/second requires EDO DRAM which was quite expensive in 1993 (but got cheap fast).

 

Or would it be cheaper to switch to another JRISC rather than an 030?

 

Gorf is right when he says cache is necessary to use the JRISC as a general processor. Cache is not easy to design or verify. I'm sure they considered cache in Jag I but didn't have time to finish it without a delay. That's why cache had to wait for Jag II.

 

- KS

 

Ok, was I just being dumb thinking the buss speed was related to the clock speed of the system. (26.59x4 = ~106.4...)

 

What do you mean by the Cache on the Jag, the unified cache mentioned, or the on-chip cache? (proposed 16 kB opposed to Tom's 4, and Jerry's 8 kB) (the latter wouldn't make too much sense)

 

The only reason I brought up the 030 was because it was offered at 40 MHz, so you wouldn't have to down-clock the RISC's to 33 MHz. (plus there's the 32-bit address, but that's a different issue) I was just wondering how much of a cost advantage it was to use their in-house chips opposed to purchasing one, though I ammagine the EC020 was pretty cheap by '94. (the JRISC would obviously be more powerful, and could possibly use a 64-bit bus connection I think)

 

It's 1993, I own Atari, which has already released the 68030 TT and Falcon computers in the ST line.

 

The Falcon has good colors, and a great selection of games.

 

Me, I would have refined the Falcon, given it a speed boost, sold a game system (if that is the direction we wanted to go) and sell it with a keyboard module later down the road.

 

Granted this is what Amiga did with the CD32, but it just seems like a logical progression.

 

I was thinking the same possibility on the Panther thread: http://www.atariage.com/forums/index.php?s...43762&st=25

 

If it was cartridge based it would have cost a lot less than the CD32. (granted you'd have to cut down a lot of the system to really make it cost optimized as a game console) Maybe switch to an EC020 (don't know how the lack of the on-chp MMU would effect things though)

 

One possible improvement over the Falcon could be use of a 32-bit data bus as you wouldn't have to worry about backwards compatibility issues (or was that a cost cutting measure?).

 

An interesting note is that the STe and Falcon offered the same controllers as the Jag (and presumably Panther).

 

I don't know how early it could be released though, had it been a parallel development with the Falcon, probably by late '92, otherwise it would be getting close to the Jag's release date. (even the alternate mid/late '94 one)

 

I suppose simply continuing to support their home computers would have been a good move in the mean time, though they were getting pushed out just like Commodore.

Edited May 20, 2009 by kool kitty89

[swapd0]

Something very important:

 

Include a cache on the Object processor, this can be easy because it would be a read only cache just to store the list and maybe the bitmap data, you only need to flush it on each vbl to be sure that is reading the correct data.

[mcjakeqcool]

Push it agressevly against the SNES and Mega Drive, tout it as a powerful 32 bit system, and demostrate it's 3d cabaibites in Jaguar commercials. Also I would make it clear that the Jaguar is a lot cheaper then the 3do.

[Gorf]

Thanks for clearing that up Gorf. -so at 33 MHz the bus speed would be up to 132 MB/s? (and 160 MB/s at 40MHz?)

 

IT would be based on the memory speed which would have to be faster but yes.

 

Would it be worth it to use an EC030 then to get 40 MHz rather than 33 MHz 020? (and would the 24-bit address bus of the EC020 really limit things that much considering ROM costs- or coult more of the address apace be dedicated to ROM -only 2 of the 8 MB of RAM address space was used)

 

There is 16 megs of address space.

 

Or would it be cheaper to switch to another JRISC rather than an 030? (it being a custom in-house chip rather than having to be purchased) With a JRISC it would also simplify the Jaguar II design. (no need for a 68k series compatible for backwards compatibility)

 

Cheaper per part yes but the initial cost to make another chip would be an issue.

 

And what do you think about the CD drive, just do kind of like they did with the Add-on and later release the JagDuo, or go CD from the start? (the disadvantage being a significant price increase at launch, but the cheaper, high data capacity CD's would be attractive to developers and allow cheaper games with more profit)

 

Would not have mattered as long as there was plenty of next gen games.

 

 

And do you think they could have afforded to wait the necessary time for a proper release? (not in terms of competition, but rather considering Atari's financial situation, as they seem to have been in trouble up to the profitable court settlement in 94 -at least as kskunk describes it) I suppose thare were other options in the intrim though, and as you mention, the Jag could have gone faster had the Panther been dropped sooner. (though as I posted in #113 the Panther may have been able to be salvaged, but it would still have been dificult to port software to) They could possibly have gotten away with just the Lynx (maybe a smaller unlit cost-reduced version), and support for their home computers a bit longer. (or maybe release an earlier home console Derived from one of their computer designs)

 

Panther was a completely stupid idea. It was not more powerful than say the Neo Geo....why bother?

Atari's name was in the trash and even they new never to publically mention panther till after the fact

of mentioning Jaguar....why do you think that is......I'll tell you why...they realized half way through

the dev of panther...."oh shit, this is a totally vain endevor."...too little too late.

 

Anyone who thinks releasing the Panther before the Jag would have been wise is clueless. It would

have buried Atari in 92. The machine was hardly a match for what was already out there. Now if they

had supported the Lynx much better and had it sold to tons more people and had tons more software,

they would not have needed a panther.

 

Consolized versions of computers would have been another disaster. Everyone else that tried fell flat

on there faces. It did not work for the 5200, CD-i and on there reverse, console to computer, Colecovision,

VCS computer, 7800 computer.

 

Though the reverse could have worked, everytime the support was shallow and the offering not much

deeper.

[Gorf]

Ok, was I just being dumb thinking the buss speed was related to the clock speed of the system. (26.59x4 = ~106.4...)

 

Actually it is related to the clock but you would still need faster memory.

 

What do you mean by the Cache on the Jag, the unified cache mentioned, or the on-chip cache? (proposed 16 kB opposed to Tom's 4, and Jerry's 8 kB) (the latter wouldn't make too much sense)

 

No by cacache he means a true cache in the local ram. The Local ram is not a cache. A cache

instead would have nullified the need for any main RAM GPU code. Caches load them selves

via the processor and the blitter would have one less duty to copy code in and out.

 

The only reason I brought up the 030 was because it was offered at 40 MHz, so you wouldn't have to down-clock the RISC's to 33 MHz. (plus there's the 32-bit address, but that's a different issue) I was just wondering how much of a cost advantage it was to use their in-house chips opposed to purchasing one, though I ammagine the EC020 was pretty cheap by '94. (the JRISC would obviously be more powerful, and could possibly use a 64-bit bus connection I think)

 

The J-RISC core would have been much better than either the 202/030. The 030 would have made the JAg cost closer to 3DO.

Much more expensive.

 

Again console to computer add ons or computer slashed down to console never worked well for anyone.

[Gorf]

Something very important:

 

Include a cache on the Object processor, this can be easy because it would be a read only cache just to store the list and maybe the bitmap data, you only need to flush it on each vbl to be sure that is reading the correct data.

 

 

You only need to do that now. The cache would not mean much if you still had to rebuild any fields

destroyed by the OPL. Instead of a cache the better would be to only have to update those fields

when needed. Then you would only need to refresh a position field or data image adderss field

only when it changed and not every frame.

[Gorf]

Push it agressevly against the SNES and Mega Drive, tout it as a powerful 32 bit system, and demostrate it's 3d cabaibites in Jaguar commercials. Also I would make it clear that the Jaguar is a lot cheaper then the 3do.

 

 

To tout it as a 32 bit system when it is CLEARLY a 64 bit system would not be wise. CAlling 64 bit was not the problem.

Not releasing enough unique and original software was....16 bit ports gave not one advantage to Jaguar. How could it?

You have Genny and SNES and Neo Geo and the other systems.....it destroyed the Jaguar. Why by a next gen system

with very little to show it's next gen capabilities? It completely senseless. Anyone who think a ton of 16 bit ports at release

of Jaguar being wise is not thinking....why spend 250 on a machine who's games aer already widely avaiable on all or most

other systems? Senseless.