30 replies to this topic

[TAdams]

I would very much appreciate a list of hardware/software required to program for the Jaguar. I would be interested also in links to information, I have found some information, but even more dead links.It is like reading a book that is missing chapters I appreciate any information you can provide!

Best regards,
TAdams

[Elrond]

First thing you're going to need is the Starcat development CD, without it you will not be able to code the custom chips (blitter,GPU ,etc) Assembly language is important, it looks very daunting, but after you've started to learn it you'll find the opposite is true. You can however, code in C. I have a GPU/DSP official C compiler, but I need the official Atari (main) Compiler. Linking to files from your C main code looks a little tough but I havent got that far yet.
You will need a custom build cable to download code from the PC to the JAGUAR (which many electronic stores can make for you) and a BJL or similar(behind Jaggy Lines) which incidentally is built into the SE version of protector so you wont need to modify your Jag. Hope this helps

Invest your time and relax and enjoy it is my advice.

[EmOneGarand]

Elrond, on Wed Dec 7, 2005 4:53 PM, said:

First thing you're going to need is the Starcat development CD, without it you will not be able to code the custom chips (blitter,GPU ,etc) Assembly language is important, it looks very daunting, but after you've started to learn it you'll find the opposite is true. You can however, code in C. I have a GPU/DSP official C compiler, but I need the official Atari (main) Compiler. Linking to files from your C main code looks a little tough but I havent got that far yet.
You will need a custom build cable to download code from the PC to the JAGUAR (which many electronic stores can make for you) and a BJL or similar(behind Jaggy Lines) which incidentally is built into the SE version of protector so you wont need to modify your Jag. Hope this helps

Invest your time and relax and enjoy it is my advice.

I havn't been able to acquire one of Starcats Dev CD's, where can I get one?

[Matthias]

Hello!

EmOneGarand, on Tue Sep 19, 2006 1:32 AM, said:

Elrond, on Wed Dec 7, 2005 4:53 PM, said:

First thing you're going to need is the Starcat development CD...

I havn't been able to acquire one of Starcats Dev CD's, where can I get one?

You can order it here:
Starcat Developments products

Please don't forget that using this CD is just a matter of convenience, it contains a collection of files which you might find (or could have found) at several places on the internet too, like the basic Jag-DevKit which you can find for example on Michael (Belboz) Hill's Atari-page.

Best regards
Matthias

[EmOneGarand]

Matthias, on Mon Sep 25, 2006 3:57 PM, said:

Hello!

EmOneGarand, on Tue Sep 19, 2006 1:32 AM, said:

Elrond, on Wed Dec 7, 2005 4:53 PM, said:

First thing you're going to need is the Starcat development CD...

I havn't been able to acquire one of Starcats Dev CD's, where can I get one?

You can order it here:
Starcat Developments products

Please don't forget that using this CD is just a matter of convenience, it contains a collection of files which you might find (or could have found) at several places on the internet too, like the basic Jag-DevKit which you can find for example on Michael (Belboz) Hill's Atari-page.

Best regards
Matthias

Thanks alot Matthias!

[JagChris]

Cheapest list of recommended requirements to develop on the Jaguar:

1.) Older PC with DOS based OS such as Windows 95 or 98 with parallel port. (Forget Windows M.E.)

2.) BJL adapter and connecting Parallel cable for PC to Jaguar transfers.

3.) BJL Program, either via Protector SE or BJL CD. The BJL CD can be gotten in the above given link from Belbozs' website. Click on the downloads tab then scroll down to the 'Jaguar downloads' section.

THERE IS NO NEED TO PHYSICALLY MODIFY YOUR JAGUAR ANYMORE TO USE BJL

I know capital letters in bold is annoying, but you wouldn't believe how many people still think you need to chop up your Jaguar to use BJL. And I didn't list it(BJL ROM modification) as an option anymore because it just seems like a pointlessly destructive option now whose time has come and gone.

4.) The Official Atari dev kit, also available on Belboz's website in the same area the BJL CD download is. Follow step 3 above.

Burning the BJL CD from Belboz's website is the cheapest BJL option.

You can then go about building your own custom BJL cable for the PC to Jaguar connection, the schematics of which are included in the Zip for the BJL. I'll post them here anyway for convenience.



Or you can buy the BJL adapter from MORE THAN GAMES. You'll see it described as the 'BJL games transfer system adapter for computer parallel port(RixCAT)'. That's all that's needed besides the use of a common parallel cable with it for cable connection to the PC.

