Cheers

Similarities:

The 060 lib core is of course always based on the Motorola FPSP and ISP code that had been made available by Motorola. Several authors including optimizations to this code (not always improving the stability).

All versions patch in a new exec scheduler because the FPU stack frame is different - and this stack frame must be taken care of on task switches.

All versions patch in a couple of replacement functions in exec to work around software bugs, i.e. software not flushing caches correctly, for example Supervisor() is patched to detect the early Aztec C startup code that resets the FPU, but is (of course) not aware of the changed FPU stack frame of the 060.

Differences:

The P5 lib not only patches the FPSP and ISP code, it also intializes the MMU and preps the P5 hardware, it also reserves the topmost pages for patches, and reserves some memory blocks for non-autodetecting P5 hardware.

My version does not touch the MMU, but rather relies on the mmu.lib to do that instead. Proprietary hardware is not initialized (P5Init in the MMU-Configuration keeps care of that to some degree), it neither reserves the topmost page (MuRedox does that via the mmu.library).

Further differences are in the API. The P5 lib does have a API, but Ralphy never got around documenting it - it is used internally by some of the P5 devices, but I'm not sure about it what the calls do, and I never tried to find out. The Mu-based version also does have a (documented, though) API that allows you to change the exception handling.

Minor details in the patched functions, latest Mu versions patch also the utility library (by request), GetMsg() (loop to short for disable/enable) and parts of the interrupt handling (again, Paula is too slow).

The Mu versions provide the fpsp.resource, which is again used by the mathieee libraries (3.9 and up) to impove the speed for otherwise software-emulated functions (calls go directly into the fpsp instead of taking a round-trip with the emulation).

Probably some minor differences in trace or trap handling, helpful for debugging.

Probably some differences in the 060 models it supports. The Mu version includes support for the EC versions as well (though never really tested it).

Probably some differences in the 060 setup. The Mu versions try to find the chip revision, and disables the buggy load-store-buffer bypass on the early 1F43G release. This makes code a tiny little bit slower, but instead addresses a majority of the 060 bugs.

MMU handling: In my opinion, not a 060 library issue (you know why), but here are a couple of differences:

DMA handling: Unaligned DMA accesses require MMU table changes due to the way how the Amiga bus system works. An old discussion between Mike Sinz and Ralph Babel was how the system should react if the MMU tables are replaced under its feed. Mike's 040 lib (there is no 060) patches even replaced/hooked in tables - required for the enforcer to work. Ralph's lib only gets hands on its own tables. The same goes for the Mu-library DMA handling (Ralph is usually right, so I'm with him). DMA handling and Mu is a tricky business anyhow, different story. I don't know how the P5 libs behaive here, but P5 devices did not use the Os to indicate DMA in first place and thus weren't compatible to anything but their own lib (closed source - no luck).

In short, while I can certainly tell you want my lib does, I'm not quite sure to Ralphies (Schmidt, not Babel).

So let's see, here's the list of patches:

CacheControl (060 cache control, obviously)
CacheClearE (CacheClearU doesn't require patching and jumps in here anyhow)
ColdReboot (flushing caches before pulling the trigger)

AddLibrary
CloseLibrary
AddDevice
AddResource
AddTask
AddIntServer
SetIntVector (all workarounds for software forgetting to flush caches)
GetMsg (see below, disable/enable PAULA reaction is too slow)
ExitIntr (Paula too slow, again)
BeginIO (of the input-device) -> some programs add input handlers without flushing caches first, using self-modifying code (urgh!)

SMult64
UMult64
UMult32
SDivMod32
UDivMod32 (64 bit math, improved 060 math)

Supervisor, and the exec scheduler, as discussed.

The 060 lib also removes and shuts down any instance of the mathieeesingbas.library it finds. Required because the FPU is not detected at rom boot time, and thus this rom based version does not use the FPU, even if there is one. The next OpenLibrary of the lib will then pull the right (FPU-enabled) version from ROM.

AddConfigDev: While not patched, I considered patching this and generating an alert. The problem here is that AddConfigDev() *after* setting up the MMU still doesn't make the hardware visible because the MMU redirects the accesses to blank pages (or generates a MuForce hit, if installed). Thus, it won't work. AddConfigDev() should, however, only be used during early rom bootstrap anyhow, thus no matter.

Greetings,
Thomas