The Atari Jaguar - Doomed from the Start!

[@GregsGameRoom]

Atari didn’t claim it was 64-bit because they “added two processors together.” It’s because it had a 64-bit bus.

[@adesignersperspective]

no, atari claimed it was 64 bit because of the two 32 bit processors. 32+32=64. this was literally why the atari jaguar's advertising slogan at launch was "do the math".

[@welliben]

@@adesignersperspective The 'do the math' thing comes from what is more powerful 16bit, 32bit or 64bit (i.e. what is the biggest number) as highlighted on her blackboard in the 'Do the Math' ad. Not adding numbers together to make 64. I'm afraid you've become a qualified Clifford! ;)

[@ArneChristianRosenfeldt]

How does a 64Bit processor look like? For example the Jaguar is limited to 24 MB memory by the 68k. If the processors (DSP, GPU) would stick to aligned 64 bit access, they could store 3 21bit pointers in one register or memory address. I know, starting with N64 vec4 is king, but on 1993 hardware vec3 is not much slower, but cheaper. PS1 also uses vec3. Of course there would still be formats like 4px times 3 color Channels. When you specify an address register in an instruction opcode, two bits would select one of the packed 21 bit, or as 4th option something exotic like displacement or unaligned or byte write.

[@coleshores]

I wish it has a 68020.. it had the 16bit 68000

[@Berserkr01]

Even better would have been the 68EC030 (like in the Amiga 4000 CR)!

[@coleshores]

@ indeed

[@Greenchrysopsaro]

I think I heard somewhere that the Jag Version of Rayman is the best playing

[@Kurriochi]

The Jag version has a bit more colour, but your powerups are taken away on hit, the sound and music are lower quality, the resolution is lower, the PS1 version has more animation frames (so, smoohter animations), the PS1 version has far more parallax scrolling... Overall the PS1 version is better. Also the D-pad on the Jaguar is awful, so the PS1 ver. controls better.

[@welchrebooted4739]

the atari jaguar was essentially saved by it's homebrew scene. I think a lot of the Jaguars failures (not all) can be contributed to their decades of bad mistakes, the best thing that came out of all this IG is that Atari along with Sega serve as crash courses on what not to do as a console manufacturer.

[@seishino]

As someone burned by buying an Atari Jaguar, they gained a bit of forgiveness by putting the whole thing in the public domain at the end. Going open for anyone is the best possible ending for any system, but especially a failed one.

[@monlynx]

How hard is it to do a proper search before doing a video? Ever heard of wikipedia or google?

[@welliben]

While you're generally quite right, there are a few factual and timeline errors in this. Atari never added the chips to make 64bit, that was 3DO casting shade in an attempt to disguise the fact they were charging three times the amount for a console of comparative power. It has a 64bit bus and the object processor and blitter are 64bit, which technically does actually make it 64bit.. although it doesn't look it graphically. The N64 is 64bit in the same way the Motorola 68k in the Genesis is actually 32bit of sorts (i.e. only internally with no way to send these 64bits anywhere else). The Jaguar also doesn't have a 68020 in it, and actually if it did the bus problems would probably not be so much of an issue, as one reason the bus is hobbled is 16bit access of the 64bit bus from the 68k and.. more alarmingly.. the Jerry DSP as well. And the Sega lawsuit was so late that the console was pretty much finished already and the Atari owners just pocketed the cash, much too late to develop a game from the IP. The on-chip ram on the jaguar's Tom and Jerry chips is not really the same as the Master system's graphics bus ram either. There are a few other flaws in your analysis as well, the most advanced arcade graphics during the Jaguar's development were flat shaded polygons, and texturing, ala Daytona, came out the same year it was due to be released which meant there was no chance of altering the hardware, later consoles had a chance to see where things were going, which is why the Saturn flips out and adds a second GPU halfway through development, as it started out much like the Jag. Most of your points are correct in the main though, games were too slow in coming and quite a lot were crap or meh - although in its slight defence 3D games were a massive step up in difficulty to program and the N64 only launched with two or three games as well (albeit very good ones) despite Nintendo being a massive titan and Atari having about ten people in their development team. Having actually gone straight from the SNES and Starfox to a Jaguar (followed by an N64), I do have to say Cybermorph at the time was actually quite impressive graphically... I think you might be rose tinting Starfox's graphics a bit there... when you take away the better artistic direction, the graphics are really primitive and render at a super low FPS. Sorry for the wall of text!

