Hi,

I have an ARMX6 and I find that the audio level 5HDMI) at startup does
not match the one preset in SndSetup, it is always at maximum level!
Can you do the test with F12 then ctrlG for example .

Thanks a lot.

--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3 Nov 2023 as I do recall,
Jean-Michel wrote:

I have an ARMX6 and I find that the audio level 5HDMI) at startup does
not match the one preset in SndSetup, it is always at maximum level!
Can you do the test with F12 then ctrlG for example .

Do you mean the Sounds settings in !Boot Configure?

I have that set to 'loud beep' by default, but if I set it to 'quiet',
then do a Ctrl-G, the volume of that beep decreases too.

--
Harriet Bazley == Loyaulte me lie ==

Please all, and you will please none.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <565e0afe5a.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 3 Nov 2023 as I do recall,
Jean-Michel wrote:

I have an ARMX6 and I find that the audio level (HDMI) at startup does
not match the one preset in SndSetup, it is always at maximum level!
Can you do the test with F12 then ctrlG for example .

Do you mean the Sounds settings in !Boot Configure?

Yes,

I have that set to 'loud beep' by default, but if I set it to 'quiet',
then do a Ctrl-G, the volume of that beep decreases too.

Yes, but if you halve it and save this setup, then reboot, I think you
will still have the sound at maximum.
If after you use !Config the config level will be taken into account.

Thank you for testing.

--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4 Nov 2023 as I do recall,
Jean-Michel wrote:

In message <565e0afe5a.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 3 Nov 2023 as I do recall,
Jean-Michel wrote:

I have an ARMX6 and I find that the audio level (HDMI) at startup does
not match the one preset in SndSetup, it is always at maximum level!
Can you do the test with F12 then ctrlG for example .

Do you mean the Sounds settings in !Boot Configure?

Yes,

I have that set to 'loud beep' by default, but if I set it to 'quiet',
then do a Ctrl-G, the volume of that beep decreases too.

Yes, but if you halve it and save this setup, then reboot, I think you
will still have the sound at maximum.
If after you use !Config the config level will be taken into account.

If I set 'Quiet beep' in !Configure and reboot, I then get a quiet beep
when the computer restarts, as I would expect. And if I then look at
the Sounds settings again, the Quiet beep icon is still displayed as
selected. I have to manually change it back again to get the loud beep
to return.

--
Harriet Bazley == Loyaulte me lie ==

Mate, this parrot wouldn't VOOM if you put four million volts through it!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <98fdd7ff5a.harriet@bazleyfamily.co.uk>, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 4 Nov 2023 as I do recall, Jean-Michel wrote:

Yes, but if you halve it and save this setup, then reboot, I
think you will still have the sound at maximum. If after you use
!Config the config level will be taken into account.

If I set 'Quiet beep' in !Configure and reboot, I then get a quiet
beep when the computer restarts, as I would expect. And if I then
look at the Sounds settings again, the Quiet beep icon is still
displayed as selected. I have to manually change it back again to
get the loud beep to return.

Confirmed.

ARMX6 running RO5.29 (20-Nov-22)

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <98fdd7ff5a.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 4 Nov 2023 as I do recall,
Jean-Michel wrote:

In message <565e0afe5a.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 3 Nov 2023 as I do recall,
Jean-Michel wrote:

I have an ARMX6 and I find that the audio level (HDMI) at startup does >>>> not match the one preset in SndSetup, it is always at maximum level!
Can you do the test with F12 then ctrlG for example .

Do you mean the Sounds settings in !Boot Configure?

Yes,

I have that set to 'loud beep' by default, but if I set it to 'quiet',
then do a Ctrl-G, the volume of that beep decreases too.

Yes, but if you halve it and save this setup, then reboot, I think you
will still have the sound at maximum.
If after you use !Config the config level will be taken into account.

If I set 'Quiet beep' in !Configure and reboot, I then get a quiet beep
when the computer restarts, as I would expect. And if I then look at
the Sounds settings again, the Quiet beep icon is still displayed as selected. I have to manually change it back again to get the loud beep
to return.

Thanks for the test, in fact the problem occurs if we use HDMI audio.

A test to check the level as the OS sees it, (to be done at startup)