Another BJL method for those who don't have a JagCD player is the Protector SE cartridge from Songbird Productions. It has BJL built into the cartridge. You will still need to buy or build the parallel cable and adapter. And you'll still need to get the PC side uploader program. So you'll probably end up downloading Belboz's BJL files anyway even if you're not going to burn a BJL CD.

It is also recommended to use an older system with a DOS based OS. Such as Windows 95 or 98.(Not M.E. Reports of trouble using that OS with Jag development stuff.) The Jaguar development tools and the BJL seem to not want to work very reliably, or at all with the M.E.,NT, 2000 and XP OS's because they weren't designed for them, having been designed back in '93 or so and they are DOS based.

Some notes on using BJL with the official Atari dev. kit that can be found and downloaded from Belboz's site. The way its initially setup does not init the video correctly with the BJL and when you upload stuff you've compiled to the BJL setup you just get a blank screen.

I've included the attached video.s file which must replace the standard video.s in the 3D/LIB directory of the dev setup so the compiles will work with BJL. I've included the whole file although only one line is changed compared to the original. *

 VIDEO.zip   2.64K   140 downloads

Also another thing. The make.exe that comes with the Atari dev kit is pure crap. It should also be replaced first thing with NMAKE 1.5

Here's also a link to Matthias BJL page where he goes more in depth into BJL usage:

http://www.mdgames.de/bjl_loader.htm

If you got money to blow, you can buy an Alpine board. I am not sure where you can get one of those as I don't have that kind of money to blow.

I have not listed or went into any of the Linux setups, or the Apple MAC setups as I have no experience with either. Someone else will have to post of their experiences with that. Unfortunately my experiences are only with the standard PC setup and M$ OS installed.

However, owners of the Atari ST/TT/Falcon line of computers who are interested in Jag developement are in luck. GT Turbo has graciously started a thread to help get you on your feet with Jag development..

http://www.atariage....howtopic=101565


*Special thanks to Belboz again for discovering the problem and implementing the fix for BJL.

Edited by JagChris, Wed Jan 30, 2008 11:25 PM.

[Clint Thompson]

Drive, Motivation, Patience, Time, (repeat xInfinateLoop).

I'll buy you dinner when you complete your first game.
It's not much, but it's something.

[JagChris]

TAdams, on Mon Nov 28, 2005 5:56 AM, said:

I would very much appreciate a list of hardware/software required to program for the Jaguar. I would be interested also in links to information, I have found some information, but even more dead links.It is like reading a book that is missing chapters I appreciate any information you can provide!

Best regards,
TAdams

I just noticed this post is from a year ago. I wonder if he ever found what he was looking for? I'll send him a PM.

[JagChris]

Elrond, on Wed Dec 7, 2005 12:53 PM, said:

Assembly language is important, it looks very daunting, but after you've started to learn it you'll find the opposite is true. You can however, code in C. I have a GPU/DSP official C compiler, but I need the official Atari (main) Compiler. Linking to files from your C main code looks a little tough but I havent got that far yet.

Unfortunately there is no GPU/DSP official C compiler. There is only the GCC compiler included in the Atari Jaguar development tools. In it's current state you cannot fully exploit the GPU and DSP. However, the guys at 3D Stooges are working on a new development system for the Jag that will hopefully change all that. But for now for a C compiler it's the best we got.

You can, like you said, program it fully in Assembly and exploit all the power the system has to offer.

[jaguar_fan]

JagChris, thanks for all these helpful informations.

[JagChris]

You're welcome.

[GT Turbo]

JagChris, on Fri Jan 19, 2007 8:48 AM, said:

Elrond, on Wed Dec 7, 2005 12:53 PM, said:

Assembly language is important, it looks very daunting, but after you've started to learn it you'll find the opposite is true. You can however, code in C. I have a GPU/DSP official C compiler, but I need the official Atari (main) Compiler. Linking to files from your C main code looks a little tough but I havent got that far yet.

Unfortunately there is no GPU/DSP official C compiler. There is only the GCC compiler included in the Atari Jaguar development tools. In it's current state you cannot fully exploit the GPU and DSP. However, the guys at 3D Stooges are working on a new development system for the Jag that will hopefully change all that. But for now for a C compiler it's the best we got.

You can, like you said, program it fully in Assembly and exploit all the power the system has to offer.

Using C on a Risc processor, is not a good choice, because only 4 Kbytes and 8 Kbytes of ram for the Gpu and the Dsp. C give too big code for this kind of processor.

