Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pro-angmar.UUCP!m.tiernan
From: m.tiernan@pro-angmar.UUCP (Michael Tiernan)
Newsgroups: comp.sys.apple
Subject: Multitasking
Message-ID: <8904180445.AA01466@obsolete.UUCP>
Date: 17 Apr 89 19:16:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 75


   Jonathan Chandross et al:
 
       Adding to a message I posted to info-apple (Multitasking thought)
   earlier, I think that for the most part if we were to approach this whole
   thing with the open mindedness that we A) Can do it, and B) That
   effectively, we are going to be writing an entire system that is (for the
   most part) incompatable with what we now use for utilites and
   applications.  The reason that I say this is that while it's being
   developed, unless we do get a piece of hardware that can manage the memory
   usage and access, we are not likely (note, I didn't say won't) going to be
   able to run our AppleWorks and desktop applications.
 
       In his reply to Dave Whitney (dcw@athena.mit.edu), Mr. Chandross
   points out that the BRK instruction will serve as a nifty TRAP
   instruction.  As a matter of fact, I do believe that I once saw a Merlin
   macro called TRAP that helped set up such a psudo instruction.  This is
   true, the use of our new TRAP would work good for directly talking to our
   running system.
 
       Someone else pointed out that "...a multitasking OS is a physical
   impossiblity on the II line. IT CAN'T BE DONE. ..."  As I remember, some
   whiz-bang at Hewlett Packard told one of their employees that you couldn't
   make a profitable micro computer and that they weren't interested in his
   design.  Now what was his name.... Steve something...  Damn, I keep
   forgetting his name...  ;->  And again, Mr. Chandross points out that in
   the dark ages the earliest versions of UNIX ran on 64K machines.  (I was
   running one a number of months ago, I asked the guy I worked with and he
   booted it up for me.) (I'm not sure what version it was but it ran
   [walked] on a 64K PDP-11)
 
       Now, down to the reason that I took pen to paper.... er.. finger to
   key.  I've read the Tannenbaum operating systems and design book and have
   thought about how such a thing could be done.  Now, this is limited in
   it's depth and I haven't even tried to put it on paper yet but, if we
   started one process (the mother hen as it were) and had it be the only
   running process that talks to the operating system, then we could
   implement a request que to it.  It's job would be to handle all calls to
   the operating system and to system resourses that aren't allocated (more
   on allocation later).  It would immediately spawn a second process that
   would (for the time being) be our operator interface, our shell.  I
   realize that we wouldn't have a REAL shell type environment right away,
   but it's a start.  Now, instead of the shell talking to the hardware, it
   ques requests for reads and writes to the request que and then go into a
   wait state.  This would give us our first level of multitasking but we
   also need to implement a scanning process that would be able to trigger a
   context switch on what we've got running and bring another into play.
   This can be done with the heartbeat interrupt from the IIgs clock (or
   another source if not on the gs).  This will give us our second level of
   multitasking, a time-slicing system.
 
       Well, that's my rambling for awhile.  I'm sure that none of it is new
   but I thought I'd at least see if I can get a little more productive
   posting done than the simple retoric in the vain of "Tastes great!" "Less
   filling!".  Let's see what else comes up!
 
       P.S. Mr. Chandross, Re: I know of a stripped down Unix kernal that fit
   in 32K on a Z-80.  User applications ran in the other 32k.  While this is
   a small amount of code, it could run a shell, ed, and other simple
   utilities.
 
       Does it run on the Apple (MicroSoft CP/M)?  If so, I would like to see
   it!
 
   << MCT >>
 
   BCS Apple/Boston Connection     [MCT] (617) 893-5681
   GEnie                           M.Tiernan
   AppleLinkPE                     M Tiernan
   BCS Net                         Michael Tiernan
   obsolete!pro-angmar!m.tiernan@bloom-beacon.mit.edu
   obsolete!pro-angmar!m.tiernan@bu-it.bu.edu
   pro-angmar!m.tiernan@obsolete.uucp
   m.tiernan@pro-angmar.cts.com