No Fragments Archive 12: Textmags & Docs/nf_archive_12.iso/MAGS/DOCS/OS.ZIP/OS.DOC

Text File | 1997-04-16 | 12.1 KB | 323 lines

        The Operating Sytem of the Atari ST
        === ========= ===== == === ===== ==
            copyright 1987 by John Ogawa

No part of this document may be reproduced without permission
from the author. Permission is granted to copy this document for
non-commercial purposes only.




    Table of Contents
    ----- -- --------

1.0 A wide angle view

2.0 The TOS and some history
    2.1 The GEMDOS
    2.2 The BIOS
    2.3 The XBIOS
    2.4 The Line A routines
    2.5 Wrapup of TOS

3.0 GEM
    3.1 The AES
    3.2 The VDI
    3.3 Wrapup of GEM

4.0 A final wrap up

5.0 Where to read

6.0 Where to reach me




Hi there.  This article is an attempt to describe the workings of
the Atari ST's operating system.  Be forewarned that I am not an
ST wizard, and that any information in here was gained through
reading non Atari documentation, playing with the ST, and talking
to people.  In other words, it may not be right! But maybe it is.
Who knows? Read on . . .

   The Atari ST has an extremely complex operating system
consisting of several groups of routines that comprise several
different levels of interaction with the machine.  Geez, what I
meant to say was that there are a lot of calls, and that they can
be divided into groups, and these groups are related to each
other in a tree-like way.  The major libraries are the BIOS, the
XBIOS, the GEMDOS, the Line A routines, the AES, and the VDI.
These groups can in turn be put into TOS and GEM.  How do they all
relate? Well, follow me! In the following sections I'll take a
bottom up look at the individual libraries, how they relate to
each other, and what they do.  The first section will talk about
the overall organization of the OS (operating system).




1.0 A wide angle view
----------------------
The ST's OS can be divided into two large groups of routines,
TOS (Tramiel Operating System), and GEM (Graphics Environment
Manager).  TOS has the underlying routines that make the machine
run, and GEM has the routines that make it talk nice to you.
   TOS can be further broken down into the BIOS, XBIOS, GEMDOS,
and Line A libraries.  These libraries control machine dependant
functions (like controlling the peripherals) and basic I/O.  The
Line A routines are basic graphics routines that are used by GEM
to create the windowing environment that the user sees.
   GEM contains two libraries, the AES and VDI routines.  GEM is
responsible for the windowing environment and the desktop that
make using the ST more intuitive.  The AES is concerned mostly
with windows and dialogs, things that the user interacts with.
The VDI routines handle complex text display and high level
graphics manipulations.
   In the next sections I'll go into the two groups of libraries,
TOS and GEM, and their respective libraries in more detail.  I'll
start with TOS.




2.0 The TOS and some history
-----------------------------
   TOS is the heart of the ST.  Everything you do, run, or write
on your ST uses TOS.  These are the routines that do all the lower
level tasks of running programs.  TOS is present and active in the
ST at all times.  A little information about the background and
design of TOS may help to make it's job clear.
   In the beginning was CP/M, an OS that I am very familiar with
:-).  CP/M was designed to run on a large number of computers,
while keeping a standard interface so that people and programs
could migrate from machine to machine without too much pain.  A
good idea, one that was very popular.
   CP/M achieved its portability by dividing itself into two
distinct sections, the machine independent and machine dependant
routines.  The code for the machine independent routines was the
same across machines, and whenever it did anything it called the
machine dependant routines using standard names.  This worked
well, and programs very easily moved from machine to machine, and
the CP/M community thrived.
   The came IBM.  When IBM/Microsoft designed PC/MS-DOS they kept
several of the concepts of CP/M.  Then came DRI.  They designed a
machine independent set of routines called GEMDOS which was based
on CP/M and MS-DOS.  It is GEMDOS that makes up the hardware
independent part of TOS.  The file manipulation and task handling
routines of TOS are in GEMDOS.  To fill out TOS, Atari added the
machine dependant routines in the BIOS and XBIOS.  Finally, to
make graphics programming easier, Atari added the Line A
routines.
   So TOS is composed of the "higher" level GEMDOS routines, the
machine dependant BIOS and XBIOS routines, and the Line A
graphics routines.  In the next sub-sections I'll very briefly
describe each of theses libraries.


2.1 The GEMDOS
---------------
   The GEMDOS, as noted before, are the machine independent
routines for handling files and tasks (programs) and doing "high"
level I/O.  They bear a great resemblance to MS-DOS routines.
These routines make it easy to manipulate files by using Fopen,
Fread, and Fseek.  Controling the execution of programs is managed
using routines such as Pexec and Pterm.  Easy I/O is done using
Cconin and Cconout.  These routines allow the programmer to
perform most of what s/he would like to do with little fuss.
   The GEMDOS is the highest level of TOS.  It is built on
routines in the rest of TOS, namely the BIOS and the XBIOS.  As we
look at the BIOS and XBIOS in the next sub-sections you will find
overlap between them and the GEMDOS.  GEMDOS was written to make
the programmer's job easier by incorporating the lower level
routines into higher level routines that are more specific.


2.2 The BIOS
-------------
The BIOS is the collection of routines that the ST uses to
communicate with the many devices available to it.  Using BIOS
routines you can read and write to, and get the status of, the
serial port, the midi port, the parallel port, the disks, and the
screen/terminal.  These routines (like Bconin and Bconout) are
general routines.  With the same routine you can get information
from several sources by varying the calling parameters.  You can
see how the device specific routines in the GEMDOS can be built
from the BIOS routines.


