MuTools and more updated to V46

[fishy_fiz]

@amidude

Ironic that you should suggest people read your posts better then go on to display the fact you didn't read certain posts at all....
The *very first* post I made was addressing Thomas Richter thanking him for the new MuTools.
A far cry from your claim that I didn't comment on the software at all.

Also ever consider the fact that people actually agree, hence the reason we "gathered around the biggest blabber mouth"?

You acted like a dick and people called you on it, its as simple as that.
No amount of smoke and mirrors will change the fact.

Anyway, I'm done with this line of conversation. I've said my bit and talking in circles will lead nowhere.

[AmiDude]

@amidude

Ironic that you should suggest people read your posts better then go on to display the fact you didn't read certain posts at all....
The *very first* post I made was addressing Thomas Richter thanking him for the new MuTools.
A far cry from your claim that I didn't comment on the software at all.

Also ever consider the fact that people actually agree, hence the reason we "gathered around the biggest blabber mouth"?

You acted like a dick and people called you on it, its as simple as that.
No amount of smoke and mirrors will change the fact.

Anyway, I'm done with this line of conversation. 've said my bit and talking in circles will lead nowhere.

So, now you're trying to turn things around. You're the greatest moron around. Nobodys falling for that. Everyone can see you jumped in to this thread just to provoke things more.
And it's not the first time you did such thing. You sick little bastard!

Quote:  
"talking in circles will lead nowhere".

That's what you were doing all the time. Glad you see it clear now. Now, stop whining and get a grip on yourself! Moron! :quickdraw:

[kolla]

@AmiDude
You're clearly the bigger moron here, jumping in here just to... what exactly? Your Amiga setup is very... simple, like its owner, obviously.

[fishy_fiz]

@amidude
Seriously bloke, get a grip.
Which part of, "the very 1st post I made was addressing Thomas Richter thanking him" is it you're having trouble with?
In what way, shape or form does that amount to me only joining the thread to provoke things more?
I agreed with the consensus *after* it was vocalized, and after my original post.

What do you think I'm trying to get people to fall for? My thanking Thomas for MuTools, or me agreeing with the opinion that you was acting like a dick?
There's no hidden agenda here. I've been upfront and straight forward from the start.
Now you on the other hand started off antagonistic and just continued to throw tantrums at everyone since.

Seriously guy, just let it go. The thread is about new MuTools, not an exercise in insulting those that think differently to yourself.
Doesn't take a rocket scientist to figure out how that will (and has) pan out.

[utri007]

I have used this with my amiga 1200 Computers with 1mb rom. Earlier there wasn't proper solution for Blizzard turbos.

[eliyahu]

@thread

i'm rather surprised at the behavior of some of you guys, but let me make it absolutely clear about conduct on this site: there is no tolerance for inappropriate language, ad hominem attacks, or childish insults. if you see anything like that, hit the report button; do not respond in kind. anyone pulling anything similar in this thread again will earn a vacation from posting privileges.

-- eliyahu

[kolla]

@eliyahu
Ahm, ok mommy.

@ThoR
So I spent last night playing with the new LoadMdule (and a little MuTools) on my SX32, since it is one of the few systems I haven't managed to find a working softkicker for.

Things mostly work fine, except with some quirks that I haven't really figured out yet - sometimes on reboot, the modules are no longer resident, yet the system will try to boot up as if they were. To get around this I must to a "long reset" (press ctrl-a-a really long), or power cycle. I will investigate this a bit more so I can reproduce the problem consistently.

A small, but really annoying thing is that LoadModule (at least with AUTO) doesn't want to load modules of same major revision as already resident. For example, kickstart 3.1 comes with trackdisk.device 40.1, while I have DEVS:trackdisk.device that is 40.2 - LoadModule will complain that trackdisk.device version 40 is already resident, so I guess I must specify such modules specifically (I just now read the line in the readme saying "This will augment the list of modules provided through the MODULE argument.")

[guest11527]

So I spent last night playing with the new LoadMdule (and a little MuTools) on my SX32, since it is one of the few systems I haven't managed to find a working softkicker for.

Depending on the avaialble RAM, MuMapRom *might* be worth a try. This said, it is also very much a hack, and yes, if you want to map a 1MB ROM for it, you need plenty of local motherboard RAM the machine does likely not provide.

Things mostly work fine, except with some quirks that I haven't really figured out yet - sometimes on reboot, the modules are no longer resident, yet the system will try to boot up as if they were. To get around this I must to a "long reset" (press ctrl-a-a really long), or power cycle. I will investigate this a bit more so I can reproduce the problem consistently.

