Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!sdd.hp.com!caen!uwm.edu!ux1.cso.uiuc.edu!chip!bazyar
From: bazyar@chip (Jawaid Bazyar)
Newsgroups: comp.sys.apple2
Subject: Re: Back to the GS MMU hack
Keywords: multitasking, mmu, unix gs
Message-ID: <1991Feb18.211848.19824@ux1.cso.uiuc.edu>
Date: 18 Feb 91 21:18:48 GMT
References: <27bef335.4e12@petunia.CalPoly.EDU> <1991Feb18.045719.22698@ux1.cso.uiuc.edu> <27c00f84.4155@petunia.CalPoly.EDU>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: bazyar@cs.uiuc.edu (Jawaid Bazyar)
Organization: Mutation Testing Facility, University of Illinois
Lines: 33

In article <27c00f84.4155@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes:
>
>Why would my implementation not allow for pre-emptive multi-tasking?
  Well, I exaggerated the case. Modifying the tools for multitasking would
be a lot cleaner with an MMU.

> You would
>have only as much memory as you got, but it keeps processes from stomping on 
>each other.  If we add a feature that also monitiors opcodes and aborts
>stuff that changes the global processor status, I think it should work.  What
>does VM have to do with pre-emptive multitasking?  Oh well, I'm personally 
>going for the custom hack still as opposed to the 68851, for the reason that
>my scheme could still  work with accelerators.  I just did some quick calcs
>and 15 MHz support should be OK.  I think the people that would be really 
>interested in buying this are the same people who already have accelarators
>andprobably don't want to give up their accelerators for an mmu hack.

  One thing that was mentioned by another (as well as myself), is a
concern about keeping invalid writes from occurring.  Contrary to what
I said above, I've not convinced it would work.  You can prevent a write,
but in the event of a valid access, can you turn it back on again
in time for the RAM chip to respond properly?
  And you're right, your scheme is definitely more attractive for 
use with accelerators.  
  If you're gung ho about this, send me mail and we can start working
out details of implementation (including what to do with tool sets,
and checking out the write signal thing).

--
Jawaid Bazyar               |"I'm sure K&R have never heard of Mike." 
Senior/Computer Engineering |
bazyar@cs.uiuc.edu          |"That's okay. I'm sure Mike's never heard of K&R".
   Apple II Forever!        |  (discussion about Orca/C)