What could have saved the Jag?

[82-T/A]

What could have saved the Jag?

Ok, guess I'll actually try to answer this question rather than make jokes. 

 

 

I suppose if we acknowledge a few things:

• Jaguar was a great overall system (really was), but release was timed poorly.
• Perhaps early out of the gate, but lacking in some features.
• Was up against stiff competition from other systems that came out literally 1 year later.
• Flooded market of new exciting systems, Saturn, Playstation, Jaguar, 3DO, Sega 32x/CD, NEO-GEO on TOP of already great selling systems, SNES, Genesis, etc.
• Atari poorly managed money, was in debt when they released the system, and didn't pay their suppliers and / or vendors on time.
• Jaguar was relatively poorly marketed

 

So if I had to say, what would have saved the Jaguar? It's all about the games, and the outreach. Atari had a few great hits that they worked hard to get, but Atari's reputation was already old and stale. Even big fans like me at the time wondered what Atari was doing. Atari's problems were deeper than the Jaguar as most people had been "lost" to Atari once the 8-bit Nintendo came out. I think though, biggest problem for them was money. If they had more money, they'd have been able to pay their vendors, and work at getting more and better titles. 

 

A couple of people seem to get really offended when I bring this up... but most Jaguar games are "beat your high score" games... that's a genre that is decidedly Atari. While I like it, the Nintendo 8-bit system brought a whole new series of games that the Jaguar totally lacked. By the time the Jaguar was cancelled and Atari went bankrupt, there were NO RPG games and NO adventure games. NBA Jam TE was excellent, but it lacked so many other sports games until it was too late. For Platform Games, it had a few good games... Rayman, Pitfall, etc... but they were largely unknown characters and / or they just weren't catchy enough.

 

The Jaguar did have a bunch of cool interesting games that they filled various niches... either by porting them, or whatever. But there were no "big name" games other than Doom that really drew people in. For most people, Doom was a computer game, and while they did port it to various systems... it was like, why would I play this on my Jaguar when I can just play it on my computer? The people who had money to pay $300+ bucks for a Jaguar +$59 for a Doom cartridge, likely already had a computer.

 

 

So... in short:

• more money,
• more / better games,
• better support to vendors.

[matthew954]

Rebooteroids, and the rest of CJs game releases ?

[Phill.T]

Imho the truth is the jag didn't need saving because it didn't die and dissappear, it has a community of supporters and is still getting great stuff released for it 26-27 years after it was released.

 

No need to read on... but...

 

We got great games that you could argue later got better on other platforms like Tempest 2000, AvP, iron soldier.

 

We had ports of some popular pc games at the time such as Doom and Wolfenstein 3D, I couldn't afford to buy or put a pc together to play those games that cost similar to the cost of a jag and those carts combined at the time of release.

 

The Jag CD gave you the VLM that bettered what was on competing consoles in that generation (psx/saturn) and had better versions of hoverstrike and iron soldier 2... and it came with vid grid, blue lightening plus a myst demo and the soundtrack thrown in for free.

 

If you were in the right place at the right time after it "failed" in the UK the console (£29.99) games (£10-20) were cheap when Game sold off the stock in their "retro section" or from telegames before prices went up.

The cd add-on was available (£150) from Virgin Megastar & Dixons "partsmaster" and they were even cheaper if found at a car boot sale.

 

To compare jaguar to PSX/Saturn/N64 is unfair, to compare the state of Atari and their choices to Sony/Sega/Nintendo that is more interesting.

[phuzaxeman]

Part of the problem with the jaguar is not only the majority of mediocre games that did not maximize the hardware. But in 1994 when I got the jag, i didn't see the games and console available at the major department stores (walmart, kmart, sears) like I did with the older ataris.  I had to get the games at an electronic stores in the mall. 

 

