Sound configure test

[Jean-Michel]

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

[Harriet Bazley]

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.

[Jean-Michel]

In message <565e0afe5...@bazleyfamily.co.uk>

Harriet Bazley <har...@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

[Harriet Bazley]

On 4 Nov 2023 as I do recall,

Jean-Michel wrote:

> In message <565e0afe5...@bazleyfamily.co.uk>
> Harriet Bazley <har...@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!

[Richard Ashbery]

In article <98fdd7ff5...@bazleyfamily.co.uk>, Harriet Bazley

Confirmed.

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

Richard

[Jean-Michel]

In message <98fdd7ff5...@bazleyfamily.co.uk>

Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

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

>> In message <565e0afe5...@bazleyfamily.co.uk>
>> Harriet Bazley <har...@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

[Jean-Michel]

In message <5b0027d3...@invalid.addr.uk>

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

[Richard Ashbery]

In article <b8102f0...@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

[Jean-Michel]

In message <5b00b574...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> In article <b8102f0...@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

[Richard Ashbery]

In article <6e010b0...@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

[Jean-Michel]

In message <5b013307...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> In article <6e010b0...@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

[Harriet Bazley]

On 10 Nov 2023 as I do recall,

Richard Ashbery wrote:

> In article <6e010b0...@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.

[Jean-Michel]

In message <dc3353015...@bazleyfamily.co.uk>

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

[Richard Ashbery]

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

<jmc....@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

[Richard Ashbery]

In article <dc3353015...@bazleyfamily.co.uk>, Harriet Bazley

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

[Chris Hughes]

In message <5b01a955...@invalid.addr.uk>

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

[Jean-Michel]

In message <5b01a8d3...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> In article <ee2c490...@jmc.bruck.orange.fr>, Jean-Michel
> <jmc....@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

[Richard Ashbery]

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

[Jean-Michel]

In message <984fab015b.chris@mytardis>

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

[charles]

In article <dd40b10...@jmc.bruck.orange.fr>,

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

[Harriet Bazley]

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.

[Chris Hughes]

In message <f0d5b5015...@bazleyfamily.co.uk>

Harriet Bazley <har...@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

[Steve Fryatt]

On 10 Nov, Harriet Bazley wrote in message
<dc3353015...@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/

[Richard Ashbery]

In article <mpro.s40kwn03...@stevefryatt.org.uk>, Steve

Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 10 Nov, Harriet Bazley wrote in message
> <dc3353015...@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

[Harriet Bazley]

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.

[Jean-Michel]

In message <5b02388c...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> In article <mpro.s40kwn03...@stevefryatt.org.uk>, Steve
> Fryatt <ne...@stevefryatt.org.uk> wrote:
>> On 10 Nov, Harriet Bazley wrote in message
>> <dc3353015...@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

[Steve Fryatt]

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

> In message <5b02388c...@invalid.addr.uk>
> Richard Ashbery <bas...@invalid.addr.uk> wrote:
>
> > In article <mpro.s40kwn03...@stevefryatt.org.uk>, Steve
> > Fryatt <ne...@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.

[Jean-Michel]

In message <mpro.s42rey00...@stevefryatt.org.uk>

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

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

>> In message <5b02388c...@invalid.addr.uk>
>> Richard Ashbery <bas...@invalid.addr.uk> wrote:
>>
>>> In article <mpro.s40kwn03...@stevefryatt.org.uk>, Steve
>>> Fryatt <ne...@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

[Steve Fryatt]

On 13 Nov, Jean-Michel wrote in message

<46c1ce0...@jmc.bruck.orange.fr>:

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.

[Richard Ashbery]

In article <mpro.s435j502...@stevefryatt.org.uk>, Steve

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

[Steve Fryatt]

On 14 Nov, Richard Ashbery wrote in message
<5b032e8e...@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.

[Richard Ashbery]

In article <mpro.s44lii00...@stevefryatt.org.uk>, Steve

Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 14 Nov, Richard Ashbery wrote in message
> <5b032e8e...@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