Jump to content

Photo

Clean version of the Jaguar's schematic


28 replies to this topic

#1 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • 2,692 posts
  • Location:France

Posted Mon Jul 23, 2018 3:05 PM

Here's a clean version (generated from source files, not scanned) of the Jaguar schematic:
https://www.mirari.fr/iS1N

Source:
https://www.chzsoft....b/ASICs-new.zip

Thanks to DEATH for finding and converting the file, and to Jonas for tracking the original source :)

Edited by Zerosquare, Mon Jul 23, 2018 3:05 PM.


#2 NeoGeo64 OFFLINE  

NeoGeo64

    Star Raider

  • 55 posts
  • Not a troll!
  • Location:Leesburg, GA

Posted Tue Jul 24, 2018 2:16 AM

Very nice!



#3 Cyprian_K OFFLINE  

Cyprian_K

    Star Raider

  • 78 posts

Posted Tue Jul 24, 2018 9:52 AM

thats cool

I see Jerry has full 32bit data bus. D16-D31 are not used and are connected to VCC. Interesting is why Atari did that.

And maybe would be possible to fix that :)



#4 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,361 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Tue Jul 24, 2018 1:32 PM

thats cool

I see Jerry has full 32bit data bus. D16-D31 are not used and are connected to VCC. Interesting is why Atari did that.

And maybe would be possible to fix that :)

 

/disregard/ edit


Edited by Clint Thompson, Tue Jul 24, 2018 2:03 PM.


#5 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,176 posts

Posted Tue Jul 24, 2018 1:45 PM

So, does this mean reboot can start working on the Jaguar One X?



#6 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,176 posts

Posted Tue Jul 24, 2018 9:30 PM

 

/disregard/ edit

 

Your detailed explanation seemed very reasonable and illuminating.  Did you find new information that disproves your original thoughts?



#7 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,548 posts
  • Location:Manchester UK

Posted Wed Jul 25, 2018 1:24 AM

thats cool

I see Jerry has full 32bit data bus. D16-D31 are not used and are connected to VCC. Interesting is why Atari did that.

And maybe would be possible to fix that :)

 

The silicon may have the lines, but if they are there they are pulled up to VCC by those resistor packs.  This will ensure that the values on those lines are in a known state and that they are not randomly fluctuating and injecting noise and randomness into the silicon (which may lead to unintended states and the resultant booms of crashy crashy :) )

There is also no bus to connect them to on the PCB, it would have been nice if they had added those extra 16 traces :)  they didn't however.



#8 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,361 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Wed Jul 25, 2018 7:48 AM

 

Your detailed explanation seemed very reasonable and illuminating.  Did you find new information that disproves your original thoughts?

Yeah, but then I realized Atari's representation of said chip could have just been for show since it was a press event, so I'm not certain now.



#9 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • Topic Starter
  • 2,692 posts
  • Location:France

Posted Wed Jul 25, 2018 12:08 PM

Come on, Atari would never give inaccurate specs to the press.
*cough* 850 million pixel per second *cough*

#10 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,361 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Wed Jul 25, 2018 12:37 PM

Come on, Atari would never give inaccurate specs to the press.
*cough* 850 million pixel per second *cough*

 

Wouldn't the frame rate then have to be about 11,000 per second? Someone got the decimal wrong in the marketing department. That's 11FPS or 850,000 pixels per second. I did the math.. ;)



#11 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • Topic Starter
  • 2,692 posts
  • Location:France

Posted Wed Jul 25, 2018 1:23 PM

It's pretty normal to handle more pixels per second than just "pixels per screen" * "framerate" (for example, with 2D or 3D Z-sorting, each pixel is drawn more than one time).

Atari's number actually checks out... assuming you use 100% of the bus bandwidth to copy pixels, with zero dead-time, and your pixels are 1-bit wide.

#12 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,548 posts
  • Location:Manchester UK

Posted Wed Jul 25, 2018 1:48 PM

I think you are being a bit harsh.. 850,000,000 @ 60Hz is 14,166,166 pixels per frame.  320x256 is 81,920..

 

 

 

I am sure the blitter could write 0 to the screen 172 times per frame :D  (as long as nothing else was running, and you had a fair wind and good fumes ventilation :D )



#13 Cyprian_K OFFLINE  

Cyprian_K

    Star Raider

  • 78 posts

Posted Wed Jul 25, 2018 4:10 PM

 

There is also no bus to connect them to on the PCB, it would have been nice if they had added those extra 16 traces :)  they didn't however.

 

I wonder what will happen after connecting those lines to the data bus. Will GPU have full 32bit access to the RAM?



#14 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,548 posts
  • Location:Manchester UK

Posted Thu Jul 26, 2018 2:51 AM

I suspect you mean DSP :) (GPU already has 32bit access)

 

I'd guess that they would be ignored or not used as the silicon possibly doesn't make any use of them, or random behaviour as it may have been due to a bug or a fabrication issue that those lines were not connected.



#15 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • Topic Starter
  • 2,692 posts
  • Location:France

