Re: [ARMini-support] SysMerge, AMPlayer

  • From: Jan-Jaap van der Geer <jjvdgeer@xxxxxxxxx>
  • To: armini-support@xxxxxxxxxxxxx
  • Date: Tue, 10 Nov 2015 21:09:36 +0100

Ewen Pring <ewen.pring@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Jan-Jaap van der Geer <jjvdgeer@xxxxxxxxx> wrote on 5 Nov 2015:

I checked the copy on the SD-card, and it seems this is how the
!System dir looks by default on the ARMX6, with a AMPlayer both
in the 350 and 500 directories.

The disc image should not have had Amplayer modules in both the
500 and 350 directories. The super pack 4 for ARMX6 does not
have them in the 500 directory so I guess the problem is
corrected for the future. Not sure how they got to be there in
the first place (my Armini had the same thing).

Looking at my backup from how I received my ArmX6, it seems the
original release had a 1.39 build in januar 2002 in the 350
directory and a 1.39 build in december 2002 in the 500 directory.

So my guess is that 1.39 in the 350 dir wasn't 32-bit compatible,
while the other one was. But that version would probably have been
fine for 26-bit as well, I guess, so it maybe should have been the
one in the 350 directory, but that's just guesswork.

But as the latest version is compatible with all versions, as you
say, it should be in the 350 directory with nothing AMPlayer
related in the 500 directory.

It seems to me this behaviour might have deleted a 32-bit
version of some stuff and retains an incompatible 26-bit
version. And this might now actually be the situation with
AMPlayer... But I'm not sure.

I don't think so; the system merge utility has kept the latest
version 1.40 and in the correct place (350) as can be seen from
the latest download at the official distribution

Indeed. I got confused because the .Modules.Audio.MP3.AMPlayer_
file has a version number of 0.00 or 0.01 depending on which
directory you check. But I just coincidentally bumped into the
announcement of AMPlayer 1.40 and checked the file, and you're
right, System Merge cleaned up the problem :)

I wonder why R-Comp's super pack doesn't instruct the user to run
the !boot merge utility (which also invokes the !system merge
utility for modules) to copy over new stuff. Instead it tells
you to just copy !boot manually over the root of your hard disc
along with everything else. This means the internal boot and
system log files don't get updated, making it harder to fault
find in future. It also means problems/conflicts like you
discovered may not be found out until the next time the user
runs a merge utility for some other reason. I upgraded an ARMX6
yesterday to SP4 using RISC OS' !boot merge utility, and it went

Agreed. I think it is because it is like this to keep the
instructions simple. That may be a valid point, but I think I will
go the !Boot merge utility in the future as well.

Maybe they should consider making the whole installation in an
Obey-file and not the drag-and-drop method. After all, the
remove part already is an Obey-file that has to be run.

It seems the Boot Merge and System Merge stuff is implemented in
the Installer module as well, so it should be possible to do that.
Pity Install_Update does not support sending in a directory, than
would make creating a script for the upgrade a lot easier.

To alter your preferences or leave the group,
visit //
List-related queries to info@xxxxxxxxxxxx

Other related posts: