Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Desdinova)
Newsgroups: comp.sys.apple2
Subject: Adding an MMU- the whole hullabaloo (long)
Message-ID: <1990Dec19.102300.16062@ux1.cso.uiuc.edu>
Date: 19 Dec 90 10:23:00 GMT
References: <11379.apple.net@pro-angmar> <10663@ucrmath.ucr.edu> <276e74a4.7324@petunia.CalPoly.EDU>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 86

In article <276e74a4.7324@petunia.CalPoly.EDU> rbannon@batman.elee.CalPoly.EDU (Roy Bannon) writes:
>
>Here Here!  Lets get a positive discussion going.  
>
>I am pretty much finished with my DSP card project.  After hacking 
>a DSP card which is able to sample at 47k and has a processor on board
>that is doing 8 Mips, I'm ready for another hardware project.  I think 
>a mmu hack would be perfect.  I am game for a try anyway.  So, what does
>it need, form the software point of view that is.  I remember hearing 
>something to the effect that the abort line to the wdc65c816 doesnt work
>reliablely.  Is this true?  Might make things a bit more complicated if it
>is true.  Initial thought, how bout a daughter board that plugs into the
>65816 socket and has the 65816 and an mmu on it.  Something to think about
>anyway.  

   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
MMU that supports 32 segments.  Something like this wouldn't be too useful,
since at any one time there are MANY MANY (often around 50-100) allocated
blocks of memory.  The '851 is a full demand-paging MMU, and supports up
to 4-level page tables (not necessary for the GS- one level will suffice).
I would choose the '851.
  As for the /ABORT pin, it's true that it doesn't work properly for a few
instructions.  However, at least two of the instructions it doesn't work
for would never generate a page fault (the SEP, REP pair I think), so it
doesn't matter.  If anyone can provide in concrete the other instructions
that don't work, we can check those.  If there ARE instructions that can
cause a fault but don't abort properly, we can just KILL the process.
A small limitation, but one I'm sure we can tolerate.
  With the /ABORT stuff worked out, you can implement full demand paging.
The page device should ideally be a fast hard drive, but Slinky RAM cards
and PC Transporter RAM cards would also make good ones, for a more cost-minded
approach. But it's likely anyone putting out for the MMU board and the 
multitasking software will have a HD.  If not, it's just a limitation,
but not a deadly one.
  Now we have to attack the software that will manage all this.  There are
again two choices: fixing GS/OS, and porting Unix V7 (I picked V7 since it's
what many people consider to be the last reasonable version of Unix, and
also it's what Minix is based on.)  Fixing GS/OS would be an incredibly
useful thing.  Imagine GS/OS never crashing again- NDAs would never again
kill the system.  Instead of purging memory handles, paging them out
(reliably, without the process having to know about it as per the earlier
discussions about swapping purgeable blocks).  Imagine a reliable switcher,
even a MultiFinder.  Imagine your Mac friends being insanely envious of
the incredible capabilities unleashed by such a simple change, one THEY
can't make.  But I digress.
  Porting Unix has its benefits- the wealth of PD software.  But much of
this software is becoming available as Orca/C gets better and better.
Oh, I forgot to mention that with an MMU development becomes a snap-
your program dies, you know instantly where and what went wrong. The only
benefit Unix would have over GS/OS is... well, actually there are none.
GS/OS is an amazing operating system.  Be happy about it.

  Now to hardware constraints.  With the (hopeful) arrival of the ASIC
25MHz processor, people will be upgrading their accelerators to use the
new super-chip.  The MMU must work with both the Transwarp and the Zip GS.
There are two ways to do this.

1)   processor -> cache -> MMU -> motherboard
2)   processor -> MMU -> cache -> motherboard

The second approach is the one most often used by designers these days.
However, it's possible it will be difficult or impossible (due to timing
requirements) to do it that way.  The first method works, but would
require a way to flush the cache, which may not be possible, and besides
would mean heavy performance losses with the large cache sizes the Transwarp
and the Zip GS have.
Fortunately, the '851 is extremely fast, and by virtue that the page tables
would be prime entries in the cache, reasonably performing.  It will require
much cooperation from AE and the Zip people to make this work.
(BTW, putting the MMU in a non-accelerated environment would be cake,
but not nearly as efficient.  But it WOULD work ok, the '851 has a page
table cache).

This has been pretty long, and some of you probably don't know what the hell
I'm saying. What I'm saying is
1) We can have incredible benefits from an MMU
2) It won't be easy, but it is VERY doable.

To do this, I need time (I can get that) and people (this depends on you).

--
Jawaid Bazyar               | Being is Mathematics 
Senior/Computer Engineering | Love is Chemistry
jb10320@uxa.cso.uiuc.edu    | Sex is Physics
   Apple II Forever!        | Babies are engineering