Jaguar Bashing

[The_Laird]

Wrong again Mr Kizza.

 

The 68000 is a CPU.

Tom and Jerry are CPUs (Well, GPU/DSP if you want to get into semantics)

 

Ok Mr. Morden the 68k might be A CPU it certainly is in the ST or Megadrive but it isn't the Jaguar's CPU it even says that in the official Atari/Flare docs.

[+CyranoJ]

And just in case you cant read:

 

 

Exhibit A

 

A Jaguar CPU.

 

Run along now Kizzy. Before you make yourself look even more stupid.

[The_Laird]

I bow down to your obviously superiour knowledge, oh mighty one. You must have learnt so much from The Big Bumper Book of Stolen Spectrum Games

 

Your above ramblings regarding how the Jaguar works prove the old addage: Mr Kizza Tells Fibs.

 

Come back when you get a clue

 

Just the kind of well thought out intelligent response I expected from you. I swear you are obsessed with me its actually quite scary even to the extent you devote half your website to me and your sig.

 

The only fact is that the 68k is not the Jag's CPU. Atari stated that and Flare stated that, if you disagree then go argue with the people who wrote that. I am merely quoting them.

[carmel_andrews]

What...Intel Crap in a beautiful Jaguar....get thee behind thee satan

 

Was the Jag Duo going to have updated h/w (i.e capable of doing the 3d gig) or was it just a jag with a built in cd drive

Edited October 12, 2010 by carmel_andrews

[GroovyBee]

Exhibit A

 

A Jaguar CPU.

 

 

The one on the left or the right at the bottom?

[Gaztee]

What...Intel Crap in a beautiful Jaguar....get thee behind thee satan

 

Was the Jag Duo going to have updated h/w (i.e capable of doing the 3d gig) or was it just a jag with a built in cd drive

AFAIK it was just a jag with CD unit all in one!

[+CyranoJ]

The one on the left or the right at the bottom?

 

Oh c'mon Bee, you know full well what I meant.

[GroovyBee]

The one on the left is the CPU from the A8 range and the A7800.

[Atari_Owl]

There's some debate as to whether the TOM chip (bottom right) says CPU or GPU - the font leaves a fair bit to be desired

 

Not that it matters - just a point of interest maybe.

Edited October 12, 2010 by Atari_Owl

[sh3-rg]

There's some debate as to whether the TOM chip (bottom right) says CPU or GPU - the font leaves a fair bit to be desired

 

Not that it matters - just a point of interest maybe.

 

Considering the clear G in the word Jaguar above (presumably in the same font), I reckon it probably says CPU.

 

Like you say though, it doesn't really matter other than being a little interesting.

[Atari_Owl]

Yes i feel looks more like a C also - i guess reflecting Atari's idea that the GPU was intended to function more as the CPU than the 68k

[+orpheuswaking]

Are we really having the 64bit argument??? I thought everyone got thast out of their systems years ago!!!

[Albert]

There's some debate as to whether the TOM chip (bottom right) says CPU or GPU - the font leaves a fair bit to be desired

That clearly says "CPU", looking at the example of the "G" in "JAGUAR".

 

..Al

[Justin42]

Was the term/abbreviation "GPU" even in use back the early 90s? I'm sort of blanking...

[philipj]

It was my impression that the GPU was meant to have been the CPU while the Motorola was only put there to have contact with the outside world, while at the same time attract more people to program Jag. My Jag has the same font and it looks like CPU when I first saw it... Then I looked again and the C looks more like the G... It's a little hard to tell.

[BeckHansen]

If i remember correctly i remember first seeing the "GPU" acronym being used when the first AGP graphics accelerators got released.

 

Before that they were simply called graphics accelerator, again, i could be wrong.

[GroovyBee]

The only fact is that the 68k is not the Jag's CPU. Atari stated that and Flare stated that, if you disagree then go argue with the people who wrote that. I am merely quoting them.

 

Nope! From page 2 of the Jaguar Software Reference Manual v2.4 dated June 7th 1995 (emphasis mine):-

 

"For graphics, Tom contains the Object Processor, the Blitter and the Graphics Processor. For sound, Jerry holds the Digital Sound Processor. In addition to these, there is an external CPU, currently a 68000. When animating graphics there are therefore four processing elements, and they have all got specific roles to play.

 

The CPU is used as a manager. It deals with communications with the outside world, and manages the system for the other processors. It is the highest level in the control flow of a Jaguar program, and has complete control of the system."

 

Seems to me that the 68K is the CPU.

[The_Laird]

C or G - doesn't really matter - either way he's wrong.

 

Not at all. The Jaguar does not have a CPU in the traditional sense that controls the whole machine. Like I said it has a custom chip set so more than one part of the system can do that role.

 

For graphics, Tom contains the Object Processor, the Blitter and the Graphics Processor. For sound, Jerry holds the Digital Sound Processor. In addition to these, there is an external CPU, currently a 68000. When animating graphics there are therefore four processing elements, and they have all got specific roles to play.

 

This is actually my point that its a custom chip set and all should be used although its seems to be the consensous among every Jag programmer I have spoken to that you should turn off the 68k once its done its job setting everything up. I am not a Jag coder neither do I profess to be so if you all want to argue about it then argue with other coders, I just have a Jag to play games. Its pretty clear that most of the Jags more impressive games, especially a few in development, use the 68k as little as possible.

Edited October 13, 2010 by The_Laird

[Atari_Owl]

Was the term/abbreviation "GPU" even in use back the early 90s? I'm sort of blanking...

 

The Jaguar Developer docummentation refers to the GPU as a GPU so certainly they were using the acronym at the time.

 

Again - not exactly important just answering the Q.

[sh3-rg]

