RO 5.20 upgrade for Iyonix

My (easy) option at the moment is to stick with RISC OS 5.16 on the Iyonix until this issue is sorted out (as I’m sure it will be). I don’t need 5.20 desperately on the Iyonix. Once 5.22 is around for the Pandaboard I’ll probably mothball the Iyonix.

My plan is to install 5.20 on my Kinetic first. (Assuming I can find it)

Keeps giving error messages to say that Such-and-Such program needs Such-and-Such module (Can’t be more specific at the mo)

This is a bit more specific. Each application was tried using Aemulor 232 on 5.18 using my normal !Boot, then with a vanilla !Boot downloaded from ROOL, then on 5.20. These are the results:

DiagramIt – undefined instruction at &00008010
Citation – undefined instruction at &00008010
Fireworkz Pro (26bit)- undefined instruction at &00008614
Photodesk (26bit)- undefined instruction at &0001F080
Fontasy – undefined instruction at &00008620
DasPicture – undefined instruction at &0006BA38
Vector (26bit) – Utility module ‘VectorUtil’ not found or too old
Eureka – you need EurekaUtils(EurUtils) version 0.02 or later
TableMate – ‘System:Modules.ImageConv’ not found

Unfortunately, this may not be the case, since Aemulor has also stopped working on my Iyonix with 5.18.

I’ve had a little fiddle around, and had some success.
I thought I’d re-flash 5.16 to see if that helped Aemulor. To my surprise, it didn’t. NO 26bit application worked, tho’ they had in 2010 and 2011(See my earlier post for which applications I was testing).
I then decided to remove Aemulor completely from the machine (including !Boot.choices), re-booted and re-installed it from my original download.zip. Dragging the applications to the Aemulor icon-bar icon then caused them all to load, except TableMate and Eureka, which still complained of missing modules, namely ImageConv and EurUtils. These I located on the original application discs, and placed them in !System.310.Modules. This caused TableMate and Eureka to load, and work properly. (Don’t understand why. They were never previously needed with Aemulor on the Iyonix, and are not needed with it on the Bb xM)
I then flashed 5.18 and everything continued to work, with the exception of DiagramIt, which still failed with an ‘undefined instruction at &00008010’. This situation is now better than it has been for at least the last couple of months (Which was when I first noticed that Aemulor wasn’t working).
Unfortunately, soft loading 5.21 then caused everything to fail with an ‘abort on data transfer’, with the exception of !Picture which worked fine.
Hope this helps.

Negative experiences so far on Iyonix with 5.20 softload with updated !Boot sequence:
1. “Error: File ‘Report’ not found.” Use of *Desktop did not complete properly, so removed all traces of Reporter. Reporter re-installed; looks OK. Now boots to desktop in mode 28.
2. Some error messages during boot still to be investigated (e.g. “File ‘Obey2’ not found.”)
3. Configure→Display allows Try to correct display, but Set does not cause proper setting to be stored.
4. QFiler needed to be re-installed (for latest version of Filer).
5. Simiar problem as others with apps under Aemulor. Aemulor produced a dump log for Impression Style which could be useful to Adrian Lees.
6. With Eureka, however, Aemulor just says “Prog. is 26 bit” and does nothing.
Otherwise most things appear normal…

Negative experiences so far on Iyonix with 5.20 softload with updated !Boot sequence:
1. “Error: File ‘Report’ not found.” Use of *Desktop did not complete properly, so removed all traces of Reporter. Reporter re-installed; looks OK. Now boots to desktop in mode 28.

My experience is that the alterations of !Boot produced by !Reporter do tend to make the system rather fragile even in normal circumstances.
Probably best to include a “remove all traces of Reporter from the Boot” instruction in the upgrade details.

3. Configure→Display allows Try to correct display, but Set does not cause proper setting to be stored.

Is this related to the frequent problems people have had with the system commenting out the display setting line? “LoadModeFile …” in PreDesk.Configure.Monitor IIRC
Same little niggling bug perhaps?

