LoadModule vs LoadResident

[kolla]

Another thread resurrection...

@Thomas
The LoadModule readme shows a few examples, one of them being...

Code: [Select]

LoadModule LIBS:icon.library LIBS:workbench.library +
  DEVS:console.device L:Ram-Handler L:FastFileSystem +
  reverse noreboot
(http://aminet.net/package/util/boot/LoadModule)

Is that meant to be taken literally? Because I never got LoadModule to work with "+" like that - I wish though, sometimes the LoadModule line can become really long. Is there any practical difference between using multiple LoadModule lines with "NOREBOOT" and using one LoadModule line that has everything?

Cheers!

[guest11527]

A
Is that meant to be taken literally?

Probably not, no, sorry. The way how "+" interacts with the shell is not obvious, and it is in particular not the way how you would expect it to work. Unlike what one might think, the shell does not continue reading stdin (or, rather CIS) once it hits a + sign as last character on the line. That this works with "run" seems to be more a coincidence than a matter of design, as "run" doesn't do any parsing at all, just starts a new process, but leaves the input (as with all other commands) in stdin, so they pick the additional characters then up. Unfortunately, ReadArgs() does not.

So, it is really not a matter of LoadModule() at all, and it is not fixable there. The problem goes for all shell commands, with the exception of Run. Call it "Tripos". Driving on the wrong side of the road was probably too much the design paradigm there...

[SpeedGeek]

Another thread resurrection...

@Thomas
The LoadModule readme shows a few examples, one of them being...

Code: [Select]

LoadModule LIBS:icon.library LIBS:workbench.library         +
       DEVS:console.device L:Ram-Handler L:FastFileSystem     +
       reverse noreboot
(http://aminet.net/package/util/boot/LoadModule)

Is that meant to be taken literally? Because I never got LoadModule to work with "+" like that - I wish though, sometimes the LoadModule line can become really long. Is there any practical difference between using multiple LoadModule lines with "NOREBOOT" and using one LoadModule line that has everything?

Cheers!

It looks like you are just another victim of the unknown (or undocumented) special "Feature" of the Amiga Shell! :laughing:

I ran into the same problem with 2 patches I released on EAB last year:
- FastCache040+
- RomCache040+

Notice the coincidence? ... the "+" character is interpreted by the Shell not as part of the command or file name but rather as the next part of the command or file name to be combined together. The problem is you have only empty space (nulls) for the combination! :p

The "+" character will mess up script execution as well as the version command and it makes no difference if there is a space (null) before or after the character. The simple solution here is:

Get rid of the "+" character!

[Oldsmobile_Mike]

sometimes the LoadModule line can become really long.

FWIW, that's why I switched to using AUTO + a custom directory that I dumped all the modules in that LoadModule couldn't find automatically.  No functional difference, just appeased my OCD to not have a miles-long line of LoadModule stuff.  

[psxphill]

FWIW, that's why I switched to using AUTO + a custom directory that I dumped all the modules in that LoadModule couldn't find automatically.  No functional difference, just appeased my OCD to not have a miles-long line of LoadModule stuff.  

What about your OCD of not easily knowing what LoadModule was loading???

[Oldsmobile_Mike]

What about your OCD of not easily knowing what LoadModule was loading???

Hey now.  It took me a while to figure it out, but I do know exactly what it's loading.  See attached screenshot.  

Although in a perfect world I think more comprehensive information like this would be helpful:

ModuleName $name1 loaded from $location1
ModuleName $name2 loaded from $location2
Etc.

[kolla]

Well, "AUTO" does not pick up all the (third party) modules I need and want, and it also happens that AUTO does more than what you actually want. Even when I build custom kickstarts containing _all_ OS3.9 rom modules and more, I still may want Poseidon modules and other stuff loaded resident

A funny work-around I typically resort to, is to have a file (S:LoadModules) containing the paths of all the modules, make sure there is a T: assign, and then do...

Code: [Select]

LoadModule REVERSE `type S:LoadModules`(T: is needed for back-ticking, sigh)

I wish LoadModule could have a built in support for such a config file. The AUTO-magic may be fine for "most users", but it can also be a painful obstacle when the system is anything out of the "ordinary". I appear to have many such systems (CD32/SX32Pro, Vampire on CDTV, Vampire A600 + Subway, A3000 CSPPC + Deneb ...) To be honest, I personally find it rather messy how AUTO works, by guessing Amiga model and traversing all the possible paths in LIBS: and DEVS: etc. And sometimes LoadModule makes wrong conclusion about which Amiga model it is running on, hence loading wrong modules.

Funny example that I reported to ThoR earlier - my "worst case scenario", the CD32/SX32Pro. Due to bad hardware design, it cannot hold ROM modules resident in FastRAM, and hence LoadModule loads them to ChipRAM. LoadModule AUTO loads all possible updates based on what's in the kickstart of the CD32 (40.60 iirc), which also includes Workbench.library and Icon.library. On the same system, LoadModule AUTO also somehow decides to load modules from A1200 directories rather than CD32 directories. So woop woop, I get wrong modules (the CD drive vanishes), and half of the chip RAM is gone! (most of it to workbench.library and icon.library)  Current work-arounds are removing all the non-relevant directories (A500, A600, A1200, CDTV, Walker etc - I have exactly _zero_ use for them!), move all modules in CD32 directories one level up (DEVS: instead of DEVS:CD32 etc) so that LoadModule AUTO finds the correct modules... then store workbench.library and icon.library in LIBS:Workbench rather than directly under LIBS: so that LoadModule AUTO does _not_ load them to chip RAM, and then add that directory to LIBS: assign before Setpatch, so that Setpatch will find them and do the update in Fast RAM instead. Phew! imagine if there was a clockport on that system too, to which I no doubt would have added a Subway or Broadway, for USB keyboard and mouse, and ethernet... more modules to add

[guest11527]

I wish LoadModule could have a built in support for such a config file. The AUTO-magic may be fine for "most users", but it can also be a painful obstacle when the system is anything out of the "ordinary".

If you have a system that is misconfigured, it is your job to keep it running. Nothing is for free in this universe, and with you modifying the system comes responsibility. The design is "make it simple for those that have a standard system". Not "make it hard for everyone". That would be the Linux way of doing it...

To be honest, I personally find it rather messy how AUTO works, by guessing Amiga model and traversing all the possible paths in LIBS: and DEVS: etc.

There is no guesswork involved. It is really just the modules on the ROM module list. As simple as it is.

And sometimes LoadModule makes wrong conclusion about which Amiga model it is running on, hence loading wrong modules.

Its using the same algorithm as setpatch for 3.9 does. In particular, it requires that the machine is equipped with the ROM came with. The CD32 is identified by the presence of the cdui.library. If that library is present, it uses the CD32. If not, the machine looks like an A1200. It never loads modules for two *distinct* machines (that would be a nice trick with the algorithm it uses), so I would say, that's all your responsibility. I'm not excluding a bug here, but it's really a pretty simple algorithm.

That it does not use fast Ram is just a matter of the fast RAM not using autoconfig properly, so it is not there after a reset where it should have been. Not fixable by software.

[kolla]

If you have a system that is misconfigured, it is your job to keep it running.

Oh, so I misconfigured the CD32 when I added the SX32 Pro, is that it? Or maybe the CyberStorm, or the USB controllers, or what? Exactly how are my systems "misconfigured"?

Your comparison with Linux is nonsense, at least with Linux, nothing and noone stands in the way of me doing my job of maintaining my systems - with Amiga on the other hand, one needs to please developers and and be careful to not rub them against their hair, or you don't get anywhere. Please feel free to send me the sources of LoadModule and I can look for the bug myself.

Its using the same algorithm as setpatch for 3.9 does. In particular, it requires that the machine is equipped with the ROM came with. The CD32 is identified by the presence of the cdui.library. If that library is present, it uses the CD32. If not, the machine looks like an A1200.

You did not see the email I sent you?

http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1437

LoadModule checks for cdui.library, finds it, and then decides it must be an A1200. Whatever OS3.9 does by default, I am quite sure it is equally broken.

[liosliante]

If you have a system that is misconfigured, it is your job to keep it running. Nothing is for free in this universe, and with you modifying the system comes responsibility. The design is "make it simple for those that have a standard system". Not "make it hard for everyone". That would be the Linux way of doing it...


There is no guesswork involved. It is really just the modules on the ROM module list. As simple as it is.


Its using the same algorithm as setpatch for 3.9 does. In particular, it requires that the machine is equipped with the ROM came with. The CD32 is identified by the presence of the cdui.library. If that library is present, it uses the CD32. If not, the machine looks like an A1200. It never loads modules for two *distinct* machines (that would be a nice trick with the algorithm it uses), so I would say, that's all your responsibility. I'm not excluding a bug here, but it's really a pretty simple algorithm.

That it does not use fast Ram is just a matter of the fast RAM not using autoconfig properly, so it is not there after a reset where it should have been. Not fixable by software.

Thank you for your help Thomas, now I can understand how it works the command. I was really having problems in the past with the command, but now I can be able to use it correctly!! You are my hero!!

[Oldsmobile_Mike]

You did not see the email I sent you?

http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1437

LoadModule checks for cdui.library, finds it, and then decides it must be an A1200. Whatever OS3.9 does by default, I am quite sure it is equally broken.

I'm sure you know this but it looks like this has been addressed in the latest release (just noticed it on Aminet this morning).

http://aminet.net/package/util/boot/LoadModule

LoadModule 45.14:  This release includes a new switch, ROMUPDATE, which works like AUTO, except that it only grabs pure modules (i.e. modules whose 'p' bit is set). This might help to housekeeping and exclude some unwanted modules. ExtractModule has been updated to set this bit as well, and allows now to use the "TO" keyword also to specify a target directory for individual files, making everyone's life a bit easier. The check for the CD32 of LoadModule apparently did not consider the extended ROM area of this device, hence failed to identify this model correctly. Sorry about that.

[kolla]

I'm sure you know this but it looks like this has been addressed in the latest release (just noticed it on Aminet this morning).

http://aminet.net/package/util/boot/LoadModule

Nope, I've heard nothing, in fact I was just about to rig up the CD32/TF328 just to verify that this bug is... was... present not just with SX32 Pro. And a wonderful new flag for "pure" moduls - no need to keep Workbench.library and Icon.library in a separate directory!
Woop woop!

Cheers, Thomas! And thanks for heads-up Mike

[guest11527]

Cheers, Thomas! And thanks for heads-up Mike

You are welcome. Whenever I find the time, I'll update my software. Which does not happen too often these days.

[kolla]

Just want to confirm that it now works as intended on CD32 systems as well

Sadly the OS3.9 Amiga ROM update doesn't contain any CD32 specific scsi.device, so ExtractModule doesn't create any DEVS:CD32, even though the original CD32 3.1 kickstart does contain the exact same scsi.device as A1200, so I copied in DEVS:CD32/scsi.device myself, and that worked.