MULTITASKING ON THE ST
PART 1
Introduction and TOS Solutions
BY JIM PIERSON-PERRY
They said a multitasking TOS couldn't be done. For years, high-level engineers at Atari claimed the ST's 68000 microchip simply wouldn't handle the added workload. Yet multitasking on the ST has existed in one form or another ever since the computer's debut. In the first installment of a special two-part series, Jim Pierson-Perry discusses the history of multitasking TOS and the recently announced MIDI-Tasking from Atari.
A restatement of Pournelle's Law is "one user, one computer." Under the normal Atari TOS operating system, this becomes further restricted to "one user, one computer, one job at a time." While many users accept this as standard ST behavior, the situation is actually a gross waste of the computer's resources. While you're staring at the screen--thinking of the next "what if" for your spreadsheet or brush strokes for a painting--your ST is locked in stasis, wasting thousands of operating cycles.
A multitasking operating system "fills in the gaps," enabling two or more programs to seem as if they're running at the same time. It can make more effective use of both the computer's capabilities and your own time than the present Atari operating system can. Activities such as formatting disks, downloading from a BBS or compiling a program can be done automatically while you concentrate on writing a letter. Some of the most demanding uses for multitasking are in the music/MIDI area where there is a vital need for several applications (sequencer, mixer, mapper) to run simultaneously in order to exchange data and I/O port accesses with millisecond timing accuracy.
The Basic Terms
A process (or task) is a generic term for a set of commands to be executed by the computer. For our purposes, we can consider each program to be a single process.
At any point in time, a particular process is in one of three states: actively running, ready to resume running (just waiting for the processor) or blocked (needs access to a system resource and cannot proceed even if picked up by the processor). Examples of a blocked process are ones that wait for a timer or a keypress.
Processes are swapped in and out of execution by a scheduling routine called the process dispatcher. The operating system sets a priority level for each process. Each process also has certain memory needs which must be kept inviolate of other processes. For multiple processing to work, developers must "follow the rules" for proper software. For example, failure to release memory after an application finishes is a frequent problem with multitasking on the Amiga. Newer processors, such as the Motorola 68030 used in the TT, contain a special hardware memory management unit (MMU) that facilitates multitasking.
The actively running process is in the foreground; other ongoing processes are in the background. Many simple processes are well suited to background operation, such as printer spooling and disk formatting. A direct example of this is the Shadow terminal program (Antic Software) which lets you automatically download from a BBS in the background while running a program under the standard GEM operating system.
While some processes are content to run in a vacuum, others thrive on sharing data or status messages between themselves. A relatively simple example is via the desk-accessory pipeline, typified by the add-on functions for DEGAS Elite described in the Summer 1987 issue of START. A much more sophisticated system is used by the M-ROS system from Steinberg/Jones which lets a MIDI program send its output either to an external port or as input to another MIDI program running concurrently.
Switcher Solutions
Although multitasking of multiple GEM programs has only recently become a reality on the ST, several earlier variations on the theme have been successfully exploited. The most common substitute is a switcher program where applications run in isolated memory partitions. This is not true multitasking as only one process runs at a time. The others are suspended and only resume when switched to active status. When an application is switched in, it takes over all ST resources (except memory previously reserved for other partitions) exactly as if it were running by itself. Switching is done on an as-needed basis by the user, through some command/function keystrokes.
There are several limitations to switchers. A major one is that memory sizes are fixed and cannot be altered without restarting from scratch. This also applies to memory released when you quit one of the applications; it is not made available to the remaining processes. There is typically no support for interprogram communication. The only solution is to save data as a disk file from one partition, then read it back in after switching to another partition.
For the ST, switchers come in several levels of capability and complexity. Juggler II (MichTron), Revolver (Intersect), K-Switch (Kuma) and HybriSwitch (Hybrid Arts) are examples of simple switcher programs.
Moving up the ladder in capability takes us to switcher programs designed to share data and functions between concurrent processes and govern shared system resources. These systems were exclusively developed to support MIDI applications, which are fairly unique in their demands for real-time interaction between processes and system hardware resources. Examples of this include the Multi-Program Environment (Dr. T's Music Software), Soft Link (C-Lab) and M-ROS (Steinberg/ Jones). As with the other switcher programs, applications must be assigned to fixed memory partitions and can only be viewed and/or controlled one at a time.
Experimental Systems
There are two TOS (non-GEM) multitasking environments for those interested in studying operating systems: MX2 and MINIX. There is precious little information available regarding MX2 other than that it's a TOS multitasking kernel from Fred Brooks. It was written in Modula-2 and is posted with source code, updates and some auxiliary tools on national BBSs. It is intended as a project to explore systems programming on the ST, rather than a basis for commercial software development. Those interested in pursuing MX2 should try to reach Brooks through his message area in Category 3, Topic 25 of the GEnie BBS ST Roundtable.
Significantly more information, in fact an entire book, is provided for MINIX (short for Mini UNIX), which was written by Andreas Tanenbaum to teach systems programming. It is available for the ST, IBM and Macintosh from Prentice-Hall along with the companion book, Operating Systems: Design and Implementation.
The ST version shipped is MINIX 1.1; additional code is available on national BBSs to upgrade it on par with the IBM version 1.5 release. For more information, check Category 3, Topic 31 of the GEnie BBS ST Roundtable.
 |
| Beckemyer's MT C-Shell, with the Visual Shell Manager, running on the Moniterm 19-inch monitor. |
Commercial Multitasking
The original version of MichTron's Juggler was a noble attempt to provide multitasking for both TOS and GEM programs. According to author Tim Purves, it was virtually identical in concept to Multifinder on the Macintosh. Unlike other switchers, it used dynamic memory allocation and was based on extensions to the inherent GEM kernel. It did not succeed, largely due to problems with existing software that did not follow proper guidelines. Multifinder had similar problems but, thanks to support from Apple, developers had to fix their software or be out of the market. Juggler had no such support from Atari, thus no driving force for developers to seek compatibility.
The only viable commercial offering is Micro RTX from Beckmeyer Development Tools. This is a robust multitasking/multi-user system that can run several TOS programs and one GEM program concurrently; desk accessories are also supported. Up to 12 users can be logged in together using a hardware expansion on a Mega ST. It was first released in 1987 and has been constantly refined and improved since then.
A UNIX-like command-line interpreter interface (Micro C-Shell) is available to control the Micro RTX system. A visual shell interface (VSH), based on the UNIX graphics interface used in Sun workstations, can be used in conjunction with Micro C-Shell. This enables individual applications to run within standard GEM windows, all on screen together. Efforts are underway to mate Micro RTX with other graphical user interfaces such as NeoDesk. A shareware version of Micro RTX was recently released on national BBSs. Several commercial applications are available from Beckmeyer that are based on Micro RTX, including a version of the Citadel BBS program and a multiuser point-of-sale system.
Stay Tuned
Next time we will explore the concepts and implementation of MIDI-Tasking, the official Atari GEM multitasking system developed and supported by Intelligent Music. It is currently in beta test and developers are working to validate (or modify) their software to run under it.