LoadModule vs LoadResident

[kolla]

Yes, the AUTO flag of new LoadModule will look in certain paths for certain filenames, it is all very detailed described in the documentation. Only thing not described so well is which modules it will look for automatically.

"*.*" is wrong platform, what you would want is "#?.#?".

[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.

[kolla]

Building custom kickstarts and softkicking is just so much easier, lol. Sadly, I have yet to find a softkicker that works with the SX32 and/or the Apollo-630, so there I have to use LoadModule. For the A600, it seems that all modules are loaded to chipram :p

[kolla]

I have at least two systems where I have not found ways to softkick, CD32/SX32Pro and Apollo 630. On the CD32/SX32Pro, it seems problematic to load modules to FastRAM even, so lots of chipram vanishes to update ROM modules. I suspect it may be possible to work around that though.

[kolla]

LIBS:resources

Personally, I actually think DEVS:resources wold be more fitting

[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!

[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

[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.

[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

[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.