Jaguar C Programming examples? C experiences?

[Starcat]

Hello everybody!

 

I know this topic isn't entirely new, but up to this point, I couldn't find good tutorials or examples on using Jaguar C to develop games. Of course C isn't exactly the strong side of the Jag and there are libs like the removers lib.

However it's my impression, that except for the Jagware people possibly, nobody is really using it. Correct me if I'm wrong.

It just seems like such a waste, if this really works well.

A lot of great games could be made with more attention to the idea than the code (as C is just faster to develop with than asm).

 

I'd really like to see a good hello world tutorial and also some background information how developing a jag program in C works compared to assembler.

For example, what functions are available? How can one modify or add own assembler routines to the program?

To those using an existing library such as the removers lib, what do you think of it and do you feel anything important is missing?

 

Regards, Lars.

[Matthias]

Hello Lars!

 

There is a lot of stuff done in C for the Jaguar:

Programs and tools written and provided by Atari like the MemoryTrack-Manager,

up to games like Doom by id software,

and the 3 games found on my Double Feature #1-CD are also C-based (but not the game-select-menu).

 

Mixing 68000-assembler and C is quite easy, just put an understroke "_" in front of the names of your assembler-functions to allow the C-functions to recognize them (and vice-versa), and learn how to access the C-function-parameters via the stack properly.

 

As you said, the weakest point of doing C-development is (or was) the lack of a Jaguar-specific library, so most time there is a lot of assembler-functions i add to the "C"-projects.

 

And as a sidenote: I even used several times the RISC-C-compiler to create RISC-assembler files for me out of C-functions which i then manually optimized and / or integrated with other RISC-routines i already had.

 

Kind regards

Matthias

[Starcat]

I didn't know the games were written in C, but it sounds promising.

What library are you using when programming in C on the Jaguar?

[Zerosquare]

The Removers' C library includes several tutorials. More info there.

[Matthias]

Hello Lars!

 

I didn't know the games were written in C, but it sounds promising.

What library are you using when programming in C on the Jaguar?

 

My own small "library" of assemble functions i am using since years, functions

you need to read the joyport, or to print text on the screen. I haven't merged them into a real C-library, just included the asm-sources to the C-projects.

 

As you and as Zerosquare mentioned, the Removers' C-library seems to be a good start,

as it is more C-like in it's usage than my approach

 

Kind regards

[Starcat]

Thanks. Matthias, what compiler are you using?

At the moment I'm trying to get a basic environment to work, that I can experiment with.

 

Zerosquare, thanks for the hint. However I'm not quite sure how I would setup an environment with this libary.

I'm familiar with the DOS based Atari environments, I mostly use batch files instead of makefiles, too.

But I'm not really used to linux, cygwin or similar environments.

 

Is there any ready to use environment like the one in the Atari examples that works with the Removers C lib?

 

Regards, Lars.

[belboz]

I have a Windows XP compatible dev environment on my website. It contains vbcc as the compiler, and smac/sln as the linker. If your using Vista or Windows 7, you can still use mac and aln too by copying them into the bin folder.

 

My dev setup contains an installer that installs and sets up everything for you. It contains a sample little C program that shows how to setup a simple screen and do some text output.

 

Seb's library doesn't work out of the box with it, but a few tweaks and you can get it working.

 

www.hillsoftware.com is my website.

 

I also have the older Atari compiler on there. If your running 98 or Vista/7 it should work fine on it. No installer for it though. But it contains info on how to set it up. It doesn't work on Windows 2000 or XP though.

 

Thanks. Matthias, what compiler are you using?

At the moment I'm trying to get a basic environment to work, that I can experiment with.

 

Zerosquare, thanks for the hint. However I'm not quite sure how I would setup an environment with this libary.

I'm familiar with the DOS based Atari environments, I mostly use batch files instead of makefiles, too.

But I'm not really used to linux, cygwin or similar environments.

 

Is there any ready to use environment like the one in the Atari examples that works with the Removers C lib?

 

Regards, Lars.

[Starcat]

I'm using Windows XP, however my environment is pretty much setup like Atari did, just mostly using batch files, setting the paths and using SMAC SLN. What needs to be done to get Seb's lib to work in that environment?

