Depending on the avaialble RAM, MuMapRom *might* be worth a try. This said, it is also very much a hack, and yes, if you want to map a 1MB ROM for it, you need plenty of local motherboard RAM the machine does likely not provide.
Right, should not be a problem, I currently have 8MB of fast RAM, but can add up to 64MB iirc.
How do you reset the machine? There are two "must-work" methods, namely the keyboard reset, and exec/ColdReboot(). If one of them does not work, let me know.
Well, I have this habit of typing "reboot", so it is the reboot command from... I think the OS 3.1 Installer floppy, but it also happens with ctrl-a-a. The SX32 Pro is a hack in so many ways (which is why Linux and *BSD never really worked well on it), the CD32 also has a reset button, and who knows what it does
LoadModule will, by default, place its modules in MEMF_KICK memory (except exec, which must potentially go into MEMF_LOCAL). In worst case, modules also need to go to MEMF_LOCAL, or even MEMF_CHIP, even though this *should* not required if the memory is announced correctly. Details would be interesting. If the standard arguments do not work, I can probably compile a version for you that puts the modules into MEMF_CHIP just for testing.
I am happy to do tests. I am going on holidays vacation, but might bring the system with me to tinker with. Ah yes, I had to use the EXECTOCHIP flag, or I would get a yellow screen and rapidly blinking power LED, followed by a reset.
BTW, it is rather important that LoadModule comes into the system before MuFastZero. Once the latter is installed, Execbase may exist "twice": Once in its original position in Chip RAM, and this is the location where it is required for the reset. And once in the mirrored position in fast RAM. The CPU can, once the tool is run, only see the latter mirror. Thus, if you install LoadModule on top of MuFastZero, you only modify the active version of exec, but not the version that comes in play after a reset.
Aha, yes, I understand.
Not only with AUTO, but in general. It is a fairly general limitation of exec. If you place two modules on the resident list, exec will grab the one with the highest version number.
And by "version number" you mean major version number.
There might be a way around this, but in general, there are system limitations like this for a reason. Libraries and devices have dependencies between them, and it is typically not a good idea to insert a lower-release into a system that was compiled for a higher release.
Maybe I was unclear - I am not inserting a lower-release, I am inserting a higher release, but with same major revision. For example, I try to replace trackdisk.device 40.1 with 40.2, but LoadModule protests. I suspect if I just edit the revision inside the binary to say 41.2 it will magically work, but that would be cheating
This doesn't help. It is only later that the code checks the release dates, AUTO only compiles the command line (so to say) for the rest of the code.
OK, that is what I suspected
What I can say, is that the previous version (40.13?) did manage to load all these "minor" upgrades just fine, so it is a bit odd that this new version doesn't.