Programming the Atari ST 20 Years Later

Goal:

One week ago everything I knew about the Atari ST could fit in this sentence: “The Atari ST was a computer.”  The past week I have studied it and have built the knowledge required to start programming on it.  Follow me and I’ll show you what I learned.  I will show you how to write software in 68k assembly on one of the iconic computers of the 80’s.

Background info on the Atari ST:

  • The Atari ST was a reasonably priced computer released in 1985
  • It’s competitors were things like the Macintosh, Apple //GS, Amiga, 80286 IBM PC Compatibles
  • It ran on the Motorola 68k chipset @ 8mhz
  • The 68k chips have 24bit addresses which gave it access to a possible 16M of memory (max size on the Atari ST is 4M)
  • The Atari ST shipped with Atari TOS (The Operating System)
  • It could be run in 3 different resolutions: 640×400 in black and white, 640×200 in 4 colors, 300×200 in 16 colors
  • You had access to 2^9 different colors but a max of 16 are used at once [thanks for the correction Chris]
  • It came with a GUI called GEM

Setting Up The Emulator:

You didn’t think we were actually going to program on a real Atari ST did you?  Who has room for that sort of stuff?  Apparently not us says my wife.  For this tutorial we are going to use Hatari.  I didn’t shop around, but this emulator seems pretty awesome.  I recommend it.  If you are on Mac OS X it’s easy to install with macports (‘sudo port install hatari’) and on Ubuntu it should be in apt-get (‘sudo apt-get install hatari’).  Macports gave me a valid bootable install that runs EmuTOS (a free replacement for Atari TOS), but Ubuntu gave me an install that can’t boot because it can’t use the EmuTOS image.  Don’t worry about that, we are going to use the easily obtainable Atari TOS anyways.  Maybe everything works with EmuTOS, I don’t know I didn’t try it.

Here is a screenshot of what you’ll be seeing right about now when you start Hatari:

Screen Shot 2014-09-23 at 7.45.52 PMOkay, right about now, if you are like me you are probably asking yourself what is up with the crappy borders around the Desktop, I know!  I mean, I don’t know.  The Commodore 64 had that too and the physical machine had that, we’ll be removing it, don’t worry.  Here is the next steps to getting your Hatari installation souped up:

  1. Download Atari TOS 2.06, the one I’m using is named Tos206us.img
  2. Make an empty directory on your computer to pretend to be your Atari Hard Drive
  3. In Hatari press F12 to get to the settings
  4. Go to the ROM section and choose the TOS 2.06 image
  5. Go to ‘Hatari Screen’ and select Atari Monitor Mono (trust me! we can play with color later)
  6. Go to “Hard disks” and select the directory you made under “GEMDOS Drive”
  7. Then go back to settings and select the “Reset machine” radio button and click the “OK” button

Now your Hatari should look like this:

Screen Shot 2014-09-23 at 8.01.09 PM*High-Five* now your system is setup and ready to get the dev tools going.

Setting Up The Development Tools:

For this bit we are going to use the assembler called DevPac3.  I’ve heard TurboAss is good too (giggle), but I found more resources talking about DevPac3 thanks to the Demoscene.  The version I’m using is DevPac 3.10 by HiSoft.  Finding it shouldn’t be difficult with an internet search.  If you find it as an “.st” file you are in luck, that’s a floppy image, you can skip the next section.

If you download Devpac and it comes as a directory of files:  You could try to be a wiseguy and drag the files to your directory you selected as your hard-drive then run DEVPAC.PRG from there like I tried, but you’d be wrong! (maybe).  My installation was giving me troubles because it wanted to be run from the floppy drive.  You may get errors when starting DevPac.  In this case, go into the Hatari settings (F12),  then go to ‘Floppy disks’ and make a new floppy image, put it into a floppy drive, then drag your DevPac files into that floppy disk and run DEVPAC.PRG from the floppy from now on.

So, open up your disk or folder with DEVPAC.PRG and double click it to run.  You should now be seeing this:

Screen Shot 2014-09-23 at 8.23.22 PMYour default settings for DevPac should be good.  There is just one thing we want to make sure is set.  If you go to Options -> Control…  make sure that Format is set to “ST RAM”  This is going to make it so that when we assemble it puts the code straight into memory so we can execute it directly.  Another option that will be useful later is selecting “Atari executable” which will be necessary to make a PRG file.

Running Code:

Okay, this post is getting long so for those impatient types I’m going to give you the code to type in:

You could always just save this code to disk in your hard drive folder then load it from DevPac but then you would miss out on the satisfying clicky sounds that the Atari ST makes while you type.