GT Turbo (C.V.S.D., Jagware)

[JagChris]

GT Turbo, on Wed Jan 31, 2007 1:28 PM, said:

Using C on a Risc processor, is not a good choice, because only 4 Kbytes and 8 Kbytes of ram for the Gpu and the Dsp. C give too big code for this kind of processor.

GT Turbo (C.V.S.D., Jagware)

Flipping overlays in and out of the 4k/8k locals is no longer necessary.

Steve Scavone, CEO of 3D Stooges elaborates on the GPU/Main Ram hardware bug he has most recently squashed in the Jaguar:

Quote

The bug is one that would not allow the GPU to run code with jump/jr instructions in main ram reliably. According to the Atari at the time, the MMU (memory management unit)was the issue....though this certainly may have an affect on the problem, I think it is more related to how the MMU handles the instruction pipeline in main RAM. Its not broken, just different in main RAM.

The pipeline is how the instructions flow into the GPU from memory. The RISC processors grab more than one instruction per fetch. In local RAM this is not a problem. However, for some reason the pipeline seems to ignore the jump and JR instructions in some cases when running from main RAM. The story goes that the GPU can not jump across a page boundary reliably. This is now proven to be false. I have 'fixed' the GPU problem with a little trial and error coding.

The truth is if you remove all other processors from the bus, the GPU will run in both local and main and also allow jumps to and from either. The only trouble with that is the rest of the system is rendered useless! The only video you could have is the GPU writing directly to the line buffers and that wont be all that impressive. All sound would have to be internal to the DSP and it could never talk to the bus when the GPU was. Not at all practical. Fear not as there is a TESTED solution now.

So far I have a 36k program of GPU code running from main jumping all over the place across pages and all. With the source code from Brainstorm and this newfound discovery of mine, I can re write MADMAC to adhere to these rules. This would not only allow more effcient use of larger GPU code not having to any longer spend 300,000 cycles a second per 4k module in the GPU just to run it faster but it will also allow for a sensible C compiler for the main code.

If Atari at the time had explored further, they would have found that the Jaguar is a lot more capable than even they realized. It took me less than 2 weeks a few hours a nite to figure this out. this really could have made all the diference in the world.

Example: If you were blitting in 4 4k modules into the gpu every frame, thats 1,200,000 cycles a second wasted waiting for the blitter to load code in the local RAM. Yes the GPU takes some cycle hits running in main but it pales in comparison to the deady hits of running code this way. Now all you need to do is load a compact renderer ONCE into local RAM and simply call it when needed. All the translation and all can be efficiently done in main.

The 68k is still needed however, to assist the GPU in jumping between main and local RAM. I hope to discover a fix for this as well. I think I may already have too. Even if not the 68k is asleep except for a few cycles to re-aim and re-start the GPU, then its right back to bed, like it should have been! Experiments to follow!

Sincerely,

Steve Scavone,

CEO

Edited by JagChris, Fri Feb 2, 2007 4:34 PM.

[GT Turbo]

JagChris, on Fri Feb 2, 2007 11:33 PM, said:

Flipping overlays in and out of the 4k/8k locals is no longer necessary.

Steve Scavone, CEO of 3D Stooges elaborates on the GPU/Main Ram hardware bug he has most recently squashed in the Jaguar:

Yes i know, but i have one question in main ram how many cycles one instruction take ? Because if in main ram, each instruction need one or two cycles instead of one, we are wasting a lot of many cycles because the pipelining will be surely not enough (If it always exist) good like in internal ram because speed acces is not the same, don't forget that.

So how many cycles one instruction take ? That's the question. Never forget copying 4 Kilobytes with blitter in phrase don't take so much cycles and until now i've got a full Gpu sprite manager (Called Orianne) and it took only 2.5 Kilobytes.


GT Turbo (C.V.S.D, Jagware)

Edited by GT Turbo, Sun Feb 4, 2007 4:11 AM.

[GT Turbo]

Zerosquare has done a new version of Bjl Uploader :

http://www.jagware.o...h...post&p=4919

SebRmv has done a library for those who wanted to code on Jaguar :

http://www.jagware.o...h...post&p=7098


GT

Edited by GT Turbo, Sun Feb 4, 2007 4:10 AM.

[Atari_Owl]

GT Turbo, on Sun Feb 4, 2007 8:24 AM, said:

JagChris, on Fri Feb 2, 2007 11:33 PM, said:

Flipping overlays in and out of the 4k/8k locals is no longer necessary.

