INSIGHT: ST

---

Bill Wilkinson


Okay, you've got your shiny new ST computer plugged in and running. You can use the mouse to select programs, copy files, and format disks. It's fun, and it certainly is easier to learn than figuring out what

COPY B:\SYSTEM\MSGS.TXT/A=A:
 SPCL*.MS?

is supposed to mean. (That's a real and possible IBM PC command.) But how did this system get built? Glad you asked.
    Collectively, the software built into the Atari is called TOS (Tramiel Operating System). When the 520ST was first shipped, TOS was delivered on a disk. If you're still using the disk-based TOS, stop now. Go out and buy the ROM (Read Only Memory) version of TOS. It should cost no more than $25 or so. Installation is not too difficult, though if you have as many left thumbs as I do, you might be advised to find a dealer or service center to install the chips for you (maybe $20 to $30 extra).
    TOS in ROM is actually composed of six separate pieces. Usually, we lump these pieces into two groups of three: the graphics processing section and the underlying operating system. As we shall see, that operating system-a derivative of CP/M-68K-is very similar to MS-DOS and PC-DOS, which are both derivatives of CP/M.

BIOS, XBIOS, And GEMDOS
In one sense, we can say that the lowest level of the ST's operating system is the BIOS (Basic Input/ Output System), a holdover from the earliest days of CP/M. At this level, we find routines for such basic tasks as sending a single character to a device, reading a disk sector (by sector number-a very dangerous practice), and so on. In CP/M, there was only one legitimate reason to call the BIOS directly: speed. With TOS, though, only the BIOS provides some of the facilities which even a moderately sophisticated program will need (admittedly, often because of bugs in the upper levels of the operating system).
    On the ST, a BIOS call is implemented as a TRAP instruction in 68000 machine language. All the necessary parameters, including the BIOS call number, are passed onto the stack. If you aren't quite sure what we're talking about, don't worry about it. Virtually every programming language for the ST has some way to use these routines which mask the mechanics of TOS calls. It's a good thing, too, since some of those mechanics can get pretty hairy.
    The next higher component of TOS is the XBIOS (eXtended BIOS). XBIOS supplies the Atari-unique routines needed to do such things as access the sound registers, screen hardware, and so on.
    The third component of the operating system is called GEMDOS Graphics Environment Manager/ Disk Operating System). Actually, this is a misnomer. The GEMDOS routines have nothing whatsoever to do with graphics. GEMDOS is essentially an MS-DOS or PC-DOS emulator. Want to open a file? Read a block of bytes? Get a character from the keyboard? Given the differences between the 68000 of the ST and the 8088 of the IBM PC, the similarities between GEMDOS calls and MS-DOS calls are almost scary.

GEM, VDI, And AES
Okay, enough about the underlying operating system. Let's take a look at the graphics systems which comprise GEM. The most familiar part is the GEM desktop which appears when you turn on your ST. But the desktop is not really a special program at all; it simply calls the lower-level routines. Again, there are three levels of graphics routines.
    The lowest-level graphics, not officially part of GEM but merely one means of implementing it, are those called the Line-A Routines. This sounds cryptic, but it simply refers to the fact that certain machine instructions of the 68000 (including those of the form $Axxx hex-hence "line-A") are reserved and cause a special hardware trap into the OS. As you might expect, routines implemented in this fashion are of the most fundamental type: draw a line, plot a point, and so forth. Most are very fast.
    The next level up in graphics is the VDI (Virtual Device Interface). In theory, VDI is capable of supporting several types of graphics devices in a uniform fashion. For example, you might use the same set of calls to draw a curve on a plotter or on the screen. Unfortunately, no such drivers are yet available (or, as far as I can tell, even in the works) for the ST. Still, the possibility exists.
    VDI does all the actual graphics work on the ST. It draws simple rectangles, bordered ovals, and text in various styles, sizes, and colors. Someone who learns nothing on the ST except how to call VDI could still do some remarkable graphics work.
    Finally, at the highest level, is AES (Applications Environment System). AES is what GEM uses to present you with that nice, pretty desktop, complete with menus, dialog boxes, alert boxes, windows, and icons. Perhaps more important to programmers, though, is the fact that AES allows us to use all the features of GEM in a relatively consistent, properly desktop-compatible manner. It is through this mechanism that even a lowly spreadsheet program can have drop-down menus, mouse-controlled windows, and all the rest of those impressive features.