Jump to content

CyranoJ

Recommended Posts

On 2/13/2021 at 8:09 PM, Clint Thompson said:

You can create a 2MB program that will load from JagCD using Jiffi. Outside of that and memory track module support, I believe that’s all you’re going to see now that the focus is shifting to SD. It doesn’t make sense to support a mostly dead format where a superior option exists tbh. 

Is that not CD emulation? Or does it support much higher bandwidth?

Link to comment
Share on other sites

On 2/15/2021 at 2:13 AM, CyranoJ said:

First, I apologise for editing your post... I'm new to this moderator lark ;)
To answer your question.
 

RAPTOR API (At the heart of this) is GPU (Tom) bound.

Whatever audio engine you select is DSP (Jerry) bound.

Your application code will run on the 68000 interfacing with the DSP/GPU via library function calls to accelerate performance.

I would have thought anything modern would not use 68K at all but compile for Tom or Jerry instead? Is there really enough free bus time in Jag programs for using the 68K gto work well? I suppose APIs like these are a tradeoff between ease and efficiency of use and maximum performacne and that is the way that it has always been.

  • Like 1
Link to comment
Share on other sites

Just now, No One You Know said:

I would have thought anything modern would not use 68K at all but compile for Tom or Jerry instead? Is there really enough free bus time in Jag programs for using the 68K gto work well? I suppose APIs like these are a tradeoff between ease and efficiency of use and maximum performacne and that is the way that it has always been.

Don't drink the cool-ade :)

 

Plenty of cycles to go around for all. As for 'are there enough cycles' - check whats been made in the last decade.

Link to comment
Share on other sites

1 minute ago, CyranoJ said:

Don't drink the cool-ade :)

 

Plenty of cycles to go around for all. As for 'are there enough cycles' - check whats been made in the last decade.

What do you mean "don't drink the cool-ade"? I thought everything that did anything didn't use 68K? Just seeing whatever has been made recently looks like doesn't tell you anything.

Link to comment
Share on other sites

29 minutes ago, No One You Know said:

What do you mean "don't drink the cool-ade"? I thought everything that did anything didn't use 68K? Just seeing whatever has been made recently looks like doesn't tell you anything.

Plenty of threads about GPU vs 68000 etc in the main forum.  Not getting into it here - in the release thread but feel free to make another one.

 

In short, "everything that did anything" is a bit of a blanket statement, lots of things use the 68000. And many of them are great.  It's not what CPU you use, but how you use it.

  • Like 3
  • Thanks 2
Link to comment
Share on other sites

23 hours ago, CyranoJ said:

Plenty of threads about GPU vs 68000 etc in the main forum.  Not getting into it here - in the release thread but feel free to make another one.

Ok. This is the first time I have looked at this and I didn't get it.

23 hours ago, CyranoJ said:

In short, "everything that did anything" is a bit of a blanket statement.

Yes that is very true.

23 hours ago, CyranoJ said:

Lots of things use the 68000. And many of them are great.

I didn't know that. I thought it was only ports of ST and Amiga stuff that used it.

23 hours ago, CyranoJ said:

It's not what CPU you use, but how you use it.

That sounds like a cliche motivational speech from a film. But in this case they are both the same thing.

Link to comment
Share on other sites

On 2/21/2021 at 7:06 PM, CyranoJ said:

Plenty of threads about GPU vs 68000 etc in the main forum.  Not getting into it here - in the release thread but feel free to make another one.

 

In short, "everything that did anything" is a bit of a blanket statement, lots of things use the 68000. And many of them are great.  It's not what CPU you use, but how you use it.

So wait - you're saying that Jag Studio doesn't pump everything through main in GPU?  How the hell is it so performant?

  • Haha 1
Link to comment
Share on other sites

9 hours ago, Stephen said:

Two 32-bit fairies flitting about in parallel, or a single 64-bit huffing down the road?

