MuTools and more updated to V46

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

[kolla]

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.

[kolla]

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)
=======================================================================

[guest11527]

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.

[kolla]

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

[klx300r]

thanks for the updates Thomas & merry Christmas! will try on my 1200T mediator system over the holidays:hammer:

[Romanujan]

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?

[guest11527]

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.

[kolla]

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.



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

[Romanujan]

The LoadModule 45.7 fixes my KingCON issue - it seems I can finally get rid of LoadResident. Thank you!

[Oldsmobile_Mike]

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 )

[kolla]

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? :p

Thanks!

[guest11527]

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? :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.