The death of RISC OS

RISC OS was an operating system developed by Acorn Computers to run on their ground-breaking ARM chip in the late eighties. It went through many different versions in its 14 or so years of mainstream life, before being dropped by Acorn's successor, Pace. I was there right at the end, and it still hurts.

I shall start this story in 1996, just before I joined Acorn. The company had been split into two different business units - Acorn Risc Technologies (ART), who developed consumer-based computers, and Online Media (OM), who developed Set Top Boxes. Both these units used ARM chips, much the same hardware, yet were not allowed to share technology. The source code of RISC OS got forked.

Just before I joined the company, the folly of this was realised and the two business units were merged into one. However, the source code remained forked. Over the next few years and, I, along with various other people, merged those changes back into one tree. It was a process that was still not fully complete four or five years later, as the process was done in a piecemeal, as-required manner.

The consumer-computer part of the company was canned in 1998, along with a new computer, the RISC PC 2, (or Phoebe) project. However, the Set Top Box and Network Computer parts of the business were kept, and that was the part I was in.

We had a big contract with a Japanese company, Funai, to whom we delivered a series of projects - I think we got to seven or eight in the end. Funai 1 was a basic Network Computer, Funai 3 was one with two smartcard slots, and I think Funai 4 had an email client. My memory is hazy about the other projects.

Then we got a contract to produce an Internet Access Card (IAC) for a television. The idea was that many people did not have computers, but wanted Internet access, so why not build Internet access into a TV? We worked on this, and at the end of the day we produced a viable, solid product with in-built Modem that displayed well on the target TVs (manufactured at Vestel in Turkey). The initial product sold poorly, but confidence appeared to be high, and we were working hard on the successor projects, Bethany and Martha.

