RISC OS

We often see both dyed-in-the-wool RISC OS users and outsiders suggesting that RISC OS ought to be ported to some ARM board they've just spotted.  Typically, this is some low-cost ARM9 or PXA-based PDA or perhaps a networking device. There are certainly some examples of this in comments made in articles on this blog, as well as this questionably RISC OS related item on IconBar.

Of course, it's all very easy to suggest that RISC OS ought to be ported to these things, and in most cases, the stock answer of effort and expense is the correct one. But why is this the case?  Surely we can just hack up a new version of RISC OS with the right drivers and have it just work on a shiny device. In practice, no - and I'd like to discuss why.

An ARM device

For the purposes of examing a real example, I'll consider the AirLink AR315W, an inexpensive wireless router that I picked up to use in its own right for my networking requirements. My choice of this device came down to price - around 16 UKP after P&P - and also an article on linuxdevices.com showing that it could be hacked to potentially run Linux or other OSes. Sadly, the page the article refers is now unavailable, but we can see that it contains an ARM9 Marvell part.

So could RISC OS be ported to this device?  In principle yes, as the existence of a Linux port demonstrates that sufficient information is available to develop drivers and provide other low-level information. The value of RISC OS on something without a display or input devices is perhaps questionable, but as we are examining this question in a slightly wider context of ARM devices in general, we'll ignore this detail. 

From the point of development, the amount of effort to convert RISC OS to a given device is quite large.  Unlike Linux, which has drivers for a vast range of hardware and has probably been ported to a similar device to the one you intend to target, RISC OS has only been targetted at a small number of devices and drivers.  This means a great deal of effort to develop new drivers from scratch.  HAL or no, this is lots and lots of programming.  If RISC OS were open source, then it's possible someone might be able to justify this as an enthusiast effort in their spare time, without having to answer to anyone.  But this is unlikely to happen any time soon.

It's true that you could obtain the source from Castle for development/evaluation purposes for no charge, but probably you would have to present some kind of business proposal to make it worth their time - and yes, it would be quite a lot of time to prepare what is essentially a software release, plus various legalities and other hoops.

I'll throw one further issue into the mix.  With unfamiliarity with such a large body of code, I would predict it would take myself, with my experience of operating system development, around 6 weeks to become comfortable enough with the code to start to be in a position to make the substantial changes required to port to a new system.  Vary that time as you see fit for different levels of experience.

A Real Product

So the problem now is that to justify the substantial time and effort to bring RISC OS to a new system, what's really needed is a proper product plan.  And likely to make any kind of financial sense, you'll have to sell at least several thousand of the device, if not more.  On top of that, RISC OS needs to make more sense on the device than competing options - we'll return to this point in a moment.

This is a problem which has plagued development of a RISC OS laptop.  It has been suggested that to make a viable product, around 1000 would have to be sold.  That might be possible with a cheaper desktop product such as the Iyonix (which also has applications outside the enthusiast market), but a laptop simply wouldn't have the same demand.  This is the major problem against a RISC OS laptop on top of all the other issues such as sourcing an appropriate case.

Suitability

Returning to the wireless router (which incidentally, I can certainly recommend after a firmware upgrade which fixes a connection dropping problem), and networking products in general, would RISC OS make sense over Linux or a custom embedded OS?  Probably not - once you have your Linux kernel port, it becomes very easy to arrange NAT, routing, wireless operations, DHCP, firewalling, a simple web server and everything else it does with a handful of commands on Linux.  True, some of this does exist on RISC OS, but much of it doesn't, and would be effort to add to the TCP/IP stack or port and hard to reach the same degree of flexibility in this area.  There isn't much competition here.

When RISC OS makes sense

Not to put a complete damper on all efforts, but there are clearly some instances where RISC OS does make sense on new ARM hardware in the shape of the Iyonix and the A9.  In these cases, the respective companies have software and solutions that work well for them and their customers on RISC OS.  Perhaps they have something that simply doesn't exist on Linux for practical, legal or political reasons or where space really is tight and a cut-down version of RISC OS is just the ticket.

So what should we expect to see RISC OS on?

That's a difficult question to answer of course - I have no idea of the plans of any of the RISC OS companies or the demands their customers might make.  What I can say is that I do expect to see RISC OS on more devices in future, but because of the reasons I've outlined, they're likely to be few and far between.