It's more complicated than that. As anyone knows, there can be the loud, booming farts and then the silent but deadly ones. On the Jag, the silent but deadly ones are handled by the 68000, and only come in at half the clock speed and a quarter of the bus bandwidth. The GPU is responsible for the loud, booming farts.

  • Like 1
  • Haha 2
Link to comment
Share on other sites

9 hours ago, Stephen said:

Two 32-bit fairies flitting about in parallel, or a single 64-bit huffing down the road?

The fairy fart particles suspended in the air are inhaled by the unicorns and mixed in their digestive system to be delivered as unicorn poo, which is used to power the JagCD.

  • Like 1
  • Haha 2
Link to comment
Share on other sites

  • 3 weeks later...
On 2/5/2021 at 11:32 PM, CyranoJ said:

You joke, but the way we've built this if we can find an extendable compiler it might be possible.  I'm partial to a bit of Pascal, myself.

 

However, I suspect that Assembler, BASIC and C cover 99.999999% of everyone. Warp 10 is impossible :)

Pascal would be fine for me, the language of choice in the firm I work for - I kid you not, it is 2021 and not 1988? 

 

  • Like 2
Link to comment
Share on other sites

On 2/13/2021 at 3:00 PM, Lavalamp said:

Would be nice to have Visual Studio Code integration like the awesome  Atari Dev Studio for 7800 Basic.

 

mksmith was kind enough to entertain my questions about this:

On 2/16/2021 at 9:48 PM, mksmith said:

Hi @Gemintronic! That certainly could be a consideration but previously looking at other languages (compilers and emulators) to include the size of this extension becomes unwieldly big - way bigger than what really is intended.  The ADS core code could definitely be used to start a separate extension if that's something the team is interested in. 

 

So, it's up to the community to figure out how to hack/mod Visual Studio extensions and make a JagStudio specific option.  Unfortunately,  the people who are keen for an integrated IDE are exactly the same people who do not have the skills to take a stab at it..  at least not yet!  Gives me something to aim for.

 

Link to comment
Share on other sites

2 hours ago, Gemintronic said:

 

mksmith was kind enough to entertain my questions about this:

 

So, it's up to the community to figure out how to hack/mod Visual Studio extensions and make a JagStudio specific option.  Unfortunately,  the people who are keen for an integrated IDE are exactly the same people who do not have the skills to take a stab at it..  at least not yet!  Gives me something to aim for.

 

I'm certainly happy to put this on to my list to start a new extension - unfortunately my family commitments are pretty busy just ATM but I will take a look soonish!

  • Thanks 1
Link to comment
Share on other sites

8 hours ago, Gemintronic said:

Unfortunately,  the people who are keen for an integrated IDE are exactly the same people who do not have the skills to take a stab at it..  at least not yet!

Well if you can code, you probably know how to use gcc so you can definitely take a stab at setting an env. in visual code. It's really not the end of the world, simply a tedious and boring task.

 

On the other hand, I created a lightweight environment around Jagstudio in sublime text and while I don't have all the fancy features that comes with vs code, it's enough for my needs for now. (compile, run, quick search and replace, basic code analysis, what else do you need :))

Link to comment
Share on other sites

On 2/23/2021 at 12:43 AM, No One You Know said:
On 2/22/2021 at 1:06 AM, CyranoJ said:

Lots of things use the 68000. And many of them are great.

I didn't know that. I thought it was only ports of ST and Amiga stuff that used it.

Yes, and probably also a good option for Genesis/Megadrive ports :)

 

However, no program on the Jaguar can do without the 68000.

It is the main CPU of the Jaguar, the other ones are co-processors which can only be given tasks by the 68000. So the co-processors cannot do anything by themselves, unless they are told what to do by their manager (If I got it right, please correct me if I am wrong?)

 