[@ArneChristianRosenfeldt]

Can you point at the time of the master system, please? App does not allow search in the transcript. Just imagine if one of the address generators could be switched from drawing a point pattern along a lines (delta x , delta y ) to delta left edge and delta right edge. Ah, uh we still need someone to set up the z values. So what if flat shaded, z buffered triangles would just vrooom out of Tom? Then provide an SDK which clearly profiles that the game coders loose all the fps before the blitter even starts!

[@undae1017]

Firstly, 3do price dropped to staggering prices at the beginning of 1994. It was expensive because the hardware was literally brand new. The arm60p was fresh and 2x CD-ROMs were brand new. It was genuinely just that expensive to manufacture. Nintendo had never sold systems at a loss, yet everyone seems to lap those underpowered systems up like crazy. Secondly, the jaguar and 3do performance is not comparable at all. The 68k has to be clocked double speed to match the arm60p MIPS. The 3do has unified ram that all chips have access to. 3do has a multithreading OS and 300mb/s bus. Nothing on jaguar is at the same graphical fidelity as something as simple as crash n burn, the launch title. Much less need for speed, starfighter, road rash, or Foes of Ali. There is a galaxy of capability differences between jaguar and 3do. Atari cheaped out and dropped the ball bro, plain and simple. Atari was publishing literal misinformation about 3do specs, sales, and even putting words in people's mouths with ZERO evidence. He even said absurd stuff about how the PS1 was just hype LOL yeah sure just hype... Grand coming from the guy who approved ad campaigns for garbage like club drive and that super scaler bike game that looks like it's for the SNES

[@ArneChristianRosenfeldt]

@@undae1017 I don’t get why everyone hacks on the 68k. It clearly is a relict from the hardware / software dev kit. A lot of registers are 16 bit or vectors of 16 bit so that a debugging tool on the 68k could inspect them. Trouble is that it made it into the retail version. Instead JRISC should have been fixed. Yeah, ARM is too CISC to reproduce as a master’s thesis, but JRISC feels even more reduced than MIPS in some parts. As I understood, no one uses interrupts. That is one of the most complicated part of a CPU ( for noobs ). Just give me raw performance and a reset line. Why no jump and link? Why does the quick displacement need two cycles to be added to the address register, where MIPS only need a single cycle?

[@undae1017]

@@ArneChristianRosenfeldt sorry should have specified. When I said MIPS I meant "million instructions per second"

[@ArneChristianRosenfeldt]

@@undae1017 yeah, I understood. Just that I read that students are able to implement MIPS without interrupts (or without delay slot ) as a homework. So when Atari wanted to in-reduce the 3 instructions Copper, they basically had an undergraduate homework to do. They reduced instruction length to 16 bit (and variable length like 68k) to not violate any copyright. Implement MUL and shift in a coprocessor. I miss rotate through carry and overflow flag. And uMAC / 32 bit MUL as in 386.

[@iwanttocomplain]

It was IBM's fault the Jaguar failed. It would have been popular in Europe because that area had all the Amiga and Atari ST supporters and surrounding game industry and if it's true that Atari per-sold 1.5mill, then they would have quickly had funds to ramp up supporting it with games and money and it could have taken off. But IBM didn't fill the order for 68k chips from it's factories, only managing a few hundred thousand maybe. So all those customer's got a refund and bought a different console or just some more games instead.

[@agramarten]

