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

[kool kitty89]

See bold

There is 16 megs of address space.

 

Yes, I know, 24-bit addressing, but that's total, I wan't sure about the reason for the 6MB game ROM limit until I read this:

It is an addressing space issue. The Jaguar has a 24-bit address bus (16 MB space). The lower 8 MB are reserved for RAM. The "missing" upper 2 MB in the ROM space are reserved for the boot ROM and I/O registers.

So in the current configuration you're limited to 6 MB (which isn't a big deal as ROM's expensive, but by '96 you could affor to do more, and 8-12 MB would be nice)

 

 

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)

 

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

 

I agree, and if you were to add anything more costly, I think it should rather be something to imporve the system's capabilities (like more RAM). Either just use the CD add-on later, or wait for the Jag II for discs.

 

 

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.

 

Ok, I wasn't entirely sure as your comments on spiffyone's proposal (post #99,100) didn't mention anything about the Panther, just not liking the MIPS R3000 part.

 

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.

 

Yeah, but at least in some cases it was simply due to poor support or bad timing, the XEGA for example was made from aging hardware and more importantly, was not supported particularly well or very long. (and was competing with Atari's own 7800 which had only had its full release a year earlier)

It may not have been Ideal, but I think something more like the XEGS (maybe with the pack-in keyboard replaced with a simple keypad with only the keys need to start/play the games), a more direct conversion of the A8-bit line, would probably have been a better option than the 5200. (since the 3200 was a bust and they needed a quice fix to copete with the Intellivision and Colecovision)

 

 

I definitely think the Lynx is a good option, I personally like the idea of introducing a 3rd low-cost, more compact model too. No backlighting, possibly running on 4 AA;s instead of 6 (maybe a 5th space noramally filled by a dummy- so NiCad's can be used 1.2x5=1.5x4) And a dedicated unlit screen will look a lot better than a backlit one with the light off (like Jag II) due to the reflective coating not possible with a backlight. (though you could have it side-lit)

I think Sega probably would have been good to do this too, particularly as Nintendo still didn't release a color system until '98, and even then with an unlit screen.

 

And setting up the Jag to allow the Lynx to be linked together with it (for play on the TV, or with Jag games supporting added features by linking to it -Nintendo did this with the GBA+GC) would have been interesting.

[Gorf]

Yes, I know, 24-bit addressing, but that's total, I wan't sure about the reason for the 6MB game ROM limit until I read this:

 

the limitation does not matter when you use bank switching anyway. How else do you think the

other 68k systems wth the same limit did it, NeoGeo for example? Zero is right it is no big deal.

The Neo Geo maxed out at 716mega BITS that is roughly 92 Megabytes. That would not be an

issue with the Jag either, but the cart bus is slow on the Jaguar...little to notice though as the data

would be compressed at ratios of upto 14:1 and quickly expanded buy a J-RISC. Of course the CD

change everything for all systems that had one.

 

 

Keep in mind we are talking 4069 on screen max. If there was compression I doubt it was much

as the 68k is hardly a compression master.

 

Of course the design of the NeoGeo was rather masterful. 214 kilobytes RAM

but dedicated for each processing task.

 

64k direct 68k ram

74k Main Video ram: 64k video ram, 8k pallete ram, 2k fast video ram.

2k direct Z80 sound with 128k on board sound ROM and allows an additional 512k add on in ROM.

Sad thing is they only filled 32k of the 128k onboard.

 

This is what the Jaguar should have done similar to.

 

020/J-RISC 256k

RAM 256/4k byte cache

 

..see right here would allow 020/J-RISC to stay off its external private bus while the blitter, in parallel,

grabs the AI and game logic info from the private RAM of the 020/J-RISC. No contentions if timed right.

 

Tom 1 megabyte RAM

 

Same here....the Tom can be doing all the drawing based on the game logic and AI data pulled from

the host private ram, while the Tom is drawing the current frame in its private, the 020/J-RISC would

be preparing the next frame of data in parallel with no contentions.

 

Jerry 786k RAM..simply load it with all samples and run the engine from the local. This would be the only

chip that the 020/J-RISC could write/read to set up sound and only its registers, not its memory.

 

Again, the only thing allowed to touch any other memory would be the blitter.

 

I would have designed the blitter to allow it to be multiplexed either to TOM's

main 64 bit bus or its OWN 64 bit bus. This way it would not hold up anyone

that was running locally and no bus contentions(in theory of course).

 

That bus would be latched on to which ever other GPU, DSP or 020/J-RISC's

private busses it needed to transfer data to and from any of the other processes.

 

Would have been one hell of a design. Might have been costly due to the

tons of logic one might need to allow such a parallel system.

 

Or would it be cheaper to switch to another JRISC rather than an 030? Ok, I wasn't entirely sure as your comments on spiffyone's proposal (post #99,100) didn't mention anything about the Panther, just not liking the MIPS R3000 part.

 

The Mips is a great processor, dont' get me wrong but it would have cost too much and really was not necessary with the right design.

Remember the Jag had a few years before the other systems.

 

Yeah, but at least in some cases it was simply due to poor support or bad timing, the XEGA for example was made from aging hardware and more importantly, was not supported particularly well or very long. (and was competing with Atari's own 7800 which had only had its full release a year earlier)

It may not have been Ideal, but I think something more like the XEGS (maybe with the pack-in keyboard replaced with a simple keypad with only the keys need to start/play the games), a more direct conversion of the A8-bit line, would probably have been a better option than the 5200. (since the 3200 was a bust and they needed a quice fix to copete with the Intellivision and Colecovision)

 

 

Atari blew it with the lynx. That had no excuse though. It had a great dev kit was a snap to code for, probably

The best VG system design ever. The Tramiels really blew it. You'd have thought they would have learned from

that miserable failure but then comes the Jaguar. Not only did they make all the same mistakes they did with

the Lynx, they blew every other thing including bugs in hardware and BS tools!

 

And setting up the Jag to allow the Lynx to be linked together with it (for play on the TV, or with Jag games supporting added features by linking to it -Nintendo did this with the GBA+GC) would have been interesting.

 

I just do not fiund this possibility interesting and I am quite confident no one would have missed it,

with killer games readily available.

Edited May 20, 2009 by Gorf

[ovalbugmann]

kk'89:

Either just use the CD add-on later, or wait for the Jag II for discs.

 

Uhh,... wait for the JagCD add-on to use later? When then? after the '96 bankruptsy. Doesn't sound like you had a Jag back then(you born in '89?), but back in '95 your forgetting "one" small "PS" thing. How can a cart system compete with a huge storage cd-rom 3D polygon pusher? - answer: It can't(athough Jag AI was better), even atari's jokers understood this, and thus there was the JagCD Player. If ya don't make it past the Jag there will be no JagII- and they didn't so there wasn't.

 

I don't understand many people's hate of the JagCD Player.

 

The BIGGEST problem Jaguar had, as Gorf or kskunk stated, was not enough A list software titles-period. A result of bad management, bad developer relations, bad dev tools, bugs and just an overall non-perfected Jag console design. More RAM and bigger chip caches, seperate 68K bus would have helped greatly.

Edited May 21, 2009 by ovalbugmann

[kool kitty89]

Yes, I know, 24-bit addressing, but that's total, I wan't sure about the reason for the 6MB game ROM limit until I read this:

 

the limitation does not matter when you use bank switching anyway. How else do you think the

other 68k systems wth the same limit did it, NeoGeo for example? Zero is right it is no big deal.

The Neo Geo maxed out at 716mega BITS that is roughly 92 Megabytes. That would not be an

issue with the Jag either, but the cart bus is slow on the Jaguar...little to notice though as the data

would be compressed at ratios of upto 14:1 and quickly expanded buy a J-RISC. Of course the CD

change everything for all systems that had one.

 

I was wondering about the Neo Geo's memory system myself (particularly the 330 Mbits w/out bank switching), then I got this response a little while ago:

 

The Jag is what it is mainly because it was cheap to make that way. Atari considered a 68020/30 -- the Jaguar chipset has support for either. They also considered NO 68000 at all, because even a 68K was considered pretty expensive for such a cheap console.

 

and offer more cartridge address space. (which won't be a problem with 32-bit addressing)

This would have been nice, but note that there were no bank switched games for the Jaguar. One reason is that large ROMs were quite expensive, especially compared to a CD. Atari even reduced Cybermorph to 1MB to save money.

 

Put yourself in the shoes of a game developer. 3DO says, 'Hey, we'll charge you $3 per disc.' Atari says, 'Hey, we'll charge you $12 for a 2MB cartridge or $16 for a 4MB cartridge. Um, you want 16MB? Sure, that'll be $40.' The stores say, 'We'll pay you $36 for each game we sell at $59'. Not gonna happen inside the Jaguar's life span...

 

Actually this leads to an interesting question, how did the the Neo Geo address the massive amount of ROM with the limited address space? Integral bankswitching? (which would be odd due to bankswitching supposedly increasing the normal 330 Mbit/41.25 MB limit to 716 Mbit/89.5 MB)

 

The Neo Geo has 5 buses on the cartridge. The graphics address bus is 25-bit (256 Mbit) and the 68K address bus is 24-bit (128 Mbit). Bank switching was also used for graphics in a few later games.

 

The Neo Geo is a good example of what happens when you let your engineers go wild.

 

So the majority of that memory isn't addressed to the 68k (so the "normal" 330 Mbits is w/out bank switching), granted bank switching would still be an option for the Jag, but even with a 24-bit bus, it probably could have been redistributed to allow 8 or 12 MB for the cart ROM (any more would be unnecessary, as ROM was too expensive).

 

This is what the Jaguar should have done similar to.

 

020/J-RISC 256k

RAM 256/4k byte cache

 

..see right here would allow 020/J-RISC to stay off its external private bus while the blitter, in parallel,

grabs the AI and game logic info from the private RAM of the 020/J-RISC. No contentions if timed right.

 

Tom 1 megabyte RAM

 

Same here....the Tom can be doing all the drawing based on the game logic and AI data pulled from

the host private ram, while the Tom is drawing the current frame in its private, the 020/J-RISC would

be preparing the next frame of data in parallel with no contentions.

 

Jerry 786k RAM..simply load it with all samples and run the engine from the local. This would be the only

chip that the 020/J-RISC could write/read to set up sound and only its registers, not its memory.

 

Again, the only thing allowed to touch any other memory would be the blitter.

 

I would have designed the blitter to allow it to be multiplexed either to TOM's

main 64 bit bus or its OWN 64 bit bus. This way it would not hold up anyone

that was running locally and no bus contentions(in theory of course).

 

That bus would be latched on to which ever other GPU, DSP or 020/J-RISC's

private busses it needed to transfer data to and from any of the other processes.

 

Would have been one hell of a design. Might have been costly due to the

tons of logic one might need to allow such a parallel system.

 

I mentioned something like that to kskunk too, but he though it would add too much to the price. On this note though, would it be most important to have the GPU on a dedicated bus, possibly having the DSP and GLP/CPU (JRISC or 020) share a bus, 1MB for each bus? (still more expensive than unified memory though)

 

You might be able to get away with these, but then you definitely would have to elliminate it being CD-based, though I think the system would have been OK on carts as long as the software was good. (the only disadvantage there is that developers would be attracted to the low cost and high capacity of CD's)

 

 

Uhh,... wait for the JagCD add-on to use later? When then? after the '96 bankruptsy. Doesn't sound like you had a Jag back then(you born in '89?), but back in '95 your forgetting "one" small "PS" thing. How can a cart system compete with a huge storage cd-rom 3D polygon pusher? - answer: It can't(athough Jag AI was better), even atari's jokers understood this, and thus there was the JagCD Player. If ya don't make it past the Jag there will be no JagII- and they didn't so there wasn't.

 

I don't understand many people's hate of the JagCD Player.

 

The BIGGEST problem Jaguar had, as Gorf or kskunk stated, was not enough A list software titles-period. A result of bad management, bad developer relations, bad dev tools, bugs and just an overall non-perfected Jag console design. More RAM and bigger chip caches, seperate 68K bus would have helped greatly.

 

The Jag CD is cool (pretty compact ad sleek apart from that one awkward asthetic issue), but it would be expensive, and if there were any other areas you want to improve with added hardware (more RAM -which was more expensive in 94/95 than '93, segmented memory with dedicated data buses, even just switching to a 68EC020 would add a bit), that would now be out of the question.

 

Are you saying that the Jag couldn't have good software w/out Discs? Even making a full released a year later than they's done that dumb "test market" would have put them nearly 6 months ahead of the Saturn's US release, and over 9 months ahead of the PlayStation. (and the PSX didn't really pick up until arround '96 as I understand)

 

To quote Gorf:

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?

 

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

 

 

Yes, I was born in '89, only 19, and I didn't have a Jag, didn't only had an NES until christmas of '95 (pretty sure, but it might have been '96), I grew up with Nintendo (we've got NES-Wii), but also with PC games (at home and school), but we almost always got systems used (exceptions NES and Wii), and often toward the end of their generation (the SNES was the most extreme case of this) So we probably wouldn't have considered getting a Jag until '97 at the earliest. (and that would greatly depend on other things as well, I really liked the N64 at the time -didn't get it til christmas '99, and most of my freinds had it, I don't remember many I knew having the PSX though)

 

Actually we had a CX-2600 packed away from before I was born, though it didn't get hooked up until around 2001/02 iirc, though I'd been bugging my parents about it for at least a year and then there was an incedent with a universal AC adaptor... but that's another story.

Edited May 21, 2009 by kool kitty89

[ovalbugmann]

Are you saying that the Jag couldn't have good software w/out Discs?

 

Oh no not at all. The Jaguar has most of it's best games on the cartridge format - even if their all 4MB or less although with expensive bank switching I've heard a cart can hold much more data.

 

Atari released the Jaguar CD to compete with the other emerging CD based systems of the time, but the Jag really wasn't as good as pushing polygons as the hands down console leader of the time: PSX was so the Jag couldn't really use all that extra storage as nicely as the PSX, since it was kinda like half in the 2D sprite world and half in the 3D polygon world. Of course still, with using the JagCD bigger worlds, more levels can be put into JagCD games for deeper games but the graphics were about the same on cart and JagCD, unfortunately. I thought it would have better graphics with more power as the Sega 32x(or was it the SegaCD) had with it's add-on, but alas the JaguarCD is only a storage device and the base unit would have to be improved as per how Gorf has said to really use it fully.

 

Sure it's got VLM-1 by Jeff Minter and can play Cinepak encoded video at 320x240 aspect ratio, 24fps, and with a very good and surprising 352.8 kbps CD data transfer rates considering it's lowly 2x CD drive, and it holds 790MB of data in a proprietory audioCD format, and also the average data rate for most all other CD products is only 150.0 kbps of data transfer per 1x of CD speed. That is just video(FMV) though and does nothing for the game graphics themselves really besides what I said above and of course providing the big video cutscences available only on the CD format and not Jagcart. I think the Jaguar II would have made much better actual in-game use of the large storage available on a CD.

 

I still like the Jaguar CD a lot though. I was waiting for it to come out in 1995 and rode my bicycle 20 miles to get one. Only 13 original games were made for it though.

Edited May 21, 2009 by ovalbugmann

[mcjakeqcool]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32 bit, the graphics in Jaguar games are the same as any cd32, 3do or 32x game, sure they look better then the MD and the SNES, but 64 bit systems like the Saturn, PS and N64 look much better, I personaly put my MD down for my Jag, and put my Jag down for my Saturn, but I never sold any of them, infact, the only console I have sold in my life is my Wii, infact I did'ent sell it, I gave it to me cousion, I don't sell my systems, as I am a collector, I will own any system and any game on this planet, I am a I own every system and every game collector, but that is just me. But, for a casual collector, or gamer, I would say that the Jag has a lot more to offer (e.g Flat shaded polygons in most of it's liabary) then the MD, but the Saturn has more to offer then the Jag (e.g a bulid in CD drive and more colors in polygonal games) so If I was a casual gamer, I would sell my MD for a Jag, but sell my Jag for a Saturn, if I was to advertise the console in '93 however, I would market it as a 32 bit system, as in '93 32 bit systems were the big thing, but 64 bit systems were unheard of, but I would indeed push it agresevly against all 16 bit systems, however to be honest, if I was Atari, around '95/'96 I would start production on a Jaguar 2.

[viMaster]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32 bit, the graphics in Jaguar games are the same as any cd32, 3do or 32x game, sure they look better then the MD and the SNES, but 64 bit systems like the Saturn, PS and N64 look much better, I personaly put my MD down for my Jag, and put my Jag down for my Saturn, but I never sold any of them, infact, the only console I have sold in my life is my Wii, infact I did'ent sell it, I gave it to me cousion, I don't sell my systems, as I am a collector, I will own any system and any game on this planet, I am a I own every system and every game collector, but that is just me. But, for a casual collector, or gamer, I would say that the Jag has a lot more to offer (e.g Flat shaded polygons in most of it's liabary) then the MD, but the Saturn has more to offer then the Jag (e.g a bulid in CD drive and more colors in polygonal games) so If I was a casual gamer, I would sell my MD for a Jag, but sell my Jag for a Saturn, if I was to advertise the console in '93 however, I would market it as a 32 bit system, as in '93 32 bit systems were the big thing, but 64 bit systems were unheard of, but I would indeed push it agresevly against all 16 bit systems, however to be honest, if I was Atari, around '95/'96 I would start production on a Jaguar 2.

That's retarted. Games don't make a system any "bits," it's the architecture. The Jaguar has a 64-bit architecture.

End discussion. 'Nuff said.

[Gorf]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32

 

 

Its like talking to a wall I tell ya!

 

 

Again, bits look like this:

 

010010100101001010

 

No consumer machine ever used more than 32 bit color, if that.

 

Even if the GPU is a 32 bit internal system, the hardware that does all the work is 64 bits

and reads and writes in 64 bits to and from the bus. The GPU and DSP and 68k simply direct

them on how to do it, perform AI and GL and sound and input. The fact that they must all

share the same bus is what slows them down greatly.

 

You could have 128 bits and still look 8 bit if you code the games with 8 bit color mode. This

is why the Jaguar typically looks 16 bit, as this is what happens when you port 16 bit titles over

with little to no updating of the graphics.

 

The Jaguar is 64 bits because it reads and writes 1,2,4,8,16, 24 and 32 bit color values 64 bits at a time.

 

1 bit color = 64 pixel writes 2 color

2 bit color = 32 pixel writes 4 color

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

16 bit color = 4 pixel writes 64k color

24 bit color = 2 pixel writes 16m color

32 bit color = 2 pixel writes 16m with effects

 

most ports used the following.

 

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

and rarely

16 bit color = 4 pixel writes 64k color

 

The blitter and the OPL write and read 64 bit values, perform 64 bit math on those values

and then write them into either a RAM buffer (blitter) or the line buffers(OPL). That is why

it is a 64 bit system. You do not need 64 bits on sound nor in game logic or AI or even the

3D math mecessary in 3D games.

 

 

Why be thick? Quality of games does not determine the bitness of a system. That simply determines

the quality of the deveolpment.

 

You can say that the quality of the games look like less quality but it does not change the fact that

the Jaguar is a 64 bit system with two 64 bit processors and a 64 bit unified main system bus(not JUST

the graphics bus as some would have you believe and again is part of the reason for the poor games.)

 

If every one developing for PS1 or Sega or N64 simply ported over 16 bit games, it would not change

the fact that those machines were 32(PS1), 32(Saturn) and 32(64 bit internal yet no one questions

Nintendo on this fact, F'ing hypocrites!)

[kskunk]

Interesting that the main focus here is on wanting to increase the capabilities of the jaguar

 

What we must remember is Atari were working on the Jaggie for over 2 years, surely if they wanted it to have dreamcast/saturn or PSx/PS1 beating capability they would have built that into the system from day one

 

I really like this quote because I think it points toward the real issue. The people who talk about 'fixing' the Jaguar in this thread are forgetting that the designers of the Jaguar built a system that is REALLY good at what it does.

 

The fact is, the designers of the Jaguar, in 1991, were designing a Neo Geo / SNES killer, not a 3DO or Saturn or Playstation killer.

 

Here's an example of what I mean:

 

Jaguar 2D sprite plotting: 53 million 16-bit pixels/second via OP

PS 2D sprite plotting: 33 million 16-bit pixels/second via GPU

Jaguar smooth shading: 53 million 16-bit pixels/second via blitter

PS smooth shading: 33 million 16-bit pixels/second via GPU

 

Jaguar totally dominates the Playstation at 2D or smooth shading! And dominates the Saturn, and the Neo Geo, and the 3DO...

 

Nearly all of the Jaguar's graphics power is devoted to 2D and smooth shading. Texture mapping is an afterthought. In the Playstation, it's the opposite. Texture mapping is the main event and 2D is an afterthought (implemented via texture mapped polys).

 

So it's wrong to suggest that the Jaguar engineers just didn't put enough raw power in. There is tons of raw power in the Jaguar. The real problem is that all that power is focused on features that the market ultimately didn't care about.

 

Let's see what the designer of the Jaguar has to say on this thread's topic:

 

Q) What are your biggest regrets about Jaguar (technology, games...)? If you can back to the past (with a time machine for example :-), will you change anything about Jaguar (and what) ?

 

A) It should have been able to run C, and do texture mapping. When we started all games were written in assembly, and Gouraud shading seemed enough. We were wrong on both those assumptions.

 

The Jaguar designers were very good engineers. They designed a massive System On Chip (Tom) before the term was even coined. They made their own freaking processor architecture. At that time, Tom was the largest ASIC ever produced.

 

Trying to second guess their detailed engineering decisions, like bitness, DRAM speed, bus width, is all just silly. They were far more aware of the best engineering tradeoffs in 1992 than any of us will ever be.

 

The real problem is that nobody at Atari in 1991, (including Flare), understood the market requirements of 1994.

 

- KS

Edited May 21, 2009 by kskunk

[kroogur]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32

 

 

Its like talking to a wall I tell ya!

 

 

Again, bits look like this:

 

010010100101001010

 

No consumer machine ever used more than 32 bit color, if that.

 

Even if the GPU is a 32 bit internal system, the hardware that does all the work is 64 bits

and reads and writes in 64 bits to and from the bus. The GPU and DSP and 68k simply direct

them on how to do it, perform AI and GL and sound and input. The fact that they must all

share the same bus is what slows them down greatly.

 

You could have 128 bits and still look 8 bit if you code the games with 8 bit color mode. This

is why the Jaguar typically looks 16 bit, as this is what happens when you port 16 bit titles over

with little to no updating of the graphics.

 

The Jaguar is 64 bits because it reads and writes 1,2,4,8,16, 24 and 32 bit color values 64 bits at a time.

 

1 bit color = 64 pixel writes 2 color

2 bit color = 32 pixel writes 4 color

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

16 bit color = 4 pixel writes 64k color

24 bit color = 2 pixel writes 16m color

32 bit color = 2 pixel writes 16m with effects

 

most ports used the following.

 

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

and rarely

16 bit color = 4 pixel writes 64k color

 

The blitter and the OPL write and read 64 bit values, perform 64 bit math on those values

and then write them into either a RAM buffer (blitter) or the line buffers(OPL). That is why

it is a 64 bit system. You do not need 64 bits on sound nor in game logic or AI or even the

3D math mecessary in 3D games.

 

 

Why be thick? Quality of games does not determine the bitness of a system. That simply determines

the quality of the deveolpment.

 

You can say that the quality of the games look like less quality but it does not change the fact that

the Jaguar is a 64 bit system with two 64 bit processors and a 64 bit unified main system bus(not JUST

the graphics bus as some would have you believe and again is part of the reason for the poor games.)

 

 

So to sum it up to people of lesser intelligence like myself you are basically saying that the games (for the most part) designed for the Jag are like using a Corvette to take old people shopping..... meaning yes the machine is very powerful and capable but the tasks given to it are mundane perhaps to simplistic for it thus not utilizing it's full potential?

[Gorf]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32

 

 

Its like talking to a wall I tell ya!

 

 

Again, bits look like this:

 

010010100101001010

 

No consumer machine ever used more than 32 bit color, if that.

 

Even if the GPU is a 32 bit internal system, the hardware that does all the work is 64 bits

and reads and writes in 64 bits to and from the bus. The GPU and DSP and 68k simply direct

them on how to do it, perform AI and GL and sound and input. The fact that they must all

share the same bus is what slows them down greatly.

 

You could have 128 bits and still look 8 bit if you code the games with 8 bit color mode. This

is why the Jaguar typically looks 16 bit, as this is what happens when you port 16 bit titles over

with little to no updating of the graphics.

 

The Jaguar is 64 bits because it reads and writes 1,2,4,8,16, 24 and 32 bit color values 64 bits at a time.

 

1 bit color = 64 pixel writes 2 color

2 bit color = 32 pixel writes 4 color

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

16 bit color = 4 pixel writes 64k color

24 bit color = 2 pixel writes 16m color

32 bit color = 2 pixel writes 16m with effects

 

most ports used the following.

 

4 bit color = 16 pixel writes 16 color

8 bit color = 8 pixel writes 256 color

and rarely

16 bit color = 4 pixel writes 64k color

 

The blitter and the OPL write and read 64 bit values, perform 64 bit math on those values

and then write them into either a RAM buffer (blitter) or the line buffers(OPL). That is why

it is a 64 bit system. You do not need 64 bits on sound nor in game logic or AI or even the

3D math mecessary in 3D games.

 

 

Why be thick? Quality of games does not determine the bitness of a system. That simply determines

the quality of the deveolpment.

 

You can say that the quality of the games look like less quality but it does not change the fact that

the Jaguar is a 64 bit system with two 64 bit processors and a 64 bit unified main system bus(not JUST

the graphics bus as some would have you believe and again is part of the reason for the poor games.)

 

 

So to sum it up to people of lesser intelligence like myself you are basically saying that the games (for the most part) designed for the Jag are like using a Corvette to take old people shopping..... meaning yes the machine is very powerful and capable but the tasks given to it are mundane perhaps to simplistic for it thus not utilizing it's full potential?

 

Yes corvette as a senoir citizen min-van. Good way to put it.

[Gorf]

The real problem is that nobody at Atari in 1991, (including Flare), understood the market requirements of 1994.

 

- KS

 

Thank you! People forget that nothing at that time touched the Jaguar. For the price is was clearly the best

silicon bang for the buck. Jaguar, 3 times less the price of a neo geo yet even with the unified bus, was much

more capable. More than 3 times the price for the 3DO too. Half the bus rate, the clock was less than half and

closer to a third of the Jaguar system clock. One risc versus two and a 68k. I know little about the actual

internals of the 3DO as no one seems to know outside of the signed developers but though it had many more

games and a few really fun games, it was no Jaguar in terms of power. It did texture map well for what it

did though.

[kskunk]

I know little about the actual internals of the 3DO as no one seems to know outside of the signed developers

but though it had many more games and a few really fun games, it was no Jaguar in terms of power. It did

texture map well for what it did though.

 

I've managed to dig up some technical docs on the 3DO, but they're hard to find. It's an interesting counterpoint to the Jaguar because it meets the market requirements of a next gen system -- it's just really underpowered. On the other hand, the Jaguar is far more powerful, but of course Atari marketing was a bunch of tossers and had no idea what the market wanted. We all knew that.

 

The 3DO was designed to be programmed in C and texture mapping is a core feature, two things the Jaguar missed out on. However, the 3DO's clock rate is slower compared to the Jaguar, and the custom chips are on an older process technology, which makes the chipset bigger, less powerful, and more expensive than Tom and Jerry.

 

The 3DO's ARM is weaker than the Jag RISC, but has the advantage of an excellent good C compiler and a bug-free memory interface, making large programs a cakewalk to make.

 

Like the Jaguar, there is no cache, so main bus bandwidth is a severe restriction. While the 3DO is texture mapping the ARM CPU is frozen.

 

This led to awesome graphics demos that turned into choppy games, since gameplay logic killed graphics performance.

 

No need to debate the 3DO's severe price disadvantage. That's been done to death.

 

- KS

[kool kitty89]

When I look at the quality of the graphics in Jag systems, I think it is clearly not a 64 bit system, but clearly not a 16 bit system, it looks decideivly 32 bit, the graphics in Jaguar games are the same as any cd32, 3do or 32x game, sure they look better then the MD and the SNES, but 64 bit systems like the Saturn, PS and N64 look much better,

 

Wait... Ok, the rest of the stuf you've bee repeating about the Jag not "looking 64-bit" and thus it seeming like atari was trying to pull something unsavory at least6 makes some sense from a common non-tecnically inclined consumer's pov.

 

But the Saturn and PSX being 64-bit??? Where did you come up with that? They aren't by any stretch, both ate 32-bit systems (and both have subsystems containing chips with lesser "bitage" like the Saturn's 68EC000 sound controller, and I beleive the PSX uses the same -or similar- 16-bit DSP in it's sound system as was used in the SNES; but this is common in most Systems, the Genesis had an 8-bit Z80 audio CPU, same for the Neo Geo and many contemporary arcade systems)

 

 

 

 

And guys (Gorf, kskunk), you mention designing a 3rd J-RISC (to act as CPU, with a large internal cache) would have taken time and possibly added to cost (more than just switching to the 020, though with volume production a custom in-hous chip would have cost advantages), but waht if another Jerry was added to be used as the CPU? It's got an 8 kB onboard cache, though I don't know if it could be connected to more than 32-bits of the bus. Would there still be too many bus hogging problems with this configuration? (assuming the major bugs were elliminated; and either way I don't see how it could be any worse off than with an 020, as loong as proper tools were provided)

 

The segmented memory proposal obviously has advantages, but I think the effect on cost might be too much, and (if we're talking about making changes in 1993) the development of the system was already centered on the unified memory configuration.

 

 

 

Are you saying that the Jag couldn't have good software w/out Discs?

 

Oh no not at all. The Jaguar has most of it's best games on the cartridge format - even if their all 4MB or less although with expensive bank switching I've heard a cart can hold much more data.

 

Atari released the Jaguar CD to compete with the other emerging CD based systems of the time, but the Jag really wasn't as good as pushing polygons as the hands down console leader of the time: PSX was so the Jag couldn't really use all that extra storage as nicely as the PSX, since it was kinda like half in the 2D sprite world and half in the 3D polygon world. Of course still, with using the JagCD bigger worlds, more levels can be put into JagCD games for deeper games but the graphics were about the same on cart and JagCD, unfortunately. I thought it would have better graphics with more power as the Sega 32x(or was it the SegaCD) had with it's add-on, but alas the JaguarCD is only a storage device and the base unit would have to be improved as per how Gorf has said to really use it fully.

 

I still like the Jaguar CD a lot though. I was waiting for it to come out in 1995 and rode my bicycle 20 miles to get one. Only 13 original games were made for it though.

 

The CD is OK, but I really think the initial launch should be just the card system so keep the cost down. I think it would be OK to released the Jag CD around the time it was in reality, around or a bit before the release of the Playstation in the US. There are certainly some games (mainly multiplatform or ports like Myst) that needed the CD, particularly those that streamed large amounts of video. I'm not entirely sure if releasing the Jag Duo would be a great idea though, it would depend on how much it would cost and how close it was to the Jag II's launch. If you could bring it out by to mid '96 for under $250, that's great, otherwise you might as well wait for the Jag II (or whatever it would be called; I kind of like the idea of Cougar), which should preferably be launched in late 1997. (though maybe that's a little premature, and you could still wait another year and beat the Dreamcast to the US maket by a full year, this might be goodif they took the time to develop some good copyright protection/anti-piracy measures)

 

But the 6th gen was one of the most crowded and inhospitable, with the PS2 dominating, a heay hitter (abeit very weakened) dropping out, and the new heavy hitter (MS) along with the old big N both struggled to compete with Sony's dominance, so I have no idea how Atari would have done. (probably would have eneded better than it did in reality after Tramiel sold it off to JTS... before which they'd supposedly been in pretty good shape financially due to several successful lawsuits)

Edited May 21, 2009 by kool kitty89

[carmel_andrews]

i think the saturn/playstation used a modified/abridged version of the 68k or the 020 processor

[Crazyace]

I was thinking about this a bit more, and I would only make the Jaguar a CD system rather than a cart system - no other changes.

 

A bit like I thought last year Old posting

 

Some of the more recent points are right - at the time the Jaguar was announced it was pretty good hardware. The pair of RISCs would give a 486 a good run for the money - and the platform was way more powerful than a 486 with VGA. The trouble was the software.

If the Jag had been a CD machine from the start ( like the PCengine ), the software would have been much cheaper to make and stock for stores - and it may have had more support from bigger US publishers ( or even JP ones like Capcom or IREM )

[kool kitty89]

Are you saying that the Jag couldn't have good software w/out Discs?

 

Oh no not at all. The Jaguar has most of it's best games on the cartridge format - even if their all 4MB or less although with expensive bank switching I've heard a cart can hold much more data.

 

Forgot to mention this in my last post: (according to kskunk) The Jag has 8 MB of address space reserved for RAM, and 8 MB for ROM, with 2 MB of that for bios ROM, so you've got 6 MB available for games. (and with the 14:1 compression Gorf mentions, that's effectively 84 MB when decompressed, ie 84 MB of CD space) I don't know how expensive bankswitching would be, if they included the hardware on-cart that wouldn't be a good option, so if anything, it should have been onboard the Jag) I don't see why it would have been necessary though, inless there are limitations on how the 24-bit address bus is distributed, I don't see why more address space wasn't allotted for games. (again anything more than 12 MB is unnecessary, -which would be effectively 168 MB using the compression)

 

I was thinking about this a bit more, and I would only make the Jaguar a CD system rather than a cart system - no other changes.

 

A bit like I thought last year Old posting

 

Some of the more recent points are right - at the time the Jaguar was announced it was pretty good hardware. The pair of RISCs would give a 486 a good run for the money - and the platform was way more powerful than a 486 with VGA. The trouble was the software.

If the Jag had been a CD machine from the start ( like the PCengine ), the software would have been much cheaper to make and stock for stores - and it may have had more support from bigger US publishers ( or even JP ones like Capcom or IREM )

 

That's wrong though, you're not going to get more developers on board putting out software of any higher quality (except maybe some streaming video and CD audio) any faster if all you do is add a CD drive. (and you're certainly not going to make that $200 price point at launch) All you'd probably end up doing is getting some ports form the Sega CD, and simpler ones from the 3DO (ie lots of FMV games, maybe some others that the 68k can handel)

 

Gorf already corrected you right after your original post. You've got to address the fundemental problems with the design, the biggest being the lack of tools for unfamiliar (custom) hardware, hence the uoveruse of the 68k and simple 16-bit console/Amiga/ST ports.

Switching to a 68020 would largely reduce the programming difficuly issue, as it's a lot more powerful than the 68k (faster, onboard cache, and double the data bandwidth -for Jerry too as it was stuck with the 68k on 16-bit data bus)

There are sill some other bugs and issues with the blitter and MMU that should be dealt with, as well as fine tuning the J-Risc's to run at full clock speed. (up to 40 MHz by design, would be 33 MHz with an 020) There's the segmented memory option, which would be nice, but that's a significant design change to the system.

 

The other options for dealing with the 68k issue is to either ass another J-RISC to use as the CPU (which would be really nice), or just stick with Tom and Jerry and add a small, unified cache and elliminate the CPU entirely. (both of these options would require good dev tools to be made, unlike the 020 which is already common)

 

 

BTW here's a good overview on the subject (by Gorf), the only thing not mentioned there is the 40 MHz possibility for the J-RISC's. (again limited ot 33 MHz with a 68020, but that's still a big improvement)

Edited May 22, 2009 by kool kitty89

[Gorf]

No need to debate the 3DO's severe price disadvantage. That's been done to death.

 

In the light of comparison it shows that at very least Atari offered more for less...then less when more was needed.

[Crazyace]

I was thinking about this a bit more, and I would only make the Jaguar a CD system rather than a cart system - no other changes.

 

A bit like I thought last year Old posting

 

Some of the more recent points are right - at the time the Jaguar was announced it was pretty good hardware. The pair of RISCs would give a 486 a good run for the money - and the platform was way more powerful than a 486 with VGA. The trouble was the software.

If the Jag had been a CD machine from the start ( like the PCengine ), the software would have been much cheaper to make and stock for stores - and it may have had more support from bigger US publishers ( or even JP ones like Capcom or IREM )

 

That's wrong though, you're not going to get more developers on board putting out software of any higher quality (except maybe some streaming video and CD audio) any faster if all you do is add a CD drive. (and you're certainly not going to make that $200 price point at launch) All you'd probably end up doing is getting some ports form the Sega CD, and simpler ones from the 3DO (ie lots of FMV games, maybe some others that the 68k can handel)

 

Actually I think I'm right. Having a CD instead of ROM reduces the risk for a publisher. Sure there may be just as many ports - but they are more likely to be profitable.

 

Gorf already corrected you right after your original post. You've got to address the fundemental problems with the design, the biggest being the lack of tools for unfamiliar (custom) hardware, hence the uoveruse of the 68k and simple 16-bit console/Amiga/ST ports.

 

Gorf gave his opinion

 

Developers overcome problems with tools - Doom , AVP, Tempest , Rayman , were all good games at the time ( in spite of the state of the atari tools )

 

 

Switching to a 68020 would largely reduce the programming difficuly issue, as it's a lot more powerful than the 68k (faster, onboard cache, and double the data bandwidth -for Jerry too as it was stuck with the 68k on 16-bit data bus)

There are sill some other bugs and issues with the blitter and MMU that should be dealt with, as well as fine tuning the J-Risc's to run at full clock speed. (up to 40 MHz by design, would be 33 MHz with an 020) There's the segmented memory option, which would be nice, but that's a significant design change to the system.

 

The other options for dealing with the 68k issue is to either ass another J-RISC to use as the CPU (which would be really nice), or just stick with Tom and Jerry and add a small, unified cache and elliminate the CPU entirely. (both of these options would require good dev tools to be made, unlike the 020 which is already common)

 

Would any of those changes improve Trevor McFur or Raiden?

 

BTW here's a good overview on the subject (by Gorf), the only thing not mentioned there is the 40 MHz possibility for the J-RISC's. (again limited ot 33 MHz with a 68020, but that's still a big improvement)

 

I went through the 'what if xxx' path for cpu/s etc before - it's fun thinking about things , but really how much improvement are you going to get. 40Mhz ( compared to 27Mhz ) is only 50% better - and it would be a major expense for the faster ram.

 

With CD's ( and better royalty models ) even EA may have supported the Jaguar

[Gorf]

Developers overcome problems with tools - Doom , AVP, Tempest , Rayman , were all good games at the time ( in spite of the state of the atari tools )

 

All of which could have been better, especially AVP and DOOM and even Minter himself told us he barely put the Jaguar to use

in Tempest 2k. EVery game you mentioned also took forever with fulltime deveolpment. Rayman? Im willing to bet it is mostly

68k utilizing the Blitter and OPL. It really does not need the GPU. ALL these games STILL overused the 68k so therefore the tools

were not suffice to do the job to the best of the machines ability or to the programers advantage. I could have written similar in

the same amount of time if that were my goal. I however realize Im wasting the machine potential when I could be doing it the

more efficient way. That will take much more time working part time in what little time I have, all by hand assembling the GPU

main RAM code, monitoring the process every build to make sure all is in its proper place.

 

Switching to a 68020 would largely reduce the programming difficuly issue, as it's a lot more powerful than the 68k Would any of those changes improve Trevor McFur or Raiden?

 

Not unless the coder desired it to but that is not the point. The Jaguar needed all the major PC titles coming out at the time.

You can bet a large jump in productivity and performance with a 68020 and in my estimation the Jaguar with a MUCH better

chance of maintaining its market share, if not owning. You theoretically double the efficeniecy by opening up the DSP to an

extra 32 bit access and the host(020) as well) and then some as the 020 has a 256 byte hardware cache. If you can't see the

difference I dont know how else to explain it.

 

I went through the 'what if xxx' path for cpu/s etc before - it's fun thinking about things , but really how much improvement are you going to get. 40Mhz ( compared to 27Mhz ) is only 50% better - and it would be a major expense for the faster ram.

 

I'll try again. Forget the 40 mhz. I can think of many reasons. Even at the same 27mhz system clock:

 

An 020 corrects a lot of bottlenecks.

 

The 020 is now 32 bits and twice the effective data rate to and from the bus.

 

Then you have 256 bytes cache in the 020 allowing reasonably contentionless buss access.

This would have allowed the 64 bit masters(OPL/Blitter) to have much more efficient accesses

to the main bus greatly reducing the bus contentions. It would have been able to read in to its

cache from the main bus once every so oftern, instead of one access per instruction.

 

The 020 now runs at the same speed as the two J-RISC's instead of half the speed.

At twice the speed and twice the data width you get on and off the buss that much faster.

 

The 020 is much more cycle efficient.

 

The GPU can now forget having to do AI and Game Logic and concentrate on drawing.

 

The DSP is now 32 bits as it follows the host. This allow twice the data for sound to be pulled on board into the local.

 

It would have made a great difference even without the seperated busses. How you don't see that I cant understand.

 

 

With CD's ( and better royalty models ) even EA may have supported the Jaguar

 

I do agree however that the CD would have made life easier. I also wish the Jag duo idea was the first Jaguar.

Edited May 22, 2009 by Gorf

[+swlovinist]

Atari Jaguar could have been handled alot better. Here is what I would have done and agree with some other posters on some things:

 

I would have waited until there was a better lineup before releasing the system

I would have launched as a CD unit only(keeping the price of games down)

I would have redesigned the controller and made it different

I would have packed in AV cables vesus RF switch cables

I would have done a different pack in game(Tempest would have been much better)

I would have done a compliation of Atari arcade games on one disk, along with info, pics, and possibly interviews of the orginal programers.

I would have gone out of my way to consult long time programmers about future games.

 

Most importantly, I would have really offered better development kits early to all developers so that there would be better tools to make better more polished games.

[kool kitty89]

The Jaguar designers were very good engineers. They designed a massive System On Chip (Tom) before the term was even coined. They made their own freaking processor architecture. At that time, Tom was the largest ASIC ever produced.

 

Trying to second guess their detailed engineering decisions, like bitness, DRAM speed, bus width, is all just silly. They were far more aware of the best engineering tradeoffs in 1992 than any of us will ever be.

 

The real problem is that nobody at Atari in 1991, (including Flare), understood the market requirements of 1994.

 

- KS

 

Yes, but was't there also a lot of meddling going on from Atari management? (including the Tramiels themselves)

 

From what Gorf's been saying it sounds like adding the 68k was a direct result of this.

 

And would the design team be the ones charged with building development tools for the system?

 

 

I'm still unsure on the CD issue, there are obvious advantages, particularly for developers, but would they have bee able to keep the cost down? (though there have been some comments on the decling cost of CD drives durring the period) Switching to a 1x speed drive would not be a good option though. (particularly given that the Jag CD used a nice 2x speed drive a bit faster than the average 2x speed drive at 352.8 kB/s compared to 320 kb/s of the Saturn and the "normal" 300 kB/s PlayStation and 3DO)

 

Would there be any issues with the limited system RAM if CD's were used?

 

And how about the possibility of simply using a second Jerry chip as the CPU instead of designing an additional chip? (or using the 020, or omitting a CPU altogether)

Edited May 23, 2009 by kool kitty89

[Crazyace]

Developers overcome problems with tools - Doom , AVP, Tempest , Rayman , were all good games at the time ( in spite of the state of the atari tools )

 

All of which could have been better, especially AVP and DOOM and even Minter himself told us he barely put the Jaguar to use

in Tempest 2k. EVery game you mentioned also took forever with fulltime deveolpment. Rayman? Im willing to bet it is mostly

68k utilizing the Blitter and OPL. It really does not need the GPU. ALL these games STILL overused the 68k so therefore the tools

were not suffice to do the job to the best of the machines ability or to the programers advantage. I could have written similar in

the same amount of time if that were my goal. I however realize Im wasting the machine potential when I could be doing it the

more efficient way. That will take much more time working part time in what little time I have, all by hand assembling the GPU

main RAM code, monitoring the process every build to make sure all is in its proper place.

 

 

I think sometimes you overestimate the negative effect of the 68k - I definitely agree that it was the slowest part of the machine, but I'm not sure it would make much difference to Rayman or Tempest ( The arcade only used a 6502 after all ) and they were 2 of the best titles on the machine.

 

 

Switching to a 68020 would largely reduce the programming difficuly issue, as it's a lot more powerful than the 68k Would any of those changes improve Trevor McFur or Raiden?

 

Not unless the coder desired it to but that is not the point. The Jaguar needed all the major PC titles coming out at the time.

You can bet a large jump in productivity and performance with a 68020 and in my estimation the Jaguar with a MUCH better

chance of maintaining its market share, if not owning. You theoretically double the efficeniecy by opening up the DSP to an

extra 32 bit access and the host(020) as well) and then some as the 020 has a 256 byte hardware cache. If you can't see the

difference I dont know how else to explain it.

 

 

PC titles were running on processors way better than a 68020 - I can see a technical difference , just not how it would change those titles.

 

 

I went through the 'what if xxx' path for cpu/s etc before - it's fun thinking about things , but really how much improvement are you going to get. 40Mhz ( compared to 27Mhz ) is only 50% better - and it would be a major expense for the faster ram.

 

I'll try again. Forget the 40 mhz. I can think of many reasons. Even at the same 27mhz system clock:

 

An 020 corrects a lot of bottlenecks.

 

The 020 is now 32 bits and twice the effective data rate to and from the bus.

 

Then you have 256 bytes cache in the 020 allowing reasonably contentionless buss access.

This would have allowed the 64 bit masters(OPL/Blitter) to have much more efficient accesses

to the main bus greatly reducing the bus contentions. It would have been able to read in to its

cache from the main bus once every so oftern, instead of one access per instruction.

 

The 020 now runs at the same speed as the two J-RISC's instead of half the speed.

At twice the speed and twice the data width you get on and off the buss that much faster.

 

The 020 is much more cycle efficient.

 

The GPU can now forget having to do AI and Game Logic and concentrate on drawing.

 

The DSP is now 32 bits as it follows the host. This allow twice the data for sound to be pulled on board into the local.

 

It would have made a great difference even without the separated busses. How you don't see that I cant understand.

 

Everything you say is correct ( as things are in hindsight ), but I still dont think that it would have made a huge difference to a lot of games.

 

When I first saw the Jaguar devkit and documentation , I didn't think that it was underpowered - I was impressed with the 'true colour' graphics ( The CRY mode was cool ) and how much more powerful it was compared with both the Consoles ( SNES / Megadrive+MegaCD ) and the computers ( Amiga 1200 , PC VGA. )

( The PSX and Saturn were in the future , and Doom had only just came out )

 

With CD's ( and better royalty models ) even EA may have supported the Jaguar

 

I do agree however that the CD would have made life easier. I also wish the Jag duo idea was the first Jaguar.

 

That's why I changed my mind - given the state of play back in 1993, a CD would have been the best thing for the jaguar - much more than any 'boost' in performance. After all Atari only sold 125000 Jaguars, even with great games like Doom, AVP , Rayman and Tempest.

 

 

 

As a separate thought - If there were no 68000 at all - what would have been really cool would have been cramming the DSP into Tom. - then you have 2 J-Risc's on the internal 64 bit bus, and no need for external interface logic

[DracIsBack]

From what Gorf's been saying it sounds like adding the 68k was a direct result of this.

 

I can see both sides of the 68K argument. On one hand, it absolutely had the by-product of generating many games that looked like they walked off the Sega Genesis even though the Jaguar had a lot more under the hood.

 

On the other hand, if it wasn't there, I have a bad feeling that the Jaguar would have had far fewer games than it actually had. Between Atari's track record, skepticism over the Jaguar's chances in the market, the poor development tools and the complicated architecture, not having the 68000 may have scared off developers even further.

[Gorf]

I think sometimes you overestimate the negative effect of the 68k - I definitely agree that it was the slowest part of the machine, but I'm not sure it would make much difference to Rayman or Tempest ( The arcade only used a 6502 after all ) and they were 2 of the best titles on the machine.

 

I think it is more like you underestimate the detriment of the 68k. Making a difference in two games that did not need the extra

horsepower has little to do with what I am talking about. Im am talking about the games that would have been better with the extra

power on board. Even before the release of the Jaguar the Tramiels were touting the 3D classic updates and that Jag could handle it.

The 020 would have made that very true.....right now it's partially true. With the right tools the 3D code could have been better.

IT was'nt and even if it was a simple 020 update would have made it much simpler to deal with.

 

The arcade Tempest is a vector monitor. You simply write a list of 2 point lines, their color and intesity. Very different from

rasterizing, shading and all the intense blitter effects used in T2k. A far cry from writting a simple list of colored lines my friend.

 

PC titles were running on processors way better than a 68020 - I can see a technical difference , just not how it would change those titles.

 

So you are telling me that those titles could not be improved upon? The Jaguar uses CRY mode to pull off that smooth lighting in Doom. PC doom

was still in 256 color mode and until recent homebrew re-writes using the doom engine, there was no such effects...there was flashing lights

but not like the Jaguar version did.

 

Doom on the Jag was as worthy as a P1 PC. That with a 68k no less which is a lot of the Doom code. The fact is with a 020, the entire sysetm

all around, is released of several bottlenecks....DOOM gets improvments in music playing at the PC resolution inthe 16 bit color it does now

at 60 fps instead of 256 x 160 at 15-20 FPS. Carmack's biggest issue with the Jaguar is the 68k needing to make to many bus accesses. It

seriuosly chokes the system. The techinical difference Makes games that run at horrible frames rate to run at frame rates twice or more.

 

PC title would have been much easier on the Jaguar with an 020. The game logic and AI on the 020 would have been not only much more efficient

but because of that 256 byte cache, would have stayed off the bus a lot more often. The 68k can only do so much and it does it very inefficiently in

comparison. Half the clock and one quater the bus width. The 020 is a far superior choice in this kind of unified memroy system, especially when

the main bus is 64 bits wide. a 32 bit Host is with a true hardware cache should be obviously more efficient than a 16 bit wide host without a cache.

 

Everything you say is correct

 

I agree.

 

but I still dont think that it would have made a huge difference to a lot of games.

 

I can't help you then. More power avaible to you and you cant think how to improve the current games?

 

I think this mentality in the development community is a LARGE part of the reason why the Jaguar failed.

This is the warm and fuzzy nonsense which in my mind equals laziness and a lack of pride in ones work.

 

As a separate thought - If there were no 68000 at all - what would have been really cool would have been cramming the DSP into Tom. - then you have 2 J-Risc's on the internal 64 bit bus, and no need for external interface logic

 

There is no 64 bit internal bus to the 2 RISC's. They are only 32 bits internal(GPU 64 bit external only using STOREP/LOADP).

The Blitter and the OPL are the 64 bit parts. Yes no 68000 would have been better than one choking the bus all the time.

Also everything you explained you liked about the dev kit was the hard ware and yes you should have been impressed with it.

The software side sucked by any standard unless your only interest was code worshiping the 68k because it was easier.