Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!petunia!news
From: rbannon@batman.elee.CalPoly.EDU (Roy Bannon)
Newsgroups: comp.sys.apple2
Subject: MMu on the IIgs
Message-ID: <278d0eda.563e@petunia.CalPoly.EDU>
Date: 11 Jan 91 01:03:22 GMT
Reply-To: rbannon@batman.elee.CalPoly.EDU (Roy Bannon)
Organization: Electronic and Electrical Engineering, Cal Poly San Luis Obispo
Lines: 44


Newsgroups: comp.sys.apple2
Subject: MMU Project
Summary: more thoughts on the IIgs MMU program 
Expires: 
Sender: 
Followup-To: 
Distribution: world
Organization: Cal Poly State University, SLO
Keywords: MMU, multitasking GS

Hi folks,

Okay, after thinking about this some more and actually requesting data
books for the 68851 and some samples, I got some more questions for you
software jocks out there.  I've looked at the 65816 data sheet and the
app notes.  Don't see an immediate problem with them. The read-modify-
write instructions must be aborted before the modify cycle, no problem.
Abort can only be a cycle long in order to prevent the abort being 
aborted.

Now my questions, The 68xxx has supervisor mode.  How should we fake 
this on the gs.  The gs would have to be in supervisor mode before
it could modify the MMU.  Some of my thoughts are haveing a memory
address which when accessed would switch it to supervisor mode.
A second thought is to use a COP $XX instruction which would trigger
an abort and put the GS into pseudo supervisor mode. $XX is probably
a unique value so things like byteworks shell can still use the rest.

This scheme would mean that when a system call was made, the first thing
to do would be to execute a cop instruction to set the GS into supervisor
mode so that the o/s had supervisor priority.  

As soon as I get the parts, I'm going to use my old 65816 (replace by the
TWGS) on a proto board in the lab to check all this out.  My thought
now is that basic memory protection would be the first reasonable goal.
virtual memory is a ways down the road.  

Remember, some of you software jocks out there expressed a desire to patch
the os and/or the tools to take advantage of this hardware if I get it 
working, so I'm going to hold you to that :-).

Roy
rbannon@cosmos.acs.calpoly.edu