Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!wuarchive!zaphod.mps.ohio-state.edu!usc!petunia!news
From: rbannon@mira.acs.calpoly.edu (Roy Bannon)
Newsgroups: comp.sys.apple2
Subject: Re: Back to the GS MMU hack
Keywords: multitasking, mmu, unix gs
Message-ID: <27c00f84.4155@petunia.CalPoly.EDU>
Date: 18 Feb 91 17:31:48 GMT
References: <27bef335.4e12@petunia.CalPoly.EDU> <1991Feb18.045719.22698@ux1.cso.uiuc.edu>
Organization: Cal Poly State University, SLO
Lines: 43



>   This basically looks good, except that I would recommend a 32Kx16 setup.
>That allows for 8 megabytes of memory under 'protection'. Plus- and this
>is important- it would allow assigning an entire Memory Manager UserID
>per 256 bytes.  If we assume that a process has the right to do whatever,
>whenever to its memory, then we don't need an access flag (it's implied).
>Your new plan also has another benefit, being that the modifications to 
>the Toolbox/GSOS would be minimal, almost trivial.  It simplifies things
>such as programs going straight to screen memory, etc.
>   I just looked at my Toolbox ref, and actually only 11 bits of a UserID
>are necessary to unambiguously identify a process under GS/OS, so that leaves
>you 5 bits for whatever.
>   About how to handle page faults- in the case of a fault, writes must
>be prevented from happening.  Checking the hardware ref, we have 'round
>250 ns to detect a fault and make sure R/W stays high (i.e. make sure
>write is turned off). 
>
>>This should cost a lot less than using the 68851 pmmu, with the drawback of
>>virtual memory support.  Anyway, lets here the flames people.
>   True- I'm pushing for VM support because it would in the future allow
>for pre-emptive multitasking and clean up the '816s architecture software-
>wise (e.g. have as much stack space as needed).
> 
>--
>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)

Why would my implementation not allow for pre-emptive multi-tasking? 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.

Roy
rbannon@cosmos.acs.calpoly.edu