4 ms·

As a former Jaguar developer, I'm getting PTSD just looking at the diagram with the four different CPUs, all on the same memory bus in constant contention, all

by drcode 7y ago

As a former Jaguar developer, I'm getting PTSD just looking at the diagram with the four different CPUs, all on the same memory bus in constant contention, all with their own unique machine instruction set.

LanceH 7y ago
That sounds like the next zachtronics game.
- rocky1138 7y ago
  Honestly I would love to see the Jaguar become the target of game jams and high-profile ports and stuff. That would warm me heart.
  - vanadium 7y ago
    It has an extremely active indie development community, still. They’re mostly huddled at AtariAge.
  - alexisread 7y ago
    One of the things I would love to see would be a voxel-based fighting game. The rage at the time was for texture-mapped polygon fighting games, but the Jaguar was better at voxels (see phase zero https://www.youtube.com/watch?v=2OPcFdkj0GU https://www.youtube.com/watch?v=2OPcFdkj0GU). TBH I reckon the Atari ST and Amiga could've handled a voxel fighter at a decent clip: https://www.youtube.com/watch?v=CmnZoUxXIQM https://www.youtube.com/watch?v=CmnZoUxXIQM at about 2:46
Someone 7y ago
I didn’t know much about this, but was surprised to read ”a Motorola 68000 […] running at 14Mhz […] two 32-bit RISC processors running at 26.59 MHz“ I wondered how those could share a bus, with that weird 1: 1.899 ratio between CPU frequencies. I think https://en.wikipedia.org/wiki/Atari_Jaguar#Processors https://en.wikipedia.org/wiki/Atari_Jaguar#Processors answers that. It says the 68000 ran slightly slower, at 13.295 MHz. That makes the other clocks exactly twice as fast.
- basementcat 7y ago
  Devices can exchange data across clock domains. https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Clock_domain_crossing http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2s/V3.Ch7-2s.PDF http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2...
  - monocasa 7y ago
    Yeah, but it's weird for devices in different clock domains of the time to share a classic parallel system bus. They "can" theoretically, but practically they didn't because of the latency that cross domain clocking imposed.
- fabiensanglard 7y ago
  Thanks for pointing this out. I did not realize how important it was to not round up.
bitwize 7y ago
One of the motivators behind GOAL (Lisp dialect used on Jak & Daxter games) is to allow programming the PS2's various processors very close to the metal in a single language. The Jaguar might benefit from a GOAL-like language of its own.
- eindiran 7y ago
  Andy Gavin has a great interview on the technical-side of developing Crash Bandicoot [0], which they wrote in GOOL, the precursor to GOAL. In fact, they wrote GOOL explicitly for Crash Bandicoot. Later, when writing Jak & Daxter, Naughty Dog developed GOAL. Sony ended up buying ND -- among other things, they were hoping to use ND's code, and were quite surprised to discover that it was all written in a homebrewed Lisp dialect. You can see some GOAL here: https://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html https://web.archive.org/web/20070127022728/http://lists.midn... [0] https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
  - kbenson 7y ago
    I just saw that interview with Andy Gavin last week, and I highly recommend it. The title is "How Crash Bandicoot Hacked The Original Playstation" and it truly fits. So much of what they did seems to have been crazy and beautiful performance hacks. Anyone that's had to work with severe limitations to achieve their goal and found crazy ways to make it work will see a kindred spirit.
    - lowtolerance 7y ago
      I saw this interview, too. It blows my mind that Crash himself accounted for a third of their budget for onscreen polygons, something like 550 polys, which is more than many PS1 games managed to render for an entire scene.
      - candeira 7y ago
        They also didn't use any texture memory for Crash; only shading. This went against all received wisdom, and shows how much they were ready to face every challenge posed to them by going back to first principles. They also wrote a software-based Z-buffer implementation. And a custom compression system that allowed vertex-based animation. And scene streaming from disc. And... https://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ https://all-things-andy-gavin.com/2011/02/02/making-crash-ba... Previously: https://news.ycombinator.com/item?id=9278082 https://news.ycombinator.com/item?id=9278082
lostgame 7y ago
I would love to hear more about the experience of programming with the Jaguar. Do you have any interviews or sources for knowledge on this?
deleted 7y ago
[deleted]
alexisread 7y ago
Yes, I think some of that complexity was due to interference by Atari, they definitely took a dump on the Handy/Lynx by changing the power circuitry and the size of the unit. From what I've read, the joypads were lifted straight from the panther, as were the launch games, rather than be redesigned. The CPU was always meant to be 32bit with a cache, Atari chose the 68000 for ease of porting games over, but cheaped out rather than choose an EC68020 which would have increased the bus bandwith by 4 times. Same with a lack of a CD unit which if it had come with one would have helped attract developers - the costs of ROM carts made it very unattractive for most dev houses. Additionally, having the designers do a proper SDK would have helped, especially with the direct memory access bug which would be mitigated with an official workaround. Lastly, the chipset was designed to be able to use 2 memory banks, so having 1meg+512K would've been better than 2meg on one bank. Obviously having more time to develop the chipset would have been benficial. I believe Atari insisted on the object processor in addition to the DSP and blitter, which the designers were not keen on, and really by that time had been demonstrated to be a bit of a dead end (Atari GTIA->MARIA->Copper vs tile/sprite-based VDPs or blitter-based processors). If they'd not put one in maybe the chips would've been ready earlier/better, or could've had some cache/registers for the blitter. Even without the chipset improvements, a handful of changes would've made things a lot easier for developers, and faster to boot.
- to11mtm 7y ago
  > EC68020 which would have increased the bus bandwith by 4 times. I thought it was only 2x (16 bit bus on the straight 68k). It did also have a cache though which likely would have helped muchly. Wikipedia does indicate the EC68020 was considered for the Jaguar 2. My gut would be that the EC68020 was considered 'too expensive'; back then 130k extra transistors still meant a few bucks from a cost standpoint, and Atari was already cutting odd corners in a desperate stupor. That bus is terrifyingly bad IMO, I remember developers lamenting it in interviews I've read over the years. One of the -smartest- things Sony did with the Playstation was picking an architecture that was known to be capable of 'pushing graphics' and licensed/reused what they could from SGI's system designs. Probably a big part of why, while still challenging for it's age, it was at least -sane- compared to what was involved on the Saturn (lol, quadratics) or the Jaguar. Nintendo, while late to the 32 bit party, also went with an SGI based architecture, but stuck with ROM carts which still cost them a bit of business. Funny, the TG-16 suffered from many of the same problems as the Jaguar (specifically, questionable CPU bus sizes and quirky hardware design). Alas, it seems nobody from Atari payed attention to that lesson.

by drcode 7y ago

LanceH 7y ago

That sounds like the next zachtronics game.

rocky1138 7y ago
Honestly I would love to see the Jaguar become the target of game jams and high-profile ports and stuff. That would warm me heart.
- vanadium 7y ago
  It has an extremely active indie development community, still. They’re mostly huddled at AtariAge.
- alexisread 7y ago
  One of the things I would love to see would be a voxel-based fighting game. The rage at the time was for texture-mapped polygon fighting games, but the Jaguar was better at voxels (see phase zero https://www.youtube.com/watch?v=2OPcFdkj0GU https://www.youtube.com/watch?v=2OPcFdkj0GU). TBH I reckon the Atari ST and Amiga could've handled a voxel fighter at a decent clip: https://www.youtube.com/watch?v=CmnZoUxXIQM https://www.youtube.com/watch?v=CmnZoUxXIQM at about 2:46

Someone 7y ago

I didn’t know much about this, but was surprised to read ”a Motorola 68000 […] running at 14Mhz […] two 32-bit RISC processors running at 26.59 MHz“ I wondered how those could share a bus, with that weird 1: 1.899 ratio between CPU frequencies. I think https://en.wikipedia.org/wiki/Atari_Jaguar#Processors https://en.wikipedia.org/wiki/Atari_Jaguar#Processors answers that. It says the 68000 ran slightly slower, at 13.295 MHz. That makes the other clocks exactly twice as fast.

basementcat 7y ago
Devices can exchange data across clock domains. https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Clock_domain_crossing http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2s/V3.Ch7-2s.PDF http://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V3/2...
- monocasa 7y ago
  Yeah, but it's weird for devices in different clock domains of the time to share a classic parallel system bus. They "can" theoretically, but practically they didn't because of the latency that cross domain clocking imposed.
fabiensanglard 7y ago
Thanks for pointing this out. I did not realize how important it was to not round up.

bitwize 7y ago

One of the motivators behind GOAL (Lisp dialect used on Jak & Daxter games) is to allow programming the PS2's various processors very close to the metal in a single language. The Jaguar might benefit from a GOAL-like language of its own.

eindiran 7y ago
Andy Gavin has a great interview on the technical-side of developing Crash Bandicoot [0], which they wrote in GOOL, the precursor to GOAL. In fact, they wrote GOOL explicitly for Crash Bandicoot. Later, when writing Jak & Daxter, Naughty Dog developed GOAL. Sony ended up buying ND -- among other things, they were hoping to use ND's code, and were quite surprised to discover that it was all written in a homebrewed Lisp dialect. You can see some GOAL here: https://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html https://web.archive.org/web/20070127022728/http://lists.midn... [0] https://www.youtube.com/watch?v=izxXGuVL21o https://www.youtube.com/watch?v=izxXGuVL21o
- kbenson 7y ago
  I just saw that interview with Andy Gavin last week, and I highly recommend it. The title is "How Crash Bandicoot Hacked The Original Playstation" and it truly fits. So much of what they did seems to have been crazy and beautiful performance hacks. Anyone that's had to work with severe limitations to achieve their goal and found crazy ways to make it work will see a kindred spirit.
  - lowtolerance 7y ago
    I saw this interview, too. It blows my mind that Crash himself accounted for a third of their budget for onscreen polygons, something like 550 polys, which is more than many PS1 games managed to render for an entire scene.
    - candeira 7y ago
      They also didn't use any texture memory for Crash; only shading. This went against all received wisdom, and shows how much they were ready to face every challenge posed to them by going back to first principles. They also wrote a software-based Z-buffer implementation. And a custom compression system that allowed vertex-based animation. And scene streaming from disc. And... https://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ https://all-things-andy-gavin.com/2011/02/02/making-crash-ba... Previously: https://news.ycombinator.com/item?id=9278082 https://news.ycombinator.com/item?id=9278082

lostgame 7y ago

I would love to hear more about the experience of programming with the Jaguar. Do you have any interviews or sources for knowledge on this?

deleted 7y ago

[deleted]

alexisread 7y ago

Yes, I think some of that complexity was due to interference by Atari, they definitely took a dump on the Handy/Lynx by changing the power circuitry and the size of the unit. From what I've read, the joypads were lifted straight from the panther, as were the launch games, rather than be redesigned. The CPU was always meant to be 32bit with a cache, Atari chose the 68000 for ease of porting games over, but cheaped out rather than choose an EC68020 which would have increased the bus bandwith by 4 times. Same with a lack of a CD unit which if it had come with one would have helped attract developers - the costs of ROM carts made it very unattractive for most dev houses. Additionally, having the designers do a proper SDK would have helped, especially with the direct memory access bug which would be mitigated with an official workaround. Lastly, the chipset was designed to be able to use 2 memory banks, so having 1meg+512K would've been better than 2meg on one bank. Obviously having more time to develop the chipset would have been benficial. I believe Atari insisted on the object processor in addition to the DSP and blitter, which the designers were not keen on, and really by that time had been demonstrated to be a bit of a dead end (Atari GTIA->MARIA->Copper vs tile/sprite-based VDPs or blitter-based processors). If they'd not put one in maybe the chips would've been ready earlier/better, or could've had some cache/registers for the blitter. Even without the chipset improvements, a handful of changes would've made things a lot easier for developers, and faster to boot.

to11mtm 7y ago
> EC68020 which would have increased the bus bandwith by 4 times. I thought it was only 2x (16 bit bus on the straight 68k). It did also have a cache though which likely would have helped muchly. Wikipedia does indicate the EC68020 was considered for the Jaguar 2. My gut would be that the EC68020 was considered 'too expensive'; back then 130k extra transistors still meant a few bucks from a cost standpoint, and Atari was already cutting odd corners in a desperate stupor. That bus is terrifyingly bad IMO, I remember developers lamenting it in interviews I've read over the years. One of the -smartest- things Sony did with the Playstation was picking an architecture that was known to be capable of 'pushing graphics' and licensed/reused what they could from SGI's system designs. Probably a big part of why, while still challenging for it's age, it was at least -sane- compared to what was involved on the Saturn (lol, quadratics) or the Jaguar. Nintendo, while late to the 32 bit party, also went with an SGI based architecture, but stuck with ROM carts which still cost them a bit of business. Funny, the TG-16 suffered from many of the same problems as the Jaguar (specifically, questionable CPU bus sizes and quirky hardware design). Alas, it seems nobody from Atari payed attention to that lesson.