Some minor tweaks before RPi release

I considered putting this in Code Review, but it isn’t a change I’m proposing…

Just a few minor tweaks prior to an RPi release.

#1: As I mentioned earlier, a configuration screen doesn’t fit analogue video output.

We probably don’t have time to perform the discussed changes for video standard detection/configuration. But it would be nice.

#2: Lock says “Hard disc lock”. As far as I can determine, it only seems to lock out the configuration on Beagle devices. Am I missing something?

#3: For people without widgets… CMOS handling (userland side) is, for want of a better word, shagged.
!SaveCMOS generates CMOS files the OS cannot reload (says it is for a different OS version). Falling back to *SaveCMOS and *LoadCMOS would be an option, if it wasn’t for the fact that *LoadCMOS essentially hangs the machine (it might be working, but after doing nothing for four minutes, I think we can call it non-viable).

This also explains why Beagle boot CMOS loading never seemed to work for me. I guess it didn’t like the !SaveCMOS files. It is working now, with a *SaveCMOS file.

Hmm. FSLock falls into the category of parts of the OS that most of the current userbase probably never uses, and therefore has gone rather rusty.

I quote from the PRM (volume 5a):

FSLock cannot protect all discs on all filing systems; it can only protect drives 4 – 7 on any one filing system. By default, the Configure application sets FSLock to protect the ADFS hard discs 4-7.

Clearly this isn’t much use for any machine that doesn’t support ADFS hard discs.

I also doubt that any post-Risc PC hardware has the motherboard jumper the PRM talks about to prevent delete-poweron from changing the CMOS settings. Nor do I suspect that the jumper survived HAL-isation of the OS…

I thought !SaveCMOS was ditched at RISC OS 4, its functionality having been integrated into !Configure at that point. As such it has probably never been updated to the newer file format that attempts to deal with changing CMOS allocations over the course of major OS releases by stamping the OS version number within it. As such, the files created by !SaveCMOS are assumed to be RISC OS 3 CMOS files by things that load them nowadays.

I also doubt that any post-Risc PC hardware has the motherboard jumper the PRM talks about to prevent delete-poweron from changing the CMOS settings. Nor do I suspect that the jumper survived HAL-isation of the OS

The Tungsten motherboard in the Iyonix includes a CMOS protection link. Referring to section 3.11.2 (“CMOS lock bit”) in the TRM reveals it is PL414 on the motherboard.

The HAL for IOMD and Tungsten both respect the link state, passing it to the kernel.

I thought !SaveCMOS was ditched at RISC OS 4

Me too – delete it and use !Configure, and be grateful that you get an error message refusing to load files it creates!