As of V0.72, ASp has the requirement of using the MMU in the 680x0 processor. This coincided with the advent of ASp being capable of emulating a 128K Spectrum. It doesn't require a genius to figure out the two are related!

The Spectrum 128K and subsequent models contained hardware which would switch "banks" or "pages" of RAM or ROM into certain address ranges of the CPU. This is an effective way of expanding the available address range of the Z80, which is normally limited to 64Kb. This action can be emulated in a number of ways, each of which has its advantages and disadvantages.

Perhaps the most obvious method would be to simply copy the data into the required place as and when it is needed. This works, but it is slow. Since the 680x0 has to copy 16Kb of data from one place to another each time, and there is often a requirement to do so several hundred times per second, the 680x0 would need to copy a few Megabytes of data around every second, as well as emulating the Spectrum! Not too useful.

Another method is more clever. The emulator can maintain a set of pointers or indexes to the Spectrum RAM pages in the Amiga memory. For each memory access (read or write) the address pattern can be analysed to find a reference to one of those pointers. This allows the 680x0 to index into a "base address" of a given page without having to copy the contents. This would work well, except this action must be performed for every emulated access. Every Z80 instruction fetch cycle, every Z80 data fetch, every data write, every access to the stack... It probably isn't as slow as the copy method, but is nonetheless a severe speed penatly.

Conveniently, many 680x0 series CPU's contain an MMU. One of the many things an MMU can do is to perform what amounts to the above method in hardware. ie: No copying of the pages need occur, but neither does the CPU need to perform the indexing - it's all sorted out transparently and almost instantly by the MMU. Using such a method incurrs no speed penatly and requires minimal adjustment of the emulation core.

OK, so a good method is to use the MMU. This is not as straightforward as it first appears. Unlike almost every other resource in the Amiga environment, there is no arbitration of the MMU hardware in the OS. There is no system-approved way of "owning" the resources, nor are there any library calls to abstract the usage. In fact, each MMU for each processor type varies both in features and implementation. How should the MMU be coded to ensure compatibility to all systems?

Enter MuLib, Thomas Richter's libraries and tools for doing exactly those things. Almost all useful functions of the MMU can be accessed via easy-to-use library function calls, all the arbitration and control functions are taken care of by the mmu.library. Any program allocating the use of the MMU via MuLib will be guaranteed to co-operate in its usage of the MMU with any other such program. In addition, the library usage remains the same regardless of which CPU or MMU is in use.

There really is no contest. The mmu.library, in my opinion, should be regarded as part of the AmigaOS, accepted and respected in the same way that other 3rd-party products are, such as Cybergraphics or MUI. It has a well-defined and easy API which will allow Amiga programs that need to use the MMU to do so without the compatibility problems and strange interactions which afflict software which doesn't use MuLib. In addition, it is far easier to program mmu.library than the MMU directly. It took a matter of a couple of hours to add the neccessary code to convert ASp from a 48K-only emulation to one capable of the basic paging requirements of 128K.

Thomas offers MuLib as Copyrighted Freeware to the Amiga community. Considering the huge amount of work that has gone into it and the high quality of the software, this is a brilliant gesture. All software which requires access to the MMU, for whatever reason, should use MuLib or be considered non system-compliant!