SYS "SoundCtrl_GetMix",0,0,0 TO,,,, mixvolume%
PRINT mixvolume%

I discovered this fault on my ARMX6 when I wanted to debug my utility and
I didn't understand why I had Beeps for errors which were not quiet at
all.
After a small modification of the HDMIauOn file the sndsetup chosen with !Configure.Sound is taken into account at startup.

To test the !MixVolume, which is very useful to me with Rhapsody, I
created this utility to listen to it, and be able to mute the internal
sound when I use a MIDI device.

https://jeanmichelb.riscos.fr/Audio.html#SonInteh


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b0027d33bbasura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <98fdd7ff5a.harriet@bazleyfamily.co.uk>, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 4 Nov 2023 as I do recall, Jean-Michel wrote:

Yes, but if you halve it and save this setup, then reboot, I
think you will still have the sound at maximum. If after you use
!Config the config level will be taken into account.

If I set 'Quiet beep' in !Configure and reboot, I then get a quiet
beep when the computer restarts, as I would expect. And if I then
look at the Sounds settings again, the Quiet beep icon is still
displayed as selected. I have to manually change it back again to
get the loud beep to return.

Confirmed.

ARMX6 running RO5.29 (20-Nov-22)
Richard

You are right but I don't know if you do the test in HDMI audio?
The problem should not exist in analog audio.


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <b8102f005b.jmb@jmc.bruck.orange.fr>, Jean-Michel

Hi Jean

To test the !MixVolume, which is very useful to me with Rhapsody, I
created this utility to listen to it, and be able to mute the
internal sound when I use a MIDI device.

https://jeanmichelb.riscos.fr/Audio.html#SonInteh

Just downloaded your !MixVolume utility which I've found very useful.
I see it's up to V0.04 but I have some issues with it.

1. Unable to display TaskWindow (Ctrl-F12) when main window is
opened.

2. Unable to move main window around desktop.

Functions 1 and 2 worked on V0.03.

3. Ideally if user tries to load another copy, MixVolume should trap
the request with a message "already loaded" or something similar but
both versions (0.03 and 0.04) display "abort on data transfer"
message.

ARMX6 running RO5.29 (20-Nov-22)

I also sent this reply to the armini-support mailing list but not sure
if you saw this.

Regards

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b00b5746fbasura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <b8102f005b.jmb@jmc.bruck.orange.fr>, Jean-Michel

Hi Jean

To test the !MixVolume, which is very useful to me with Rhapsody, I
created this utility to listen to it, and be able to mute the
internal sound when I use a MIDI device.

https://jeanmichelb.riscos.fr/Audio.html#SonInteh

Just downloaded your !MixVolume utility which I've found very useful.
I see it's up to V0.04 but I have some issues with it.

1. Unable to display TaskWindow (Ctrl-F12) when main window is
opened.

2. Unable to move main window around desktop.

Functions 1 and 2 worked on V0.03.

Thanks for the feedback,
I uploaded the corrected version, error in the Toolbox res file.

3. Ideally if user tries to load another copy, MixVolume should trap
the request with a message "already loaded" or something similar but
both versions (0.03 and 0.04) display "abort on data transfer"
message.

The program sends the message: Error at start up: MixVolume is already
running! (Maybe to change...)

but both versions (0.03 and 0.04) display "abort on data transfer"
ARMX6 running RO5.29 (20-Nov-22)

I discovered this problem some time ago (not with Mixvolume) and it comes
from the sharedlibrary module (v 6.15) of ARMX6 version 5.29

I asked ROOL to do a test and no problem because they use a newer version
of the module : v6.20
I advise you to upgrade to the new version available in Nightly Beta
HardDisk4, the module file is called CLib. https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is loaded at
startup and the message is displayed correctly !

In April, I reported it to Andrew with a small test program, but I think
he didn't see it...
If you can do the test with version 6.20 of the SharedLibrary and it works
for you, it would be good if you put a message on armini-support list in better English than mine...

I also sent this reply to the armini-support mailing list but not sure
if you saw this.

I checked this morning and I don't see your message...

Regards

Richard

Feedback is a good thing.


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

[snip]

I discovered this problem some time ago (not with Mixvolume) and it
comes from the sharedlibrary module (v 6.15) of ARMX6 version 5.29

