-----------------------------------------------------------------------------
Contents:
This archive contains the binaries only. No sources or manuals are included
whatsoever. You'll find example code, include files, manuals and more
information in the "MemManual.lha" archive, on Aminet.
-----------------------------------------------------------------------------
Purpose and goal of the memory.library:
The memory.library is the second step stone of the mmu.library project. The
purpose of this library is to provide virtual memory for the AmigaOs
environment. The requirement for making the memory.library working is to
install the mmu.library.
What does the memory.library, and what not?
The memory.library is *not* a system patch in the spirit of VMM or GigaMem.
It will not provide virtual memory automatically to old programs. The AmigaOs
is not prepared to handle this kind of virtual memory due to certain re-
strictions arising from access exception handling. However, "virtual memory
on demand" is possible - that is, programs are able to allocate virtual memory
from this library, and make use of it. These programs need not to care about
how memory is swapped in or out, this is done automatically. The only
additional step that is required to make use of virtual memory is to allocate
it from the memory.library directly rather than from exec, plus some safety
rules how to use this memory. A transparent patch to the system to make
virtual memory available to all applications automatically is *not* possible,
and is neither the intention of the memory.library at all.
The memory.library requires the installation of the mmu.library as it is
build on top of it. You are also encouraged to use the MuLib provided
68040 resp. 68060 libraries as they handle virtual memory more careful than
other implementations. The "SwapTest" program in the Examples directory
should be run to find out whether the cpu support library you're using is
prepared for virtual memory.
About the mmu.library:
The mmu.library is a basis for MMU (memory management) related functions the
MC68K family can perform. Up to now certain hacks are available that program
the MMU themselves (Enforcer,CyberGuard,GuardianAngle,SetCPU,Shapeshifter,
VMM,GigaMem...).
It's therefore not unexpected that these tools conflict with each other.
There's up to now no Os support for the MMU at all - the gap this mmu.library
fills.
The goal is to provide a basis of functions to address and program the MMU in
a hardware independent, Os friendly fashion. Hence, the new version of the
Enforcer, called MuForce, will work together with virtual memory, and others.
The mmu.library is also the basis for this virtual memory project, the
memory.library. Even though the mmu.library does not provide virtual memory
itself, it builds the basics to allow an easy implementation and to avoid the
hacks required by other implementations so far.
Thomas Richter,
February 2002
|
aminet net>