Upgrading Iyonix to OS 5.24 fails

Using the Tungsten 5.24 flash program has failed to upgrade the ROM on my Iyonix leaving it still on 5.18 and still working. Nothing seems to have changed except the contents of HardDrive4 which I upgraded with the 5.24 version before flashing, as recommended.

I had the same result when I attempted the upgrade to 5.20 back in February 2014, did 3 posts (19th, 21st and 23rd of February) to this subforum in thread “RO 5.20 upgrade for Iyonix” and got no responses.

Has anyone got any ideas?

After the trouble Jon had/has with upgrading his ‘Iyonix’ – it might pay to stay with RO5.18 and softload RO5.25?

I run the softload from ‘!Boot !Run’ – here – only a slight delay on startup.

Has anyone got any ideas?

Is there an error message reported?
Stick a

TRACE ON

I had the same result when I attempted the upgrade to 5.20 back in February 2014, did 3 posts (19th, 21st and 23rd of February) to this subforum in thread “RO 5.20 upgrade for Iyonix” and got no responses.

I have successfully flashed my Iyonix from 5.22 to 5.24 so I know it works.

You don’t say what screen messages appear so if you can provide that detail it will help narrow it down to either the backup/clearing ROM or programming the new ROM stage.

Also does it make a backup of the old ROM and to where.

Where are you extracting the ROM to or are you attempting to run it from the archive.

What type of ROM are you trying to flash is it a Full or migration type?

This information with Sprow’s suggested Trace details may well help.

Right, here is the report that comes on the screen as the flash program is run.

RISC OS 5.24 (16 APR 2018)
Tungsten flash ICP 0.69 (02-Jan-14)

Loading ROM image now …
Image loaded, checking …
ROM image checksum good.
Patch Nvidia: Identifying the ROM image patch points

All ROM tokens found: Patching HAL Nvidia STRAP data:

Comparing ROMS

Creating restore file for ROM518
Restore file created

Press SPACE or click mouse to continue

End of on screen report.

It makes a backup of the old ROM as !Restore518 in the root directory.

I am running !ROM524, extracted, from the root directory. To be clear, not from the archive.

I am flashing the full ROM type.

Creating restore file for ROM518, Restore file created

I take it a back up has successfully been created?

Have you added Sprow’s suggested addition to provide further output?

It seems to be seeing an unexpected error so I know you said you updated to the latest !Boot /HardDisc image but I’d be inclined to do a complete clean install after making a backup so has to ensure there is nothing in the Boot sequence casuing issues.

But lets see the output from the added Trace On command first.

I inserted TRACE ON just after line 94 (renumbered as 940) and immediately before line 960, “REM Log that we have startred (sic)”.

The on screen report is as in my previous post, but with the extra line “^{960 970}” just before the final line, “Press SPACE or …… to continue”

I take it this means that the flash program has not progressed beyond this point.

Well out of interest I would do a clean !Boot install from the 5.24 download after saving the old one and then try again.

You have got the correct time and date on the machine as well?

The on screen report is as in my previous post, but with the extra line “960 970” just before the final line, “Press SPACE or …… to continue”

Most likely, then, is that you have an application called Do or Echo somewhere on your Run$Path which is kicking BASIC out of the application slot. Ordinarily they’re utilities (and hence run in the RMA and leave the application slot alone) or modules commands (same).

Or, just comment out the OSCLI after ‘Log that we have startred’; it’s not clear why it’s formulated in such a fruity manner when BASIC has file and string output functionality built in.

I commented out the line you suggested and it works. Nixiyo, my Iyonix, is now on OS 5.24. Thanks.

I did look at Run$Path, but none of the directories mentioned contained applications called Echo or Do. In fact I have never heard of these words as applications, only as commands.

David

Good to hear that you are sorted and update.

I guess my more radical surgery option of a clean !Boot would have worked as well.

Maybe, but why? What I have I got in my !Boot directory, and you haven’t, that might have messed things up? The response to *show run$path is

Run$Path : ADFS::HardDisc4.$.!BOOT.Library.,,%.,
ADFS::HardDisc4.$.Internet.bin.,
ADFS::HardDisc4.$.Utilities.!PSUtils.bin.,
ADFS::HardDisc4.$.Utilities.!PSUtils.pl.

These filepaths came out on one line originally, but I have broken them up for readability. What is ,%. in the above?
I have looked in these directories and seen nothing of “Echo” or “Do”. All of the directories listed above (I don’t know about ,%.) are the result of following the ROOL instructions. There was no instruction to clear out the Utilities directory and the others come from the ‘clean boot’ supplied by ROOL. This matters as there may be many others ‘out there’ who also had my problem including Colin and Jon? (see Colin’s post above.) Should the ROOL instructions be changed or the line in the FlashICP program be deleted as suggested by Sprow?

David,

Maybe, but why? What I have I got in my !Boot directory, and you haven’t, that might have messed things up?

Well the last two items for starters.