Steve Scavone, CEO of 3D Stooges elaborates on the GPU/Main Ram hardware bug he has most recently squashed in the Jaguar:

Yes i know, but i have one question in main ram how many cycles one instruction take ? Because if in main ram, each instruction need one or two cycles instead of one, we are wasting a lot of many cycles because the pipelining will be surely not enough (If it always exist) good like in internal ram because speed acces is not the same, don't forget that.

So how many cycles one instruction take ? That's the question. Never forget copying 4 Kilobytes with blitter in phrase don't take so much cycles and until now i've got a full Gpu sprite manager (Called Orianne) and it took only 2.5 Kilobytes.


GT Turbo (C.V.S.D, Jagware)

It is slower, but not as much slower as i initially implied in the 'Have we seen the best of the Jag thread', a lot depends on circumstances, and i was hitting the bus fairly hard at the same time. I fixed that with the re-write that occurred after the VMWare crash.

Plus bear in mind that VERY few GPU/DSP instructions execute in 1 cycle anyway since the registers are only dual port. Thats why when two register operands are used they take longer than cycle since there are 2 reads and a write..

Thus for add sub, imult, div, etc where 2 register inputs and an with a writeback are used you get around 16-17MIPS instead of 26.5MIPS which you would get with NOPs or moves.


Edit: For my purposes it is most efficient to keep the tight, frequently executed loops in local RAM and dip into main for the less frequently used routines.

Edited by Atari_Owl, Sun Feb 4, 2007 4:31 AM.

[JagChris]

GT Turbo, on Sun Feb 4, 2007 12:24 AM, said:

JagChris, on Fri Feb 2, 2007 11:33 PM, said:

Flipping overlays in and out of the 4k/8k locals is no longer necessary.

Steve Scavone, CEO of 3D Stooges elaborates on the GPU/Main Ram hardware bug he has most recently squashed in the Jaguar:

Yes i know, but i have one question in main ram how many cycles one instruction take ? Because if in main ram, each instruction need one or two cycles instead of one, we are wasting a lot of many cycles because the pipelining will be surely not enough (If it always exist) good like in internal ram because speed acces is not the same, don't forget that.

So how many cycles one instruction take ? That's the question. Never forget copying 4 Kilobytes with blitter in phrase don't take so much cycles and until now i've got a full Gpu sprite manager (Called Orianne) and it took only 2.5 Kilobytes.


GT Turbo (C.V.S.D, Jagware)

I'm not sure how many cycles one instruction takes in main ram but as you can see from above that unless flipping everything in and out of local can beat an over a million cycles of optimization, then it's not ideal.

Edited by JagChris, Mon Feb 5, 2007 2:20 AM.

[Orion_]

who need more than 4k+8k of code anyway ?
this million cycle optimization is only if you have more than 3 or 4 full gpu/dsp cache of code to blit per vbl ...

[Zerosquare]

Atari_Owl, on Sun Feb 4, 2007 11:23 AM, said:

Plus bear in mind that VERY
few GPU/DSP instructions execute in 1 cycle anyway since the registers are only dual port.

Thats why when two register operands are used they take longer than cycle since there are 2 reads and a write..

They do not always take longer ; this kind of pipeline stall only occurs if more than two different registers have to be accessed on the same cycle. So if there is no write-back from a previous instruction, or if the write-back involves a register that is being read, no cycles are wasted.

About the 'very few', I tend to disagree. Of course that depends heavily on the actual code you're writing, so maybe we've just had different experiences, but I was able to get more than 80% of active cycles (i.e. cycles where the processor is not stalling or executing a NOP). But that often means spending much time tweaking your algorithms to make them fit the particularities of the Jag RISC processors. This is not always worthwhile, either.

There's also something else that must be taken into account when using external RAM to execute code : fetching the instructions uses some of the bus' bandwith. So if your program is already bus-intensive (for example, by using the blitter extensively), this may slow things down.

Edited by Zerosquare, Sun Feb 4, 2007 2:27 PM.

[Atari_Owl]

Zerosquare, on Sun Feb 4, 2007 8:26 PM, said:

Atari_Owl, on Sun Feb 4, 2007 11:23 AM, said:

Plus bear in mind that VERY
few GPU/DSP instructions execute in 1 cycle anyway since the registers are only dual port.

Thats why when two register operands are used they take longer than cycle since there are 2 reads and a write..

They do not always take longer ; this kind of pipeline stall only occurs if more than two different registers have to be accessed on the same cycle. So if there is no write-back from a previous instruction, or if the write-back involves a register that is being read, no cycles are wasted.

