Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!necntc!ames!ucbcad!UCBVAX.BERKELEY.EDU!schoet
From: schoet@UCBVAX.BERKELEY.EDU (Steve Schoettler)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga2000 Expansion, or Should there be an MMU?
Message-ID: <8703100418.AA25578@ucbvax.Berkeley.EDU>
Date: Mon, 9-Mar-87 23:18:53 EST
Article-I.D.: ucbvax.8703100418.AA25578
Posted: Mon Mar  9 23:18:53 1987
Date-Received: Tue, 10-Mar-87 20:10:57 EST
Sender: schoet@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 55

Paraphrasing Perry Kivolowit:
> What if third party vendors were to put am MMU on a CPU board?

This raises a few concerns for me:

1.We need to have a standard way to use it: Exec library routines
  (or maybe even a seperate MMU.library?) to find out if an MMU exists
  and to set/read its registers.
  You don't want the library routines to be chip specific, so simply
  returning a pointer to a memory-mapped chip location is not sufficient,
  as register locations would depend on the chip type.

  Don't forget the ability to override and restore registers concerning
  system memory space.  A program that knows what it is doing should be 
  able to modify Execbase or Library vectors, etc., and then restore
  protections.  Obviously the machine could die if the program went
  haywire here, so a bombproof method wouldn't allow user programs to 
  modify MMU registers at all.  A more correct way to modify system
  structures would be to only allow the MMU registers to be modified 
  when in supervisor state and provide routines to move a byte or block 
  into system memory.  This isn't bombproof, either, as any program has to 
  have the ability to call the routines, but this method should allow such
  programs to be easily debugged. Anybody have a "more" bombproof method?

  I feel Commodore should be the one to establish the calling procedure
  for these routines.  Third party hardware vendors who provide MMU's
  in their products can create or replace library vectors with their own
  routines during the autoconfigure process.

2.We all should realize that simply adding an MMU would not save the
  system completely after the crash of a program that left signal bits
  allocated or left a device or library open.  A complete rewrite of
  Exec would be required, and I doubt that CBM or third parties are 
  interested in this.  We might, however, have a hope of doing it right
  with MINIX.

3.How many Kickstart routines need to be modified?    When 
  AddTask() needs memory, for example, does it call AllocMem() through
  the library interface or just use a relative or absolute branch?
  In other words, would replacing AllocMem and Freemem fix everything,
  or are there other ways programs can get memory?
  [Actually, AllocMem seems to be in the lower DOS Library memory, in
  which case calling the routine is probably done correctly and
  consistently from Kickstart.]


In answer to your question, Perry, I think that if the above criteria
are realized or accomplished, you would see interest from many people
(myself included) in rewriting the AllocMem and Free routines.
It's not as simple as it seems, but I say go for it!

 Steve Schoettler
 ucbvax!schoet

 Nobody is responsible for me.