RISC OS Open: One year on - RISC OS News, Software and Information

RISC OS Open: One year on

Published: 21st Jul 2007, 23:16:47GMT Source: drobe.co.uk
By Martin Hansen

Page 1 of 1

As ROOL celebrates its first birthday, Martin Hansen studies the project's past and looks to the future

Opinion - It occurred to me this week that RISC OS Open is one year old this month. I checked by searching back through the news archives. Yes, there it is: the first proper mention of ROOL popped up on July 9 2006. That was an exciting moment. Unexpected too. Castle had taken the brave decision to begin the release of the RISC OS source code. ROOL, a new company founded by five experienced RISC OS enthusiasts, was the vehicle through which RISC OS source code would be made available to those who could handle it.

Anyone who wanted to was free to hack, modify, experiment and enhance the computer code at the very heart of the operating system. Good ideas, well coded, would be folded back into the source and so become a part of RISC OS. The ROOL team would oversee the entire activity and provide the system with quality control.

this should only have one candle in it, we know.

this should only have one candle in it, we know.

Opening up the RISC OS blue prints was a courageous initiative. From Castle's point of view, it was loosening the grip on a precious commodity, its intellectual property. Furthermore, it was a public admission that they were too small a company working too small a market and with too few resources to develop RISC OS further by themselves.

It can be a difficult thing to do, to ask for help. Many a business in the computing and electronics industry has gone bust through a combination of pride and failure to adapt to changing circumstance. Castle went through considerable internal agonizing before finally deciding to go down the shared source path.

When writing this article, I wasn't sure if I should emphasise that ROOL was one year old. It's so easy to slip into a negative mode of thought, and from such a position observe that after a whole year it is still not possible to run a version of RISC OS 5 on Iyonix that is better or fuller featured than that of a year ago.

History
The truth, however, is that the idea embodied by ROOL was reported upon at an early stage. It has taken a year to turn the idea into a workable practicality. Setting up a website to manage the system under which code could be accessed, worked on and returned was, I think, done quickly, yet professionally and to a high standard. Let us not forget, the enthusiasts making this happen, Steve Revill, Ben Avison and Andrew Hodgkinson, are doing so in their spare time.

Getting the wording of the conditions under which the source code would be released, in batches, took months. Castle, not unreasonably, wanted a modest financial return should RISC OS be used in a commercial product. That meant that a legal and properly worded license had to be drawn up. Better to get that correct at the start than to have problems later on.

A big time-eater must have been making sure that code posted on the ROOL website was legally theirs to give. All sorts of individuals and companies have contributed bits to RISC OS under various arrangements dating back years. ROOL have have to be careful not to take liberties with these previous agreements.

For my part, I feel quite positive about how ROOL is developing. The amazing fact is, that one year on, code is available. If the fact that the !Draw application features a "Save as" box that violates what is in the RISC OS 3 Style Guide bothers you, you can now get in there and sort it out. Being able to understand BBC BASIC, C and ARM assembler are the main requirements.

I suppose I can no longer complain about that "feature" in the !Chars application. The one that causes every press of the <shift> key to insert, into whatever window has the input focus, the random letter that happens to be under the mouse pointer. Given that <shift> gets pressed every time a capital letter is required it does not make for a good hot key which, presumably, was the original intention. Rather than complain, I can now sort it out for both myself and all other future users of RISC OS 5.

In more detail, the first batch of code published on the ROOL website featured utilities such as CloseUp and Chars, major desktop applications such as Paint, Draw, Edit and Pinboard, and large parts of the OS relating to the handling and integration into the system of a CD drive such as, for example, CDFS, CD device drivers and the CD filer. The BBC BASIC module is available in its entirety.

It is an encouraging first posting of material that was partly selected for the ease with which it could be made legally available and partly because even a less technically minded user would recognise what was being talked about and feel included. Opening up software successfully is all about inclusion.