How do you reset the machine? There are two "must-work" methods, namely the keyboard reset, and exec/ColdReboot(). If one of them does not work, let me know.

LoadModule will, by default, place its modules in MEMF_KICK memory (except exec, which must potentially go into MEMF_LOCAL). In worst case, modules also need to go to MEMF_LOCAL, or even MEMF_CHIP, even though this *should* not required if the memory is announced correctly. Details would be interesting. If the standard arguments do not work, I can probably compile a version for you that puts the modules into MEMF_CHIP just for testing.

BTW, it is rather important that LoadModule comes into the system before MuFastZero. Once the latter is installed, Execbase may exist "twice": Once in its original position in Chip RAM, and this is the location where it is required for the reset. And once in the mirrored position in fast RAM. The CPU can, once the tool is run, only see the latter mirror. Thus, if you install LoadModule on top of MuFastZero, you only modify the active version of exec, but not the version that comes in play after a reset.

A small, but really annoying thing is that LoadModule (at least with AUTO) doesn't want to load modules of same major revision as already resident.

Not only with AUTO, but in general. It is a fairly general limitation of exec. If you place two modules on the resident list, exec will grab the one with the highest version number. There might be a way around this, but in general, there are system limitations like this for a reason. Libraries and devices have dependencies between them, and it is typically not a good idea to insert a lower-release into a system that was compiled for a higher release.

(I just now read the line in the readme saying "This will augment the list of modules provided through the MODULE argument.")

This doesn't help. It is only later that the code checks the release dates, AUTO only compiles the command line (so to say) for the rest of the code.

[kolla]

Depending on the avaialble RAM, MuMapRom *might* be worth a try. This said, it is also very much a hack, and yes, if you want to map a 1MB ROM for it, you need plenty of local motherboard RAM the machine does likely not provide.

Right, should not be a problem, I currently have 8MB of fast RAM, but can add up to 64MB iirc.

How do you reset the machine? There are two "must-work" methods, namely the keyboard reset, and exec/ColdReboot(). If one of them does not work, let me know.

Well, I have this habit of typing "reboot", so it is the reboot command from... I think the OS 3.1 Installer floppy, but it also happens with ctrl-a-a. The SX32 Pro is a hack in so many ways (which is why Linux and *BSD never really worked well on it), the CD32 also has a reset button, and who knows what it does

LoadModule will, by default, place its modules in MEMF_KICK memory (except exec, which must potentially go into MEMF_LOCAL). In worst case, modules also need to go to MEMF_LOCAL, or even MEMF_CHIP, even though this *should* not required if the memory is announced correctly. Details would be interesting. If the standard arguments do not work, I can probably compile a version for you that puts the modules into MEMF_CHIP just for testing.

I am happy to do tests. I am going on holidays vacation, but might bring the system with me to tinker with. Ah yes, I had to use the EXECTOCHIP flag, or I would get a yellow screen and rapidly blinking power LED, followed by a reset.

BTW, it is rather important that LoadModule comes into the system before MuFastZero. Once the latter is installed, Execbase may exist "twice": Once in its original position in Chip RAM, and this is the location where it is required for the reset. And once in the mirrored position in fast RAM. The CPU can, once the tool is run, only see the latter mirror. Thus, if you install LoadModule on top of MuFastZero, you only modify the active version of exec, but not the version that comes in play after a reset.

Aha, yes, I understand.

Not only with AUTO, but in general. It is a fairly general limitation of exec. If you place two modules on the resident list, exec will grab the one with the highest version number.

And by "version number" you mean major version number.

There might be a way around this, but in general, there are system limitations like this for a reason. Libraries and devices have dependencies between them, and it is typically not a good idea to insert a lower-release into a system that was compiled for a higher release.

Maybe I was unclear - I am not inserting a lower-release, I am inserting a higher release, but with same major revision. For example, I try to replace trackdisk.device 40.1 with 40.2, but LoadModule protests. I suspect if I just edit the revision inside the binary to say 41.2 it will magically work, but that would be cheating

This doesn't help. It is only later that the code checks the release dates, AUTO only compiles the command line (so to say) for the rest of the code.

OK, that is what I suspected

What I can say, is that the previous version (40.13?) did manage to load all these "minor" upgrades just fine, so it is a bit odd that this new version doesn't.

[kolla]

