IOMD Softload 5.19

I am trying to softload RISC OS 5.19 on top of 4.0.2. I’ve a tried a number of things with no success. The hardware is SA233Mhz, 64MB of RAM and 2MB of VRAM – no other additional hardware (although I’m using a CF card connected to an IDE adapter).

I’ve tried the following:
1) Newly initialized drive with original !Boot from the RISC OS 4 CD. Then I installed !System (from iyonix.com) and the System resources archive from ROOL’s download page (I’m not clear if they’re the same thing). Finally, I downloaded the latest softload and merged the !Boot to install. After restarting, I get the following…
-
Softload version 1.16
Platform class: RiscPC
Hard ROM logaddr: 03800000
Hard ROM physaddr: 00000000
Traditional memory map: Yes
ROM type: Hard
soft-loading ROM…
Npages=16896 Freesize=62820k
physmem @ 00001c0
chunk addr chunk size
02000000 00200000
18000000 04000000
foundpage=15872 foundphysaddr=1bc00000
-
… after which my display complains about the resolution and the computer appears to resolution – or at least, the keyboard no longer responds to Caps Lock and if I hit F12 and do ctrl-g, there is no beep.

2. Next I tried removing the !Boot altogether and using the one from the latest ROOL HardDisc4 image. Rebooting gives me “Error: File ‘System:Modules:CallASWI’ not found”. Fair enough, so I then merged !System from iynoix.com. Restart now gives me “Error: Message token * not found”. I guess this !Boot isn’t meant to be used on pre-RISC OS 5 machines as a new !Boot?

I appreciate the IOMD ROM is at the bottom of your priority list. Grateful for any advice, happy to try anything that you can advise. Long-time RISC OS user but been away for a while so things are rusty.

Gavin

Hi. There’s a !System distribution on the ROOL site now. Our aim is to remove/replace the extremely old and crusty one on iyonix.com.

Thanks Steve, I’m using the ROOL one now. I still get the problem mentioned in the first half of my post, with no further activity from the machine until I reset.

I’ve just tested the 5.19 softload on my RiscPC (RO 3.7, 233MHz SA, 32+2MB) and everything seems fine. So the problems people are reporting here and elsewhere are either (a) just limited to softloading over 4.02 and/or (b) limited to specific RAM configurations. (Podules are unlikely to be causing problems, at least for Gavin, since he doesn’t have any)

So the problems people are reporting here and elsewhere are either (a) just limited to softloading over 4.02 and/or (b) limited to specific RAM configurations.

Hadn’t considered RAM, I’ll remove one of the 32MBs and give it another crack. I’m not missing anything else am I? Clean RISC OS 4 !Boot (right off the CD), !System from ROOL download page, merge the !Boot softload, restart…

Just tested a fresh download of IOMD softload of 5.19 on my 4.02 fitted SA RPC and it boots into the new OS ok. Machine is late 1996 vintage with over clocked 233mhz SA (rev S I think), memory 32MB+8MB+1MB vram. Oh and a 111GB (120GB claimed) hard disc.

Excellent. I wonder if it is a RAM thing then – perhaps I even have a dodgy module. Looking at the message I got when softloading (in my original post), it looks like it’s shifting the ROM into RAM at that point and maybe that’s when it locks up.

It was indeed RAM related.

- 64MB module was in Slot 1 and always caused machine to hang. Moved it to Slot 0 and slight progress – when softload kicks in, machine reboots back into 4.02 and asks if I want to softload all over again and so on but doesn’t hang.

- Removed 64MB module and put in a single 16MB module. It loads RO5 (yay!) but fails just before Desktop with “Error: Internal error: abort on data transfer at &00012A5C (Error number &80000002)”. Typing “Desktop” gets me in although attempting to open !Boot gives me the same data transfer error. The same !Boot still opens fine in RO4. This was a clean RO4 !Boot from the RO4 Install CD, with the !System updates from ROOL and the softload installed, nothing else. Kind of sounds like a !Boot issue now?

64MB module was in Slot 1 and always caused machine to hang. Moved it to Slot 0 and slight progress – when softload kicks in, machine reboots back into 4.02 and asks if I want to softload all over again and so on but doesn’t hang.

The RAM detection code is based around the code that was used in RISC OS 3.71, so it should be OK if the OS is running from ROM. But from looking at the code last night I did spot a few suspect bits that look like they could cause it to fail during a softload. So it looks like that would be what the problem is. I’ll see if I can have a go at fixing it sometime in the next few days.

I wonder – since the code should be the same as in 3.71, what happens if you try softloading a 3.71 ROM image? (The softload tool should be able to cope with it, I’ve tested it in the past)

Kind of sounds like a !Boot issue now?

Yep, that’d definitely be a !Boot issue.

“Error: Internal error: abort on data transfer at &00012A5C (Error number &80000002)”

Maybe a non-32-bit compatible transient utility is being run, or some otherwise non-32-bit safe API call being made by something in your PreDesk directory?

Maybe a non-32-bit compatible transient utility is being run, or some otherwise non-32-bit safe API call being made by something in your PreDesk directory?

I removed items from !Boot.Choices.Boot.PreDesk, rebooting each time as a test, but same error message. There’s nothing at all in PreDesk now (apart from !!SoftLoad). I went back to scratch with a new RO4 !Boot from the ROL site, installed !System from ROOL and then installed the softloader but it still fails with the same error after starting the RO5 ROM (right after the Acorn ADFS line).

Would hugely appreciate any pointers for other things I can try. In the meantime, I’m going to keep digging!

Would hugely appreciate any pointers for other things I can try. In the meantime, I’m going to keep digging!

