Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Adding an MMU- the whole hullabaloo (long)
Message-ID: <10736@ucrmath.ucr.edu>
Date: 21 Dec 90 07:13:11 GMT
References: <10663@ucrmath.ucr.edu> <276e74a4.7324@petunia.CalPoly.EDU> <1990Dec19.102300.16062@ux1.cso.uiuc.edu>
Organization: University of California, Riverside
Lines: 18

>>   Hmm. Okay, there are basically two premade MMUs you can use, both are
>>Motorola.  The 68451 and the 68851.  The '451 is a segmentation-based

Actually, Motorola actually makes another MMU for the 6809 which might
work.  I believe the problem with the Abort pin is that certain instructions
are not restartable.  In any case, the abort occurs before one process can
damage another.  If you're willing to give up virtual memory (you want
VM on a GS?  Think about that!), the abort pin should work fine.  If you must
have VM, you're in trouble.  A page fault on REP/SEP can get you into
trouble if the first byte is in one bank and the second in another and you
cannot properly restart the instruction (e.g., suppose it changes M & X
*BERFORE* your abort routine saves their status.  How do you know how to
restore them?)
Certainly a paged MMU is the way to go.  The hybrid paged/segmentation
system on the 386/486 is very powerful.  Having segments (in software) and
paging on a GS would clean up several memory allocation problems.
*** Randy Hyde
.