Inside Tramiel Operaing System
By Patrick Bass & Jack Powell of the Antic Staff
When starting to use a brand new computer, we find ourselves learning the vocabulary of a brand new language and we don't mean a programming language. Articles about the 520ST are liberally sprinkled with unfamiliar terms like VDI and TOS, GEM and GEM Desktop. What's the difference between GEM and GEM Desktop? How is a Dialog Box different from an Alert Box?
It gets pretty confusing. So we thought we'd take time to examine the ST vocabulary Just to make sure we're all speaking the same language.
BIOS TO DESKTOP
Starting at the very lowest level of instruction, we find a collection of zeros and ones that the machine understands. This is, quite logically, called machine language. We can translate these numbers into hexadecimal, decimal, or any base we like, but it's all still machine language.
Let's make these same numbered instructions a little easier for humans to remember by translating them into alphabetical mnemonics. We now have assembly language.
Using assembly language, we write a collection of routines which allow the user to communicate with the machine. These Basic routines allow information to flow In and Out between the computer and the user. They are, therefore, called the BIOS, or Basic Input/Output System. BIOS in the ST includes a section of routines that manage disk file manipulations. This section is known as BDOS, or Basic Disk Operating System.
At a slightly higher level, the ST needs a series of routines for its own internal use, such as enabling or disabling interrupts, or setting the screen location. Many of these calls are more or less simple extensions to BIOS, so they are known in the ST as XBIOS.
Above these levels we need a series of routines that will recognize commands from the user and translate these commands into a series of calls to both BIOS and XBIOS. This command level is known in the ST as GEMDOS.
GEMDOS is the ST name for a version of CP/M 68K-which is known industry-wide as a command-level DOS because, unlike menu-driven Atari DOS 2.5, GEMDOS requires simple commands typed in at a prompt. For example, type DIR at the prompt and the computer will show the disk directory.
At this point we have assembled essentially the same operating system that older computer systems have. The user needs to remember a series of commands which are then typed in at the proper time to get the computer to do the proper task. It would be nice to have the computer do most of that work for us.
The people at Digital Research, Inc. also thought that would be nice. So they wrote a series of routines that will sit on top of GEMDOS and act as a go-between, simplifying the process of getting the users' commands into the computer.
They decided that since a picture is usually worth 1,000 words, the system should be graphics-based, when-ever practical. Since the object of this collection of routines is to Manage the use of a Graphics-based Environment, the name selected for the system is GEM, which is short for Graphic Environment Manager.
GEM is divided into three basic sections VDI, AES and the GEM Desktop.
VDI, which stands for Virtual Display Interface, is the workhorse of the three routines. Here we find the code that actually draws the dots and lines and circles on the video screen. Whenever a box, polygon or word is drawn on the TV screen, VDI is at work.
VDI controls the display hardware, and can be used by other programs without either AES or the GEM Desktop in place. Atari has even provided developers a back-door into VDI, called the "Line A" interface. This bypasses the processing that GEM puts on each graphics call and allows more or less direct access to the low-level graphics drawing routines from assembly language.
The section that often gives VDI its commands is called AES, for Application Environment Service. AES contains a world of pre-defined routines for nearly everything a programmer needs to do while working with GEM. Need to open a window? AES has a call for that. Need to find out which icon the user clicked on? AES to the rescue! There are routines for everything from hiding the mouse cursor to dragging boxes around the Desktop. AES cannot operate without VDI in place, but it doesn't really care if the Desktop is there.
The GEM Desktop is really nothing more than a program that runs when the system is powered up. The Desktop allows the user to check disk directories, move, copy and delete files, format disks, rename files, and generally do anything that could be done from a command-level operating system. Except here we can simply point-and-click to perform a complicated series of commands.
Hallmarks of any program running under GEM are Alert Boxes, Dialog Boxes, Drop-Down Menus, and Desk Accessories. All of these elements may also be found on the Desktop.
When a program written for a text-based computer gets confused and needs guidance from its user, it pops a question onto the screen, then waits for the user to type in some instruction and (usually) press [RETURN]. And all this may vary considerably from computer to computer and from program to program.
To standardize such operations, Digital Research designed two ways to present questions to and get answers from the user. The simpler of the two is called an Alert Box and the other is called a Dialog Box.
An Alert Box has three parts. One of three icons is presented at the left side of the box-an exclamation point, a stop-sign, or an upraised hand meaning wait. Then you may have as many as five 40-character lines of information, followed by up to three buttons along the bottom.
GEM waits until the user has clicked inside one of the buttons, and then returns the number of that button to the user. The user can then act upon the exit information. For a Desktop example of an Alert Box, try to move one of the Disk Icons into the Trash Can. An Alert Box will appear telling you that you may not throw the disk icon into the Trash.
An Alert Box literally alerts you to a situation, then permits from one to three responses. In the above example, your only choice is to click the OK button.
Sometimes more information is needed than can just be clicked on. Dialog Boxes-naturally-permit a dialog between the user and the computer.
For example, whenever a disk file is re-named, the new file name is typed into a Dialog Box.
Whenever a Dialog Box is created by the programmer; GEM is told how big to make the box, where inside the box to draw pictures, put text and receive answers.
There are controls for putting shading, color; and different fonts into a Dialog Box, whereas the Alert Boxes are sized, drawn and operated automatically by GEM.
Programs can be run from the Desktop in one of four ways. If they have been written to take advantage of GEM, they may be given the extender .PRG and, when double-clicked from the desktop, they will be installed as a GEM program and will contain many of the elements mentioned above.
A program may be installed as a TOS program by giving it the extender TOS. When double-clicked, this program will typically boot up with a white screen and blinking rectangular cursor. In short a typical CPM/68K program. The Express Letter Processor reviewed in this issue is such a program.
Some CP/M-style programs require parameters to be input before they can run. For example, to compile a C program, you might type: C B:MYFILE. By putting the extender .TTP on this type of program, you may run it directly from the desktop. It will be automatically installed as TOS Takes Parameters. When you double-click it, a Dialog Box will appear requesting your parameters.
The fourth way to run a program is as a Desk Accessory. Desk Accessory programs are GEM programs which have been specially linked. The object file is named DESK1.ACC. Only the number (up to three) may be changed in the file name. Now, when that program is placed on your system disk and booted, it will appear in the Desk Drop-Down Menu. The Control Panel is a Desk Accessory. (For more details on how to design a Desk Accessory, see our ST Font Loader in this issue. -ANTIC ED)
So where did TOS go?
First we group together all of the routines that we have discussed so far BIOS, XBIOS, GEMDOS, VDI, AES and GEM Desktop. Together this collection of routines can be known as TOS, which stands for Tramiel Operating System.
At this writing, GEMDOS with TOS in RAM takes up about 90K and the GEM Desktop about 110K. Compare this with the 10K to 24K operating systems found in smaller 8-bit machines.
We hope that this quick overview of the different parts of TOS will help you design software for the versatile 520ST computer. When the divisions of labor are clear; it becomes possible to insert your own instruction list at any level, bypassing what may be (for your needs) a slower or clumsier routine already in place. In short, experiment! You can't hurt the computer by giving it instructions.