Path: utzoo!attcan!uunet!btni!mcmi!hdr!unocss!tucker
From: tucker@unocss.UUCP (Greg Tucker)
Newsgroups: comp.sys.apple
Subject: Re: ProDOS vs. DOS 3.3 (was: SOFTSWITCH)
Summary: I will grant you that much...
Message-ID: <300@unocss.UUCP>
Date: 14 Jun 88 22:06:15 GMT
References: <369@dogie.edu>
Organization: U. of Nebraska at Omaha
Lines: 56

In comp.sys.apple #3187 [Re: ProDOS vs. DOS (was: SOFTSWITCH)]
John C. Terranova (terranova@vms.macc.wisc.e) wrote:

> 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.

At one time I did think about writing a DOS >< ProDOS switcher, with
ProDOS in the main bank and DOS in the aux bank, using & commands to
switch between the two.  Though I never thought about making it 
multitasking...

> 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.

I don't remember anything like this in my //e reference manual that I read
several years ago.  Could you explain it to me in more detail...

> 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.)

Don't forget the fact that you can only use 40 columns.  The 80 column
screen runs in both banks... 

> 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 **

Given the limitations, 40 x 12 screen, nothing useful could be written.
Of all machines available, why would someone other than a hacker choose
to write this on an apple?

"Amid concrete and clay, and general decay,
 Nature must still find a way..." -The Smiths


-- 
--------------------------------+---------------------------------------------
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