Zerosquare Posted July 23, 2018 Share Posted July 23, 2018 (edited) Here's a clean version (generated from source files, not scanned) of the Jaguar schematic: https://www.mirari.fr/iS1N Source: https://www.chzsoft.de/asic-web/ASICs-new.zip Thanks to DEATH for finding and converting the file, and to Jonas for tracking the original source Edited July 23, 2018 by Zerosquare 18 Quote Link to comment Share on other sites More sharing options...
NeoGeo64 Posted July 24, 2018 Share Posted July 24, 2018 Very nice! Quote Link to comment Share on other sites More sharing options...
Cyprian Posted July 24, 2018 Share Posted July 24, 2018 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 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted July 24, 2018 Share Posted July 24, 2018 (edited) 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 July 24, 2018 by Clint Thompson Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 24, 2018 Share Posted July 24, 2018 So, does this mean reboot can start working on the Jaguar One X? 2 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 25, 2018 Share Posted July 25, 2018 /disregard/ edit Your detailed explanation seemed very reasonable and illuminating. Did you find new information that disproves your original thoughts? 2 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 25, 2018 Share Posted July 25, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted July 25, 2018 Share Posted July 25, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted July 25, 2018 Author Share Posted July 25, 2018 Come on, Atari would never give inaccurate specs to the press. *cough* 850 million pixel per second *cough* 4 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted July 25, 2018 Share Posted July 25, 2018 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.. 1 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted July 25, 2018 Author Share Posted July 25, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 25, 2018 Share Posted July 25, 2018 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 (as long as nothing else was running, and you had a fair wind and good fumes ventilation ) 4 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted July 25, 2018 Share Posted July 25, 2018 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? Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 26, 2018 Share Posted July 26, 2018 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. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted July 26, 2018 Author Share Posted July 26, 2018 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? 1 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted July 26, 2018 Share Posted July 26, 2018 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) Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 30, 2018 Share Posted July 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted July 30, 2018 Author Share Posted July 30, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
PeterG Posted July 30, 2018 Share Posted July 30, 2018 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. Haha thanks for reminding me. 2 Quote Link to comment Share on other sites More sharing options...
DEATH Posted August 1, 2018 Share Posted August 1, 2018 (edited) 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 August 1, 2018 by DEATH Quote Link to comment Share on other sites More sharing options...
Lost Dragon Posted August 1, 2018 Share Posted August 1, 2018 (edited) 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 August 1, 2018 by Lost Dragon 3 Quote Link to comment Share on other sites More sharing options...
Lost Dragon Posted August 1, 2018 Share Posted August 1, 2018 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. 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. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted August 1, 2018 Share Posted August 1, 2018 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. 4 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted August 1, 2018 Share Posted August 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
DEATH Posted August 1, 2018 Share Posted August 1, 2018 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.