Jump to content
IGNORED

What is the Atari Jaguar's Biggest Design Flaw / Problem?


Jag64

Recommended Posts

This isn't about poor marketing, pre-order hearsay, or any of those "What If" questions that involve befriending an old scientist while you're high school (not weird at all) to change the space time continuim. I'm just wondering what the points of views from both gamers and developers (no one needs a Venn diagram to know all you devs are "hardcore gamers" too, so exhale) are in terms of the Jaguar's design shortcomings. e.g. Bottlenecks, Ports, Shell, Controller Layout, Etc. And this isn't about beating up on our beloved 64-bit console, so be gentle.

  • Like 2
Link to comment
Share on other sites

Lack of good tools and support for devs.

 

Many bad decisions in hardware can be worked around and if the games are fun enough technical limitations can be ignored. The longevity of the SNES can attest to that.

 

Had they put out some heavy hitters ahead of the release of Saturn and PSX they might have sold enough units to keep going.

  • Like 2
Link to comment
Share on other sites

Probably going to re-ignite the great debate, but the gpu-in-main-memory issues not being fully root-caused/worked around and instead being deemed impossible, and lack of a production-quality C compiler for the GPU/DSP combined with an assembler that spit out code already containing workarounds for the jump issues, including the GPU-in-main ones. I think if those were addressed, a lot of the "It was too hard to program" issues wouldn't have existed. It still wouldn't have been an awesome texture mapped 3D machine, but you'd probably see fewer things like 2D games pointlessly chugging. There's obviously a bunch of other stuff, but I think those combined were both the highest impact and plausibly avoidable technical issues.

  • Like 5
Link to comment
Share on other sites

2 minutes ago, JagChris said:

Vasm will help with the GPU in main stuff. Same as SMAC. Mid to late beta stage.

Does RMAC include that stuff? It was a spin-off of SMAC right? Or was it forked before that?

 

Regardless, I know we can do these things now. Even just my personal list of "fun" Jaguar projects/tools I could do in my free time is endless. We can also spend hours and hours hand-coding GPU and DSP routines now without the pressure of shipping products in a quickly closing market window. I was saying more I think it's something that really could have had substantial impact on Jaguar software quality if it was available around mid-1993.

 

