Hi folks,
yesterday, a major update of MuTools and the mmu.lib appeared in the Aminet, along with additional tools around it. Since the list of updates is so long, it's probably good to give an overview on what happened:
- mmu.library
Except minor bug fixes, the library introduces one new concept, namely that of "Context Windows". This is a set of memory regions whose MMU mapping can be rapidly changed between various pre-defined settings, as to map in hardware quickly or switch between multiple configurations quickly.
- MuManual
Reworked the manual completely. This is more a second edition which was proofread, extended and corrected. Especially, I added the documentation for the ContextWindows, and for the internal interface by which the library talks to "LIBS:mmu" commands and the MMUInit module.
The archive also contains example codes, e.g. that of MuSetCacheMode, or a demo of the context windows, along with all the includes, .fd files and prototypes.
- CPU libraries.
No major changes, except that the interface towards p5emu.library and P5Init was somehow reworked and is much looser now (the CPU libraries are not supposed to know, they are patched by p5init). The advantage of this design is that many (most? all?) P5 graphic cards should now work out of the box without further patching of the CGFx driver. P5 PPC hardware is still in the stage of being unsupported due to lack of documentation.
- MuFastROM:
Support of CD32 ROMs. In particular, MuFastROM can now also mirror the extension area of the ROM.
- MuScan, MuForce:
Support of context windows (see above, a new feature).
- MuProtectModules:
Supports V45 of LoadModule (see below). In addition, MuProtectModules can now also relocate loaded modules into faster 32 bit RAM if necessary. On some boards, modules can only be placed in autoconfiguring slow 16-bit RAM, but MuProtectModules now includes an option to mirror them to 32-bit RAM.
- Installer
Also recognizes now P5 PPC boards correctly now in case their ROM-based CPU libraries have been removed by BPPC fix. This was a last-minute change Harald ("Rotzlöffel") and I found two weeks ago.
Unfortunately, Hyperion reacted too slow for this release, but in the next release, I will be able to include the 3.9 Installer program to avoid the hassle of 3.1 users first requiring this binary for installation of the tools. The "go" came just hours too late.
License conditions for the installer were unacceptable before ("you need a written permission by Commodore Büromaschinen GmbH", yeah - right!)
- MuMapRom:
Reworked again to support additional boards and to enhance compatibility.
- MuFastChip,MuFastZero,MuMove4,MuSetCacheMode,MuRedox,MuGuardianAngel:
No changes necessary, work OOB with the new library due to its stable interface. The only thing I changed was my contact email.
Associated to the MuTools, but not exactly in the package, the following also appeared two days ago:
- LoadModule and Extractmodules:
Completely reworked and extended versios of the tools. The new feature is that "ExtractModules" now recognizes the contents of the modules it extracts, and can name and place them itself. If you call "ExtractModules" without any arguments, it will "spill" the contents of the ROM updates exactly in the right places on your disk (namely, LIBS:, DEVS: and L:) so that LoadModule can pick them up from there.
I didn't even know that the ROM Updates included an exec version for the walker. Well, here you go...
LoadModule became much more intelligent now. In addition to a string of module names, "LoadModule" takes now also a single argument "AUTO" which automatically scans your system for replacement modules and loads them. Thus, "just place the new layers.library into LIBS: and LoadModule will pick it for you". The same goes for the shell, the file system... and everything else ExtractModules found - or is somewhere in the ROM of the system. The modules are also sorted by system, so you can keep several versions of the same module on the disk, for multiple systems.
Hence, you no longer need to know which modules to replace, or edit the startup-sequence for that. Of course, the manual mode continues to work if you want to fine-tune.
In addition, LoadModule can now also replace the exec.library (provided the library has been prepared in the right way, the 3.9 version is). The mechanism for this stunt is a little bit different, but also a lot simpler than that in SetPatch, and also works in case the system placed exec in autoconfiguring memory.
The only library neither SetPatch nor LoadModule is able to replace consistently througout all boards is expansion. Lukely, there is not much about it that requires replacement, hence...
I hope "LoadModule" will gain some importance in the future, and will be able to replace the rather "closed" ROM-Updates mechanism of SetPatch. The functionality offered by LoadModule is much more flexible and open: Whenever you need a ROM module replaced, just put it in its right path (e.g. LIBS: or DEVS:) and the system will pick it up for you automatically. Details - as always - in the documentation.
So long,
Thomas