Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!bu.edu!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.sys.apple2
Subject: Re: apple // and multitasking, perfect together! (??????????)
Message-ID: <1990Mar8.022901.24974@world.std.com>
Date: 8 Mar 90 02:29:01 GMT
References: <14298@phoenix.Princeton.EDU>
Organization: Saber Software
Lines: 31

I'm getting into this rather late, but here's my two cents.

I thought about doing such a thing for awhile and checked into some
historical methods of accomplishing it.

First, you can provide memory protection through emulation without a
lot of problems.  Whenever you want to use a non-relative instruction,
replace it with a BRK sequence which is interpreted and checked for
validity.  While the interpretation will take some time, it's not all
that bad and does give the protection you want in a multitasking OS.

Second, you can provide a non-preemptive multitasking scheme without a
lot of problems.  Many other systems do this with good results --
witness the Mac multifinder.  Non-preemptive means that you don't
interrupt a process at a random time -- it gives up control
(implicitly or otherwise).  Most of the time this is done during
system calls such as I/O routines (which I assume you wish to
provide).

There are a few problems with implementing a multitasking system under
the Apple hardware other than those I've discussed.  The biggest is
its very primitive I/O.  Since I/O is handled in software and not
hardware, you don't get to spend I/O time running something else.
This is a severe performance bottleneck, especially since you don't
have the memory to do I/O caching with periodic synchronization.

Happy hacking,

jim frost
saber software
jimf@saber.com