From: jyoung@nyx.cs.du.edu (Jeff Young)
Subject: MultiTOS re: TOS   
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Tue, 28 Jul 92 02:54:04 GMT

In article <1992Jul27.004328.25208@cs.rose-hulman.edu> catapcnl@Rose-Hulman.Edu. (Chris Lawrence) writes:
>
>Did they ever fix that crap in Atari's TOS about those Line A and Line F  
>op-codes (for the unininitiated - Atari uses (used?) illegal (on the 68000)  
>instructions (that triggered software exceptions) to call many system routines.   
Atari Falcon uses 68030 AND MultiTOS. I mailed French developer to
compare and he said MultiTOS and Unix are very close so millions
of students will buy Falcons because of low price and Unix
is used at many schools around  world.

This is short MultiTOS description..

 MultiTOS (preemptive multitasking OS with memory protection, Unix system 
 call compatible with IPC pipes/shared memory/process spawning) included
 in ROM and floppy disk.


     "Since most programs spend a relatively large portion of their time
awaiting AES event input, MultiTOS is designed to reclaim CPU time that
would otherwise be spent in this fashion. Thus, even without altering
process priorities, MultiTOS manages to increase overall throughput. More
sophisticated forms of adaptation further allow MultiTOS to adjust
process priorities to optimal levels. However, if a user finds that
MultiTOS' own decisions aren't working well for a certain combination of
applications, a utility allows him to graphically review how much CPU
time each process is being offered and how much it is using, and alter
priorities at will." The result is that, from the user's perspective,
MultiTOS seems to perform at a rate similar to single-tasking TOS.

     MultiTOS allows as many processes to run concurrently, and as many
windows to be open, as memory permits. It can employ the 68030 Memory-
Management Unit's (MMU) hardware-based memory-protection capability to
prevent accidental memory trespass and restrict how much memory each
process occupies. Well-behaved applications can set their own boundaries,
using Malloc() and Mshrink() calls; while badly-behaved applications can
be restricted deliberately, by the user. Even in the absence of an MMU
(i.e., when MultiTOS is running on a 68000-based ST), features have been
incorporated to permit indentification and graceful shutdown of rogue
processes, avoiding system crashes in all but the most severe cases.

     File- and record-locking is now automatic at the TOS level -- another
reason why current applications don't need to be rewritten to run under
MultiTOS. Output from TOS (i.e., non-GEM) applications is piped
automatically to the window-manager, and output is displayed in its own
window. A variety of Inter-Process Communication (IPC) facilities are
supported, including piping and forms of shared memory, as well as a
brace of options by which processes may "spawn" child-processes, and
control their operation.

     Though a portion of MultiTOS will be built into ROM in future Atari
computers, the bulk of the operating system is RAM-loaded. According to
Jack Tramiel, Chairman of Atari Corp., MultiTOS will be made available in
some form for all ST systems (though hardware memory-protection will not
be available on systems lacking a 68030 with MMU), and will be
incorporated in future Atari products. A pre-release version of the OS
has already been sent to developers, along with a reworked Developer's
Kit and MiNT-kernel utilities package. Commercial release is expected in
Winter. (For further information, developers should contact Bill Rehbock,
Director of Application Software, Atari Corp., 1196 Borregas Ave.,
Sunnyvale, CA 94089, (408) 745-2082, FAX: (40) 745-2088 ).