I asked ROOL to do a test and no problem because they use a newer
version of the module : v6.20 I advise you to upgrade to the new
version available in Nightly Beta HardDisk4, the module file is
called CLib. https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is loaded at
startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though I've
placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and re-booted.
How do I get the system to run the latest CLib?

In April, I reported it to Andrew with a small test program, but I
think he didn't see it... If you can do the test with version 6.20
of the SharedLibrary and it works for you, it would be good if
you put a message on armini-support list in better English than
mine...

Your English is better than you think :-)

I also sent this reply to the armini-support mailing list but not
sure if you saw this.

I checked this morning and I don't see your message...

Sorry Jean-Michel I'm having problems posting to it so no can do at the
moment.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b01330765basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

[snip]

I discovered this problem some time ago (not with Mixvolume) and it
comes from the sharedlibrary module (v 6.15) of ARMX6 version 5.29

I asked ROOL to do a test and no problem because they use a newer
version of the module : v6.20 I advise you to upgrade to the new
version available in Nightly Beta HardDisk4, the module file is
called CLib. https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is loaded at
startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though I've
placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and re-booted.
How do I get the system to run the latest CLib?

Sorry I forgot, you have to modify the line in !System.!Run

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19 RMLoad

6.19 is a version that I tested which works, although 6.20 was available.

For this to work, you only need to have a number greater than 6.15, this
module becomes dormant and version 6.21 will replace it.

In April, I reported it to Andrew with a small test program, but I
think he didn't see it... If you can do the test with version 6.20
of the SharedLibrary and it works for you, it would be good if
you put a message on armini-support list in better English than
mine...

Your English is better than you think :-)

Thanks.

I also sent this reply to the armini-support mailing list but not
sure if you saw this.

I checked this morning and I don't see your message...

Sorry Jean-Michel I'm having problems posting to it so no can do at the moment.
Richard

No problem, you allowed me to fix the latest version of !MixVolume and I
think the question regarding SharedClib should interest people because
there is a bufg in version 6.15

Thanks






--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10 Nov 2023 as I do recall,
Richard Ashbery wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

I discovered this problem some time ago (not with Mixvolume) and it
comes from the sharedlibrary module (v 6.15) of ARMX6 version 5.29

I asked ROOL to do a test and no problem because they use a newer
version of the module : v6.20 I advise you to upgrade to the new
version available in Nightly Beta HardDisk4, the module file is
called CLib. https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is loaded at
startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though I've
placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and re-booted.
How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and ended
up with C Library 6.21 (09 Aug 2023).

I hope it didn't break anything else in !Boot that I don't know about!


--
Harriet Bazley == Loyaulte me lie ==

Let a fool hold his tongue and he will pass for a sage.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <dc3353015b.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 10 Nov 2023 as I do recall,
Richard Ashbery wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

I discovered this problem some time ago (not with Mixvolume) and it
comes from the sharedlibrary module (v 6.15) of ARMX6 version 5.29

I asked ROOL to do a test and no problem because they use a newer
version of the module : v6.20 I advise you to upgrade to the new
version available in Nightly Beta HardDisk4, the module file is
called CLib. https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is loaded at
startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though I've
placed the latest CLib (V6.21 9 Aug 2023) in
!Boot.Resources.!System.500.Modules as you suggested and re-booted.
How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and ended
up with C Library 6.21 (09 Aug 2023).

I hope it didn't break anything else in !Boot that I don't know about!

Regarding SharedClib no problems, I've been using it since April.
I only did this update.
Would it be good to ask on the armini.list?


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <dc3353015b.harriet@bazleyfamily.co.uk>, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 10 Nov 2023 as I do recall, Richard Ashbery wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

I discovered this problem some time ago (not with Mixvolume)
and it comes from the sharedlibrary module (v 6.15) of ARMX6
version 5.29

I asked ROOL to do a test and no problem because they use a
newer version of the module : v6.20 I advise you to upgrade to
the new version available in Nightly Beta HardDisk4, the module
file is called CLib.
https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is
loaded at startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
I've placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and
ended up with C Library 6.21 (09 Aug 2023).

I hope it didn't break anything else in !Boot that I don't know
about!

