Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: System programming for the Apple II (preferably the IIe)
Message-ID: <1990Mar6.215758.11521@spectre.ccsf.caltech.edu>
Date: 6 Mar 90 21:57:58 GMT
References: <6673@hydra.gatech.EDU> <7368@latcs1.oz.au>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 72

stephens@latcs1.oz.au (Philip J Stephens) writes:

>   First of all, remember that Unix is multitasking, whereas the Apple IIe is
>not!

Multitasking is provided BY unix. It is a pain to do without continuous
interrupts, to be sure, but that is easy to provide. GEOS provides such a
card when you buy the first package. Any Mockingboard or Mouse Card can be
made to fire regularly timed interrupts which are essential for true pre-
emptive multitasking.

> You'd have to modify the C sources quite drastically to get a single
>user version capable of running on an Apple.  Either that, or get your hands
>on one that isn't multitasking.

I'd modify the sources period. There are lots of things about unix that we
don't need. A version of the kernel that uses an interrupt source to provide
multitasking shouldn't be that hard to do. Writing a decent C compiler for the
Apple might be, but I maintain that it is not impossible, just time consuming.
Compilers for the 68K stunk until Motorola poured lots of research into them.
The same goes for the 80x86 or any CPU at all. 65xxx compilers simply haven't
had the development man-hours that compilers for other CPUs have had.

>   The same problems exist for implementing the virtual memory system, paging
>faults, disk I/O handling etc.

Virtual memory would be a problem ONLY if you expect the compiler to be totally
stupid. Boundary checking code could be added to compiled programs (as a debug
option maybe) OR you could organize the data structures around the zero page
indirect addressing scheme: (gasp) segment them. The main reason C compilers
on the Apple stink is because they try to imitate a 68K which is IMHO neither
necessary nor desirable. C itself looks like a 68K, but if you read the specs
about pointers then it becomes obvious that the actual memory organization of
the data is entirely the compiler's prerogative. Nobody seems to understand or
exploit this.

> Basically, what I'm trying to get at is you
>can't port over a standard version of Unix from a Pyramid, Mips or Vax.

I'll bet it could be done. Not to a bare //e, but to one with an interrupt
source and decent C compiler.

>   Someone has already mentioned the security aspects as well, which relates
>back to what ought to happen when a program crashes.  Unix expects to regain
>control in situations like this, but on an Apple that is not always possible!

This is more the programmer's fault than anything else. The nice thing about
hardware protection is that it gives you a safety net. The Mac and the Apple
as of yet do not implement such safety nets so we must be more careful.

>Put simply, the 6502 (and the Apple in general) couldn't cope with anything
>but a diluted version of Unix; and in that case, you'd be better off re-writing
>the C sources yourself!

Currently, yes, but I still say that it is a software problem. The Amiga runs
a version of unix without virtual memory.

In unix's case I think you'd still be better off re-writing the sources. unix
is not optimized for microcomputers, and an O/S as simple as unix but optimized
for micros would be really nice.

>   Actually, writing a single user version of Unix from "scratch" wouldn't be
>that bad; if you're into that sort of thing...I would think that a basic
>version wouldn't be any more complex than DOS or ProDOS.  I wouldn't mind
>attempting it if I had the time ;-)

Neither would most of us, we don't have the time either... I had some excellent
ideas on how to write a great O/S for the Apple last year but found that my
homework was more insistent on my time. :(

Todd Whitesel
toddpw @ tybalt.caltech.edu