Hello Atari ST

This is the first part of the Hello World Project.

As I’ve been an Atari ST owner since the late 80’s, and still code on my ST occasionally, it was an easy choice to begin with this platform. I could write most of this code without looking through documentation, with a few exceptions, like the OS function code number.

Before I begin to explain the code, I should tell you that this code is not very system friendly. You will not be able to exit the program, all you can do is reboot. After I wrote this code, I have started looking at the Amiga, and realized that it is quite handy to be more system friendly and exit the program in a more kind way. It will save you many reboots of the hardware/emulator while coding. It is very likely that I will return to this code later and fix those issues.

It is quite straight forward to get something draw on the screen on the ST. Just set the address to your allocated screen memory and move some data there. But to access the hardware registers that change the screen address and palette registers, we have to run our code in supervisor mode. This is special mode in the m68k processors where you can execute some privileged instructions and access protected memory areas. I will not go any deeper into the working of the m68k processor family, but if you are interested in programming the Atari, Amiga or any other machine containing an m68k processor, I recommend that you download the Programmers Reference Manual.

One way to run our code in supervisor mode is to call the XBIOS function Supexec, which calls a function in supervisor mode. Since this code is not system friendly, I decided to just stop and loop forever once the function has been completed.

The pea super_run instruction pushes the address to the function super_run to the stack, and the trap #14 instruction calls the XBIOS that then calls our function before it completes.

    pea    super_run    ; Push function address to stack
    move.w  #$26,-(sp)  ; XBIOS call to Supexec.
    trap    #14         ; Software interript #14 -> XBIOS
    addq.w  #6,sp       ; Fix stack pointer (not really needed in this case.)

.halt   bra.s   .halt

The first thing to do in our function is to fix the screen memory address and set the screen base registers to point to our allocated memory. At the very end of the source code, there is a SECTION BSS entry, which contains a label screen_mem followed by a ds.b statement. The ds.b declares that we want to allocate space. The ST screen memory always consist of 32000 bytes (unless you are really advanced and do some hardware tricks to achieve overscan, but that is another story).

On an ST, the screen address must be aligned on 256 bytes. Therefore we allocate 256 extra bytes, add 255 to the original address and then clears the lowest byte. If you don’t understand why, grab a pen and a piece of paper and do some calculations yourself.

To set the screen base address, there are two byte sized registers you must write to. As the memory address space of the ST is only 24 bits, and the lowest byte in the address must be 0, it is only the two middle bytes in the 32 bit address that are relevant. The higher of these should be written to $ff8201 and the lower to $ff8203. The last to instructions in the code block below takes care of that. Remember, the m68k is a big endian system.

    move.l  #screen_mem,d0  ; Move address to screen mem to d0
    add.l   #$ff,d0         ; Add 255 d0 address
    clr.b   d0              ; Clear lowest byte in address
    move.l  d0,a6           ; Store screen pointer in a6

    lsr.w   #8,d0           ; Shift low 16 bits right 8 bits.
    move.l  d0,$ffff8200.w

Lets move on to the colors. The ST palette is stored at the address $ff8240 and contains 16 16-bit  wide (a word in the m68k lingo) registers with color data. Here is a little loop that sets all palette entries to black.

At address $ff8260 lies the screen mode register. By setting this to 0 we set the resolution to low res, which is 320 by 200 pixels.

    ; Set palette
    movea.w #$8240,a1   ; Pointer to palette entries.
    moveq   #0,d0       ; Color is black.
    moveq   #15,d1      ; loop 16 times. (dbra loops until dn == -1 )
    move.w  d0,(a1)+
    dbra.w  d1,.clear_palette

    move.w  d0,$ffff8260.w

Start copying data to the screen memory. In lo wres mode, the screen consists of four bitplanes, interleaved with 16 bit words for each plane. If you never used bitplanes, they can be a bit confusing at first, but since many of the old school platforms in one way or the other uses bitplanes, it can be a good idea to read up on them. I will not try to explain how they work just now.

The graphics i made is one bitplane (uses only one color and thus only need one bit per pixel), so we skip three bitplanes when copying data.

    lea     gfx,a0  ; Load graphics data pointer to a0.
    move.l  a6,a1   ; Copy screen address to a1
    moveq   #5,d1   ; loop 6 times (dbra loops until dn == -1)
    move.w  (a0)+,0(a1)
    move.w  (a0)+,8(a1)
    move.w  (a0)+,16(a1)
    lea     160(a1),a1      ; Skip to next row, (160 bytes per row)
    dbra.w  d1,.draw_loop

The screen base is set, our graphics is copied to the screen and the only thing that remains is to set palette entry 1 to our color of choice. Of course, if we had copied the graphics data to another bitplane than the first we would have to change another palette entry.

On plain ST the palette data consists three bits of data for each RGB channel in the lowest three nibbles. $700 would be red, $070 blue and $007 green.

    move.w  #$777,d0
    move.w  d0,$ffff8242.w

    rts         ; Return from subroutine

Define the graphics in a data section. The data contains of binary data, where one bit corresponds to one pixel. 48 pixels wide and 6 pixels high.

    dc.w    %0100010000000101,%0000000100010000,%0000000100001010
    dc.w    %0100010011100101,%0011000100010011,%0001100100111010
    dc.w    %0100010100010101,%0100100100010100,%1010010101001010
    dc.w    %0111110111110101,%0100100101010100,%1010000101001010
    dc.w    %0100010100000101,%0100100101010100,%1010000101001000
    dc.w    %0100010011110101,%0011000010100011,%0010000100111010

And finally we declare some space for the screen memory that we referenced earlier. The difference between the DATA section and BSS section is that everything in the DATA section will be store as data in the binary file, whilst the BSS section will be allocated by the system at load time.  There is a flag in the executable file header that tell the OS whether the memory in the BSS section should be set to zero before the program starts. This is the default behaviour, but if the fast-load flag is set, the memory in the BSS section will be undefined when the program starts.


; Reserve screen memory
    ds.b    32256


Any questions or complaints? Leave a comment!

Next up, Amiga OCS. In a future not so far away.