The Jag is without question a 64 bit machine, but this does not mean that it has to be more powerful than the newer 32 bit systems, as these have much more hardware support for 3D graphics and specialized RAM areas for video and sound generation to speed up data throughput. Marc Rosocha Eclipse (Iron Soldier 1+2)
It’s not even more powerful than older 32 bit systems like Saturn and PSX. Hell look at the new Doom 32x resurrection. Destroys the Jaguar doom. I like the Jaguar but I have yet to see anything except a better color palette then 16 bit systems
@@WhitePointerGaming One thing i always wonder is what makes the PC Engines´s TG16 ppu 16 bit? If PPU´s or Display Processors have a "bitness" then, how many bits is the Nes PPU, the SNES PPU or the Genesis/MD VDP?
@@jsr734 Probably the easiest way for a layman to deduce the "bitness" of a console's GPU is to look at the color specs. 8-bits can encode 256 numbers. So if a console renders more than 256 colors at a time or if it has a palette that is more than 256 colors than it's probably 16-bit. 16-bits can encode 65,536 numbers, so if a console renders more than 65,536 colors or has a palette that is more than 65,536 colors, than it's probably 32-bit. So we can use that to deduce the following (the color numbers may be off, but should be accurate enough for this excersise): The NES is limited to 56 colors, so it's 8-bit. The SNES is limited to 256 colors on screen, from a palette of 32,768, so it's 16-bit. The Genesis has an on screen limit of 96 colors from a palette of 4096, making it 16-bit. The TG16 can display 482 colors from a 512 color palette, so it's also 16-bits.
The 64-bit was more marketing than anything else. Few people realize that the Mattel Intellivision (1979) was actually a 16-bit console. Likewise, the Sinclair QL and the Commodore Amiga were both 16-bit computers yet had widely different graphic capabilities. As far as the reasons why most developers overused the 68000 instead of using Tom & Jerry, I can see a few. First of all, they were probably given limited amount of time to port games to the Jaguar. Second, the Jaguar may have been considered a B-tier platform as Atari wasn't the 800-lb gorilla it used to be, so the goal was to port a game but not spent much more time making it really better. Last but not least, it seems like the SDK was barebone. According to Leonard Tramiel they came up with an assembly dev kit over a weekend, and the decision was made to release it as is. If Atari had released a C dev kit with many examples showcasing what can be done with the Tom and Jerry, third party developers may have been more likely to make games which took advantage of the hardware.
My personal take: Bits are a stupid way to measure console/computer power in the first place. They kind of lined up with actual capabilities in the 8bit and 16bit era, but that was more of a coincidence than anything else. 16bit CPUs happened to be paired with more powerful graphics chips simply because transistors were now cheaper. The turbografx-16 is a great example, it's an 8bit CPU paired with a way more powerful graphics chips than any other 8bit console/computer.
I think that the 64bits were the elegant way before SDRAM. See how buggy the Jaguar is already. Now imagine if they had tried to max out the capabilities of the transistors. Instead they saw: pins are cheap, pcb is cheap. Let’s use a dumb 68k bus logic, but 4 times the lanes
I bought one of those at a garage sale for $15 and within a few months of that, I had accumulated around 20 or so games for it! It's not my favorite Atari, that would be the Atari 7800, but its still a neat console!
Calling this a 64 bit computer is like calling a modern computer 384 bit because it has a 4090 in it. Although it is a bit different since the GPU of a modern computer can be removed, whereas here the graphics processing is a fundamental part of the architecture. Really, we should call it what it is: a console with a 16 bit processor, two 32 bit processors, and two 64 bit processors. It's all three!
To me the answer is simple - A video game console can be characterized as true 64-bit if all components are 64-bit and that includes CPU's registers and data bus, RAM, memory controllers, and GPU/blitters. Processing, memory bandwidth, graphical processing, and sound processing operations must all utilize a 64-bit architecture. If those requirements are not met, the console becomes semi-64-bit at best. That isn't to say that bits are the deciding factor for quality. I couldn't care less a system is 64-bit if developers cannot fully harness its full power. Despite them not being 64-bit I would much rather take a preference on SNES and Genesis!
The N64 processes one pixel at a time. No pixel format on the N64 has 64 bits. Instruction words are 32 bit. No VLIW. And the Jaguar would have better fillrate per Watt if it also had a scalar pixel shader.
I don't know what to think anymore. The size of the CPU data bus was the standard for a while and why the Intellivision was technically the first 16-Bit system or how even though the 68000 CPU had 32-Bit internal registers it was still limited to a 16-bit data bus. I can't even really blame Atari, Sega or Nintendo because even the CPU manufacturers themselves bent the rules sometimes to suit their marketing needs like in the case of the WDC 65816 that's in the Super Nintendo. It's the same 6502 or 65C02 but with a 24-bit address bus, new instructions and expanded 16-bit registers but at the end of the day it still processes data 8-bits at a time. What I find fascinating and just found out recently too that while the N64 was a true MIPS 64-Bit CPU, every Nintendo console up until the Switch were still 32-Bit even including the more powerful Wii U. I digress but I think it's fair to call the Jaguar a 32-bit system or a 16/32 hybrid which the latter isn't a thing but it's best how I would describe it.
I now wonder how a shared bus could be used with low latency. The Jaguar already is a bit high on transistor count. With latency, all devices on the bus would need longer queues and bigger cache. So how fast can priority be resolved? For starters: every device on the bus needs its dedicated request line to something like the sprite priority resolver. CMOS gates are fast up to 4 inputs. So 3 devices could have direct resolution. Cascade for low priority . Some devices may want to reserve in the near future because they know their internal latency. But then again learned that transistors are much faster and clock edges have low jitter. And the bus is idle a lot of the time. All devices could run at a slight time delay. So there would only be one request per phase. Then the following requests have to wait and are sorted by priority. Still, thanks to a lot idling, most requests will be granted right away. Now one caveat is that the target device needs to be alerted in advance and checked if it has capacity in its input latch.
Due to bad dev kits and people being lazy we will never know what that Jaguar was capable of. The Homebrew community is obsessed with converting Amiga to the damn thing. It is embarrassing.
@@Tolbat MK1 was always intended for the console before it got cancelled. He's really doing Gods work porting it over now. I would also be interested to see if it would be possible to run Duke Nukem or Quake on the console if Tomb raider has finally been proven to be possible.
@@John-nb6ep We need some new coders like the guy doing the MK port to get obsessed with the Jag before we see real progress. The entire community uses the damn 68000 too much
You mean: utilise ? The great thing with 2d games was that the custom chips could synthesise the graphics using scanline rendering. Only a limited number of sprites were allowed. Hardware did the y sort in one scanline. Meanwhile the CPU could run the game logic for the next frame. With 3d you need to transform all vertices before you can sort by. For this reason the Nintendo DS has a special chip, which does this very fast once in a frame. Ah, weird. Wouldn’t the game logic stream on 68k in vertices and meshes? Then in a pipeline the GPU transforms them right away? Give the GPU special instructions for quicksort, which is now the bottleneck.
Games on consoles had to be written and designed on a home or office computer. I mean, the Jaguar, SNES, and Megadrive don't even have a keyboard, right? So one problem that the Jaguar had, was that many of the games were written and developed using 16-bit computers such as the Atari ST or Amiga. So how do make something look 64-bits if the graphics computer that was used to originally to design it's graphics was just 16-bit? You can't. The 64-bit tools just weren't there yet.
Not quite right. Consoles have what are called development kits, or "devkits". These have all the same hardware as a retail model, with some additional features such as extra memory, perhaps an internal hard drive, a port to connect it to a computer, and support for various debugging tools that make development easier. The code itself is still written on a computer, but it's compiled and then sent to the devkit to be executed, tested and debugged. In the Jaguar's case, it was a bit of an unusual setup. Instead of having a dedicated devkit as such, a retail console was modified with a special cartridge that had a large circuit board attached (called the "Alpine board") and the console itself had a custom ROM installed into it to make it work. It looked very weird, here's a picture: steemitimages.com/640x0/steemitimages.com/DQmYUXJ11SBYzmWXmfhZXyScsdGpPJjhbN6XkPwEci4oBtF/Atari-Jaguar-Development-Kit.jpg
@@dtester the better games used PCs with SVGA. A good number though I suppose used Amiga and Atari ST computers especially european developers who developed mostly for the Atari ST and Amiga computers. This is one reason why many of the Atari Jaguar games look closer to 16 bit Amiga and Atari games then a 32-bit or even 64-bit games system
Most textures on the PS1 only have 16 colors. Doom was ported from PC to Jaguar and really got better colors. Just Code up your 3d game on PC and get a nice fps increase on Jaguar.
3:09 Ehhhhhhhh.. "Yes", but that ignores the giant friggin white elephant in the room that you lose your speed advantage if the architecture is difficult to work with, which most certainly the Jaguar is. They should have just used 64-bit variants or commissioned them of the other two chips for the sake of ease of use. You can't just glue 32-bit CPUs together and call it 64-bit; if the OVERALL instruction set isn't 64-bit, then you've lost the plot.
That isn't at all what they did or how they got the 64bit number. Object Processor and Blitter have no spec rating and are what Carmack referred to as chips with no theoretical upper limit. This is because their speed and performance was dependant upon and only limited by the (64bit) bus and available memory. Unfortunately using the 68k choked the bus severely but was what most developers used for familiarity,, tools available and deadline considerations.
@@A31ChrisOkay, so I was being a bit hyperbolic there, however I was arguing FOR a unified instruction set, not five different ones essentially glued together in order to make a game console. Look at how they wrote music on the SNES (albeit unrelated) for how unwieldy that can become shipping whole programs as data to other processors can get.
It's a common misunderstanding that they got the 64-bit number by adding 32+32. As explained in the video there ARE indeed 64-bit components in the machine. I mean if they just added them together why didn't they say it was 64+64+32+32+16 = 208 bits? The question is whether the system as a whole can be considered 64-bit or not, based on the overall architecture. It was however overall too complicated to work with and the lack of proper developer tools didn't help matters.
@@WhitePointerGaming well considering especially back then there was no criteria for what officially determined system bitness and a 64bit ALU wouldn't have made much difference for what was needed then. And since impinging upon what Atari considered to be the 64bit aspects of the system(which can be seen in almost all commercial releases) has the most marked detriment in performance it seems reasonable to consider it a 64 bit system IMO.
@@WhitePointerGaming Which was partly the reason I was being a bit hyperbolic, lol. AVP may have been 64-bit(?), but it appears to run like a dog dragging its ass across the carpet, lmao. Granted that I haven't looked much into developing for the Jag, BUT it looks like you'd need the 64-bit code to be essentially data in the 32-bit ROM in order for TOM or Jerry to be able to use it. Or to link it together in a specific manner in order to get what they wanted to run on TOM and/or Jerry. From what I know about GNU AS/NASM, and that just sounds especially painful, lol.
Can you draw a 16 million color picture using a computer that only displays 256 colors? No you cant. One problem of the Atari Jaguar is that developers had to develop its games on PCs and Atari desktop computers which were only 16-bits at that time. So how do you make a 64-bit looking game if it was drawn and designed on a 16-bit computer?
As I explained in a reply to your other comment, there was a devkit available for the Jaguar, it was just kind of half baked and weird, requiring a modification of a retail console and a strange cartridge with a huge circuit board sticking out of it called the "Alpine board". The code was written on a computer, but it was executed, tested and debugged on Jaguar hardware.
@@WhitePointerGaming yes this was my point too. You mentioned that the code had to be written on a different computer and then it was tested on a Jaguar Dev kit. This is my point exactly! The computer used for coding and designing the game graphics were not made on the Jaguar Dev kits, they were merely tested and debugged on the Dev kits. Coding and graphics designs had to be done on a computer such as an Atari ST, or an Amiga which are both 16-bit computers. So it is difficult for devs to take full advantage of the 64-bit power of the Jaguar if their development tools (which would have been an Atari ST or an Amiga) was just 16-bit.
@@WhitePointerGaming btw, I'm sorry for sending 2 almost identical comments. I didn't mean to spam your comments. I thought I watched the videos separately and I actually thought I watched 2 videos on the same topic instead of just watching 1 video twice. Anyway, it just shows how much I enjoyed your video.
The code for every game is first written on a computer then executed, tested and debugged on a devkit. That's how all console game development works. That's not unique to the Jaguar. All console games are made that way. It doesn't really matter what the specs of the computer are that's being used to write the code, because you're executing it on the devkit hardware.
There was this well know .TGA file format. I thought that it was invented by a PC graphic card manufacturer for true color graphics. Where did Philips CDi , Kodak photoCD and all the DVD manufacturers get their videoDACs from? I saw a demo with interesting dithering. Palette was divided into 3 parts each of which provided fine control (6bit). of one of the color channels. Then consider that photoshop and deluxe paint often ram on 800x600 CRTs and you could zoom in.
The Jag is without question a 64 bit machine, but this does not
mean that it has to be more powerful than the newer 32 bit systems, as
these have much more hardware support for 3D graphics and specialized
RAM areas for video and sound generation to speed up data throughput.
Marc Rosocha Eclipse (Iron Soldier 1+2)
It’s not even more powerful than older 32 bit systems like Saturn and PSX. Hell look at the new Doom 32x resurrection. Destroys the Jaguar doom. I like the Jaguar but I have yet to see anything except a better color palette then 16 bit systems
@phonedork The Jaguar released before the Saturn and PSX.
@@WhitePointerGaming One thing i always wonder is what makes the PC Engines´s TG16 ppu 16 bit? If PPU´s or Display Processors have a "bitness" then, how many bits is the Nes PPU, the SNES PPU or the Genesis/MD VDP?
@@jsr734 Probably the easiest way for a layman to deduce the "bitness" of a console's GPU is to look at the color specs. 8-bits can encode 256 numbers. So if a console renders more than 256 colors at a time or if it has a palette that is more than 256 colors than it's probably 16-bit. 16-bits can encode 65,536 numbers, so if a console renders more than 65,536 colors or has a palette that is more than 65,536 colors, than it's probably 32-bit. So we can use that to deduce the following (the color numbers may be off, but should be accurate enough for this excersise): The NES is limited to 56 colors, so it's 8-bit. The SNES is limited to 256 colors on screen, from a palette of 32,768, so it's 16-bit. The Genesis has an on screen limit of 96 colors from a palette of 4096, making it 16-bit. The TG16 can display 482 colors from a 512 color palette, so it's also 16-bits.
@@truesus1718or just look on the PCB: two 8 Bit SRAM Chips sit on a common address bus. For video RAM.
The 64-bit was more marketing than anything else. Few people realize that the Mattel Intellivision (1979) was actually a 16-bit console. Likewise, the Sinclair QL and the Commodore Amiga were both 16-bit computers yet had widely different graphic capabilities.
As far as the reasons why most developers overused the 68000 instead of using Tom & Jerry, I can see a few. First of all, they were probably given limited amount of time to port games to the Jaguar. Second, the Jaguar may have been considered a B-tier platform as Atari wasn't the 800-lb gorilla it used to be, so the goal was to port a game but not spent much more time making it really better. Last but not least, it seems like the SDK was barebone. According to Leonard Tramiel they came up with an assembly dev kit over a weekend, and the decision was made to release it as is. If Atari had released a C dev kit with many examples showcasing what can be done with the Tom and Jerry, third party developers may have been more likely to make games which took advantage of the hardware.
My personal take: Bits are a stupid way to measure console/computer power in the first place.
They kind of lined up with actual capabilities in the 8bit and 16bit era, but that was more of a coincidence than anything else. 16bit CPUs happened to be paired with more powerful graphics chips simply because transistors were now cheaper. The turbografx-16 is a great example, it's an 8bit CPU paired with a way more powerful graphics chips than any other 8bit console/computer.
Neo Geo was 16bit and beat the 32bit PS1 at 2D
@@Jim-i2ybecause neo geo uses cartridges like N64.
I think that the 64bits were the elegant way before SDRAM. See how buggy the Jaguar is already. Now imagine if they had tried to max out the capabilities of the transistors. Instead they saw: pins are cheap, pcb is cheap. Let’s use a dumb 68k bus logic, but 4 times the lanes
I bought one of those at a garage sale for $15 and within a few months of that, I had accumulated around 20 or so games for it! It's not my favorite Atari, that would be the Atari 7800, but its still a neat console!
Calling this a 64 bit computer is like calling a modern computer 384 bit because it has a 4090 in it.
Although it is a bit different since the GPU of a modern computer can be removed, whereas here the graphics processing is a fundamental part of the architecture.
Really, we should call it what it is: a console with a 16 bit processor, two 32 bit processors, and two 64 bit processors. It's all three!
And then the nearest marketing guy will go, "OK, well, I am going to use the big number and you can't stop me!"
I used to want a Jaguar. Boy I was a dumb kid, lol.
I took one look at the controller and decided that I wanted a 3DO instead...
Don't be so hard on yourself. You did the math!
"Well yes, but actually no."
To me the answer is simple - A video game console can be characterized as true 64-bit if all components are 64-bit and that includes
CPU's registers and data bus, RAM, memory controllers, and GPU/blitters. Processing, memory bandwidth, graphical processing, and sound processing operations must all utilize a 64-bit architecture. If those requirements are not met, the console becomes semi-64-bit at best. That isn't to say that bits are the deciding factor for quality.
I couldn't care less a system is 64-bit if developers cannot fully harness its full power. Despite them not being 64-bit I would much rather take a preference on SNES and Genesis!
The N64 processes one pixel at a time. No pixel format on the N64 has 64 bits. Instruction words are 32 bit. No VLIW. And the Jaguar would have better fillrate per Watt if it also had a scalar pixel shader.
I don't know what to think anymore. The size of the CPU data bus was the standard for a while and why the Intellivision was technically the first 16-Bit system or how even though the 68000 CPU had 32-Bit internal registers it was still limited to a 16-bit data bus. I can't even really blame Atari, Sega or Nintendo because even the CPU manufacturers themselves bent the rules sometimes to suit their marketing needs like in the case of the WDC 65816 that's in the Super Nintendo. It's the same 6502 or 65C02 but with a 24-bit address bus, new instructions and expanded 16-bit registers but at the end of the day it still processes data 8-bits at a time. What I find fascinating and just found out recently too that while the N64 was a true MIPS 64-Bit CPU, every Nintendo console up until the Switch were still 32-Bit even including the more powerful Wii U. I digress but I think it's fair to call the Jaguar a 32-bit system or a 16/32 hybrid which the latter isn't a thing but it's best how I would describe it.
The Intellivision actually had a 16-bit CP1610 microprocessor.
I now wonder how a shared bus could be used with low latency. The Jaguar already is a bit high on transistor count. With latency, all devices on the bus would need longer queues and bigger cache. So how fast can priority be resolved? For starters: every device on the bus needs its dedicated request line to something like the sprite priority resolver. CMOS gates are fast up to 4 inputs. So 3 devices could have direct resolution. Cascade for low priority . Some devices may want to reserve in the near future because they know their internal latency.
But then again learned that transistors are much faster and clock edges have low jitter. And the bus is idle a lot of the time. All devices could run at a slight time delay. So there would only be one request per phase. Then the following requests have to wait and are sorted by priority. Still, thanks to a lot idling, most requests will be granted right away. Now one caveat is that the target device needs to be alerted in advance and checked if it has capacity in its input latch.
Due to bad dev kits and people being lazy we will never know what that Jaguar was capable of. The Homebrew community is obsessed with converting Amiga to the damn thing. It is embarrassing.
Someone is working on Tomb Raider at least.
@@John-nb6ep and MK 1
@@Tolbat MK1 was always intended for the console before it got cancelled. He's really doing Gods work porting it over now. I would also be interested to see if it would be possible to run Duke Nukem or Quake on the console if Tomb raider has finally been proven to be possible.
@@John-nb6ep We need some new coders like the guy doing the MK port to get obsessed with the Jag before we see real progress. The entire community uses the damn 68000 too much
Better to go off what bit the games are programmed in and how many transistors it has. The proof of how good it is is down to the games.
You mean: utilise ? The great thing with 2d games was that the custom chips could synthesise the graphics using scanline rendering. Only a limited number of sprites were allowed. Hardware did the y sort in one scanline. Meanwhile the CPU could run the game logic for the next frame.
With 3d you need to transform all vertices before you can sort by. For this reason the Nintendo DS has a special chip, which does this very fast once in a frame. Ah, weird. Wouldn’t the game logic stream on 68k in vertices and meshes? Then in a pipeline the GPU transforms them right away?
Give the GPU special instructions for quicksort, which is now the bottleneck.
Games on consoles had to be written and designed on a home or office computer. I mean, the Jaguar, SNES, and Megadrive don't even have a keyboard, right?
So one problem that the Jaguar had, was that many of the games were written and developed using 16-bit computers such as the Atari ST or Amiga. So how do make something look 64-bits if the graphics computer that was used to originally to design it's graphics was just 16-bit? You can't. The 64-bit tools just weren't there yet.
Not quite right. Consoles have what are called development kits, or "devkits". These have all the same hardware as a retail model, with some additional features such as extra memory, perhaps an internal hard drive, a port to connect it to a computer, and support for various debugging tools that make development easier. The code itself is still written on a computer, but it's compiled and then sent to the devkit to be executed, tested and debugged. In the Jaguar's case, it was a bit of an unusual setup. Instead of having a dedicated devkit as such, a retail console was modified with a special cartridge that had a large circuit board attached (called the "Alpine board") and the console itself had a custom ROM installed into it to make it work. It looked very weird, here's a picture: steemitimages.com/640x0/steemitimages.com/DQmYUXJ11SBYzmWXmfhZXyScsdGpPJjhbN6XkPwEci4oBtF/Atari-Jaguar-Development-Kit.jpg
Were they using those old Atari St or Amigas at that time? 32bit workstations/PCs with SVGA graphic cards were easily available by then.
@@dtester the better games used PCs with SVGA. A good number though I suppose used Amiga and Atari ST computers especially european developers who developed mostly for the Atari ST and Amiga computers. This is one reason why many of the Atari Jaguar games look closer to 16 bit Amiga and Atari games then a 32-bit or even 64-bit games system
Most textures on the PS1 only have 16 colors. Doom was ported from PC to Jaguar and really got better colors. Just Code up your 3d game on PC and get a nice fps increase on Jaguar.
Too bad that despite the powerful processors, most of the game library was trash due to it being difficult to program for...
Trying to get caught up on content about technology that is forty years old. A bit of a procrastination, I'd say.
3:09 Ehhhhhhhh.. "Yes", but that ignores the giant friggin white elephant in the room that you lose your speed advantage if the architecture is difficult to work with, which most certainly the Jaguar is.
They should have just used 64-bit variants or commissioned them of the other two chips for the sake of ease of use.
You can't just glue 32-bit CPUs together and call it 64-bit; if the OVERALL instruction set isn't 64-bit, then you've lost the plot.
That isn't at all what they did or how they got the 64bit number.
Object Processor and Blitter have no spec rating and are what Carmack referred to as chips with no theoretical upper limit. This is because their speed and performance was dependant upon and only limited by the (64bit) bus and available memory.
Unfortunately using the 68k choked the bus severely but was what most developers used for familiarity,, tools available and deadline considerations.
@@A31ChrisOkay, so I was being a bit hyperbolic there, however I was arguing FOR a unified instruction set, not five different ones essentially glued together in order to make a game console.
Look at how they wrote music on the SNES (albeit unrelated) for how unwieldy that can become shipping whole programs as data to other processors can get.
It's a common misunderstanding that they got the 64-bit number by adding 32+32. As explained in the video there ARE indeed 64-bit components in the machine. I mean if they just added them together why didn't they say it was 64+64+32+32+16 = 208 bits? The question is whether the system as a whole can be considered 64-bit or not, based on the overall architecture.
It was however overall too complicated to work with and the lack of proper developer tools didn't help matters.
@@WhitePointerGaming well considering especially back then there was no criteria for what officially determined system bitness and a 64bit ALU wouldn't have made much difference for what was needed then.
And since impinging upon what Atari considered to be the 64bit aspects of the system(which can be seen in almost all commercial releases) has the most marked detriment in performance it seems reasonable to consider it a 64 bit system IMO.
@@WhitePointerGaming Which was partly the reason I was being a bit hyperbolic, lol.
AVP may have been 64-bit(?), but it appears to run like a dog dragging its ass across the carpet, lmao.
Granted that I haven't looked much into developing for the Jag, BUT it looks like you'd need the 64-bit code to be essentially data in the 32-bit ROM in order for TOM or Jerry to be able to use it.
Or to link it together in a specific manner in order to get what they wanted to run on TOM and/or Jerry.
From what I know about GNU AS/NASM, and that just sounds especially painful, lol.
Can you draw a 16 million color picture using a computer that only displays 256 colors? No you cant.
One problem of the Atari Jaguar is that developers had to develop its games on PCs and Atari desktop computers which were only 16-bits at that time. So how do you make a 64-bit looking game if it was drawn and designed on a 16-bit computer?
As I explained in a reply to your other comment, there was a devkit available for the Jaguar, it was just kind of half baked and weird, requiring a modification of a retail console and a strange cartridge with a huge circuit board sticking out of it called the "Alpine board". The code was written on a computer, but it was executed, tested and debugged on Jaguar hardware.
@@WhitePointerGaming yes this was my point too. You mentioned that the code had to be written on a different computer and then it was tested on a Jaguar Dev kit. This is my point exactly!
The computer used for coding and designing the game graphics were not made on the Jaguar Dev kits, they were merely tested and debugged on the Dev kits. Coding and graphics designs had to be done on a computer such as an Atari ST, or an Amiga which are both 16-bit computers. So it is difficult for devs to take full advantage of the 64-bit power of the Jaguar if their development tools (which would have been an Atari ST or an Amiga) was just 16-bit.
@@WhitePointerGaming btw, I'm sorry for sending 2 almost identical comments. I didn't mean to spam your comments. I thought I watched the videos separately and I actually thought I watched 2 videos on the same topic instead of just watching 1 video twice. Anyway, it just shows how much I enjoyed your video.
The code for every game is first written on a computer then executed, tested and debugged on a devkit. That's how all console game development works. That's not unique to the Jaguar. All console games are made that way. It doesn't really matter what the specs of the computer are that's being used to write the code, because you're executing it on the devkit hardware.
There was this well know .TGA file format. I thought that it was invented by a PC graphic card manufacturer for true color graphics.
Where did Philips CDi , Kodak photoCD and all the DVD manufacturers get their videoDACs from?
I saw a demo with interesting dithering. Palette was divided into 3 parts each of which provided fine control (6bit). of one of the color channels. Then consider that photoshop and deluxe paint often ram on 800x600 CRTs and you could zoom in.