JRISC C compiler now incorporated into my SDK environment

[Cyprian]

or instead slow 68000 or not so cheap 68030 Atari could add a third JRisc processor

[agradeneu]

1 hour ago, Clint Thompson said:

.

 

 

There's no denying more cache and RAM would have helped (hey, it was originally suppose to have 4MB) but to suggest the 68030 is only slightly faster at 9 MIPS compared to a 68000 at 3 MIPS? No way. That's literally 3 times faster, not to mention the 32-bit bus access.

 

 

Or you could have eliminated the 68K entirely, then you wouldn't have to transfer anything.

 

 

*fixed that for you that's because the 68k was never intended to go into the Jag in the first place

 

TOM and Jerry are both rated at 26 MIPS, just to put that into perspective. 

 

The 68K was put in there to make porting games easier and it is a well known chip in game programming. 

 

But it depends on the game, what components you should use.

 

Some rather impressive games, like Rayman or even Doom,  are still using some 68K, so what is the problem? 

 

[42bs]

3 hours ago, Clint Thompson said:

Here's a question for you: Why is the CoJag's ROM bus 64-bit wide but the Jaguar is only 32-bit?

You cannot compare an arcade machine with a consumer device. How many ROM cards do you build for an arcade machine? The cost and size does not matter. But for a consumer product, it does. How large would a Jaguar game card be with a 64bit data bus?

 

And BTW, the ROM bus is not the bottle neck.

[42bs]

3 hours ago, Clint Thompson said:

It would have been far more ideal to release at $299 and drop the ADC. How much was the 68020? $45? That would have been a fair compromise.

At some point during development, you need to make a design descision. It is useless to later think about the if and when. That's for the second revision which in this case never came.

 

[+CyranoJ]

9 hours ago, Cyprian said:

or instead slow 68000 or not so cheap 68030 Atari could add a third JRisc processor

 

It has just been pointed out that the JRiscs are flawed critically for making a full game due to the bugs, and you want them to add another bugged piece of silicon to the system?  How does that help?

 

The Jaguar setup is actually really well designed. If the JRiscs didn't have any bugs and could run out of main flawlessly none of this would be an issue.

 

They were bugged, they couldn't - it was a deal breaker at the time, and still is for the most part today. It was utterly impractical to use them exclusively for large projects. The 68000 was never the problem, the jRISC bugs were.

[+Stephen]

On 11/21/2023 at 1:53 AM, CyranoJ said:

Now Jagchris has this there's gonna be no holding him back.  I can't wait!

Does this run GPU code in main for the awesome unleash the POWA?!?

[dilinger]

To paraphrase the author of the "gpu in main science" paper.
"At the end of the day this is a hobby, if you want to run your code in main, go for it! have fun! enjoy what you are doing! but just don’t expect it to be the most snappy code."

[JagChris]

4 hours ago, dilinger said:

To paraphrase the author of the "gpu in main science" paper.
"At the end of the day this is a hobby, if you want to run your code in main, go for it! have fun! enjoy what you are doing! but just don’t expect it to be the most snappy code."

If you're going to paraphrase people then add context or you just make things worse.

 

It will be snappier than 90% of the 68k code. For the other 10% use the local. 

[+CyranoJ]

4 hours ago, JagChris said:

If you're going to paraphrase people then add context or you just make things worse.

 

It will be snappier than 90% of the 68k code. For the other 10% use the local. 

 

Says the guy with utter nonsense in his signature

[+Sauron]

18 hours ago, 42bs said:

At some point during development, you need to make a design descision. It is useless to later think about the if and when. That's for the second revision which in this case never came.

 

That's exactly it. It's easy for us in hindsight to look back and say "Atari should've just thrown in X processor instead of Y", but that's really sidestepping much of the issue here. Using the much cheaper 68000 in the Jag was a design choice that was most likely made more for budgetary and pricing concerns than anything else. Atari had a very limited budget with the design and development of the Jag in comparison to its contemporaries, which meant that making compromises on hardware components for the sake of saving a few $$$ wasn't just the ownership being cheap, it was most likely a necessity. And when you're comparing a $10 processor to a $40 processor, that can make a huge difference when it comes to component purchasing and manufacturing costs for a mass-produced product. As it stands, considering the limited budgets and other challenges that Atari was facing at the time, just being able to bring the Jaguar in its final state to market was a huge undertaking that they were able to pull off, and saving a few dollars on certain components is quite possibly what allowed it to happen at all.

 

