Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Oldsmobile_Mike on January 18, 2017, 04:32:30 AM
-
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?
(besides that LoadModule seems to be newer and have more features)
Are there certain modules/libraries/etc. that can only be loaded with one or the other? Is one more "reset-proof" than the other? From what I've seen they seem to be pretty interchangeable...
-
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?
(besides that LoadModule seems to be newer and have more features)
Are there certain modules/libraries/etc. that can only be loaded with one or the other? Is one more "reset-proof" than the other? From what I've seen they seem to be pretty interchangeable...
I think LoadResident started more as a way to have a resource kept handy by the OS, rather than loading it from disk. C commands, executables that were going to be used a lot. Helped a lot with a using a floppy system sometimes, if you didn't have to load the resource repeatedly. Also true of other things, but not so good for selecting a different age or version of system module, like a different version of device, handler, library etc. IIRC you had to get everything in place before the magic "binddrivers" command in a WB 1.3 startup system. After that point, you were kind of locked in to what you had setup previously. Not for executables, but for system modules.
LoadModule uses more "joined up thinking" in the matter, lets you change things like exec.library, maybe. Things that LoadResident could not handle.
That could be why some stuff works on both, some you have to use one or the other for, to get correct operation. LoadResident was good, but it was not fool proof in the early days. I think LoadModule is what you should mostly use for 2.0 onwards really. The delayed release of 2.0 caused a lot of issues in the matter. Certainly it did for me.
Confused the hell out of me at the time. I was trying to answer the phone in one hand while asking questions over the phone in the other hand, and usually both receiving and transmitting the wrong information. Developers in theory were better informed, but they were not paying money to answer "casual questions" from non-developers, even if they were friendly enough to chat.
-
I think LoadResident started more as a way to have a resource kept handy by the OS, rather than loading it from disk. C commands, executables that were going to be used a lot. Helped a lot with a using a floppy system sometimes, if you didn't have to load the resource repeatedly.
I think that was just "resident", not "LoadResident". i.e., you'd put "Resident C:Assign" into your floppy-based startup-sequence right before your list of 20 assign commands. So it wouldn't have to load the command each time. But I can't remember, it's been over 20 years since I used 1.3. ;)
-
Basically here's what I'm trying to do (see attached picture). Am currently loading all those libraries and modules through a carefully organized sequence of those two commands. It works fine, but my OCD is getting to me and I'd like to try to make it cleaner, without it erroring out at "SYS:C/LoadModule: command too long", LOL. :lol:
-
Attached screenshot shows how it is currently. And yes, it works fine like this. But it's messy and I'm OCD. Keep trying to find a way to clean it up that doesn't involve getting the hardware to burn my own custom ROM's. ;)
-
Looks pretty good. Not sure why you are doing a Version >NIL, but making Assign resident is a very smart thing to do, any Amiga age. PATH was good for making resident too, you wanted multiple paths to look for things that might be in different places.
I kind of remember 1.3 so vividly because it was always a big deal, getting things setup before the drivers got bound, on a bootable disk release. You could put the lines after that, but your LoadWB might not activitate properly unless things were set "just so" prior to that. Binddrivers was like a "glue in place" action.
WB 2.0 onwards was much nicer for that sort of thing, you might get error messages, but at least the system would startup, in some form or other. Getting a "LoadWB failed" error code and a DOS prompt was not a trivial thing, it meant I had screwed up massively somewhere already. L handler, Dev or library, setpatch, etc. Something was setup wrong.
I guess having an ENV folder was a key concept change. You wanted to tailor an environment, just use that properly. Nice idea, didn't always work, but it was a clear direction rather than a mess of spaghetti.
You could have your regular libs, devs etc in the "correct" place, and put any upgrades or downgrades in ENV and use that module instead. Saved a lot of deleting, copying, renaming stuff. Maybe that was the whole point of ENV. Most people didn't really use it, but they might have if somebody had oversight and direction of the issues.
-
The latest LoadModule can use an AUTO statement and automatically load all the modules you have in the proper places.
http://aminet.net/package/util/boot/LoadModule
-
The latest LoadModule can use an AUTO statement and automatically load all the modules you have in the proper places.
I tried that but couldn't seem to get it to work. Think I need more documentation. Is there a list of exactly what it loads, and from where? Alternatively, if I fill up a directory with everything I want loaded, can I just point it at that directory?
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).
-
There should be some info in the .Lha, maybe more related to ExtractModule and where it would place them.
It may also require more direct naming like LIBS:graphics.library instead of LIBS:graphics.library_42.8b11-02
-
Hmmm... depends on the syntax of the command. It might be OK with wildcards, after a CD. It's been too long since I used Amiga wildcards, but in theory they work with most commands.
CD Fullpath/Newmodules/
Loadmodule *.* AUTO
That way you can keep all the new stuff in a separate folder, but don't forget to CD back to SYS:S or have PATHs all lined up. Else the system might get a bit lost about locating and running the next line of startup-sequence. Unlikely, but it does no harm to be "correct as you can".
Sometimes is is helpful for system changes to be reported, and you can redirect that output into a logfile somewhere, rather than output the messages to NEWCON: or the starting shell window or whatever.
Paths are a double edged sword. While they help with getting the system to find the right pieces, they do also add a bit of overhead, and can confuse things mightily if you have multiple HDF images stored and PATH'd out. Use wisely, it's not a shotgun really.
-
Hummm. Trying the above (including renaming the files and using *.* wildcards) but keep getting various "object is not of the required type" and "already resident - object already exists" errors.
Will keep poking at it. Not a huge priority, just had a few minutes of free time tonight and thought maybe I'd get lucky...
-
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 "#?.#?".
-
Hummm. Trying the above (including renaming the files and using *.* wildcards) but keep getting various "object is not of the required type" and "already resident - object already exists" errors.
Will keep poking at it. Not a huge priority, just had a few minutes of free time tonight and thought maybe I'd get lucky...
Well, might be the intiial CD. Commands like that are very sensitive to what they're pointing at, and exactly where the system is looking, when they are run. Unless the new module replaces an existing module just right, I would expect some errors. Maybe they have to happen in a certain order? Hmmm... L handlers, Dev devices, Lib Libraries. It depends how dependent the new ones are on each other? That would make sense. If a device needs a library, you have to make the library available first. Likewise, if an device needs a handler, you need the handler first?
It's a puzzle trying to work out the priority, but there should be a pretty simple concept behind that. Can't work it out now.
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 "#?.#?".
Whatever. A wildcard is pretty much the same basic concept, but the way it's handled is kind of unique to each platform.
So I guess maybe wildcards with paths and assigns, or you really do have to put things in the right place... nah, that doesn't make sense, you don't have an AUTO option unless there's a manual option too, somehow. Manual you retain control, automatic could do any kind of system without you being aware of what's really happening,
-
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.
Guess I would need the "for dummies" guide. As in, "AUTO will only load graphics.library from LIBS:, and only if the filename is "graphics.library".
I know the docs mention stuff about wildcards, and also putting stuff in subfolders, but I couldn't get it to work. I created subfolders inside DEVS:, LIBS:, and L: and called them A2000B, and stuck copies of all my custom libraries in them, but the most I could get out of it were errors that the library had already been loaded when I tried cold booting. :(
"*.*" is wrong platform, what you would want is "#?.#?".
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?
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
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.
-
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.
-
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.
-
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.
-
@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.
-
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.
-
Yes, of course. If the directory name is "SYS:ResidentModules", then
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...
-
Which patch is the utility.library ?
-
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
-
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
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. (-;
-
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/#? ?
-
So that I understand correctly, it's still looking in the LIBS: directory
No, Mike. It's in your ROM. I yet have to see an Amiga that comes without intuition in ROM. (-;
-
No, Mike. It's in your ROM. I yet have to see an Amiga that comes without intuition in ROM. (-;
Then why is LoadModule SYS:/ResidentModules/#? failing to replace it?
But when I write the command as "LoadModule Libs:Intuition.library" it works fine?
What I'm saying is, everything works fine. I just have huge and unwieldy long lines full of "LoadResident" and "LoadModule" commands in my Startup-Sequence. They're so long, in fact, that I can't add anything else to them. I hit the limits of character spacing in Ed, even.
I'm replacing just about every component in the ROM through these long and unwieldy statements and am trying to simplify by dumping all my modified libraries/devs/handlers all into one directory and just saying "Hey, LoadModule, just load everything in this directory" where I'm struggling. :confused:
Yeah yeah, one of these days I'll just break down and get the equipment to burn my own ROM's. :rofl:
-
Then why is LoadModule SYS:/ResidentModules/#? failing to replace it?
See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.
But when I write the command as "LoadModule Libs:Intuition.library" it works fine?
No. It doesn't make a freaking difference. The matter *how* you load the modules does not matter. With AUTO, without AUTO, manually, with or without wildcards, all irrelevant. Once again:
You cannot replace a module in ROM with a module from disk if the latter has a version number lower or equal than the version that is already there. Already there = it is in the ROM of your machine.
It is really *that* simple. Exec resident modules work this way. There is no check for the revision. There is only a check for the version. If the version from ROM is newer or equal, LoadModule and also exec takes the version from ROM.
If you want to override this, add "DOWNGRADE". But then don't come back to me and tell me that your system became unstable. It's then your problem.
-
See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.
I think that's where a lot of us have been screwing up. That is what gives the user the control back, if they want to take the responsibility. I'm guilty of not knowing that.
Things are pretty much set to encourage using later versions of modules, but you don't HAVE to. If you do start doing that though, you might break bits other parts of the OS. Much more likely if you are downgrading to earlier resources (V number does not always tell the whole story here).
Which is fair enough, developers are encouraged to write new versions which address issues with the module. Not patch things up so that older software, which the developer might not have to test with. If the older software follows the rules, it should work anyway with an updated resource.
-
See above: You have already a V40 in ROM. You cannot replace a V40 in ROM with a V40 from disk, *UNLESS* you also specify "DOWNGRADE". You can replace V40 from ROM with V42 from disk if you would have it.
It's not a downgrade. It's intuition.library version 40.86b7 from here (https://amiga.foul.fr/), that was discussed "to death" way back in this thread (http://www.amiga.org/forums/showthread.php?t=67146). Version in ROM is 40.85. But I think I get it, now. This goes back to something mentioned in one of the previous threads on this subject - that unless you specify the file directly, AUTO only reads the major version number (40) and not the full "40.86". This is just an example, though - it's doing the same thing with all the libraries (like in Kolla's case, it was trackdisk.device (http://www.amiga.org/forums/showpost.php?p=818021&postcount=47)). Now I think I understand.
Ah well, so wildcards don't work, and AUTO doesn't work (with my particular requirements, anyway)... guess I'll keep doing it the "old fashion" way. Thanks! :)
If you want to override this, add "DOWNGRADE". But then don't come back to me and tell me that your system became unstable. It's then your problem.
Hey now, no need to get snippy. From a layman's perspective I had assumed what I was trying to do was pretty simple: automatically load an entire directory full of replacement libraries, devs, and handlers, instead of having to spell out each one in the Startup-Sequence. Didn't realize it would be so difficult, lol. ;) Thanks for your help, cheers!
-
Have you tried wildcards to load all of them from your directory plus the DOWNGRADE option on the end as Thomas said? If he says it should work then it ought to.
-
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
-
It's not a downgrade. It's intuition.library version 40.86b7 from here (https://amiga.foul.fr/)
So it's a downgrade. How often do I need to say this again: *IF* you want to replace a ROM module with a disk module of the same or a lower release, you need to specify DOWNGRADE.
There is no discussion here. This is the way it is. There is no official 40.xxx something, and if there would be a new version of intuition, it would have a version number of 41 or above. It is *really* that simple.
This goes back to something mentioned in one of the previous threads on this subject - that unless you specify the file directly, AUTO only reads the major version number (40) and not the full "40.86".
NO, NO, NO, and NO again. AUTO does not read version numbers. Version numbers are completely *UNRELATED* how you specify the file.
What is so complicated reading the specs. There are two very simple things here:
a) the file MUST be named like the module inside. The module is "intuition.library", so the file must be named "intuition.library".
b) if the version number of the module in the file is below or equal to the version number in ROM, you MUST specify DOWNGRADE.
Ah well, so wildcards don't work, and AUTO doesn't work (with my particular requirements, anyway)... guess I'll keep doing it the "old fashion" way. Thanks! :)
AUTO does work, and wildcards also *DO WORK*. Just name the thing correctly, and use proper versions. YES, I DID TEST THIS.
Hey now, no need to get snippy.
At some point, enough is enough. I explained multiple times. I wrote a spec, I provided examples. If you still do not read them, and instead invent any other "explanation", I really do not see how I can possibly help you.
From a layman's perspective I had assumed what I was trying to do was pretty simple: automatically load an entire directory full of replacement libraries, devs, and handlers, instead of having to spell out each one in the Startup-Sequence. Didn't realize it would be so difficult, lol. ;) Thanks for your help, cheers!
And exactly that works. Put all the replacement stuff in one directory, then run
LoadModule mydirectory/#?
YES, IT IS REALLY THAT SIMPLE.
And once again, if you want to use any hacked up versions that conflict with the versions in ROM, and do not advance the version number, this becomes
LoadModule mydirectory/#? DOWNGRADE
And once again, the file names must match the module names. Thus, the thing needs to be named "intuition.library" and not something else. In particular, *NOT "intuition_blablabla.library".
If you look into LIBS:, then the "mathieeedoubbas.library" is also named "mathieeedoubbas.library" and not "mathieeedoubbas_v45.library". It is the very same simple principle. Don't tell me that things "don't work" if you still do not read *carefully* what I have written.
-
Building custom kickstarts and softkicking is just so much easier, lol.
Not for people that don't read instructions. It's the same problem all over.
For the A600, it seems that all modules are loaded to chipram :p
If that's the only memory that is MEMF_KICK, then that's the way it is.
-
There is no check for the revision.
Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.
-
Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.
It's always a downgrade if it's the same broad version, because it is ALIEN to the release the system is currently using. That might be the release on the ROM, it might not. The system just cannot tell from the V number.
The replacement might work well, it might not, but it forces the user to think about these issues. The system can't tell really, but assumes new V whole numbers are genuine upgrades.
I figured there had to be some way for manual selection of libraries, but I couldn't find a definite "this is correct" method.
Thank you ThoR. I did not post that earlier, I am truly grateful.
Please, don't be too harsh on Mike, it's mostly my (garbled) recollections that led to the issue being discussed.
I set you on a wild goose chase Mike - but at least there WAS a goose at the end. Sorry for the amount of confusion raised, but at least we did get a definite solution.
-
Why is this? Eg. V45.1 is of course an upgrade compared to V45.0, but would be considered incorrectly to be a downgrade by LoadModule.
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:
struct Resident {
UWORD rt_MatchWord; /* word to match on (ILLEGAL) */
struct Resident *rt_MatchTag; /* pointer to the above */
APTR rt_EndSkip; /* address to continue scan */
UBYTE rt_Flags; /* various tag flags */
UBYTE rt_Version; /* release version number */
UBYTE rt_Type; /* type of module (NT_XXXXXX) */
BYTE rt_Pri; /* initialization priority */
char *rt_Name; /* pointer to node name */
char *rt_IdString; /* pointer to identification string */
APTR rt_Init; /* pointer to init code */
};
The system - exec and LoadModule - cannot and does not possibly distinguish between a 45.1 and a 45.2.
Thus, whether you replace a 45.3 by a 45.10 or a 45.1 looks all the same to LoadModule, and to exec, and to all the rest. Thus, without a check, you could replace a 45.3 by a 45.1, and that's not desired. You could also replace the ROM version with an older version, and that's not desired either.
"DOWNGRADE" is the "yes, I really know what I'm doing" switch, and tells LoadModule not to worry about versions. It cannot tell anything about revisions.
-
If that's the only memory that is MEMF_KICK, then that's the way it is.
There is, BTW, a switch "NOMEMFKICK" to try "MEMF_PUBLIC", i.e. generic memory for the modules. I do not know whether this works on your machine, it is really a matter of how the memory is added to the exec memory list. I afraid you just need to try it....
-
"DOWNGRADE" is the "yes, I really know what I'm doing" switch
I think what's confusing to a layman is the name "downgrade". ;)
Thanks for the help, guys. Like I said before, all of my custom modules work fine when I load them the old fashion way. Will just keep on doing it like that, lol. :lol:
-
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.
-
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).
-
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:
-
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?
-
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.
-
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!
-
Seconded
-
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.
-
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:
-
Grumpy Cat and I are very pleased with your legacy of accomplishments Mike! Ummm, just take my word for it! :lol:
(http://momsieblog.files.wordpress.com/2014/07/the-grumpy-cat-is-finally-happy-very-cute-funny-picture.jpg)
-
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:
-
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.
-
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.
-
LIBS:resources
Personally, I actually think DEVS:resources wold be more fitting :)
-
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.
-
Another thread resurrection... :)
@Thomas
The LoadModule readme shows a few examples, one of them being...
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!
-
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...
-
Another thread resurrection... :)
@Thomas
The LoadModule readme shows a few examples, one of them being...
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! ;)
-
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. ;)
-
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???
-
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.
-
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...
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 :)
-
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.
-
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.
-
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!!
-
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.
-
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 :D
-
Cheers, Thomas! And thanks for heads-up Mike :D
You are welcome. Whenever I find the time, I'll update my software. Which does not happen too often these days.
-
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.