Now that you have the code in memory lets assemble it!  Go to Program -> Assemble, watch the fun assembling happen, if you have errors in your transcription you’ll see them here.  Now assuming that went well you’ll have your assembled program in memory too, lets just run it by going to Program -> Run.  And now you should see this:

drawlineWhoa!  Watch out, don’t get angry!  We actually did something, look in the top left-hand corner… no closer, look there is a diagonal line there!  We did that!  Okay, you are right I should have warned you at the beginning of the article that the program was lame.  But it is understandable and digestible for a first program.  Press any key to exit once you are done soaking in the wonderful line.

Explanation of the Code:

Here is a quick rundown of the code.   In the first section of the code we are just creating aliases to offsets and commands.  All of those constants I got from the Atari ST Internals book [see references].  Next we jump to the subroutine (jsr) initialize which sets us up for Super User mode.  I didn’t actually test to see if Super User mode is required for the demo but why not go Super, we can handle it.  When initialize returns (rts) we are going to call Line A init.  Line A is the package of drawing calls we are using.  There are other ways to draw on the Atari ST.  I think these are the fastest least portable graphics calls (any greybeards to correct me?).  The weird thing about that call is that it is happening with the dc command which is just putting that data directly into our code instead of using some sort of call opcode.  If you check out the documentation for init you’ll see that it sets up register a0 with a struct we can edit to set parameters to other Line A calls.  We do that in our next section to setup the parameters to the draw line function.  Then we finally call the draw line function on line 35.  Then we are going to use a GEMDOS function to wait for a key press (function 7 of the GEMDOS which is trap 1) on line 37-38.  Now that we have a keypress we are just going to restore User Mode, then call the GEMDOS exit function on line 42.

Conclusions:

In some ways Atari ST development is better than the development I do today for iOS.  In other ways its a bit clumsy.  A dark shadow falls over me when I think about all the hours of work spent by Atari ST engineers to build something almost lost to oblivion.  The silver lining is the amount of love that still exists by a select few fans of the Atari ST.  I can’t help but think about the similarities between software development and Sand Mandala.  Maybe I’ll get around to figuring out how to do animation next, we’ll see.

References:

19 Comments

  1. I wrote 6 games for the ST, and it was a great computer. Most of them took around 16 weeks to program, and after Hyperbowl I didn’t use the OS at all (a custom disk loader, meant I could use 511K out of the 512K available). I loved programming in 68000, I still prefer it to programming in C/C++ or Java but unfortunately it’s no longer used.

  2. Good read, minor correction needed…

    The Atari ST(FM) had 2^9 (512) colours, of which 16 could be shown at a time.

    The later STe model had 2^12 (4096) colours, still only with 16 displayable at once.

  3. whoa!! Such memory recall… damn, all those traps and stuff… why not try GfABasic, was (over here) quite popular!

    Gosh, I recall soldering myself a Blitterchip in my 520…. darn, I’m getting old!

    1. I tried GFABasic. I felt like I came so far I might as well make the plunge into 68k. I have been doing some 8086 stuff in my spare time so it wasn’t that much of a leap. I’d like to play around with the Blitter at some point, so many side projects, so little time.

  4. Real men programs a ZX Spectrum in Z80 assembly !
    Jokes aside. I never meet an Atari ST, but I know that is an amazing computer. Also, the AY sound chip always does nice chip tunes…
    Good luck doing programs for old machines!

    1. Aw, you like the Atari ST sound chip?! It has its charm. In the 90’s as a kid I played with MOD trackers so I’m partial the Amiga sound. The chip I really love is the one in the Sega Genesis.

  5. I went back and did some work on Atari a few years ago. Amazingly I remembered almost everything, and even managed to fix some bugs that eluded me in the code I’d written 18-20 years prior. Yes, I even remembered the CPU cycle counts for most instruction forms. Geek? Guilty as charged.

    1. Hey those look like the original disks, looks like you haven’t been keeping up with their recommended regular back-up cycle 😉

  6. Correction for you: 320×200 in 16 colors

    [4 bitplanes interleaved per word, and no h/w assists, which is why it was a challenge to make it run at any speed. Blitter was only on some later models, and wasn’t really that fast. Most coders took the time/space tradeoff of pre-shifted sprite data.]

    BTW If you’re on Windows, STeem is a better emulator for development, it can run in GEM mode to run the assembler very quick (not a big deal for small projects, but my last foray a couple of years back had me compiling old 120,000 line source files) and it has built in a debugger/monitor.

    1. Cool, thanks for the tips Oberje. I might try out TurboAss too, it suppose to do real time assembly as you edit code. Unfortunately Windows isn’t an option for me now.

Leave a Reply

Your email address will not be published. Required fields are marked *