1. “Error: File ‘Report’ not found.” Use of *Desktop did not complete properly, so removed all traces of Reporter. Reporter re-installed; looks OK. Now boots to desktop in mode 28.

My experience is that the alterations of !Boot produced by !Reporter do tend to make the system rather fragile even in normal circumstances.
Probably best to include a “remove all traces of Reporter from the Boot” instruction in the upgrade details.

This is not caused by Reporter as such if the ROOL instructions are followed. It is caused by a combination of
(a) removing !Reporter from its normal position (wherever it was installed).
(b) copying something from the old !Boot that includes some Reporter commands.
AND having Reporter set to start at Boot.

If neither (a) or (b), or only one is done, all should be well.

I do try to explain how Reporter is started at Boot in the documentation, and to explain the consequences of changes which affect it.

But if in ANY doubt, when messing with !Reporter or !Boot, it may be best to remove Reporter from !Boot first.

The Mode 28 is nothing to do with Reporter!

Thank you Martin. I’m sorry if I made it sound as if Reporter was at fault, when it was probably just my haste in trying 5.20 with less than due care. However, I now find that Reporter’s latest boot log has almost 1,900 occurrences of this quatrain:

  Error  : &00000000
  Message: You may now keep the new settings, or discard them in favour of the old ones.
18:08:04.97 [Appl/Screen configuration] Exec
18:08:04.97 ** WimpError ** from Screen configuration

The good log contains three occurrences of this sequence:

18:08:37.69 [Appl/Screen configuration] LoadModeFile BootResources:Configure.Monitors.Acer.Acer-AL2416W
18:08:37.70 [Appl/Screen configuration] IconSprites BootResources:Configure.Monitors.Acer.!Sprites
File 'BootResources:Configure.Monitors.Acer.!Sprites' not found

Something that surprised me last night: in the network configuration, if you set the IP address by host name, the host name comparison is case sensitive. The entry in my hosts file was “iyonix”. Putting “Iyonix” in the hostname window failed to find a match; editing it to “iyonix” made it work.

I thought hostname comparisons with the hosts file were always case insensitive?

Bernard

How did you upgrade your !Boot sequence was it via merge or complete new copy of !Boot and if the later did you boot in to RISC OS first and set up the basics like screen settings/network etc before starting to add old Choices back in and adding new 5.20 softload

If you merged then this could be the source of your issue and I would start from a fresh copy of !Boot for 5.20.

As the ROOL setup instructions say take one step at a time and prove things work.

I thought hostname comparisons with the hosts file were always case insensitive?

http://technet.microsoft.com/en-us/library/cc958812.aspx

Two thirds down the page: “Entries can be case sensitive depending on the platform. Entries in the Hosts file for UNIX computers are case sensitive. Entries in the Hosts file for Windows 2000 and Windows NT–based computers are not case sensitive.”

Inherited with the recent update from the x-based sources I think.

Thanks Doug. Yes, I made backup copies of !Boot then merged the new !Boot following some advice I’d read (obviously not ROOL’s official advice!). Previous ROM upgrades have gone smoothly, but this time there’s more to change, so I’m very grateful for the softload option.

I will now do as you suggest and start vanilla, adding fruit and flavours one by cautious one.

I think the best way to get that resolved is to contact Adrian Lees and see if he’s able to determine what’s going on in your setup.

Actually it is not my setup. I have tried this with a completely vanilla !Boot and 5.20 and still get the abort. Aemulor Pro 2.32 will not work on an Iyonix with RISC OS 5.20 (despite a post to the contrary on csa.apps).

In case this is to do with the Shared C Library, I am trying the following:
unplug sharedclibrary
place a revised sharedclibrary saved from 5.16 or 5.18 in place of CLib inside System.500.Modules and boot up with the older library.

Now I am finding that RMREINIT SharedCLibrary does not undo the effect of unplugging it.

Will post later when I’ve had a cup of tea…

rminsert