There also wasn't any great fighting games too when MK and SFII ruled the market.  The sports titles also lacked (ie NBA live, Blitz, Tecmo).  There was so many things wrong when the jag released.  You're going to brand the "64bit" name but then have games like Trevor Mcfur and Ultra Vortek?  Nintendo had Mario.  Sega had Sonic.  Atari just didn't market well, didn't have the funds, no 3rd party support, lack of availability at the main stores, and had a lack of strong software titles.  There was no way it could compete with Sony launching too.   

Edited July 26, 2020 by phuzaxeman

[Pete5125]

Basically what has been said, Sega beat Nintendo because they reentered the mkt at the right time, and thought hard toget the type of games that were popular at the time, they could see sports games were big so they spent alot to get big Names attached to Arcade like sports Games, fighting games were big Sega hit them all on their console.

 

Atari just had no strategy other than following with not enough money to go after what kids buying systems wanted, they had a weird strategy of bringing bug name PC titles to their system honestly a PC was 2 grand so a $300 machine that could play best of PC not the worst strategy yet they didn't advertise it that way, they basically took the ad campaign from Sega, advertised they had 64bits vs Sega and Nintendo 16 bits, so their games should be 4x better, yet the games weren't, some were missing basic elements of sound and control.

 

Atari's major competitors 3D0 and Cdi didn't servive against Playstation and 3D0, did have the games people wanted (street fighter 2/samurai Showdown/Madden Football/FIFA/Road Rash/etc) CDi had Mario and zelda.

 

Sega had every major game only losing EAgames in yr 2, it couldn't beat Sony.

 

Atari was never going to be 1st place, Sega had done the impossible and destroyed Nintendo's dominance, by changing the rules.

 

SEGA, had money, and their games were the next level, plus Sega had an arcade devision to support them 

[ArneCRosenfeldt]

The Jag has a lot of onchip SRAM buffers, but could not use them for the blitter. There is 4kiB for the GPU, 1kiB color palette, 1480 bytes line buffer, 256 bytes general purpose regiters. There is a hardware multiplier. Jerry, which is made with the same tech, has a single 8 kiB buffer .

We could use CRY color for most stuff and only keep 16 entries in the color table to mark "escape codes". Colors we found that we don't use as solids and which should be interpreted as having some transparency and maybe a slightly different color.

There could be a framebuffer mode where the line buffer is loaded in the side borders. Thus we still can use totally different clocks for memory and pixels.

 

The blitter can utilized the freed up memory in 3 buffers ( A1, A2, localMap ) should work in steps:

1. We generate the px-addresses ( as before ) and write them in the buffer A2. If the phrase address really changed, we advance the repective pointer. We stored the px-pointer into A2 in our localMap, where we always advance to the next entry.
2. buffer A2 is full with 4 entries or the localMap is full with 8 entries
3. We load all the phrases for A2 from external DRAM : px-color and z-values
4. Per pixel calculate z and compare with the loaded z values. If z>z_old we store the generated address A1 in its buffer and also only advance if the phrase address changed.
5. We either reached the write pointers in buffer A2 or the local Map or buffer A1 is full with 4 entries
6. We load all the phrases A1 from external DRAM: texel color
7. Per pixel calcuate CRY Gouraud  (  reuse the 3 adders from ZUV ) and write the new pixel data
8. Write back all phrases A2 back into the frame buffer
9. If A1 was limiting us in 5, we go back to 7

For a large count given by the GPU this needs to be repeated. The specs say that external memory is only half the speed of the internal clock rate. So step 1 and 8 could be interleaved : load one entry, store one entry.

Step 4 can start when we have the first phrase. Interleaved: store phrase, read pixel . Likewise Step 7 can start after the first entry in step 6.

 

Write back can start when the pixel shader as finished 3/4 of all pixels. Not that I assume that the pixel shader needs 2 cycles, while the technology ( the process ) allow to do adds and moves in a single cycle as can be seen with the MAC instruction and program counter. So we may save some transistors in the ALU and the writeback register and load all accumulating values in nibbles starting with the least significiant one and then two 3 ADC spread over the phases of the clock to account for the carry propagation time. In all 3 registers the nibbles rotate with the counter so that one nibble can act as the target while one is the source and we don't need a write back register nor phase.

