Conference hydra::amiga_v1

    Some naughty games take over the machine (usually self-booting,
    computational-intensive ones, like FS][, Marble Madness, Defender
    of the Crown, etc.).  Most others can be toggled to a background
    plane by hitting left-Amiga-N, or left-Amiga-M.
    
    The user has to exercise a little common sense restraint when
    multitasking.  It would be dumb to compile a buggy program while
    finishing a $25 download from Compuserve.  
    
    Personally, I have run DeluxePaint, Sonix, Scribble (an editor)
    and my terminal program all at once.  I presently have 1.5 megs.
    One must really consider what multitasking means, though.  For example,
    I consider a task that is creating useful output while I'm off doing
    something else to be real multitasking, such as using a terminal
    program to do a long upload or download while I am backing up disks
    or doing a long printout.  The Amiga is of course most effective
    when multiple tasks do not demand the same physical device, such
    as drive 0, although it can deal with it.  I can open several CLIs
    and demand printouts from two different files on the same disk,
    and each task will share the drive in a civilized way.
                      
    Of course, frequently, a second or third task is just hovering in
    the background, waiting for input.  The MAC can accomplish this
    with Switcher, but it is not real multitasking.  
    
    But to answer your question, yes, the majority of software either
    runs in a sizable window, or a dropable screen.  It's kinda hard
    to explain, maybe you should get a knowledgeable dealer to give
    a thorough demo.
    
    The nice part is that with the IFF graphics/text standard emerging,
    one can share the contents of the clipboard device with various
    applications.  This is no big deal, since the MAC could do it from
    day one, but it makes the Amiga seem more like a real computer now.

Multi tasking was one of the primary reasons I bought the machine
in 85.  At the time the colors were just fringe benefits.  I wanted to
to C hacking, potentially in a development capacity.

I have not been disappointed.  I have 2-1/2 megs, and keep all kinds of
things around for fun and use in memory.  The major tasks I would run
would be the compiler/linker and downloads over the phone;
while minor tasks I keep around all the time are GFXMEM (a memory monitor)
EMACS, and occasionally OING (cute sprite program I get endless kicks from
for no particular reason).  There are always GOTCHAS, if you play with
priorities (or use programs that do), or if you aren't carefull about
floppy access competition.  But for the price, I have been extremely happy
with the multitasking.  And I'll probably be happier when I try the
recoverable ram disk utility,  but I haven't yet.

Dave Tenny
DTN 225 6089
BACH::TENNY

Re .0:

As the previous two replies state, a program on the Amiga does not have
not have to do anything special to work with multi-tasking.  That is a
property of any true multi-tasking system.  For example, a VMS program
doesn't have have to be written to take advantage of VMS multi-tasking.

About the only programs that do not work with multi-tasking are game
programs.  The Amiga operating system provides two ways for a user program
to take take over the machine.  Thus, a program may, if it wishes, turn
off multi-tasking.  Arcade games are to be the only offenders I have come
across.

There may be a misconception that you may have about multi-tasking  (I
apologize if I have misread your note here).  The important thing about
Amiga multi-tasking that sets it apart from more primitive task switching
mechanisms is that it time slices; the 256 priority levels is merely 
icing on the cake.  The difference between true multi-tasking and more
primitive forms of task switching is that task switching is automatically
managed by the system and that all tasks are basically the same.

A Mac, an ST, an MS/DOS clone, and other similar systems can be thought
of as having primitive multi-tasking because it is possible to switch
between tasks.  Let's call this class of operating systems Primitive
Tasking Systems, or PTS for short.  I do not mean primitive in an
pejorative sense anymore that I would be insulting them to call them
non-supercomputers.  (Be aware that this discussion is going to be a
mismash of several operating systems that while it is representative
of the operating systems of Macs, STs, and clones, it is not necessarily
faithful to any of them.)

