Do softloads use the same CMOS settings?

Do softloads use the same CMOS settings as a real ROM?

If so, why?

I can see it will make sense if the softload is intended to be flashed at some point, however, if the softload is the future (as far as I can see this would be the case for everything but the iyonix) wouldn’t it make more sense to have a config file?

Do softloads use the same CMOS settings as a real ROM?

Yes and no. They’ll both try and take their settings from CMOS, but if the CMOS RAM bytes are assigned differently between the two OS versions then there’ll be a conflict and either one or both of the OS’s will read bad settings or think that CMOS is corrupt and keep resetting it.

If so, why?

Before the HAL was introduced it would have been very tricky to get the OS to load its CMOS settings from elsewhere. Since softloads were originally intended just for internal use by the OS developers, I’d assume that the changes required to support this would have been deemed too invasive to make. Especially since the developers would want the softload to emulate as closely as possible the behaviour of the machine after performing a real ROM upgrade (you don’t want to risk introducing bugs where things work fine if it loads the CMOS from disc but fails once it’s been flashed to ROM because of some bug in the IIC driver that talks to the real CMOS)

Also the developers would have had full knowledge of what changes (if any) had been made to the CMOS layout, so they’d know beforehand what side-effects running a particular softload may have. So they would have ran into far less issues than a regular user would now.

Of course that was then and this is now. Softloads are now a common practice, and they’re being done by users and not OS developers, so finding a better solution would be desireable (how does RISC OS Select handle it?)

The problems preventing us from having different CMOS settings for different ROM images is essentially the same as the problems faced by trying to use multiple !boot sequences – the current ROM images are dumb and aren’t designed to accept any parameters from a bootloader. They also don’t have any bulletproof way of determining if they’ve been softloaded or not, so you can’t even hard-code the parameters into the ROM.

The best solution as far as I can see would be to update the ROMs to be more softload-aware, and the only foolproof way of doing this would be to add an extra entry point. This entry point would skip some of the potentially destructive lower-level bits (e.g. RAM initialisation) and accept a pointer to some kind of parameter block. This parameter block would indicate what CMOS settings to use, what !boot sequence to run, etc. We’d also obviously need to modify the OS intialisation to make it aware of the parameter block, and to make sure it uses the parameters where appropriate.

Overall those changes shouldn’t be too tricky, and could open the door to other softload features. e.g. we’d want some kind of header to allow the softload tool to locate the second entry point; this header could then be used to indicate the machine type the softload is intended for, to prevent people from accidentally trying to softload an Iyonix ROM image on a RiscPC.

Thanks for the excellent explaination.

how does RISC OS Select handle it?

Not very well initially, I had scsi CD and had to softload a scsi driver that was unplugged, because in the ROM OS I had to unplug the atapi module. They did fix it though.

add an extra entry point.

I assume there would be differences in the way it would have to behave if started from RISC OS compared to a generic bootloader.

Some RISC OS podules have flash ROM on board, (eg unipod) could these be used (one day) to house a bootloader that bypasses the built in OS?

I assume there would be differences in the way it would have to behave if started from RISC OS compared to a generic bootloader.

Yes.

Some RISC OS podules have flash ROM on board, (eg unipod) could these be used (one day) to house a bootloader that bypasses the built in OS?

You won’t be able to stop the built in OS from starting to boot, but podule modules will get initialised very early on, I think after the main ROM modules have been initialised and just before the POST screen that shows the RAM & processor type. So a podule module could easily take control over the system and softload a new ROM image from its internal flash.

So a podule module could easily take control over the system and softload a new ROM image from its internal flash.

I hadn’t actually thought of a podule to load the new OS from, because I don’t think the flash is big enough in anything that already exists.

I was thinking of it being one option for loading the OS from a medium that the native OS doesn’t support.

(e.g. a new format HDD on a 3.x machine, or if partitions are introduced, and the scheme is not backwards compatible for the first partition *)

Obviously an alternative would be adding a module that contains the support. (or if there is no issue with the first partition being read on old RISC OS, softload from there)

• I have a pile of Matrix NCs that could benefit from such an option.

• I just tried plugging a disk from a Mico into my iyonix and the first partition was visible, but plugging it into an XP box, didn’t show any partitions, so I don’t know if a current style partition can live alongside a standard PC partition system

Obviously an alternative would be adding a module that contains the support.

Yes, that would be possible too.

I just tried plugging a disk from a Mico into my iyonix and the first partition was visible, but plugging it into an XP box, didn’t show any partitions, so I don’t know if a current style partition can live alongside a standard PC partition system

I’m not sure what kind of partition scheme the Mico uses. The fact that an Iyonix saw the first partition suggests that there’s no DOS partition table, which would also explain why the Windows machine didn’t see anything. Or possibly the Windows machine found the partitions but didn’t know what to do with them – did you try checking the disk management tool? (control panel → administrative services → computer management → storage → disk management)

One thing’s for certain though – DOSFS has minimal support for DOS partition tables (I suspect it just mounts the first partition), so when we add proper DOS partition table support to filecore it should be possible to use partitioned hard discs on older machines just by having a small FAT formatted partition containing a minimal !boot sequence that would then softload whatever ROM image/modules are necessary to obtain full partition support.

I’m not sure what kind of partition scheme the Mico uses. IDEFS, the same as some expansion IDE cards.

The fact that an Iyonix saw the first partition suggests that there’s no DOS partition table, That is what I thought too. the windows machine didn’t see any partition table (XP disk mangler thought it was blank).

DOSFS has minimal support for DOS partition tables I didn’t think 3.x had any support for DOS partition tables. (My machine with a Castle SCSI card did, on SCSI).

http://www.riscos.com/adjust/AdjustROMchanges.htm

As far as I understand normal ADFS has no concept of partitions, and partitioning consists of effectively lying about the size of the disk and then using a different system to access the rest of the disk.

If that is correct then an ADFS partition would have to NOT overwrite the DOS partition table.

If that is not already the case and can’t be contrived. Then old machines would have to use a non standard method (e.g. put a standard partition table somewhere else or use the IDEFS method, if it is common).

In that scenario, I guess the (new) OS would check whether the disk has an ADFS partition, if not it would look for a standard partition table, if it has, it would then look in the alternative location for a partition table.

I didn’t think 3.x had any support for DOS partition tables.

All discs with FAT partitions on them have a partition table. So for DOSFS to work at all it must be doing one of two things – either examining the partition table to find where the FAT partition is, or assuming that everything except the first sector is the FAT partition (since the first sector of the disc will be the partition table). I haven’t checked the source code, but I’d hope that it uses the former approach and not the latter. I’d also hope that it behaves sensibly if there are multiple partitions (e.g. it only mounts the first partition)

As far as I understand normal ADFS has no concept of partitions, and partitioning consists of effectively lying about the size of the disk and then using a different system to access the rest of the disk.

Yes, that’s basically correct.

I didn’t think 3.x had any support for DOS partition tables.

Yes, now I think about it, that is wrong – it supported hard drive image files (though I seem to remember a 32MB limit, that needed a soft loaded new version to fix)

I’ll try again :)

I didn’t think 3.x had any direct support for DOS partitions on the IDE interface.

Update: I just tried a 500MB DOS formatted hard drive (read by Iyonix OK on USB adaptor) on a RISC OS 4 system. It was not readable. (IBM 500MB drives didn’t have the same problem as WD drives, did they?)