About the 'very few', I tend to disagree. Of course that depends heavily on the actual code you're writing, so maybe we've just had different experiences, but I was able to get more than 80% of active cycles (i.e. cycles where the processor is not stalling or executing a NOP). But that often means spending much time tweaking your algorithms to make them fit the particularities of the Jag RISC processors. This is not always worthwhile, either.

There's also something else that must be taken into account when using external RAM to execute code : fetching the instructions uses some of the bus' bandwith. So if your program is already bus-intensive (for example, by using the blitter extensively), this may slow things down.

Of course it is highly dependent on application.

I still maintain that AS i stated when using imult, add, sub, etc the standard arithmetic instructions you WILL tend to get stalls.

Re: the BUS, yes thats what i already said.

Also the 80%, yes thats not too far from what i stated too. I'm not giving precise numbers here because it varies so much depending on what you're doing.

Edit: The FACT remains you WILL NOT under realistic coding circumstances get 26.5MIPS. SO the drop in speed from running from main is not as much as might be feared.

Who needs more than 4k + 8k?
Anybody doing a project complicated enough to require it... do you think?

Edited by Atari_Owl, Sun Feb 4, 2007 5:26 PM.

[JagChris]

Orion said:

who need more than 4k+8k of code anyway ?
this million cycle optimization is only if you have more than 3 or 4 full gpu/dsp cache of code to blit per vbl ...

Well like GT Turbo said...

GT Turbo said:

Using C on a Risc processor, is not a good choice, because only 4 Kbytes and 8 Kbytes of ram for the Gpu and the Dsp. C give too big code for this kind of processor.

Now creating a C compiler for the RISC's makes more sense now that the GPU main ram bug is squashed.

Edited by JagChris, Sun Feb 4, 2007 8:00 PM.

[GT Turbo]

JagChris, on Mon Feb 5, 2007 2:56 AM, said:

Now creating a C compiler for the RISC's makes more sense now that the GPU main ram bug is squashed.

A bad coder with the Gpu can only get 50% of it power, a bad coder plus a C compiler will only take something like 25%, 30% of it power. Perhaps having a C compiler can help a lot of people but don't expect to get all the power of the Gpu with this kind of things.


GT

[JagChris]

GT Turbo, on Sun Feb 4, 2007 11:07 PM, said:

JagChris, on Mon Feb 5, 2007 2:56 AM, said:

Now creating a C compiler for the RISC's makes more sense now that the GPU main ram bug is squashed.

A bad coder with the Gpu can only get 50% of it power, a bad coder plus a C compiler will only take something like 25%, 30% of it power. Perhaps having a C compiler can help a lot of people but don't expect to get all the power of the Gpu with this kind of things.


GT

JagMod would probably disagree with you regarding how well C can compile code, and he is reported to be a C whiz.

A fully functional C compiler for the Jag would probably cut development time for a determined Jag developer at least in half if not more.

Also, your post assumes every one of the C coders will be bad coders. Nevertheless even bad coders can become good coders with practice.

[GT Turbo]

JagChris, on Mon Feb 5, 2007 8:56 AM, said:

JagMod would probably disagree with you regarding how well C can compile code, and he is reported to be a C whiz.

JagMod can disagree or agree with me, he is perhaps a C wizz, it's his right, i don't know him, i can't talk about him. But you're saying that a compiler his better than human mind... How many compilers can do self modifying code, or generated code ? Any, can you count cycles in C program ? No how do you want to optimize something if you don't know time taken for that ?

JagChris, on Mon Feb 5, 2007 8:56 AM, said:

A fully functional C compiler for the Jag would probably cut development time for a determined Jag developer at least in half if not more.

I fully agree with you, but C give more than half of his asm size at all programs written with. Never forget, Jaguar is not a PC, we've got only 2 megs of ram.

JagChris, on Mon Feb 5, 2007 8:56 AM, said:

Also, your post assumes every one of the C coders will be bad coders. Nevertheless even bad coders can become good coders with practice.

No, i've never told that. There is a lot of good C coders, i talk with some everyday, i'm too bad in C, but how many of them think the ASM give faster, better result and smaller program than C.

Just a question how many people have done an Boosector intro (Atari demo) (480 bytes) in C ? Any because it's impossible. Using C can be a good choice for a lot of things, but i think not on Jaguar or for some special applications.

GT

[Orion_]

well, you can code in C on jaguar if you are lazy, but don't expect speed nor quality results ...