Usually you don't need super high performance for game logic, so in many cases the game logic is executed on the 68000. The nice thing is that it can do some game logic in parallel with the GPU, as it focuses on handling the graphical stuff at the same time. So the combination of this gives better performance than to put it all on one RISC CPU.

Link to comment
Share on other sites

4 hours ago, phoboz said:

Yes, and probably also a good option for Genesis/Megadrive ports :)

 

However, no program on the Jaguar can do without the 68000.

It is the main CPU of the Jaguar, the other ones are co-processors which can only be given tasks by the 68000. So the co-processors cannot do anything by themselves, unless they are told what to do by their manager (If I got it right, please correct me if I am wrong?)

 

Usually you don't need super high performance for game logic, so in many cases the game logic is executed on the 68000. The nice thing is that it can do some game logic in parallel with the GPU, as it focuses on handling the graphical stuff at the same time. So the combination of this gives better performance than to put it all on one RISC CPU.

Some coders and Atari have suggested shutting off the 68K completely (e.g. the likes of J. Carmack, M. Rosocha and Leonard Tramiel), so I guess TOM and Jerry can work just fine without it.

I also found this info:

http://atariowlproject.blogspot.com/2009/10/atari-jaguar-homebrew-whats-this-lay.html

  • Like 2
Link to comment
Share on other sites

1 hour ago, agradeneu said:

Some coders and Atari have suggested shutting off the 68K completely (e.g. the likes of J. Carmack, M. Rosocha and Leonard Tramiel), so I guess TOM and Jerry can work just fine without it.

I also found this info:

http://atariowlproject.blogspot.com/2009/10/atari-jaguar-homebrew-whats-this-lay.html

Interesting, but I think the theoretical section trying to compare the performance between a RISC processor and a CISC processor (the 68000) using the benchmark MIPS (million of instructions per second) is a little bit like comparing apples and pears.

Because a RISC processor is targeting to execute one instruction per clock cycle (if the pipeline is kept full at all times), while on a CISC processor an instruction can take a variable ammount of clock cycles to execute. We also know that due to bugs, the pipeline of the RISC processor needs to be cleared, or filled with junk instructions, which makes the MIPS comparison even more complex.

So perhaps something can be gained when running a very tight loop on the RISC CPU, and the Jaguar really doesn't do anything meaningfull, but as soon as you start to use the object processor, and the blitter (otherwise you won't see anything on the screen). The bus will be occupied by these resources as well, so the question is really how much you would gain by disabling the 68000 when many other system resources still needs to use the bus?

Edited by phoboz
  • Like 3
Link to comment
Share on other sites

1 hour ago, phoboz said:

Interesting, but I think the theoretical section trying to compare the performance between a RISC processor and a CISC processor (the 68000) using the benchmark MIPS (million of instructions per second) is a little bit like comparing apples and pears.

Because a RISC processor is targeting to execute one instruction per clock cycle (if the pipeline is kept full at all times), while on a CISC processor an instruction can take a variable ammount of clock cycles to execute. We also know that due to bugs, the pipeline of the RISC processor needs to be cleared, or filled with junk instructions, which makes the MIPS comparison even more complex.

So perhaps something can be gained when running a very tight loop on the RISC CPU, and the Jaguar really doesn't do anything meaningfull, but as soon as you start to use the object processor, and the blitter (otherwise you won't see anything on the screen). The bus will be occupied by these resources as well, so the question is really how much you would gain by disabling the 68000 when many other system resources still needs to use the bus?

Why dealing with abstract questions, the proof is in the (empirical) pudding: Doom, you can't get those high FPS running the engine on the 68K. So Carmack and the other guys made a valid point I guess. 

But this was from a time when the Jag tried to compete with the Playstation/Saturn. 

So for hombrews it's not really that relevant anymore(?), most projects are totally fine using the 68K, because its still lots of possibilties to make a great game.

As long as the 68K does not slowdown the game, who cares which processor someone uses ;-)

 

Edited by agradeneu
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...