[JagMod]

The 68000 probably is the only bug free silicon in the jag!
However, its 16 bit data bus, no instruction cache, and 13 MHz clock doesn't help.

 

The 68EC020 would have been a better choice.
Very inexpensive at the time since it didn't have the MMU and only 24 address lines.
What it did have is:
--the ability to run at 26 MHZ instead of 13
--256 byte instruction cache
--32 bit data bus

 

Tom is full of bugs and compromises, but I always thought the OP not having its own cache for the display list is what cripples the system the most.
 

[JagChris]

4 hours ago, JagMod said:

The 68000 probably is the only bug free silicon in the jag!
 

 

Tom is full of bugs and compromises, but I always thought the OP not having its own cache for the display list is what cripples the system the most.
 

Well hell if the OP has all those fixes it would really kick ass. As it is the Native demo according to statements made by Duranik indicate that it's only 1/8th of what its capable of.

 

The biggest crippler is the 68k. The Jag needs a GPU compiler because not everyone could handle wrangling with it at that level like Duranik, Eclipse, Scatologic etc. That's why Atari tried what they did to get lesser programmers away from the 68k.

 

It would have and still would be a game changer.

[+Stephen]

1 hour ago, JagChris said:

As it is the Native demo according to statements made by Duranik indicate that it's only 1/8th of what its capable of.

You mean the demo that can't play sound?  Awesome that at full buss saturation without sound, it's only using 1/8th of the system's capabilities.  I just wonder what it could do if blast processing was used, or maybe they used GPU in main(TM).

[JagChris]

8 hours ago, Stephen said:

You mean the demo that can't play sound? 

It doesn't have sound not that it can't play sound. Duranik said it shouldn't have problems playing sound. They ran out of space I tgink.

 

Quote

Awesome that at full buss saturation without sound, it's only using 1/8th of the system's capabilities.  I just wonder what it could do if blast processing was used, or maybe they used GPU in main(TM).

 

Yes. So Natives advertising talks about over a 100 objects on-screen at once etc. 

 

 

Everyone take a look. Objects, 5 layer paralax, transparencies etc. That is full screen at full bandwidth. That's what it looks like. Sure there are things they could do to improve that. More efficient caching system, whatever. And they said they used very very little 68k.

 

When asked a while ago what they would do to improve  NATIVE they said ONE of the things they would do is branch the display list. Apparently they weren't aware of it at the time.

 

Everyone remembers Oliver of Super burn out fame.

 

Quote

So the way I resolved that was to actually use the branches of the display list, by having 3 levels of branches I was actually able to split the screen in 8 horizontal bands of 30 pixels or so. Then I just had to fill each of the sub-display lists separatly, thus I just had 125+ sprites per display list, but 1000+ total displayed on the screen.  That way each horizontal line had almost full bandwidth

so we got two proven developers throwing out the same numbers. 100 or so objects for full bus saturation.

 

Splitting the screen into 8 slices with each slice getting... well you guys get the picture.

 

NATIVE demo isn't the limit. Its only 1/8th of what the Jag is capable of.

Edited November 28, 2023 by JagChris

[+CyranoJ]

Amazing, you have no comprehension at all of what they are saying.

But, as always, I'm sure you (think) you know best. Far more than the other developers here in the thread.

 

To be honest, I don't know why you are even here. Your total contribution over the decades is zero. Nothing here is ever good enough for you, all you do is moan and complain or be obtuse, and, frankly, your two-faced nature is plainly obvious to anyone who sees what you post outside of this place.

[agradeneu]

5 hours ago, Stephen said:

You mean the demo that can't play sound?  Awesome that at full buss saturation without sound, it's only using 1/8th of the system's capabilities.  I just wonder what it could do if blast processing was used, or maybe they used GPU in main(TM).

Eh, do you have a glimpse of an idea of why it has not sound?  

 

 

 

Edited November 28, 2023 by agradeneu

[agradeneu]

