JagStudio

[No One You Know]

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?

[No One You Know]

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.

[+CyranoJ]

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.

[No One You Know]

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.

[+CyranoJ]

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.

[No One You Know]

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.

[SlidellMan]

I think we should show this to Modern Vintage Gamer when the opportunity arises.

[+Stephen]

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?

[+CyranoJ]

11 minutes ago, Stephen said:

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

Fairy farts.

[+Stephen]

5 minutes ago, CyranoJ said:

Fairy farts.

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

[+Sauron]

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.

[+CyranoJ]

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.

[TheyAlwaysFckYouAtTheDriveThru]

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? 

 

[SlidellMan]

By the way, Cyrano, is it possible to use custom fonts in JagStudio?

[+CyranoJ]

8 minutes ago, SlidellMan said:

By the way, Cyrano, is it possible to use custom fonts in JagStudio?

Sure is, edit the fonts in the <projectname>\assets\FONTS folder

[+Gemintronic]

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.

 

[+mksmith]

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!

[+CyranoJ]

Might be worth creating new threads instead of making this one X+ pages long, there's lots of sub-chats going on in here

[LordKraken]

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 :))

[phoboz]

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.

[agradeneu]

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

[phoboz]

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 March 23, 2021 by phoboz

[agradeneu]

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 March 23, 2021 by agradeneu

[rayr]

This is great stuff. Thanks to all involved in creating Jag Studio and Raptor. I can't wait to start programming. Please let me know if I can donate to the Jag Studio and Raptor teams. I really appreciate all involved.

[+CyranoJ]

Thanks but no donations required. 

 

Reward us by making something cool!