It would be useful if you were to provide some kind of source, evidence for this. Please do. Although about Motorola 68000 is that it is outdated when there is 68020 that is much better and initially Jaguar was to have latter yet Atari choose former for cost reason while CoJag arcade machine had latter.

[@iwanttocomplain]

@@agramarten oh yes the O20 would have been a big improvement. I read that in the Jaguar wikipedia article. It said the pre-sold 1.5mill but IBM, new to manufacturing failed to make more than a few thousand and the sales were lost. Perhaps there is a newspaper scan somewhere.

[@agramarten]

@@iwanttocomplain It wasn't just IBM as Motorola along Toshiba were ones manufacturing Tom and Jerry's yet yield was as low as 40% so if like you were trying to make 10 processors then only 4 of them were working without fault(besides hardware bugs from design standpoint that can't be rectified unless Atari introduces changes to design) ...

[@kushy_TV]

still feels wild to me how they got doom running on this somewhat well, even if it was cut down with lowered graphics.

[@nightmarezer0507]

0:03 You made more than a slight mistake my friend. That is why I am here. 0:18 A lot of stuff you are about to say "Isn't exactly true". Research really helps when you make a script for a video. You should try doing that to make sure you know what you are talking about. 0:41 Yes the Jaguar was a failure but I do not believe they "tripped up" as you claim in "every step". I will get into this part later. 2:24 You go into all these technical aspects. You could of just summed it up and said "It had a slow bus" that is all you had to say. You didn't have to get so detailed. Just a minor gripe but bro get to the point. 2:27 How is Jaguar Doom a mistake? Do you even know what you are talking about? 2:38 Do you realize how stupid of a statement it is to say "Who gives a shit?". You talked about Doom being on the Jaguar and then proceed to say "Who gives a shit". Do you realize how big of a deal having Doom on a console in the early 90s is? If you did just a little bit of research you would know that Doom was absolute huge at the time. Having Doom on a console was a big deal. It was a system seller. I will explain why a little bit later in the video. 3:14 Bro you are rambling on and on. Get to the point. 3:31 Bro just stop. Please. We get it. The Jaguar needed more work done to it. It's not that hard to understand. 4:10 Atari pulled a POG move by securing Doom on the console. What are you even talking about? Yes they made bad choices but they also made a few good ones. 4:18 Game console that never got released "sucks". Heard the Dreamcast 2 also sucks. My uncle has one in his attic. 4:36 If something doesn't sell well it automatically sucks. Earthbound barely sold in the USA when it was released. I guess it sucks too because it didn't sell right? 4:57 Do you understand the words that are coming out of your mouth? It sold for $250 dollars. Go look up how much a PC cost at the time. You would need a proper PC setup (Which costs thousands of dollars) to run Doom. So do you want to spend 1000's of dollars or pick up a Jaguar for $250 and a game for $60 and have one of the greatest games ever made at your fingertips? Doom was a system seller. Yeah it might of not sold well but if you had 2 brain cells in your head at the time you would of bought the Jaguar to play Doom instead of spending 1000s of dollars on a PC. A simple google search could of told you that. 5:38 Doom was released on a PC and you complaining about paying $250 for a Jaguar. 6:06 Doom 6:17 You have a very strong point. These games are horrible. 7:01 You show one of the most enhanced versions of Wolfenstein 3D and do not understand how big of a deal having Wolf3d and Doom on a system was at the time. Expecially a graphical enhanced Wolf3d. You brush off these legendary games like they aren't shit. 7:30 Yes because everyone that wants to play Doom has 1000s of dollars in their pocket to fork over for a 486. You are getting a wonderful deal if you wanted to play Doom by buying a Jaguar. Yeah it is a bit cut back from the PC version but it was still Doom. 7:42 Doom 7:56 Doom 8:20 Doom 8:59 They brought one of the most saught after game over to their system. They knew a few things I mean they made the 2600. Getting Doom on the Jaguar was a power move. 9:17 Doom 9:20 Doom 9:26 Doom 9:22 They were on better platforms yes. But the other platforms were highly expensive at the time. Did you ever do any research? Doom is far from pathetic. It was bigger than football at one point. Google and KZbin videos are your friends. 10:20 its id software (ieed) not i.d. 10:26 You are 1000% wrong about this. Doom was built from the ground up by John Carmack. Sandy Peterson went through the levels by hand to delete gemotry. Doom was built for the Jaguar. Jaguar Doom was also used as a base for other Doom Ports (The levels at least). You have no idea what you are even talking about. This is the reason I decided to type this up. If you are going to make a video do some research and know what you are speaking on. 10:33 Jaguar Doom at the time was the only port. So there was nothing else to compare it to. Yes it was better on the PC but the idea was you could play Doom with out shelling out 1000s of dollars. 10:52 D-o-o-m DOOM I'll say it again DOOOOOM. 11:20 JAGUAR DOOM WAS UNIQUE DO RESEARCH BEFORE MAKING A VIDEO. Jesus Christ get your facts straight.

[@archive3do769]

I'm not sure repeating doom over and over helps your point

[@nightmarezer0507]

@@archive3do769 Do you realize how big of a game it was at the time?

[@archive3do769]

@@nightmarezer0507 not big enough to put jaguar on top apparently lol

[@ArneChristianRosenfeldt]

Jaguar Doom has less color banding than PC Doom. I know that we must be glad for Atari to accelerate walls, but with 4 columns drawn at once and a debugged blitter for the floors (and GL_REPEAT for power of two textures), 320x240 would have been fluent.

[@gamecomparisons]

Where was the Motorola 68020 in the Jaguar? That would have been quite an upgrade for a $250 1993 console.

[@agramarten]

No. It was 68000 thus 24bit address width and 16bit data bus. 13MHz that is almost exactly half clock of Tom and Jerry were.

[@PancakeDev]

I still think the 2600 is worse in every aspect, and it's only respected because people forget gaming didn't start in consoles and "it's what we had". It's a machine clearly not made to go into the 80s, but they kept supporting it and canibalizing 5200 support. The only games actually worth playing are Adventure, mostly for historical reasons and a bunch of activision games, most notably pitfall. Everything else has a better version elsewhere or straight up sucks. And don't get me started on controlling the TIA.

[@Kurriochi]

Have you tried Solaris? It's (by atari 2600 standards) really good.

[@VikingBoyBilly]

It's processor was literally a motorolla flipphone?

[@johnjay6370]

I had the Jaguar and for its time the Hardware was FINE. The issue with the Jaguar was not its hardware but its games. What would have save the jaguar, honestly almost nothing. What could have made the Jaguar better, more 2.5d FPS games. Doom, Wold 3d, AVP all played Great on the Jaguar!!!! If the Jaguar had a Real mortal Kombat game like 1 and 2, Street fighter, and some more Arcade ports... Atari did not have the money and that was the main reason it failed.

[@ArneChristianRosenfeldt]

As launch titles. And then meet hardware demand for Xmas 1993.

[@johnjay6370]

@@ArneChristianRosenfeldt I would have loved a MK1 on the Jaguar in 1993. The jaguar is part of the lost generation (32x,3do, and Jaguar).. Alll 3 systems showed a little a little of what the future real next generation was going to bring... Doom on the Jaguar was the best port until the psx version... You needed a 1k computer to play doom as well as the jaguar in 1994..

[@ArneChristianRosenfeldt]

@@johnjay6370 I root for the 3do. Why did the second model come out so late? Fabs already ramped up yields for higher clock rate. Then add a cache on die similar to 486 so that it runs on memory which couldn’t reach those clocks. Backproject polygons onto the texture map and rasterize there. So you could draw quads (stream in texels row by row (or let’s say 8 rows at a time) and let the (smaller) framebuffer deal with random access. Okay, maybe ordered frame-buffer access becomes vastly more important with translucency and z-buffer. But order by texel is great for multiple textures? But not if not aligned like shadow maps or decals. Ah okay quads killed the 3do.

[@johnjay6370]

@@ArneChristianRosenfeldt I honestly think the 12MHZ CPU and the crazy high cost. The 3do struggled with DOOM because it's processor could not keep up even though it was rushed. The 32X was by far had the most raw processing CPU power, but its very low RAM upgrade and 7MHZ16bit bus also slowed it down. But when it comes to raw processing power working with its 256k memory, it was kinda of a beast. There is a full screen version of DOOM with all the assets facing all directions on the web and you can even take a look on youtube for it. There is also a developer that worked on a game for both the saturn and 32x and he stated the 32x outperformed the Saturn in some areas. Go figure!!!! anyways what do you think could have helped the 3do or 32x?

[@agramarten]

@@johnjay6370 While CPU of 3DO was clocked at 12MHz yet performance wise it was like 24MHz due to architecture of it while primary issue with 3DO is price point due to being licensed to be manufactured by several companies that did it for high profit margin to justify production of it. As for Doom on 3DO and Jaguar is that former was made in 2 months by company that is not one that made the game and its engine unlike latter that iD Software did it with Carmack and Taylor in like 6 months since they ported Wolfenstein 3D in 3 weeks that was polished too.

[@agramarten]

Atari could not have added more cache to the GPU due to maximum being 750 thousand transistors compared to DSP being 600 thousand on same manufacturing process as GPU. Aside from hardware bugs on GPU the "CPU" the 68000 dragged whole system down when everything it does could fit inside DSP and still have 82 thousand transistors left until reaching limit of 750 thousand. Jaguar could have had 128 bits for DRAM with 64 bits each GPU and CPU/DSP thus 2MB of RAM for each along direct access to.

[@ArneChristianRosenfeldt]

The Jaguar has problems to handle 64 bit. 128 are insane. The blitter already in 2d trashes the fast page-mode. So it would be nice if it would read short bursts like 4 phrases and then spit out 4 phrases in the other page. Video DMA would kick in between these bursts and should itself read bursts like two phrases for object descriptions or 4 phrases of pixel data. And then it could run expensive pixel shaders like shadows, scaling or color lookup while someone else uses the bus. I wonder if Jerry would need to load blocks at full speed. Like how does mp3 work. Could the DSP load a block just in time and transform and then have the first sample ready? For simple PCM samples the DSP only needs a 16bit bus. Bursts for memory typically allow the consumer to read while the burst proceeds. Even in burst mode, memory needs two cycles. Read and write cache of the blitter could be shared because memory can do only one thing at a time. Problem is of course that the blitter needs read and write access. So separate caches there are. Still concurrent access happens. Memory delivers 4px a time. So a one pixel per cycle blitter would progress fully over the buffer and be almost overtaken by the input. But output the is full and memory switches to write. A scalar pixel shader (as in N64) allows complex shading because there is only one. Lighter, darker, color look up.scaling. With two inputs, shadows and translucency would be possible.

[@agramarten]

Issue with that as far I can understand is due to hardware bugs along architecture relying on 68000 thus bandwidth of FP-DRAM was being unused due to developers needing to waste cycles in order to avoid bugs and potential system crash. Removing 68000 and integrating any function it did into DSP would remove bottleneck along those functions that 68000 did would been done in half time. Maybe even increase a bit the processor clocks of GPU and DSP since I suspect 68000 was limitation due to being 13MHz that is half the clock compared other two. Thus even with hardware bugs the Jaguar could have been at least twice as fast if M68000 was removed and any functions M68000 did were integrated into DSP. Considering that there would not be 16bit bus bottleneck of M68000 thus plausible it's functions could be done with considerably less than 68000 transistors in part due to those transistors were 2 or over 2 times higher operating frequency than on 13MHz M68000. More so if DSP had own FP-DRAM pool such as for audio that if I remember correctly Sega Saturn had 512KB of DRAM dedicated for sound. Since DSP would become full blown CPU by also doing functions and roles M68000 did on Jaguar along adding some more to increase flexibility in what it can do, more instruction sets and or 1KB scratch pad added.

[@ArneChristianRosenfeldt]

@@agramarten I actually don’t know how they did it, but the 68000 does not limit the speed of the system bus unless it needs to use it for itself. Priority of the CPU can set below the other chips. Yeah, so better not try 3d physics simulation on the CPU. It won’t finish. I don’t know how many voices we need. I thought that 4 voices for music and 4 for effects is enough? Audio is not my strength. So 8 streams round robin should not be a big burden for the unified RAM. Sadly, the DSP can only read 16 bit - so one sample. And it blocks memory for 6 cycles. Jerry is really broken. But then again if we just load uncompressed samples just in time, I guess it is not so bad. Add some nasty global optimization to fill up the now mostly useless RAM with the most common sample. Decompress on level load. Accept simple music. I wonder if in SuperBurnout all sound and logic could run in the lower/upper border and sky. Then on full scanlines the GPU keeps the object list lean. It would be cool if the blitter could load code into the scratchpad at full speed. Or better, JRISC needs a jump into subroutine of length x in DRAM instruction, which blocks CPU instruction fetch for instructions not yet fetched into the scratchpad (like when a branch skips a block). Of course I want a shortcut so that the newest phrase goes directly into the instruction register. Likewise it would be nice to load structs, but LOADP is good enough mostly.

[@agramarten]

Motorola 68000 is considerable bottleneck thus removing it and adding co-processor that does every task it did to Jerry would be much better as too add 256 bytes each for instruction and data cache. Add 16bit FPM DRAM bus for 512 kilobytes of FPM DRAM to reduce conflicts with Tom when comes to memory. Thus Tom could have entirely of four 512 kilobytes for itself to use for z-buffer, framebuffer and texture data.

[@ArneChristianRosenfeldt]

@@agramarten what is wrong with the JRISC DSP? Why do you need more than two Turing complete processors? JRISC got the MAC instruction from the Motorola DSP in the falcon, but otherwise is a general purpose processor. For example it does not have zero-overhead loops. For me it just still longs too much after reg-mem instructions. I want a core with 3 port register memory and 6502 like ALU . Those instructions run scalar . JRISC adds this score board. I think you can LOADP and use the loaded value at the same time when it is written to the register file. Texture memory does not help much when you do the math. When you utilize the full 720px resolution of the Jaguar, and squeezed your textures into a small cartridge, textures will always be scaled up. So the blitter re-reads the same pixel or at least the same phrase multiple times. You need a CLUT and then pack 4x4 px @ 16 colors in each phrase. I would love if for more vertical antialiasing the blitter reads a slightly displaced line at the same time and takes the average (sum, SHR ) after CLUT. Half of the textures will be blown up quite big. So texture reading cannot saturate the memory. Furthermore, in a game loop are no conflicts. It is quite serial thing (to achieve arcade like low latency). Read control inputs, physics, game logic, trigger sounds, clip triangles, Blitter, VideoDMA. And JRISC has the scoreboard to be able to proceed while the system bus is occupied. VideoDMA and memory refresh operate using a pressure model : priority rises closer to the deadline. The blitter should have some flexibility in its in and output buffers. It would need a queue to replay texture coordinates this time to fetch texels out of the cache. I like how JRISC uses a single format : 6+5+5 bits. Condition codes for jumps use 5 bits. 6502 only needs 3 . JRISC wastes a lot of its 64 instruction encodings. A single jump instruction may be enough? Anyway, the 5 bit allow to express : never, always, not positive for a 32 bit value, not positive taking into account the carry flag (CMP or sub of unsigned numbers). ROL 1 puts the sign of both operands into bit 0. Let’s say this is the high word and sign extension. Then ADC or SBC give use the sign of fully signed arithmetic. Or use shift. And then check for zero flag. I feel like it should be possible to place bit 31 and 32 in such a way into a register that the cond. can express < > and overflow.

[@jamesstaggs4160]

I was a teenager back then and had spent a few years as a young child playing an Atari. I was more into PC gaming by then but the specs on the Jag seemed good and I always rooted for Atari. This thing failed due to a lack of unique software of any quality. The best games on it were on other platforms and they didn't really look any better than they did on lesser systems. This thing had potential but from what I understand it was a bitch to program for unless you used a "lesser* mode

[@eskimopi8617]

Not enough focus on an SDK, mistakes with a more experienced manufacturer to make more for launch, not the best marketing. Ultimately going to recede to SONY anyway. It is host to a bunch of best ports and great games, a luxury to play. For a console collector having the best dozen games would satisfy, but I would be upset if it was my only console.

[@agramarten]

Because upper management at Atari wanted for all games to be written in assembly and software development kits were not a priority as they wanted good competent programmers to make games on their consoles because assembly is king. Yet they also choose for Motorola 68000 to be I/O processor and to ease in some developers, it is contradictory. They should have picked 68020 or even 68EC030 since 68000 nor 68020 had memory management unit unlike 60830 while 68EC030 doesn't have MMU. Doing some research it seems that system memory was clocked at same frequency as 68K and DRAM controller on Tom thus one or other could be reason for that, hence there was only 106 megabytes per second bandwidth from system memory when it should have had been 212 MB/s since it is 64 bit wide memory bus while graphic cards in 1994 that had 64bit width and FPM DRAM were having 240 MB/s. Simply doubling bandwidth could yield 25 percent increase in performance though question is if 68000 was at fault or is the bugged DRAM controller that is causing halved system memory bandwidth. If instead of 68000 there was 68EC030 then communication between it and Tom / Jerry processor would not stall by needing two cycles to send information since both address and data bus were 32 bit registers. Another is 68EC030 had both instruction and data cache hence it would need to constantly rely on system memory bandwidth in order to function unlike 68000 that had neither hence basically a hog. Also 68EC030 could match clock frequency of both Tom and Jerry while its performance could be comparable to 486DX clocked at 40MHz thus by itself alone in theory could run a port of Doom without utilizing processing from either Tom GPU and Jerry DSP/CPU. To add if hardware was not bugged and blitter processor had a decent cache then performance when texturing polygons would have been at least increased three fold according to John Carmack thus in theory if there was no penny pinching from Tremiel family as too focusing on Jaguar from get go instead of diving resources to Panther until 1991 that was even more buggy and too late. Perhaps Jaguar textured polygon performance could have been 4 or 5 times better than what it ended up being in our worst timeline. What a shame, it could have ran over 3DO in 3D graphics ...

[@ArneChristianRosenfeldt]

@@agramartenMemory is very expensive. That is why consoles had none. Now with 2 MB Atari still opted for cheap memory which can only run at 14 MHz . I guess someone did the maths with the nanoseconds and RAS CAS stuff. PCs tried odd frequency ratios and edo RAM. On a breadboard we learn to minimise lead lengths. I wonder why Atari did not place Tom in the center of the memory chips with 1:1 traces for data. And the 20 bit address I would shot around in a circle with extra long leads with impedance matched termination. With some fancy PLL we could skew the bytes and also max out the frequency for memory and core! Yeah, it is really strange that the blitter cannot even gobble up like 32px of a 2d object line and then spit it out in one go. The hardware devs clung to their idea of two 32bit memory banks too long. Bad team communication/direction.

[@HENN3H]

One pertinent question remains: Where DID you learn to fly?

[@fattiger6957]

Even if the Jaguar was perfect in its tech and had the most powerful specs, Atari failed in every other regard. The fact is no one wanted the Jaguar. It didn't have any truly great killer apps. The marketing sucked. And, for kids in the 90s like me, Atari was a name you associated with old people since many of our parents or grandparents had a 2600 collecting dust in a cupboard. The PS1 is the blueprint for how to launch a console. Have a pre-existing good reputation for the manufacturer (Sony's rep as a consumer electronics company was pristine) Court a ton of 3rd party developers and give them better terms than they were getting with the competition. Buy development studios to make exclusive games. And spend an absolute butt-ton of money on marketing (I heard Sony spent $200M on marketing the PS1, 10x as much as Sega did for the Saturn) All of what Sony did, however, requires the kind of money that only billion dollar corporations possess. That's why the console space is now dominated by corporate giants and why smaller companies like modern Sega and modern Atari will never release a mainstream console. And that's also why you shouldn't buy into an Ouya-like pie in the sky dream of crowdfunded consoles.

[@agramarten]

No one wanted Jaguar is outright lie, if it went perfectly with technology by having no hardware bugs and manufacturing was not hampered by low yields of custom processors then more units could have been produced in order to facilitate general launch in nearly all states in the union. Marketing sucked initially which improved over time though that was too little too late when it was less cringe, more on point. If there were no hardware bugs then developers could have focused on writing game code instead of implementing work arounds at nearly every corner to get performance along to not crash console. Then games that were in development would have been considerably easier for the Jaguar to point depending on game it could have came sooner or more complete, some even release on Jaguar. Jaguar could have had put up a decent fight against Saturn and PlayStation if right decisions were made during development which goes as far back as 1989 when developed along side Panther that was more bugged and being far enough when rumors next generation consoles happened hence cancelled. Resources were split because both Panther and Jaguar were being developed at same time when if they focused on one or other they could have completed it sooner or at same time without hardware bugs. Also even with hardware bugs if 68020 was actually implemented in Jaguar instead of 68000 then it could have been variant closest one to matching clock speed of Tom GPU and Jerry DSP/CPU custom chips. By late 1992 or early 1993 there were economic cost variants of 68030 the 68EC030 at 25MHz for 34USD that is perhaps 20USD more expensive than 68000 used in Jaguar being MC68HC000FN16 that is low power consumption model at 16MHz yet clocked at 13MHz in Jaguar. 16MHz 68000 does 2.8 MIPS and 25MHz 68030 does 9 MIPS while slightly better than 25MHz x486DX. Another is EDO RAM was mass produced since 1991 and widely available same year since it is improved FPM DRAM derivative while mass manufacturing of SDRAM was in 1992 and widely available in 1993. FPM DRAM 5-3-3-3 | EDO RAM 5-3-2-2 or was it 5-2-2-2 | SDRAM 5-1-1-1 latency cycle Hardware would stall far less with SDRAM and bandwidth would be more efficiently utilized. Also if blitter that does depth/z-buffer calculations along can texture polygons had sizeable cache then performance would improve three fold according to John Carmark of iD Software and possible it would have been more than that if hardware bugs were resolved, Lastly bandwidth of Jaguar does not make sense as 106 megabytes per second is too low for FPM DRAM rated at 70ns latency on 64 bit wide system memory bus considering graphic cards in 1994 that also had 64 bit bus and FPM DRAM at 60ns did 240 megabytes per second bandwidth. Thus bugged DRAM controller halved clock of FPM DRAM or could not use every other cycle from it yet possible it is fault of 68000 used as control processor since it is half clock of both Tom and Jerry. Thus if data could have been processed without needing to store it in cache to process it due to hardware bug while Blitter had cache added to it to not resort to using graphic processor's SRAM then with double bandwidth as too much lower latency... Performance with textured polygons should improve at least five fold and maybe ten fold at most.

[@Glenn83100]

The funny thing is If I have to sell my game collection The jag will get the most money. Lol 😂

[@davidray4506]

Nice.

[@helenakesina4697]

Second