Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!accuvax.nwu.edu!tank!shamash!nis!sialis!orbit!pnet51!shawn
From: shawn@pnet51.cts.com (Shawn Stanley)
Newsgroups: comp.sys.apple
Subject: Re: multitasking, softswitch, etc.
Message-ID: <860@orbit.UUCP>
Date: 4 Apr 89 04:45:10 GMT
Sender: root@orbit.UUCP
Organization: People-Net [pnet51], Minneapolis, MN.
Lines: 83

dcw@athena.mit.edu (David C. Whitney) writes:
>In article <8903181259.aa27052@SMOKE.BRL.MIL> SASQUATCH@ALBION.BITNET ("Kevin O. Lepard  629-5511 x6668", 517) writes:
>>
>>Would it be possible to write a program similar to softswitch that could
>>automatically switch between applications, allowing something to run in
>>background?  I've heard people talk about "heartbeat" interrupts.  Couldn't
>>that be used somehow?  Even if this cut the speed of the GS in half, it
>>would still be running as fast as a normal //e
>
>I think everyone here needs a bit of enlightenment. As much as I would LOVE a
>multitasking environment on my //GS, I *know* that it can't be done within
>any reasonable degree of efficiency.
>
>Even Macintoshes don't have "true" multitasking (ie, Multifinder is a good
>hack, but it isn't "for real"). Only Mac IIs with the PMMU installed (or any
>IIx - 68030) can even *hope* to do multitasking. The problem? A system for
>handling virtual memory is a MUST for multitasking. Now, a virtual memory
>handler *could* be written in assembler, but one running on a screeching 68030
>going at 45MHz still wouldn't go fast enough to make the machine come within
>tolerable speed limits. That's why there is the PMMU - that's Paged Memory
>Managment Unit. It handles page faults in hardware, so things go reasonably
>fast (although most A/UX people will tell you it's still too slow).

Beg pardon, but while a MMU is desirable for multitasking, it's not absolutely
necessary.  The MMU keeps tasks from stepping on each others toes, and
provides a large amount of data/process security, but task-switching is the
main drive behind multitasking, not a MMU.  (Besides, the Amiga multitasks
without a MMU.)

>The next problem is designing a way to quickly make calls to the OS. The
>Mac (more accurately, the 680x0 series), along with 80x86 machines use
>something called "traps." They are basically undefined processor instructions
>that can be defined by the host computer. The Mac implements its toolbox
>calling by using traps. As far as I know, the 65816 doesn't have a trap
>mechanism (although, I suppose the COP instruction might get useful here...).

I think what the Apple line needs is smarter I/O, maybe more
hardware-oriented.  It really slows the system down to have to pause on disk
I/O that some other task is causing.

>Apple is going to release a new system sometime that uses the 68030 (or PMMU)
>to do virtual memory stuff. Sometime after that, MultiFinder will be a thing
>of the past, as *real* multitasking will be here. This is relatively easy
>to do on the Mac while it's remarkably hard on the //GS. So hard in fact that
>nobody should even bother.

I hear the Mac SE/030 is going to be A/UX capable.  It's actually the design
of the OS that makes it so difficult to integrate multitasking.  For instance,
the MultiFinder (from what I hear) does context-switching through event loops.
Not particularly efficient, of course, but then the Finder/toolboxes weren't
designed for multitasking to begin with.  A/UX, on the other hand, was, and
the programs written to run under it came into being on a multitasking system,
therefore they live in it well enough.

As to "nobody should even bother", please speak for yourself.  Those that wish
to bother should feel free to do so without being told how worthless their
efforts are.  I've always felt that the Apple II line is a good hobby line,
and "shouldn't even bother" just doesn't fit into that universe too well.

>Sorry to rain on your parade, but a multitasking OS is a physical impossibility
>on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting
>GNU C and GNU Emacs, and I'll be VERY VERY happy!

It's only a physical impossibility without interrupts.  Your statement that IT
CAN'T BE DONE just shows that you don't know enough to accomplish it yourself,
or you're not willing to put the effort into even thinking about how to
accomplish it.

Right now, I can envision methods for accomplishing it.  For instance, if
someone wanted to write a shell, and then write programs that would be
shell-aware, and the shell had multitasking abilities, there you go.  As is
true with most multitasking systems, the software that runs under it is
generally designed to run under it (with I/O handing, etc.), so that's an
obstacle to overcome to be sure.

I'm not saying that all Apple II software should be converted to some
multitasking shell.  I am saying that it would be fun to do something like
that.  Again, in my opinion, it's a hobby machine, and that to me means that
there are no absolute rules with regard to what you can and can't do.  (Beyond
the obvious.  And the absence of a MMU is not one of those.)

UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn
INET: shawn@pnet51.cts.com