Loosely related: I recently found "gasm" as well (https://github.com/cubanismo/jaguar-sdk/commit/0e72b82687591d02ee1cb0031c8f30ce775bd1be) after noticing the CD BIOS sources rely on its alternate syntax. If Atari had time to maintain two different RISC assemblers, you'd think they could have gotten around to more useful tools improvements. If anyone has links to the "xdefsym" tool used in the CD BIOS Makefiles in concert with gasm and ltxconv, or has any idea what it does, I'd appreciate pointers.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Goochman said:

Memory (4MB) (...) 68010+ vs 68000

Originally planned, scrapped because it was too expensive at the time.

(Also, you'd need at least a 68020. The 68010 is only slightly faster than the 68000, and only in specific cases.)

 

2 hours ago, Goochman said:

Blitter Cache

Implemented in the Jaguar II. It's a pity Atari folded before it could be released.

 

1 hour ago, cubanismo said:

the gpu-in-main-memory issues not being fully root-caused/worked around and instead being deemed impossible

It's one of the Jaguar's biggest red herrings. Even if it worked correctly, the performance hit is massive.

For code that's executed more than once, copying it to the GPU/DSP local RAM and running it from there makes much more sense.

And for code that isn't, you may as well run it on the 68000.

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

2 hours ago, cubanismo said:

Does RMAC include that stuff? It was a spin-off of SMAC right? Or was it forked before that?

It was forked after and the guts of GPU in main stuff yanked according to what I remember them saying. 

 

You can of course put them back in SMAC or RMAC I guess.

 

Yeah I know you were referring to back in the day. I just didn't know how many people may realize it's an option now.

 

And Atari could have had all that back in the day as well. What a shame. 

  • Like 1
Link to comment
Share on other sites

2 hours ago, cubanismo said:

Loosely related: I recently found "gasm" as well (https://github.com/cubanismo/jaguar-sdk/commit/0e72b82687591d02ee1cb0031c8f30ce775bd1be) after noticing the CD BIOS sources rely on its alternate syntax. If Atari had time to maintain two different RISC assemblers, you'd think they could have gotten around to more useful tools improvements. If anyone has links to the "xdefsym" tool used in the CD BIOS Makefiles in concert with gasm and ltxconv, or has any idea what it does, I'd appreciate pointers.

 

If you don't mind I'll share it on FB. Some of the old devs stick their heads up around there.

Link to comment
Share on other sites

5 hours ago, Zerosquare said:

For code that's executed more than once, copying it to the GPU/DSP local RAM and running it from there makes much more sense.

And for code that isn't, you may as well run it on the 68000.

I haven't waded into this much because I'd never seen any actual data. Just the competing claims over and over again. However, if you look at @42bs's fire demo comparison, GPU in main is at least an order of magnitude gain over the 68k. I should wire up some actual FPS counters, but it looks more like ~3x subjectively. So I think we can safely conclude that while there's a substantial perf hit Vs. local memory, it's also a substantial speed gain over 68k.

 

That brings us to the claim that if it's code that matters, you might as well move it to the GPU local memory. Well, yes, of course you should. But if the farthest you got was taking your engine written in C, building it for the 68k, and writing a few blitter routines and an object list handler, again in C, and then needed to ship, you'd still be a lot better off if you could have flipped a switch and built that for the GPU instead. No need to organize your code into tiny segments and blit it in/out of local RAM.

 

I'm not trying to make the old argument that the only way to get good perf is shut off the 68k forever and run everything on the GPU+DSP because the 68k somehow infects your program and makes it run slow just by turning on for a vblank interrupt or by rendering menus while paused. I'm talking about harnessing some low-hanging fruit that could have raised the minimum bar of game quality, and if done properly, allowed developers to ignore some of the RISC bugs by letting the compiler deal with them.

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

I feel that the discussion diverges from the OPs intent. I think that the OP asks to point design decisions that turned out to be wrong. So bugs in RISCs and lack of good toolset aren't design decisions. Using 68000 instead of e.g. 68030 is such decision but I don't think it can be called an obvious design flaw. The system certainly would benefit from better processor (especially from caches, pipelining and 32-bit bus). We know that it was considered, and it ended being against the design philosophy where the CPU is only a supervisor to RISC processors and the increase of final cost of the box had been considered unacceptable. We don't know if the machine would be competitive with better processor.

I think that the topic is about things that could have been designed differently without increasing cost too unacceptable levels, and was in reach of Atari engineers. Certainly doubling the amount of GPU RAM should have been easy and maybe not too costly, since DSP already had 8 kB. I'm not sure now about the blitter cache - maybe it was difficult. On the other hand the amount of DRAM had rather big impact on the price so doubling it to 4 MB could have been off the table too.

 

 

 

 

Edited by laoo
  • Like 2
Link to comment
Share on other sites

There's an interview where Mathieson says the on-chip memory was actually considered very large from a design POV, and the size of Tom was already reaching the limits of their manufacturer. I think it's from Atari Explorer. Remember that while Jerry had 8k of local memory, Tom had the memory controller, the object processor, and the blitter, as well as a 64-bit internal bus connecting many of these. I'm guessing that's why it had less room for local memory. I'm not sure whether people mean an actual cache for the blitter, or just double-buffering or adding a FIFO in front of the registers, but similar issues apply if it's an actual cache. You have to put the transistors somewhere. Bigger chips cost more, yield lower, and there are real upper limits to the size for a given manufacturing process.

 

If you want to limit discussion to hardware design decisions, sorry for diverging, but what they invested their resources in was very much a decision. E.g, Leonard could have worked on compilers instead of the CD add-on BIOS in theory. As has been mentioned ad-nauseam, they could have spun the RISC chips one more time each too, but that's a massive expense and delay. I'm not clear shipping them as they are was a mistake, even given my assertions about GPU-in-main above.

  • Like 2
Link to comment
Share on other sites

On 4/26/2022 at 3:47 PM, laoo said:

John Carmack had some theories about it.

He's talking big, but maybe just some minimal cache for blitter could be.. maybe not a game-changer but at least huge improvement.

 

 

The blitter has a read cache of 16 bytes and a write cache of 8 bytes. I just does not use it on PixelMode because the hardware devs felt that they could not debug it. So the blitter resets everything after phrase (in that mode) or after a pixel. I think even in phrase mode it throws away the second phrase for misaligned reads. Even the object processor can just flip those two registers. The Blitter is eager to read the target data. This is only useful for z-buffer. It would be great if it would switch to a pipeline if you don't read the target: address generator1 for the source. Then the shader. Then address generator2 for the target. Collect the pixels in the target register with WriteEnable flag for the bytes. Then when the targetRegister is full, use Address generator2 to flush it to RAM. In case of drawing horizontally, this phrase is written on one go. In case of drawing vertical walls in Doom, you may instruct the OP to organize your VRAM so that you can write 4px without page miss. So you only need 4+2+2+2 cycles.

Notice how one address generator usese fractions and integers. In a pipeline the fraction is increased in one cycle, the carry goes to the integer part in the next cycle ( like 6502 ). This is a pipeline. Addresses can be generated 1 per cycle, but you then read the phrase for this pixel and need to pass it through the shader. If the next pixel is in a different phrase, you need to read anyway. Of course the walls in Doom and Wolf3d could be layed out like in the PC version in column fashion. But what do you do on the floor? Also you need another register to store the current phrase address to compare it with the new pixel address. Compare may take a cycle .. longer pipeline.

It would be cool if Gourad shading could be added to the read texture and the same circuit is then used to generate z-values on write flush. The whole z-compare needs to be part of the write flush and not part of the shader.

  • Confused 2
Link to comment
Share on other sites

1 hour ago, ArneCRosenfeldt said:

The blitter has a read cache of 16 bytes and a write cache of 8 bytes. I just does not use it on PixelMode because the hardware devs felt that they could not debug it. So the blitter resets everything after phrase (in that mode) or after a pixel. I think even in phrase mode it throws away the second phrase for misaligned reads. Even the object processor can just flip those two registers. The Blitter is eager to read the target data. This is only useful for z-buffer. It would be great if it would switch to a pipeline if you don't read the target: address generator1 for the source. Then the shader. Then address generator2 for the target. Collect the pixels in the target register with WriteEnable flag for the bytes. Then when the targetRegister is full, use Address generator2 to flush it to RAM. In case of drawing horizontally, this phrase is written on one go. In case of drawing vertical walls in Doom, you may instruct the OP to organize your VRAM so that you can write 4px without page miss. So you only need 4+2+2+2 cycles.

Notice how one address generator usese fractions and integers. In a pipeline the fraction is increased in one cycle, the carry goes to the integer part in the next cycle ( like 6502 ). This is a pipeline. Addresses can be generated 1 per cycle, but you then read the phrase for this pixel and need to pass it through the shader. If the next pixel is in a different phrase, you need to read anyway. Of course the walls in Doom and Wolf3d could be layed out like in the PC version in column fashion. But what do you do on the floor? Also you need another register to store the current phrase address to compare it with the new pixel address. Compare may take a cycle .. longer pipeline.

It would be cool if Gourad shading could be added to the read texture and the same circuit is then used to generate z-values on write flush. The whole z-compare needs to be part of the write flush and not part of the shader.

The blitter has a read cache of 16 bytes and a write cache of 8 bytes. I just does not use it on PixelMode because the hardware devs felt that they could not debug it. So the blitter resets everything after phrase (in that mode) or after a pixel. I think even in phrase mode it throws away the second phrase for misaligned reads. Even the object processor can just flip its two analogours registers. One address generator in the blitter has variable step width. It would need something like:  phraseAddress:pxWithinphrase:fraction(x,x)  . Every carry flag into phraseAddress triggers a memory access. The other address generator can go in 8 directions. There is no fraction. Still it needs to trigger on phraseAddressCarry. Also the blitter should release the bus inbetween for the OP.

Before the target address changes, for transparency the old target data would need to be loaded. For z-comparison the old z value needs to be loaded. Bus is not released while calculating these to keep the memory page. But if we z-sort stuff and only use full transparent or none, speed should go up immensly. No reads necessary. The Jag cannot even do proper alpha. Who wants to render behind color keyed content?

 

With backups for the address generator registers, they could go ahead and load multiple phrases in one pass and then shade in a second pass. This would be the only way we could use those two source registers.

  • Confused 2
Link to comment
Share on other sites

I think the controller only having three face buttons instead of six is the biggest design problem. The Super NES had established six action buttons three years before the Jaguar's release and both the Genesis and PC Engine came out with six button controllers for fighting games. Why Atari thought a three face button controller would cut it is beyond me. Same thing for 3DO and a five action button controller.

 

I know the Jaguar controller was already designed for the Falcon or whatever, so they were simply using a pre-existing design to save money. It was still a dumb idea.

 

And this is coming from somebody who loves the Jaguar controller and has no problem with three face buttons 99% of the time. I still recognize it as a huge flaw.

Edited by jeremiahjt
Grammar
  • Like 3
Link to comment
Share on other sites

3 hours ago, jeremiahjt said:

The Super NES had established six action buttons three years before the Jaguar's release and both the Genesis and PC Engine came out with six button controllers for fighting games.

Actually original controller for PC-Engine has 2 buttons. Good luck playing Street Fighter with that (you change move sets using "select"). There were "pro" controllers with multiple buttons, but it's the same story as with pro controller for the Jag.

  • Like 1
Link to comment
Share on other sites

On 4/27/2022 at 4:29 PM, cubanismo said:

on-chip memory was actually considered very large from a design POV, and the size of Tom was already reaching the limits of their manufacturer

Right, RAM is very very costly silicon wise. IIRC a SRAM cell are 6 transistors. Look at die shots of for example a Cortex-M3 SoC. The actual CPU is only 1/10th or less of the whole die.

  • Like 1
Link to comment
Share on other sites

9 hours ago, laoo said:

Actually original controller for PC-Engine has 2 buttons. Good luck playing Street Fighter with that (you change move sets using "select"). There were "pro" controllers with multiple buttons, but it's the same story as with pro controller for the Jag.

Yes, but the PC Engine six button controller had been released before the Jaguar was released. 

Link to comment
Share on other sites

Rebecca Heineman has talked about the difficulty of doing work on the Jaguar in multiple interviews, here's a quote from one she did in 2015:

 

Quote

Rebecca: And then later on a Atari shot themselves in the foot again because they released the Jaguar, the video game console. But the fact that they required you to use a Atari ST Falcon to do all of your development on. They refused to convert their development tools to run on a PC or any other machine like a MAC or PC mostly people were asking for PC and developers are saying why do you want me to develop your on your console using the Atari ST using this really crappy operating system that's buggy as all hell that you keep pushing in the keyboards and peripherals like hard drives are very hard to come by. So it really turned off a lot of potential developers. I know that the companies I was working with really did not like using that Atari ST as a development system and so I had no idea why Atari itself made these decisions but they really were I don't know maybe they were hell bent on destroying their own company.

 

  • Like 4
Link to comment
Share on other sites

6 minutes ago, harmonyFM said:

I know that the companies I was working with really did not like using that Atari ST as a development system and so I had no idea why Atari itself made these decisions but they really were I don't know maybe they were hell bent on destroying their own company.

Same reason why Apple to this day forces you to use a Mac to do iPhone development-  to sell more hardware!   But Atari wasn't big enough to get away with it.

  • Like 2
Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

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