Jaguar 2

[+remowilliams]

Just as an asside (kinda) didn't someone produce an entire 2600 in a single FPGA? I think Atari should have planned to add this to the Jag 2 for backwards compatibility, giving the Jag access to all that huge back catalog

 

They should have just made one of these adapters for the Jag. It sure would have helped by improving its available library at the time.

 

[LinkoVitch]

Just need a 7800 to jag one then and plug that into that whole tower of emulation and hacks

[+Stephen]

Alright, I think the Jaguar 2 FPGA/JS2 portion of this topic has run it's course.

 

Just as an asside (kinda) didn't someone produce an entire 2600 in a single FPGA? I think Atari should have planned to add this to the Jag 2 for backwards compatibility, giving the Jag access to all that huge back catalog

They did (it was Legacy Engineering - led by Curt Vendel).Don't think the technology was there in 93, but it would have been pretty cool. I wish one of the 2600 emulators was finished. I really wish the 8-bit computers will one day get a 100% cycle accurate FPGA implementation. I have lots of them, but am afraid one day they will all stop working.

[wozencl]

Apologies for going back to FPGA conversation but I believe the update is pertinent:

 

I don't need to prove anything, I know what I need to know.

 

Which again appears to be nothing.

 

maybe you can contact the guy from that FPGA arcade site.

 

Just a little update:

 

The Jaguar II FPGA is due for "some serious effort soon" as yet nothing has come of the project "but it might". The guy seems very knowledgeable and judging by his site he has had considerable success in other endeavours. There's hope but only time will tell.

Edited March 20, 2011 by wozencl

[kool kitty89]

Then again, it's the same thing with the Jaguar I. Take Jerry and give it a decent MB of EDO DRAM with 2 banks (1 256kx16 and 4 64kx16 chips) of EDO DRAM running as fast as TOM and allowing double the bandwidth for all buffered operations and roughly 4.66x faster texture mapping (26.6 MHz, separate source and destination) and a 2nd bus with Jerry and a decent 32-bit CPU using FPM or EDO DRAM (possibly faster JERRY accesses since it doesn't have to deal with TOM handshaking) or maybe a dedicated sound bus for Jerry. (and whatever capacity of RAM you wanted depending on the exact cost parameters)

A pretty major reimagining of the Jaguar - why not just fix the h/w bugs, drop the 68k and release a CD only machine in 93

That comment was in the context of someone other than Atari pushing the Jag chipset (TOM and JERRY) as a high-end console or arcade machine more like the PSX or Saturn in terms of component/production costs.

 

In the context of Atari Corp, I made a separate statement on that in the last 2 paragraphs:

