Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!usc!petunia!news
From: rbannon@mira.acs.calpoly.edu (Roy Bannon)
Newsgroups: comp.sys.apple2
Subject: Back to the GS MMU hack
Summary: Don't use 68851, roll your own
Keywords: multitasking, mmu, unix gs
Message-ID: <27bef335.4e12@petunia.CalPoly.EDU>
Date: 17 Feb 91 21:18:45 GMT
Organization: Cal Poly State University, SLO
Lines: 56




Hi folks, guess you all figured that I had sorta faded away into the ether.
Not so, just got real busy with classes and my job, (which is where am I know,
so don't tell my boss :-) ).  Anyway, heres my latest thoughts. 


The idea had been to implement a mmu on the GS using a motorola 68851 pmmu 
chip.  I finally got the data book on the thing a couple of weeks ago.  I think
there is a big problem with using it on the gs.  The 68000 series uses address
strobe and dack to get data from memory.  The pmmu takes the as from the 68000
does a lookup and the issues a as to memory with a new address.  The problem I
see is that the 65816 wants to see data on the up edge of the clock.  Even
using the fastest version of the pmmu, it would delay the time when the address
becomes valid til it was too late for the memory to respond in time for the
rising edge.  Also, the glue logic would have to convert all the 65816 signals
to 68000 like signals and the convert the 68000 back to 65816. This is because
the pmmu stores most of its translation tables in RAM.  So when it tries to 
look up an address that isn't in its cache, it finds it in RAM itself by 
becoming bus master.  This would drive the cost of this thing way up.

Secondly most of the pmmu features relate to address translations for virtual
memory.  This means we wouldn't be using all the features of the chip we 
bought.

So, As I see it, what we need is a more simple implementation of memory 
protection.

So, here goes.

Break the memory up into 256 byte pages (the pmmu does this too).  Then 
make put 64k x 8 of static ram on the new daughter board.  This will hold
an eight bit code for each page.  When the 65816 asserts an address, the
ram will give the current code of that page.  A state machine will check
that code against the type of cycle.  For example maybe 1 bit for whether
the page is writeable, and 7 bits for who owns it.  Or depending on the cost
of the ram, make it 64k x 16 bits and encode more stuff.  I would like to 
hear from all of you out there about this.  The state machine would then keep
track of which process was currently runing and check its access rights 
against the code.  Since the machine isn't doing any address translation,
the address can be presented to main memory as usual.  If the state machine
determines a page fault, it will assert abort for one clock cycle so that
the data coming back from RAM will be ignored.  This 64kx8 could be mapped
into the highest ram bank ($7F) and accessible only by the memory manager.
A couple of control locations need to be mapped somewhere else (like bank
$80) so that you can tell the state machine to switch process and maybe some
other locations so when a page fault occurs you can tell why.

This should cost a lot less than using the 68851 pmmu, with the drawback of
virtual memory support.  Anyway, lets here the flames people.

Now that that's done, we can get back tothe Mac Lc vs GS comparison (oh boy!).

Roy
rbannon@cosmos.acs.calpoly.edu