Invitations
Steve Revill, one of the ROOL five, recently assured me that this was indeed the first of several postings of code that would be made available from the ROOL website. As well as simply posting the code on the website, the ROOL team have begun to actively invite specific people who might be particularly interested in enhancing particular pieces of code to do so.

They are thus enjoying a lively dialogue about which parts of the OS are particularly wanted and which would be enthusiastically pounced on once released. I asked Steve if he'd be willing to let drobe publish part of what was on the current ROOL "most wanted" short list. Here is what he responded with:

• Toolbox modules and associated libraries.
• Printer stack (USB printer manager, PDrivers, PDumpers, PDFs)
• File system stack (ADFS, SCSIFS, DOSFS, FileCore, FileSwitch)
• WindowManager, FilterManager, DragAnObject, DragASprite, SpriteExtend, etc

He further explained that selecting the next components to release was an interesting process. Components were having to be released in a sensible order.

He said: "For example, there's no point releasing the kernel sources yet because even if someone were to fix a bug or add an amazing feature, they could not, as things stood, softload it. Only once more of the OS sources have been released will it be possible to build a viable ROM image for which there are tools available for a softload".

There is considerable pressure on the ROOL five to keep the process zipping along and build on the interest and enthusiasm generated by the initial, official unveiling. They know that building up momentum and a sense that the ROOL initiative is taking off are important psychologically. The knowledge is driving the team onwards to get the sources fully released and a management system to routinely handle coders' offerings set up and fully operational.

Video
I was particularly interested to know what had happened to Tematic's Prism project. A couple of years ago I put out an article in Archive and this website on video playback under RISC OS. Sadly, capabilities in this arena have not moved on.

Cineroma continues to gather dust on its developer's hard-drive, and Adrian Lees encountered insurmountable difficulties in getting his Cino DVD player up to speed. Prism, you may recall, was an ambitious and official Castle/Tematic project to add multimedia support to RISC OS and which, allegedly, had resolved a lot of the problems that Cino was struggling with.

It was to be a part of their next-generation set-top TV box offering. Andrew Hodgkinson, one of the ROOL five, was fully involved with this project prior to Castle having to axe it in the autumn of 2005. Alas, the Prism code will have to stay under wraps for the time being due to the terms and conditions under which it was developed and financed. All of the ROOL team would love to see it released, but to do so is problematic. So, two years on, I still cannot unwrap those irritating Quicktime and Windows AVI files using RISC OS nor, if I could, am I likely to be able to play what is inside - which is a shame.

Help
Not everyone who wishes ROOL well is able to help by enhancing the RISC OS 5 source code. Encouragingly, ROOL are receiving offers of help with other aspects of the project, especially with the administrative side of the business. As ex-Acorn and ex-Pace engineers the ROOL five should ideally at some point be able to switch from the task of getting the sources released, setting up forums, and negotiating with potential developers by email, to being amongst those free and able to get stuck into the code itself.

Part of the quality control will presumably involve them having to help with the odd stubborn bug thrown up by new offerings and providing intricate help as a less experienced contributor struggles with a particularly involved passage of code. Their role will have to evolve as time passes.

The most exciting thing about ROOL is that it does have the potential to become big. RISC OS is now a small band of enthusiasts, and we are down, but with initiatives such as ROOL, definitely not out. NetSurf is a glowing example of what can be achieved by a focused and motivated set of individuals doing something for love rather than money. With just twenty coders working in their spare time, RISC OS 5 could really start to develop and move forward fast. It's taken one year to get the idea turned into a reality that is more professionally set up and managed than I thought possible when I first heard of it. I am optimistic that over the next year we'll start to see some significant progress being made.

Links
RISC OS Open website

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

