hamish@waikato.ac.nz (03/15/90)
Putting an MMU into the amiga requires the addition of just one chip, the 68451 MMU. This is the 24/16 bit version of the 68851, and is designed to be used as a peripheral to the 68000, or if you wish to add a 68010, it can be used in much the same manner as the 68020 and later, where the MMU is mapped into CPU space & doesn't take any memory away from the user and is completely transparent. Adding a 68010 has the advantage that virtual memory is possible. So a small board, a PAL and 1 or 2 chips make memory protection possible on all members of the amiga family. Hamish Marson. Disclaimer: This idea is all mine!
alex@bilver.UUCP (Alex Matulich) (03/17/90)
In article <227.25ff6050@waikato.ac.nz> hamish@waikato.ac.nz writes: >Putting an MMU into the amiga requires the addition of just one chip, the >68451 MMU. This is the 24/16 bit version of the 68851, and is designed to The problem with that is that you could no longer multitask well. Communication between processes on the Amiga is accomplished by one process passing a message pointer to another process. Only a pointer is passed, not the entire message. This means that the tasks in question must share the same address space. An MMU would prohibit that. An MMU causes each process to run in its own "aritifically-induced" address space, so a pointer from one process will not point to the same address as the same value of that pointer for another process. -- /// Alex Matulich /// Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 \\\/// alex@bilver.UUCP ...uunet!tarpit!bilver!alex \XX/ From BitNet use: bilver!alex@uunet.uu.net
panon@cheddar.cc.ubc.ca (Paul-Andre Panon) (03/21/90)
In article <532@bilver.UUCP> alex@bilver.UUCP (Alex Matulich) writes: >[blurb about message passing on the amiga] >This means that the tasks in question must share >the same address space. An MMU would prohibit that. An MMU causes each >process to run in its own "aritifically-induced" address space, so a pointer >from one process will not point to the same address as the same value of >that pointer for another process. This is incorrect as far as I know. Now certainly UNIX gives each process its own virtual address space but that certainly isn't necessary for VM. All processes could share the same map for VM->physical memory so that you could still pass pointers. The problem is when you try to implement memory protection that you can break things. For obvious reasons, you could only run VM on FAST RAM, not CHIP (blitter wants this address. Just a second I'll page it in. oops, there goes your screen, Sorry.) > >-- > /// Alex Matulich P-A -- Paul-Andre_Panon@cheddar.cc.ubc.ca or USERPAP1@UBCMTSG or Paul-Andre_Panon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca "What should the role of the University be? It should be to enlighten Society." -Luis Sobrino
charles@hpcvca.CV.HP.COM (Charles Brown) (03/22/90)
> The problem with that is that you could no longer multitask well. > Communication between processes on the Amiga is accomplished by one > process passing a message pointer to another process. Only a pointer > is passed, not the entire message. This means that the tasks in > question must share the same address space. An MMU would prohibit > that. An MMU causes each process to run in its own > "aritifically-induced" address space, so a pointer from one process > will not point to the same address as the same value of that pointer > for another process. > -- > /// Alex Matulich This is not quite true. The process which will pass a message must first allocate the message space from the global pool. This would be a pool of memory which is set aside for all shared memory requirements such as message passing. All memory which was not allocated from the global pool would be protected. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
brianm@sco.COM (Brian Moffet) (03/23/90)
In article <7250@ubc-cs.UUCP> panon@cheddar.cc.ubc.ca (Paul-Andre Panon) writes: >The problem is when you try to implement memory protection >that you can break things. For obvious reasons, you could only run VM on >FAST RAM, not CHIP (blitter wants this address. Just a second I'll page it in. >oops, there goes your screen, Sorry.) Umm, hate to burst your bubble, but memory management does not require virtual memory. On the amiga, memory management without virtual memory would be quite nice. (Of course VM would be nice too :-) Wasn't this discussed to death a few months ago? brian moffet
panon@cheddar.cc.ubc.ca (Paul-Andre Panon) (03/27/90)
In article <5334@scolex.sco.COM> brianm@sco.COM (Brian Moffet) writes: > >In article <7250@ubc-cs.UUCP> panon@cheddar.cc.ubc.ca (Paul-Andre Panon) writes: >>The problem is when you try to implement memory protection >>that you can break things. For obvious reasons, you could only run VM on >>FAST RAM, not CHIP (blitter wants this address. Just a second I'll page it in. >>oops, there goes your screen, Sorry.) > >Umm, hate to burst your bubble, but memory management does not >require virtual memory. On the amiga, memory management without >virtual memory would be quite nice. (Of course VM would be nice too :-) Quite true, but I don't see where I said that. I said you break things with memory protection (having initially talked about message passing, which is where most programs would break - but you edited that out) and then I talked about not using VM for CHIP RAM. I know the difference but, considering I didn't seperate things out, I can see how there could be confusion. > >Wasn't this discussed to death a few months ago? probably -- Paul-Andre_Panon@cheddar.staff.ucs.ubc.ca or USERPAP1@UBCMTSG or Paul-Andre_Panon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca Looking for a .signature? "We've already got one. It is ver-ry ni-sce!"