Btw - on installing 680?0.library files, the installer is eager to patch c:SetPatch - there is no patch for the 44.38 from 3.9BB2, does that mean that 44.38 does not need patching and will work as is, also with 68030.library?

[guest11527]

Btw - on installing 680?0.library files, the installer is eager to patch c:SetPatch - there is no patch for the 44.38 from 3.9BB2, does that mean that 44.38 does not need patching and will work as is, also with 68030.library?

Yes, you are right. The Os 3.9 versions also check for the 68030.library. No need to patch.

[guest11527]

Right, should not be a problem, I currently have 8MB of fast RAM, but can add up to 64MB iirc.

Fast Ram is not important. Local Ram is important. The difference is that MEMF_LOCAL additionally requires that the RAM does not go away during a reset. Autoconfig Ram typically goes away because expansion has to re-run the configuration, and that is of course deadly if the MMU tables are in this Ram.

Well, I have this habit of typing "reboot", so it is the reboot command from... I think the OS 3.1 Installer floppy, but it also happens with ctrl-a-a. The SX32 Pro is a hack in so many ways (which is why Linux and *BSD never really worked well on it), the CD32 also has a reset button, and who knows what it does

There are various "tools" to reboot. The worst of them run into a CPU reset, potentially followed by a jump into the kickstart. That is in almost all cases not a good idea. The MMU reset resets the peripherals, but not the CPU, and in particular not the MMU. Depending on the system setup, this may have deadly side conditions - see above why.

I am happy to do tests. I am going on holidays vacation, but might bring the system with me to tinker with. Ah yes, I had to use the EXECTOCHIP flag, or I would get a yellow screen and rapidly blinking power LED, followed by a reset.

The output of ShowConfig would be a good start. It means that MEMF_KICK is probably not announced correctly. Don't worry about exec in chip, MuProtectModules will move it away from there.

And by "version number" you mean major version number.

I - or rather exec/InitResident - mean that indeed.

What I can say, is that the previous version (40.13?) did manage to load all these "minor" upgrades just fine, so it is a bit odd that this new version doesn't.

Actually, you then must have been using a very old release. This particular check is not new in this release. I don't remember when it came it, but certainly not this time. AUTO is more a top-level change, and the only other change I made was the ability to replace exec. This, however, was quite tricky. "expansion" is still out of reach, and might probably remain so for quite a while. But there is nothing particular in expansion that requires fixing.

[kolla]

Yes, you are right. The Os 3.9 versions also check for the 68030.library. No need to patch.

OK, and no need to 680x0.library I take it

[Romanujan]

It is a fairly general limitation of exec. If you place two modules on the resident list, exec will grab the one with the highest version number. There might be a way around this, but in general, there are system limitations like this for a reason. Libraries and devices have dependencies between them, and it is typically not a good idea to insert a lower-release into a system that was compiled for a higher release.

Some workaround must be possible - with LoadResident from RemApollo package I'm able to substitute the console handler with KingCON (Remus-compatible version, patched by Cosmos). With LoadModule I can't - it complains about module already present.

-------

One more option I miss is to be able to do something like this:

Code: [Select]

LoadModule module1 NOREBOOT
LoadModule module2 NOREBOOT
...Currently this load only the 1st module. I use plenty of them (probably most of the kickstart gets replaced) and the maximum command line length is simply too small for me.
Better yet, it could be possible to submit a directory instead of module, and the tool could load all the modules inside. Even better - the machine type check could be applied to this directory and appropriate subdirectory could be used.

(this is, of course, only a suggestion)

[guest11527]

Some workaround must be possible - with LoadResident from RemApollo package I'm able to substitute the console handler with KingCON (Remus-compatible version, patched by Cosmos). With LoadModule I can't - it complains about module already present.

Then it's probably better that you cannot. (-;

Better yet, it could be possible to submit a directory instead of module, and the tool could load all the modules inside. Even better - the machine type check could be applied to this directory and appropriate subdirectory could be used.

(this is, of course, only a suggestion)

Did you check the documentation of the AUTO argument? It picks the modules from all over the system.

What might be missing is wildcard resolution, though.

[Romanujan]

Did you check the documentation of the AUTO argument? It picks the modules from all over the system.

What might be missing is wildcard resolution, though.

Yes, I have checked. If module name looks like this - check this directory, if looks like that - check that directory, etc. It's so smart that is almost unpredictable. And I definitely don't want to spread the modules all over my system - I use Remus from time to time.

But the wildcard resolution would work fine for me too.