Posted Thu Jul 26, 2018 4:16 AM

I wonder what will happen after connecting those lines to the data bus. Will GPU have full 32bit access to the RAM?

If it was that easy, don't you think Atari would have done it already?

#16 Cyprian_K OFFLINE  

Cyprian_K

    Star Raider

  • 78 posts

Posted Thu Jul 26, 2018 6:03 AM

I suspect you mean DSP :) (GPU already has 32bit access)

 

I'd guess that they would be ignored or not used as the silicon possibly doesn't make any use of them, or random behaviour as it may have been due to a bug or a fabrication issue that those lines were not connected.

 

yep I mean DSP 

 

If it was that easy, don't you think Atari would have done it already?

 

good question.

There is similar case - Falcon - where due to cost-cutting, data path was reduced to 16bit for the CPU (Videl has full 32bit access)



#17 Stephen OFFLINE  

Stephen

    Quadrunner

  • 7,173 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Mon Jul 30, 2018 9:35 AM

Come on, Atari would never give inaccurate specs to the press.
*cough* 850 million pixel per second *cough*

1 bpp though :)  Oh - it's 1993.  You want colour?  Hmm - just crunched some numbers.  Pretty sure the machine can't clear even a monochrome 320*240 screen 11,000 times per second.

 

They also said the machine was more powerful than the Playstation, so.



#18 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • Topic Starter
  • 2,692 posts
  • Location:France

Posted Mon Jul 30, 2018 1:40 PM

They also said the machine was more powerful than the Playstation, so.

Lies! Here's what Sam Tramiel actually said:

As I said, Saturn is the same, if not a even less, technology than Jaguar. PlayStation is a little big more -- not more technology, but PlayStation does have more memory than Jaguar, it's using more silicon as a solution.

See? Not the same thing at all.

#19 PeterG OFFLINE  

PeterG

    Dragonstomper

  • 864 posts
  • Location:Germany

Posted Mon Jul 30, 2018 5:05 PM

Lies! Here's what Sam Tramiel actually said:See? Not the same thing at all.

I remember that interview. What an embarassing answer that was. Even if you do not have a clue (like myself) that was real facepalm material. :D Haha thanks for reminding me.



#20 DEATH OFFLINE  

DEATH

    Space Invader

  • 30 posts
  • Location:France

Posted Wed Aug 1, 2018 8:53 AM

ok ok ok, guys, keep cool.
There are "many" reasons why the DSP has a 16-bit BUS in the Jaguar. But the main reason is the COST.
To be cost effective and minimise the use of external chips the jaguar has to use the integrated fonctions of TOM.
Remember, TOM has a built-in Motorola 68000 compatible CPU interface. And the DSP uses this same interface. So, if the CPU interface is set to 16-bit mode (read the manual) the DSP will also be in 16-bit mode.

To pass the DSP in 32-bit mode, it would be necessary to pass the CPU interface in 32 bits. Which means that you have to either put a 32-bit processor (68020 ...), or add a whole bunch of external chips to modify / manage the logic to the 68000. (32bit-> 16bit ....) I lets you imagine the bloody mess on the PCB…
AND, AND, and that's not to mention the fact that the DSP is buggy in 32-bit mode! (again, read the manual) And so need other external circuits to work around / fix these bugs.

So ok, that's what COJAG cards do. But did you see the complexity of the PCB of a COJAG game ??!


 


Edited by DEATH, Wed Aug 1, 2018 9:14 AM.


#21 Lost Dragon OFFLINE  

Lost Dragon

    River Patroller

  • 3,306 posts

Posted Wed Aug 1, 2018 9:12 AM

Come on, Atari would never give inaccurate specs to the press.*cough* 850 million pixel per second *cough*

:-)) This aspect was brought up many years later in Arcade magazine i think..

Sony had just released it's PS2 'alleged' final hardware performance figures, designed of course to dwarf the actual performance polygon performance figures Sega were talking about for the Dreamcast.

Argonaut Software's Jez San commented about people giving 'soap on a rope' figures to the press, Atari and that 850 million pixels..claim was brought up.

EDIT...

Found the quote:

Posted Tue Dec 30, 2014 1:25 PM

Jez San 'Look at the 3DO and Jaguar.Both of them are trying to outdo each other on pixels per sec, 3DO claiming 50 Million per sec, Jaguar claiming 850 million per sec.Both numbers are actually wrong and Atari is just playing the numbers game-they are talking about a 1 bit pixel, a black and white screen.Nobody wants a B+W screen, so divide it by 16 or more-24 bits even.We don't really believe the numbers game'.

Edited by Lost Dragon, Wed Aug 1, 2018 9:18 AM.


#22 Lost Dragon OFFLINE  

Lost Dragon

    River Patroller

  • 3,306 posts

Posted Wed Aug 1, 2018 9:22 AM

I remember that interview. What an embarassing answer that was. Even if you do not have a clue (like myself) that was real facepalm material. :D Haha thanks for reminding me.