There are some other utilities that get run as part of the boot sequence (in !Boot.BootUtils I think?), but if you removed those it would completely break the boot sequence.

Until we/ROOL get a new universal boot sequence I think your best course of action would be to create your own hybrid boot sequence from the RO 4 boot, RO 5 boot (easiest to get hold of by downloading the full disc image from this page? you’d want 32bit versions of the other disc image components anyway), and the 26bit compatible ROOL !System (PlingSystem download).

One easy technique that I know has been suggested in the forums is to just create a dummy !Boot that has the two seperate boot sequences inside it. That way all it needs is dummy Boot/Run files to run the appropriate boot sequence depending on the OS version.

!Boot with dual booting using OS 4.02 and 5.17/9 is a bit of a nightmare! Although both their respective !Boot apps are based on Acorn’s UniBoot app both versions are tailored to their specific OS. One of the thing’s I have done is download the BootCmds module and RMEnsure it early on, while also removing the disc based 26 bit versions of the same commands. You also need to make sure your !Boot contains ROXXXHook folders for the versions you are using. From what I can remember from my own digging a few months back is that which of these folders get added to the relevant paths is flawed. I will try and have a play again when I next have a day off.

I’ve spent most of today trying everything I can think of but I get the exact same data transfer error each time, after it boots into RO5 (before Desktop).

So, finally, I pulled the 4.02 ROMs and put in 3.71 ROMs. I changed the RAM and I even removed the CPU and put in an old SA 202Mhz. Finally, I put in an old 1GB drive that hasn’t been touched in years, with a standard 3.7 !Boot. Then I merged PlingSystem and the softload and… got exactly the same message.

So, the only constant now is the motherboard, unless there’s something else I should be installing that everyone is taking for granted, but I’m forgetting having been away from RISC OS developing on Macs for several years.

It’s highly unlikely that an abort on data transfer would be the result of faulty hardware, especially if it only happens when using RISC OS 5.

A couple of things to try:

• Have you tried completely replacing your boot sequence with the RISC OS 5 one? That one should boot into OS 5 without any issues. The only tricky bit would be getting it to work with non-32bit OS’s. There are a few relatively easy ways round this:
  • Go with the approach suggested above of making a dummy !Boot that contains two seperate !Boots, one for each OS
  • Manually rename the !Boot folder before rebooting into OS 5 (which is what I’m currently doing on my RiscPC since I run the softload tool manually instead of placing it in my boot sequence)
  • Hold down shift when booting into OS 5 so that the boot sequence will be skipped and you’ll be left at the supervisor prompt. Then manually run the OS 5 boot sequence from the command line.
• Try using Reporter to find out what program is crashing

Have you tried completely replacing your boot sequence with the RISC OS 5 one?

The way I have tried to do this is by booting into RO3.7, renaming the RO3.7 !Boot and putting the new RO 5 one in place. Then, I manually ran the softload tool from the 3.7 Desktop (it didn’t even occur to me that this might work earlier). It reboots into RO5 but before the desktop, it complains about lack of memory (I didn’t note the exact message unfortunately as a toddler was pulling my arm to read her a bedtime story, but it was telling me to go into Task Manager and free up space).

From the star prompt, I go into the Desktop and all is well. Next I try to run !Boot but now it’s complaining about ProgInfo not being 32-bit which makes no sense as it’s straight from the recent HD image (I checked the file info and it was built on the 15th of this month).

So, in summary, I’m in 5.19 without Configure. Any idea on the ProgInfo thing or is that just a red herring?

(I sincerely appreciate the help I am receiving. Hopefully I’ll be able to contribute something once I’m back up to speed)

Unless I’m mistaken ProgInfo isn’t included in the disc image – the one you’re looking at must be from PlingSystem. Which, as you’ve probably guessed from the error, isn’t 32bit (PlingSystem is only meant for 26bit OS versions).

The real location of ProgInfo is in the ROM image. Chances are it’s been unplugged, so check *rommodules to see what’s up.

Unless I’m mistaken ProgInfo isn’t included in the disc image – the one you’re looking at must be from PlingSystem. Which, as you’ve probably guessed from the error, isn’t 32bit (PlingSystem is only meant for 26bit OS versions).

Yeah, I read “for pre-RISC OS 5 machines” and assumed that applied to me when softloading. I’ll take a clean !Boot from the new HD image and try again tonight, thank you.

Success and not an error in sight! For anyone else a little rusty on RISC OS (or newbies) here’s exactly what I did.

I started from scratch with a clean 3.7 !Boot. I fired ROOL’s PlingSystem into it for good measure. I dragged !!SoftLoad out of the IOMD softload archive and into $ so I could easily run it manually.

Next, I extracted the latest !Boot from ROOL’s HD image into a temporary folder. Finally, I renamed the 3.7 !Boot to 37!Boot and dragged the new RO5 !Boot into place. Finally, I double-clicked !!SoftLoad and it booted into the RO5 Desktop with no issues.

The only remaining issue was that when I tried to Configure, it complained about the lack of ProgInfo. ProgInfo was indeed unplugged, not sure why this would be but a quick forum search shows other people have had the same issue in the past. Anyway, a quick *RMReinit ProgInfo and Configure was working smoothly.

Huge thanks to Jeffrey for his patience and work and obviously thanks to the ROOL guys for making any of this possible. Nice to see RO5 on an old RiscPC – next, hopefully a few Raspberry Pis…

Which modules are unplugged is stored by the module number, not name. And the numbers can change from one ROM image to the next.

The module list definitely changed in 5.19, as I found out, because I had a similar problem with the BootCommands module being unexpectedly unplugged.

I had the unplugged BootCommands module problem, too, on a Beagleboard.