🚀 go-pugleaf

I think that the people who insist that multi-tasking is not useful
to the average user of a personal/home computer are missing a few
vital points.

Since these people dismiss multi-use multi-tasking as something only
advanced users will ever need, let me address what seems to most people
to be a simple, single tasking problem.

Terminal emulation.

The Digital Equipment Corp. VT100 terminal processes and displays characters
comming from the serial line, scrolls the display, blinks characters and
the cursor, and processes keystrokes into characters, control sequences and
state transitions.  With few exceptions, these things do not interfere
with eachother.  Even when in slow scroll, characters are sent when they
are typed rather than waiting for the scroll to complete.  This is done
in a real VT100 with a simple multitasking kernal and several tasks, each
responsible for its own parts, and communicating with the others through
shared memory structures.

On the ST, most terminal emulators do this by checking for keystrokes
and incomming characters alternately, and processing them as they get
them, so if a sequence received from the serial line takes a long time
to process (say, split-screen jump scrolling), the characters typed at
the keyboard are not processed until that process completes, meanwhile
the host sending these characters has continued with what it was doing,
and the abort command (^C?) that you sent to the host gets there too late.
This is better handled using multi-tasking, though async. I/O with completion
routines (ala RT-11) or "unsolicited character AST" (software traps on
character reception) and timer routines (ala RSX-11M) are reasonable
substitutes, but these are not available on the ST, Amiga, Mac, MD-DOS,
most UNIX-like systems, or most other personal scale machines.
Unix systems do this with multi-tasking (fork).  Most personal computers
use a similar approach to TOS.  With a graphics terminal, the problems
with this approach become more visible.

Multi-tasking by itself will not solve all of the problems in terminal
emulation.  The kernal/OS should be designed to allow close cooperation
between tasks.

Other "average user" applications that work better with multi-tasking --
Networking/Electronic mail, file transfer, interactive debugging,
real-time simulations and games.

Multi-tasking kernals are not large and complex.  I helped write a simple
multi-tasking real-time kernal for a M68000 based system with message
passing, streams, async I/O, mark-time requests, event notification
and I/O completion routines, and event waiting for a project I was working
on at a previous job.  This system was written mostly in C and had a built-in
debugger, yet occupied less than 16K of code for the kernal.  It did not have
any file-systems, though.  This kernal was more efficient than GEMDOS,
CPM-68, MS-DOS, yet was smaller than any of them (I know, no file system,
but one could have been added at minimal cost -- it would have been a
task (like in MINIX)).

To sum it all up:

	The average user on a limited disk/memory machine can use multi-tasking
	to great effect.  What the average user probably does not need is a
	multi-user system (like Unix or VMS).  Multi-tasking systems do not
	need to add alot of overhead and are not difficult to design or
	program for.

Disclaimer:
	UNIX is a trademark of Bell Labs, AT&T, or someone who looks like
	them.  RT-11, RSX-11M, VT100 and VAX are trademarks of DEC.  MS-DOS
	is a trademark of MicroSoft.  CP/M is a trademark of Digital Research.
	Tempo, Taurus, and Pinto are trademarks of Ford Motor Corp.
	In Canada, Asprin is a trademark of Bayer.

	This is NOT cross posted to comp.sys.amiga, since every time I
	cross post to there, someone flames me for being closed minded
	about the Amiga and then proceeds to be closed minded about the
	Atari ST.  I'm not up to a flame-fest, so I'm posting only to
	"friendly" territory.
-- 
					Daniel A. Glasser
					...!ihnp4!chinet!dag
					...!ihnp4!mwc!dag
					...!ihnp4!mwc!gorgon!dag
	One of those things that goes "BUMP!!! (ouch!)" in the night.