[belboz]

Never tried it with the old environment. I would just try compiling one of his demos and include the path to the removers library header files in my compile options. Then link in the various libs needed by the library. One of the makefiles for the examples should show you much of what is needed.

[Starcat]

Hello Matthias!

 

There is a lot of stuff done in C for the Jaguar:

Programs and tools written and provided by Atari like the MemoryTrack-Manager,

up to games like Doom by id software,

and the 3 games found on my Double Feature #1-CD are also C-based (but not the game-select-menu).

 

Mixing 68000-assembler and C is quite easy, just put an understroke "_" in front of the names of your assembler-functions to allow the C-functions to recognize them (and vice-versa), and learn how to access the C-function-parameters via the stack properly.

 

 

Can you tell me how parameters are passed between C and asm functions? With other words how a C functions passes its parameters to an asm functions and vice versa.

 

Regards, Lars.

[+Stephen Moss]

I have a Windows XP compatible dev environment on my website. It contains vbcc as the compiler, and smac/sln as the linker. If your using Vista or Windows 7, you can still use mac and aln too by copying them into the bin folder.

I had a play with the GUI version over the weeked but not being the cleverest of people when it comes to the more technical aspects of using PC's I could not figure out how to get it to load or save to my HD

 

Hello Matthias!

 

There is a lot of stuff done in C for the Jaguar:

Programs and tools written and provided by Atari like the MemoryTrack-Manager,

up to games like Doom by id software,

and the 3 games found on my Double Feature #1-CD are also C-based (but not the game-select-menu).

 

Mixing 68000-assembler and C is quite easy, just put an understroke "_" in front of the names of your assembler-functions to allow the C-functions to recognize them (and vice-versa), and learn how to access the C-function-parameters via the stack properly.

 

 

Can you tell me how parameters are passed between C and asm functions? With other words how a C functions passes its parameters to an asm functions and vice versa.

 

Regards, Lars.

 

SubQmod has just been covering that subject at http://www.jaguarsector.com/index.php?showtopic=31245

Edited April 9, 2010 by Stephen Moss

[belboz]

Not sure exactly what you are referring to.

 

My post you quoted was referring to the Jaguar developers environment I have online for XP/2000 and higher systems. It is a Windows installer. You run the installer, it puts the dev environment onto your Windows system and creates a program group with a readme, uninstall. Once you run the installer your setup to do dev work on your XP/2000/Vista/7 machine.

 

I can only assume your talking about the GUI CD (or my SkunkGUI program). If your talking about the GUI CD then you can access your HD from the System Icon on the desktop. (system / storage media / your HD partition)

 

But I would only use the CD if you need a fully working dev system with either the original dev tools by Atari, or you have an Alpine, etc). Otherwise just use my Windows installer to put current dev tools on your 2000/XP system.

 

I had a play with the GUI version over the weeked but not being the cleverest of people when it comes to the more technical aspects of using PC's I could not figure out how to get it to load or save to my HD

[+Stephen Moss]

I was talking about the GUI CD, Jagdev_102 appears to work fine.

The reason I tried the GUI CD was that I am having trouble trying to assemble the varions Atari 3D demos I have aquired into aCOF file so I thought I would try the GUI CD in the hope that the (to my eyes) more automated Compile, Build and Go functions would make up for my in experiance and lack of knowledge but I am probably asking too much of it.

I can now get the files into the development editor but the Bulid, Compile and Go options are greyed out an non responsive. I think I will wait until JFUK hopefully someone there should be able set me straight.

 

I can only assume your talking about the GUI CD (or my SkunkGUI program). If your talking about the GUI CD then you can access your HD from the System Icon on the desktop. (system / storage media / your HD partition)

 

But I would only use the CD if you need a fully working dev system with either the original dev tools by Atari, or you have an Alpine, etc). Otherwise just use my Windows installer to put current dev tools on your 2000/XP system.

 

I had a play with the GUI version over the weeked but not being the cleverest of people when it comes to the more technical aspects of using PC's I could not figure out how to get it to load or save to my HD

[belboz]

Your best bet is to probably go to a terminal prompt and try running the makefile from there first.

 

You can do it this way.

 

