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?)
Alien vs. Predator and SkyHammer are excellent proof of what could have been. Apparently some programmers/developers/game designers knew what to do. Battlemorph and Hoverstrike also...did I miss anything?
Love the initial intro that the Jaguar had good hardware, but really was hell for developers from different angles. As a hardware enthusiast I've had to learn the hard way how important it is to properly document your stuff and make it as accessible as possible if you want people to use your stuff.
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.
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.
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 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.
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.
@@ZygalStudios Good point. This is the type of stuff we looked at in an embedded systems MSc, and that was hosted by the department of engineering. I took a CS BSc at the same University and nothing like this was covered. Excellent video btw!
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.
Still hoping one day you will show us what this system is capable of, no one has a clue, they just argue about it, or walk away because of Atari Age and Reboot drama.
We have a clue . Modern audio libraries are 4 times faster the the original. Towers got 10% faster. Doom and Kart run fluently. I Wonder if fight4life could reach 60fps (now 30). But then again, so many fighting games on the Jaguar already.. A racing game with nice scenery is missing. Like need for speed or outrun. I would even trade in a flat shaded street.
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.
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.
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!!
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.
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.
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 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.👍
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.
cannot argue with you on this one.... but it would be nice to see someone master the coding for the thing and release something to show what could have been, No one has or will me thinks.
@@Tolbathow can you show off a system where half of the circuit is only useful in 2d and half is only useful in 3d? PlayStation and 3do went full framebuffer even for isometric scrolling games.
Another thing worth mentioning is that the object processor needs a new object list every frame (50/60 Hz). So unless you buffer the list, fix the old one or create a new one, you end up with a corrupted list which will likely crash the OP. All of that requires other processors (68k, Tom or Jerry) to fix up a list. That CPU time could have been used otherwise. Also depending on how your object list is organized, performance can vary quite a bit. Not only the GPU/DSP have bugs. The blitter can be tricky to use. You need a processor to tell it what to do as well. There are so many other fun things to look out for. :) That being said, many consoles at the time had their peculiarities.
The object list had to be rebuilt every frame as it modified parts of it when processing objects. Chances are it would not corrupt the list but the objects Data and Height would get updated - so next time around it would be 0 pixels high - thus nothing to display
Let's not forget, if you really want the OPL to pump out lots of objects, you are going to want to not only rebuild but re-order your list as well as properly ordered objects in the list which will help speed things up. A nice 8k cache on the blitter to traverse would take a load off the GPU/68k drawing things. Much less intervention from the external processors would be needed. Two slope update registers would have been nice so a complete polygon could be draw in one setup from the GPU instead of one per each line of the polygon. that was supposedly corrected on Jag II's Blitter as well as adding trip drawing with light and shading in one command.
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.
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.
4 ปีที่แล้ว +7
Makes you wonder why they stuck a 68k in there instead of a PowerPC or a MIPS like the Cojag arcade board used
My guess is cost. One of the major things that the project was marketed towards Sega as was the cost. The other two processors (Tom and Jerry), were also Motorola chips. If they purchased an older 68000 along with the other two custom chips, they'd be able to save a large amount of cost due to volume. Plus, the 68k was a pretty well known system at the time, so they'd be able to market it that way to developers.
@@maroon9273 Motorola wasn't keen on mass producing the 68k20 or 68k30 for the cheap price needed for the Jaguar or even other Atari desktops computers. That would have ruined their lucrative workstation and server markets. I don't know if they even could produce it that cheap, but these cpu's would made more possible for the Jaguar and it would have been hold back the customn chips less. Hell... it was designed for the 68k20. I still get annoyed by people calling it the general purpose processor. It was the central processing unit which limited so many things like the total amount of memory in the cartridge, the limited complexicity of the development tools (because of the lack of memory management) and efficient control of the customn chips to name a few. Basically at that time Atari hadn't the creditibillity anymore to get big company's like Motorola really backing them up and not the capital to do stuff without them.
@@erikkarsies4851 lowest cost 68k20 was the ec which is a cut down version of the CPU. I don't how much it cost during the development of the jaguar hardware.
@@ZygalStudios cost and as John Maitheson explained, they wanted to put something in there that people were familiar with. Atari were keen to use a 68K family device, and we looked closely at various members. We did actually build a couple of 68030 versions of the early beta developers systems, and for a while were going to use a 68020. However, this turned out too expensive. We also considered the possibility of no [Motorola 680x0 chip] at all. I always felt it was important to have some normal processor, to give developers a warm feeling when they start. The 68K is inexpensive and does that job well. - John Mathieson
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.
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.
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?
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!
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!
Just ran onto Your channel. I bought my first Jaguar in 1995, when it was on its way out. Bought the CD add on also. Still love both of them. Thanks for taking me back to my late teens early 20s. I subscribed. Thanks 😊!
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!
Great video I love this series!! All those great chips and devs just went for the familiar 6800 I guess that was Atari fault. It explains why so many Jaguar games didn't look 64 hell even 32 bit
Thank you! And yes, exactly! The architecture was phenomenal, but the manpower behind the design was small and the time was short. With more developers on the system, no doubt it would have done better. And yes, it definitely had an effect on the games. :)
Like the Falcon, the Jaguar hasn't fullfilled its destiny. Hell even A1200 didn't show anything new or better than the A500. Developers probably jumped ship to PC
I remember Sam Tramiel saying "if the programmers aren't smart enough to figure out how to program for our machine we don't want them making games". That attitude didn't work to well....
90% of videogame devs aren't much better than amateur programmers. We all showed pity over how hard it was to make games for the ps3 and now we have 100gb call of duty games.
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 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
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.
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.
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.
This is easily one of the best Jaguar related videos I've seen on TH-cam to date. Thank you so much for all the insights and facts rather then the usual folklore stories out there. Followed
Thanks for the feedback! No problem, it was a good time learning about it. I don't like engineering by storytelling, so being able to review this documentation, I prepared myself as if I was actually going to be writing a production game on it before I made this video. Comments like this are why I'm continuing to make video game hardware architecture videos, so thank you! No folklore here :)
I guess Atari much like Sega with the Saturn approached it as arcade developers where the boards were often cutting edge, expensive and modular ie separate systems joined together. It took Sony entering without this pattern of working to apply corporate minimal viable product to it. Sega tried to make the Saturn great at absolutely everything, Sony said just make it do 3d simply. Sadly this corporate mentality has homegenised all consoles to be near identical, basically scaled down pcs. I miss the old days where systems had a character of their own, the Saturn with its quad polygons, the ps1 with its quirky integer use, the n64 with its muddy anti-aliasing. While hardware is arguably much better these days as you'd expect you only have to go the gamestore app on the device to realise it is 95% crap and 99% identical across the 3 big systems.
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
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.
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.
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.
Ive Heard that jaguar is still using 16bit cpu and only GPU and sound processor are 32bit(combine with 64bit bus memory) That sound like combine rtx GPU with Intel atom cpu. Also they said, cpu do nothing only give command to GPU and sound processor. All process are done by GPU and sound processor. Sound like science fiction to me.
One of the main processors is also supposed to be the main CPU and its 32bit with some 64bit processors most devs used the 16bit Motorolla 68000 as the main CPU as it was easier to work with.
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.
Hey Jefferson, So unfortunately no. The hardware itself had faults in the processor design and the UART hardware did too. This is cast into the dies and cannot be changed unless you physically rework and redesign the board.
These complicated hardware is why Doom in Jaguar can't have music in the actual level. Instead you either get sounds with better graphics or you have audio but only in fix screen such as the title and result screen only.
did you check the ROM-hack which corrects this? Does it slow down Doom? Doom crams some game logic and engine stuff together with the wavetable code into the tiny 8 kB of the DSP.
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.
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.
@@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.
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.
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.
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. :)
Excellent video, that really was a deep dive! Tell me, are these kind of flaws/bugs present in other systems too or is the Jaguar just bad for these? Cheers!
There is no system without 'errata', hardware bugs that have been documented and just remain unfixed. Every PC has several thousand of these bugs, with corresponding workarounds in the system software and drivers - the workaround doesn't mean the hardware needs to be detected explicitly, nor do the workarounds usually limit performance, but the errata impose a particular order of doing things. On modern systems, these plentiful errata are low severity and are well hidden by the thicc system software, so on the application side, you don't need to be aware of them. PS2 has a few notorious errata, like WHO IN THEIR RIGHT MIND designed the interlacing flicker filter as 1:1 instead of 1:2:1? This is just so useless, makes for a jumpy and blurry image, so games didn't even bother using it. There is something wrong with edge rule on PS1 and MIP selection rules on many systems, and you can trip out the graphics chips in most systems a little bit when approaching numerical limits even when at a glance it looks like you might have some latitude. Odd little bits of weirdness. And of course peripheral device weirdness is pretty much expected, but nothing particularly detrimental, like there is a way of doing what you need to do, and robustly. However there's exactly a reason nobody, and i mean absolutely nobody, in their right mind, designs the high complexity main programmable processors themselves if they can help it. License existing logic. Leave it to a company who has a lineup of CPUs or DSPs already going and have them make at most minor alterations. Like one of the main things you do is assess risks, and try to make utter engineering fiasco as unlikely as possible. Jaguar went with self-designed chips which are de facto the main processors of the system. Jaguar brings the bugginess to a completely unprecedented and absurd level. It's right on the knife's edge where if it was just a tiny bit buggier, it couldn't have booted at all, and honestly no other company, not even Atari in a better functioning state, could have deemed the Jag even as it stands now releasable. You don't generally find errata which make the system borderline useless or eat up pretty much all of its performance. Of course design fitness varies - many systems don't reach as much performance in real uses as they seem to on paper, but then that's just generally due to almost inevitable compromises or the fundamental uncertainty as to what the actual usage of the system will be like. Microcontrollers, CPUs and DSPs that you can buy for your product or project actually all come with errata sheets in the documentation, and even comparatively simple ones have quite extensive ones, and you really need to consider errata in the system design, as some of them can be limiting as to how you design the system, some of them can actually hurt. And their designers actually know what they're doing and they have iterations upon iterations under the belt, so to an extent this is inevitable. But it's a million times better you design against errata that you know, than against ones you don't.
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.
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.
@@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.
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.
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: th-cam.com/video/iEQLbbyToxw/w-d-xo.html
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.
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?
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
Except that the Saturn didn't have buggy hardware.
“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?)
Alien vs. Predator and SkyHammer are excellent proof of what could have been. Apparently some programmers/developers/game designers knew what to do. Battlemorph and Hoverstrike also...did I miss anything?
I would love to see a major game company create a good game for the jaguar hardware.
Love the initial intro that the Jaguar had good hardware, but really was hell for developers from different angles. As a hardware enthusiast I've had to learn the hard way how important it is to properly document your stuff and make it as accessible as possible if you want people to use your stuff.
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
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.
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've always wanted to know how the Jaguar was put together and why it was so hard to develop for
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.
"So I decided to add it to the stack"
...I see what you did there.
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.
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.
"jagwire" eh, oh boy
JAG-U-ARE ;)
@@ZygalStudios It sounds like "Jag-u-wire" in the video. Thanks for the video though!
I think the country that won both world wars gets to dictate the English language
@@ZygalStudios JAG-U(Short U)- R
This should be a project for CS students, would be better than my CS Architecture classes back two decades.
Funny, because my degree is in Electrical Engineering:)
CS students don't typically like hardware stuff.
@@ZygalStudios Good point. This is the type of stuff we looked at in an embedded systems MSc, and that was hosted by the department of engineering. I took a CS BSc at the same University and nothing like this was covered. Excellent video btw!
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.
That was really interesting! Loved how you explained how the Jaguar works and how objective you were in your commentary! Nicely done!
Still hoping one day you will show us what this system is capable of, no one has a clue, they just argue about it, or walk away because of Atari Age and Reboot drama.
We have a clue . Modern audio libraries are 4 times faster the the original. Towers got 10% faster. Doom and Kart run fluently. I Wonder if fight4life could reach 60fps (now 30). But then again, so many fighting games on the Jaguar already..
A racing game with nice scenery is missing. Like need for speed or outrun. I would even trade in a flat shaded street.
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.
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.
Black Ice/White Noise held the highest promise IMO. Could have been grandbreaking for its time, GTA3 before GTA3.
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.
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.
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.
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 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.👍
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.
Atari Jaguar was awesome
To quote scotty from star trek 3 "the more they overthink the plumbing the easier it is to stuff up the drain"
cannot argue with you on this one.... but it would be nice to see someone master the coding for the thing and release something to show what could have been, No one has or will me thinks.
@@Tolbathow can you show off a system where half of the circuit is only useful in 2d and half is only useful in 3d? PlayStation and 3do went full framebuffer even for isometric scrolling games.
Another thing worth mentioning is that the object processor needs a new object list every frame (50/60 Hz). So unless you buffer the list, fix the old one or create a new one, you end up with a corrupted list which will likely crash the OP. All of that requires other processors (68k, Tom or Jerry) to fix up a list. That CPU time could have been used otherwise. Also depending on how your object list is organized, performance can vary quite a bit. Not only the GPU/DSP have bugs. The blitter can be tricky to use. You need a processor to tell it what to do as well. There are so many other fun things to look out for. :) That being said, many consoles at the time had their peculiarities.
Yikes, sounds like a fun challenge though! :)
The object list had to be rebuilt every frame as it modified parts of it when processing objects. Chances are it would not corrupt the list but the objects Data and Height would get updated - so next time around it would be 0 pixels high - thus nothing to display
Let's not forget, if you really want the OPL to pump out lots of objects, you are going to want to not only rebuild but re-order your list as well as properly ordered objects in the list which will help speed things up. A nice 8k cache on the blitter to traverse would take a load off the GPU/68k drawing things. Much less intervention from the external processors would be needed. Two slope update registers would have been nice so a complete polygon could be draw in one setup from the GPU instead of one per each line of the polygon. that was supposedly corrected on Jag II's Blitter as well as adding trip drawing with light and shading in one command.
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.
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.
Makes you wonder why they stuck a 68k in there instead of a PowerPC or a MIPS like the Cojag arcade board used
My guess is cost. One of the major things that the project was marketed towards Sega as was the cost. The other two processors (Tom and Jerry), were also Motorola chips. If they purchased an older 68000 along with the other two custom chips, they'd be able to save a large amount of cost due to volume. Plus, the 68k was a pretty well known system at the time, so they'd be able to market it that way to developers.
@@ZygalStudios the m68k20 would have been better and work well with Jag coprocessor than the 68k.
@@maroon9273 Motorola wasn't keen on mass producing the 68k20 or 68k30 for the cheap price needed for the Jaguar or even other Atari desktops computers. That would have ruined their lucrative workstation and server markets. I don't know if they even could produce it that cheap, but these cpu's would made more possible for the Jaguar and it would have been hold back the customn chips less. Hell... it was designed for the 68k20. I still get annoyed by people calling it the general purpose processor. It was the central processing unit which limited so many things like the total amount of memory in the cartridge, the limited complexicity of the development tools (because of the lack of memory management) and efficient control of the customn chips to name a few.
Basically at that time Atari hadn't the creditibillity anymore to get big company's like Motorola really backing them up and not the capital to do stuff without them.
@@erikkarsies4851 lowest cost 68k20 was the ec which is a cut down version of the CPU. I don't how much it cost during the development of the jaguar hardware.
@@ZygalStudios cost and as John Maitheson explained, they wanted to put something in there that people were familiar with.
Atari were keen to use a 68K family device, and we looked closely at various members. We did actually build a couple of 68030 versions of the early beta developers systems, and for a while were going to use a 68020. However, this turned out too expensive. We also considered the possibility of no [Motorola 680x0 chip] at all. I always felt it was important to have some normal processor, to give developers a warm feeling when they start.
The 68K is inexpensive and does that job well.
- John Mathieson
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.
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.
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.
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!
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!
Just ran onto Your channel. I bought my first Jaguar in 1995, when it was on its way out. Bought the CD add on also. Still love both of them. Thanks for taking me back to my late teens early 20s. I subscribed. Thanks 😊!
Thank YOU for coming by! :)
Welcome!
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!
Great video I love this series!! All those great chips and devs just went for the familiar 6800 I guess that was Atari fault. It explains why so many Jaguar games didn't look 64 hell even 32 bit
Thank you! And yes, exactly!
The architecture was phenomenal, but the manpower behind the design was small and the time was short. With more developers on the system, no doubt it would have done better. And yes, it definitely had an effect on the games. :)
I read somewhere back in the day the 68k was chosen to give developers a warm feeling when taking it on. I still love my Jaguar.
Like the Falcon, the Jaguar hasn't fullfilled its destiny. Hell even A1200 didn't show anything new or better than the A500. Developers probably jumped ship to PC
@so if by accelerated you mean some vampire, then yes
One bug here, one bug there, one bug for everyone everywhere... Bugmambo no 6 :D
I remember Sam Tramiel saying "if the programmers aren't smart enough to figure out how to program for our machine we don't want them making games". That attitude didn't work to well....
90% of videogame devs aren't much better than amateur programmers. We all showed pity over how hard it was to make games for the ps3 and now we have 100gb call of duty games.
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.
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.
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
Where did you learn to fly?
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.
Holy Crap ! I had no idea this system was so complicated !
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.
Zygal my friend, we are still waiting on you to make a Jaguar game sir.
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.
This is easily one of the best Jaguar related videos I've seen on TH-cam to date. Thank you so much for all the insights and facts rather then the usual folklore stories out there. Followed
Thanks for the feedback!
No problem, it was a good time learning about it.
I don't like engineering by storytelling, so being able to review this documentation, I prepared myself as if I was actually going to be writing a production game on it before I made this video.
Comments like this are why I'm continuing to make video game hardware architecture videos, so thank you! No folklore here :)
Looks like Jag went from from a headache to a full blown migrane.
I miss these times of unique custom hardware, nowadays its all the same.
I guess Atari much like Sega with the Saturn approached it as arcade developers where the boards were often cutting edge, expensive and modular ie separate systems joined together. It took Sony entering without this pattern of working to apply corporate minimal viable product to it. Sega tried to make the Saturn great at absolutely everything, Sony said just make it do 3d simply. Sadly this corporate mentality has homegenised all consoles to be near identical, basically scaled down pcs. I miss the old days where systems had a character of their own, the Saturn with its quad polygons, the ps1 with its quirky integer use, the n64 with its muddy anti-aliasing. While hardware is arguably much better these days as you'd expect you only have to go the gamestore app on the device to realise it is 95% crap and 99% identical across the 3 big systems.
To be fair, the ps2 was very difficult to code on but once people got used to it, it really shined.
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.
Trying to make a game for this thing seems a lot like Sully following you in the parking garage. From here it looks like a nightmare.
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.
Most games just ran on the 68000 which is why many games looked 16 bit because it was.
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
Great video! Background music was a bit too loud but awesome content!
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.
Ive Heard that jaguar is still using 16bit cpu and only GPU and sound processor are 32bit(combine with 64bit bus memory)
That sound like combine rtx GPU with Intel atom cpu.
Also they said, cpu do nothing only give command to GPU and sound processor. All process are done by GPU and sound processor. Sound like science fiction to me.
One of the main processors is also supposed to be the main CPU and its 32bit with some 64bit processors most devs used the 16bit Motorolla 68000 as the main CPU as it was easier to work with.
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.
Great video, I remember this console well from my youth. Question, could the hardware bugs of been corrected with a BIOS patch?
Hey Jefferson,
So unfortunately no. The hardware itself had faults in the processor design and the UART hardware did too.
This is cast into the dies and cannot be changed unless you physically rework and redesign the board.
Is funny how everyone is focusing on your way to say GaeWare but i appreciate the entire video
Lol hey it's fair game 🤣
Thank you for the support!
These complicated hardware is why Doom in Jaguar can't have music in the actual level. Instead you either get sounds with better graphics or you have audio but only in fix screen such as the title and result screen only.
did you check the ROM-hack which corrects this? Does it slow down Doom? Doom crams some game logic and engine stuff together with the wavetable code into the tiny 8 kB of the DSP.
Ahh yes, so you have a very in depth understanding of this, what would it take to make a clone console of this system?
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.
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.
Angry dachshund? Now you're speaking my language!
The music is loud enough to drown out your otherwise perfect explanation.
This is the only console whose rights were released to the public, no one has taken advantage of this.
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.
What a neat series!
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.
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.
Sooo just use the 68000 and Nevermind tom and jerry
When did the JAG-WIRE come out? I only ever heard of the Jaguar? 🤣🤣🤣
Oh you didn't hear, it came out last year 🤣🤣
Love your channel...please do the atomiswave...or the neo geo pocket...thx
Thank you!!!
Planning on doing both :)
Thanks for stopping by!
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!
Excellent video, that really was a deep dive! Tell me, are these kind of flaws/bugs present in other systems too or is the Jaguar just bad for these? Cheers!
There is no system without 'errata', hardware bugs that have been documented and just remain unfixed. Every PC has several thousand of these bugs, with corresponding workarounds in the system software and drivers - the workaround doesn't mean the hardware needs to be detected explicitly, nor do the workarounds usually limit performance, but the errata impose a particular order of doing things. On modern systems, these plentiful errata are low severity and are well hidden by the thicc system software, so on the application side, you don't need to be aware of them.
PS2 has a few notorious errata, like WHO IN THEIR RIGHT MIND designed the interlacing flicker filter as 1:1 instead of 1:2:1? This is just so useless, makes for a jumpy and blurry image, so games didn't even bother using it. There is something wrong with edge rule on PS1 and MIP selection rules on many systems, and you can trip out the graphics chips in most systems a little bit when approaching numerical limits even when at a glance it looks like you might have some latitude. Odd little bits of weirdness. And of course peripheral device weirdness is pretty much expected, but nothing particularly detrimental, like there is a way of doing what you need to do, and robustly.
However there's exactly a reason nobody, and i mean absolutely nobody, in their right mind, designs the high complexity main programmable processors themselves if they can help it. License existing logic. Leave it to a company who has a lineup of CPUs or DSPs already going and have them make at most minor alterations. Like one of the main things you do is assess risks, and try to make utter engineering fiasco as unlikely as possible. Jaguar went with self-designed chips which are de facto the main processors of the system.
Jaguar brings the bugginess to a completely unprecedented and absurd level. It's right on the knife's edge where if it was just a tiny bit buggier, it couldn't have booted at all, and honestly no other company, not even Atari in a better functioning state, could have deemed the Jag even as it stands now releasable. You don't generally find errata which make the system borderline useless or eat up pretty much all of its performance. Of course design fitness varies - many systems don't reach as much performance in real uses as they seem to on paper, but then that's just generally due to almost inevitable compromises or the fundamental uncertainty as to what the actual usage of the system will be like.
Microcontrollers, CPUs and DSPs that you can buy for your product or project actually all come with errata sheets in the documentation, and even comparatively simple ones have quite extensive ones, and you really need to consider errata in the system design, as some of them can be limiting as to how you design the system, some of them can actually hurt. And their designers actually know what they're doing and they have iterations upon iterations under the belt, so to an extent this is inevitable. But it's a million times better you design against errata that you know, than against ones you don't.
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?
Please do a video on the NUON system.
At cost jack trammel ears kicked up their probably how he fell for it.
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.
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
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.
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
The biggest bug on the Atari Jaguar? All the experts I've heard pronounce the Atari Jaguar "The Atari JagWIRE"...lol
Is the jaguar graphically better than the game boy Advance?
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: th-cam.com/video/iEQLbbyToxw/w-d-xo.html
Yes!! Absolutely!
Thanks for your feedback :)
I love gamehut and coding secrets btw, pretty awesome.
poor further ado he never gets to go any where
This one took me a good minute to understand 🤣🤣 I love this.
Good one!
THE MUSIC IS TOO LOUD
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.
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?
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.