LoadModule vs LoadResident

[Pat the Cat]

This could partially explain why CBM or anybody else really were not in a hurry to release new versions. It's only one byte, you can't go higher than V255. But, what could be done maybe, with the LOADMODLUE issue, is for the command to scan the file name it is loading, and maybe add a query with a toggle off you had to set, to prompt the user. That's a lot more complex and less elegant really.

I think the way it is implemented is OK. It does the job, AND it really does make you, the end user, take responsibility for what you are doing.

[Georg]

I haven't designed "struct Resident" and the resident system of exec. That's the way it is. There is no "revision" information in the resident structure, only a version information:

In most residents there is revision information in rt_IdString. So you could extract it from there if the string contains (tostr(rt_Version) + "."), otherwise assume revision = 0 (unknown).

[Oldsmobile_Mike]

Just thought I would follow up on this old thread to say I finally got LoadModule working with the "DOWNGRADE" option.

I had to use a combination of DOWNGRADE + AUTO + a manually specified directory ("SYS:ResidentMods") where I packed in all the extra stuff that LoadModule wasn't able to detect automatically.

But here's some additional info, if anyone is interested (screenshots attached).  Still a hair on the kludgy side, still not as good as burning a custom ROM, but it's able to successfully load all my modules without the super-long strings of commands I was having to use before.  And that's all I was really trying to do, LOL.  :banana:

[trixster]

Could you use Setpatch NOROMUPDATE rather than SKIPROMUPDATES? This would save you having to list all the updates in your setpatch line that you don't want setpatch to load. Or does "romupdate" do more than just load those various libraries/devices?

[Damion]

still not as good as burning a custom ROM

It's a fun proof-of-concept, otherwise you're not missing out on anything. It's really annoying when some piece of software is inevitably broken due to a change in the ROM, and now you're stuck without some further hassle.

I've gone back to standard ROMs and tools like LoadModule and BlizKick. (Or some sort of flashrom is handy, like the DENEB or new A500Flash...). As Kolla mentioned, softkicking your modified ROM (if possible) is the way to go.

[dschallock]

Just wanted to applaud your constant effort @oldsmobilemike to improve and tweak your system by means of the latest and greatest libraries and in the cleanest most streamlined method possible.  As is often the case with our miggies, once you dig into a problem it can take numerous hours of head banging to get it working right (if at all).  The efforts and frustrations you make permanent on the forum make the process a little less daunting for the next Joe.  Personally this process is still above my pay-grade... I'm finally (in 2017) using "versionWB" to check libraries and just update them with the latest versions while maintaining a backup of the version before just in case. hahaha.  But maybe I'll get the guts to try what you did here at some point.
Anyway... good on ya!

[trixster]

Seconded

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

[Oldsmobile_Mike]

Just wanted to applaud your constant effort @oldsmobilemike to improve and tweak your system by means of the latest and greatest libraries and in the cleanest most streamlined method possible.  As is often the case with our miggies, once you dig into a problem it can take numerous hours of head banging to get it working right (if at all).  The efforts and frustrations you make permanent on the forum make the process a little less daunting for the next Joe.  Personally this process is still above my pay-grade... I'm finally (in 2017) using "versionWB" to check libraries and just update them with the latest versions while maintaining a backup of the version before just in case. hahaha.  But maybe I'll get the guts to try what you did here at some point.
Anyway... good on ya!

Thank you, sir!  My fame will live forever in the hallowed halls of amiga.org website.  That is unless, of course, it goes down like amigaworld.net.  :lol:

[giZmo350]

Grumpy Cat and I are very pleased with your legacy of accomplishments Mike! Ummm, just take my word for it! :lol:

[Oldsmobile_Mike]

Hi!  Since somebody just asked me about this, and for the benefit of anyone who comes after me.  I was just setting up a CF a few days ago that has 3.1 + BetterWB + some of the custom LoadModule stuff on it (like I have on my A2000 but without the additional LoadModule items for the graphics card).  Here's a few photos.

The LoadModule statement itself (in Startup-Sequence) scans and replaces various system modules with AUTO.  I also created a separate folder of stuff for it to load (SYS:ResidentMods) that it is not able to find automatically.  In the case of this one I also took out the NOREBOOT option, since it's 3.1 (as opposed to 3.9).

TL;DR.  Some quick photos off my camera phone attached.  

Edit: This is still a WIP. :lol:

[guest11527]

Don't make it too complicated. All ROM-based components can go into their canonical location, and LoadModule will pick them up, with the AUTO option only.

battmem.resource, FileSystem.resource misc and potgo and card.resource goes, like every resource, into LIBS:resources. However, none of these resources, probably with the exception of card.resource, do have any defects I am aware about. battmem is just a very tiny wrapper around battclock.

ramlib goes to LIBS:modules.

utility.library goes to LIBS: (where else?)

The datatypes.library is likely not ROM-able and should stay on disk.

Kingkong goes to SYS:Trashcan.

[dannyp1]

TR, I think the reason for the updates of the resources you mentioned was just to make them smaller to free up room for fitting more on roms that are being made. Someone with your knowledge would have to be the judge if they are actually more efficient.

[kolla]

LIBS:resources

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

[guest11527]

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

Yes, I see what you mean. Though it depends a bit on the resource. FileSystem.resource works well in LIBS: It's too late to change at this time, though.

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