Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!stephens
From: stephens@latcs1.oz.au (Philip J Stephens)
Newsgroups: comp.sys.apple2
Subject: Re: System programming for the Apple II (preferably the IIe)
Message-ID: <7373@latcs1.oz.au>
Date: 7 Mar 90 02:10:33 GMT
References: <6673@hydra.gatech.EDU> <7368@latcs1.oz.au> <PNAKADA.90Mar6012126@pnakada.oracle.com>
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 48


   Oh dear!  I've been flamed for the misuse of terms!!!  Let's see if we can't
clear this up...

In article <PNAKADA.90Mar6012126@pnakada.oracle.com>, pnakada@oracle.com (Paul Nakada) writes:
> 
> b) There is no such animal as a single process (which I imagine you refer
>    to as single user) UNIX operating system.  UNIX is inherently multi
>    processing, and thus multi user.

   Well, talking about Unix (TM), of course it is multi-user, multi-tasking
etc. etc.  That doesn't mean you can't create a stripped-down version of
Unix which supports single processes.  Naturally, it would no longer function
in quite the same way as Unix does (in particular, you won't have parent and
child processes), but you can certainly have a version that emulates the
shell and passes control along to the program to be executed.  It would simply
become more like CP/M than Unix (TM).

> c) The Apple //e is a computer.  It is not an operating system.
>    Therefore it should not be compared to an operating system.

   I've now been picked up twice for making that comparison.  I'm sorry that
I didn't choose my words with more care.
   Maybe what I should have said is that the Apple //e is not the best computer
to implement a multi-tasking operating system like Unix, simply because it
doesn't provide an interrupt source.  Sure, you can get an interrupt source
by adding the right card, but a standard //e can't do it.  You'd need to
interpret your code, and that's slow.
 
> d) In any case, the Apple //e was not designed with a multi processing
>    operating system in mind, but this does not rule out the
>    implementation of one despite obvious obstacles (of which you point
>    out many)

   OK, so it _could_ be done if someone decided to sit down and work very
patiently through the problems.  But the fact remains, the 6502 isn't a good
processor for the job, and _alot_ of messy, sneaky tricks would be needed to
get it to work.  I wouldn't like to be the one who has to figure out the
best way to implement virtual memory and paging (without exception conditions,
you've got to simulate this in software) and so on.  I'm sorry about this,
but I hate messy code, that's all, which is why I said it in the first place.
   The basic point of the whole article was to say that it would be somewhat
easier to write a single-user version of Unix from scratch, rather than to
try and port bits of the real thing over to the //e.  And if you wanted a
multitasking version, you'd certainly be better off having an interrupt source
from somewhere (so in that case, the original poster of this article might as
well buy himself a clock card or mouse card or whatever, as well as the extra
memory).