Parts of the start up sequence were changed slightly for RISC OS 4 and Select. The banners printed during the start up were one of the more visible parts of the changes. The banner originally was just a plain message giving the OS version. For RISC OS 4 we had begun by adding code to allow users to customise the banner to include their address. The idea was that we could burn different ROMs containing their details and that would make it easier to identify for them, and be a little more personalised.
A new SWI OS_ReadSysInfo interface was added so that the information that was required could be obtained - the data was stored in a simple format at the end of the ROM image, so was quite easy to extract. We also introduced other features into the ROM information fields, like the explicit part number and the build date.
The parts number was part of our tracking database that kept a copy of every released version of the OS, so that we could always reproduce whatever problem the user was seeing, if it was a purely software issue. We also released small tools to make it possible to get at the information easily (not that it was particularly difficult, as the information was just a single SWI call away). Other diagnostic tools I produced later, like !Bugz and the BTSDump tool would all record these details as they were very useful in identifying a particular version.
The build date would be included even in unreleased versions, as this gave an explicit point at which the code was built and would probably uniquely identify the code it was built with (as almost all builds came directly from CVS at the time).
Initially the owner details were displayed by the Kernel, but these were moved to the module before release. This allowed us to print the information in a little information box as the desktop banner was displayed.
When it came to Select, I wanted to remove even the OS banner from the
start screen. The idea was that I wanted to be able to allow the system
to start without any messages at all - this might be useful to some
customers who might want to hide the system being used, etc. It had been
asked about by people in the past and made reasonable sense. So the plain
text banner that printed the OS version
RISC OS 4.19 (17 Sep 2003) 64MB') and the user details
were moved into the module and a new service introduced which
would trigger it (Service_OSInitBanner).
For Select, this would place a 'RISC OS' graphic on the screen, and an indication of the processor as a sprite. I initially used a rather fun font to show the processor type and OS versions. These were met with criticism in the first couple of issues of the first version of Select, so I dropped back to 'Classico' font (the 'Milton Keynes' font I liked, but more professionally drawn) and the OS banner was updated for Select. I wasn't as keen on the 'Select' splash, but it at least looked a bit brighter than before.
Later versions just used the plain 'RISC OS' banner and lost the processor version. Mainly that's because the way that they obtained the processor type was to read a magic value out of zero page, which was pretty nasty - and broke completely when the address was no longer populated with the processor version. I intended to replace the feature with some system specific banner, but never got around to it. Ideally, the system should be able to have the banner in ResourceFS and use whatever is stored there.
The original ARM 710 logo - bouncy and fun.
More professional looking ARM 710 logo.
The original OS logo.
Updated Select logo.
When printing out the banner messages the module would also change the text window so that if the output scrolled whilst booting, the banner would stay on the screen. This is actually quite inefficient as it requires (on non-accelerated hardware) the memory to be moved around manually. But it does look quite good during the start up, I thought (albeit less so when half the screen is taken up with the very large 'Select' version of the logo).
When reworking a small part of the Kernel start up for the boot task I wanted to create a way that the system could be controlled without having to leave the user at a command prompt. Essentially, a failed boot (usually because of a misconfigured drive) left you at a Supervisor (Kernel command) prompt, which was unfriendly. PC systems have a BIOS to step into, but RISC OS and ARM systems have no real standard like that, and in any case would not configure the operating system.
The idea of the ResourceFS.was to provide some basic means of booting from alternate devices. If the 'no boot' path was followed, we would always drop to the boot menu instead of going straight to the Supervisor. Essentially this happened if the boot failed, or was disabled by holding the shift key during start up. In those cases we ran the from
The initial version was a text based affair, which merely let you pick a a boot device to start from, or to exit to the command line. If you exited to the command like it would take you back to the start up banners, with a supervisor command prompt. The boot devices were known about for a limited set of systems - FileCore filesystems which were present in the system were listed, offering the option to boot from the devices that were available.
The system was then extended to allow there to be multiple levels of menus, and we could then offer multiple enumerated discs from LanManFS. For we could just enumerate the discs from Freeway. LanManFS was a little more complicated because you need to issue a transaction to enumerate shares from a browser (assuming there is one). In both of the cases, the system probes whether the filesystem is bootable. Authenticated shares are therefore not bootable - you wouldn't have a password.and
The network menu was extended with the advent of DHCP so that it offered the option to boot with DHCP in addition to BootP. Later, it also got the option to network boot with 'the current network settings' - because the system may have obtained an address by the time thestarted (or a prior BootP or DHCP option may have given us an address).
There was a basic configuration that had the ability to configure the filesystem and ADFS drive (which might be honoured by other filesystems). The menus could be traversed down and up - with the exception of the configuration menu, which you couldn't move back out of without rebooting. Mostly that was just for simplicity - it would have been harder to ensure that every configuration option was applied immediately, as each might need its own special casing.
The items were given the ability to suggest their option keys. For example, drive numbers could suggest that they be given their number as the key to select them. This was also useful for fixing the exit and configuration options - eg configure was always 'W' in the list, rather than changing depending on the number of items in the menu.
Chris Williams made quite a few nice changes to the menu to give it a decent look. Instead of being a text menu, printed in a text window that excluded the initial splash bar, it became a fully anti-aliased graphical affair. Not only did this make it look a lot more professional (and not like something that a programmer had just hacked together quickly), but it also made it a lot more approachable - it shouldn't have been something that felt like you were running at a 'lower level'.
The use of a more graphical interface had always been the goal for the boot menu, and all of the implementation had been focused around a two phase 'collect menu data' then 'render collected data' process. The graphical interface also meant that the cursor keys and return could be used to select items in addition to directly pressing the option keys.
I think when I had originally started on the Wimp proper, with no other applications started, and provide a proper mouse based interface. However, I don't think I ever articulated this except maybe in a commit message, and Chris just implemented what he thought was right for the . I have a vague feeling we did discuss using the mouse but opted for not doing so, as the mouse might not work and if it didn't work the user might think that everything was broken and not try the keyboard - whereas leaving the keyboard as the only option should always work. The use of the cursor keys also allowed the system to work when the keyboard was not mapped correctly.I had intended to start up the
Chris Johns supplied code necessary to implement NetFS booting, so that you could start from an Level4 server (or other, I guess) if you wished. I'm pretty sure I remember trying that and, finding that it worked, I never touched it again . Not that I don't like NetFS, but it just wasn't a system that I worked with much, and I trusted that left alone it would continue to do its job.
CDFS was updated quite late on so that it could be configured as a boot filesystem - it would use the configured Drive (I believe) as the boot CD drive. To complement this, was also able to boot from CDs.
The configuration menu was updated so that it could configure the mouse type (as this might prevent the machine being configured without manually typing commands - including remembering which number was your mouse type), display number (for multiple display device systems), and what type of automatic network configuration was in use (that is, 'None', 'DHCP/ZeroConf' or 'AUN').
The 'V' key was explicitly bound to show the version number of theitself, so that you could find it out without running the command with command line options (which we never did anyhow).
Because I was keen to make everything able to run on portable systems - as should have been obvious from the many similar changes elsewhere - the main menu would gain the option to power off the system if the Portable menu was present. Always nicer to offer the option rather than relying on pressing the power button to turn off the system.
Theitself was rather fixed, in that you had to rebuild it to get support for booting from different systems, or changing the configuration options. This was obviously not going to make it useful for Podules (or other expansion systems) which provided things we'd not even thought of. To make the menu dynamic a system of hooks were added.
This allowed developers to create a simple AOF files in sub-directories of thedirectory which contained hook functions which would be called to add items to menus. For example a hook function would be called to add items to the main menu, and a different function would add items to the configure menu.
A limited number of functions from the standard library were provided, to allow the hooks to perform their tasks. It wasn't a perfect system, but there were some examples provided so that people could see how to extend the system. The code was always built 32bit-safe so that it could run on any system without developers having to supply differently compiled code for systems (which would be impractical as the purpose of the boot menu was to recover a system - and if the system wasn't working because it was of a wrong bitness, that wouldn't help).
The lack of internationalisation for the !ResEd's Window gadget hooks worked.could be a source of criticism - and I'm pretty certain I didn't think too much about it when the main menu was being put together. Certainly it shouldn't have been hard to tokenise things, if it had been considered. Separate message files could have been used per extension hook, in the same way as