(A word on the naming schemes. The original IAC project was codenames Lazarus, as it arose from the dead. The successor was called Martha, after Lazarus' sister. Bethany, the successor project using vastly improved technology, was named after the place that Bethany and Lazarus lived.)

Then Pace canned the project. Various reasons were put forward for this, but I was told that the Network Computer work had actually made a large profit the previous year. Various reasons were given. The first was a potential lack of future business; as far as I am aware, that was far from the truth. The second was that we were not a core business for Pace, which was undoubtedly true. The third, and in my opinion the most realistic, was that Pace had trouble recruiting engineers, and needed us. There were no redundancies, and I was moved over to work on a Set Top Box for a Portuguese broadcaster using Windows CE and MS TV.

RISC OS was canned just as some significant improvements were being made to it. Much of RISC OS ran in the ARM chip's 26-bit mode. Later versions of the ARM chip did not have this throwback, and were fully 32-bit. For this reason, many parts of the OS that were written in ARM Assembler either had to be fixed or rewritten in C. (For more details on this, see a document by Paul Skirrow). There was no great pressure from the management for this to be done, but a talented (no, genius) engineer did it as a skunkworks project. I sat in the same cubicle as him at the time, and in the corner there was a prototype ARM development board. This frequently had oscilloscopes or logical analysers attached to it as the engineer tried to find the sources of bugs.

Much of the Kernel of RISC OS and other parts of the the heart of the system were written in ARM assembler, some by people who were actually involved with the creation of the original ARM chip. Because of this, the code was very efficient, and in places hard to alter. Efficiencies in terms of speed came at the expense of maintainability of the code.

One of the biggest problems with selling RISC OS-based systems to third parties was, strangely, the development tools available. When compared to software tools such as Microsoft's Visual Studio, the development environment was poor. We had a very good C compiler (based on Norcroft C), a very basic, bare-bones C++ compiler (based on CFront), and a debugger that did not cut the mustard. Having said this, it was relatively easy to develop for, especially when you had the experience.

The problem lay in getting that experience, and Acorn was lucky in the fact that many kids had grown up in schools programming on their systems, and had used Acorn systems at home. Many of my colleagues were in their late twenties and early thirties and fitted this mould. However, this was not of much use for third parties who may have wanted to use RISC OS. They wanted a nice, shiny development environment for their engineers to use, and we could not offer them that. The management did talk to various providers, including ARM, to see if we could use their development kits, but the talks got nowhere for various reasons.

I still remember the Monday morning when the engineer announced that he had a basic 32-bit Kernel working. We all crowded around to see his work. It was basic, but it was a start. What had started as a side project by one engineer became slightly less unofficial, if not quite official. Over time, more and more modules (distinct, separate parts of the OS) were converted to 32-bit. Modules that were written in C were fairly easy to convert; the compiler was altered, as was a shared library for C applications. The assembler was a different matter, though; each module had to be converted by hand.

We got that 32-bit build up-and-running on a Lazarus board (the board that went into the Alba Internet TV); I still have that board in storage, with that build on it. This build was easier than those of a desktop PC, as the Lazarus board was far less complex than a PC.

A couple more good engineers got involved, and slowly more of the OS was converted. The hardest part, so I recall, was ADFS, part of a filing system. This proved very difficult to convert to 32-bit due to the lack of available registers. In the end it was done, and just as they started looking at the creation of a Hardware Abstraction layer for newer hardware, Pace cancelled all work on RISC OS. It was a terrible time. On the day of the announcement a bunch of us went out to the Fort St George pub by the River Cam and got very, very drunk.

RISC OS lived on. One company, RISC OS Limited, had already licensed some old 26-bit sources, and these were released as RISC OS 4 for existing Acorn computers (Risc PC, A7000 etc). Variosu other incremental improvements came over time, but then something really exciting happened.

Castle, a long-standing company in the Acorn field, managed to licence the 32-bit sources for RISC OS off Pace, and released a computer (the Iyonix) that used the much faster XScale processor. This continued to be sold, until it was end-of-lifed last year.

This led to a split in the RISC OS world - Castle, with much newer (and in my opinion better) underlying technology. This included full 32-bit compatible code, and many improvements we had made at Pace. On the other side of the split was RISC OS Limited, with older sources, but many new UI improvements. It was a fork in the sources that has still not been resolved.

Here the software versions become complex. RISC OS Limited released RISC OS 4. Castle released RISC OS 5 on the Iyonix (with a new HAL and 32-bit). Later, RISC OS Limited released RISC OS 6, with other, mostly incompatible improvements. The fork in the sources got larger, and the resources available to RISC OS got more divided. It was ART and OM all over again.

Then a deal was done to open-source Castle's version of RISC OS 5. RISC OS Open Limited was set up, and now they can apparently build an Iyonix ROM image. Third parties are altering the code base; adding applications and fixing bugs. RISC OS lives, just.

Unfortunately, and with regret, I have to say that RISC OS is now firmly in its old age. It is sitting comfortably by the fire, slippers on its feet, telling anyone who'll listen about the glories of it's youth. The youngsters - Linux, Symbian, Android, and others - somewhat reluctantly gather around the fire to listen to the stories. Even Windows joins in, although he is really an old-timer that has had many facelifts (or, more accurately, an old-timer that regularly gets rejuvenated at the fountain of youth).

RISC OS is still a good system for low-cost, embedded systems, but the world has changed around it. In the last decade computing resources (memory and processor power) have become so cheap that the baseline for a low-cost system has increased massively. In the world where my camera has a cheap, 4GB Flash memory card, why do I still need my OS to fit in 2MB (or 1 2,000th of the space?)

These resources meant that it is much easier to use other cut-down full computing systems, such as Linux, Win CE or even Win XP on these devices. They are known, reliable systems, are portable between different platforms and have many engineers who know and understand them.

There is still a need for very small, cut-down OS - for things like controlling washing machines, where few resources are still available. However, RISC OS has never been the sort of OS you would use for these applications.

RISC OS is being squeezed from above and below. Unfortunately, and with regret, that is why I think it will die. True, now it has been open-sourced I think that it will continue being a hobbyist OS, perhaps even one that will be popular. However, the time is probably past for it to get a new lease of life by being incorporated into mass-market consumer products.

I hope I am wrong, and some talented people are working hard to prove me wrong. I wish them luck.

=========

So now for the second part of this essay. What could have happened?

In 1997 Acorn proposed a new consumer Operating System, Galileo. It was due to have some advanced features such as Quality of Service (QoS). This is a concept where high-priority tasks are guaranteed certain system resources that they need. Try watching video clips on YouTube when your system is running many different tasks - the video regularly become jerky. A QoS Operating System will guarantee that the video has enough resources (such as memory and processor power). There was also a new module microkernel, a vast step up from the efficient but hard-to-maintain RISC OS Kernel. Pre-emetive multitasking also featured. It was a neat idea for a company that was hoping to be big in the video on demand market.

Unfortunately, Galileo got canned in 1997, either shortly before or shortly after I joined Acorn. I remember seeing some demos of non-rectangular windows, along with reams of documentation. It is one of the great what-if moments in Acorn's history; not that Galileo got canned, that was probably the right decision; but what if they had decided to start Galileo a couple of years earlier? There are plenty of successful, niche market OS in the market - could Galileo have been one of them? There was an in-depth description of Galileo in a Byte magazine in 1997 - it still makes fascinating reading.

Another what-if: What if the resources that got put into Galileo (a largish number of extremely competent engineers) got put into RISC OS. What would I have done?

1. Rewrite the Kernel and other core OS parts in C
2. Create a Hardware Abstraction Layer (HAL)
3. Modernise the file system
4. Add full memory protection
5. Run the new RISC OS on a non-ARM system as a proof-of-concept
6. Get a modernised toolkit with improved debugger, and ideally given them out for free to interested businesses.
   
7. Produced new, improved Programmer Reference Manuals.
   

This would have give RISC OS the potential of extra life by removing the current reliance on ARM chips. Although it could be argued that the future for RISC OS lay in ARM chips, the creation of a HAL was necessary (and has since been done for the Iyonix), and the rewriting of the Kernel would have made the whole system much more maintainable, at the expense of a tiny amount of efficiency.

What I did not mention was turning the kernel from co-operative multi-tasking to pre-emptive multi-tasking. This change would have modernised the operating system , but would also have meant that many applications running on the ARM would have been broken. Whilst such a switch from CMT to PMT was possible (Windows did it from 3.1 to 95), I am not convinced that it was actually technically required for the markets that RISC OS was being considered for. PMT is best for open systems where users can pick and choose thousands of different applications to run; CMT may be better where a few, known applications are to be run (e.g. early STBs). This is only a rule of thumb, and it should be noted that a good CMT can be better than a bad PMT. Again, the definition of 'better' is also vague.

All of this is idle talk, because it never happened. If it had, though, would we be talking about RISC OS in millions of mobile phones instead of Symbian? Or RISC OS-powered notebooks rather than Linux or Windows XP? Who knows. All I know is that I miss it.