Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: guest11527 on December 15, 2016, 11:39:30 AM
-
Hi folks,
yesterday, a major update of MuTools and the mmu.lib appeared in the Aminet, along with additional tools around it. Since the list of updates is so long, it's probably good to give an overview on what happened:
- mmu.library
Except minor bug fixes, the library introduces one new concept, namely that of "Context Windows". This is a set of memory regions whose MMU mapping can be rapidly changed between various pre-defined settings, as to map in hardware quickly or switch between multiple configurations quickly.
- MuManual
Reworked the manual completely. This is more a second edition which was proofread, extended and corrected. Especially, I added the documentation for the ContextWindows, and for the internal interface by which the library talks to "LIBS:mmu" commands and the MMUInit module.
The archive also contains example codes, e.g. that of MuSetCacheMode, or a demo of the context windows, along with all the includes, .fd files and prototypes.
- CPU libraries.
No major changes, except that the interface towards p5emu.library and P5Init was somehow reworked and is much looser now (the CPU libraries are not supposed to know, they are patched by p5init). The advantage of this design is that many (most? all?) P5 graphic cards should now work out of the box without further patching of the CGFx driver. P5 PPC hardware is still in the stage of being unsupported due to lack of documentation.
- MuFastROM:
Support of CD32 ROMs. In particular, MuFastROM can now also mirror the extension area of the ROM.
- MuScan, MuForce:
Support of context windows (see above, a new feature).
- MuProtectModules:
Supports V45 of LoadModule (see below). In addition, MuProtectModules can now also relocate loaded modules into faster 32 bit RAM if necessary. On some boards, modules can only be placed in autoconfiguring slow 16-bit RAM, but MuProtectModules now includes an option to mirror them to 32-bit RAM.
- Installer
Also recognizes now P5 PPC boards correctly now in case their ROM-based CPU libraries have been removed by BPPC fix. This was a last-minute change Harald ("Rotzlöffel") and I found two weeks ago.
Unfortunately, Hyperion reacted too slow for this release, but in the next release, I will be able to include the 3.9 Installer program to avoid the hassle of 3.1 users first requiring this binary for installation of the tools. The "go" came just hours too late.
License conditions for the installer were unacceptable before ("you need a written permission by Commodore Büromaschinen GmbH", yeah - right!)
- MuMapRom:
Reworked again to support additional boards and to enhance compatibility.
- MuFastChip,MuFastZero,MuMove4,MuSetCacheMode,MuRedox,MuGuardianAngel:
No changes necessary, work OOB with the new library due to its stable interface. The only thing I changed was my contact email.
Associated to the MuTools, but not exactly in the package, the following also appeared two days ago:
- LoadModule and Extractmodules:
Completely reworked and extended versios of the tools. The new feature is that "ExtractModules" now recognizes the contents of the modules it extracts, and can name and place them itself. If you call "ExtractModules" without any arguments, it will "spill" the contents of the ROM updates exactly in the right places on your disk (namely, LIBS:, DEVS: and L:) so that LoadModule can pick them up from there.
I didn't even know that the ROM Updates included an exec version for the walker. Well, here you go...
LoadModule became much more intelligent now. In addition to a string of module names, "LoadModule" takes now also a single argument "AUTO" which automatically scans your system for replacement modules and loads them. Thus, "just place the new layers.library into LIBS: and LoadModule will pick it for you". The same goes for the shell, the file system... and everything else ExtractModules found - or is somewhere in the ROM of the system. The modules are also sorted by system, so you can keep several versions of the same module on the disk, for multiple systems.
Hence, you no longer need to know which modules to replace, or edit the startup-sequence for that. Of course, the manual mode continues to work if you want to fine-tune.
In addition, LoadModule can now also replace the exec.library (provided the library has been prepared in the right way, the 3.9 version is). The mechanism for this stunt is a little bit different, but also a lot simpler than that in SetPatch, and also works in case the system placed exec in autoconfiguring memory.
The only library neither SetPatch nor LoadModule is able to replace consistently througout all boards is expansion. Lukely, there is not much about it that requires replacement, hence...
I hope "LoadModule" will gain some importance in the future, and will be able to replace the rather "closed" ROM-Updates mechanism of SetPatch. The functionality offered by LoadModule is much more flexible and open: Whenever you need a ROM module replaced, just put it in its right path (e.g. LIBS: or DEVS:) and the system will pick it up for you automatically. Details - as always - in the documentation.
So long,
Thomas
-
I like the description of new LoadModule - great, thanks! MuFastROM for CD32 also sounds good, I suppose the SX32 Pro with full MMU 030 is the only system where it can be useful? Well, I just happen to have one :)
-
I like the description of new LoadModule - great, thanks! MuFastROM for CD32 also sounds good, I suppose the SX32 Pro with full MMU 030 is the only system where it can be useful? Well, I just happen to have one :)
It is usefull with any Amiga wich have 1mb custom kickstart.
-
It is usefull with any Amiga wich have 1mb custom kickstart.
Yes, and many thanks for testing!
Be reminded, however, that only A1200 and A4000 (besides the CD32) can take 1MB ROMs. Even then, at least a couple of 1MB ROMs are "wrong" in a particular sense. The ROM size (at ROMEnd) does *not* indicate the total size of the ROM, but only the size of the upper ROM area, hence can be at most indicate a size of 512K. I currently added a workaround to the tools, though I would prefer if people would stop playing with it.
-
Thank you Thomas.
-
I am testing Muforce and MuGuardianAngel, and work very nice, providing stability to M1230XA Accelerator.
-
I am testing Muforce and MuGuardianAngel, and work very nice, providing stability to M1230XA Accelerator.
I've an M1230XA up and running here, and it's very stable without the MU software. I figure: the more little hacks and commands, the more unstable the system becomes.
At least, that's my experience. I'd like to keep my systems simple & original.
:cool:
-
I've an M1230XA up and running here, and it's very stable without the MU software. I figure: the more little hacks and commands, the more unstable the system becomes.
The 68030 has a particular bug that becomes most apparent on bridgeboards where it causes hangs and that can be successfully worked around by using the MMU, so I wouldn't really call this "becoming more unstable".
The bug is that the 68030 caches long-word aligned long-word writes in its data cache even if the cache-inhibit pin of the CPU signals that it should not to. Typically, the data cache of the 030 is small enough to let programs get away with it, but in particular situations interesting and strange things can happen due to this problem. For example, the CBM bridgeboard software had a loop that was tight enough to run into the issue.
-
Thomas : Would MU libraries help with 68060 and Bridgeboard? I have 8088 bridgeboard wich has a latest bios.
-
The 68030 has a particular bug that becomes most apparent on bridgeboards where it causes hangs and that can be successfully worked around by using the MMU, so I wouldn't really call this "becoming more unstable".
The bug is that the 68030 caches long-word aligned long-word writes in its data cache even if the cache-inhibit pin of the CPU signals that it should not to. Typically, the data cache of the 030 is small enough to let programs get away with it, but in particular situations interesting and strange things can happen due to this problem. For example, the CBM bridgeboard software had a loop that was tight enough to run into the issue.
I don't own a bridgeboard and my system is véry stable and doesn't need software workarounds or any other hacks. Ofcourse, I can't speak for other people with different configurations.
-
Thomas : Would MU libraries help with 68060 and Bridgeboard? I have 8088 bridgeboard wich has a latest bios.
Well, the 68060 requires the MMU anyhow, no matter whether you have a bridgeboard installed or not.
So, in one way or another, you need a 68060.library. I provide one, but not the only one of course. Probably the only one that is still maintained.
-
I don't own a bridgeboard and my system is véry stable and doesn't need software workarounds or any other hacks.
Actually, where is the hack here?
Well, believe it or not, this 68030 bug is reality. You probably haven't triggered it in your setup, or you haven't noticed or correlated a problem with this bug, but it doesn't go away from not looking. I'm only giving you a particular well-known manifestation of it.
-
I'd like to keep my systems simple & original.
:cool:
And some people like to push their systems "to the limits". Your point is? :p
-
In fact this system (from where i´m writing right now) is very stable and original. But extremely rare times could crash on Internet. On the other hand, few WHDload games have problems even changing some commands as "noautovec" and others. With MuForce some WHDload games with problems are working now.
-
Actually, where is the hack here?
Well, believe it or not, this 68030 bug is reality. You probably haven't triggered it in your setup, or you haven't noticed or correlated a problem with this bug, but it doesn't go away from not looking. I'm only giving you a particular well-known manifestation of it.
So, you solved a 68030 bug. Good for you. I don't need it. As I said earlier;
My 030 based A1200 system is working perfect. Why change things then?
It's more logical to change things when a problem occurs. Maybe other people
have some use for your little program, but I don't. OK, clear now?
-
And some people like to push their systems "to the limits". Your point is? :p
My point is? Read the above. And if people want to push their systems "to the limits",
then that's their choice. I'd like to keep my systems as "classic as possible".
Different flavours for different people. ;)
-
So, you solved a 68030 bug. Good for you. I don't need it. As I said earlier;
My 030 based A1200 system is working perfect. Why change things then?
It's more logical to change things when a problem occurs. Maybe other people
have some use for your little program, but I don't. OK, clear now?
Your A1200 will work perfectly until you throw some software at it that doesn't. If you're happy with that notion, then good for you. Your computer will be better off with Thor's software though; he was only trying to make you aware of a problem that you may not have known about.
-
My point is? Read the above. And if people want to push their systems "to the limits",
then that's their choice. I'd like to keep my systems as "classic as possible".
Different flavours for different people. ;)
This thread is about some new software that some of us are actually pretty excited about (well, I tend to get pretty excited about any development for a 30-year-old computer, lol). You're obviously stuck in the 1980's. Why are you even commenting on it? Go back to playing with your Workbench 1.1. ;)
-
Well, the 68060 requires the MMU anyhow
How is that? And how about the 68040? Of course I ask this in the context of Apollo Core :)
-
How is that? And how about the 68040? Of course I ask this in the context of Apollo Core :)
The problem with the 68040 and above (and to some degree also the 68030) is that they don't have a cache-inibit-in line anymore (and it's partially non-functional on the 68030, as said, as it only applies to read, but not to write accesses), so you can no longer turn on and off caching based on some hardware logic that identifies chip ram and/or custom chip/hardware IO accesses. This is how all GVP and CBM cards attempted to solve the caching issue for the 68030, or rather believed so. That \CIIN was non-working for write accesses was found out only later, and Motorola then declared it as "specification change" in the later versions of the 68030 stating that one should use the MMU.
So, one needs to disable caching by software one way or another, on the 68040 and 68060 for certain, on the 68030 with its small cache it usually goes unnoticed since the data leaves the cache so early that it does (typically) not matter much. Exceptions do exist, though.
In principle, the TTx-registers of the 040 and 060 are "almost sufficient" because they could map the entire lower 16MB as non-cachable (all of the chip ram, all of the hardware registers), even though this is a bit extreme (also all of Zorro expansion ram becomes non-cachable by that). The exec coldstart does exactly that as "best attempt".
However, it doesn't end there: Also, you need the MMU to make DMA working. Due to a side effect of the '040 and '060 copyback cache, you need to temporarily turn off copyback caching for non-cache-aligned DMA read accesses as otherwise a dirty cache-line could overwrite data read from disk.
In other words: Either full MMU control, or only writethrough cache and no copyback cache. Or no stable DMA. Pick your poison.
In case you wonder: No, the 040 and 060 bus snooper does not help because the bus snooper cannot snoop behind the Zorro bus drivers that may separate the CPU bus from the Zorro bus.
Concerning Apollo: Yes, Gunnar and I had a long dispute over the issue as I really had some doubts concerning this problem. It turned out that the Apollo core only implements a write-through cache, so the DMA problem does not exist, and otherwise uses a fixed (but in principle software-adjustable) cache control in page sizes of 256K. This is much too coarse for most useful MMU application, but fine enough to ensure that chip RAM and IO resources are not cached, while everything else can be cached. So in principle, the Apollo core is working in this respect, though not as flexible as I was hoping for.
-
Thomas - very interesting information on the caching. A good read.
Cheers!
-
I don't own a bridgeboard and my system is véry stable and doesn't need software workarounds or any other hacks. Ofcourse, I can't speak for other people with different configurations.
Then why are you trying to speak for other people? If you have no use and aren't speaking for anyone else then I don't see why you'd comment on posts made by people who do have a use for it.
-
:) Thanks - Danke - merci :)
-
Then why are you trying to speak for other people? If you have no use and aren't speaking for anyone else then I don't see why you'd comment on posts made by people who do have a use for it.
I was refering to a comment from Drummerboy:
QUOTE:
"I am testing Muforce and MuGuardianAngel, and work very nice, providing stability to M1230XA Accelerator."
I happen to have the same accelerator. So next time, read the whole thread! Your comment to this post isn't constructive. :rtfm:
-
Your A1200 will work perfectly until you throw some software at it that doesn't. If you're happy with that notion, then good for you. Your computer will be better off with Thor's software though; he was only trying to make you aware of a problem that you may not have known about.
I know all that, but for now everything is working perfect with the software I use. If, for any reason I'm gonna try out new software in the future, then we will see how things will work out.
-
This thread is about some new software that some of us are actually pretty excited about (well, I tend to get pretty excited about any development for a 30-year-old computer, lol). You're obviously stuck in the 1980's. Why are you even commenting on it? Go back to playing with your Workbench 1.1. ;)
No need to be so denigrating! Believe me, because I like my systems to be as original and classic as possible, doesn't mean that I'm stuck in the 80's. And I can, like anybody else here, comment on every post. I was refering to Drummerboy's post.
-
I was refering to a comment from Drummerboy:
QUOTE:
"I am testing Muforce and MuGuardianAngel, and work very nice, providing stability to M1230XA Accelerator."
I happen to have the same accelerator. So next time, read the whole thread! Your comment to this post isn't constructive. :rtfm:
I did read the whole thread. Next time don't make wild assumptions before throwing around accusations.
How constructive do you think it is to reply to people who say it makes their system more stable, by saying that you have the same accelerator but you refuse to run the software? At best it's an odd post to make, at worst it could be you're trying to persuade other people not to run it. I don't know if there is something about Drummerboys configuration that requires this and yours doesn't, for all I know there is a hidden problem on your computer that you haven't noticed yet. When someone acts the way you do, then it doesn't instil confidence in what you say.
But if you don't want to run it then congratulations, you don't have to.
-
So go play with yourself for that matter, and shut the f**k up! :quickdraw:
Wow, thanks for turning an interesting thread about new software development into some bullsh**. Another one for the block list. Good job, jackass. :(
-
@Thomas Richter
Thank you very much.
Great software update. Its rare to get these sorts of low level things for classic Amigas these days, so this was a very nice surprise.
-
@Oldsmobile_Mike
I was about to post the same as your BS comment. Thanks! :)
-
Everyone was thinking it. :)
Half the point of my post above was simply an attempt to let Thomas Richter know his efforts are appreciated, and people are interested.
A person doesn't have to be interested in everything released for the Amiga, but a simple "Its not something I'll use, but thanks" is a lot better than making multiple posts and potentially spoiling other peoples fun.
-
I did read the whole thread. Next time don't make wild assumptions before throwing around accusations.
The same counts for you also..
But if you don't want to run it then congratulations, you don't have to.
Duuuhh... that was my point all the time!
-
Wow, thanks for turning an interesting thread about new software development into some bullsh**. Another one for the block list. Good job, jackass. :(
Oh yeah?! You started it by your childish coment: "Go back to playing with your Workbench 1.1"
Who do you think you are with your big mouth?! In real life you're a nobody!
Arrogant maggot! I squash you like a worm! :python:
-
@Oldsmobile_Mike
I was about to post the same as your BS comment. Thanks! :)
Everyone was thinking it. :)
Half the point of my post above was simply an attempt to let Thomas Richter know his efforts are appreciated, and people are interested.
A person doesn't have to be interested in everything released for the Amiga, but a simple "Its not something I'll use, but thanks" is a lot better than making multiple posts, being a jackass, and potentially spoiling other peoples fun.
You're idiots who follow the big mass. Brainless *ssholes! :destroy:
-
@AmiDude
And you are a big ass.
-
@AmiDude
And you are a big ass.
And why do you come to this conclusion? Did I say something wrong to you?
You also follow the big mass and are therefore also a brainless *sshole!
-
@amidude
So you're saying that being reasonable to a developer for delivering something we're interested in, for free makes us "brainless @ssholes"?
The better option is what? To be a dick instead?
Given the options I'll settle for being a brainless @sshole!.
By the way,... follow the mass? What mass do you think you're talking about? There's not even a dozen people who have responded.
And all seem to agree that you're acting like a dick by the way.
Just give it up. Every comment you make is just making the hole bigger.
*me awaits predictable childish response.
-
@amidude
So you're saying that being reasonable to a developer for delivering something we're interested in, for free makes us "brainless @ssholes"?
The better option is what? To be a dick instead?
Given the options I'll settle for being a brainless @sshole!.
By the way,... follow the mass? What mass do you think you're talking about? There's not even a dozen people who have responded.
And all seem to agree that you're acting like a dick by the way.
Just give it up. Every comment you make is just making the hole bigger.
*me awaits predictable childish response.
No, I didn't say that if someone is interested in new developped software, is an brainless *sshole. I said that the ones that are gathering behind the biggest blabber-mouth are brainless *ssholes!
Again read my posts better next time! You also have said nothing constructive in this thread. Why are you reacting in this thread any way? You've had nothing to say about the MU software in the first place. You come barge in and go blabber stupid things that makes no sense at all!
-
And why do you come to this conclusion? Did I say something wrong to you?
You also follow the big mass and are therefore also a brainless *sshole!
I just looked at your avatar, dumbass :laughing:
-
I just looked at your avatar, dumbass :laughing:
Yeah, you like that, don't you! You dirty o'll wanker! :biglaugh:
-
Thor, new mmulib is working fine. A feature I would like in loadmodule is to force loading an older library or module. When running a custom ROM sometimes I think I screwed up and want to try an older version of a library but there is no way to currently do this that I know of.
-
Thor, new mmulib is working fine. A feature I would like in loadmodule is to force loading an older library or module. When running a custom ROM sometimes I think I screwed up and want to try an older version of a library but there is no way to currently do this that I know of.
you have to Load all Modules from the Romupdate manually and set the path to your older lib by hand.....
Loadmodules libs:olderlib/myoldlib.library should do the trick...
Setpatch NOROMUPDATES
-
you have to Load all Modules from the Romupdate manually and set the path to your older lib by hand.....
Loadmodules libs:olderlib/myoldlib.library should do the trick...
Setpatch NOROMUPDATES
What I mean is I burned a custom Kickstart ROM with scsi.device 44.2, if I want to try scsi.device 43.43 loadmodule will fail saying scsi device version 44 present. Same issue if you have v43.43 of a library and the library you want to load is 43.45, it will fail saying you have the the same major version.
Loadresident has a FORCE option, but it isn't always reliable-as in the older library sometimes doesn't actually take effect. I'm just thinking it would be better in some cases for Loadmodule to not be "smart" and allow you to force whatever version you want to load.
-
What I mean is I burned a custom Kickstart ROM with scsi.device 44.2, if I want to try scsi.device 43.43 loadmodule will fail saying scsi device version 44 present..
ahh, OK... sorry I missunderstood !
-
@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
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:
-
@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.
-
@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.
-
I have used this with my amiga 1200 Computers with 1mb rom. Earlier there wasn't proper solution for Blizzard turbos.
-
@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
-
@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.")
-
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.
-
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.
-
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?
-
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.
-
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.
-
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 :)
-
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:
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)
-
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.
-
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.
-
After some more playing around...
LoadModule AUTO does not want to replace some libs in ROM, such as lowlevel.library and nonvolatile.library, because same major revision is already resident. However, SetPatch, it seems, "removes" them, so I have moved them to a SYS:Libs2 for now, which is then added to the LIBS: assign, and presto... sadly, this type of work-around does not work for other "modules", such as trackdisk.device - I simply see _no way_ to replace trackdisk.device 40.1 with 40.2 - which kinda sucks.
-
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.
Here follows:
10.Minne:> showconfig debug
PROCESSOR: CPU 68030/68030mmu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 45.65535, Exec version 45.20, Disk version 45.5
RAM: Node type $A, Attributes $105 (FAST), at $17800010-$17FFFFFF (~8.0 meg)
Node type $A, Attributes $703 (CHIP), at $8000-$1FFFFF (~2.0 meg)
Node type $A, Attributes $2 (CHIP), at $4000-$7FFF (64 K)
BOARDS:
=======================================================================
Board + ROM (HD?) (Masoboshi GmbH): Prod=2157/0($86D/$0) (@$E90000 64K)
ConfigDev structure found at location $4858
==== Board ID (ExpansionRom) information:
er_Manufacturer =2157=$86D=(~$F792)
er_Product =0=$0=(~$FF)
er_Type =$D1
(type 3, size 64K, not for free list, ROM diag vec valid, not chained)
er_Flags =$40
(no space preference, can not be shut up)
er_InitDiagVec =$80
==== Configuration (ConfigDev) information:
cd_BoardAddr =$E90000
cd_BoardSize =$10000 (64K)
cd_Flags =$2 (CONFIGME bit still set)
=======================================================================
-
Here follows:
Thanks. May I ask where the 8MB is located? This looks like 8MB 32-bit RAM on the Masoboshi, is this correct? However, this is not autoconfig RAM, and expansion surely does not add it to the system. Thus, the reason why it fails is *likely* that the ram *does* go away during a reset, unlike announced. At least exec cannot allocate resident tags there.
I should probably also set MEMF_KICK here. It's not set for this memory type and would exclude the problem.
-
Thanks. May I ask where the 8MB is located? This looks like 8MB 32-bit RAM on the Masoboshi, is this correct?
It is, a 72 pin SIMM slot on the SX32 Pro, yes. DCE really messed up with vendor and product IDs.
However, this is not autoconfig RAM, and expansion surely does not add it to the system. Thus, the reason why it fails is *likely* that the ram *does* go away during a reset, unlike announced. At least exec cannot allocate resident tags there.
I should probably also set MEMF_KICK here. It's not set for this memory type and would exclude the problem.
I'm happy to experiment.
Ideally I wish there was a softkicker that would work, or I should just get an EPROM writer again. Every time I update my kickstarts I also assemble one for CD32, but can only use those with FS-UAE :)
-
thanks for the updates Thomas & merry Christmas! will try on my 1200T mediator system over the holidays:hammer:
-
Many thanks for today 45.6 release :) Although I still have to use LoadResident for the KingCON - even with DOWNGRADE option it loads, but has totally no effect.
BTW. Do you have any plans regarding potential 68080.library for the Apollo Core?
-
Many thanks for today 45.6 release :) Although I still have to use LoadResident for the KingCON - even with DOWNGRADE option it loads, but has totally no effect.
As it seems, another bug.
[/SIZE]
BTW. Do you have any plans regarding potential 68080.library for the Apollo Core?
[/SIZE]
Well, in principle yes, though probably not in this year's Christmas break as I'm already booked for another fascinating project. I'm a bit short of development tools for it, short of a suitable hardware as well, and getting it through customs in Germany is still another hassle.
So let's put it like this: As soon as the product is mature, and there are sufficient development tools for it, it will be another interesting project.
What needs to be done is probably patching in a new exec scheduler, and probably adding some math support for it. How the math model of the chip will look like is still a bit unclear to me.
-
I also still need LoadResident for trackdisk.device (not that I really _need_ trackdisk.device, but for the sake of "argument", upgrading from 40.1 to 40.2). I didn't bring the CD32/SX32 with my on vacation, but have been playing with a disk image on FS-UAE to see what works.
(http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1385)
FailAt 21 - because LoadResident fails RC 20 when attempting to load trackdisk.device 40.2 when it is already present, and LoadModule >NIL: because it complains about trackdisk.device 40 already being present. DOWNGRADE for no good reason, other than without it, LoadModule will fail on the trackdisk.device issue and not reboot the system. I had hoped DOWNGRADE would allow me to drop LoadResident alltogether :)
-
The LoadModule 45.7 fixes my KingCON issue - it seems I can finally get rid of LoadResident. Thank you!
-
Sooo... any thoughts on how the new LoadModule "AUTO" switch can help clean up this mess? :lol:
(believe it or not, with the exception of exec.library being stuck on 45.20 resident and not wanting to take the 45.25 I've specified, this all works pretty well :) )
-
With the LoadModule 45.8, my SX32Pro no longer needs EXECTOCHIP flag, I suppose that is intentional? :)
Btw - when using LoadModule, what's with the funky kickstart version (http://www.amiga.org/forums/album.php?albumid=204&pictureid=1403)? :p
Thanks!
-
With the LoadModule 45.8, my SX32Pro no longer needs EXECTOCHIP flag, I suppose that is intentional? :)
That's absolutely intentional. I added a workaround for this expansion as apparently more than one person had a problem with it.
It is really specific to this particular piece of hardware LoadModule detects now - as said, it announces its capabilities incorrectly and for that reason made my day...
There is another problem this version works around, namely in the exec "ranger memory" detection that is unfortunately broken, even in the latest version of exec.
First, it checks too much (including checking the IDE registers for RAM, causing writes on I/O regions it should not write to) and second, it overwrites ranger memory without actually restoring the original values. Someone must have been drunk when coding this function.
So, ranger memory is actually not safe to use for resident modules. *Sigh*.
Btw - when using LoadModule, what's with the funky kickstart version (http://www.amiga.org/forums/album.php?albumid=204&pictureid=1403)? :p
That's just what is in exec. It looks to me as if there is some problem with the build process of AmigaOs I need to check. LoadModule itself does not touch version or revision numbers. Probably it is up to the final step of the kickstart ROM building process to fit in the revision, which is why you see this funky number. The "resident loader" of SetPatch comes with a particular patch for it, though it currently seems to be more like a problem from elsewhere, and I'd rather fix the problem at its source - though I need to learn more about it.