So a long shot here is that “ADFS::HardDisc4.$.Utilities.!PSUtils.pl.” has some perl scripts in it and look at the start of them and they have @echo off in the script.

Also a clean !Boot sets things up again in choices etc and I’ve always found it is a good way of checking you have nothing included or running at start up that is causing issues.

I agree that the Flash program should have better error handling but how many people now actively use Iyonix’s and keep them up to date?

how many people now actively use Iyonix’s and keep them up to date?

Me for one!

I didn’t have !PSUtils mentioned anywhere in !Boot, as I have already said, it was a ROOL ‘clean boot’. So why this particular application should be mentioned and not any of the others I have in the Utilities directory is puzzling. Yes, I see the @echo lines in the files in !PSUtils.pl and Echo lines in the two Obey files in !PSUtils.bin . But, one way or another, the ROOL instructions are lacking. One can’t expect the user to go through applications in Utilities or Printing (another directory looked at in the bootup) to check whether Echo and Do lines are in the files. You were just lucky? The simplest solution seems to be to delete or REM out that line in FlashICP.

@ Martin
Good on you for speaking up! But wait ‘til I get started on updating the OS on my RISC PC! Goodness knows what prolems I’ll have with that – I have forgotten what OS version that is on, probably, a number a lot less than 5. I have only just given away my A5000, but I think ROOL are not going back that far – just as well. :-)

@ Doug
The plural of Iyonix can’t be what you have written. There was an argument about that some time back with some saying Iyonices, but I would say Iyonixes. Blame Castle for making up the name which, if I remember, was totally contrived.

DIM buf% 256
SYS "OS_FSControl", 37, "do", buf%, "run$path",0,256 TO ,,,,,len%
IF len% = 0 PRINT "buffer too small":END
buf%?(256-len%) = 13
PRINT $buf%

This should track down the location of ‘do’ if it’s on run$path

David asked (and tellingly, no one replied)

What is ,%. in the above?

% means “the library directory”, or LIB – a concept that dates back to the BBC Micro and is now very rarely used. I don’t know why. You can set your library directory (and FS, obvs) with *Lib but I’m sure you probably remember that now.

RO4 has the (actually very useful) feature of allowing multiple directories in !Boot.Library – I’ve got 200 files in there (including help files – LibraryHelp is another useful thing). But RO5 has just a single directory.

Anyway, I use *Lib when I’m writing Utilities, so I can test them at the command line without having to change the CSD (or “work directory”). Clever eh?

some saying Iyonices, but I would say Iyonixes

There’s an argument for treating it as Anglo-Saxon rather than Classical, hence Iyonixen.

Colin wrote

<trying too hard>

The pathname returned is terminated, so let Basic do the work for you, and there’s an unused buffer at &8300 too:

SYS"OS_FSControl",37,"do",&8300,"run$path",,256TO,,A$:PRINTA$

The thing is, FSControl,37 doesn’t tell the whole story:

I wrote *Commands because it is often very hard to work out what is running when you do a star command.

And remember that you can precede a module star command by the name of the module – so in the above (completely uncontrived) example you can choose which one of those three implementations to run by typing one of:

• *BootCommands:Do
• *Bits:Do
• *Run Do

As it happens I don’t have an Alias$Do defined, but it would show it if there was one.

Martin wrote:

Me for one!

Well though I update and occasionally use my Iyonix it is mainly there so I can test the ROOL builds and on rare occasions raise issues as I have other machines now but it at least gets fired up on a weekly basis.

David wrote:

@ Doug
The plural of Iyonix can’t be what you have written.

Heh I didn’t know this was a english exam otherwise I would have been more careful :-)

On the other points I assummed from your comment:

Nothing seems to have changed except the contents of HardDrive4 which I upgraded with the 5.24 version before flashing, as recommended.

That you had done an update over the existing using a new ROOL version not a hide and replace and reconfigure.

As I also said:

I agree that the Flash program should have better error handling

I agree with you a simple user such as I should not have to go hunting around but at least you have resolved the situation and joined the modern world with our updated Iyonixes/Iyonixen/Iyonices.

As to updating your RISCPC then the last time I did that was when I updated to 6.20 which has got to be many years ago though I have installed many versions on the freely available emulators since.

This should track down the location of ‘do’ if it’s on run$path

I use a program which by Duncan Moore to find locations of commands etc. See http://duncan-moore.netau.net/riscos/index.html

And remember that you can precede a module star command by the name of the module – so in the above (completely uncontrived) example you can choose which one of those three implementations to run by typing one of:

*BootCommands:Do

Which is one thing that Castle (I believe the flash programmer originates there) could have done to make the that line a bit more specific and less error prone.

The thing that puzzles me is why the line is there in the first place as it and a similar line near the end¹ only put the message into a file in the scrapfile directory and never read it back.
If is ever of any use it’s in a bog obscure location and if it isn’t of any use why bother?

¹ A line which David hasn’t noticed giving a similar effect presumably because it is after the work has been done.