2.3 The XBIOS
--------------
These routines are very much like the BIOS, but involve much more
control over the ST's peripherals.  In general, you read or write
with BIOS calls, you *control* with XBIOS calls.  These routines
also allow you to control the sound chip, the floppy disks, the
serial port, the mouse, and the midi port.  GEMDOS is also built
from these calls.


2.4 The Line A routines
------------------------
These routines are the graphics primitives in the ST.  They allow
you to create complex graphics with relatively few, simple
commands.  With these routines you can draw pixels, lines and
boxes as well as control sprites and the mouse pointer.  The GEM
routines are built from these routines (but more about that
later).


2.5 Wrapup of TOS
------------------
That was TOS.  Hope it was kind of clear.  Sorry if it wasn't.
Theose routines are the basis for anything you will run on the
ST.  The next level up is GEM.




3.0 GEM
-------

Now we come to the complex stuff.  GEM, the Graphics Environment
Manager, is a machine independent (runs on the IBM too) set of
routines that enable the programmer to use windows, dialogs, the
mouse, buttons, and sliders to interface with an end user.  GEM
also allows you to present complex graphics and output them to a
number of different devices.  It is built so that these features
can be defined, accessed, and used with a relatively small number
of routines.  It also allows limited multitasking through desk
accessories.  In addition to all that, GEM allows inter-process
communication and control.  I said it was complex!
   GEM consists of two libraries of routines, the AES
(Application Environment Services) and the VDI (Virtual Device
Interface).  The AES is responsible for drawing and getting input
from windows and dialogs, as well as coordination of multiple
input sources and the interaction between concurrently running
programs.  It is primarily concerned with input.
   The VDI is responsible for complex output.  It handles fancy
text output, high level graphics output, and output to devices
other than the screen.
   In the next two sub-sections I'll describe the AES and VDI
libraries in a little more detail.


3.1 The AES
-----------
The AES, as I mentioned before, is mostly concerned with input.
While it is responsible for drawing windows and dialogs, it's
most important job is to receive input through those windows and
dialogs.  The evnt_button, evnt_timer, and evnt_multi calls are
input related calls in AES.
   Another function of the AES is to coordinate more than one
running program.  Inter-program messages and coordination are AES
responsibilities.
   Central to the AES is the notion of an object.  An object is
(usually) something to be drawn in a window (like a slider bar)
or a dialog (like a button).  Objects can also be text or boxes.
A collection of objects is organized into a tree, which gives
information about the relationships between the objects.
Once drawn, some object can be acted on (selected, moved, sized,
etc.), and the results of these actions comprise the input that
the AES is charged with obtaining.
   The AES attempts to provide a smooth and easily programmed
interface between the user and the program.


3.2 The VDI
------------
The VDI routines are primarily concerned with output.  The VDI
offers complex graphics capabilities using simple and easily
handled routines.  It also handles fonts and text output.
   One of the most important VDI functions is to provide access
to a variety of output devices.  VDI routines are built so that the
device that they are outputting onto is not specific.  One can
draw a circle on the screen or on a plotter with the same
routine.  The device independent portion of the VDI is the GDOS.
Its routines control the peripheral devices and allow output from
VDI routines to them.
   The important concept in the VDI library is the workstation.  A
workstation is a device that can handle output from the VDI
routines.  Printers, plotters, and the screen are examples of
workstations.  Each VDI routine is given the workstation it is
expected to output to.
   The VDI provides a flexible means for presenting complex
output to the user.


3.3 Wrapup of GEM
------------------
Well, there is GEM.  As you might guess, the GEM routines are
built on the BIOS, XBIOS, and Line A routines.  GEN lets the
programmer present sophisticated information elegantly and
receive complex feedback using a library of high level routines.
GEM is the highest level of the ST's operating system.




4.0 A final wrap up
-------------------
I've done my best to describe the ST's operating system and all
it's interconnections, hierarchies, and overlaps.  Negotiating
your way around all those routines as a programmer can be very
confusing.




5.0 Where to read
-----------------
Most of the information in this article was gleamed from all of
the books listed below. In addition, Tim Oren's ProGem series was
an invaluable tutorial on the ins and outs of GEM.

    "Programmer's Guide to GEM" by Phillip Balma and William
        Fitler. Sybex, 1986.

    "Atari ST Internals" by K. Gerits, L. Englisch and R.
        Bruckmann. Abacus Software, 1985.

    "Atari ST GEM Programmer's Reference" by Norbert
        Szczepanowski and Bernd Gunther. Abacus Software,
        1986.

    "Mark Williams C for the Atari ST, version 2.0" (manual).
        Mark Williams Co., 1986.

And of course, many thanks to all the people in the ST community
who have answered my questions. I'll probably have a lot more.
:-).




6.0 Where to reach me
---------------------
Feel free to write me and correct anything I have said or ask me
questions. Though for the latter, remember that I probably know
about as much about the ST as you do!
   I can be reached at:

    GEnie:     TUSHIE

    Usenet: [e-mail]
            or
        ...ucbvax!sdcsvax!sdcc13!ps136sag

    BBSs:    Sysware
        [phone]
        ST-SDACE
        [phone]

    USMail: John Ogawa
        1028 W, Lewis Dr.
        San Diego, CA   92013

Happy Hacking!

tush
5/19/87