edit: I should add unpluging the shared c library may cause havoc with restarting

Ah! Need to change !Boot.Resources.!System.!Run to RMEnsure SharedCLibrary 5.56 – there is a typo where it RMEnsures 5.66 whereas only 5.56 is in RISC OS 5.16

edit: I should add unpluging the shared c library may cause havoc with restarting

There is no reason why it should. Anything (in the ROM) statically linked to it should work (as it is still physically there) and I am RMLoading 5.56 where the system checks the C Library is present.

Now I am starting RISC OS 5.20 with a softloaded SharedCLibrary 5.56 I am getting ‘Unknown library chunk’ sp perhaps I need to try SharedCLibrary 5.66 (from RISC OS 5.18).

Right. I am starting RISC OS 5.16, RMEnsuring 5.56 (because that’s all that is in the ROM) with a soft-loaded version of 5.66 in 500.Modules in place of 5.77. RISC OS 5.16 starts OK, with a line in !System.!Run that RMKills SharedCLibrary if OS version is >= 520 before RMEnsuring 5.66 (which will load 5.66) leaving the shared C library 5.77 in 5.20 dormant. But despite only RMEnsuring 5.66, RISC OS 5.20 does not complete the boot properly. The saga continues…

Unknown library chunk

Are you using a SharedCLibrary extracted from rom. I got that error when I tried that.

Are you using a SharedCLibrary extracted from rom. I got that error when I tried that.

Yes. Previously (under 5.16) I did an RMFaster to get the SCL into RAM before saving it (and it worked) but under 5.18 RMfaster-ing it didn’t work, so I saved it from ROM… Now what?

Thats why I ended up using SharedCLib 5.53 that came in the AcornC/C++ Enduser folder in an old version I have. Any old clibs hanging around?

Bernard:

Message: You may now keep the new settings, or discard them in favour of the old ones

Did you also see that message in a normal error window? I suspect that the program repeatedly raises the ‘error’ to display the message while waiting for a response from you (perhaps to check if it should have timed out?).

Thats why I ended up using SharedCLib 5.53 that came in the AcornC/C++ Enduser folder in an old version I have. Any old clibs hanging around?

Ah! I have just got the same error under 5.18 when softloading SCL 5.56 which was saved from RAM after RMFaster-ing for 5.16. So saving from ROM may not be the issue.

I think its effectively the same you are saving an initialised copy which you would have thought would have made no difference but apparently it does.

Success!

I now have RISC OS 5.20 on my Iyonix running with SharedCLibrary 5.59. !Writer+ now works.

The steps you need to take are as follows:
Obtain a 32 bit Shared C Library 5.59 – this is available in the C/C++ tools in the ‘EndUser’ directory and can be distributed with any application that requires it (despite the odd-sounding ReadMe file, which I assume is an error – perhaps it means that it can only be distributed to end users).
This file is called ‘CLib’ – place it in !Boot.Resources.!System.500.Modules in place of the version 5.77 ‘CLib’ that resides there in the latest HardDisc4 image.
Edit the file !Boot.Resources.!System.!Run just before the ToolBox line to say:

...
If Boot$OSVersion >= 310 Then RMEnsure FPEmulator 4.03 RMLoad System:Modules.FPEmulator
If Boot$OSVersion >= 500 Then RMKill SharedCLibrary
If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 5.56 RMLoad System:Modules.CLib
| In place of former UnplugTBox
If Boot$OSVersion >= 310 Then RMEnsure Toolbox 1.41 RMLoad System:Modules.Toolbox.Toolbox
...

At an early stage of the booting this kills the shared C library and RMensures what is in modules: which now is 5.59. The (later) version in ROM thereafter remains dormant – any ROM modules statically linked to it are unaffected. This is enough to allow 5.16 to start and to softload 5.20 which is also happy.

Problem with !Writer+ under 5.20 therefore solved.

However the problem with Aemulor is clearly not related to the shared C library as that still aborts under 5.20.