And poor old Darryl Still made a similar claim replying to a readers letter in C+VG magazine...

The letters page a month after his claim was printed....oh boy..they buried him.

He latter admitted he was only going on what Atari's Engineering department had told him, but it was painful to read.

#23 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,548 posts
  • Location:Manchester UK

Posted Wed Aug 1, 2018 10:06 AM

ok ok ok, guys, keep cool.
There are "many" reasons why the DSP has a 16-bit BUS in the Jaguar. But the main reason is the COST.
To be cost effective and minimise the use of external chips the jaguar has to use the integrated fonctions of TOM.
Remember, TOM has a built-in Motorola 68000 compatible CPU interface. And the DSP uses this same interface. So, if the CPU interface is set to 16-bit mode (read the manual) the DSP will also be in 16-bit mode.

To pass the DSP in 32-bit mode, it would be necessary to pass the CPU interface in 32 bits. Which means that you have to either put a 32-bit processor (68020 ...), or add a whole bunch of external chips to modify / manage the logic to the 68000. (32bit-> 16bit ....) I lets you imagine the bloody mess on the PCB…
AND, AND, and that's not to mention the fact that the DSP is buggy in 32-bit mode! (again, read the manual) And so need other external circuits to work around / fix these bugs.

So ok, that's what COJAG cards do. But did you see the complexity of the PCB of a COJAG game ??!


 

 

I'm confused by a few of these points...

 

TOM (GPU) is 32 bit, with a 32bit bus.. running at 32 bits, not 16... it works fine, and the 68K can access it's RAM... the DSP, is internally 32 bits, and runs at 32bits, but it's data bus to main RAM is 16 bits...  The same silicon is on the Co-Jag boards, which have alternate CPUs to the 68K, and even a non-Motorola CPU on some, so not sure what this Motorola compatible interface is you mention?

Is it not that the DSP within Jerry is likely connected via a 16bit bus as it was more cost effective?  Adding those extra 16 bits would likely require the silicon to be in a larger package with higher pin density, perhaps they decided that it simply wasn't worth the extra expense?  I have no idea if the costs of custom silicon vary that much based on the package size.



#24 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,361 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Wed Aug 1, 2018 11:55 AM

As a side note, they created the CoJag so that the 68020 or alternate CPU (MIPS 3041) had its own dedicated memory so the program was more predictable and it wouldn't have to deal with any of the slowdown from the Jaguar chipset. I ran across one board that was straight up a 586 PC motherboard attached to a Jamma board and the thing even had an AGP slot. It was a Maximum Force board I believe but was clearly no longer a CoJag at that point. No idea why or what trouble they ended up going through to make that all work out.



#25 DEATH OFFLINE  

DEATH

    Space Invader

  • 30 posts
  • Location:France

Posted Wed Aug 1, 2018 12:03 PM

 

I'm confused by a few of these points...

 

TOM (GPU) is 32 bit, with a 32bit bus.. running at 32 bits, not 16... it works fine, and the 68K can access it's RAM... the DSP, is internally 32 bits, and runs at 32bits, but it's data bus to main RAM is 16 bits...  The same silicon is on the Co-Jag boards, which have alternate CPUs to the 68K, and even a non-Motorola CPU on some, so not sure what this Motorola compatible interface is you mention?

Is it not that the DSP within Jerry is likely connected via a 16bit bus as it was more cost effective?  Adding those extra 16 bits would likely require the silicon to be in a larger package with higher pin density, perhaps they decided that it simply wasn't worth the extra expense?  I have no idea if the costs of custom silicon vary that much based on the package size.

 

First of all, for the sake of clarity, we are talking about the data bus here, only.

 

TOM is referring to the ASIC circuit (also marked as JAGUAR CPU on the circuit) with 208 pins. And which contains several different functions: the RISC processor, the Blitter, the object processor, the management of memory access, and the management of the interface with the "main" processor (CPU Interface).
The RISC processor is in 32 bits but that's not the question here. The TOM data BUS is 64 bits wide, and it manages the memory access of all components of the Jaguar, whether they are 8, 16, 32 or 64 bits.
For TOM and the main processor to understand each other, he must speak the same language. For cost reasons TOM was therefore directly designed to speak the 68000.

That's why TOM and the 68000 can be connected directly without going through another circuit. And JERRY uses the same interface (pretty much). So if TOM is in CPU32 mode (read the manual) then the processor (68000) and JERRY will see their external data BUS processed in 32 bits.

Now as I said, you can use another processor, even an x86 if you want, but it will be necessary to put several logic circuit to manage the conversion between TOM and the external processor. This is what is done in the COJAG.

In the Jaguar, TOM is configured in mode "NO CPU32" (CPU32 disable), the 68000 and JERRY are therefore managed with an external BUS of 16 bits. However, the version of JERRY in the Jaguar is intended to work in 32 bits external. So the upper 16 bits are connected to + 5v to have stable inputs.

Oh, and you can also configure TOM to work without an external processor. This may be the case also in COJAGs






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users