LoadModule vs LoadResident

[cha05e90]

True enough. I remembered that after I posted. I know *.* works on my Miggy but I think that's only after it's booted, and only because of one of the multi-function commodities I'm running. Memory is a bit hazy, didn't they make some kind of change to that around Workbench 2 or 3?

In the old times there were patches - "official" support for this was introduced with AmigaOS 3.5 if I remember correctly. Though you had to activate this in the Prefs.

[olsen]

I'm trying to figure out something dumb and this is a piece of the puzzle.  What, exactly, is the difference between the LoadResident command and the LoadModule command?

I wrote the original LoadResident command during the preparation which eventually led to the AmigaOS 3.5 update development.

At first it was used in-house at Amiga Technologies GmbH for testing the V43 FFS and scsi.device updates. Heinz Wrobel then built the LoadV43Module command on top of my original code, and the mechanism which loads the AmigaOS 3.5/3.9 ROM update code is descended from it.

This should be pretty much the entire history, and development of LoadResident stopped in around 2003 at version 1.13. As far as I know the source code was never published, and the LoadResident command itself was never intended to be published either. It was useful during OS update testing, but not for much else.

Today's LoadModule was developed separately, by Thomas Richter. Its purpose is similar to what LoadResident could do, but this is where the similarities end.

[guest11527]

What, exactly, is the difference between the LoadResident command and the LoadModule command?

The overall technique how to replace ROM modules is of course identical for both programs, probably with the exception of exec which requires special care. LoadModule also allocates memory for modules in a way that allows write-protecting them later.

Are there certain modules/libraries/etc. that can only be loaded with one or the other?

"exec" can most likely only be loaded with LoadModule, because it does not follow the canonical approach of loading resident modules. "expansion" cannot be loaded by "LoadModule" in any case. LoadResident *may* allow to replace expansion on some machines (those with exec not in autoconfig RAM), but certainly not on all.

Is one more "reset-proof" than the other?

There's probably only a difference in implementation details how the memory is allocated, so I doubt there is much of a practical difference here.

[Pat the Cat]

I think the order it all happen is pretty important, but the logical choice is - alphabetical order. Think of Exec as managing fast food deliveries around a town called Amiga.

First, exec needs to know about any changes to customers and supplier. That's the devices. A device on the Amiga is like a map reference, giving bus size of data (portion size), also things like rate of production, and finally a map of controls. So a device is kind of like an entry in an businessman's card index - it doesn't do anything much on it's own, but it gives the fast food delivery service some kind of idea of how fast the fast food appears, or is needed for consumption. (Devs).

Next, the handlers are like the pizza delivery folks. They actually run around, organizing the scheduling from the different providers and customers. L also includes filesystems, but a filesystem needs hardware to live on, so getting filesystems moduled up first doesn't make sense to me. You need the card list of customers and suppliers (Devs) before the delivery people can start running around carrying fast food from one place to another (the L handlers, filesystems and similar).

Finally, in cases where a customer or fast food provider is very popular, and has a lot of business, a library of common interactions is very helpful. Rather than having lots of different transalators for everyone to talk to each other, you arrange commonly used translators in a big group. You don't need the translators to begin with, they come last. First the pizza has to go from one place to another. It's only on the customers doorstep, or the pizza houses serving counter, that common transactions happen between multiple elements.

It sounds logical to me, but maybe not true in ALL cases. things like maybe 68040.library you want at the beginning, not the end. You want it to happen first. Because that's the processor, a critical system. Kind of like the boss to the universal pizza company, Exec Pizza Deliveries Inc. If the boss gets mad being kept waiting, or is given an order they don't understand like an instruction that is software implemented on that processor, the whole business has a hard time and can't operate properly.

If you go - find out the critical system modules first, then do devs, l, libs. And generally that order. That should work, if I'm thinking straight.

[guest11527]

Is there a list of exactly what it loads

I cannot give one in general, because that depends on your machine. Thus, the answer is "it depends", or to be precise: "whatever is in ROM on your machine". If your ROM includes a "NCR scsi.device", it will try to load one, if not, then not. Tools like "Xoper" or "Scout" will give you a list of resident modules in your ROM, and all those will be looked for by LoadModule AUTO.

and from where?

