Home Documentation Products History Screenshots Forum

 
 
 
 MiNT mailing list
 Bugtracker
 ChangeLog
 
 HyperActive
 www.ataricq.org
 www.atari-users.net
 sparemint.atariforge.net 
 

The Unofficial XaAES Page
From CP/M to TOS MiNT & MultiTOS MiNT goes FreeMiNT The XaAES story
 
The CP/M operating system
When the first ST model was released back in 1985, Atari had developed an OS largely based on already existing components.
Atari ST
The Atari ST
The core of this new OS consisted to a great extent of CP/M, originally developed by Gary Kildall and often considered to be the first cross-platform operating system. Kildall had isolated the parts that addressed hardware directly, and moved them into a module which he called the BIOS - the Basic Input/Output System. This ensured that the system could easily be adapted to new hardware platforms, without the need for major rewrites of the complex core of the OS.
 
The 68k version of CP/M that Atari adapted for their ST range of computers is referred to as GEMDOS. The Atari GEMDOS comprise the highest level in TOS, while low level tasks are handed over to the BIOS as well as the XBIOS. The latter ran at a slightly higher level where it included routines that the new OS needed internally, like managing interrupts and setting screen location.
 
GEM - The graphical user interface
Atari added a graphical user interface to GEMDOS in form of GEM, short for Graphical Environment Manager. Originally developed by Kildall's company Digital Research, GEM in its turn consisted of 2 layers - the AES (Application Environment Service) and the VDI (Virtual Device Interface).
GEM Desktop
GEM Desktop
While the VDI takes care of the actual blitting, drawing, plotting and filling, the AES is the highest level in GEM and as such provides functions to maintain window redraws and drawing of dialog boxes as well as evaluation of user input via the mouse and keyboard. The last ingredient of GEM was the GEM Desktop which in reality was nothing more than a GEM program itself. Via the GEM Desktop the user could now perform almost any task that any command-level operating system would allow, such as copying or deleting files and launching programs.
 
Atari's version of this new, CP/M-based OS was given the name TOS - The Operating System. There have been suggestions that the acronym instead translated to "Tramiel Operating System", after Atari's boss at the time, but early Atari manuals did in fact make direct references to The Operating System.
 
TOS - A singletasking OS on chip
The early ST models loaded TOS 1.0 from floppy disk, but Atari soon after started supplying the ST with TOS on a ROM-chip.
TOS ROM-chips
TOS ROM-chip
There were some clear advantages with this approach, and sure enough some disadvantages too. Loading the operating system from a ROM chip made the ST boot up very fast and also saved some precious memory, as the OS did not have to be loaded into RAM. However, with the OS in ROM there was no easy way to allow updates - the user had to get hold of a new TOS ROM-chip and physically replace the old one. Any bugs that might still be lurking in the operating system code would have to be cured by external hacks and patches.
 
TOS was a single tasking operating system, in essence limiting the user to run only one application at a time. As a small exception to this rule there were desk accessories, small programs that were coded to be accessed via the GEM menu bar.
The GEM menu bar
GEM menu bar
While working in a GEM application one could have up to 6 desk accessories open concurrently. This solution in essence meant that TOS had support for a primitive kind of co-operative multitasking in GEM. As opposed to pre-emptive multitasking, which gives each process a regular "slice" of operating time, the co-operative mode means that while several processes might be running simultaneously only one of them can be active at a time. This might sound complex enough but since programs written for GEM need to return control back to the AES while being idle (waiting for user input), this multitasking mode works very well. If however a certain process would perform CPU intensive tasks or wait for user input, any other process would become un-accessable until that task was finished.
 
Proceed to next page>
 
 

The Unofficial XaAES Page © Joakim Högberg 2003-2015