[+GoldLeader]

M O N E Y

[+Biff Burgertime]

2 hours ago, ArneCRosenfeldt said:

[...]

This man right here.

 

This man could have saved the Jag.

[ArneCRosenfeldt]

3 hours ago, Buffalo Biff Burgertime said:

This man right here.

 

This man could have saved the Jag.

The external memory has its own address lines and there is a bus interface which can assemble 4 words from narrow memory, latch them, and put them on the bus. Now this could be a full latch / transceiver. Then internally the 64 bit bus could have even clock cycles which go out to the external DRAM and internal cycles. There are independent priorities for both of them. Priorities get a hysteresis. So when the blitter is on the bus, it stays for some cycles. Meanwhile the next component is selected. Even with a small line buffer we have some timing flexibility for the ObjectProcessor when we only display a simple frame buffer. So it goes round robbing: GPU, DSP, Blitter, OP, DRAM refresh. The last two hold on a little longer if needed. The first three get kicked out if pressure from OP or refresh gets too high. So there is a hub who receives 2 bit lines with pressure value.

[toiletunes]

[phoboz]

On 1/26/2022 at 2:52 PM, ArneCRosenfeldt said:

Then internally the 64 bit bus could have even clock cycles which go out to the external DRAM and internal cycles

but what to do on the odd clock cycles? What do you expect DRAM to do on these even cycles? Did you mean to run the DRAM clock at half the speed of the 64-bit bus internal clock?

Doesn't DRAM require to pass several states for a complete read, or write cycle?

Is it then enough to just wait for the next even cycle, given that there are 4 states to pass in the diagram above?

 

On 1/26/2022 at 2:52 PM, ArneCRosenfeldt said:

There are independent priorities for both of them

for which two, the bus and the DRAM?

 

On 1/26/2022 at 2:52 PM, ArneCRosenfeldt said:

4 words from narrow memory, latch them, and put them on the bus.

What part should be reading these 4 words from the bus, and what to do with them?

 

On 1/26/2022 at 2:52 PM, ArneCRosenfeldt said:

So there is a hub who receives 2 bit lines with pressure value

How do you determine the pressure value from OP and refresh?

Edited January 27, 2022 by phoboz

[phoboz]

@ArneCRosenfeldt you should check out this SDRAM controller we used for implementing the Genesis on a FPGA system with just one single piece of memory.

 

https://github.com/phoboz/fpgagen/blob/master/src/sdram_controller.vhd

 

The real Genesis has multiple sub-systems, each with it's own memory and bus. While the Jaguar has a single bus with a lot of sub-system sharing the same DRAM.

 

This way of implementing the Genesis on a system like the Jaguar might be very interesting to compare against how it is implemented on the Jaguar?

 

It was a very challanging task to get enough bandwith on this to avoid partial updates of the screen.

 

First failed attempt where we simply relied on the SDRAM to be fast enough...

 

Edited January 27, 2022 by phoboz

[ArneCRosenfeldt]

FPGA is cool. I think I would have even been cooler back in the day when CPUs were slow. I always imagined that one could implement inner loops or some methods ( custom instructions ) in a small FPGA. Then memory became the bottleneck. I loaded the *.vhd and skimmed over it, but it will take me some time. Generally with a tile based console in an emulator I would want to draw tile by tile into a frame buffer like on Amiga or ZXspectrum or CommanderKeen. I feel like tha Jag would have problems with tiles: You have so many branches. And due to shared memory the ObjectProcessor needs to load the tile data ( char map ) and the bitmap per tile from the shared memory.

 