Please let us know if you do encounter problems. ARMX6 auto-updates
may have come to an end. Ideally we need a simple solution to do this ourselves. What other things apart from upgrading the !Boot program
are required - I'm thinking of the ROM upgrade?

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ee2c49015b.jmb@jmc.bruck.orange.fr>, Jean-Michel <jmc.bruck@orange.fr> wrote:

I discovered this problem some time ago (not with Mixvolume) and
it comes from the sharedlibrary module (v 6.15) of ARMX6 version
5.29

!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

Sorry I forgot, you have to modify the line in !System.!Run

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19 RMLoad

OK found it: Should be

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19
RMLoad System:Modules.CLib

As it happens the line was already there except the CLib, version
number was old (5.66). Simply editing to 6.19 ensured the latest copy
loaded.

Warning - editing !Sytem !Run file must be done with great care as one
false character will prevent computer booting correctly. Before
attempting anything like this always take a copy of the file or even
the whole of !Boot.

The best way is to do what Harriet did and perform a full !Boot merge.
Ensure you have a copy of the old !Boot program before updating.

Back to Jean-Michel MixVolume. With latest CLib the nasty "abort on data transfer" message has been replaced with a sensible message
"initialisation stopped - only 1 copy can be run" or words to that
effect. I suggest if user tries to load another copy then simply ignore
it - you really don't need a message. Most programs seem to follow this protocol.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b01a9559fbasura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <dc3353015b.harriet@bazleyfamily.co.uk>, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 10 Nov 2023 as I do recall, Richard Ashbery wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

I discovered this problem some time ago (not with Mixvolume)
and it comes from the sharedlibrary module (v 6.15) of ARMX6
version 5.29

I asked ROOL to do a test and no problem because they use a
newer version of the module : v6.20 I advise you to upgrade to
the new version available in Nightly Beta HardDisk4, the module
file is called CLib.
https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is
loaded at startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
I've placed the latest CLib (V6.21 9 Aug 2023) in
!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and
ended up with C Library 6.21 (09 Aug 2023).

I hope it didn't break anything else in !Boot that I don't know
about!

Please let us know if you do encounter problems. ARMX6 auto-updates
may have come to an end. Ideally we need a simple solution to do this ourselves. What other things apart from upgrading the !Boot program
are required - I'm thinking of the ROM upgrade?

What makes you think auto-updates have ended for the ARMX6 ?

Andrew is awaiting the release of 5.30 before issuing a new auto-update I understood. 5.30 is taking a rather long time to be fully released it
seems - lots more testing/fixing being done this time round - which can
only be good in long run.



--
Chris Hughes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b01a8d3d1basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <ee2c49015b.jmb@jmc.bruck.orange.fr>, Jean-Michel <jmc.bruck@orange.fr> wrote:

I discovered this problem some time ago (not with Mixvolume) and
it comes from the sharedlibrary module (v 6.15) of ARMX6 version
5.29

!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

Sorry I forgot, you have to modify the line in !System.!Run

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19 RMLoad

OK found it: Should be

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19
RMLoad System:Modules.CLib

As it happens the line was already there except the CLib, version
number was old (5.66). Simply editing to 6.19 ensured the latest copy
loaded.

Warning - editing !Sytem !Run file must be done with great care as one
false character will prevent computer booting correctly. Before
attempting anything like this always take a copy of the file or even
the whole of !Boot.

