Sound configure test

On 3 Nov 2023 as I do recall,

Post by Jean-Michel
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

2023-11-04 18:25:11 UTC

Post by Harriet Bazley
On 3 Nov 2023 as I do recall,

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,

Post by Harriet Bazley
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

2023-11-08 01:00:18 UTC

On 4 Nov 2023 as I do recall,

Post by Harriet Bazley
On 3 Nov 2023 as I do recall,

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,

Post by Harriet Bazley
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

2023-11-08 15:32:19 UTC

Post by Jean-Michel
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

Jean-Michel

2023-11-09 09:23:12 UTC

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

Jean-Michel

2023-11-08 16:51:24 UTC

Post by Harriet Bazley
On 4 Nov 2023 as I do recall,

Post by Harriet Bazley
On 3 Nov 2023 as I do recall,

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,

Post by Harriet Bazley
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.

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

Richard Ashbery

2023-11-09 17:19:17 UTC

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

Hi Jean

Post by Jean-Michel
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

2023-11-10 08:53:44 UTC

Post by Richard Ashbery
Hi Jean

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

Post by Richard Ashbery
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...)

Post by Richard Ashbery
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...

Post by Richard Ashbery
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...

Post by Richard Ashbery
Regards
Richard

Feedback is a good thing.

--
Jean-Michel

Richard Ashbery

2023-11-10 16:10:53 UTC

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

[snip]

Post by 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?

Post by Jean-Michel
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 :-)

Post by Richard Ashbery
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

2023-11-10 20:12:47 UTC

Post by Richard Ashbery
[snip]

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.

Your English is better than you think :-)

Thanks.

Post by Richard Ashbery
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

Richard Ashbery

2023-11-11 13:37:36 UTC

Post by 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

!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

Jean-Michel

2023-11-11 15:09:36 UTC

Post by 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

!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

:-(

Post by Richard Ashbery
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.

Post by Richard Ashbery
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...

Post by Richard Ashbery
Richard

--
Jean-Michel

charles

2023-11-11 15:45:03 UTC

Post by 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

!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

:-(

Post by Richard Ashbery
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

Harriet Bazley

2023-11-10 22:02:19 UTC

On 10 Nov 2023 as I do recall,

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

2023-11-11 07:41:45 UTC

Post by Harriet Bazley
On 10 Nov 2023 as I do recall,

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

Richard Ashbery

2023-11-11 13:43:08 UTC

Post by 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

Chris Hughes

2023-11-11 14:04:41 UTC

Post by 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!

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

Richard Ashbery

2023-11-11 15:24:58 UTC

Post by Chris Hughes

Post by Richard Ashbery
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

2023-11-11 15:43:30 UTC

Post by Chris Hughes

Post by 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!

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

Post by Chris Hughes

Post by Richard Ashbery
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

Harriet Bazley

2023-11-11 15:59:39 UTC

On 11 Nov 2023 as I do recall,

Post by Chris Hughes
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

2023-11-11 18:04:31 UTC

Post by Harriet Bazley
On 11 Nov 2023 as I do recall,

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

2023-11-12 14:14:52 UTC

On 10 Nov, Harriet Bazley wrote in message

Post by Harriet Bazley
On 10 Nov 2023 as I do recall,

Post by Richard Ashbery
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

2023-11-12 15:47:24 UTC

Post by Steve Fryatt
On 10 Nov, Harriet Bazley wrote in message

Post by Richard Ashbery
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.

Post by Steve Fryatt
, 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.

Post by Steve Fryatt
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.

Post by Steve Fryatt
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

Jean-Michel

2023-11-13 08:34:08 UTC

Post by Steve Fryatt
On 10 Nov, Harriet Bazley wrote in message

Post by Richard Ashbery
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?

Post by Richard Ashbery
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.

Post by Steve Fryatt
, 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)

Post by Richard Ashbery
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.

Yes

Post by Richard Ashbery
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,

Post by Steve Fryatt
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.

Post by Steve Fryatt

Post by Harriet Bazley
Harriet
I did a full !Boot merge

seems like the right solution?

--
Jean-Michel

Steve Fryatt

2023-11-13 18:30:39 UTC

On 13 Nov, Jean-Michel wrote in message

Post by Steve Fryatt
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.

Post by Steve Fryatt
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/

Jean-Michel

2023-11-13 19:08:02 UTC

Post by Steve Fryatt
On 13 Nov, Jean-Michel wrote in message

Post by Steve Fryatt
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.

Post by Steve Fryatt

Post by Steve Fryatt
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.

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

--
Jean-Michel

Steve Fryatt

2023-11-13 23:35:34 UTC

On 13 Nov, Jean-Michel wrote in message

Post by Steve Fryatt
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/

Richard Ashbery

2023-11-14 12:34:29 UTC

Post by Steve Fryatt
On 13 Nov, Jean-Michel wrote in message

Post by Steve Fryatt
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

Steve Fryatt

2023-11-14 18:18:23 UTC

On 14 Nov, Richard Ashbery wrote in message

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/

Richard Ashbery

2023-11-15 19:26:28 UTC

Post by Steve Fryatt
On 14 Nov, Richard Ashbery wrote in message

Post by Richard Ashbery
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!!!

Post by Steve Fryatt
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 "|".

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

Makes perfect sense.

Post by Steve Fryatt

Post by Richard Ashbery
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

Harriet Bazley

2023-11-12 20:14:52 UTC