I also always arrive back at this conclusion when I look at mode-7 on the SNES. This only works because the SNES like the genesis on the pcb has more than one address bus. In a pipelin session first character code and than the texture is loaded. On any other system at least repeated loads of the character code would need to be avoided. Then at the horizon where character become too small, artefacts should appear. Now I wonder how the GBA with its unified VRAM does it. I think it has half the pixel count, less idle time in the borders, and just loads everything serially from VRAM ( and throws half the bits away in 8 bit mode, almost like the Jag ).

[ArneCRosenfeldt]

18 hours ago, phoboz said:

but what to do on the odd clock cycles? What do you expect DRAM to do on these even cycles? Did you mean to run the DRAM clock at half the speed of the 64-bit bus internal clock?

Doesn't DRAM require to pass several states for a complete read, or write cycle?

Is it then enough to just wait for the next even cycle, given that there are 4 states to pass in the diagram above?

 

for which two, the bus and the DRAM?

 

What part should be reading these 4 words from the bus, and what to do with them?

 

How do you determine the pressure value from OP and refresh?

I am concentrating on the small cycles and the sequence between writing and reading. For some reason reading and writing is considered the same, though I would say for writing you send {address, data} in one cycle, while for reading you send{address} and get the {data} two cycles later similar to Load and Store on internal SRAM of the GPU. The Jag is already prepared to avoid the path over "precharge". For example the OP reads the object from a double phrase aligend address .. then there is one cycle delay from read to write .. then it writes back the updated counters (.. then it goes to precharge if we don't place the objects next to its data) .. then it loads two phrases of data ( small cycle ). Refresh does a burst of small cycles. The blitter can write a Gouraud span using small write cycles.

 

For the bursts on DRAM we better plan a little into future. So when someone becomes DRAM bus master they stay at least lets say 8 cycles even if a higher priority component requests access. Internal RAM does not need or like bursts, thus busmaster switches immediately. Then may allow to do away with some special internal buffers. For example the N64 has not special buffers for color look up. The additional 16 bit register bus may be removed .. though a it feels so much like the Jag was fully designed to be used by the 68k ... and then they added the GPU. The GPU should read 4 instructions in a phrase and have LoadStoreP regFrom, regTo  ( address in r14 , byte mask on write in r15 bits ). Uint, Ufrac, VinVfrac could be one registers. A register for delta. For Gouraud we could have RGBA and its fractions in one register.

 

The current ciruitry "Bus interface" can interface the 64 bit internal bus with a 16 bit 68k or 16 bit ROM and even 16 bit RAM. If we used 16 bit RAM, but the blitter expects 64 bit data on the bus, we need a circuit to serially read 4 16 bit values and latch them. Now I think that this circuit is not part of the bus interface, but also used internally to assemble 16 bit GPU RAM reads to 64 bit Blitter inputs.

 

Pressure from OP is when the read out pointer comes close to the end of the (sub-) linebuffer. Pressure is 0 up to 70% of it and then raises linearly to 95%. The Jag already has two refresh counters. One with equal pace and one with the actual refreshes. When the actual refresh counter gets too far behind, the pressure rises. The refresh logic releases the bus when the actual counter is too far in front of the pace maker. Likewise the OP releases the bus when the back linebuffer is full.

[ArneCRosenfeldt]

Now I looked over the collection of Games for the Jaguar. There are indeed not so many ports from 68k systems. If they had just left out the 68k, Jerry could have used the 32 bit data bus. DSP and GPU share so many instructions that it is a pity that we cannot move workload around. If money was not there to buy a MIPS: How expensive would have been to double check that JRISC is complete? Compared to Z80 and MIPS it is missing conditional codes on BitSet .. I mean: Why not even have RotateThroughCarry like 6502? Offset in addressing mode is fed into the pipeline as multiple µInstructions and thus they could just as well have given use post(Inc|Dec)rement addressing mode for write (only one Target Register). Who even needs the unaligned reads of the 68k in a game? They probably used the 68k to debug their chips. Like ARM used 6502 to debug their CPU. Then GCC did not work so well with JRISC  ( RISC was invented to be friendly to a compiler!! ), and they left their development vehicle in the production system.

Some instructions have constant (verbatim) in the register field of the instruction. Maybe the ALU could be expanded to have 3 inputs for example for a shift where the higher bits are pulled in from another reg.

 

We have CMP == subN , but not andN ? We have NOT , but not xorQ signExtended,r . We have NEG but not  QsignExtendd-reg -> reg

[42bs]

14 minutes ago, ArneCRosenfeldt said:

They probably used the 68k to debug their chips.

Nope. The 68k was meant as IO CPU and system-bring-up. It only became the "main" CPU due to the bugs in Tom which makes it difficult to use DRAM for GPU code.

And building an ASIC back in time cost a fortune. So they certainly hoped for Jaguar II to improve things. Atari's problem was "The Tramiels", means bad marketing, bad developer support, bad decisions.

See how Lynx II got improved over Lynx I.

[Djmicklovin]

What could have saved the Jaguar, 3DO, Saturn, Dreamcast, any of these consoles? The PlayStation not existing that's what... Sony just dominated everything, even Nintendo wasn't safe. They had some moderate success with the N64 and Gamecube but lost a lot of market share to Sony. In an alternate universe somewhere where the PlayStation never came to be i'm sure the Jaguar would have thrived and been a lot more successful.

[Flojomojo]

I don’t think it works that way. The PlayStation was popular and brought a lot of new customers in, and had hundreds of games available. 

 

The Jag struggled to release a few dozen games. It’s not like the Tekken and Ridge Racer crowd would have flocked to the Jaguar just because it was the only thing in the market. 
 

Jaguar was outsold handily by Super Nintendo, which despite its age was more of a competitor for the kinds of games on the Jag. 
 

There should be a statute of limitations for starting threads like this, since the anniversary of Jaguar’s failure was 25 years ago. 

[ArneCRosenfeldt]

23 hours ago, 42bs said:

Nope. The 68k was meant as IO CPU and system-bring-up. It only became the "main" CPU due to the bugs in Tom which makes it difficult to use DRAM for GPU code.

And building an ASIC back in time cost a fortune. So they certainly hoped for Jaguar II to improve things. Atari's problem was "The Tramiels", means bad marketing, bad developer support, bad decisions.

See how Lynx II got improved over Lynx I.

I read that the 68k boots at address 0. Already the Amiga did some gymnastics to move that to a different address after boot. The Jag could have gotten a boot process which automates a load of the first 4k from ROM into TOM ( boot sector). Jerry does IO. I see how Tom is not friendly to the C-programming language, but how should it even run code from main memory? The data rate is too high and Load from external RAM adds one cycle lateny .. for every Jump? The calling convention for the compiler would have to be: decide if to run on Jerry or Tom, Load the function into internal SRAM, load arrays into internal SRAM, load individual values into registers, call method in internal RAM. For recursive functions we need to be able to reuse the registers, so the upper registers need to be swapped out into a stack in external DRAM. All this needs fast and simple commands to the blitter. Jumps within internal SRAM are relative or via registers which had been off-set by the loader. Likewise, the "result set" of the function is DMAed to external RAM afterwards. Jumps out to external DRAM lead to a trap ( like on 68k for example on Atari ST ) and call the loader. Of course, providing this code would mean "developer support" and Tramiels did not do that ( not for PET, not for VIC ).

ARM2 was improved over ARM1 and it shipped with the Archimedes. SuperFx got a second version which was merely a shrink. The original SuperFx was developped for NES. When SNES came out, most bugs were sorted out.

So the Jaguar could have been Lynx II ?

[ArneCRosenfeldt]

20 hours ago, Djmicklovin said:

What could have saved the Jaguar, 3DO, Saturn, Dreamcast, any of these consoles? The PlayStation not existing that's what... Sony just dominated everything, even Nintendo wasn't safe. They had some moderate success with the N64 and Gamecube but lost a lot of market share to Sony. In an alternate universe somewhere where the PlayStation never came to be i'm sure the Jaguar would have thrived and been a lot more successful.

Others have written that there was tough competition. In the years before weak consoles reached the market. PC-engine: 8 bit CPU register starved. Genesis: only 512 colors. SNES: CPU which everybody operated in 8 bit mode .. needed SuperFx on module .. still too weak for Doom. So everbody tried to correct that. Atari had the head start by one year.

 

PSX is not perfect. 24 bit color mode was a last minute add-on though the fill rate was high enough for it to be used in low overdraw scenes. The triangles wobble and are even buggy to a degree that you get gaps like if you had T-joints though you have none. In the Jag this is done by Tom .. and any bug in the SDK could be corrected. The PSX triangle renderer is a mess almost like the Jag Blitter. Wants to do too much.

 

The DreamCast could have been a PSX HD. It had 640x480 progressive scan. Sega was too cheap to buy a DVD license and so everybody waited for the PS2. PS2 is so .. I mean I saw it at Coppeti .. the anatomie .. there is just nothing .. it feels like a mess. DreamCast II is the Xbox and it is succesful. The N64 has no optical drive and as such low detail assets and textures . Hardware developers invested time into a blurry edge antialias method for no good reason. It had Rambus Ram. So it could burst large amount of data. So they could just have rendered everything as low detail 640x480 and output as interlaced. Most games were 30 fps anyway. For me the N64 looked just bad.

[ArneCRosenfeldt]

20 hours ago, Flojomojo said:

I don’t think it works that way. The PlayStation was popular and brought a lot of new customers in, and had hundreds of games available. 

 

The Jag struggled to release a few dozen games. It’s not like the Tekken and Ridge Racer crowd would have flocked to the Jaguar just because it was the only thing in the market. 
 

Jaguar was outsold handily by Super Nintendo, which despite its age was more of a competitor for the kinds of games on the Jag. 
 

There should be a statute of limitations for starting threads like this, since the anniversary of Jaguar’s failure was 25 years ago. 

Glad, I did not start it. Still people fail to explain why the Jag was hard to code for. You ask Google and get competing answers. Only the recent homebrew games show that the only thing easy on the Jag are games which already run on the SNES. The Jag is not difficult to code for, but it is almost impossible to get performance out of it. People always claim that game devs don't write assembler --  they always had, Saturn needed them to --. Now I saw the neo geo and it also can only zoom efficiently. There is no rotation. I was ideal for fighter games though today all those zooming and even that scrolling looks ridicoulus if you could just play it on a large 16:9 LCD with a fixed background ( okay burn in ). How can a specialized console be outperformed by a PC or general purpose CPUs in 32x ? Can we finally state that Gouraud looks great on round models of planes and figher legs and the blue sky, but pretty ugly for the rest of the level? Why does CheckerFlag run at the same low FPS like StarFox ? Just write it: Argonaut wrote a better software renderer which fits into a module than Atari did for something which needs its own console. I don't even know why they did not use ARM .. aren't they all british? I mean, to free up developer resouces. 

[42bs]

1 minute ago, ArneCRosenfeldt said:

Still people fail to explain why the Jag was hard to code for

So stop talking (mostly bullshit) and just start coding.

[42bs]

25 minutes ago, ArneCRosenfeldt said:

read that the 68k boots at address 0. Already the Amiga did some gymnastics to move that to a different address after boot.

You seem to read a lot. Any practice. For your info, most (if not all) machines which use an 68k do not boot from 0. As RAM at 0 is precious so why waste with ROM. If you wonder why: Read the 68k manual again.

[+CyranoJ]

5 minutes ago, 42bs said:

So stop talking (mostly bullshit) and just start coding.

Those than can, do. 

Those that can't join forums and talk shit about what they think they could do. 

[Gunther]

3 hours ago, CyranoJ said:

Those than can, do. 

Those that can't join forums and talk shit about what they think they could do. 

So more ST ports then...