Table of Content

This page contains Information about Atari ST programming languages and environment.

What language should I use?

There is obviously no easy answer to this question! It really depends on the requirements of your project but even more importantly of your familiarity with specific languages. Many languages are available on Atari but the most common choices are Assembly, Basic, and C.
Other languages (e.g. Pascal) were not so popular on Atari and their implementations are usually not so good and therefore they should be avoided. Personally most of my development on Atari are done in C and I use Assembly only for small critical sections of my projects.

If you are new to programming and/or Atari my advice is that you should learn C.

 

Assembly languages

I will not provide much information about using assembly language for the Atari because there is already plenty of sites that cover this subject...

There are a lot of 68000 assemblers available for Atari ST but the most famous is the Devpac package from HiSoft. It contains an editor, an assembler, a linker, and a debugger. The two widely used versions are :

Note also that most of the C compiler packages includes an assembler sufficient when you have only small pieces of your project in ASM.

It is sometimes necessary (reverse engineering, cracking, ...) to look at some Atari executable code. For that matter you will need a disassembler. On the Atari I recommend to use Easy4 or this DASM68 or DIGGER. On PC you can use this disassembler from Fred76.

And if you are ready to pay and spend lot of time in learning you should use the extremely powerful Ida Pro (Windows, Mac, Linux) multiprocessors Disassembler and debugger (there is a free evaluation version).

Back to the top

C Compilers

There are many good C compilers available on Atari. The most famous ones are the Pure C and Lattice C compilers but they are not maintained and they do not have a good documentation. Therefore I recommend to use the AHCC Compiler developed and still maintained by Henk Robert. AHCC is fully compatible with Pure C code and libraries.

Back to the top

AHCC Compiler

For C development I recommend to use the AHCC (ANSI Home Cooked C) compiler from Henk Robbers. AHCC is an excellent full ANSI C89 compiler and is binary compatible to Pure C so it is possible to freely mix AHCC produced and Pure C produced objects and libraries. It uses the same project files as Pure C and a very similar graphic environment. It is therefore possible to migrate smoothly from Pure C to AHCC. The big big advantage of AHCC is that the code is maintained and continue to evolve. For example the current version 5.11 provides support for the Coldfire project. It also comes with sources so you can look at standard library implementation.

The only potential problem is that AHCC does not provide any support for floating point: no support for floating point declaration in the source (i.e. no float no double types) and no library. So if you need to do floating point computing you should use the Pure C compiler. See HERE

The latest version of compiler and related tools and documents can be found on the Home page of Henk Robbers

Back to the top

Pure C Compiler

The Pure C compiler implements the ANSI C specification efficiently and comes with an integrated documentation. However the program is not maintained and I have found that some standard routines are implemented inefficiently. In some cases I have also found bugs (for example the code generated for volatile is not done correctly). However it remains an excellent compiler.

The latest release of the Pure C compiler is version 1.1. The on-line help files are available in English, German and French. You should not have any problem to find this version on the Web (for example at Reservoir Gods) but for convenience I have placed a complete English version HERE. The first document to read is the English Overview text written by Dan Wilga. You can find HERE a PDF version of this document edited by me as well as an ST-Guide version HERE.

Back to the top

Lattice C Compiler

The latest version 5.6 of the Laticce C compiler is pretty efficient and provide an excellent ANSI C implementation. Unfortunately there is no documentation of this version available on the Web. It is possible to find documentation for version 5.0 but the program has drastically changed between versions 5.0 and 5.6. It is therefore difficult to efficiently use this compiler because of the lack of documentation.

You can find here version 5.60 of the Lattice C compiler.

Back to the top

Learning C and GEM for Atari

If you want to learn C in the context of the Atari there is an excellent book from Clayton Walnum called The C-manship. It has been published by Taylor Ridge Books in 1990. In this book you will learn some basic information about the C language as well as GEM programming Fortunately for us the original book was converted (with permission from the Author) from the original Calamus document to an ST-Guide document by Lonny Pursell (lp). As I hate the HYPertext format I have converted the document in PDF (320+ pages) .