In short, "in the canonical place". Any library is looked for in LIBS:, any device in "DEVS:", any file system or file handler in "L:". Resources are looked for in "LIBS:resources", the shell in "L:Shell-Seg", and finally, everything else that does not fit into one of the above, in "LIBS:modules".

Thus, should anyone ever replace the boot menu, it would be in "LIBS:modules/bootmenu".

There are a couple of additional tricks you can play, for example provide both a scsi.device for A4000 and A3000 on the same system without collision, but for this time, let's keep it simple.

Alternatively, if I fill up a directory with everything I want loaded, can I just point it at that directory?

Yes, of course. If the directory name is "SYS:ResidentModules", then

Code: [Select]

LoadModule SYS:ResidentModules/#?

will do that for you. Though I must say that I like the idea of "AUTO" better because you drop off the module in the same places a disk-based module would have to be put to.

A lot of the custom modules I load have names like "LIBS:graphics.library_42.8b11-02" and I think the AUTO switch only works with "standard" names (i.e., scsi.device).

That goes in general. The name of the file needs to match the name of the module within it.

[guest11527]

If you go - find out the critical system modules first, then do devs, l, libs. And generally that order. That should work, if I'm thinking straight.

The order in which modules are loaded depends on their priority, which is coded into the module, and - for exec and expansion - also on the system.

The initialization order is "exec", "expansion", "utility", "diag"... up to the strap module. "strap" will (indirectly through a stunt) initialize dos, which will (through another Tripos stunt) start the boot shell, which will then process the startup-sequence.

Some modules just "sit in ROM" and wait to be used, and are not initialized at all during bootstrap, amongst them "audio" and "mathffp". Strangely, due to an oversight likely, "mathieeesingbas" is none of them and is initialized during bootstrap, though it should probably better not.

On some machines, those with exec in autoconfig RAM, the initial bootstrap order is a bit different. It is "a dummy exec" first, followed by "expansion", then followed by "final exec" again, so exec is there initialized twice.

[Pat the Cat]

The order in which modules are loaded depends on their priority, which is coded into the module, and - for exec and expansion - also on the system.

OK. I was trying to find a logical path to do the same thing by hand, giving me the choice of which modules should have more recent versions added.

If AmigaOS doesn't do this, OK. It makes we wonder why there's an AUTO option to LOADMODULE if the inverse, manual, has no effective meaning.

This sounds to me like how 3.5 onwards, ie PPC capable OS, implemented this idea, of being able to use more advanced versions of system files than were supplied with the initial release.

Being PPC friendly might be the real reason for this. I can't for the life of me see why though. That's OK, on a bad day I can't see the end of my nose very clearly.

[guest11527]

OK. I was trying to find a logical path to do the same thing by hand, giving me the choice of which modules should have more recent versions added.

You can certainly manually define which modules you want to replace. AUTO is a "please replace any ROM modules you find on disk" option. AUTO can be combined with manual module selection, BTW. No worries.

It makes we wonder why there's an AUTO option to LOADMODULE if the inverse, manual, has no effective meaning.

Manual allows to select which ROM modules to replace, and which additional (!) modules to place on the list.

Neither manual nor AUTO has any impact on the order in which modules are initialized (or whether they are initialized).  That is really up to the module to decide.

So loadmodule decides which modules to load, and - if manual - where to take them from, and which modules to load, but not the time at which they are initialized. The order on the command line does not have any particular meaning.

[Pat the Cat]

You can certainly manually define which modules you want to replace. AUTO is a "please replace any ROM modules you find on disk" option. AUTO can be combined with manual module selection, BTW. No worries.


Manual allows to select which ROM modules to replace, and which additional (!) modules to place on the list.

Neither manual nor AUTO has any impact on the order in which modules are initialized (or whether they are initialized).  That is really up to the module to decide.

So loadmodule decides which modules to load, and - if manual - where to take them from, and which modules to load, but not the time at which they are initialized. The order on the command line does not have any particular meaning.

I see. Some modules need to be initialized, reset, in order to get a proper start condition. They are kind of "undefined" when LoadModule gets them available.

Some are not like that, but you have to power them up, reset them, in the right order.

That is coded into the module? Hmmm... must make replacement very tricky sometimes.

