Kevin's Research Blog

RISC-OS: In-depth look at the Boot Process

Booting an operating is no simple feat, and there is a lot that must be done in order to get a working system ready for the user up and running. In today's post about RISC-OS, I will dive deep into it's boot process.

Before I dive into the boot process of RISC-OS, I'd like to first quickly go over the much more simpler boot process of the BBC Micro. The reason will be much more clear once I move to the RISC-OS boot process, as it is rather interesting on how similar both of their boot processes are, at least at first.

Booting the BBC Micro

RISC-OS shares one major component, well, actually two with it's predecessor the BBC Micro. This is the concept of !Boot programs, along with the concept of how it is executed on system start. In both systems there exists the concept of Load, Run, and Exec. These are flags that can be attached to your boot medium, on the BBC Micro, it was a part of the DFS, and the later ADFS filing systems. The latter file system became the default filing system under RISC-OS, and these can still be set on modern ADFS discs.

If the Load is set via OPT 4,1, it will load the !Boot program into memory at the location it is configured to within it's metadata. On DFS, and older ADFS, the now File Type metadata space which RISC-OS uses was actually used to store a file's Load Address and Execute Address. This allows star-commands like *Load and *Run to operate without the end-user needing to know either of these addresses, but these star-commands also allow the end-user to load programs into any address if they know what they are doing. It is a rather flexible system that caters to both end-users who don't need to be bothered about which address something loads at, and for advanced users who need that extra ability to load binaries anywhere in memory. As you might have guessed by it's name Load will not execute any code, but merely just load it into memory. This is mainly useful to say load specific drivers at boot, or maybe even a screen image. The more useful boot methods follow. Next there is Run, which is set via OPT 4,2. This will do as you would except, it would not only load the binary image, but also begin executing code at the execute address. The final one is probably the most used one, Exec, which is set via OPT 4,3. This one works like a primitive shell script, but it will take each command from the !Boot file and insert them directly into the keyboard buffer. This is very similar to the EXEC command on the Apple ][ for those familiar with that platform. As you could except, this allows the file to run any command on the BBC Micro, such as CHAIN "MYPROG" which was the most common use for BBC BASIC programs.

All of these can still be set as I mentioned above on RISC-OS systems, and it is usually configured to use Run, not because the !Boot program on RISC-OS is an executable binary image, but because of how the new Run star-command functions. In ROM, RISC-OS has pre-configured File Types to assist the system in booting, and one of these file types is called the Obey file type, $FEB. An Obey file is a more modern take on the older Exec method which existed on the BBC Micro, and the Exec type still even exists on RISC-OS, if you so desired to use it.

The next concept carried over from the BBC Micro is the concept of holding a modifier key down on system boot or reset to perform a specific boot function. This key is none other than the Shift key. On the BBC Micro, if you held down the Shift key upon start, or via a reset via Shift-Break, it will use the disc's boot flag as mentioned above and use the aforementioned !Boot file upon start-up. On the BBC Micro, from my understand as well, is that there were a few DIP Switches under the keyboard which could be changed to ensure this was the default, and that holding Shift when set would instead disable this automatic boot sequence, allowing the user to troubleshoot. On RISC-OS, there now exists a CMOS RAM, and now instead of having to manually adjust DIP Switches, all you need to do is set a specific option there, which I will get to in the next section.

The other manual aspect of the BBC Micro boot process is the ROM order on your motherboard. It is possible to not load into BBC BASIC on start, but rather have another language, or even another program start-up instead. This was all controlled by where the user placed the individual ROMs in their BBC Micro. This can allow for say, a custom business application to immediate load upon boot, thus not requiring a bootable disc, or even a disc at all. It could load in a full screen file management UI, or even another programming language like ISO-Pascal. This feature also exists on RISC-OS believe it or not, but is now also configured within the CMOS RAM.

Initial Stages of RISC-OS Booting

To best follow along, it is best to have RISC-OS running next to you as you read through this post, as I do not post full script sources here. You should however be-able to follow along if you download the UniBoot ZIP archive. It should have a similar structure to what is being discussed here.

RISC-OS is usually stored on a ROM chip, with the modern exception of the Raspberry Pi where this ROM image is now stored and loaded from the SD Card. I won't go into how the ROM starts up, as I don't really know all the details myself, but at some point it will check various values in the CMOS RAM. One of the variables it will check is the one labeled Language, which can be configured via a star-command, *Configure Language <Module #>. You can view which one is currently configured on your own RISC-OS system via the *Status star-command. For example, on RISC-OS 5.27, if you do *configure language 19, it will be configured to use the BASIC ROM module on start. However, if you keep the *configure boot option enabled, it will still run your !Boot program, which is configured to start the desktop. You will also need to do a *configure noboot, and upon restarting, you will see the familiar BBC BASIC welcome prompt and be ready to type in some BBC BASIC code. This can of course be easily reverted, which I will explain in the next section here.

The other interesting option which can be set in the Language option is in fact 0, a zero. Again, if you have NoBoot configured in your CMOS RAM configuration, you will be presented with a different command prompt, the so-called Supervisor mode. This is the same command-line you get if you open a Task Window or simply press F12 on your keyboard while on the RISC-OS desktop. The neat part about Supervisor Mode is that you can still start the desktop, although it will not load any of your configuration by typing in desktop at the prompt. This can also work if you booted to BBC BASIC via *desktop of course too. If you do this, you'll see the most vanilla RISC-OS desktop experience, all it's glory from just ROM, and no additional modules, or patches. This mode can be useful in troubleshooting your boot process for example. There are some ways to inhibit this without needing to change your CMOS RAM settings. Documentation I've read seems to imply that using Shift-Break would turn off automatic booting, but I cannot seem to get this to work myself.

The variable which the ROM will use before transferring access to the ROM Module provided in Language is the FileSystem. Like Language and Boot, this can also be checked via the *Status star-command. Depending on how you are running RISC-OS, this will differ, and we won't be changing it in this post, but I will explain some of the most common ones you might see:

The !Boot Folder or File

In the root of your RISC-OS disc, there will normally be a !Boot folder. Normally if you try opening this, it will just launch the !Configure application. This can also be simple a file if you so choose, which can be useful for floppy booting on some emulators where a full !Boot Structure is too large. They both function in a similar way, but as you'd expect the !Boot Structure is much more complicated. To open this directory, you will need to hold down the Shift key while double-clicking onto it.

At first glance you might just assume that during boot the !Boot script in here will be called, but you'd be wrong. It isn't accessed until later in the boot process. The purpose of the !Boot file within an application directory is solely for the Filer to use to configure the icon and some needed paths for the application itself. During the boot process, the !Boot directory or file is actually Run, so the !Run file is what is executed in this directory upon boot-up, so let's dive into it.

Examining the $.!Boot.!Run Script

It would be best to use a proper editor to view these files, so before shift-clicking them open to read them, and also remember that, don't go double-clicking these files, although !Run here won't do any harm, as it will just launch the !Configure application. Locate and launch !StrongEd if you have it, as it will highlight these Obey files making it easier to read.

The first line is RMEnsure UtilityModule 3.10 Error ..., this one is very easy to understand. If the user doesn't have this version of the module, then show them this error message. In this case, it is checking to confirm that you are running RISC-OS 3.10 or higher, and displays an error and stops if you aren't. I won't be explaining each and every call to RMEnsure in this post, as there is A LOT of them, if you want to understand what that module does, look it up, and look at the error message also returned on that line.

The next set of lines are as follows:

Set Boot$Dir <Obey$Path>
Set Boot$Path <Boot$Dir>.
Run <Boot$Dir>.Resources.!System

This configures some system-wide variables, similar to what other operating systems call Environment Variables, but RISC-OS uses them extensively, like on steroids, literally! You can view all of them from the command-line via the following star-command, *show, you can even choose to see only certain ones via a simple wildcard, *show Boot* for example. The Boot$Path, or rather the $Path suffix is actually very special in RISC-OS. For example, if you typed in right now *Filer_OpenDir Boot:, guess what this will do? If you guessed opened up a window to the directory pointed to by this variable, then you'd be right! This is rather nifty feature in RISC-OS, and is used throughout the Boot process as you will come to see, so do keep a note of it.

In the next section, I will go through the !System part, but let us first continue going through this file first. The next section after this is as follows:

RMEnsure SharedCLibrary 5.43 Error ...
/<Boot$Dir>.Utils.BootVars
If "<Boot$State>" <> "desktop" then Obey -c <Boot$Dir>.Utils.BootRun else Obey -c <Boot$Dir>.Utils.DeskRun

The first line I explained how it works before, it just ensures that you have a specific version of the Shared C Library available before continuing. The next line might at first look a tad odd, but it is essentially *Run, which according to the documentation can be shortened to just a /, but personally I think there is a bit more going on under the hood here, as then why aren't all *Run in the boot process replaced with /, it seems that while it can act as *Run, I also believe that it may bypass the internal file association system in some regards, namely for these Absolute file types which are always loaded into 0x8000 in memory. I'm not entire sure if these files can be executed through *Run or not yet, but keep that in mind just in-case that is the reason. Anyways, this line starting with a / will execute this binary program which I am unsure what exactly it does, as it's a binary, but it implies that it configures a bunch of Boot Variables. The final line is how the !Configure application is run if you double-click it on the desktop, while on the other hand, if you are not on the desktop, then it will continue the boot process by running the aptly named BootRun Obey Script. I will go through this script in a later section as well.

Okay, so now that the main !Boot.!Run script is out of the way, let us continue to the various scripts that are run from this script.

$.!Boot.Resources.!System.!Run Script

The Resources directory here is it's own beast entirely, and perhaps I will go into more detail of the rest of it's contents in a future post. For now, we are going to be focusing on the !System directory here, so give it another Shift double click to open it up.

As the initial !Boot.!Run script mentioned, the !System directory is run, which is important to remember, so the !Boot script in here is not yet executed. This script is fairly long, as it contains a lot of RMEnsure commands to make sure that a bunch of loadable ROM modules are properly loaded. Think of this part of the boot process where the operating system, such as Linux, is loading all of it's kernel modules. These are somewhat similar in concept, but also very different. I won't be getting into the differences in this post however. Here are the first few lines:

If "<System$Dir>" = "" Then IconSprites <Obey$Dir>.Themes.!Sprites
WimpSlot 20k 20k
Set System$Dir <Obey$Dir>
/<System$Dir>.SysPaths

This first line first checks if essentially this script has ever run before, and if not, it will load in a bunch of Sprites from the Themes directory located within this !System directory. This is just the Icon which will be displayed as the !System directory within the RISC-OS Filer, every application does this, it's nothing special.

The next line *WimpSlot command will allocate some memory in the GUI system, in this case a minimum of 20k and a maximum of 20k, for which I'm honestly not sure why, it just does.

I shouldn't need to explain the *Set here, as I did before.

The final line here will run a BBC BASIC program. Yes, you indeed heard me right, this boot process actually runs BASIC programs as boot scripts, which works rather well it seems. You can check out this program via the regular Shift double-click if you are curious. From my understand, it configured a bunch of paths, and I won't be going through it in this post. All that you need to know is that it configures the system variable System$Path with the following on RISC-OS 5: Sys:500.,Sys:370.,Sys:360.,Sys:350.:Sys:310.,--RootFS--:$.!Boot.Resources.!System.

The next thing I should mention before diving into the next sections of this code is that there is another interesting feature to system variables with a $Path suffix, is that they sort of do work like a traditional $PATH or %PATH% variable on other operating systems, where they are a search path, but a customizable one. If you try and use the filer to open this, *Filer_OpenDir System: you will only be presented with the first one in the list, Sys:500., but to scripts, they see a combined structure, allowing for scripts to do what you'll see next here.

The section directly after this is a bunch of conditional checks for the current RISC-OS version stored in the Boot$OSVersion system variable, and performing various RMEnsure calls based on the OS version. Each of the modules it will load are located within one of the directories within the System$Path variable as mentioned above. This allows a module to be easily loaded regardless of what version of RISC-OS is being booted. Again, I will no be going through each module being loaded, just take a look for yourself and it should be easy to understand what each one does. In a lot of cases here, they will be replacing some of the modules which are built into the RISC-OS ROM image itself, as a way of patching the operating system. The !System directory is essentially a way to patch the system ROM upon boot with additional features. This system variable is also used by some programs to load modules on-demand during their start-up, and so some applications may request that the user merge a provided !System directory with the one in their own system. The !Configure program in the System icon provides a System Merge tool for this exact purpose.

$.!Boot.Utils.BootRun Script

Okay, so now we've made it to probably the most complicated part of the boot process, this is where the desktop finally gets initialized and the user will soon see a GUI! Let's explore the first few lines first:

FX 247 2_10101010
FX 229 1

These two lines are what are called OS_Byte calls, low-level operating system calls which are exposed via a nice command-line front-end via star-commands. Both of these are also available on the original BBC Micro believe it or not, which is also another reason why I started this post talking about that older system. The first will disable the various Break functions, so that during this process, the user cannot press any of the Break combination keys. It is set via a binary, and here's how to decode it:

Knowing those details, here is what you can set each binary bit to for each of the following results:

So, as you could probably figure out, it places each of these into No effect, disallowing the user from using these keys during the boot process. Neat! This can also be used in user programs and of course in BBC BASIC programs.

As mentioned the second line disabled the escape key function, which is normally used to abort almost anything, including scripts like this. A 1 will disable this functionality, while a 0 will enable it. At the very end of this script, the reverse is performed to re-enable everything once the desktop is up and running, and so I won't explain the final *FX commands in the script in this post.

Let's move on, here is the next set of lines:

If "<Run$Path>" = ",%." Then Set Run$Path <Boot$Dir>.Library.,,%.
If "<Run$Path>" = "..." Then Set Run$Path ...

I didn't include the full second line, as on modern RISC-OS the second line is never actually true so that version of Run$Path is never set. This system variable is special in that it acts more or less similar to the typical system path found on other operating systems. This is where your commands entered into the star-commands prompt will be checked. On the BBC Micro, this was called the Library, which also exists in RISC-OS, as you can see here by the % symbol which actually means the system library, if it's set. So, this line will configure the system run path during this part of the boot process to look in $.!Boot.Library, the current directory, and in the legacy library. In some older versions of RISC-OS, this Library directory actually contains some new and upcoming ROM-based star-commands, such as the now built-in Do, Repeat, and AddApp which you will see shortly in the boot process.

The next set of commands will RMEnsure the BootCmds module, which is where the aforementioned Do, Repeat, and AddApp are held.

I'm not entirely sure yet how the Boot$ProgressLoad and Boot$ProgressRun system variables are used, as I don't see any boot progress during system start. Although, they are unset on modern RISC-OS, including my version.

The next set of RMEnsure commands are specifically for versions of RISC-OS lower than 5, and since we are exploring modern RISC-OS 5 boot here, they are of no concern to us.

I don't personally have a !Territory application in my boot directory, but this would be executed at this point if you did.

The next set of commands relate to configuring memory within the GUI, or the WIMP:

WimpSlot -next 256K
FreePool
AddToRMA 768K

I omitted the conditional If statements as they check if we are running version of RISC-OS 3.50 or greater. If you'd like to understand what these do, these star-commands are well documented and aren't really of a concern to this post. You can use the *help AddToRMA for example if you really want a description.

The next three lines add new Aliases which we haven't yet covered, these act like Aliases from the DOSKEY era of computing, where you can store short commands in memory that you can type in as shortcuts to run macros and such. Here they are temporarily used to allow more verbosity during the boot process in the case that something might go wrong.

The next set of Alias$@LoadType_??? are very special in RISC-OS, and they control what the *Load star-command does. In this case, it will actually call the previous created aliases to run various programs, modules, and scripts. At the bottom of this script they are set back to the original system values.

The /<Boot$Dir>.Utils.HOn is used to turn on the mouse cursor and change it into an hourglass to let the end-user know that the system is booting up and to wait.

The next line /<Boot$Dir>.Utils.SetChoices is yet another BBC BASIC program, which configured a few system variables, namely the Choices$* ones. Choices in RISC-OS are essentially user application and system preferences. There is a variable called Choices$Write, which is where all your personal and systems settings will be placed. You can easily view this via *Filer_OpenDir <Choices$Write>. The most interesting part about this variable is that it can in theory be stored anywhere, such as a RAM Disc if you don't want anything to persist, or even a network share. Applications will usually use Choices$Path as a way to potentially load some default settings, although it seems this is only really used for the Boot application, as this system variable contains the following after boot: Boot:Choices.,--RootFS--:$.!Boot.RO520Hook.. To this effect, you can also see the choices via *Filer_OpenDir Choices:.

The other thing that the /<Boot$Dir>.Utils.SetChoices program does is set up these system variables Boot$ToBeLoaded and Boot$ToBeTasks, which will be referenced later in the boot process. These point to some other boot files located in <Choices$Write>.Boot.

The next line in this script which will be covered the following section is BootObey Choices:Boot.PreDesktop, which performs some tasks before the desktop itself is started.

The next line here will configure the System Scrap which is more or less like a temporary directory like /tmp on UNIX-like systems, where applications can store data for either temporary use, or for when they exchange large amounts of data with another application. In theory, this could be placed onto a RAM Disc to potentially increase the performance of some applications. Because this does a conditional check specifically for <Wimp$ScrapDir>, you could easily have it register a different Scrap application you've placed into a different location.

The next directory will configure the core Internet applications, this will run the $.!Boot.Resources.!Internet.!Boot, which do some configuration of various networking tools such as ifconfig, ping, etc...

The next three lines, also related to the Internet will configure the default MimeMap settings, and load a module for it.

Okay, we're almost done with this script. The next two lines will iterate through a specific directory, !Boot.Choices.Boot.PreDesk:

Do Repeat BootLoad <Boot$ToBeLoaded> -files <Boot$ProgressLoad>
Do Repeat BootRun <Boot$ToBeLoaded> -directories <Boot$ProgressRun>

These two lines will iterate over all of the files and then directories in the $.!Boot.Choices.Boot.PreDesk directory. This is where you could boot some start-up scripts of your own that need to be loaded before the desktop is run. I won't be going through the files and directories located in here, as they can vary from installation to installation. Some system applications, such as the monitor configuration will place it's setting here, namely into the Configure.Monitor Obey file.

It is also important to note that if you do add a script here, how it will be executed, here is how each will be run:

Based on the file-type, it will be run in a different way, here is how some common types will be executed by the system here:

Other file types may work, but these are the one's specially configured within the boot process to be a bit special. If you run any other file-type, it may not work as expected during the boot process.

For directories located here, the !Run file within that directory will be executed as it normally would using the standard *Run <Your Directory>.!Run. To check yourself how a file type might run in a directory, here's how you can check via star-commands:

I omitted some file types from the previous list as they do not have any Alias$@RunType_???, and thus I am assuming they would be invalid. While Sprite does have a RunType, it will launch a desktop application, which if the desktop isn't started would probably cause problems, and I don't think a !Run should ever be a Sprite... Even a module a bit farfetched for !Run, as it should be loaded properly through an Obey script.

The section after these in the script we were following will revert all the file types back to the system defaults before actually starting the RISC-OS desktop! Yes, we're almost there!

The very bottom will set up the AppSize, which will shrink the RMA memory size to it's smallest amount, and is only used during the boot process to perform that exact feat.

The next three lines are the FX star-commands to resume Break and escape before moving onto finally starting the RISC-OS desktop itself:

FX 247 1
FX 229 0
/Choices:Boot.Desktop

This last line can also be written as *Run Choices:Boot.Desktop as you probably know by now, the reason I am mentioning this very specifically, is that this is a very special file with a special file type. The File type name is Desktop and while it is mostly formatted like an Obey file, it gets run in a different way. Let's quickly examine the Alias$@RunType_FEA which is Desktop -file %*0. This in effect will run that Desktop file above by passing it as a parameter to another star-command, *Desktop, which I mentioned way earlier in this document. Now, do you understand why I brought up the boot process like the Supervisor Mode above? This was way, as the same star-command you can use from a fully command-based RISC-OS is also used during the boot process to actually start the desktop itself. This is why if you set *Configure Boot, even though the *Configure Language isn't that of the Desktop module, why it will still launch the desktop.

$.!Boot.Choices.Boot.PreDesktop Script

Okay, but before we can explore how the Desktop script works, we need to take a step back and continue through all the other scripts which I mentioned in the BootRun script.

The PreDesktop script works more or less like an old school AUTOEXEC.BAT, where it runs a bunch of commands before your Windows desktop might run. So, let's quickly go through what this script here contains.

The first section is dedicated to setting up a bunch of theme related variables for the eventual desktop. Themes can be set in RISC-OS 5, and their settings are stored into Choices:Boot.PreDesk.ThemeSetup. If you've been paying attention, you'll also realize that this script here is actually called a second time later in the BootRun script, so I do personally find it odd that it is manually called here, but I'm sure it's for a reason. However, there is something that other script doesn't do that is done here in PreDesktop and that is to configure the !ThemeDef application with all the currently installed themes.

The next section sets up some default system aliases, and provides some examples of aliases you could add here yourself.

Then there is a section for setting up additional paths, which I've mentioned a few times in this post and how those work. You can configure additional ones here if you please.

RISC-OS has a huge assortment of options for various applications, and this is generally the section where you'd place those. In my current configuration, there is only one to configure the country, which is also configured through the Keyboard Configuration tool in !Configure.

Okay, so do you recall my post from yesterday about the so-called Apps icon in the Icon Bar, and that it can be configured via the !Configure program via the Boot icon there? Well, this section is why adding new app directories is located there, as it is a part of the boot process, which I will actually list here:

IfThere Boot:^.Apps then AddApp Boot:^.Apps.!*
IfThere Boot:RO520Hook.Apps Then AddApp Boot:RO520Hook.Apps.!*
IfThere Boot:^.Printing.!Printers Then AddApp Boot:^.Printing.!Printers

Below this will be any of the apps or directories you may have added via the !Configure application. And that is the end of the PreDesktop!

$.!Boot.Choices.Boot.Desktop Script

And finally we come to the RISC-OS desktop portion of the boot process. As mentioned in the BootRun script section, this is executed as *Desktop -file <Boot$Dir>.Choices.Boot.Desktop, which has the side-effect of actually starting the Desktop module with this file as it's configuration script. Let's examine it's contents.

The first section of to finalize the loading of the desktop theme, such as loading in the theme's sprites.

The next section will iterate through all the previous RISC-OS version resources and load them in starting with the most recent. This also uses the Repeat, but there is a notable absence of Do as the previous calls had. This is due to that now we aren't needing to output any special characters out to the screen, as we are now on the desktop. The Do command will actually process the command through a special OS API called the GSTrans which is responsible for converting specific characters on the output stream from my understanding. I will put one of the lines here to explain it in more detail:

Repeat Filer_Boot Boot:RO500Hook.Res -Applications -Tasks

I specially chose RO500Hook over the newer RO520Hook as it is really the only directory that actually has any files in it. This Repeat command will iterate only through the applications, launching them into separate tasks as it goes along. Currently, there is only a single application in here, the !Configure application. There is also a subdirectory called Configure which contains all of the control panel programs seen in the !Configure application. I'm not currently sure if Repeat if recursive, and also runs the !Boot program in all these control panels as well, but I am guessing that it must, as those files do load in the various sprites for their icons.

A line after these will then run the !Boot program in each of the applications within the $.!Boot.Resources directory. As these can differ between RISC-OS installations and aren't a part of the core boot process, I will not be going through all these Resource applications here.

Then the !Boot program found inside the !Boot directory is executed, which will ensure that it's icon sprite is correct when you open the root of your disc.

This next line which I will also show will perform a *Run action on all the files it contains, the same that I mentioned above for these sort of file types also applies here:

Repeat Filer_Run Choices:Boot.Tasks -Tasks

Here is where you could set-up some additional tasks to run after your RISC-OS Desktop is up, such as opening a default set of Filer windows or even applications. In fact, RISC-OS provides this facility natively without you needing to write any script files. I'll explain these in a later post when I cover earlier versions of RISC-OS for completion. I will however make note of some very special files in this directory:

The next section in this file will check some special locations on your disc and boot up all of those applications so that RISC-OS is aware of them. These are the Utilities, and Printing directories.

The next two sections are actually from the Look At, and Run icons from the Boot icon within !Configure. The Look At, or as the window title bar says Boot at startup are a set of applications which are both added to your Apps icon, and their !Boot file is run. The Run, are applications which you would like to run on start-up alongside the desktop. One example for the latter is a clock, or the !Organizer application.

The next part configures the name server resolver via the !Internet application, if the appropriate alias has been created. This is located here in the boot process because the DHCP client is actually located just above in the Run section, where I mentioned you may also run a clock as an example.

Okay, we're nearing the end of the entire RISC-OS boot process! Huston! We've got RISC-OS Desktop! So, the next line turns off the hourglass mouse cursor to let the user know that their desktop is ready for use. Here are the final lines of the desktop booting script:

/Boot:Utils.HOff
if "<Wimp$Font>" <> "" then /BootResources:Configure.FontChange
IfThere BootResources:Configure.!InetSetup Then Filer_Boot BootResources:Configure.!InetSetup
IfThere BootResouces:!Configure Then ...
IfThere BootResouces:!Configure Then ...
WimpSlot -next 640k

Here after the hourglass is turned off, it will check for a font, and configure a font change if needed. It will then run the !Boot program in the !InetSetup application which will configure it's own directory system variable along with loading it's icon for the Filer.

Those next IfThere lines which I truncated will enable the CMOS file type, so that you can save and restore your CMOS RAM settings easily.

Then finally because the boot process comes to end, it configures the memory for the next Wimp task to be 640k of memory.

Conclusion

Although the RISC-OS boot process can be a bit confusing to someone who may not really know the operating system. It is rather well built, and provides a lot of customizability at almost any point via custom scripts or programs. I hope that this post has clarified the entire process for you, and while I didn't go into each of the smaller applications within the process, after reading this, you should now at least know when those programs are run and how they are run.

Happy RISCing!

#booting #riscos