41 minutes ago, JagChris said:

 

 

 

 

 

NATIVE demo isn't the limit. Its only 1/8th of what the Jag is capable of.

Can you explain how you could measure 1/8? Source?

 

Maybe yes, 8 levels instead of 1 and sound.

[agradeneu]

10 hours ago, JagMod said:

The 68000 probably is the only bug free silicon in the jag!
However, its 16 bit data bus, no instruction cache, and 13 MHz clock doesn't help.

 

The 68EC020 would have been a better choice.
Very inexpensive at the time since it didn't have the MMU and only 24 address lines.
What it did have is:
--the ability to run at 26 MHZ instead of 13
--256 byte instruction cache
--32 bit data bus

 

Tom is full of bugs and compromises, but I always thought the OP not having its own cache for the display list is what cripples the system the most.
 

Luckily we got Gorf then. :_)

 

Seriously, I  dont like the wording of "crippled". The system is very capable if programmers know how to handle it. 

[JagChris]

1 hour ago, agradeneu said:

Can you explain how you could measure 1/8? Source?

 

Maybe yes, 8 levels instead of 1 and sound.

I just explained the source. Re-read the post plz. 

Edited November 28, 2023 by JagChris

[JagChris]

51 minutes ago, CyranoJ said:

Amazing, you have no comprehension at all of what they are saying.

But, as always, I'm sure you (think) you know best. Far more than the other developers here in the thread.

 

To be honest, I don't know why you are even here. Your total contribution over the decades is zero. Nothing here is ever good enough for you, all you do is moan and complain or be obtuse, and, frankly, your two-faced nature is plainly obvious to anyone who sees what you post outside of this place.

Wow I thought that would be good news. And listen to developers? Well that is actually where I heard it from. Duranik the developer. They posted the statement here for all to see.

 

Can you explain to me where I am wrong? The sources are available for everyone to see.. Can you show me where they did actually branch the display list? Can you show me where I'm confused/mistaken. 

 

I'm happy to admit when I'm wrong. Well not always but you know...

Edited November 28, 2023 by JagChris

[Duranik]

Why we didn't add any sound at all, I cannot remember. The simplest explanation is probably that we didn't know how to do it because the only pieces of source we had were two examples of a Jaguar head scaling in and out, and the infamous Jaguar underground docs. This was pretty much at the very beginning of the internet; information was not as easily available as it is today.

At first, the game was completely running on the 68k and was slowing down heavily at maybe around 40-50 objects. This engine was then converted to the GPU, and it had no problems with object list slowdowns anymore (at some parts, the object processor is running out of bandwidth, but that's another story).

Hardware prices are hard to find for this time, but here is a list with the cost of goods for the Amiga CD32 and 1200, which have some comparable specs and mainboard complexity. You can see that 2MB alone was $50; even the 68EC020 is $8.

Edited November 28, 2023 by Duranik

[+CyranoJ]

26 minutes ago, Duranik said:

(at some parts, the object processor is running out of bandwidth, but that's another story).

 

Appreciate your comments, some great coding!

And thank you for clarifying the above, because ArseChris has been denying that for as long as he's been here.

[JagChris]

6 minutes ago, CyranoJ said:

 

Appreciate your comments, some great coding!

And thank you for clarifying the above, because ArseChris has been denying that for as long as he's been here.

I only denied being able to see it to the extent you only could. 

[agradeneu]

3 hours ago, JagChris said:

 

Yes. So Natives advertising talks about over a 100 objects on-screen at once etc. 

 

 

 

 

NATIVE demo isn't the limit. Its only 1/8th of what the Jag is capable of.

Basically you took the number of 1000 sprites by Oliver out of context and applied it to Native for a lofty claim no dev seriously suggested. I dont think that proves anything. 

Actually FACTs demo renderns even more than 1000 sprites, but we should not compare Apples with Oranges.

Edited November 28, 2023 by agradeneu

[JagChris]

1 hour ago, agradeneu said:

Basically you took the number of 1000 sprites by Oliver out of context and applied it to Native for a lofty claim no dev seriously suggested. I dont think that proves anything. 

Actually FACTs demo renderns even more than 1000 sprites, but we should not compare Apples with Oranges.

OK...