IvanDobski (+1.0) 23/7/07 11:06AM	'If the fact that the !Draw application features a "Save as" box that violates what is in the RISC OS 3 Style Guide bothers you, you can now get in there and sort it out.' As mentioned here: [Link: groups.google.co.uk] You can't sort it out yet because RISCOSLib hasn't been released yet.
druck (+2.0) 23/7/07 1:30PM	Yes you can, as the issue isn't in RISCOS_Lib but in the Draw source and templates, so you can link against the already released RISCOS_Lib binary.
piemmm (+2.0) 23/7/07 1:40PM	Ouch, that style guide is a bit old now,... Alright it has served us well and it was a bang-up job when it was first created, but I still think it could do with updating... Suppose there are more important things to concentrate on first though...
VinceH (+2.0) 23/7/07 2:03PM	*In reply to piemmm:* Yes, there are areas where it can be improved etc - this has been discussed a while back, and I kept ringing Castle's email doorbell until I got an answer on the subject! The results of that discussion ended up somewhere in ROOL's forums - but I have to admit, I never really got into the habit of routinely checking their forums, and so haven't seen what has been said on the subject in the last however many months.
Stewy (+2.0) 23/7/07 2:47PM	A great article, Martin. Thanks! " I suppose I can no longer complain about that "feature" in the !Chars application." I should think not when the very wonderful XChars is available [Link: www.mw-software.com] XChars is much more flexible than Chars, and the more recent versions of XChars even allow you to save characters as Draw files which is a very natty feature. Highly recommended.
jb (+2.0) 23/7/07 9:41PM	*In reply to aw:* yours is the first mention of RISCOS Ltd in this article..??
AMS (+2.0) 23/7/07 10:30PM	*In reply to AW:* The primary benefit of the shared source initiative are the users (or potential future users) of RISC OS 5.xx - as such it has nothing to do with RISCOS Ltd. It does, however, open up possibilities for better exploiting and further expanding RISC OS 5. The other big plus is it gives more developers the option to update/upgrade or experiment upon the actual source. That may suggest as yet unthought of options in terms of new features or functionality. It may also mean that RISC OS 5.xx can be adapted to use newer or different hardware. How much of this can be acchieved is dependant on circumstances and also the ingenuity of the RISC OS developer community - on the whole I'd be optimistic.
pthw199 (+2.1) 24/7/07 12:02AM	The gradual opening of the RISC OS source certainly holds potential, and I think a necessary move as RISC OS moves further and further into an enthusiasts only market. Short of a huge influx of investment commercial I fail to see how RISC OS development can do anything other than continue to dwindle and so I feel that open sourcing the code can only extend the life of the OS itself. Allowing the enthusiasts to tinkle with the code will hopefully (eventually) allow features added as wanted by users, and increased hardware support. Of course, given that the OS has to be run atop of an ARM processing core vastly reduces the number of people who might enjoy tinkering so I have my doubts as to how many new people will come back to help develop the OS, and revitalise the user base.
bucksboy (+3.0) 24/7/07 10:37AM	Thanks for an interesting and informative article. The reference to the Prism project was particularly interesting, and frustrating in equal measure. I have used RISC OS as my main home computing platform for the last fourteen years, and although like everyone else I suffer from the well-known browser and multimedia shortcomings, thanks to the efforts of dedicated developers such as David Pilling, Martin Wuerthner, Dave Higton, Anton Reiser, Rob Davison and many others, the ability of RO to handle daily computing tasks and interface with other platforms has never been better or more complete IMO than it is now. If the same level of dedication can be applied to development of the OS itself, much can be accomplished. As to the ARM platform, the impetus to greater speed and power is clear, driven by ever more sophisticated hand-helds. We should not forget either that there must be many more ARM chips in daily use than any other platform, x86 included.
Jwoody 24/7/07 6:24PM	Well a year is quite a long time, it would be nicer if more of the source had been released by now. But I guess slow but sure is fine as long a Castle don't get cold feet. Personally I will feel more optimistic when all the source is released. At the end of the day its going to take a number of white knight to come along and devote time and energy developing for free. I have not noticed a great rush so far but I guess its still early days. At the end of the day my glass is half empty and I remain pessimistic no doubt time will tell.
epistaxsis (+2.0) 24/7/07 10:43PM	*In reply to Jwoody:* This has been said many, many times - the reason for the time to release issue is due to legal reasons as Martin mentioned in the article. RISC OS is from a very closed sourced background (which interestingly may not be as "one company"* as was tought), open sourcing in this instance is fraught with copyright issues. The last thing an open version of RISC OS needs is a legal battle! Better that this is done in a controlled and careful manner. In reply to bucksboy:* dammit! beat me by 2 yrs In my defense I'd wanted one since 1989...
AW (+2.0) 24/7/07 11:33PM	Personally if I was in charge at ROOL I could imagine making the raison d'etre to be discovering those hardware possibilities that would translate into a feasible computer project for Castle, as a matter of urgency.
stevek (+2.0) 25/7/07 7:45AM	The "killer" part of ROOL is unfortunately not the desktop market. The RISC OS desktop market is a good environment to test out ideas, new technologies, OS functionality etc but is ultimately a very small market. For this to work for Castle they need to sell STB devices in the tens of thousands, collecting royalities along the way. ROOL's roll in this is that it provides a mechanism for releasing parts of RISC OS to third parties so they can customise it to gain competitive advantage over other STB's. Opening RISC OS reduces the barriers that previously made this kind of thing difficult and gives STB makers more options. Lets hope a few jump on board. Still it is nice that anyone can make changes and improve RISC OS for the desktop market too. Time to stop posting on Drobe and dig out the C compiler!
flypig (+1.0) 25/7/07 11:27AM	Great article - thanks Martin My feeling is that projects like this need momentum. The more people seen to be working on bits of the OS, the more attractive it is to others looking to join in; hopefully building this up is just a matter of time. *In reply to bucksboy:* I share your desire for development of ARM hardware, and I hope given - as stevek points out - that the point of opening RISC OS was largely about attracting STB licences, that the project will also help drive native hardware too. I wonder whether the 'promise' of an eventually totally open platform is enough to attract STB makers in itself? One of the great things about ROOL is that the benefits will never go away; the code will always be available to look at and improve.
Jwoody 25/7/07 12:34PM	"stevek" "For this to work for Castle they need to sell STB devices in the tens of thousands, collecting royalities along the way." I am glad I am not a Castle Sales person. If I was a STB developer or in the market for one. I would favour Linux over Shared Source RISC OS by a mile. Things that come to mind immediately are, Multitasking, Non blocking I/O, ability to handle Video/DVD, development in C rather than ARM Assembler and Basic, availability of skills
Hairy 25/7/07 1:59PM	*In reply to epistaxsis:* Been using since 1992 Wink , Wink !!
flibble 25/7/07 2:46PM	stevek woody: Linux has a few other plus points. Portability between ARM/MIPS/PowerPC (most STBs seem to be one of these 3), allowing you to pick the cheapest core. No royalties at all. Incidentally the reasons you suggest are why of the last 10 or so STB reference designs that came through our office have had Linux on them (and gcc cross compiling based toolchains).
bucksboy 25/7/07 3:31PM	RISC OS vs Linux: I'm not a programmer so can't comment on the specific remarks above, but since RISC OS was specifically designed to run on ARM, whereas Linux was not, doesn't that give the former some advantage?
Jwoody (-0.9) 25/7/07 4:21PM	"RISC OS vs Linux: I'm not a programmer so can't comment on the specific remarks above, but since RISC OS was specifically designed to run on ARM, whereas Linux was not, doesn't that give the former some advantage?" RISC OS in native ARM should be faster than Linux on ARM but RISC OS give away this advantage with technical drawbacks. Blocking I/O, No Multitasking, No virtual memory. Linux on ARM/MIPS/Power PC are going to be more than powerful enough for an STB so in summary the answer is "No"
rjek 25/7/07 4:43PM	*In reply to Jwoody:* Linux on ARM is several magnitudes faster than RISC OS, due to the fact that it has a good, modern design. I suspect even if non-blocking I/O, good PMT and a virtual memory system were implemented, Linux would still have a noticeable edge. I remember fondly that RISC iX also made better use of the hardware than RISC OS, by using the interrupt prioritisation PIC on the backplane, that RISC OS just ignores.
jess 25/7/07 5:13PM	Why would PMT and virtual memomory be an advantage on an STB? PMT's advantage is it stops dodgy software hogging the CPU. The STB would only run its own software. The use of paged memory slows down a system compared to having enough memory, what would an STB be doing that requires more RAM that would be cheap to fit? (And would it have a hard drive anyway?)
rjek 25/7/07 5:16PM	*In reply to jess:* PMT dramatically decreases effort required to write complex systems, as well as providing better reliability and often better throughput. Please don't confuse virtual memory and swap: Virtual memory is a higher-level concept, and swap is just one application of that. Virtual memory allows, amongst other things, create memory use efficiency by loading only one copy of data that is shared among numerous processes, as well as loading files into memory that are larger than physical memory.
Jwoody 25/7/07 5:43PM	"Why would PMT and virtual memomory be an advantage on an STB" PMT lets you have one task decode video stream at same time as another reads from DVD, something RISC OS is not very good at. In the case of STB then the more things it needs to do at the same time the better PMT is. Virtual Memory is probably less important in an STB unless it has a harddrive. In AIX a version of UNIX you can do I/O by paging which is more efficient than disk I/O, not sure if Linux has this though.
rjek 25/7/07 5:47PM	*In reply to Jwoody:* You're confusing virtual memory with swap, too. Don't do that I'm not sure what you mean about AIX. What does "I/O by paging" mean, and how is it different to "disk I/O" ? Do you mean that you can use a syscall called mmap() to load a file without actually loading it, and it is demand paged into memory? If so, all UNIX OSes do this bar a few exclusions that are designed to work on MMUless machines.
Jwoody 25/7/07 5:52PM	"What does "I/O by paging" mean, and how is it different to "disk I/O"" Means the code used to handle an I/O is the code that handles paging and is in Page size chunks as opposed to the standard I/O routines.
rjek 25/7/07 5:53PM	*In reply to Jwoody:* Sorry, I'm still at a complete loss as to what you mean. Do you mean that I/O to block devices like hard drives are done in block sizes that are identical to the native page size of the machine?
jess 25/7/07 5:58PM	*In reply to rjek:* I suspect that by the time you get to "complex", current arm designs somewhat underpowered. If so, in that situation RO would be out in the cold anyway. Doesn't RISC OS have some support for virtual memory anyway (as in mapping, not swap files obviously)? But isn't it the blocking I/O that is the real nasty for RISC OS?
rjek 25/7/07 6:07PM	*In reply to jess:* RISC OS has no support for memory mapping in terms of mmap() at all. Chris Williams has done some work on this, though. As did one of Dave Thomas's friends, but this was many years ago. RISC OS's virtual memory is the most limited you can manage: in the basic sense, all it means is that logical memory addresses aren't used. For example, all WIMP programs appear at 0x8000, and they are swapped in and out by the WIMP/kernel on Wimp_Poll. With a good virtual memory system, applications can share code and data for almost free, leading to massive gains in memory efficiency. For example, look at all the programs that link to UnixLib: each program has its own copy. GCCSDK4 hopefully will help solve this problem with shared libraries. I don't know if the library gets loaded multiple times, once for each program using it, however. If this is the case, your only saving is disc space. In UNIX, the library is only loaded into memory once, but it is "mapped" into each program, so it looks like they've got their own copy, but they're actually sharing a single copy. This gives memory usage improvements, as well as improving performance as there's only one copy of the code that can go through the CPU's cache. In summary: Virtual memory is good. Often, swap is good. The two aren't the same, and don't judge swap entirely on experiences from Windows. On UNIX, for example, the VM system will swap out data that's not been used in ages to disc, and then use the freed up memory for caching data from disc that you use often, thus actually increasing performance, not reducing it.
2 comment(s) are below your moderation threshold. Login to view them.
Please log in to post a new comment Use the forum for more comments on this article