:-(

The best way is to do what Harriet did and perform a full !Boot merge.
Ensure you have a copy of the old !Boot program before updating.

Harriet gave the correct method, in April I was looking for the source of
the error and it was this module.
In fact I was waiting for the green light from Andrew... he must have been
very busy.

Back to Jean-Michel MixVolume. With latest CLib the nasty "abort on data transfer" message has been replaced with a sensible message
"initialisation stopped - only 1 copy can be run" or words to that
effect. I suggest if user tries to load another copy then simply ignore
it - you really don't need a message. Most programs seem to follow this protocol.

Good idea, I will modify the program and update it.
I'm going to re-read the Style guide manual...

Richard

--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <984fab015b.chris@mytardis>, Chris Hughes

Please let us know if you do encounter problems. ARMX6
auto-updates may have come to an end. Ideally we need a simple
solution to do this ourselves. What other things apart from
upgrading the !Boot program are required - I'm thinking of the
ROM upgrade?

What makes you think auto-updates have ended for the ARMX6 ?

Andrew is awaiting the release of 5.30 before issuing a new
auto-update I understood. 5.30 is taking a rather long time to be
fully released it seems - lots more testing/fixing being done this
time round - which can only be good in long run.

That's excellent news - the impression I got was that due to the age
of the machine no further release were likely - obviously I
misunderstood the posting.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11 Nov 2023 as I do recall,
Chris Hughes wrote:

What makes you think auto-updates have ended for the ARMX6 ?

Andrew is awaiting the release of 5.30 before issuing a new auto-update I understood. 5.30 is taking a rather long time to be fully released it
seems - lots more testing/fixing being done this time round - which can
only be good in long run.

I wasn't aware that there were any auto-updates!

--
Harriet Bazley == Loyaulte me lie ==

We will release no software before its time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <dd40b1015b.jmb@jmc.bruck.orange.fr>,
Jean-Michel <jmc.bruck@orange.fr> wrote:

In message <5b01a8d3d1basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <ee2c49015b.jmb@jmc.bruck.orange.fr>, Jean-Michel <jmc.bruck@orange.fr> wrote:

I discovered this problem some time ago (not with Mixvolume) and
it comes from the sharedlibrary module (v 6.15) of ARMX6 version
5.29

!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

Sorry I forgot, you have to modify the line in !System.!Run

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19 RMLoad

OK found it: Should be

If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19
RMLoad System:Modules.CLib

As it happens the line was already there except the CLib, version
number was old (5.66). Simply editing to 6.19 ensured the latest copy loaded.

Warning - editing !Sytem !Run file must be done with great care as one false character will prevent computer booting correctly. Before
attempting anything like this always take a copy of the file or even
the whole of !Boot.

:-(

The best way is to do what Harriet did and perform a full !Boot merge. Ensure you have a copy of the old !Boot program before updating.

Harriet gave the correct method, in April I was looking for the source of
the error and it was this module. In fact I was waiting for the green
light from Andrew... he must have been very busy.

He posted yesterday that his father has been in hospital and he'd been
unable to concentrate on RISCOS matters

--
from KT24 in Surrey, England - sent from my RISC OS 4té²
"I'd rather die of exhaustion than die of boredom" Thomas Carlyle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <984fab015b.chris@mytardis>
Chris Hughes <news13@noonehere.co.uk> wrote:

In message <5b01a9559fbasura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <dc3353015b.harriet@bazleyfamily.co.uk>, Harriet Bazley
<harriet@bazleyfamily.co.uk> wrote:

On 10 Nov 2023 as I do recall, Richard Ashbery wrote:

In article <6e010b015b.jmb@jmc.bruck.orange.fr>, Jean-Michel

I discovered this problem some time ago (not with Mixvolume)
and it comes from the sharedlibrary module (v 6.15) of ARMX6
version 5.29

I asked ROOL to do a test and no problem because they use a
newer version of the module : v6.20 I advise you to upgrade to
the new version available in Nightly Beta HardDisk4, the module
file is called CLib.
https://www.riscosopen.org/content/downloads/common

I copied the file to Boot:Resources.!System.500 and it is
loaded at startup and the message is displayed correctly !

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
I've placed the latest CLib (V6.21 9 Aug 2023) in
!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and
ended up with C Library 6.21 (09 Aug 2023).

I hope it didn't break anything else in !Boot that I don't know
about!

Please let us know if you do encounter problems. ARMX6 auto-updates
may have come to an end. Ideally we need a simple solution to do this
ourselves. What other things apart from upgrading the !Boot program
are required - I'm thinking of the ROM upgrade?

What makes you think auto-updates have ended for the ARMX6 ?

Andrew is awaiting the release of 5.30 before issuing a new auto-update I understood. 5.30 is taking a rather long time to be fully released it
seems - lots more testing/fixing being done this time round - which can
only be good in long run.

The SharedCLibrary 6.15 module did have a bug which has been corrected. So
this update was necessary.
Harriet did a full update and it works fine, I think.

There is a log file for updates, fortunately, I made a big mistake, I have downloaded the 26 bits version:-(
From ROOL

You could check the merge log in !System.Log to see if that gives you any >>clues as to what was changed.

MixVolume has been updated and uploaded.

https://jeanmichelb.riscos.fr/Audio.html#SonInteh

The error message is especially important when building the program.

Thanks for feedback.

--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <f0d5b5015b.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 11 Nov 2023 as I do recall,
Chris Hughes wrote:

What makes you think auto-updates have ended for the ARMX6 ?

Andrew is awaiting the release of 5.30 before issuing a new auto-update I
understood. 5.30 is taking a rather long time to be fully released it
seems - lots more testing/fixing being done this time round - which can
only be good in long run.

I wasn't aware that there were any auto-updates!

Richard meant, the Super Packs and the ROM update packages that R-Comp do
at intervals.

--
Chris Hughes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10 Nov, Harriet Bazley wrote in message
<dc3353015b.harriet@bazleyfamily.co.uk>:

On 10 Nov 2023 as I do recall,
Richard Ashbery wrote:

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though I've
placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and re-booted. How
do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time, and ended
up with C Library 6.21 (09 Aug 2023).

The SCL has to be loaded very early on in the Boot sequence, as soft-loading
it "on demand" by applications is dangerous: it will work once, but the
second application to try it in a session will stiff the machine.

As a result, applications must never soft-load a new SCL from !System. All
they can do is test the active version and refuse to run if it isn't new
enough for them. This prompts the user to install an updated version into !Boot, which includes lines called early from !Boot.!Run[1] to soft-load the module for the whole session[2].


1. I'd have to fire up a RISC OS box to check where, exactly.

2. Although anything in the ROM will still use the ROM version of the SCL.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

On 10 Nov, Harriet Bazley wrote in message
<dc3353015b.harriet@bazleyfamily.co.uk>:

On 10 Nov 2023 as I do recall, Richard Ashbery wrote:

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
I've placed the latest CLib (V6.21 9 Aug 2023) in !Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time,
and ended up with C Library 6.21 (09 Aug 2023).

The SCL has to be loaded very early on in the Boot sequence

Ahh! that's why the SCL line is high up in the !Run file order. I didn't
notice this when I first opened !System.!Run file.

, as
soft-loading it "on demand" by applications is dangerous: it will
work once, but the second application to try it in a session will
stiff the machine.

When I added another SCL line it didn't stiff the machine but failed to
boot returning me to the black 'command line' screen hence why I put out
a warning about modifying !Run files in !Boot.

As a result, applications must never soft-load a new SCL from
!System. All they can do is test the active version and refuse to
run if it isn't new enough for them. This prompts the user to
install an updated version into !Boot, which includes lines called
early from !Boot.!Run[1] to soft-load the module for the whole
session[2].

But it's OK to replace old SCL module with latest version in !System.500.Modules and then edit the SCL line at the top of the
!System.!Run file (change 5.66 to 6.19) to force it to run?
Jean-Michel's instructions were confusing but I think that's what he
intended. Doing this now runs SCL, V6.21.

1. I'd have to fire up a RISC OS box to check where, exactly.

2. Although anything in the ROM will still use the ROM version of
the SCL.

This not my experience. Excuse me Steve if I'm misunderstanding this
process.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12 Nov 2023 as I do recall,
Steve Fryatt wrote:

[snip]

The SCL has to be loaded very early on in the Boot sequence, as soft-loading it "on demand" by applications is dangerous: it will work once, but the second application to try it in a session will stiff the machine.

As a result, applications must never soft-load a new SCL from !System. All they can do is test the active version and refuse to run if it isn't new enough for them. This prompts the user to install an updated version into !Boot, which includes lines called early from !Boot.!Run[1] to soft-load the module for the whole session[2].

1. I'd have to fire up a RISC OS box to check where, exactly.

| !Boot.!Run
| Version 1.36 (20-Feb-23)
RMEnsure UtilityModule 3.10 Error This !Boot structure is only suitable for RISC OS 3.10 or later

Set Boot$Dir <Obey$Dir>
Set Boot$Path <Boot$Dir>.
Run <Boot$Dir>.Resources.!System
RMEnsure SharedCLibrary 5.43 Error This !Boot structure requires SharedCLibrary version 5.43 or later

/<Boot$Dir>.Utils.BootVars
If "<Boot$State>" <> "desktop" then Obey -c <Boot$Dir>.Utils.BootRun else Obey -c <Boot$Dir>.Utils.DeskRun


--
Harriet Bazley == Loyaulte me lie ==

Cloning is the sincerest form of flattery.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5b02388c57basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

On 10 Nov, Harriet Bazley wrote in message
<dc3353015b.harriet@bazleyfamily.co.uk>:

On 10 Nov 2023 as I do recall, Richard Ashbery wrote:

Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
I've placed the latest CLib (V6.21 9 Aug 2023) in
!Boot.Resources.!System.500.Modules as you suggested and
re-booted. How do I get the system to run the latest CLib?

I did a full !Boot merge, as I hadn't done one in a long time,
and ended up with C Library 6.21 (09 Aug 2023).

The SCL has to be loaded very early on in the Boot sequence

I think it's one of !Sysmerge's roles to make sure that's the case?

Ahh! that's why the SCL line is high up in the !Run file order. I didn't notice this when I first opened !System.!Run file.

, as
soft-loading it "on demand" by applications is dangerous: it will
work once, but the second application to try it in a session will
stiff the machine.

But luckily RISC OS is in ROM, I made the mistake by updating with the
wrong one !System:-( (26 bits version)

When I added another SCL line it didn't stiff the machine but failed to
boot returning me to the black 'command line' screen hence why I put out
a warning about modifying !Run files in !Boot.

As a result, applications must never soft-load a new SCL from
!System. All they can do is test the active version and refuse to
run if it isn't new enough for them. This prompts the user to
install an updated version into !Boot, which includes lines called
early from !Boot.!Run[1] to soft-load the module for the whole
session[2].

Yes

But it's OK to replace old SCL module with latest version in !System.500.Modules and then edit the SCL line at the top of the
!System.!Run file (change 5.66 to 6.19) to force it to run?
Jean-Michel's instructions were confusing but I think that's what he intended. Doing this now runs SCL, V6.21.

Sorry,

1. I'd have to fire up a RISC OS box to check where, exactly.

2. Although anything in the ROM will still use the ROM version of
the SCL.

This not my experience. Excuse me Steve if I'm misunderstanding this
process.

Me too.

Harriet
I did a full !Boot merge

seems like the right solution?


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:

On 13 Nov, Jean-Michel wrote in message
<17b894025b.jmb@jmc.bruck.orange.fr>:

In message <5b02388c57basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

The SCL has to be loaded very early on in the Boot sequence

I think it's one of !Sysmerge's roles to make sure that's the case?

It is, but Richard didn't use SysMerge as far as I can make out.

I did this and it's not good advice. I wanted to know if it was just the
SCL that was causing an error and I didn't think to update everything.

2. Although anything in the ROM will still use the ROM version of the
SCL.

This not my experience. Excuse me Steve if I'm misunderstanding this
process.

Me too.

AFAIK, ROM components are hard-linked to the ROM SCL as part of the process of building the ROM. This is completely different to the process used by applications loaded into RAM, which populate the stubs' jump table when they initialise. As such, there's no mechanism for ROM components to see a soft-loaded version of the SCL and link to it.

Thank you for this information.
Version 6.15 is dormant. Is the SWI call made on the softloaded version?


--
Jean-Michel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13 Nov, Jean-Michel wrote in message
<17b894025b.jmb@jmc.bruck.orange.fr>:

In message <5b02388c57basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

The SCL has to be loaded very early on in the Boot sequence

I think it's one of !Sysmerge's roles to make sure that's the case?

It is, but Richard didn't use SysMerge as far as I can make out.

2. Although anything in the ROM will still use the ROM version of the SCL.

This not my experience. Excuse me Steve if I'm misunderstanding this process.

Me too.

AFAIK, ROM components are hard-linked to the ROM SCL as part of the process
of building the ROM. This is completely different to the process used by applications loaded into RAM, which populate the stubs' jump table when they initialise. As such, there's no mechanism for ROM components to see a soft-loaded version of the SCL and link to it.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13 Nov, Jean-Michel wrote in message
<46c1ce025b.jmb@jmc.bruck.orange.fr>:

In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:

AFAIK, ROM components are hard-linked to the ROM SCL as part of the
process of building the ROM. This is completely different to the process used by applications loaded into RAM, which populate the stubs' jump
table when they initialise. As such, there's no mechanism for ROM components to see a soft-loaded version of the SCL and link to it.

Thank you for this information. Version 6.15 is dormant. Is the SWI call
made on the softloaded version?

The SWI calls, made by RAM-loaded applications and modules, will be made to
the version of the module which is currently active at the time when the
call is made. If the ROM version is dormant, then that will be the
soft-loaded version in RAM.

Anything which called the SWI before the soft-load occurred will link to the ROM version of the module, and remain linked to that version after the soft-load.

The same is true of additional soft-loads. If you soft-load a new version of the module, load an application which calls the SWI to link up the stubs,
then soft-load a second, newer version of the module, that application will remain linked to the *first* version which was soft-loaded. Even though the system will have killed that version off and freed up the RMA space that it
was occupying. This won't be noticed until that free space gets allocated to
a new module or workspace, however, and the library routines get overwritten with other data.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <mpro.s435j502jos4k04sw.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

On 13 Nov, Jean-Michel wrote in message
<46c1ce025b.jmb@jmc.bruck.orange.fr>:

In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk> Steve
Fryatt <news@stevefryatt.org.uk> wrote:

AFAIK, ROM components are hard-linked to the ROM SCL as part of
the process of building the ROM. This is completely different
to the process used by applications loaded into RAM, which
populate the stubs' jump table when they initialise. As such,
there's no mechanism for ROM components to see a soft-loaded
version of the SCL and link to it.

Thank you for this information. Version 6.15 is dormant. Is the
SWI call made on the softloaded version?

The SWI calls, made by RAM-loaded applications and modules, will be
made to the version of the module which is currently active at the
time when the call is made. If the ROM version is dormant, then
that will be the soft-loaded version in RAM.

Anything which called the SWI before the soft-load occurred will
link to the ROM version of the module, and remain linked to that
version after the soft-load.

The same is true of additional soft-loads. If you soft-load a new
version of the module, load an application which calls the SWI to
link up the stubs, then soft-load a second, newer version of the
module, that application will remain linked to the *first* version
which was soft-loaded. Even though the system will have killed that
version off and freed up the RMA space that it was occupying. This
won't be noticed until that free space gets allocated to a new
module or workspace, however, and the library routines get
overwritten with other data.

So Steve from what your saying the way I've updated the SharedCLibrary
is a seriously bad way to do it. Even though it all appears to be
working it may impact on other software that uses that module.

If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do I
have to also update the ROM image?

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14 Nov, Richard Ashbery wrote in message
<5b032e8ee8basura@invalid.addr.uk>:

So Steve from what your saying the way I've updated the SharedCLibrary is
a seriously bad way to do it. Even though it all appears to be working it
may impact on other software that uses that module.

I thought that you had somehow hacked it into !Boot.!Run, so that it was
loaded at startup? That's what the normal soft-load does, so it's probably fine; the problems could come when you try to upgrade again, if you've put different lines into the !Run file.

The requirement is to load the latest version possible, as early as
possible: before anything tries to link to it.

If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do I have
to also update the ROM image?

It's probably wise to keep them mostly in step. However, if it's an R-Comp system, I'm not going to advise further.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <mpro.s44lii00ijhl803c5.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:

On 14 Nov, Richard Ashbery wrote in message
<5b032e8ee8basura@invalid.addr.uk>:

So Steve from what your saying the way I've updated the
SharedCLibrary is a seriously bad way to do it. Even though it
all appears to be working it may impact on other software that
uses that module.

I thought that you had somehow hacked it into !Boot.!Run, so that
it was loaded at startup?

I'm not that clever!!!

That's what the normal soft-load does, so
it's probably fine; the problems could come when you try to upgrade
again, if you've put different lines into the !Run file.

That's a point - I never delete any lines in !Boot obeyfiles but
always prefix the unwanted line with a "|".

The requirement is to load the latest version possible, as early as
possible: before anything tries to link to it.

Makes perfect sense.

If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do
I have to also update the ROM image?

It's probably wise to keep them mostly in step. However, if it's an
R-Comp system, I'm not going to advise further.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)