Alarm$Options

Here’s the strangest thing… I save Alarm$Options as:

-timeout |"10|" -weekwork 62 -format |"%yr-%mn-%dy %24:%mi:%se|"

but they come back on reboot as:

-timeout |"10|" -weekwork 62 -format |"%yr-%mn-%dy 4:%mi:%se|"

Any ideas?

There is a perfectly logical explanation for this anomaly which I have forgotten, the issue came up some years ago. Fortunately the answer is on my Iyonix, and RiscPC, and it is to use an additional ’’ in front of the ’%24’ argument, that is %24.

Vaguely (very), it is something to with the way GSTrans works and the way ’2’ is interpreted as an argument by GSTrans. ’%2’ is a legitimate argument to GSTrans which it swallows and then just outputs the ‘4’, ’%24’ to GSTrans is passed on as the required ’%24’.

How are you saving them? Switcher/Save settings? This writes the file ‘Choices.Boot.Desktop.!Boot’ and the format string is appropriately quoted to avoid the %24 being eaten. (Tested with Alarm 2.79)

Any ideas?

Yes, I’d like to know which version of Alarm you are using, the contents of the User defined display icon in the Alarm choices window and the contents of the file !Boot.Choices.Boot.PreDesk.Alarm

How are you saving them? Switcher/Save settings? This writes the file ‘Choices.Boot.Desktop.!Boot’ and the format string is appropriately quoted to avoid the %24 being eaten. (Tested with Alarm 2.79)

The recent versions of ROOL Alarm save the Alarm$Options value to !Boot.Choices.Boot.PreDesk.Alarm too.

There is a perfectly logical explanation for this anomaly which I have forgotten, the issue came up some years ago. Fortunately the answer is on my Iyonix, and RiscPC, and it is to use an additional ’’ in front of the ’%24’ argument, that is %24.

The recent versions of ROOL Alarm already double the % automatically, so there shouldn’t be a problem.

Set Alarm$Options -timeout "10" -weekwork 62 -format "%%24:%%MI:%%SE |<Alarm$Free>"

Set Alarm$Options -timeout "10" -weekwork 62 -format "%24:%MI:%SE |<Alarm$Free>"

The current Alarm gets both right automatically.

First statement: I’ve solved the original problem by doubling a percent character. Now the Alarm$Options come out correct.

However, !Alarm always appears on the icon bar in analogue format, even though Alarm$Options are clearly for a digital format, e.g. 2010-05-21 20:37:58 In Alarm’s “Choices” window, the display format is Analogue, with my correct format string in the “User defined” writable icon (but greyed out, of course). If I click the “User defined” radio button, select the “Automatically update the alarm database”, click “Set”, and do no more, the display format changes to what I want. Howver, next time the BB starts up, the display is back to analogue, and the “Automatically update the alarm database” is not selected.

I don’t have this trouble on the Iyonix.

Is it anything to do with the CMOS settings (or lack thereof)?

I’d like to know which version of Alarm you are using

2.79 (11-Jun-09)

the contents of the User defined display icon in the Alarm choices window

%ce%yr-%mn-%dy %24:%mi:%se

and the contents of the file !Boot.Choices.Boot.PreDesk.Alarm

Set Alarm$Options -timeout "10" -weekwork 62 -format "%%ce%%yr-%%mn-%%dy %%24:%%mi:%%se"

I just had a look at the source. It does indeed read the cmos settings.

Should be easy enough to do a custom rom build with the required settings.

Right, OK, thanks, Chris. At least you have explained why it’s doing what it’s doing.

I’d like to volunteer to give a functional equivalent of the CMOS RAM by having a writable file on the SD card. At least I understand how FAT filing systems work. However, I have no idea where to look for existing code that accesses the SD card. There are at least read routines in there, and there may well be write routines too.

I’ve also interfered with the IIC module before now, so I can see how to redirect CMOS accesses.

However, I have no idea where to look for existing code that accesses the SD card. There are at least read routines in there, and there may well be write routines too.

There isn’t any code in RISC OS to access the SD card at the moment. Uwe Kall was working on it, but I don’t think he managed to make any real progress. Apart from the relevant bits of the OMAP TRM, you’ll want to look at the SD card “simplified physical layer specification”, which describes how to talk to cards using the SPI protocol (for details of any other protocols you have to shell out cash!) Or for some code to look at, you could probably find some clean & simple code in the u-boot source – although since u-boot is GPL you obviously won’t be able to copy the code into a RISC OS ROM image.

I’ve also interfered with the IIC module before now, so I can see how to redirect CMOS accesses.

There’s a HAL interface for accessing CMOS/NVRAM, it would be preferable to use that instead of hacking something into the IIC drivers. (I’d give you a link in the wiki, but the wiki’s down as usual!)

Of course whether it’s easy to implement FAT file manipulation code within the confines of the HAL is a different matter entirely. The way RISC OS is currently structured means you’ll need to at least need to have some code to read the data from the SD card on boot, so that it’s available when RISCOS_Init is called (I think – I’m not 100% sure when RISC OS first attempts NVRAM access). Saving the data back out to the card can always be done from a module if it’s infeasible to do it from within the current HAL/HAL API.

I’m not 100% sure when RISC OS first attempts NVRAM access

AIUI it must be before booting a disc image, because the NVRAM contains information about which drive (if any) and which FS to boot from. However, I don’t think it would write anything back at this stage. The possible exception I can think of is the base year for the RTC, if it happens that the year has wrapped in the RTC since last boot-up.

I just had a look at the source. It does indeed read the cmos settings.

The development version has now been fixed to store the cmos settings in the Alarm$Options variable in a similar way to the RISC OS Select version of Alarm. So in future it should work fine on the Beagleboard.

The development version has now been fixed to store the cmos settings in the Alarm$Options variable in a similar way to the RISC OS Select version of Alarm. So in future it should work fine on the Beagleboard.

Thanks, James! Is that in the 2010-06-25 build? I’ve been running it for a couple of days, but I wasn’t looking at Alarm.

Thanks, James! Is that in the 2010-06-25 build? I’ve been running it for a couple of days, but I wasn’t looking at Alarm.

No, sadly I haven’t been able to fix some minor issues so it still hasn’t been added to the CVS.

I can email you a copy of the current development version if you want.

Thanks, James, but I think I’ll wait until you’ve fixed the issues and got it into CVS. The problem isn’t a big enough deal for me to need a special version. It was good to know the cause of the problem, and now we can all be confident of a fix.