Go to the the system icon / storage media. Find your hard drive. Note the device name listed for it when you browse it.

 

Mine says "system:/media/hdb1" in the file browser location window. That is my Windows C drive. Your path may vary.

 

Now launch a terminal prompt. It is the little black icon on the bottom left of the screen. Just to the right of the K icon.

 

In the terminal that pops up. I would do the following to go to my C:\JAGUAR\3D folder. (without the quotes)

 

"cd /mnt/hdb1/JAGUAR/3D" (note the hdb1 was taken from the file browser location line above. The GUI CD mounts partitions it finds and puts them in the /mnt folder under hdXX depending on the partitions. So you might have an hdb1 and hdb2 or hda1 or hda2.

 

Also when typing paths on the command line you can hit the TAB key to have the terminal autocomplete things for you. Very useful if your not sure on the exact name of a file or path. It should also be noted that linux is case sensitive with filenames. You will find many files on your Windows partition are all in caps or a mixture. Windows doesn't care about case in filenames, Linux does.

 

Once you change to your projects directory, then I would type "make" and it would attempt to run the makefile

 

You may have to edit or tweak the makefile if the paths are different from what the makefile expects.

 

I was talking about the GUI CD, Jagdev_102 appears to work fine.

The reason I tried the GUI CD was that I am having trouble trying to assemble the varions Atari 3D demos I have aquired into aCOF file so I thought I would try the GUI CD in the hope that the (to my eyes) more automated Compile, Build and Go functions would make up for my in experiance and lack of knowledge but I am probably asking too much of it.

I can now get the files into the development editor but the Bulid, Compile and Go options are greyed out an non responsive. I think I will wait until JFUK hopefully someone there should be able set me straight.

 

[belboz]

Also the build compile and go options will be grayed out when you don't have a C or assembly file loaded.

 

Try loading one of those from the project you want to build and then see if they are grayed out. One thing I never tried which might be your problem. The editor might be looking at the case of the file extension to determine if the build option will be available. If your source file has an uppercase .C or .S on them the editor may not be showing the build option since it might be looking for .c or .s (in lowercase)

 

Try build first since it runs make which looks for the projects makefile. If one doesn't exist you will need to do a little work (depending on the projects size)

Edited April 13, 2010 by belboz

[tarkb]

Hello everybody!

 

I know this topic isn't entirely new, but up to this point, I couldn't find good tutorials or examples on using Jaguar C to develop games. Of course C isn't exactly the strong side of the Jag and there are libs like the removers lib.

However it's my impression, that except for the Jagware people possibly, nobody is really using it. Correct me if I'm wrong.

 

 

 

Hey, I'm nobody, and I'm using it!

 

I'm nowhere near writing a game, just testing my "ever-growing library of misc. c code"

on another target at the moment.

 

 

Hope this isn't reviving a dead thread, but seeing as how it is the most current one...

 

 

 

Maybe this will help someone else? (or me when my hard drive crashes, and I come back years later

trying to get this stuff running again)

 

 

I'm using:

 

 

(Self-built) binutils 2.16.1 and GCC 4.2.0 targetting m68k-aout

jlibc & rmvlib (built with the above, for rmvlib I needed to use a linux madmac instead of smac though)

 

 

building jlibc will give you a crt0.o

 

I believe jlibc has malloc() and free(), IIRC qsort() is the only thing I noticed

missing (I don't use much stdlib stuff though).

 

 

rmvlib has skunkboard-compatible printf() and getchar() and putchar().

 

 

That printf() seems broken for printing signed char/int/long/short

(maybe just PEBKAC, but my code runs on other targets fine...).

 

 

You will want a rmvjcp binary if you are using rmvlib's printf() -- there are linux

and windows binaries @ www.hillsoftware.com IIRC.

 

( standard skunkboard "jcp" doesn't work with rmvlib printf() ).

 

 

Output is kinda slow, but it is still in development and Seb is nice enough to release

his stuff, so I am not complaining I asked him for source (I don't run much linux or

windows around here) but no response, but I am not going to bother him

 

Output is even slower when ran under e.g. virtualbox

 

 

 

I needed to link against libgcc.a too to get:

 

_divsi3 _modsi3 _mulsi3 _udivsi3 _umodsi3

 

 

No idea if my gcc and/or the jaguar does hardware or software floating point (haven't tried).

 

 

 

Had no luck getting sln 1.0.0 (or older) to link stuff --

I use a linux binary of aln instead for now.

 

It has a lovely limitation of "File name too long: xyz (sorry!)"

 

(at least it said it was sorry!)

 

 

rather than limit myself to whatever it thinks is short enough, I use binutils "ar" to

add all my compiled objects to an archive/library (.a) with a short name, then use aln to link

that against:

 

crt0.o xyz.a rmvlib jlibc and libgcc (in that order).

 

 

 

 

 

Hope this helps someone else!

 

 

 

 

I also like using http://www.cs.utah.edu/flux/knit/cmi.html CMI to reduce the size of binaries too,

just be careful you pass it the right args to not "optimize out" e.g. _start() or __main() startup

code that you might not call explicitly from your code, but that is invoked "behind the scenes"

(e.g. by a library you are linking against, or the compiler is).

 

 

I might try vbcc and sln again, I think last time I couldn't get sln to link my stuff --

maybe vbcc and aln would work for me though...

 

 

Someday I will make more use of rmvlib...the mod player is tempting...

[Zerosquare]

I asked him for source (I don't run much linux or

windows around here) but no response, but I am not going to bother him

If you mean the source for the Remover's library, it's available on their website (there). If you need something else, just ask Seb again -- I think he didn't see your message, as he usually replies

[tarkb]

I asked him for source (I don't run much linux or

windows around here) but no response, but I am not going to bother him

If you mean the source for the Remover's library, it's available on their website (there). If you need something else, just ask Seb again -- I think he didn't see your message, as he usually replies

 

I meant source for rmvjcp -- no biggie

 

I also told him it is cool another jaguar homebrewer likes iron maiden

 

Maybe he thought I was sucking up to try and persuade him

[SebRmv]

On 6/4/2010 at 6:58 AM, tarkb said:

 

I meant source for rmvjcp -- no biggie

 

I also told him it is cool another jaguar homebrewer likes iron maiden

 

Maybe he thought I was sucking up to try and persuade him

Sorry, I will publish source of rmvjcp

 

Done: https://github.com/theRemovers/skunk_jcp/

Edited June 14, 2020 by SebRmv

[dilinger]

On 6/3/2010 at 5:39 AM, tarkb said:

I also like using http://www.cs.utah.edu/flux/knit/cmi.html CMI to reduce the size of binaries too,

just be careful you pass it the right args to not "optimize out" e.g. _start() or __main() startup

code that you might not call explicitly from your code, but that is invoked "behind the scenes"

(e.g. by a library you are linking against, or the compiler is).

I know this subject is 10 years old, but the download section of the site is not accessible (which is not really surprising). Does someone owns the cmi-1.0.0.src.tar.gz ?

[ggn]

I never used this so I don't have the sources for it. But here's some comments from the peanut gallery on this:

 

• It's from 2003 so God only knows if it'll work with today's tools. (although the report says it was working with gcc 4.x so it might be fine)
• The speed claims are rather dubious and they don't include any information on how they build the code (did they build gzip with -O0 for example? Then sure, I would guess that an optimiser would make this run faster!). Also, is this platform dependent or x86 only?
• All the clever size optimising stuff they mention like dead code elimination and auto inlining should be possible with modern gcc versions. Just enable link time optimisation and/or perform a unity build of your code.
• If you're aiming for really good performance (and let's face it, a 14MHz 68000 is not exactly a CPU you can code freely without consequences for a long time) you're probably much better off sticking to a compiler and learning what code it produces (Brownbot is your friend) so you can adjust your programming style to that instead of relying on an automated tool that was probably written for generic purpose optimisations without aiming for the best possible.

[dilinger]

You are correct.
I have done benchmarks, for 68000, from gcc 4.8.0 to gcc 10.0.0. I have generated most of the toolchains by myself, so they may not be perfect.
The "fastest" for the moment is gcc 5.2.0 and 5.5.0; I have read from a Sega homebrew developer that the gcc 3.x has better support for the 68K.
Anyway, doing C is also not the best way to code for the console.