I guess it does make sense to use "Auto" option rather than wildcards. Not that wildcards are bad, but they will present the options to the command in a pseudo random order with some filesystems. If you have an AUTO option (supposedly) and the real deal is coded into the modules anyway, this can't work. The filesystem plays back the files in a strange way. It's almost certainly going to be the WRONG way, for 3.5 onwards. Unless you hack the module or modules, and that's no guarantee you'll improve matters at all.

[kolla]

@Thomas

If you were to use http://aminet.net/package/util/boot/romboot44_3, how would you load it? I ask because I have tried various ways, along with AUTO, without success.

[guest11527]

If you were to use http://aminet.net/package/util/boot/romboot44_3, how would you load it?

I'm not exactly sure what this is, and whether it creates anything that reessembles a resident module, but if it replaces the bootlogo, then this is done by a module called "strap". The file need to be named "strap", and for "auto", it has to go into LIBS:modules/strap.

However, in the original kickstart, "strap" and "romboot" are somehow intertwined, so it is likely that the result of this patching creates a file that contains two modules, not one, and the first one is "romboot", and only that will then be loaded and become active.

Note that LoadModule will require "binary load" files in the HUNK format, it cannot load binary blobs which are missing relocation information.

Hence, somebody first has to clean up the module and strictly separate out the "strap" part of it, and remove the "romboot" part of it, or rather, create two clean files from one, and in the proper file format, which is HUNK, not raw data.

[Oldsmobile_Mike]

Yes, of course. If the directory name is "SYS:ResidentModules", then

Code: [Select]

LoadModule SYS:ResidentModules/#?
will do that for you. Though I must say that I like the idea of "AUTO" better because you drop off the module in the same places a disk-based module would have to be put to.

Tried this.  Copied all of the modules I currently load via a combination of 'LoadResident' and 'LoadModule' statements into SYS:ResidentModules and added the line "LoadModule SYS:ResidentModules REVERSE NOREBOOT" to my s-s.

Rebooted and got the error "intution.library version 40 already resident", "Loading intution.library failed: object already exists".  I tried it named both "intuition.library" and "intuition.library_40.86b7".

Next I tried deleting that particular library, rebooted again, and this time got the same error, only with card.resource.  Deleted card.resource from my new directory again, rebooted, and this time the error was with trackdisk.device.

Thoughts?  I can't seem to get this to work at all - neither trying to load all of the modules from a single directory or using the AUTO switch.  But doing it "the old fashion way" works just fine.


Edit: still playing around with this.  It seems like some things just will not load with LoadModule, but will with LoadResident.  Hummm...

[Ancalimon]

Which patch is the utility.library ?

[Oldsmobile_Mike]

Which patch is the utility.library ?

It's here:

https://amiga.foul.fr/
utility_41.0(020)(18.10.14).library

Tiny little thing, I don't recall off-hand exactly what the update is for.  But here's what utility.library does, in general:

http://wiki.amigaos.net/wiki/Utility_Library

[guest11527]

Rebooted and got the error "intution.library version 40 already resident", "Loading intution.library failed: object already exists".  I tried it named both "intuition.library" and "intuition.library_40.86b7".

If it is already present, it is already present. Delete intuition.library from LIBS: and off you go. Renaming is, as said, not necessary and does not even help.

Thoughts?  I can't seem to get this to work at all - neither trying to load all of the modules from a single directory or using the AUTO switch.  But doing it "the old fashion way" works just fine.

It's really quite simple. You can only replace a ROM module with a newer version. As simple as it is. You can find the version of a file with

Code: [Select]

version xxxx file full

There is *also* the "DOWNGRADE" option which explicitly allows such downgrades, but in general, I do not recommend doing this. The ROM has no capabilities to distinguish different revisions of libraries and modules.

Edit: still playing around with this.  It seems like some things just will not load with LoadModule, but will with LoadResident.  Hummm...

As always, reading the documentation might have helped. DOWNGRADE is explicitly mentioned there. (-;

[Oldsmobile_Mike]

If it is already present, it is already present. Delete intuition.library from LIBS: and off you go. Renaming is, as said, not necessary and does not even help.

So that I understand correctly, it's still looking in the LIBS: directory (at the old copy there), even though I'm explicitly telling it to load the modules from SYS:/ResidentModules/#?  ?