SoftSCSI and 5.23 ROM

I have a PandaES with a low vector 5.23 ROM , 11th July 16.

If I download the latest self extracting Hard Disc image then extract the files then in RO510Hook I get the latest SoftSCSI modules but not in RO520Hook.

The SoftSCSI modules are later than the versions in the 5.23 ROM I have so why does the latest disk image not have them in?

Secondly if I run a clean !Boot and Choices then indeed I do not see any SoftSCSI entry in my !Boot.Choices.Boot.Predesk.

If I copy the ones out of RO510Hook in to !Boot.Choices,Boot.Predesk and then reboot then they do not replace the ROM based SCSI modules unless I alter the !Run file to include reference to later than ROM modules.

This very well may be my lack of understanding but an explantion would help me understand what is going on.

Are you copying the !Boot structure in place completely without any alteration AND then rebooting?

The Hook directories are only used the first time $.!Boot is booted. The contents of the hook directories are then automatically copied from the appropriate directories to the necessary ones.

I’m not sure if hook works like !System were say a module is RISC OS 3 and all later versions compatible and so sits in the 3.1 directory. i.e. they are missing from later directories.

!Boot only installs the contents of one hook directory (the directory which is closest to but no greater than the ROM version). If it installed multiple directories then you might end up with a bunch of patches which were only intended for older OS versions.

Early Iyonix ROM versions didn’t include the SoftSCSI modules – they were only available in softload form. Once they were added to the ROM, there’s little point having the boot sequence try to softload them on newer OS versions, because we know the versions which are in ROM are “good enough”. If people want newer versions of ROM modules, the theory is that they should just update to a newer ROM version, as modern machines make ROM upgrades a lot easier than older machines (mainly because the ROM isn’t actually a ROM chip!)

Also softloading device drivers or filing systems can get a bit messy if the driver was already in ROM – you’ll be adding an extra delay to the boot sequence while devices are re-initialised, and if the module is critical for the operation of the boot filing system then you’ll need to cope with the filing system vanishing in the middle of the softload.

Yes I save the current contents and then delete them except for the PCFolder and copy over the new !Boot contents.

I’ll look at making a new disc image using a new card and Systemdisc on Friday if I get time in case there is something funny going on.

I have checked the full HardDisc image and also the 5.22 one as well and they both have no SoftSCSI in RO520Hook.

Tried this with a clean card and set up via System Disc with 25th Jan 17 hard disc image from the ROOl site and it still does not build a SoftSCSI set of latest modules in !Boot.Choices.Boot.Predesk.

The ROM in this case was a RaspberryPi one dated late Oct16.

So have the SoftSCSI modules been missed off the HardDisc image build for RO520Hook due to an issue in the ROOL build or are they assuming that they will be in the latest ROM. This would also effect any 5.20 builds as well given the testing I’ve done if this is the case.

Also still doesn’t answer the second part of the question of why the SoftSCSI !Run file , if manually copied,does not load the latter modules than those in the ROM.

I have a feeling you missed my reply – we both posted at about the same time.

But in summary, the SoftSCSI modules aren’t meant to be in RO520Hook. If you want newer versions, the preferred way of getting them is to update to a newer ROM image.

Jeffrey, thanks for the replay and clarification which seems logical though why are the updated modules in RO510Hook and below and thus it only effects machines running ROM builds 5.20 upward as refusniks get the latest builds unless it it is to do with those that run systems that need those specific older ROM builds or does 5.1x and below not have the modules in ROM?

I think the timeline is:

• The SoftSCSI modules are created for the Iyonix/RISC OS 5 USB stack. IIRC they were initially only made available as a softload because they were considered experimental/beta. CVS suggests the first public release was around 2005.
• A few years later, the OMAP3 port is started (January 2009), with (IIRC) RISC OS 5.15. Since USB is the only storage solution available (no SDFS yet), the SoftSCSI modules are a key part of the OMAP3 ROM.
• A few more years pass (January 2012), and the release of RISC OS 5.18 is approaching. This will be the first stable release for OMAP3, and since we’ve got some spare space in the Iyonix ROM, the decision is made to go for feature parity with the OMAP3 ROM by adding the SoftSCSI modules to the Iyonix ROM. USB mass storage in ROM is also pretty useful if your hard disc is busted (easier than burning recovery software to a CD or trying to find a working floppy disc)
• All future OS ports have followed suit and included the SoftSCSI modules in ROM. The only machine which doesn’t have them in ROM is IOMD, since there currently aren’t any USB podules which are compatible with the RISC OS 5 USB stack.

So anyone running RISC OS 5.16 or older on their Iyonix will be in need of the softload which is provided in the disc image. Considering that reflashing an Iyonix can be a bit scary (if it goes wrong you’ll probably have to send the machine in to a dealer for repair/recovery), it seems reasonable to continue to provide the modules for those older versions. There may also be some people who can’t or won’t update due to software compatibility issues, so we need to provide the builds for them.

If we were to make a change to the SoftSCSI modules which made them incompatible with older versions of the USB stack or other key OS components then we’d probably update the disc image to lock the modules to a specific version. But until that happens we might as well continue to supply the latest versions of the modules, much like we also provide the latest versions of the Wimp and other key modules for RISC OS 3.x users.

Jeffrey, thanks for an excellent, comprehensive and easy to understand explantion of things.

So anyone running RISC OS 5.16 or older on their Iyonix will be in need of the softload which is provided in the disc image.

Perhaps the logical thing to do is to remove them from the HardDisc image and ensure they are in the PlingSystem image? That comment based on the fact that PlingSystem is intended for the older OS systems while HardDisc is for the newer OS builds.
That said, I think one of the things most people need is a !Boot cleanup/upgrade tool that works in a slicker fashion than this set of instructions

HardDisc isn’t just for new OS builds. It works dandy back to RISC OS 3.1. In my opinion, the separate PlingSystem is a faff. Do people really care about a touch of saved disk space on a modern machine?

I absolutely agree that upgrading Boot is a bit of a trainer Eck. How would people feel about Boot/HardDisc embracing a package management system?

Those instructions may be rather old as it doesn’t point out in giant letters that !Boot.LOADER (if present) must be moved, never ever copied (and the original deleted).

That said, I run my Harinezumi so I don’t tend to bother upgrading the boot stuff unless something breaks. I’ve a lot of auto actions (starting two servers and getting the weather station interface going, preparing the DDE, blah blah) so I prefer to leave it alone unless there’s a specific pressing reason why I shouldn’t…

HardDisc isn’t just for new OS builds.

“newer” two letters extra.

It works dandy back to RISC OS 3.1.

Mostly, but I believe you need the PlingSystem as well

In my opinion, the separate PlingSystem is a faff.

Ah, you noticed and don’t like the extra step on the old kit

How would people feel about Boot/HardDisc embracing a package management system?

Seems like a good idea. Stage 1 is the bit where it automates a cleanup of old tat from the dino-days.

BTW. Delay in post due to having been in to work between the two posts to fix a network stack. Cracking start to the weekend.