Hmm, actually I wonder how cost effective it would have been for Atari to configure the Jag with pure EDO DRAM if they cut total RAM to just 1 MB (512k 16-bit bank and 512k 64-bit bank). Less RAM is limiting, but the sheer bandwidth advantages would have been extremely substantial for the time and the price of EDO DRAM would have been dropping significantly at a time when common low-end FPM DRAM prices were stagnating (so that 1 MB of EDO DRAM would have been getting cheaper and cheaper while the historical Jag's FPM DRAM was barely changing in price). Keeping JERRY and the 68k in that 16-bit bank all the time would also reduce performance hits a good bit (especially if they could have implemented Amiga-like interleaving but in fast page mode for the separate bank).

Maybe they could even have switched to a 386SX on top of that, or even a Cyrix 486SLC. (both would use a similar number of traces as the 68k -more pins, but just redundant VCC/gnd/NC lines- and a 386SX, or maybe even the SLC may have been cheaper on the mass market than an EC020 due to the higher demand/volume for x86 CPUs and more competitive market -vs 68k which only had the original 68000 being produced competitively by multiple manufacturers, then there's the surge of high profile PC games being developed in x86 assembly language in the early 90s before the switch to mainly high-level programming; that and there were no 26.6 or 39.9 MHz 68000s available in mass production from those competitive licensed manufacturers -technically a fast 286 would have had better performance than a 68k too, but then you don't get the flat 32-bit address model of 386 protected mode and 286 production was declining in the early/mid 90s -had Atari corp kept pushing their PC line, they might have already had a high volume supplier for 386SXs and stockpiles -maybe even Cyrix SLCs in use: that 1k cache and the added 486 instructions are pretty nice)

 

And, of course, Atari had many more problems than hardware or even software difficulties with the state they were in in 1993. (management, cash flow/funding, marketing, etc) Though at least with more foolproof hardware they'd have had more of a chance to get enough momentum to dig into a niche on the market and have a better chance of rectifying their various management/marketing/etc problems. (but as Kskunk said, they were pretty much doomed after 1991 -not having any new home console from the 7800 to Jag was a big part of that, but screw ups with the computers and other things certainly were major factors as well -more so for their European market than the US- and even having the sub-par Panther out in 1990 probably would have been a lot better than what they did -which was nothing until the Jag and the Lynx and ST had failed to make anywhere near the impression in the US as in Europe)

 

 

Unless TOM wouldn't mesh with EDO DRAM without modification, in which case there were still other options for different configurations with FPM DRAM to consider. If they'd realized that the market was mainly using simple sample based audio (the lines of the SNES barely did more than 8 channel MODs with compression, interpolation, and occasional use of reverb, the jaguar mainly used straight-up Amiga mod -sometimes 8 channel- without), they could have stripped the DSP out of JERRY to make it a much more basic sound/ASIC, maybe with more hardware DMA channels or just relying more on the CPU (or GPU for that matter) to drive audio. (having an ASIC including the Falcon's sound hardware, controller I/O ports, and a UART would have made sense, maybe an on-chip SRAM buffer to allow the DMA sound to read that and stay off the main bus)

Then either the 68k, or a better alternative (be it on a 16 or 32-bit bus) along with the dual bank interleaving to reduce overhead without other major redesigns to allow better bus sharing. (a bottom barrel 16 MHz rated 386SX might have been OK, but a CPU with a cache would help a lot regardless though and the 486SLC and 68EC020 were probably the cheapest examples of that, though you could go the other way and look for a higher performance low-cost CPU that lacked a cache like an ARM60 or even a plain ARM2 -specifically the newer CMOS ARM2as- which definitely would have been cheaper to manufacture -much smaller die, even smaller than a 68000- but I'm not sure if the volumes/competition would have actually priced it cheaper than a 16 MHz 68EC020 or 486SLC -or a 25 or 33 MHz rated 386SX for that matter)

 

Or you could widen the hypothetical context and change other things like release date, add more funding for Atari, etc, they weren't going to have the hardware bugs fixed in time. Hell, if you solved all the bugs in TOM and fixed the memory interface for JERRY, all that would be left was to tweak the system to make it bootable via one of the RISCs and you'd have a pretty damn powerful system even without caching. (the DSP would be just as usable as a CPU other than being limited to a 32-bit bus) You'd still want to have dual banks to allow separate source and destination for textures though, unless you added a word buffer for the blitter (even without a line buffer -and only 175 ns performance in DRAM- that would be much faster than unbuffered fast page rendering, especially for 8-bit source and 16-bit destination -moreso if they'd added support for 4-bit source with 16-color indexed textures)

Hmm, maybe another hack instead of a whole added 256kx16-bit DRAM bank (or 512kx8-bit if you wanted to mainly focus on 8-bit textures and cut some cost) could have added a single 35 ns 32kx8-bit SRAM chip as texture buffer of sorts (aimed at 8bpp textures specifically) and allowing 26.6 MHz reads (so as fast as any textures buffered into TOM's SRAM) to allow boosted performance of the most used textures. (and with a bit of added work, it could be managed on the fly as sort of a rudimentary texture cache)

That would be less attractive in a case where you still had another CPU, especially one without a cache. (in that case, there's a lot more benefit from having a full 2nd DRAM bank that the CPU could also work in) Perhaps having the cart bus configured as a separate bank and supporting faster ROM to allow code to be run directly from ROM at full speed could have been useful, especially if made optional with support for a range of ROM speeds -Kskunk gave me the impression it's locked at 375 ns, otherwise you could make it pretty damn fast for modern homebrew stuff - and maybe it would have been reasonably cost effective to use a smaller fast ROM chip for code and another bulk storage chip for compressed data to load into RAM -and make that optional as well, with cheaper games using only slow ROM, that is unless it was CD based from the start, then you'd just want a nice slot with support for RAM expansion -hell, then you could even add a 2nd bank after the fact )

 

 

Also, cutting out the "helper/manager" CPU in general is also a significant design change that went against what Flare had designed the system as from the start (albeit, unlike the older Flare 1, the Jag actually had a custom RISC processor embedded in the fundamental chipset that could be used as a fairly decent CPU -even if not optimized as such- vs the DSP in the Slipstream/Flare 1 which obviously wouldn't be able to fill that role)

 

 

There's plenty of other hypothetical stuff that could have put Atari in a much better position in general, and hardware wasn't Atari's biggest problem anyway, as I mentioned in the final paragraph in my last post. (but having fewer hardware problems definitely could have gone a good way towards alleviating some of the other problems -or potentially even helping to resolve them . . . without buggy RISCs, Atari's development tools would have been much more useful too, and that buggy compiler probably wouldn't have been so buggy or useless)

They were really in a bad position in general though, and Kskunk had a good point when he said they were doomed after 1991. (they had some chance of recovering, but 1991 marks the point where things really started falling apart -missing the 4th generation console market on top of the screw-ups in the computer side of things took its toll on the company and exacerbated the issues with declining management following Jack's retirement at the end of 1988) This is going further off topic, but on the computer side of things, it's interesting to note that Atari started to get things right when CBM was still stagnating. (the TT's video was a step in the right direction, but they didn't extend that to lower-end systems or upgrade the blitter -or maybe even hacking in the Lynx's blitter- to be faster and efficient using 8-bit packed pixels -or even working directly on the 64-bit TT video bus, but the Falcon got more things right -blitter was still weak though and the Falcon was the opposite of the TT being limited to the low-end range, but the Falcon was especially progressive compared to what Amiga did with AGA -except they kept up with a range of machines with the 1200 in the lower-end and high-end 4000 with workstation class configurations as well, a shame that didn't work out with the falcon though -they also ended up pulling out of computers just before CBM collapsed, so there's another missed window -albeit with PCs coming into Europe at that time)

I wonder if Atari could have done better with their PC line too, or if it would have been wise to transition to PC/compatibles in Europe rather than extending the ST line in the early 90s. (especially after the previous mistakes with that and missing major opportunities to maintain a dominant position in Europe)

Edited March 21, 2011 by kool kitty89

[Fredifredo]

Someone has seen this before ?

 

in the demo.c 3D Render source code sept. 1995 :

 

/* if running on Jaguar II prototype, fix up DSP access */

buts = (*(volatile long *)0xf02114) & 0x0000f000; /* get GPU version */

if (buts == 3) { /* if version 3 */

 

[Pete5125]

The way to go at that point if staying in the computer market, was to make a Windows compatible machine but nobody really stayed in buisness making PC's tge mkt was flooded and you had to make all your money off of hardware, as you would get no residuals off software, very few of the big companies from the late 90s survived, HP and Dell are about it,tgen Apple stood their ground and survived.

 

Atari, had just done to many people dirty over a decade after the early 80s buyout. They confused tge mkt with 7800 late entry, 2600 reentry, xe being re-released the same year as all 3, somehow working and maling tgem a profit,then skipping the 16bit generation, only to fail with a superior lynx im the handheld mkt.

 

Their was no solution other than a merging witha major company to fight Sony and Sega,then the deep pockets of microsoft.

[82-T/A]

Please add me to the waiting list...

[Clint Thompson]

Someone has seen this before ?

 

in the demo.c 3D Render source code sept. 1995 :

 

 

 

Someone has seen this before ?

 

in the demo.c 3D Render source code sept. 1995 :

 

/* if running on Jaguar II prototype, fix up DSP access */

buts = (*(volatile long *)0xf02114) & 0x0000f000; /* get GPU version */

if (buts == 3) { /* if version 3 */

 

Most likely this is talking about the JagDuo since that's what the Jaguar II actually was. Learned this the hard way by asking a lot of questions about the JagDuo when it actually was referred to as the Jaguar II and the new Jaguar II was actually Jaguar III, which hadn't had the GPU finalized anyways. I guess it would make sense they may have had a 3rd revision of the GPU for the combo unit. Both Sam and Leonard were confused as they had never heard it coined as JagDuo so it must have been something the media came up with or elsewhere years later. To further confirm this, the "JagDuo" pcb files are actually titled Jaguar II re-work in the headliner.

[VintageGamer74]

@Clint I was just wondering if the Jag could be cloned or if a FPGA Jag could be developed? The only reason I ask is that these systems can't last forever and there are very few of them out there and they continually rise in price.

[pacman000]

I think there's already been two FPGA projects, but they were too expensive for a commercial release.

[Zerosquare]

http://atariage.com/forums/topic/212136-atari-jaguar-in-fpga/

[kskunk]

Most likely this is talking about the JagDuo since that's what the Jaguar II actually was. Learned this the hard way by asking a lot of questions about the JagDuo when it actually was referred to as the Jaguar II

 

That's true and a source of confusion, but I'm pretty sure this code is for the "second" Jaguar II. Midsummer - the new chipset - was also called Jaguar II by Atari engineering during its development. (I guess they recycled the name.)

 

In Eric Smith's weekly status reports from 1995, he consistently uses "Jaguar II" when describing his modifications to sample code to support Midsummer features.

 

This code could be related to that effort. If you match up the code in question to the Midsummer datasheet, you'll find it's an exact match:

  /* if running on Jaguar II prototype, fix up DSP access */
  buts = (*(volatile long *)0xf02114) & 0x0000f000;   /* get GPU version */
  if (buts == 3) {                                    /* if version 3 */
      *(volatile short *)0xf00056 = 0x0060;           /* mess with TEST1 register */
  } 

 

The above code detects Oberon, then configures it to talk to Jerry instead of Puck. This matches with another piece of history:

Working prototypes were shown to developers in early 1995. The Oberon graphics chip (which replaced the Tom chip from Jaguar), taped out and was running in this prototype. Its companion chip, Puck, had not taped out and the prototypes used Jerry chips instead.

 

In Midsummer, 0xf02114/GPU_CTRL bits 12-15 are documented as follows:

1 Pre-production test silicon (Jaguar One)

2 First production release (Jaguar One)

3 Pre-production test silicon (Midsummer)

 

In Midsummer, setting 0xf00056/TEST1 to 0x60 does the following:

0x20 enable the Jaguar One Jerry interface

0x40 delay the DRAM write strobes by one half clock cycle

 

- KS

Edited June 8, 2019 by kskunk

[Kalani]

I would make the arguement Atari was doomed to some degree by it being split up by into two companies. Tengen/Atari soft and Atari computers. The lack of in house 1st party developers really hamstrung. They didn't have fall back area. At the end of its life Atari should of maybe a play into the emerging markets. Where genisis clones where played till mid 2000. Like Brazil and eastern Europe.

[pacman000]

In the late 80's Atari Corp did have some success marketing their 8-bit computers in Eastern Europe, if what I've read is correct.

[Clint Thompson]

 

That's true and a source of confusion, but I'm pretty sure this code is for the "second" Jaguar II. Midsummer - the new chipset - was also called Jaguar II by Atari engineering during its development. (I guess they recycled the name.)

 

In Eric Smith's weekly status reports from 1995, he consistently uses "Jaguar II" when describing his modifications to sample code to support Midsummer features.

 

This code could be related to that effort. If you match up the code in question to the Midsummer datasheet, you'll find it's an exact match:

  /* if running on Jaguar II prototype, fix up DSP access */
  buts = (*(volatile long *)0xf02114) & 0x0000f000;   /* get GPU version */
  if (buts == 3) {                                    /* if version 3 */
      *(volatile short *)0xf00056 = 0x0060;           /* mess with TEST1 register */
  } 

 

The above code detects Oberon, then configures it to talk to Jerry instead of Puck. This matches with another piece of history:

 

In Midsummer, 0xf02114/GPU_CTRL bits 12-15 are documented as follows:

1 Pre-production test silicon (Jaguar One)

2 First production release (Jaguar One)

3 Pre-production test silicon (Midsummer)

 

In Midsummer, setting 0xf00056/TEST1 to 0x60 does the following:

0x20 enable the Jaguar One Jerry interface

0x40 delay the DRAM write strobes by one half clock cycle

 

- KS

 

Fantastic info, thanks for clearing that up! =)

[RREDDWARFF]

On 6/6/2019 at 7:12 AM, VintageGamer74 said:

@Clint I was just wondering if the Jag could be cloned or if a FPGA Jag could be developed? The only reason I ask is that these systems can't last forever and there are very few of them out there and they continually rise in price.

 

Edited July 11, 2019 by RREDDWARFF

[philipj]

On 6/8/2019 at 8:27 AM, Kalani said:

I would make the arguement Atari was doomed to some degree by it being split up by into two companies. Tengen/Atari soft and Atari computers. The lack of in house 1st party developers really hamstrung. They didn't have fall back area. At the end of its life Atari should of maybe a play into the emerging markets. Where genisis clones where played till mid 2000. Like Brazil and eastern Europe.

 

I think he guy who ran "Tengen" had fell ill then passed sometime in 1994... Also Jay Miner, the guy who created the "TIA, GTIA, and the CTIA" had passed that very same year; which he was well some years with Amiga, but still that had to have did something to the morale at Atari for those who knew the guy. The following year Jack Tramiel son has a heart attack on top of the Jaguar not doing so well. That particular part of Atari was just done to do any kind of real legacy game making. I don't know what role "Midway" played, but they kept they seemingly kept the name going by rubber stamping their games with the Atari name. Seem like they would've been better to keep things going in that regard into the 2000, but they were busy keeping their own brand thriving with the more modern console of that time (the N64, Dreamcast, PS2, Original XBOX and so forth).

 

Long live Hydro Thunder... ? 

 

Ok back to the topic.