25 years of Elite.

The BBC website has a page dedicated to the 25th anniversary of the computer game Elite.

This game, created by Ian Bell and David Braben in 1984, has to be one of the best games ever. In it, you play the captain of a Cobra Mark-III spacecraft, flying around space either trading or fighting. The 3D-wireframe graphics were very advanced for the time, and had a definite wow! factor. A novella, 'The Dark Wheel', was released with the BBC version by science fiction author Robert Holdstock - this was virtually unheard of for a computer game.

The game was revolutionary in several aspects - most games before Elite were heavily scripted, with linear game flows. Instead, Elite was open-ended. You could fly around the star systems of eight massive galaxies, either trading or shooting other ships. There were various upgrades that you could buy for your ship, including items such as fuel scoops or the near-obligatory docking computer. All of this was fitted into just 32kB on the BBC B. It was a superb feat of programming by Braben and Bell.

Unlike most games of the time there was no score - instead, the aim was to become 'Elite'. Initially you started off as 'Harmless'. As you destroyed other ships, your ranking would grow, through 'Mostly harmless' (a reference to the Hitchhiker's Guide the the Galaxy, perhaps?), to dangerous, and then finally Elite.

I dread to think how many hours that I have spent playing the game. I became Elite on the BBC Master 128, and also on the superb Archimedes version, ArcElite. Over the years I must have spent hundreds, if not thousands, of hours have been spent pretending that I am some superb space-trading pirate.

It very much got me into programming - I remember programming spinning wire-framed 3D objects, initially in BBC Basic and later 6502 assembler. It also gave my imagination a spur - my friend, Jamie, and myself would pretend to be spacemen whilst it loaded off tape. I doubt any children would do such a thing nowadays, if only because most games now load almost instantaneously.

Last year Şencan and I attended a meal celebrating the 30th anniversary of Acorn. It was good to see so many old faces, including some people that I had not seen for many years. David Braben was there, and he gave an impromptu demonstration of docking on a BBC B that had been put on display. It is a sign of the almost mystical aura around the game that he had a large crowd around him as he did it.

If you wish to give it a go, have a look at Oolite, which is heavily based upon the original game. I deliberately do not have it installed to avoid wastage of too much time.

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.

Seeing my name in lights

A long time ago, another life really, I worked for Acorn Computers in Cambridge. Whilst there I did lots of interesting stuff - Internet Computers, Internet Access modules for televisions, work on build systems; all stuff that, looking back was fun and good.

Well, Acorn went bye-bye ten years ago, but Pace (the Set Top Box makers) took over the part I worked for. They kept the Acorn Operating System, RISC OS, going. Then, in 2002, it all got cancelled.

Now, I really liked RISC OS. As an operating system it was very easy to use, with some features that are still not in Windows or Mac OS X (such as right-clicking on windows furniture causing the inverse effect). I still miss it. I've got a computer capable of running RISC OS somewhere, but I haven't started it up for years. I could run it on my PC using an emulator called VirtualAcorn, but it seems pointless. My memories will probably be better than the experience.

Pace canned their work on RISC OS in 2002, and with it went any realistic chance that RISC OS had as a mainstream operating system. However, it still has its fans, and new versions were produced by several companies. The ownership of the code became a thorny and complex issue, one which I believe had not been fully ironed out. The source code was open-sourced a year or so ago, and today I went to have a look at it. I was somewhat surprised to find my name in a few places.

The following is a commit log I made into the source control system. See: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/ARM600

Summary:
Fix to bugzilla bug 4065

Detail:
1MB VRAM was not being correctly identified. This was
due to register corruption in r12 in the VRAM detection
routines in s.ARM600. This bug has been a longstanding
one introduced in Kernel 4.69 two years ago.

Admin:
Been put through the Kev&Mike change control process
(tm).

Version 5.40. Tagged as 'Kernel-5_40'

This was apparently seven years, eleven months ago. How time flies.

It would be interesting to know who owns the copyright of the text above. I originally wrote it, but it would have belonged to Pace, who I was working for at the time. That code was passed onto two different companies, one of which open-sourced the code. The relevant licences are fairly heavyweight, and the chain of ownerships and rights complex.

I spent half-an-hour this afternoon looking through some of the source code, the first time for nearly seven years that I had really studied it. I guess this must be what it is like for an author to go back and read something he had written many years before; a creeping sense of joyful familiarity. Or perhaps it would be better to say an editor, as most of the work I did were in areas of the code that are not in the public domain. I have read over most of the code many times in the past, either sorting it out for putting into various build and versioning systems, merging code, searching for bugs, code reviews, or just for pure intellectual interest.

There was also a short document that I wrote back in 2000. We had a project to build a low-cost, ROM-based Internet access computer (which eventually became the Bush Internet TV). The customer wanted to support many different countries - Turkey, Germany, Spain, and others. This meant we needed many different languages, and as there was no disc, it had to be done in ROM, which was short of space (message translations are invariably large).

I looked at this problem on-and-off as time permitted, and I took the notes with me when I went on a walk through Scotland (the same walk where I met Sam). One wild night I pitched my tent on a boggy stretch of ground on a beallach, got my notebook out, and worked out an answer.

People often say that getting away from a problem can help you find a solution; on that occasion I think I took it to extremes.

Whilst looking into all of this I found a webpage that showed an Easter Egg (a treat hidden within the software). In this case it was a photo of the development team and, yes, I'm in it. What's more. I've actually got the original copies of the photos somewhere.

It really feels as though it was a different world. The technology has moved on so far in the last seven years. What we were trying to do then - low cost devices for Internet access - are now coming onto the market in the form of Netbooks. Some of these use the ARM chip, although these use the Linux operating system. I wonder if anyone will try and port RISC OS onto them? If so, I can see myself getting one, just to use a real Operating System, and one that I contributed to in a a little way.