The book came with a diskette that contains the code presented in the book. The code was written for Laser C compiler and unfortunately does not compile directly under Pure or AHCC C.

Back to the top

Development Environment

Your development environment is a matter of taste and depends on the computers you love! Some people likes to do all their development on powerful Atari or Atari Emulators. All the ASM and C packages presented above comes with an integrated environment and therefore you can certainly do all your development using these packages on an Atari.

Personally I prefer to do most of my Atari's developments on a PC.

Back to the top

Source Code Editing

For source code editing there a lot of excellent free tools available on PC. For example Notepad++, or ActiveState Komodo Editor. Personally I use the Visual C++ environment from Microsoft. I have been working with the VS environment for many years in my job. It includes a powerful text editor with syntax coloring, browser for functions/variables, on-line C function help, etc. One nice feature is the intellisense technology that automatically displays function and structure parameters (calltips) as you type (even for TOS, AES, VDI) and it provides auto-completion… I usually compile the source code under Visual C++ to quickly catch incorrectly typed code (syntax checking).

To get all the benefit of intellisense and in order to compile correctly you need to add access to the AES.H, VDI.H and TOS.H file and in order to get rid of linker error I have created a file called atari.c that contains dummy function declarations for all the AES, VDI, and TOS calls. This file needs to be included conditionally when compiling under windows to make the linker happy.

Back to the top

Source Revision Control

It is always a good practice to keep track of the modification you do on a project so you can revert to previous stable version.

For quite some time the rule was to do revision control on a file basis and for that matter I was using the free revision control application CS-RCS Pro from ComponentSoftware Inc.

But today the tendency is to save revision not on a file basis but on a set of files basis. This make sense as implementing a new feature usually requires to modify many files of the project. The two most widely used version control packages are Subversion and GIT.

Personally I have chosen GIT that is very easy and intuitive to use. I also use the GitExtension package and publish my projects on GitHub.

Back to the top

Project Documentation

For documentation of the project and the documentation of the code I use the fabulous and free Doxygen. Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#... It produces a very complete set of HTML documents. Doxygen can also produce a .hpp command file that allows to process the HTML files by the free HTML Help workshop from Microsoft in order to produce one compiled and compressed HTML file (.chm) that is easy to transmit and read under windows.

The installation of Doxygen is easy. You also have to install the Doxygen GUI front-end. All my Doxygen command file have the extension .dcf (Doxygen command files) so I can directly start Doxygen GUI just by double clicking them.

The project documentation is usually also done under Doxygen. For that matter the text documentation of the project uses Doxygen commands that allow to produce nice HTML documentation. The files used for documentation uses the .dox extension (so it is easy to recognize them). In some projects I also have .css (HTML style sheet) files to better control the look of the output.

Back to the top

Creating Atari executable and Debugging

To generate the final Atari executable the source is first compiled with Pure C or AHCC C compiler on a PC running STeemSSE or Hatari emulators. One advantage is that the code can be compile very quickly by using a virtual machine with a fast CPU (compilers work at any speed)! The code is run and debugged under the emulator using the compiler environment. When the program seems to work as expected the complete project with sources is transferred via an SD card plugged into an UltraSatan drive on a real Atari. The executable is then tested on an Atari that contains the compiler environment. If bug are found it is therefore possible to make modification to the source and recompile on the target machine. Modifications are then transferred back to the PC.

Back to the top

Creating Resources file

In most cases GEM programs requires to create a resource file. For building resource files I use Interface 2.33. It works well most of the time but it crashes from time to time when FTEXT objects are used? So as a last resort, when this happen, I use WERCS from Lattice. It is an extremely basic rsc editor but it is very robust! For documentation see HERE Back to the top

Libraries

Here are some libraries that I use for Atari development:

Back to the top

Links

Back to the top