As a former user of RISC OS many years ago, it’s been interesting to see that RISC OS still has some kind of active community around it. In the last year or so, it appears to have gone open-source, so having a bit of a play with it seemed only sensible…
Building RISC OS
So at the time of originally looking into RISC OS (quite some months ago, admittedly), it turns out that a potential developer needed to pay £50 to gain access to the development tools. Not ideal, but RISC OS is a small community and worthy of a punt, so £50 was duly handed over to receive a copy of the DDE (developer tools). These are the RISC OS binaries and supporting “gubbins” required to build RISC OS and have a bit of a look “under the hood”, as they say. (Do note, RISC OS is not built in a cross-platform manner – it certainly isn’t a case of “here’s the GNU toolchain, now off you go”!)
The build process is a little tricky, but without too much trouble it was possible to point the !Build utility at the source files and generate a RISC OS ROM image, which could then be placed on the Raspberry Pi’s main partition as a file called “RISCOS/IMG”. A quick reboot of RISC OS and the freshly-compiled RISC OS fired up. So good, so far. And, looking back, it’s interesting to think that all those years ago, RISC OS was just a set of ROM chips to be stuffed in the machine and yet, as grown-ups, here we are, now able to build it independently without any input from Acorn.
Let’s Go Downhill
In order to confirm the situation, a decision was taken to make some kind of small, initial – and easily visible – change to one of the components, just to confirm that there was indeed the requisite degree of control over the source at that point.
For no particular reason, the change to be made was to alter the build date displayed in the “About” dialog box (the “Version” field as shown below):
At the time, the Version field read “5.27 (20-Apr-19)”. This was to be changed to the current date, which at the time was “27-Nov-19”. (Quite why it wasn’t saying that date to start with, was unfortunately not picked up on!) This article now presents a summary of what was learned through the idea of making this seemingly simple change…
Initially the source files were searched for a Templates file carrying this particular dialog box definition and, after a short while, the above dialog box was found as a window template called “proginfo” in the following Templates file (take a deep breath here):
BCM2735/RiscOS/Sources/Internat/Messages/Resources/ROOL/BCM2835/01/UK/Resources/Switcher/Templates
Immediately it was clear that the dialog box definition didn’t have “20-Apr-19” text in there by default. So something at the code level must be taking the dialog box and updating it at the right time (either at compile time, or run-time presumably).
Not to put too fine a point on it, the next couple of hours were spent investigating what turned out to be a small number of dead-ends. Clearly the lack of documentation, the lack of exposure to the project, and the sheer volume of ARM code within it, all combined to frustrate the initial efforts; the day drew to a close with no success.
Day 2
The following day resulted in a fresh look at things, and within a few minutes there was a bit of a “lightbulb moment”. Pressing F12 from the Desktop environment, the following command was executed:
*time
This reported a date and time which started – a-ha! – with the coveted “20 Apr 2019”.
And this drove the realisation: that whereas original RISC OS computers came with battery-backed CMOS memory for storing (amongst other things) the date and time, the Raspberry Pi does not have an equivalent.
Thoughts suddenly diverted towards finding – at least as a starter – any CMOS-related code. Was there perhaps something that “emulated” or managed the underlying concept of the CMOS memory?
A fresh search on the source code uncovered, quite quickly, the following ARM source file:
BCM2835/RiscOS/Sources/HWSupport/SD/SDCMOS/s/sdcmos
And within this file were two very important clues:
... NonCanonicalisedPath2 = "SDFS.$.!Boot.Loader.CMOS", 0 ... ; If there's no RTC, try restoring the time from the file timestamp ...
It’s worth pausing to reflect here: without these two human-readable clues, it may have taken a lot longer to delve through the ARM instructions to understand this. A valuable reminder of just how important inline commentary can be.
The CMOS Timestamp
So what appears to happen with RISC OS here, is that if RISC OS has no RTC available, it will use a file called “CMOS” to fall back on, in order to determine the current date and time at start-up. And it does this by reading the filesystem’s timestamp for the file.
Validating
A quick check of the file – which can be found on the main (FAT) partition of the Raspberry Pi RISC OS SD card (which can also be found by shift-double-clicking on !Boot, then going into the Loader directory) – did indeed confirm that upon turning on RISC OS, the date and time were being taken from the timestamp associated with the CMOS file.
Moreover – and again the source code can be seen to back this up – whenever a change is made to the CMOS, the CMOS file has its timestamp updated. This includes being triggered when RISC OS is shut down.
One simple way to confirm this behaviour, is to use the Configure facility in RISC OS to update a CMOS setting, and check the timestamp on the CMOS file. For example, update the Windows configuration by switching off all the real-time redraw options. Press “Set” to update the configuration, and the CMOS file will have its timestamp updated.
The CMOS timestamp will also be updated at the point you shut down RISC OS (providing you do it nicely, of course).
And of course if the Configuration facility is used to set manually the date and time, that will suitably affect the CMOS file’s timestamp as well.
The Moral of the Story
A seemingly benign alteration to RISC OS turned into a bit of a rabbit hole. Pushing through the difficulties encountered was worthwhile, and it was ultimately quite fun to solve how this worked.
RISC OS clearly has a lot of work to do to improve the quality of its build process (in various ways), although it is positive to see it now hosted using modern Git technologies. Similarly it’s very nice to see all the source code is better organised now, as prior to the open-sourcing, the source files were exploded over a number of license-based directories (which really wasn’t very helpful!)
Hopefully more time can be spent by the author with RISC OS in future. It’s definitely “retro cool”. The author is currently also tinkering with a RISC OS-style Operating System for the Raspberry Pi (https://www.imp-os.org/). Which is a bit of a slow-burner/part-time project. But it is interesting to be both building one from scratch as well as gaining exposure to an existing, mature OS such as RISC OS.
Oh, and the moral? Well, the moral is that presumably none of this would be a problem if the user enables NTP in the first place…