I was a Jag developer. The biggest problem is that the fastest resources are extremely hamstrung so you either write something slow on the 68000 and get the job done in time, or carefully craft small optimized GPU assembly routines like a demoscene coder, swap them in and out as needed, and take years to get it running properly. I remember we wrote all kinds of test benchmarks because it was impossible to know what the savings would really be without doing it both ways.
Sounds like a sorrowful excuse. You failed and gave the market to Sony a consumer appliance cheaper and weaker than any home console compared to its generations next to The ps2 which was criminally weaker than the dream cast GameCube and xbox
Like ALL video game companies, This one is Atari's "Blast Processing". Adding bits does not determine a systems bitness. Atari knows this, says so in the dev docs in a round about way and tells you it has very powerful 64 bit parts. The GFX hardware is all 64 bits. HOWEVER...the 64 bit bus gets cut down to one quarter that at 16 bit and one half the system speed at 13 mhz while the 68000 is running( here's some math for you.....that means you are now running at half the system speed and accessing data at one quarter the size( put that in your GPU and smoke it.)) So it does not matter if the most powerful chip in the machine was 1 billion bits: The 68k will reduce it down to it's lowly level. Moral of the story: Keep the 68000 OFF THE BUS AT ALL COST! Atari's 64 bitness is as accurate as the TurboGfx 16's 16 bitness. Neither is an unreasonable claim. No claim of Turing completeness at 64 bits was made... as a system it very well is 64 bits..... if you take the time to code it as such. Math has nothing to do with bitness in this sense. Atari's slogan was a self betrayal. But it's not the first time Atari shot itself in the foot.
It seems like the Jaguar was difficult to develop for for some of the same reasons as the Saturn. Tho Sega had more resources to develop its own games and create better tools
This nop-after-jump to clear pipeline isn't actually unique. Hitachi SuperH used on... well everything SEGA 32-bit, has 16-bit instructions but 32-bit memory bus; so usually it has the next instruction already preloaded, and they decided, let's make it 'always' instead of 'usually', and let's just start executing it anyway, regardless of any jump that happens; so canonically you nop after a jump, or alternatively, you can just shove an extra instruction from before the jump into there to be executed while the jump is happening. The time would be wasted otherwise anyway! The CPU wasn't designed with assembly programming in mind, but explicitly for C compilers. But buffering a div with nops is not what one may call good design... and it's usually a variable length instruction, so it is a waste of time.
it was a common way to pad instructions on some RISC architectures. It probably saved on logic costs. Always remember kids.... if it works can it really be stupid(especially if it helps the bottom line?)
I absolutely have no idea what was presented here but sat on my couch, watching the whole video as if I knew what was being explained. 🤣🤣🤣 You a smart dude. Great video!!
Jaguar is one of my top 5 systems of all time. It's an interesting machine that has some great original games, some amazing ports and a vibrant homebrew scene. Thanks for taking the time to showcase this underappreciated segment of console gaming history
Of course Paul! It's a great honor to cover a system like this. The architecture is a work of art. And with a few tweaks, and maybe some more engineers working on this design, originally, it could have been pretty competitive. It's cool to see it where it's at now though.
@@willman85 The controller is fantastic even if it's not the most attractive. It's very comfy and those keys do help big time, games like DOOM and AVP and others.
I just finished watching your N64, PS3, and now this episode. Great series! After you do the Saturn which is another great choice, I would love a video on the 32X and developing with that while still having the Bottleneck of the Genesis and if you jad the Sega Cd as well, what could be possible with all 3. That woukd be pretty fascinating.
Sounds to me like the hardware and software development tools needed more time in the oven; as they were a bit under-baked. Probably Atari trying to rush the system out and save the company. I actually was one of the first people to own a Jag in ‘93… I had hopes Atari would reclaim their spot on top of the video game world… at that age, I totally bought into the 64-bit marketing stuff. Lol… hindsight!
I think it's the wrong approach altogether. Sure you can design an elegant processor; but can you spin up the whole ecosystem around it? Especially if you're a small engineering firm? Can you make sure it doesn't have critical bugs? Sure it would have all been shaken out eventually, given enough time and resources; but if you have little to work with, the last thing you do is build this sort of failure mode into your design proposal. Imagine what if they did a SENSIBLE thing. Like a couple commodity RISC cores, SuperH or whatever, or DSPs, and a self-designed jungle chip in the middle to do the line blits, scratch RAM, bus management, DAC and IO operations, the usual. Then they could focus on the core competence of delivering a chip, it would be structurally simpler so it would likely be free of critical errata, and there would be debug boards available for the commodity chips used, which you just solder in place of the chip, instant debugging capability, plus more debugging capabilities foreseen in the CPU core proper. Besides, the 68k crutch can be ditched then, potentially making the whole thing cheaper too. And not necessarily weaker or slower than with these custom DSPs. Sure, less ambitious, but ambition means work, and you want to do the least possible amount of work to deliver a given or best possible result. Less work means more opportunity to do the work at high quality, on time and under budget.
@@maroon9273 The 68k was a known entity, so not a bad choice per se, its assembler was widely known and it had good tools, Jags problem were the custom chips, while powerful, Atari lacked the time and money to provide proper dev tools for them. The company behind the custom chips survived another console lifecycle, the successors to the tom and jerry chips made it into the Nuon console almost no one knows about, but with the PSX basically the methodology was shifting and those chips did not cut it anymore! Atari had good foresight but it took too long and they ran out of money!
@@maroon9273These would’ve been expensive compared to a 68K. The problem was that Atari opted for a the regular 68000 when the 68020 would’ve removed a giant bottleneck on the system.
Time is correct but Atari did not think they had the time so they made some ugly and costly choices...that BTW way could have been avoided and still would have allowed for a very powerful system. Dump the 68k, add another Jaguar RISC with its on private memory and you'd be keeping up with the jones's. Oh and actual decent tools to code the system with.
In terms of the 68000 being used as the Manager chip.. The 68020 and 68030 chips were both considered for that role at one point, but dropped due to how much it would push up the manufacturering costs.
@@MaxAbramson3 don't they even have instruction cache? Together with the large register file on a 68k this would allow a lot of code to run without congesting the system bus or eating into JRISC cache.
@@ArneChristianRosenfeldt The 68EC030 has a 256 byte ICache and a 256 bytes DCache. While those only manage a 50% hit rate on benchmarks, they can manage about 80% on gaming code thats written to take advantage of them.
@@MaxAbramson3 From an overall perspective, I would invest in the gaming code to run on JRISC and the rest to run on 68k. Still, 50% hit rate mean that the 68k can run 2 instructions before it has to wait for the bus and with 32bit it is twice as fast off the bus again. Still, I would rearrange the main board more like this: Tom in the center of the memory (like PS4). Small cartridge slot and associated area. Point2Point DDR connection to Jerry. And uh, a 6502 core inside Jerry as the friendly face. PCB would look as clean as the N64. I really don't see a path forward with a discrete 68k. 50% hit rate really isn't great, considering that Doom manages the JRISC cache so much better. I would rather invest into a package to remove the color conversation off Tom .. uh, but it is too small to justify a whole custom chip. Not like in the VGA days with the palette or the character ROM in MDA.
Excellent video. Another annoying issue is the fact that the act of the GPU processing its object list is destructive to the list, so it must be recreated every time you use it :(
Yes... another cost saving flaw.....you can however reuse most of the list but will have to replenish certain fields of the OPL instructions. They really needed an instruction cache on this silicon and on the blitter as well. It would have made a monster difference.
I just bought my third jaguar. Only reason was alien vs predator. It cost $400 this time for a new one, the last one I bought before that was in the mid-90s at Walmart for $50.
Did you know they were thinking about using the Lynx for AvP radar/sonar? How awesome would that have been...They had the machine but didn't know how to use it properly.
@@randyfemrite7525 Because the UART on the Jaguar was greatly flawed and locked up all the time. Scatologic(formerly 4-play) folks were the only dev team to figure out how tomake the networking work, not only properly but in such a way that the more Jaguar you hooked up together in BattleSphere, the 'smarter' all machine got. If one machine in the network was not being overworked, it would take up slacke from another machine that could use the help. The only other team I know who did such was Airs Cars folks, who I think were licensed the code from Scatologic(formerly 4-Play). Had Atari known how to deal with their own bugs as did these folks, you might have seen that Lynx hook up which yes could have been really cool for a second player to work as a team with you.
Cool video. The weird hybrid of two 64-bit processors, two 32-bit processors and one 16-bit processor still to this day makes it unclear if the system as a whole is 64-bit as Atari claimed it was.
It was basically just marketing talk, because it had 64-bit architecture, it coukd be marketed as a 64-bit console, but it wasn't a 'true' 64-bit system as we would know it.
@@thefurthestmanfromhome1148 It was true 64 bits just like the 8 bit 16 bit Turbo gfx..... both referring to the gfx processors. Not the main processors....but... technically you are correct since there is no Turing complete 64 bit main processor.... but with that said, there is NO main processor in the Jaguar. At best the 68k is a boot processor. You can turn it off and run the system completely with Tom & Jerry. We do this in several demos... we released one to the public to promote the use of main RAM RISC coding, only to be laughed at by people who can code past an 16 bit cpu if their lives depended on it. Look up Surrounded 3d.
@@LakeHowellDigitalVideo Well even today PC's have buses bigger than the main processors...but they are all very high speed serial one lane PCIe and all so how do you rate the mother board? It's even moreso a technical conundrum ....but hey.......imagine the Jaguar today with PCIe tech?......wowzers. Of course it would be quite a different beast at that point.
That took some effort to make, thank you for that. I didn't closely follow every bit of information you you presented, but two things stood out: UART bug seems like a problem in comms between JAG and another external device (like modem or another Jaguar in some kind of network), not inter-chip communications. MC68K 32-bit issue from my understanding means that you just cannot trust some long word operations in two memory areas. Rest of the memory is fine, other '.l' assembly instructions seem fine, and non-long-word operations are fine (so you can use two move.w or four move.b instead of one move.l). Annoying, but not a deal-breaker. Again, thanks for the interesting vid.
The 68k only has a 16 bit data bus externally anyway so it's not like you will gain much in the way of performance. Best turn the damn thing off and let Tom and Jerry deal with the real work.
Cool. I''ve got to get myself one of these Atari Jagwires to go with my Atari Jaguar. Good video. I knew these were awkward - just not how awkward. I had friends worked on some cool stuff on the 8 bit Ataris, there were some good tricks with those to improve things but it seems you needed something like those tricks just to make it work like it's supposed to. I had a friend import one of the very first ones (so early we had to solder the RGB cables onto the edge connector, we couldn't get a cable here) from the US to Scotland, and although it had a few great games, overall it was a huge disappointment.
Sooooo, programming a game on an Atari Jaguar was equivalent to trying to eat a hot dog stuck in the spokes of a bicycle wheel whilst moving at 60 mph during an earthquake. 🤔
So now that I understand a little bit of assembly I went back and read the thread where they tested out the GCC for GPU output. It was very interesting. You were right. It looks like it's a GPU compiler output problem and not a hardware bug. I'm not sure what went down with Brainstorm if Atari didn't pay them and they just told Atari that there was a bug they couldn't figure out. Because it beggars belief that they were skilled enough to put in all those actual hardware bug work aroundarounds in there but couldn't get the loop counter right. Change one register and one condition code from GT to LT and the output is fixed. No wonder Corley couldn't remember what the problem was because it wasn't memorable Probably took him a half hour to whip up a script to fix it. The buffoonery of the Atari management also beggars belief even more looking at it now because it's apparent they didn't even check. All that money they spent contracting Brainstorm to do this wasted for want of a competent manager. So now that makes sense when I asked Carmack some years ago if he ever ran into this comparison hardware bug when he retargetted his compiler and he said no and that he'd never even heard of it. Because there never was one.
I would like to see a video on what you think about the canceled Panasonic M2 video game console. I really enjoyed this video, and the one about the Sega Saturn.👍
Amazing and in-depth! Great job. N64 had bottlenecks, ps3 was arcane, but this one is straight up bugged haha. No wonder it was left in the dust. ps. weird pronunciation, Jaguayer
I remember hearing at the time that if not for these hardware bugs the Jaguar would've been much more powerful. Someone (Minter?) said that one of the bugs caused texture mapping to take 11x as long as a plain ploygon, for example. Even as it was it was a worthy competitor for the 3DO, and not that much worse than the Saturn.
You might be thinking of Martin Brownlaw, coder of Missile Command 3D, not Jeff Minter. John Carmack also commented on how slow texture mapping was on Jaguar
Texturing was handled at a whopping one pixel at a time as where the CRY mode shading was full phrase capable( ei 64 bits at a time or 4 cry color 16 bit pixels)....... once again.... another costly cost saving maneuver. I'm almost wondering if the GPU in software might compete against the crippled blitter texturing....I can write 32 bits at a time.... thats2 cry pixels,4 8bit pixels. Better than one pixel at a time.
Credit has to go to developers who did use the hardware wisely and discover work arounds to get the best from it. Eclipse for discovering the small area of memory that could be used as a texture source and it was the same speed as flat and Gouraud shading (twice as fast as normal textures). ATD for using the GPU to get a better framerate and draw distance for Battlemorph over Cybermorph and ignoring Leonard Tramiel'S demands to fully texture-map the game. Rebellion for Skyhammer. Ubisoft for Rayman and showcasing the machines 2D abilities.
3DSSS( us) along with AtariOwl came up with the main RAM GPU work around.... it makes a big difference in performance. Perhaps one day I'll consider coding a game for the Jaguar again.
This is probably the deepest dive video on the Jaguar anywhere on the Internet. I've always been curious about that beast, so thanks for that. That said, I feel like you are putting a lot of weight on pipeline stall and related issues. Anybody familiar with MIPS would have been pretty well versed in needing to throw in no-ops and arrange instructions to be pipeline friendly. And pretty much every gamedev in that area had to be somewhat familiar with MIPS, given it was used in the PS1 and N64. The odd mish mash of ISA's and bus sharing behavior was probably a much bigger issue. I feel like if you do a followup video, you should try to actually write some simple software for it. By the time you get all the various dev tools set up to do a build, you'll be weeping for something like an N64.
Thanks for the in depth comment! I appreciate it! So the 3DO and Jag were some of the first consoles to use RISC architectures. The high instruction throughput and scheduling issues were fairly new in the software development world at the time. IIRC, the Jaguar was the first (or one of the first) to use a MIPS processor (In a later Rev of hardware, no MIPS processors on the board originally.) specifically up until this point for a game console. So that was definitely a challenge. But yes, I do agree with you. The largest challenge was using the hardware to the fullest extent, as is with most of these consoles. And yes, as I mentioned, no real time debugger. But the PS1 and N64 were much different, more refined, mature, and more efficient. They also had much more resources for R&D and Nintendo had the best 3D hardware company in the world on their side, so these environments were much more mature and developer friendly. The Jaguar was not and that's definitely something to consider. Excellent points!
ANYTHING even a cheap ARM would have been better than the 68k. You don't think the PS1 has flaws? Just look at those horribly sloppy textures with the Charlie Brown warp effect. The difference is, the PS1 was a fantastic design...all parts having their own private memory and hardware textruring....which came at a cost.... the Charlie Brown syndrome). The Jag... a great futuristic chipset used in an outdated console design.
The Jaguar: A console that was pushed out far too quickly. -The excellent hardware wasn't properly integrated and implemented - couple of tweaks could have made it more robust and powerful. -The support library's were somewhere between useless and non-existent - this made it a pig to develop for on stupidly short timelines. -Atari wasn't in a position to provide sufficient support or marketing - there was too much to do in too little time with insufficient money. It may have bombed anyway, but at least it could have gone down fighting.
Cojag arcade board is a what if scenario had atari used a m68020 or the great MIPS R3000 cpu. With the r3000 it would've rivaled the ps1 and Saturn performance with tweaks on the hardware as well. Plus, solving to remove the bugs from the coprocessors.
TOM & Jerry were fine, in spite of the bugs.... the 68000 was a really bad move on Atari's part. You just took a 64 bit chipset and dropped on to a 16 bit /half speed system bus. It might as well be an Atari ST, amiga or Genny at that point. it should have been another RISC or a 68x20 or higher.
Just stumbled on this, but holy damn is this ever in my wheelhouse of enjoyment! Good stuff man, very good stuff! One of the more easier subs I've ever had the delight of making!
So in summary: Jaguar: Hardware bugs requiring wait states and screwing up regular commands Saturn: Too many processor subsystems with no easy way to access them all at once Both: Terrible first party development tools and documentation.
That was a great video, I have a Jag and love to hear about the hardware and history of it. Right now I ordered an SCable and found an old flat screen TV. I am pumped about that and the fact that I can buy new games that run better, have save options and improve frames. Also, they have a lot of options of either buying a new controller or getting one custom made. All good things!
To be fair, many systems of the early 90's were grappling with the concept of superscalar pipelining, and the Jaguar just had more problems than average. It was fashionable for companies to attempt an in-house RISC CPU back then, rather than license a well-tested core. In terms of system architecture, the Jaguar was actually quite nice, and the N64 and Saturn were both far more difficult to program. Also, *please* turn down the music, or at least use something less melodramatic.
Unlike those systems, the Jaguar's main chipsets were held back by bugs. If Atari had left it's development tool set and chipset a little longer in the oven like let's say, a delay for it's launch in 1994, that would've been preferred over an early launch with half baked tool and hardware designs.
@@crazedlunatic43 The bugs in the chips could have been forgivable if they did not choke the rest of the system with the 68000...a chip I love dearly... just not in the Jaguar.... but yeah.... a few of the bugs fixed and boom.... In fact.... most were not bugs.... but oversights....cost cutting ones at that. A cache on the blitter would have been a major speed up...ei...now the blitter can draw an entire polygon with no intervention from an outside processor. The OPL needed some extra registers to eliminate the destructive fields in the OPL list...this too would have saved a lot of time. I would have gladly waited but Sony was ready to release by then and remember...they had 50 titles ready.... Jaguar even a year later barely had a dozen or so.... most hardly next gen. Tom & Jerry ... fantastic tech wasted on a cost cut to death design. I think Atari should have released the CoJag. Now you have an authentic arcade machine in a console. Nowyou also have hard drive and other media expansion out of the box as well. Long before Sony or Xbox did so.
@@GORF_EMPIRE Are you one of those guys from Atari Age? I feel like I’ve heard the name “Gorf” somewhere around Atari Age and explaining how the Jaguar worked.
It be really interesting if a programmable logic array was used to model the jaguars chip(s) but with most of these bugs worked out and to see how fast this chipset could have been at the released Mhz rating. Essentially making one more revision to the silicon which is evident being needed. Also was this rush to market driven by marketing or dollars running out for the company?
Dumb non-programmer question: Instead of workarounds, what would it take to actually FIX these bugs? A redesign and manufacture of chips? I don't know anything about programming but it just sounds like no one will ever be able to use the hardware's full potential.
Not a dumb question at all! Most of these bugs would require new hardware spins, which is definitely not ideal from a cost standpoint. This also means in some cases that software developed on old chips is not compatible with the new hardware either.
The Jaguar GPU had 4kb of internal nonwait RAM , due to a bug , you had to write everything in 4kb chunks. They could not change it to 64kb of normal ram as the design was complete. The system had countless design faults.
@@FantasyVisuals The RISC chips in the Jaguar were only capable of 64k address spaces as it is. I think 16 k would have been killer but unfortunately that would have cost a lot. You are not lying about the design faults, both in the chipset and the console.
Your videos are absolutely incredible and I love how digestible they are! They get me interested further in CS through things I already love; good stuff!
The Jag Gwar was hard to develop for because most developers used IBM PC based SDK. If you really wanted to tap its true potential, you needed an Atari TT030 computer. It's not pronounced 'Jag Gwire.'
Did the JAG-U-ARE have a SDK for the Atari TT030? If not, this would appear to make the task of development more difficult. The SDK/Environment cannot mask the system architecture bottlenecks and hardware bugs, which, overwhelmingly, were the main issues with it.
You know words are pronounced differently across cultures right? What he said was absolutely correct. It is pronounced 'Jag Gwire' here in the states. Just as we wouldn't be caught dead saying something as ridiculous as "Zedbra." Thank you and have a pleasant week.
@@polytrashed I've been to every state in the Union and not one time have I heard anyone pronounce Jaguar like British people. If you want to hear the most common way a word is spoken look at Television or film as they tend to match the most popular or frequently used dialect...especially commercials advertising a product. One example of this is the Atari Jaguar commercials that ran from 1993-1996. I encourage you to look it up as it will show you the correct pronunciation here in the states. Before you tell me the UK this or that...remember, every country has its way of doing things. We might all predominantly speak "English" but it is not the same as "English" in the UK. Often times their words have different meanings than ours do and spelling can be radically different. Just look at the word color and colour. Both mean the same thing but are spelled completely different. This phenomenon is very prevalent in Spanish speaking countries as well. Spanish in Spain is very different than Spanish from Puerto Rico.
@@Sinn0100 What? I think there’s been a misunderstanding; everywhere I’ve been it’s been pronounced “jag-gwar” (similar to “bar”), while the stereotypical English version is the three-syllable variant “jag-yew-are”… but never before today have I heard it pronounced it as “jag-wire” lol
it could still do good graphics, its other hold back was the cartridge, i saw article talking with Rebellion software who did the game Alien vs Predator, which was a nice looking game and they said specifically, that they cut back on the texture quality considerably, due to having to cram it on a cartridge
And they had to practically beg the Tramiel's to increase the cartridge size over the original allocated size. A full orchestral musical score was intended for the title, but no room for it on the final cartridge.
I always thought the Jag suffered from hardware complexity issues, but it sounds like the system wasn't very complicated... But all the different components in the system had a tendency to trip over their own or each other's feet, and nothing in the system really ran in sync properly. This is quite different from the the problem the Saturn and PS3 had, where the architecture was incredibly complicated but ran very fast and smooth if you knew how to actually control it.
Sync happens via the system bus and is a major slow down. Rather all subunits should get input and output queues and leeway in their timing. Pipeline! I tried to read up on a simple bus and thought SPI or I2C. But those are more complicated! With a parallel bus no stop bits are needed. We recover no clock like RS232. Also there is a star topology for requests.
I think you have misunderstood the JUMP recommendations.. you certainly don't have to prefix a JUMP with NOPs, and you don't HAVE to postfix them with NOPs either, but you do need to be aware of them with the pipelining. As the instruction after the jump will be loaded into the pipeline before the jump is executed (hence the suggestion of using a NOP after), but there is nothing to stop you adding an instruction immediately after a JUMP as long as it is contained within the 16bits of an instruction (no MOVEI's), and a few other gotchas (Indexed offsets go boom :D ). I use instructions after a JUMP quite a lot in my code on the Jag and it works without issue. Obviously these are jumps in SRAM, I don't bother with any of the GPU in Main crazyness, life's too short.
Now remind me, is this the jump recommendations I reference around 13:50? Or is it somewhere else? Either way thank you for pointing that out and commenting! :)
@@ZygalStudios Don't know if you came across it or not, it is touched on in the Tech Manual (there are at least 3 versions of that, each with it's own extras and corrections, the one dated 1995 I think is the most complete), but the "Jaguar" part of the system is just Tom & Jerry with an additional generic general CPU. In the Arcade versions of the system, the 68K is replaced with either a 68030 or an R3K or R4K, as well as increased ROM size and DSP bus connection being full 32bit.
I do not know most of the jargon you were saying but it is still extremely interesting! Honestly I would love to watch more and see if I’m able to learn. I’m intrigued on Jaguar games that actually achieved the hardwares true potential.
I don't know if there are any that TRULY did reach full hardware potential. One thing thought that I find interesting is that if you look at the two games that were on every system at the time, NBA Jam TE and Doom, it's the Jaguar versions that are regarded as being the best, even better than PS1 and Saturn versions. So who knows what could've been with the Jaguar.
@@roxynano I think the one thing that could be telling is that there's still a fairly large group of homebrew developers that make new games that you can buy on Atariage, but those also don't showcase the full power, most of them not even coming close to what was already commercially available, so after all this time, homebrew coders can't figure out how to squeeze out the full power, it was unlikely anybody was.
I know this would be a super late reply, but there wasn't much in the way of "2nd (or 3rd) generation" software for the system, which successful consoles get, and beyond of teams producing 2/3/4+ games for the same system. John Carmack, who coded Wolf 3D and Doom for the Jaguar, did say that if he had done Doom again, there are several things that he would have done differently and more efficiently, so it's safe to assume that had they done Doom II, it would have been better than the Doom port was. That all said, the best examples of what the Jaguar could do were: Iron Soldier II, BattleSphere, Wolf 3D, Super Burnout, Doom, Missile Command 3D, Zero 5, Skyhammer, BattleMorph, NBA Jam, Tempest 2000, Alien Vs. Predator, Hover Strike CD, Tube SE, and Primal Rage. There was also some unreleased games that showed off some near-PSX potential, such as BlackICE/White Noise, Phear (which actually became Tetrisphere on the N64), Phaze Zero, Native, Conan, and the AtariOwl RPG game. :)
A delayed launch to ensure that the chipset's hardware bugs have been fixed, and Atari providing proper development tools over pushing the system for a '93 launch would've been preferred.
Atari didn't have the money. Any revisions to the hardware would have meant cooking up more silicon, which was millions upon millions of dollars per revision, at a time where Atari Games hadn't seen success since the Crash.
show me any bug which does not need more transistors ( and potentially more bugs ) to solve. Feature creep is the problem. All those special JRISC instructions for JPEG and mp3! Multilevel interrupts on all 3 processors! Two audio DACs ( why not stick to external from the start ? ). Complicated backwards compatibility to Atari controllers instead of simpler Japanese design. Vertical scaling should never have been done by the OP. Why can the blitter scan for values, but at an unusable slow pace? Why do we have OP and blitter? Really, the Jaguar needs one simple 64 bit memcopy unit with access to the bus and then one pixel pusher with private memory. Bringing a 16 or 32 bit framebuffer to the screen is just a matter of memcopy. Don't confuse it with sprite or palette or scaling or shadows, all of which are too slow for the memory bandwidth. The OP already has its own (private) linebuffer and palette. Just unify it with the blitter . Who ever needs this exploding pixel mode of the blitter? Why have to relearn everything when going from 2d to 3d? Why 32bit cartridge if the clock rate is too low and the bits too expensive for live data anyway? Who needs more than a pi/2 cos table in DSP ROM?
Not enough money and time was of the essence. Could things have been more wiser, absolutely but any delay would not have helped as it would have buried Atari.
@@GORF_EMPIRE If anything, I definitely agree with the 68k being a mistake on Atari’s part. I’m not too familiar with Tom and Jerry, but these two chips were the main highlight of the console and it’s a shame that they were burdened with an outdated 16 bit processor. And yeah, Atari was short on cash compared to its competitors. Honestly, Atari would’ve had a tougher time trying to compete with (Newcomer who had loads of money compared to Atari) Sony, Nintendo, or even Sega, as those had stronger brand recognition compared to Atari in general.
Another thing about development on the Jag, various direct ports used the 68000 almost exclusively as the main CPU for programming, almost completely ignoring Tom and Jerry. This is something other Utubers have mentioned when deep diving into software quality and why some titles look 16 bit while others like Rayman and Tempest 2000 excelled.
With some good middlewear the Jaguar could have done some amazing 2D games like platformers and the like. It was never going to compete with the likes of the Saturn and Playstation though. I've always thought that they should have just released the Panther in 91 to compete with the Megadrive and SNES tried to build up a stable of third party developers and put the Jaguar on the back burner. People always say "oh but the Panther doesn't compare to the Jaguar" and no it didn't but it still exceeded the 2D arcade PCBs of the late 80's and early 90's and was easier to write software for than the Jaguar which was good enough. The mid to late 90s were a dark time for video games comparable to the "iron age" of comics. If you showed someone beautiful pixel art vs ugly blocky 3D of that time 9 out of 10 people would prefer the 3D.
What would the middleware do what the SDK does not? Tile based background? Box2d collision and physics? Did people need this middleware on 16-bit consoles? Better audio driver?
@@ArneChristianRosenfeldt From what I have read the Jaguar SDK was terrible and didn't make it any easier to develop for. an middelware would give you a software framework to start with with all the heavy ASM lifting done already.
@@atomicskull6405 the Framework did not even give a printf . I think that this is called C stdlib. People complain that the compiler did not check for overflow. I did not know that C can throw this exception. I don’t understand how to overflow 32bit. Much bigger problem is that factors need to be 16 bit. Probably, if OP would not be able to write to DRAM, development would have an easier start. Middleware to draw a background from tiles would be nice.
According to Atari uk, had Panther been released, there would only of been around a 9 month window, before Jaguar was ready. People who worked on the Panther, like Jeff Minter, Rob Nicholson from HMS etc, stated the actual sprite abilities weren't anything like the numbers Atari were pushing.
14:28 I wonder if this is a flaw of divide-scoreboard itself were maybe divide-read isn't considered a read by the scoreboard, thus the first divide isn't scoreboarded first (or at all), so second divide can occur falsely. This makes the previous bug, of divide needing a dummy wait, make sense, as divide isn't viewed as doing a read by scoreboard and so is ignored by scoreboard. If divide is too long between reading and execution, the scoreboard may see some weird, null, intentionally placed wait (to account for long divide time, divide may include a built in dummy wait statement) operation occuring. But a "dummy wait ending with divide result being stored" instruction doesn't contain a read, is seen as a dummy, thus the scoreboard treats this end of divide, and so the whole divide itself, differently and ignores it.
The divide hardware is pretty stable and only requires 18 cycles to produce a result but it is separate from the store/load issue which are scoreboard shortcomings.
Good Video, I always wondered about the bugs in the hardware that John Carmack talked about. Saying that, I think the bugs were NOT a show stopper for the hardware. Yes they are an issue and will slow things down for development, but if all the bugs are flagged and addressed, i do think the Jag had some clever ideas. I had one back in the day and DOOM , AVP, and Iron Soldier were some good games.
There's really nothing ahead of its time about the Jaguar, a lot of its games are just worst versions of either PC or console games of the time. Even the Super NES and Sega Genesis had better 3D capabilities than Jaguar. Companies need to know that games are made to be play, not to be look at. A lot of Jaguar intend was to just make games that are good to look at regardless how they play and this is why not everyone wanted to buy one.
@@VOAN Wrong. You truly are clueless. Nothing the SNES or Genny could do could possibly outclass the Jaguar.... at least not without serious help from 'enhancement' processors on the carts like the SNES and Sega had to do and even then did not have the ability for Jag's 3D OR 2D for that matter. Jaguar hardware wise was superior in many ways to anything at the time.... unfortunately it was grossly mishandled in its dev kit, it's marketing and developer relations, not to mentions public relations. Do a little research about the systems you are talking about before you make a fool of yourself next time. Though you are correct about a system needing games, you are perfectly clueless when it comes to that time period's hardware. The SNES could not even do a decent version of Doom even with the help of it's BEST enhancement chip. Might as well build a new console at that point. Jaguar DOOM alone outclasses the 10 FPS garbage DOOM on SNES. You SNES fans got ripped off. Forget 3D though, the Jaguar pissed all over SNES and GENNY 2D wise.... show me a game like Phase Zero on the other two.... oh wait... that's right.... neither could do it even with enhancement chips... enhancment chips for systems with no dick.
@@ZygalStudios AVP, Iron Solider 1 and 2, Battlesphere, Skyhammer, Rayman.. Zero 5.. Probably the best examples of Jaguar hardware being used wisely, maybe Battlemorph as well.
Could you go into how this affected the programming of Jaguar Doom? Carmack has been quoted as saying "Coding for the Jaguar is fun!" And nobody at id wanted to work on it. So basically only he and Sandy Petersen ended up working on Jaguar doom.
So what would you say caused the “Hardware Bugs” : The design or the manufacture? I ask this because I find most quick to jump on Atari on the lack of dev support for the complex and/or flawed system but NEVER, to my knowledge, place any responsibility on the manufacturer IBM.
Well Flare Technology was contracted to design it. So it would be on them for sure. But it was really just two guys and they designed this within just a couple years, so it makes sense. 2 guys designing this system with just a couple years of development explains why it was just functional and didn't have any pomp and frills. But if we're talking specifically, Atari contracted resources for the project, they are certainly responsible for the lack of resources.
@@ZygalStudios Thanks for the response. But I remember an interview with one of the Flare team in which, to paraphrase, someone asked him why did they chose assem. Instead of C for coding and what John Carmack say about scratchpad memory and no virtualization in the blitter? To which he replied that it was supposed to have those thing but there were defects in the hardware( he may have said silicon) and he blamed the Tramels for rushing the project. My point is Atari made mistakes their’s no doubt but if there was a defect in the manufacturing process then that is on IBM.
Jez San, Argonaut, who were working on the cancelled Jag CD version of Creature Shock: "A true 64 bit chip would have a 64 bit ALU and 64 bit registers. The Jaguar does not. Simply having two 32 bit chips does not constitute a 64 bit cpu. Having a 64 bit databus does technically allow you to call it a 64 bit system if you must, but 64 bit cpus? no way."
On the N64 the CPU was usually switched into 32 bit mode because no game needs 64 bits ( unless there are vector instructions). The so so graphic design on the GBA from Argonaut tells me that they are not competent.
If there are hardware bugs, why not do what Nintendo did. Put in some expansion chips into the cartridges themselves with other processors on them so that you didn't have to use the processors with the bugs in them on the actual console. Like you could put in a faster 68,000 processor into the cartridge and just use that.
That would massively increase the cost of producing those carts, and considering Atari was in some pretty dire financial circumstances at the time, I doubt they could've afforded it. Realistically if they were going to eat extra costs, they would have been better served by delaying the Jaguar's launch until they had fixed at least some of the more serious hardware bugs. Really a shame to see some otherwise brilliant architecture cut down by being rushed to market. Another possible solution is if they'd beefed up the Jaguar CD with some actual power, and maybe did a hardware revision that incorporated it. As far as I understand, all the Jaguar CD does is allow for bigger games due to the increased capacity of CDs (unlike the Sega CD, which actually has extra processing power). Seems like a wasted opportunity. But as a hypothetical solution to the problem of the system being on the market in a buggy state, your solution could have worked if cost wasn't such an issue.
@@GreyMatterShadesSam Tramiel didn't want devs using bigger cartridges, he was never going to sign off on putting DSP chips on carts to help with 3D etc. That's the reason the Jag CD is a dumb drive, costs had to be kept to bare minimum
@@thefurthestmanfromhome1148 I totally agree that Sam Tramiel wouldn't sign off on extra chips on carts. As for the Jag CD, I still think they could have done something. I'm not sure they could have (or should have) gone as far as the Sega CD, but it was clear developers were struggling to release visually impressive games on the Jaguar/JagCD. Even some relatively cheap additional ram or processing might have helped the system perform better without raising the cost too much. Of course the real solution to their problems was to fix their hardware issues before launching. Anything else would have just been a band-aid, but sometimes band-aids are helpful.
There were no bugs with this. If there were, the processor wouldn't have even gotten off the ground. It had hardware to detect hazards and then register scoreboarding logic to correct when a pipeline stall occurred. The purpose of explaining this was to show some of the design challenges in assembly that you would have as a programmer.
Why would you use the 68k to write to registers in production. Weird that even this is buggy because I feel that Atari used this access to debug the custom chips.
Great research dude! It really is too bad that Atari shipped this system with inherent bugs. It's my understanding that they rushed this thing out the door as a hail marry to save the company. Not realizing the bugs. There is a 2600 game that builds a unique map per each play. No one has access to the pre compiled data. No one knows how it was accomplished. Even the original programmer forgot the algorithm that he derived at. Might be a neat puzzle to look into even though it's not really hardware related.
Still does not explain nut case like an Object Processor which writes back into the display list. Non power of 2 for maps enforced, instead wrap around is not there. They use 16.16 math for Gouraud shading, but have an overflow problem because they could not be arsed to store the 8 bit chromance in a dedicated register. They allow detailed bit width for ROM (where we need to decompress anything slowly because ROM is expensive, but have not separate configuration for Jerry and CPU ?? The controller . Uh why not compatible with NES and this shift register?
@@pocketstationman6364 you can strike Tomb Raider from the list, been confirmed by multiple Core Design sources, Press took mock up screens and claimed game was headed to 3DO and Jaguar CD Jeremy Heath-Smith boss of Core Design, has gone on record saying the Jaguar would only ever reciece enhanced Sega Mega CD ports.
hi, very complex. I have a question though Atari had their woes for sure, but given more time, as this project was surely rushed. Could someone with the right 'knowhow' try to fix it 'Even just to show the Jaguars' potential. I mean. Do 'you' honestly think this could have wiped the floor with the PSOne; if done correctly??????????????? Only Using What 'Is In It, or maybe, just maybe addages 'from the time that atari might have had 'if not being up against the wall' so to speak. Sorry, I hope you get my meaning. I would love to see this console be 'what it was meant to be'!
Some games need 100 cycles for a single pixel. So obviously there is more wrong than fillrate (which is not thaaat bad). Any optimization will cost transistors. The blitter could speed up by a factor of two or three. We ditch one line buffer. There is already a high resolution 2d mode where you have to redraw all sprites which reach over the middle of the screen. Basically kill rayman and super burnout for more real 3d performance. Full motion video was all the hype. Instead vector3 and vector 2 instructions working on registers or at least fixed point 16.16 from SRAM would be nice. GL_REPEAT . Ditch non power of two size for pictures. Interleave x,y for texture buffers. Remove all the monochrome features from the blitter. Collision detection in pixel mode?? Better overlap between GPU and blitter, so like the left x of the current span can be set to the new line value while the last is still drawn. The others may have a cycle skew. The blitter should not use interrupts, but pace the STORE instructions so that new values come just in time. So no idle blitter. Blitter needs to do alignment. Everything needs to look like pixel mode for GPU.
@@alkenstein That is not how Atari, the commercials or any employees of Atari at the time or even now pronounce it either way. it's Jag (short u) R. Like the cat. Not the car.
Got this from Steve Heath's RISC, CISC, & DSP book. According to him the 6800 had approximately 6.8k transistors and the 68000 had approximately 68,000 transistors.
We say "Jag-you-are" in Australia too. I'm used to hearing the American "Jag-wuah" pronunciation as well, but I too have never heard anyone say "Jag-wire".
I found this series and immediately subscribed to this channel, i hugely appreciate the effort you put into yours videos. Will you make deep dive to ps2 architecture, emotion engine and graphics synthesizer are really interesting, and i would like know their potential a hurdles since i watch this coding secrets video: ua-cam.com/video/iEQLbbyToxw/v-deo.html
Got a sub from me. Went and watched some of your other videos and it's seems the music I'm this video overtakes your voice at time where in other videos it's fine. I'd like you to do next iver the 3do console and or the 32x addon
0:42 The PS3 didn't revolutionize jack shit... CELL and its SPU's was a COMPLETE and utter technological dead-end, with next to no relevance for how games would be coded post-PS3 and added very little to what could be achieved at the time for a MASSIVE increase in programming difficulty. The Xbox 360 with its 3x symmetrical cores w/ SMT was far, FAAAAAAR more representative of the future of CPU's in game consoles & development.
@@ZygalStudios No, it had some great games, but that statement you made is absolute garbage on a pure technological history front. Even for HPC, which is what the chip was actually designed for, GPGPU made the CELL look like the backwards dead-end it was before the time it even released in volume... (Nvidia Tesla came out basically dead-on w/ CELL). CELL was nothing more than a GARGANTUAN waste of money (SOOOOO much money... O_O) going down the same vector processing rabbit-hole Sony had been obsessed with since the PS2. Wanna know what does vector processing these days? Not bizarre, anti-programmer CPU + VPU hybrids. GPU's. Lots and lots of GPU's.
The MC6800 from 1974 was the precursor to the 68k. The 6800 was an 8-bit processor and wasn't used a ton after the release of the 68k. The 68k at this time was about 15 years old, but far from obsolete. I think versions of the 68k were sold well into the 2000's even after Motorola's semiconductor business formed two separate spinoff companies, ON and Freescale. Funny enough, at my embedded systems job, I've actually used a Coldfire Freescale microcontroller and guess what architecture that uses? :) a modified version of the good old 68k. So remnants of it are still around to this day. But in this application, it was strictly to be used as a manager and for controller I/O. It wasn't designed to be the main driver of game logic for this architecture.
I was a Jag developer. The biggest problem is that the fastest resources are extremely hamstrung so you either write something slow on the 68000 and get the job done in time, or carefully craft small optimized GPU assembly routines like a demoscene coder, swap them in and out as needed, and take years to get it running properly. I remember we wrote all kinds of test benchmarks because it was impossible to know what the savings would really be without doing it both ways.
Thanks for the information, but i have a question. What was the name of the video game that you developed for Atari Jaguar?
What game did you program???
Sounds like a sorrowful excuse. You failed and gave the market to Sony a consumer appliance cheaper and weaker than any home console compared to its generations next to The ps2 which was criminally weaker than the dream cast GameCube and xbox
What are some titles u worked on ?
@@enhancementtank5876
^ does anyone know what this idiot is talking about?
So Atari came with the phrase "do the math" ... how can I do the math with a flawed hardware? xD Great video.
🤣🤣 very carefully.
Thank you!
Oh! I see what ya did there!
Like ALL video game companies, This one is Atari's "Blast Processing". Adding bits does not determine a systems bitness. Atari knows this, says so in the dev docs in a round about way and tells you it has very powerful 64 bit parts. The GFX hardware is all 64 bits. HOWEVER...the 64 bit bus gets cut down to one quarter that at 16 bit and one half the system speed at 13 mhz while the 68000 is running( here's some math for you.....that means you are now running at half the system speed and accessing data at one quarter the size( put that in your GPU and smoke it.)) So it does not matter if the most powerful chip in the machine was 1 billion bits: The 68k will reduce it down to it's lowly level. Moral of the story: Keep the 68000 OFF THE BUS AT ALL COST! Atari's 64 bitness is as accurate as the TurboGfx 16's 16 bitness. Neither is an unreasonable claim. No claim of Turing completeness at 64 bits was made... as a system it very well is 64 bits..... if you take the time to code it as such. Math has nothing to do with bitness in this sense. Atari's slogan was a self betrayal. But it's not the first time Atari shot itself in the foot.
It seems like the Jaguar was difficult to develop for for some of the same reasons as the Saturn. Tho Sega had more resources to develop its own games and create better tools
“Just throw in some null ops” that is some old school problem solving....lol
🤣🤣
This nop-after-jump to clear pipeline isn't actually unique. Hitachi SuperH used on... well everything SEGA 32-bit, has 16-bit instructions but 32-bit memory bus; so usually it has the next instruction already preloaded, and they decided, let's make it 'always' instead of 'usually', and let's just start executing it anyway, regardless of any jump that happens; so canonically you nop after a jump, or alternatively, you can just shove an extra instruction from before the jump into there to be executed while the jump is happening. The time would be wasted otherwise anyway! The CPU wasn't designed with assembly programming in mind, but explicitly for C compilers.
But buffering a div with nops is not what one may call good design... and it's usually a variable length instruction, so it is a waste of time.
it was a common way to pad instructions on some RISC architectures. It probably saved on logic costs. Always remember kids.... if it works can it really be stupid(especially if it helps the bottom line?)
I absolutely have no idea what was presented here but sat on my couch, watching the whole video as if I knew what was being explained. 🤣🤣🤣 You a smart dude. Great video!!
Thanks for stopping by!
:)
Very simple..... The Atari Jaguar was an idea with great potential,executed horribly.
Jaguar is one of my top 5 systems of all time. It's an interesting machine that has some great original games, some amazing ports and a vibrant homebrew scene. Thanks for taking the time to showcase this underappreciated segment of console gaming history
Of course Paul! It's a great honor to cover a system like this. The architecture is a work of art. And with a few tweaks, and maybe some more engineers working on this design, originally, it could have been pretty competitive. It's cool to see it where it's at now though.
wich are your favorite games on it?
You like the controller?
@@willman85 The controller is fantastic even if it's not the most attractive. It's very comfy and those keys do help big time, games like DOOM and AVP and others.
I just finished watching your N64, PS3, and now this episode. Great series! After you do the Saturn which is another great choice, I would love a video on the 32X and developing with that while still having the Bottleneck of the Genesis and if you jad the Sega Cd as well, what could be possible with all 3. That woukd be pretty fascinating.
The 32x would be great! Good idea.
"So I decided to add it to the stack"
...I see what you did there.
I've always wanted to know how the Jaguar was put together and why it was so hard to develop for
Sounds to me like the hardware and software development tools needed more time in the oven; as they were a bit under-baked. Probably Atari trying to rush the system out and save the company. I actually was one of the first people to own a Jag in ‘93… I had hopes Atari would reclaim their spot on top of the video game world… at that age, I totally bought into the 64-bit marketing stuff. Lol… hindsight!
I think it's the wrong approach altogether. Sure you can design an elegant processor; but can you spin up the whole ecosystem around it? Especially if you're a small engineering firm? Can you make sure it doesn't have critical bugs? Sure it would have all been shaken out eventually, given enough time and resources; but if you have little to work with, the last thing you do is build this sort of failure mode into your design proposal.
Imagine what if they did a SENSIBLE thing. Like a couple commodity RISC cores, SuperH or whatever, or DSPs, and a self-designed jungle chip in the middle to do the line blits, scratch RAM, bus management, DAC and IO operations, the usual. Then they could focus on the core competence of delivering a chip, it would be structurally simpler so it would likely be free of critical errata, and there would be debug boards available for the commodity chips used, which you just solder in place of the chip, instant debugging capability, plus more debugging capabilities foreseen in the CPU core proper. Besides, the 68k crutch can be ditched then, potentially making the whole thing cheaper too. And not necessarily weaker or slower than with these custom DSPs.
Sure, less ambitious, but ambition means work, and you want to do the least possible amount of work to deliver a given or best possible result. Less work means more opportunity to do the work at high quality, on time and under budget.
@@SianaGearz even a armv3 or nec v series CPU would've been great risc CPU for the jaguar. M68k is the worst main cpu to use for a 32-bit console.
@@maroon9273 The 68k was a known entity, so not a bad choice per se, its assembler was widely known and it had good tools, Jags problem were the custom chips, while powerful, Atari lacked the time and money to provide proper dev tools for them. The company behind the custom chips survived another console lifecycle, the successors to the tom and jerry chips made it into the Nuon console almost no one knows about, but with the PSX basically the methodology was shifting and those chips did not cut it anymore!
Atari had good foresight but it took too long and they ran out of money!
@@maroon9273These would’ve been expensive compared to a 68K. The problem was that Atari opted for a the regular 68000 when the 68020 would’ve removed a giant bottleneck on the system.
Time is correct but Atari did not think they had the time so they made some ugly and costly choices...that BTW way could have been avoided and still would have allowed for a very powerful system. Dump the 68k, add another Jaguar RISC with its on private memory and you'd be keeping up with the jones's. Oh and actual decent tools to code the system with.
In terms of the 68000 being used as the Manager chip..
The 68020 and 68030 chips were both considered for that role at one point, but dropped due to how much it would push up the manufacturering costs.
I remember reading somewhere, a programmer said "IF ONLY THEY ADDED 1 MORE REGISTER!!" then everything would've been so much better. :P
That's tragic, because the 68EC02/30 chips were only about $5-10 at that point and could've made the development of games much easier.
@@MaxAbramson3 don't they even have instruction cache? Together with the large register file on a 68k this would allow a lot of code to run without congesting the system bus or eating into JRISC cache.
@@ArneChristianRosenfeldt The 68EC030 has a 256 byte ICache and a 256 bytes DCache. While those only manage a 50% hit rate on benchmarks, they can manage about 80% on gaming code thats written to take advantage of them.
@@MaxAbramson3 From an overall perspective, I would invest in the gaming code to run on JRISC and the rest to run on 68k. Still, 50% hit rate mean that the 68k can run 2 instructions before it has to wait for the bus and with 32bit it is twice as fast off the bus again.
Still, I would rearrange the main board more like this: Tom in the center of the memory (like PS4). Small cartridge slot and associated area. Point2Point DDR connection to Jerry. And uh, a 6502 core inside Jerry as the friendly face. PCB would look as clean as the N64. I really don't see a path forward with a discrete 68k. 50% hit rate really isn't great, considering that Doom manages the JRISC cache so much better.
I would rather invest into a package to remove the color conversation off Tom .. uh, but it is too small to justify a whole custom chip. Not like in the VGA days with the palette or the character ROM in MDA.
Excellent video. Another annoying issue is the fact that the act of the GPU processing its object list is destructive to the list, so it must be recreated every time you use it :(
Yes... another cost saving flaw.....you can however reuse most of the list but will have to replenish certain fields of the OPL instructions. They really needed an instruction cache on this silicon and on the blitter as well. It would have made a monster difference.
I just bought my third jaguar. Only reason was alien vs predator. It cost $400 this time for a new one, the last one I bought before that was in the mid-90s at Walmart for $50.
How much would a sega cd go for right now? I still have mine and it’s the one you would connect on the side of the genesis.
Did you know they were thinking about using the Lynx for AvP radar/sonar? How awesome would that have been...They had the machine but didn't know how to use it properly.
@@randyfemrite7525 Because the UART on the Jaguar was greatly flawed and locked up all the time. Scatologic(formerly 4-play) folks were the only dev team to figure out how tomake the networking work, not only properly but in such a way that the more Jaguar you hooked up together in BattleSphere, the 'smarter' all machine got. If one machine in the network was not being overworked, it would take up slacke from another machine that could use the help. The only other team I know who did such was Airs Cars folks, who I think were licensed the code from Scatologic(formerly 4-Play). Had Atari known how to deal with their own bugs as did these folks, you might have seen that Lynx hook up which yes could have been really cool for a second player to work as a team with you.
I remember buying a shit ton of them for ten bucks each back in the blowout days. I wish I bought many more than I did. I'd be making a killing today.
Cool video. The weird hybrid of two 64-bit processors, two 32-bit processors and one 16-bit processor still to this day makes it unclear if the system as a whole is 64-bit as Atari claimed it was.
System bus size was usually how they determined it back then. Like how the 386sx was 16 bit and 386dx was 32 bit
It was basically just marketing talk, because it had 64-bit architecture, it coukd be marketed as a 64-bit console, but it wasn't a 'true' 64-bit system as we would know it.
@@thefurthestmanfromhome1148 It was true 64 bits just like the 8 bit 16 bit Turbo gfx..... both referring to the gfx processors. Not the main processors....but... technically you are correct since there is no Turing complete 64 bit main processor.... but with that said, there is NO main processor in the Jaguar. At best the 68k is a boot processor. You can turn it off and run the system completely with Tom & Jerry. We do this in several demos... we released one to the public to promote the use of main RAM RISC coding, only to be laughed at by people who can code past an 16 bit cpu if their lives depended on it. Look up Surrounded 3d.
@@LakeHowellDigitalVideo Well even today PC's have buses bigger than the main processors...but they are all very high speed serial one lane PCIe and all so how do you rate the mother board? It's even moreso a technical conundrum ....but hey.......imagine the Jaguar today with PCIe tech?......wowzers. Of course it would be quite a different beast at that point.
That took some effort to make, thank you for that. I didn't closely follow every bit of information you you presented, but two things stood out: UART bug seems like a problem in comms between JAG and another external device (like modem or another Jaguar in some kind of network), not inter-chip communications. MC68K 32-bit issue from my understanding means that you just cannot trust some long word operations in two memory areas. Rest of the memory is fine, other '.l' assembly instructions seem fine, and non-long-word operations are fine (so you can use two move.w or four move.b instead of one move.l). Annoying, but not a deal-breaker.
Again, thanks for the interesting vid.
The 68k only has a 16 bit data bus externally anyway so it's not like you will gain much in the way of performance. Best turn the damn thing off and let Tom and Jerry deal with the real work.
Black Ice/White Noise held the highest promise IMO. Could have been grandbreaking for its time, GTA3 before GTA3.
Cool. I''ve got to get myself one of these Atari Jagwires to go with my Atari Jaguar. Good video. I knew these were awkward - just not how awkward. I had friends worked on some cool stuff on the 8 bit Ataris, there were some good tricks with those to improve things but it seems you needed something like those tricks just to make it work like it's supposed to. I had a friend import one of the very first ones (so early we had to solder the RGB cables onto the edge connector, we couldn't get a cable here) from the US to Scotland, and although it had a few great games, overall it was a huge disappointment.
Jagwire! Lol. I think me and you are the only ones who noticed.
Sooooo, programming a game on an Atari Jaguar was equivalent to trying to eat a hot dog stuck in the spokes of a bicycle wheel whilst moving at 60 mph during an earthquake. 🤔
Maybe a little easier that that 🤣, but yes difficult
So they said F it and coded to the 68000 instead.
It's not really but it is very time consuming using the shit tools Atari left us with.
@@richhutnik2477 yes essentially choking the systems real ability.
So now that I understand a little bit of assembly I went back and read the thread where they tested out the GCC for GPU output. It was very interesting.
You were right. It looks like it's a GPU compiler output problem and not a hardware bug.
I'm not sure what went down with Brainstorm if Atari didn't pay them and they just told Atari that there was a bug they couldn't figure out. Because it beggars belief that they were skilled enough to put in all those actual hardware bug work aroundarounds in there but couldn't get the loop counter right.
Change one register and one condition code from GT to LT and the output is fixed. No wonder Corley couldn't remember what the problem was because it wasn't memorable Probably took him a half hour to whip up a script to fix it.
The buffoonery of the Atari management also beggars belief even more looking at it now because it's apparent they didn't even check. All that money they spent contracting Brainstorm to do this wasted for want of a competent manager.
So now that makes sense when I asked Carmack some years ago if he ever ran into this comparison hardware bug when he retargetted his compiler and he said no and that he'd never even heard of it.
Because there never was one.
I would like to see a video on what you think about the canceled Panasonic M2 video game console. I really enjoyed this video, and the one about the Sega Saturn.👍
Amazing and in-depth! Great job. N64 had bottlenecks, ps3 was arcane, but this one is straight up bugged haha. No wonder it was left in the dust.
ps. weird pronunciation, Jaguayer
Thank you!!!
Should be 'Jag-U-Are' I suppose.
Its the North American pronunciation.
@@robertfoxworthy5503 so, the wrong one then.
@@Ayrshore the root word is from a south American
@@robertfoxworthy5503 Time the yanks learned to speak English.
P.S. - when are you programming your first Jaguar game? ;-)
Haha, that's a good one ;) maybe I will take a look sometime in the future
@@ZygalStudios reach out to songbird productions for help
@@Tolbat Jaguar freaking sucks bro
@@tutoriais5266 I hear your mom calling.
@@GORF_EMPIRE yeah that's called bad trip, stop doing meth
I remember hearing at the time that if not for these hardware bugs the Jaguar would've been much more powerful. Someone (Minter?) said that one of the bugs caused texture mapping to take 11x as long as a plain ploygon, for example. Even as it was it was a worthy competitor for the 3DO, and not that much worse than the Saturn.
You might be thinking of Martin Brownlaw, coder of Missile Command 3D, not Jeff Minter.
John Carmack also commented on how slow texture mapping was on Jaguar
Texturing was handled at a whopping one pixel at a time as where the CRY mode shading was full phrase capable( ei 64 bits at a time or 4 cry color 16 bit pixels)....... once again.... another costly cost saving maneuver. I'm almost wondering if the GPU in software might compete against the crippled blitter texturing....I can write 32 bits at a time.... thats2 cry pixels,4 8bit pixels. Better than one pixel at a time.
Credit has to go to developers who did use the hardware wisely and discover work arounds to get the best from it.
Eclipse for discovering the small area of memory that could be used as a texture source and it was the same speed as flat and Gouraud shading (twice as fast as normal textures).
ATD for using the GPU to get a better framerate and draw distance for Battlemorph over Cybermorph and ignoring Leonard Tramiel'S demands to fully texture-map the game.
Rebellion for Skyhammer.
Ubisoft for Rayman and showcasing the machines 2D abilities.
3DSSS( us) along with AtariOwl came up with the main RAM GPU work around.... it makes a big difference in performance. Perhaps one day I'll consider coding a game for the Jaguar again.
This is probably the deepest dive video on the Jaguar anywhere on the Internet. I've always been curious about that beast, so thanks for that.
That said, I feel like you are putting a lot of weight on pipeline stall and related issues. Anybody familiar with MIPS would have been pretty well versed in needing to throw in no-ops and arrange instructions to be pipeline friendly. And pretty much every gamedev in that area had to be somewhat familiar with MIPS, given it was used in the PS1 and N64. The odd mish mash of ISA's and bus sharing behavior was probably a much bigger issue. I feel like if you do a followup video, you should try to actually write some simple software for it. By the time you get all the various dev tools set up to do a build, you'll be weeping for something like an N64.
Thanks for the in depth comment! I appreciate it! So the 3DO and Jag were some of the first consoles to use RISC architectures. The high instruction throughput and scheduling issues were fairly new in the software development world at the time. IIRC, the Jaguar was the first (or one of the first) to use a MIPS processor (In a later Rev of hardware, no MIPS processors on the board originally.) specifically up until this point for a game console. So that was definitely a challenge. But yes, I do agree with you. The largest challenge was using the hardware to the fullest extent, as is with most of these consoles. And yes, as I mentioned, no real time debugger. But the PS1 and N64 were much different, more refined, mature, and more efficient. They also had much more resources for R&D and Nintendo had the best 3D hardware company in the world on their side, so these environments were much more mature and developer friendly. The Jaguar was not and that's definitely something to consider. Excellent points!
A series where James tries to write simple demos for all the systems he talks about would be Kino 👌
ANYTHING even a cheap ARM would have been better than the 68k. You don't think the PS1 has flaws? Just look at those horribly sloppy textures with the Charlie Brown warp effect. The difference is, the PS1 was a fantastic design...all parts having their own private memory and hardware textruring....which came at a cost.... the Charlie Brown syndrome). The Jag... a great futuristic chipset used in an outdated console design.
Zygal my friend, we are still waiting on you to make a Jaguar game sir.
The Jaguar: A console that was pushed out far too quickly.
-The excellent hardware wasn't properly integrated and implemented - couple of tweaks could have made it more robust and powerful.
-The support library's were somewhere between useless and non-existent - this made it a pig to develop for on stupidly short timelines.
-Atari wasn't in a position to provide sufficient support or marketing - there was too much to do in too little time with insufficient money.
It may have bombed anyway, but at least it could have gone down fighting.
Cojag arcade board is a what if scenario had atari used a m68020 or the great MIPS R3000 cpu. With the r3000 it would've rivaled the ps1 and Saturn performance with tweaks on the hardware as well. Plus, solving to remove the bugs from the coprocessors.
TOM & Jerry were fine, in spite of the bugs.... the 68000 was a really bad move on Atari's part. You just took a 64 bit chipset and dropped on to a 16 bit /half speed system bus. It might as well be an Atari ST, amiga or Genny at that point. it should have been another RISC or a 68x20 or higher.
Just stumbled on this, but holy damn is this ever in my wheelhouse of enjoyment! Good stuff man, very good stuff! One of the more easier subs I've ever had the delight of making!
So in summary:
Jaguar: Hardware bugs requiring wait states and screwing up regular commands
Saturn: Too many processor subsystems with no easy way to access them all at once
Both: Terrible first party development tools and documentation.
One bug here, one bug there, one bug for everyone everywhere... Bugmambo no 6 :D
Holy Crap ! I had no idea this system was so complicated !
That was a great video, I have a Jag and love to hear about the hardware and history of it. Right now I ordered an SCable and found an old flat screen TV. I am pumped about that and the fact that I can buy new games that run better, have save options and improve frames. Also, they have a lot of options of either buying a new controller or getting one custom made. All good things!
To be fair, many systems of the early 90's were grappling with the concept of superscalar pipelining, and the Jaguar just had more problems than average. It was fashionable for companies to attempt an in-house RISC CPU back then, rather than license a well-tested core. In terms of system architecture, the Jaguar was actually quite nice, and the N64 and Saturn were both far more difficult to program.
Also, *please* turn down the music, or at least use something less melodramatic.
Unlike those systems, the Jaguar's main chipsets were held back by bugs. If Atari had left it's development tool set and chipset a little longer in the oven like let's say, a delay for it's launch in 1994, that would've been preferred over an early launch with half baked tool and hardware designs.
@@crazedlunatic43 The bugs in the chips could have been forgivable if they did not choke the rest of the system with the 68000...a chip I love dearly... just not in the Jaguar.... but yeah.... a few of the bugs fixed and boom.... In fact.... most were not bugs.... but oversights....cost cutting ones at that. A cache on the blitter would have been a major speed up...ei...now the blitter can draw an entire polygon with no intervention from an outside processor. The OPL needed some extra registers to eliminate the destructive fields in the OPL list...this too would have saved a lot of time. I would have gladly waited but Sony was ready to release by then and remember...they had 50 titles ready.... Jaguar even a year later barely had a dozen or so.... most hardly next gen. Tom & Jerry ... fantastic tech wasted on a cost cut to death design. I think Atari should have released the CoJag. Now you have an authentic arcade machine in a console. Nowyou also have hard drive and other media expansion out of the box as well. Long before Sony or Xbox did so.
@@GORF_EMPIRE Are you one of those guys from Atari Age? I feel like I’ve heard the name “Gorf” somewhere around Atari Age and explaining how the Jaguar worked.
It be really interesting if a programmable logic array was used to model the jaguars chip(s) but with most of these bugs worked out and to see how fast this chipset could have been at the released Mhz rating. Essentially making one more revision to the silicon which is evident being needed. Also was this rush to market driven by marketing or dollars running out for the company?
Cool idea and yes. They pulled it out of the oven too soon due to Atari rapidly bleeding money at the time.
Dumb non-programmer question: Instead of workarounds, what would it take to actually FIX these bugs? A redesign and manufacture of chips? I don't know anything about programming but it just sounds like no one will ever be able to use the hardware's full potential.
Not a dumb question at all!
Most of these bugs would require new hardware spins, which is definitely not ideal from a cost standpoint. This also means in some cases that software developed on old chips is not compatible with the new hardware either.
@@ZygalStudios at the time, Rob Nicholoson of Handmade Software said the Jaguar chipset needed a further 2 revisions to fix the bugs alone.
The Jaguar GPU had 4kb of internal nonwait RAM , due to a bug , you had to write everything in 4kb chunks. They could not change it to 64kb of normal ram as the design was complete.
The system had countless design faults.
@@FantasyVisuals The RISC chips in the Jaguar were only capable of 64k address spaces as it is. I think 16 k would have been killer but unfortunately that would have cost a lot. You are not lying about the design faults, both in the chipset and the console.
Your videos are absolutely incredible and I love how digestible they are! They get me interested further in CS through things I already love; good stuff!
The Jag Gwar was hard to develop for because most developers used IBM PC based SDK. If you really wanted to tap its true potential, you needed an Atari TT030 computer.
It's not pronounced 'Jag Gwire.'
Did the JAG-U-ARE have a SDK for the Atari TT030?
If not, this would appear to make the task of development more difficult.
The SDK/Environment cannot mask the system architecture bottlenecks and hardware bugs, which, overwhelmingly, were the main issues with it.
You know words are pronounced differently across cultures right? What he said was absolutely correct. It is pronounced 'Jag Gwire' here in the states. Just as we wouldn't be caught dead saying something as ridiculous as "Zedbra." Thank you and have a pleasant week.
@@Sinn0100 Uhhh, not in any of the states I’ve ever been in, lmao 😂
@@polytrashed
I've been to every state in the Union and not one time have I heard anyone pronounce Jaguar like British people. If you want to hear the most common way a word is spoken look at Television or film as they tend to match the most popular or frequently used dialect...especially commercials advertising a product. One example of this is the Atari Jaguar commercials that ran from 1993-1996. I encourage you to look it up as it will show you the correct pronunciation here in the states.
Before you tell me the UK this or that...remember, every country has its way of doing things. We might all predominantly speak "English" but it is not the same as "English" in the UK. Often times their words have different meanings than ours do and spelling can be radically different. Just look at the word color and colour. Both mean the same thing but are spelled completely different. This phenomenon is very prevalent in Spanish speaking countries as well. Spanish in Spain is very different than Spanish from Puerto Rico.
@@Sinn0100 What? I think there’s been a misunderstanding; everywhere I’ve been it’s been pronounced “jag-gwar” (similar to “bar”), while the stereotypical English version is the three-syllable variant “jag-yew-are”… but never before today have I heard it pronounced it as “jag-wire” lol
it could still do good graphics, its other hold back was the cartridge, i saw article talking with Rebellion software who did the game Alien vs Predator, which was a nice looking game and they said specifically, that they cut back on the texture quality considerably, due to having to cram it on a cartridge
And they had to practically beg the Tramiel's to increase the cartridge size over the original allocated size.
A full orchestral musical score was intended for the title, but no room for it on the final cartridge.
@@thefurthestmanfromhome1148with music you mean: wavetable?
I always thought the Jag suffered from hardware complexity issues, but it sounds like the system wasn't very complicated... But all the different components in the system had a tendency to trip over their own or each other's feet, and nothing in the system really ran in sync properly.
This is quite different from the the problem the Saturn and PS3 had, where the architecture was incredibly complicated but ran very fast and smooth if you knew how to actually control it.
Sync happens via the system bus and is a major slow down. Rather all subunits should get input and output queues and leeway in their timing. Pipeline!
I tried to read up on a simple bus and thought SPI or I2C. But those are more complicated! With a parallel bus no stop bits are needed. We recover no clock like RS232. Also there is a star topology for requests.
Looks like Jag went from from a headache to a full blown migrane.
I think you have misunderstood the JUMP recommendations.. you certainly don't have to prefix a JUMP with NOPs, and you don't HAVE to postfix them with NOPs either, but you do need to be aware of them with the pipelining. As the instruction after the jump will be loaded into the pipeline before the jump is executed (hence the suggestion of using a NOP after), but there is nothing to stop you adding an instruction immediately after a JUMP as long as it is contained within the 16bits of an instruction (no MOVEI's), and a few other gotchas (Indexed offsets go boom :D ).
I use instructions after a JUMP quite a lot in my code on the Jag and it works without issue. Obviously these are jumps in SRAM, I don't bother with any of the GPU in Main crazyness, life's too short.
Now remind me, is this the jump recommendations I reference around 13:50?
Or is it somewhere else? Either way thank you for pointing that out and commenting! :)
Just kidding I see it at 12:19!
You're right! Thank you. Just an effect of pipeline systems! :D
@@ZygalStudios Don't know if you came across it or not, it is touched on in the Tech Manual (there are at least 3 versions of that, each with it's own extras and corrections, the one dated 1995 I think is the most complete), but the "Jaguar" part of the system is just Tom & Jerry with an additional generic general CPU. In the Arcade versions of the system, the 68K is replaced with either a 68030 or an R3K or R4K, as well as increased ROM size and DSP bus connection being full 32bit.
@@linkovitch Did not know about the different hardware in the cabs! That's neat they used a MIPS CPU :) smart move on that one and actual 64-bit
@@linkovitch the Cojag cpu hardware is a 68EC020 or R3K.. no R4K.
Nobody knows the 68000 from the Mac, it is known from the Amiga and the Atari.
And the Mega Drive / Genesis
@@watchm4ker oh yes, many console used it and almost all of the arcade machines, but I was referring to home computers only.
@@Corsa15DT Oh. Sharp X68000
@@watchm4ker yes, the X68000 is a great machine, but it was not a commercial success, very few sold...
@@Corsa15DT Not massively successful, no, since it never left Japan, but it lasted until 93 and had numerous models made.
Great video! Background music was a bit too loud but awesome content!
I do not know most of the jargon you were saying but it is still extremely interesting! Honestly I would love to watch more and see if I’m able to learn.
I’m intrigued on Jaguar games that actually achieved the hardwares true potential.
I don't know if there are any that TRULY did reach full hardware potential. One thing thought that I find interesting is that if you look at the two games that were on every system at the time, NBA Jam TE and Doom, it's the Jaguar versions that are regarded as being the best, even better than PS1 and Saturn versions. So who knows what could've been with the Jaguar.
@@BHGMediaGroup Who knows?
@@roxynano I think the one thing that could be telling is that there's still a fairly large group of homebrew developers that make new games that you can buy on Atariage, but those also don't showcase the full power, most of them not even coming close to what was already commercially available, so after all this time, homebrew coders can't figure out how to squeeze out the full power, it was unlikely anybody was.
I know this would be a super late reply, but there wasn't much in the way of "2nd (or 3rd) generation" software for the system, which successful consoles get, and beyond of teams producing 2/3/4+ games for the same system. John Carmack, who coded Wolf 3D and Doom for the Jaguar, did say that if he had done Doom again, there are several things that he would have done differently and more efficiently, so it's safe to assume that had they done Doom II, it would have been better than the Doom port was.
That all said, the best examples of what the Jaguar could do were: Iron Soldier II, BattleSphere, Wolf 3D, Super Burnout, Doom, Missile Command 3D, Zero 5, Skyhammer, BattleMorph, NBA Jam, Tempest 2000, Alien Vs. Predator, Hover Strike CD, Tube SE, and Primal Rage. There was also some unreleased games that showed off some near-PSX potential, such as BlackICE/White Noise, Phear (which actually became Tetrisphere on the N64), Phaze Zero, Native, Conan, and the AtariOwl RPG game. :)
@@AP-mw9oj Will note! Thank you for the late reply!
A delayed launch to ensure that the chipset's hardware bugs have been fixed, and Atari providing proper development tools over pushing the system for a '93 launch would've been preferred.
Rob Nicholson of Handmade Software, said the chipsets needed another 2 revisions, just to get the bugs out.
Atari didn't have the money. Any revisions to the hardware would have meant cooking up more silicon, which was millions upon millions of dollars per revision, at a time where Atari Games hadn't seen success since the Crash.
show me any bug which does not need more transistors ( and potentially more bugs ) to solve. Feature creep is the problem. All those special JRISC instructions for JPEG and mp3! Multilevel interrupts on all 3 processors! Two audio DACs ( why not stick to external from the start ? ). Complicated backwards compatibility to Atari controllers instead of simpler Japanese design. Vertical scaling should never have been done by the OP. Why can the blitter scan for values, but at an unusable slow pace? Why do we have OP and blitter? Really, the Jaguar needs one simple 64 bit memcopy unit with access to the bus and then one pixel pusher with private memory. Bringing a 16 or 32 bit framebuffer to the screen is just a matter of memcopy. Don't confuse it with sprite or palette or scaling or shadows, all of which are too slow for the memory bandwidth. The OP already has its own (private) linebuffer and palette. Just unify it with the blitter . Who ever needs this exploding pixel mode of the blitter? Why have to relearn everything when going from 2d to 3d? Why 32bit cartridge if the clock rate is too low and the bits too expensive for live data anyway? Who needs more than a pi/2 cos table in DSP ROM?
Not enough money and time was of the essence. Could things have been more wiser, absolutely but any delay would not have helped as it would have buried Atari.
@@GORF_EMPIRE If anything, I definitely agree with the 68k being a mistake on Atari’s part. I’m not too familiar with Tom and Jerry, but these two chips were the main highlight of the console and it’s a shame that they were burdened with an outdated 16 bit processor. And yeah, Atari was short on cash compared to its competitors. Honestly, Atari would’ve had a tougher time trying to compete with (Newcomer who had loads of money compared to Atari) Sony, Nintendo, or even Sega, as those had stronger brand recognition compared to Atari in general.
Another thing about development on the Jag, various direct ports used the 68000 almost exclusively as the main CPU for programming, almost completely ignoring Tom and Jerry. This is something other Utubers have mentioned when deep diving into software quality and why some titles look 16 bit while others like Rayman and Tempest 2000 excelled.
Yes.... Gee.... they look 16 bit because they are simple ports from 16 bit machines.
Ahh yes, so you have a very in depth understanding of this, what would it take to make a clone console of this system?
With some good middlewear the Jaguar could have done some amazing 2D games like platformers and the like. It was never going to compete with the likes of the Saturn and Playstation though.
I've always thought that they should have just released the Panther in 91 to compete with the Megadrive and SNES tried to build up a stable of third party developers and put the Jaguar on the back burner. People always say "oh but the Panther doesn't compare to the Jaguar" and no it didn't but it still exceeded the 2D arcade PCBs of the late 80's and early 90's and was easier to write software for than the Jaguar which was good enough.
The mid to late 90s were a dark time for video games comparable to the "iron age" of comics. If you showed someone beautiful pixel art vs ugly blocky 3D of that time 9 out of 10 people would prefer the 3D.
What would the middleware do what the SDK does not? Tile based background? Box2d collision and physics? Did people need this middleware on 16-bit consoles? Better audio driver?
@@ArneChristianRosenfeldt From what I have read the Jaguar SDK was terrible and didn't make it any easier to develop for. an middelware would give you a software framework to start with with all the heavy ASM lifting done already.
@@atomicskull6405 the Framework did not even give a printf . I think that this is called C stdlib. People complain that the compiler did not check for overflow. I did not know that C can throw this exception. I don’t understand how to overflow 32bit. Much bigger problem is that factors need to be 16 bit. Probably, if OP would not be able to write to DRAM, development would have an easier start. Middleware to draw a background from tiles would be nice.
According to Atari uk, had Panther been released, there would only of been around a 9 month window, before Jaguar was ready.
People who worked on the Panther, like Jeff Minter, Rob Nicholson from HMS etc, stated the actual sprite abilities weren't anything like the numbers Atari were pushing.
14:28 I wonder if this is a flaw of divide-scoreboard itself were maybe divide-read isn't considered a read by the scoreboard, thus the first divide isn't scoreboarded first (or at all), so second divide can occur falsely.
This makes the previous bug, of divide needing a dummy wait, make sense, as divide isn't viewed as doing a read by scoreboard and so is ignored by scoreboard.
If divide is too long between reading and execution, the scoreboard may see some weird, null, intentionally placed wait (to account for long divide time, divide may include a built in dummy wait statement) operation occuring. But a "dummy wait ending with divide result being stored" instruction doesn't contain a read, is seen as a dummy, thus the scoreboard treats this end of divide, and so the whole divide itself, differently and ignores it.
The divide hardware is pretty stable and only requires 18 cycles to produce a result but it is separate from the store/load issue which are scoreboard shortcomings.
Good Video, I always wondered about the bugs in the hardware that John Carmack talked about. Saying that, I think the bugs were NOT a show stopper for the hardware. Yes they are an issue and will slow things down for development, but if all the bugs are flagged and addressed, i do think the Jag had some clever ideas. I had one back in the day and DOOM , AVP, and Iron Soldier were some good games.
The Atari Jaguar was like a system from the future way ahead of its time.
There's really nothing ahead of its time about the Jaguar, a lot of its games are just worst versions of either PC or console games of the time. Even the Super NES and Sega Genesis had better 3D capabilities than Jaguar. Companies need to know that games are made to be play, not to be look at. A lot of Jaguar intend was to just make games that are good to look at regardless how they play and this is why not everyone wanted to buy one.
@@VOAN Wrong. You truly are clueless. Nothing the SNES or Genny could do could possibly outclass the Jaguar.... at least not without serious help from 'enhancement' processors on the carts like the SNES and Sega had to do and even then did not have the ability for Jag's 3D OR 2D for that matter. Jaguar hardware wise was superior in many ways to anything at the time.... unfortunately it was grossly mishandled in its dev kit, it's marketing and developer relations, not to mentions public relations. Do a little research about the systems you are talking about before you make a fool of yourself next time. Though you are correct about a system needing games, you are perfectly clueless when it comes to that time period's hardware. The SNES could not even do a decent version of Doom even with the help of it's BEST enhancement chip. Might as well build a new console at that point. Jaguar DOOM alone outclasses the 10 FPS garbage DOOM on SNES. You SNES fans got ripped off. Forget 3D though, the Jaguar pissed all over SNES and GENNY 2D wise.... show me a game like Phase Zero on the other two.... oh wait... that's right.... neither could do it even with enhancement chips... enhancment chips for systems with no dick.
Most games just ran on the 68000 which is why many games looked 16 bit because it was.
The music is loud enough to drown out your otherwise perfect explanation.
Were there any games that took advantage of the Jaguar's system? Have there been any from the homebrew scene that push the system?
AVP stands out I would say per the time period and same with Missile Command 3D.
As far as homebrew is concerned, I'm sure there have been some too!
@@ZygalStudios AVP, Iron Solider 1 and 2, Battlesphere, Skyhammer, Rayman.. Zero 5..
Probably the best examples of Jaguar hardware being used wisely, maybe Battlemorph as well.
The biggest bug on the Atari Jaguar? All the experts I've heard pronounce the Atari Jaguar "The Atari JagWIRE"...lol
When did the JAG-WIRE come out? I only ever heard of the Jaguar? 🤣🤣🤣
Oh you didn't hear, it came out last year 🤣🤣
Could you go into how this affected the programming of Jaguar Doom?
Carmack has been quoted as saying "Coding for the Jaguar is fun!"
And nobody at id wanted to work on it. So basically only he and Sandy Petersen ended up working on Jaguar doom.
John Romero and Dave Taylor also worked on Jaguar Doom, but they weren't fans of the hardware, Taylor in particular
So what would you say caused the “Hardware Bugs” : The design or the manufacture?
I ask this because I find most quick to jump on Atari on the lack of dev support for the complex and/or flawed system but NEVER, to my knowledge, place any responsibility on the manufacturer IBM.
Well Flare Technology was contracted to design it. So it would be on them for sure. But it was really just two guys and they designed this within just a couple years, so it makes sense. 2 guys designing this system with just a couple years of development explains why it was just functional and didn't have any pomp and frills.
But if we're talking specifically, Atari contracted resources for the project, they are certainly responsible for the lack of resources.
@@ZygalStudios
Thanks for the response. But I remember an interview with one of the Flare team in which, to paraphrase, someone asked him why did they chose assem. Instead of C for coding and what John Carmack say about scratchpad memory and no virtualization in the blitter? To which he replied that it was supposed to have those thing but there were defects in the hardware( he may have said silicon) and he blamed the Tramels for rushing the project.
My point is Atari made mistakes their’s no doubt but if there was a defect in the manufacturing process then that is on IBM.
Jez San, Argonaut, who were working on the cancelled Jag CD version of Creature Shock:
"A true 64 bit chip would have a 64 bit ALU and 64 bit registers. The
Jaguar does not. Simply having two 32 bit chips does not constitute a 64
bit cpu. Having a 64 bit databus does technically allow you to call it
a 64 bit system if you must, but 64 bit cpus? no way."
On the N64 the CPU was usually switched into 32 bit mode because no game needs 64 bits ( unless there are vector instructions).
The so so graphic design on the GBA from Argonaut tells me that they are not competent.
poor further ado he never gets to go any where
This one took me a good minute to understand 🤣🤣 I love this.
Good one!
Please do a video on the NUON system.
Is the jaguar graphically better than the game boy Advance?
Love your channel...please do the atomiswave...or the neo geo pocket...thx
Thank you!!!
Planning on doing both :)
Thanks for stopping by!
THE MUSIC IS TOO LOUD
Sooo just use the 68000 and Nevermind tom and jerry
Awesome video. Also I bet you could do an awesome impression of Robin from Teen Titans/GO.
Thank you!!
Haven't heard that one before 🤣🤣 gonna have to look this up
If there are hardware bugs, why not do what Nintendo did. Put in some expansion chips into the cartridges themselves with other processors on them so that you didn't have to use the processors with the bugs in them on the actual console. Like you could put in a faster 68,000 processor into the cartridge and just use that.
That would massively increase the cost of producing those carts, and considering Atari was in some pretty dire financial circumstances at the time, I doubt they could've afforded it.
Realistically if they were going to eat extra costs, they would have been better served by delaying the Jaguar's launch until they had fixed at least some of the more serious hardware bugs. Really a shame to see some otherwise brilliant architecture cut down by being rushed to market.
Another possible solution is if they'd beefed up the Jaguar CD with some actual power, and maybe did a hardware revision that incorporated it. As far as I understand, all the Jaguar CD does is allow for bigger games due to the increased capacity of CDs (unlike the Sega CD, which actually has extra processing power). Seems like a wasted opportunity.
But as a hypothetical solution to the problem of the system being on the market in a buggy state, your solution could have worked if cost wasn't such an issue.
@@GreyMatterShadesSam Tramiel didn't want devs using bigger cartridges, he was never going to sign off on putting DSP chips on carts to help with 3D etc.
That's the reason the Jag CD is a dumb drive, costs had to be kept to bare minimum
@@thefurthestmanfromhome1148 I totally agree that Sam Tramiel wouldn't sign off on extra chips on carts.
As for the Jag CD, I still think they could have done something. I'm not sure they could have (or should have) gone as far as the Sega CD, but it was clear developers were struggling to release visually impressive games on the Jaguar/JagCD. Even some relatively cheap additional ram or processing might have helped the system perform better without raising the cost too much.
Of course the real solution to their problems was to fix their hardware issues before launching. Anything else would have just been a band-aid, but sometimes band-aids are helpful.
Was it really that Tom tried to implement hazard detection and failed, or was it that it used pipelining but no hazard detection?
There were no bugs with this. If there were, the processor wouldn't have even gotten off the ground. It had hardware to detect hazards and then register scoreboarding logic to correct when a pipeline stall occurred.
The purpose of explaining this was to show some of the design challenges in assembly that you would have as a programmer.
16:01 - This is real problem... Who created this one ?
Why would you use the 68k to write to registers in production. Weird that even this is buggy because I feel that Atari used this access to debug the custom chips.
Jag wire?
Great research dude! It really is too bad that Atari shipped this system with inherent bugs. It's my understanding that they rushed this thing out the door as a hail marry to save the company. Not realizing the bugs.
There is a 2600 game that builds a unique map per each play. No one has access to the pre compiled data. No one knows how it was accomplished. Even the original programmer forgot the algorithm that he derived at.
Might be a neat puzzle to look into even though it's not really hardware related.
Still does not explain nut case like an Object Processor which writes back into the display list. Non power of 2 for maps enforced, instead wrap around is not there. They use 16.16 math for Gouraud shading, but have an overflow problem because they could not be arsed to store the 8 bit chromance in a dedicated register. They allow detailed bit width for ROM (where we need to decompress anything slowly because ROM is expensive, but have not separate configuration for Jerry and CPU ??
The controller . Uh why not compatible with NES and this shift register?
'jag-wire ..... um .... no it's jag -u-ar
At cost jack trammel ears kicked up their probably how he fell for it.
To think that they planned to release Tomb Raider and Need for Speed on this... I do wonder what it would have been like
Pretty crazy right?
This had such high hopes.
@@ZygalStudios The list of cancelled games kinda makes me sad, I wish there were more racing games on the console.
@@pocketstationman6364 you can strike Tomb Raider from the list, been confirmed by multiple Core Design sources, Press took mock up screens and claimed game was headed to 3DO and Jaguar CD
Jeremy Heath-Smith boss of Core Design, has gone on record saying the Jaguar would only ever reciece enhanced Sega Mega CD ports.
@@thefurthestmanfromhome1148 Ah, okay
Wish you could have showed us some of the games that had terrible problems with these bugs 🕹🐆📺
The games were written with the bugs in mind so the programmers worked around them.
Look kids, its the Jag-Wire!
hi, very complex. I have a question though Atari had their woes for sure, but given more time, as this project was surely rushed. Could someone with the right 'knowhow' try to fix it 'Even just to show the Jaguars' potential. I mean. Do 'you' honestly think this could have wiped the floor with the PSOne; if done correctly??????????????? Only Using What 'Is In It, or maybe, just maybe addages 'from the time that atari might have had 'if not being up against the wall' so to speak. Sorry, I hope you get my meaning. I would love to see this console be 'what it was meant to be'!
Some games need 100 cycles for a single pixel. So obviously there is more wrong than fillrate (which is not thaaat bad). Any optimization will cost transistors. The blitter could speed up by a factor of two or three. We ditch one line buffer. There is already a high resolution 2d mode where you have to redraw all sprites which reach over the middle of the screen. Basically kill rayman and super burnout for more real 3d performance. Full motion video was all the hype. Instead vector3 and vector 2 instructions working on registers or at least fixed point 16.16 from SRAM would be nice.
GL_REPEAT . Ditch non power of two size for pictures. Interleave x,y for texture buffers. Remove all the monochrome features from the blitter. Collision detection in pixel mode?? Better overlap between GPU and blitter, so like the left x of the current span can be set to the new line value while the last is still drawn. The others may have a cycle skew. The blitter should not use interrupts, but pace the STORE instructions so that new values come just in time. So no idle blitter.
Blitter needs to do alignment. Everything needs to look like pixel mode for GPU.
Atari Jagwire
Jagwire, it's the best kind of wire
Jaguire
It's not jag wire, it's jag war.
I was only kid that had one in 90s I just wanted doom AVP but no pc 😢 so jaguar it was I don't know price wich I keept it
I love the "Jag-WIRE".
"JAG-U-ARE"
Jag-you-er
@@alkenstein That is not how Atari, the commercials or any employees of Atari at the time or even now pronounce it either way. it's Jag (short u) R. Like the cat. Not the car.
@@GORF_EMPIRE I bow to your superior knowledge
The 68K has not 68 000 Transistors....... The name is the logical update from the old CPU 6800......
Got this from Steve Heath's RISC, CISC, & DSP book.
According to him the 6800 had approximately 6.8k transistors and the 68000 had approximately 68,000 transistors.
@@ZygalStudioswouldn't an fpga eliminate pipeline issues? As glue?
I know in Britain it’s “Jag-you-are” and in America it’s “Jag-wahr” but until now I’d never heard “Jag-wire” but, ok.
We say "Jag-you-are" in Australia too. I'm used to hearing the American "Jag-wuah" pronunciation as well, but I too have never heard anyone say "Jag-wire".
@@WhitePointerGaming I’m Aussie too. One of my Dad’s sayings was “What a dag you are in your Jaguar”😁
I found this series and immediately subscribed to this channel, i hugely appreciate the effort you put into yours videos. Will you make deep dive to ps2 architecture, emotion engine and graphics synthesizer are really interesting, and i would like know their potential a hurdles since i watch this coding secrets video: ua-cam.com/video/iEQLbbyToxw/v-deo.html
Yes!! Absolutely!
Thanks for your feedback :)
I love gamehut and coding secrets btw, pretty awesome.
The background music is very disturbing. It's not needed to be a good video!
Cool video
Got a sub from me. Went and watched some of your other videos and it's seems the music I'm this video overtakes your voice at time where in other videos it's fine. I'd like you to do next iver the 3do console and or the 32x addon
Funny enough, the 32x was my last console based video a few weeks back. Stay tuned for the 3DO! :)
@@ZygalStudios brill i will check it out and keep up the good work
Jag-wire.
Why do you keep calling it jag wire?
Because I'm an idiot. You didn't pick up on that? 🤣
I’ve never heard the word Jaguar butchered so mercilessly. I’m wondering how this host reads: Studio (“Sss - tu-di-oh!”).
Wonder no longer! The 9th word in the video is Studios 🤣😅
Good content
0:42 The PS3 didn't revolutionize jack shit... CELL and its SPU's was a COMPLETE and utter technological dead-end, with next to no relevance for how games would be coded post-PS3 and added very little to what could be achieved at the time for a MASSIVE increase in programming difficulty. The Xbox 360 with its 3x symmetrical cores w/ SMT was far, FAAAAAAR more representative of the future of CPU's in game consoles & development.
Wow, did a PS3 hurt you in the past? 😬
@@ZygalStudios No, it had some great games, but that statement you made is absolute garbage on a pure technological history front. Even for HPC, which is what the chip was actually designed for, GPGPU made the CELL look like the backwards dead-end it was before the time it even released in volume... (Nvidia Tesla came out basically dead-on w/ CELL). CELL was nothing more than a GARGANTUAN waste of money (SOOOOO much money... O_O) going down the same vector processing rabbit-hole Sony had been obsessed with since the PS2. Wanna know what does vector processing these days? Not bizarre, anti-programmer CPU + VPU hybrids. GPU's. Lots and lots of GPU's.
@@Cooe. I appreciate the history lesson
The Jaguar would be hard to develop for if you were using an IBM PC clone system and not an Atari TT030.
I love my jag. But I know the jag had much more potential!!! It could have lasted longer. To Brian e.... Do you think the same?
Liked the video but.... jag wire ? Surely jag you are
Check the latest video on the 32x :)
That's how I pronounce it now moving forward.
Jagwire?
Sorry, the background music is too loud and your voice too quiet.
:-(
Regardless of their success the PS2 still seems like the most challenging and worst system to develop for
The games sucked for Atari Jaguar, they usually seemed like something you would expect on a previous generation system
Shovelware from previous systems that didn't take advantage of the new hardware. The CD³² had similar issues.
so the 6800 from the 80's was old already and obsolete
The MC6800 from 1974 was the precursor to the 68k. The 6800 was an 8-bit processor and wasn't used a ton after the release of the 68k.
The 68k at this time was about 15 years old, but far from obsolete. I think versions of the 68k were sold well into the 2000's even after Motorola's semiconductor business formed two separate spinoff companies, ON and Freescale.
Funny enough, at my embedded systems job, I've actually used a Coldfire Freescale microcontroller and guess what architecture that uses? :) a modified version of the good old 68k. So remnants of it are still around to this day. But in this application, it was strictly to be used as a manager and for controller I/O. It wasn't designed to be the main driver of game logic for this architecture.