Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!petunia!news
From: rbannon@mira.acs.calpoly.edu (Roy Bannon)
Newsgroups: comp.sys.apple2
Subject: MMu on the GS
Summary: Memory maped MMu
Keywords: Multitasking, MMU, memory-mapped
Message-ID: <278e8271.b58@petunia.CalPoly.EDU>
Date: 12 Jan 91 03:28:49 GMT
Organization: Cal Poly State University, SLO
Lines: 57



Instead of include the response to my previous post, I'll just summerize.

The idea put forth by the software have of this design consortium was to
use a memory mapped interface to the MMu.

On a side note, we could communicate directly by email, but I would hope
that by sending mail we could get some more people involved in this.  If
you're reading this right now and saying, what the heck is all this about
anyway, ask a question.  IMHO, this is the point of the internet is for all
of us to get together and learn something.  So don't be afriad to ask, or
even better to offer suggestions, critisizims or whatever.

Back to the point at hand (and you thought I'd forgotten :-)  )

Here's what I think a memory mapped scenario would be like.

1) System loader, which has all access, load a new process and the memory 
manager gives it an Id.  Call in proc A.  The patch to the System loader
then tells the MMu that proc A is about to be in control.

2) Proc A runs merrily along until it needs to make a system call.  It makes
the jmp (or jsr or whatever).  The machine tries to execute fetch from the
system call entry point.  At this point the MMu should abort the instruction 
cause proc a has no business at a system call entry point.  However the
abort vector isr checks the address of the bad fetch and determines that
its the tool call, so it resets the currently process to system level and
then lets the instruction restart.  At the end of the tool routine, the rtl
will not cause a page-fault, because they are at system level, so how does
the mmu know that that proc A is back in control?

3)  My second thought is about interrupts.  My thought now is when an interrupt
occurs to automattically set the level to highest.  If it went through the same
search as in 2 above, the latency befor the isr was executed would be long.
Since this would be tied to the hardware int line, brk or cop wouldn't have an 
effect.  

Anyway, I not completely convinced that a cop #XX where XX is also checked 
would be bad.  For example if we used on of the sigs that Western Design
has reserved (we know they will never use them) it would not confilct with
all the other people using cop.

So, lets here from all of you out there.

Oh yea, if this engineering curiosity is going to be a product someday, I would
like to know how many of you out there might be interested in buying such a 
thing.  It would allow some pretty neat stuff that just can't be done now.

Just send me some email.  Saying, yea, if it cost less than x.  Try to be 
reasonable about what you would pay. The good mmu chips ain't exactly cheep
themselves.  

Thanks for listening to me ramble.

Roy
rbannon@cosmos.acs.calpoly.edu