Was the term/abbreviation "GPU" even in use back the early 90s? I'm sort of blanking...

 

The Jaguar Developer docummentation refers to the GPU as a GPU so certainly they were using the acronym at the time.

 

Again - not exactly important just answering the Q.

 

It wasn't used widely to describe graphics hardware back then, as far as I remember, it's more a matter of them using a simple acronym to describe what that processor did. It wasn't until the late 90s that the current use of 'GPU' came about, with the GeForce256. Like Owl says, not exactly important...

[OldAtarian]

The Jag came out 2 years before the Saturn and the PS1 so that has nothing at all to do with it

 

Consoles "bitness" is generally defined by its CPU. The PC Engine has an 8 bit CPU with a 16-Bit graphics chip as does the Lynx which is also often reffered to as 16-bit wrongly.

 

The Jaguar does not have a CPU it has a custom chip set much like a modern console and thanks to a 64-bit bus it can process data 64-bits at a time. This is what makes it 64-bit, it dosn't have to break anything down into smaller chunks unless you make it do so

 

 

Then how do you move a 64 bit number across the 32 bit memory controller?

[mellis]

The Jag came out 2 years before the Saturn and the PS1 so that has nothing at all to do with it

 

Consoles "bitness" is generally defined by its CPU. The PC Engine has an 8 bit CPU with a 16-Bit graphics chip as does the Lynx which is also often reffered to as 16-bit wrongly.

 

The Jaguar does not have a CPU it has a custom chip set much like a modern console and thanks to a 64-bit bus it can process data 64-bits at a time. This is what makes it 64-bit, it dosn't have to break anything down into smaller chunks unless you make it do so

 

 

Then how do you move a 64 bit number across the 32 bit memory controller?

 

The JRISC chips have a total of sixty-four 32-bit registers, but only thirty-two of the registers are active at a time, so they are referred to as "Bank 0 registers" and "Bank 1 registers". Which bank is currently active is software-selectable.

 

Tom's (the GPU) LOADP instruction will perform a 64-bit load from external memory, where the low 32-bits of the acquired value are available in the given Bank 0 register, which the upper 32-bits of the value are available in the corresponding Bank 1 register. Tom sits on a 64-bit coprocessor bus, along with the Blitter chip. Using these two chips and that wide bus, it is possible to do some serious pixel pushing.

 

Tom also has a STOREP instruction, which is the opposite of LOADP. With STOREP, you put the lower 32-bits of the value to store in a Bank 0 register of your choice, and the upper 32-bits in the corresponding Bank 1 register. The execution of the STOREP (and the LOADP instruction, for that matter) causes the data to be placed on (or read from) the 64-bit coprocessor bus as a 64-bit phrase (a "phrase" is a 64-bit number).

[Atari_Owl]

The Jag came out 2 years before the Saturn and the PS1 so that has nothing at all to do with it

 

Consoles "bitness" is generally defined by its CPU. The PC Engine has an 8 bit CPU with a 16-Bit graphics chip as does the Lynx which is also often reffered to as 16-bit wrongly.

 

The Jaguar does not have a CPU it has a custom chip set much like a modern console and thanks to a 64-bit bus it can process data 64-bits at a time. This is what makes it 64-bit, it dosn't have to break anything down into smaller chunks unless you make it do so

 

 

Then how do you move a 64 bit number across the 32 bit memory controller?

 

Ahhh i believe you got that info from wikipedia - it appears to be in error.

 

If one looks at the Atari supplied specifications it states...

- DRAM memory controller

- 64 bits

- Accesses the DRAM directly

Whilst they certainly weren't right about everything i see no reason to disbelieve them on this occassion.

 

also if you look at the document that the wiki is based on it states

Memory widths can be 8,16,32 or 64 bits wide but the memory controller makes it all

look 64 bits wide.

 

The processor bus is a 64-bit data, 24-bit address multi-master bus. The bus interface logic and

memory controller allows transfers of any width (one to eight bytes) to be made to any width of external

memory.

 

The bus interface accommodates 16 and 32-bit microprocessors.

 

The last sentence may be where the confusion arises.. because whilst certainly the 68k and DSP access it 16bits at a time (the 68020 and DSP are 32bits at a time for the CoJag) the OP and blitter are able to access 64 bits at a time. In addition the GPU can load or store 64bits as a single instruction although whether the data is transferred in a single cyle is something i've not checked. In practice i find that two LONG transfers is not appreciably slower than a PHRASE transfer and does not incur the overhead of retrieving the data from the GPU_HIDATA location.

 

Edit: Certainly one only writes to the GPU at 16bit to its standard memory or 32bit to standard memory +$8000

 

Hope this is a help - in the meantime someone should probably address the wikipedia error.

Edited October 13, 2010 by Atari_Owl

[Zerosquare]

Tom's (the GPU) LOADP instruction will perform a 64-bit load from external memory, where the low 32-bits of the acquired value are available in the given Bank 0 register, which the upper 32-bits of the value are available in the corresponding Bank 1 register.

Nope, the upper 32 bits are stored in the G_HIDATA special register ; same thing for STOREP. Otherwise you're correct. Edited October 13, 2010 by Zerosquare

[mellis]

Tom's (the GPU) LOADP instruction will perform a 64-bit load from external memory, where the low 32-bits of the acquired value are available in the given Bank 0 register, which the upper 32-bits of the value are available in the corresponding Bank 1 register.

Nope, the upper 32 bits are stored in the G_HIDATA special register ; same thing for STOREP. Otherwise you're correct.

 

Yep - I was mistaken. The high long word is stored in G_HIDATA, just as you pointed out.

 

That's what I get for posting without consulting the docs first. Nevertheless, the question of how a 32-bit JRISC chip processes 64-bit data did get answered.