Under a PTS, there are basically three types of tasks: normal user
programs, "desk accessories," and system tasks.  Normal user programs
have no restrictions on what they can do.  They can compute for as
long as they want, do any type of system calls they want, do any type
of I/O that they want.  They normally have control of the CPU (except for
sharing with system tasks).  Desk accessories basically are similar to
user tasks, but somewhat parasitic on normal tasks.  A desk accessory
only can get control of the CPU when the user decides to task switch
by calling the desk accessory (selecting it from a menu or whatever).
When this happens, the normal user program is frozen, and the desk
accessory has full control (except for sharing the CPU with system
tasks).  The third type of task is the system task.  The system task
gets control through a timer interrupt (just like time slicing under
a true multi-tasking operating system!) and keeps control until it
gives explicitly gives it up.  The most important restriction on a
system task is that it not do very much.  If the system task does not
give up the CPU, then it takes over the entire machine.  Under some PTSs,
if a system task does not complete its processing before the next schedule
timer interrupt goes off, the system can become corrupted.  A system task
may have further restrictions in that it may not be able to perform a
arbitrary system call.  A system task is usually responsible for saving
its own state (it may even have to save and restore its own registers!).

Under this type of OS, it is not unusual for a normal program and a desk
accessory to be different types of programs with different entry and
exit conditions.  Luckily for the programmer, many times linking with
the right library or using the proper compiler options may allow the
same source program to be built as a normal program or a desk accessory.
However, system tasks are usually so weird that you must start up to
write a program as a system task and it can not be run as anything else.

Under true multi-tasking, there is only one real class of task.  This
task can do anything it wants for as long as it wants.  It needs make
no special provisions for multi-tasking.  In addition, task switching
is automatic: neither the user or the program need do cause the CPU
to be divided between tasks.

You might note that if you have a multi-tasking kernel, it affects how you
write the rest of your operating system.  On a PTS, there are parts
of the operating system that are written as "system tasks".  If you have
a multi-tasking kernel, you can write these tasks as normal tasks and let
the kernel worry about scheduling and setting up the task.  For example,
on the Amiga, the operating system immediately several tasks to monitor
for mouse and keyboard input and perform general housekeeping.  In kind,
these tasks are no different from a user C program.

For an intermediate level of tasking between a PTS and true multi-tasking,
look at Microsoft Windows.  It is interesting because it is an attempt
to add multi-tasking after the fact to a PTS.  Although, you would think
that turning a PTS into true multi-tasking would not be that hard, in
practice, it is very difficult.  For multi-tasking to work, you need to make
the right system services available to the user program.  The user program
needs to be able to request to be signaled when an event occurs rather
than having to loop polling for the event.  The user program needs to
be able to inform the operating system that it wants to access shared
data structures in a safe way to avoid one task getting half of
an update done before another task tries to read the data structure.
The file system management needs to be able to cope with multiple requests
from different tasks to perform I/O.  (You don't want a disk corrupted
because a directory wasn't completely updated before another task comes
along and writes stuff to the disk!)

Putting multi-tasking in an operating system sort of changes the rules.
Making existing programs to continue to work even though they break
the new rules is not easy.  Under MS/Windows, the decision was made
(I have been told) to only allow task switching when a user program
makes a system call.  The reasoning is that the program can arbitrarily
bad, but the system knows the state of the program when the system
has taken control.  Thus, the system knows enough about the program
to interrupt it and task switch.  The only problem with this is that
a compute bound program, in effect, turns off multi-tasking.  So,
under Windows, you could down load a file using Kermit and edit a
program at the same time.  But you couldn't download a file and compute
a FFT at the same time: while the FFT runs, Kermit doesn't.

Recently, a computer neophyte asked me why the Amiga doesn't have
desk accessories.  I explained that all the programs on the Amiga
were desk accessories, that that was what multi-tasking meant.
(Actually, to use the same definitions I used above, I would have to
say that all programs on the Amiga are unrestricted system tasks,
but that wouldn't have helped the fellow understand.)

I am sure that a lot of readers of this note have noticed that I have
greatly simplified (but I hope not oversimplified) the various forms
of tasking support in operating systems.  In addition, as I said before,
my PTS is not really a Mac, ST, or MS/DOS machine.  I have even glossed
over some basic facts.