Path: utzoo!attcan!uunet!husc6!uwvax!dogie!terranova
From: terranova@vms.macc.wisc.edu
Newsgroups: comp.sys.apple
Subject: Re: ProDOS vs. DOS 3.3 (was: SOFTSWITCH)
Message-ID: <369@dogie.edu>
Date: 13 Jun 88 21:19:14 GMT
Sender: news@dogie.edu
Organization: University of Wisconsin Academic Computing Center
Lines: 69

In article <299@unocss.UUCP>, tucker@unocss.UUCP (Greg Tucker) writes...
 
>In article 3179 (Re:ProDOS vs. DOS 3.3 (was: SOFTSWITCH)) 366@dogie.edu
>states:
> 
>> Perhaps we don't agree as to what a real OS is.  Let me enumerate:
>> 	- multi-tasking (I guess this rules out most micros)
>> 	- I/O re-direction
>> 	- device independence
>> 	- piping (this can be done without m-t)
>> 	- virtual memory (on a 6502?  yea, right)
>> Anyone care to add to this list?
> 
>Sounds to me like you are looking for a UNIX shell on the Apple.
>No low end micro has added more than one of these features, you expect
>them added on an Apple?  I hate to disappoint you, but...
> 
>> It is interesting to note that I believe all of the above (except
>> virtual memory) can be done on a //e/c.  At one time (I'm talking
> 
>On a crummy little Apple?  Even one program can barely run with only
>128k of memory.  Do you want 2 or 3 programs to?  Besides, bank
>switching pretty well eliminates any hope of running a multitasking
>environment.  What happens when you get an interrupt?
> 

An Apple //e/c have parallel banks of 64K ram.  Two programs which each
fit into one bank can run independent of each other.  They have their
own stack and their own zero-page.  BASIC and ProDOS can be copied
into the auxiliary bank.  You then have, in effect, two 64K computers.

Context-switching can be handled by a small VBL interrupt routine.
The routine can switch contexts every 10-20 ticks to give each process
time to get some work done.

Potential problems that I see:
    1) interrupts - interrupt routines must run in main mem so require
	all processes that need interrupts to run in main.  This means
	 that two of them CANNOT run together.
    2) disk I/O - I believe ProDOS disables interrupts during disk I/O,
	so no fear of context-switching at a bad time.
    3) screen contention - the screen bounds can be convienently set so
	that a program writes to only it's window (eg top half).  With
	two programs one get the top half, the other gets the bottom.
    4) keyboard contention - make a slight modification to the kbrd input
	routine to check for special key combinations to designate which
	half of the screen (which program) gets the input.  (This routine
	would probably have to disable interrupts during execution.)

These problems, really, don't seem to be too terribly difficult to
overcome.  Unless someone can think of more problematic problems, or
have reasons why these are more serious than I think they are, I will
stick by my original claim: multi-tasking can be done on a //e/c!!
** with only two processes **

>-- 
>---------------------------------+---------------------------------------------
> Gregory A. Tucker- Consultant   | Internet: conslt05%zeus.dnet@fergvax.unl.edu 
> Campus Computing                | Bitnet:   CONSLT05@UNOMA1
> University of Nebraska at Omaha | UUCP:     {ihnp4}!unocss!tucker

------------------------+------------------------------------------------
John C. Terranova       |  I'd start a revolution, but I don't have time.
  CS, BS to be		|      --Billy Joel,  "Close to the Boarderline"
------------------------+------------------------------------------------
I speak for myself and all those listed below.  And no one else.
	1)
	2)
	3)