RISC OS Open: One year on | Drobe.co.uk archives

RISC OS Open: One year on

By Martin Hansen. Published: 21st Jul 2007, 23:16:47 | Permalink | Printable

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

Previous: Unix Porting Project back online
Next: PrivateEye window scroll bug fixed

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

'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]

You can't sort it out yet because RISCOSLib hasn't been released yet.

IvanDobski on 23/7/07 11:06AM
[ Reply | Permalink | Report ]

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.

druck on 23/7/07 1:30PM
[ Reply | Permalink | Report ]

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...

piemmm on 23/7/07 1:40PM
[ Reply | Permalink | Report ]

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.

VinceH on 23/7/07 2:03PM
[ Reply | Permalink | Report ]

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]

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.

Stewy on 23/7/07 2:47PM
[ Reply | Permalink | Report ]

Excuse me but I'm missing a piece of the jigsaw here - how is the work of RISC OS Ltd going to faciliate new hardware emerging that can run whatever they produce? And how exactly is whatever they produce from the OS itself going to run on new hardware or old hardware?

AW on 23/7/07 7:58PM
[ Reply | Permalink | Report ]

aw: yours is the first mention of RISCOS Ltd in this article..??

jb on 23/7/07 9:41PM
[ Reply | Permalink | Report ]

AW: RISCOS Ltd and Advantage 6 have together produced a version of RISC OS (RO6) that runs on hardware that is currently being produced - and the work they have done is available for license by any other hardware developer. Advantage 6 have not placed restrictions on the development they have supported so it's open to any third party to ask ROL for a licence for their own hardware.

jc on 23/7/07 10:28PM
[ Reply | Permalink | Report ]

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 RISC OS 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.

AMS on 23/7/07 10:30PM
[ Reply | Permalink | Report ]

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.

pthw199 on 24/7/07 12:02AM
[ Reply | Permalink | Report ]

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.

bucksboy on 24/7/07 10:37AM
[ Reply | Permalink | Report ]

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.

Jwoody on 24/7/07 6:24PM
[ Reply | Permalink | Report ]

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.

bucksboy:

dammit! beat me by 2 yrs :-p

In my defense I'd wanted one since 1989... :-)

epistaxsis on 24/7/07 10:43PM
[ Reply | Permalink | Report ]

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.

AW on 24/7/07 11:33PM
[ Reply | Permalink | Report ]

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!

stevek on 25/7/07 7:45AM
[ Reply | Permalink | Report ]

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.

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.

flypig on 25/7/07 11:27AM
[ Reply | Permalink | Report ]

"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

Jwoody on 25/7/07 12:34PM
[ Reply | Permalink | Report ]

In reply to epistaxsis: Been using since 1992

Wink , Wink !!

Hairy on 25/7/07 1:59PM
[ Reply | Permalink | Report ]

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).

flibble on 25/7/07 2:46PM
[ Reply | Permalink | Report ]

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?

bucksboy on 25/7/07 3:31PM
[ Reply | Permalink | Report ]

"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"

Jwoody on 25/7/07 4:21PM
[ Reply | Permalink | Report ]

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.

rjek on 25/7/07 4:43PM
[ Reply | Permalink | Report ]

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?)

jess on 25/7/07 5:13PM
[ Reply | Permalink | Report ]

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.

rjek on 25/7/07 5:16PM
[ Reply | Permalink | Report ]

"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.

Jwoody on 25/7/07 5:43PM
[ Reply | Permalink | Report ]

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.

rjek on 25/7/07 5:47PM
[ Reply | Permalink | Report ]

"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.

Jwoody on 25/7/07 5:52PM
[ Reply | Permalink | Report ]

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?

rjek on 25/7/07 5:53PM
[ Reply | Permalink | Report ]

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?

jess on 25/7/07 5:58PM
[ Reply | Permalink | Report ]

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.

rjek on 25/7/07 6:07PM
[ Reply | Permalink | Report ]

" 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?"

Yes thats an option.

Jwoody on 25/07/07 6:16PM
[ Reply | Permalink | Report ]

"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."

Thought that was the same in RISC OS for shared libraries as in C shared library.

Jwoody on 25/07/07 6:21PM
[ Reply | Permalink | Report ]

Jwoody: "Yes thats an option" All UNIXes work like that, then.

"Thought that was the same in RISC OS for shared libraries as in C shared library." No. RISC OS's SharedCLibrary is shared by all processes, and the share the same pointers to it. For example, if one program where to overwrite it to change it, all programs linked to it would suffer the change. Also, you can't have more than one version of the SCL loaded and in use at once.

rjek on 25/07/07 7:03PM
[ Reply | Permalink | Report ]

rjek, jwoody: you seem to be saying that, even after a substantial amount of development, if not effective rewriting, to incorporate PMT, virtual memory and the I/O block, RISC OS will still struggle to match Linux on ARM for embedded systems etc. What then is the point of ROOL, or any further development?

bucksboy on 26/07/07 07:45AM
[ Reply | Permalink | Report ]

"RISC OS will still struggle to match Linux on ARM for embedded systems etc." Thats my view but clearly other people have other views"

Jwoody on 26/07/07 08:38AM
[ Reply | Permalink | Report ]

Part of the reason Castle decided to open RISC OS up is to make it more attractive to potential users. RISC OS is already used in STB's but the advantages being eroded as alternatives get these features e.g. fonts that look good on TV and being first into the market.

Designing STB hardware with dedicated MPEG video decoders (or other custom hardware) would require significant customisation of RISC OS. Providing a license that allows third parties to experiment with the OS means they can do so in private and with a choice of developers (not just Castle) to work on the project.

Linux is definitely competition to RISC OS and has compelling features. To make RISC OS a more viable alternative then increasing the speed and reducing the cost involved in migrating to other ARM processors is critical. At the same time RISC OS must offer features that differentiate it from other OS's targetting ARM.

The STB market is huge think satellite decoders, TV on demand in hotels, Inflight entertainment systems, TV's with built in digital decoders, HDD recorders etc.

stevek on 26/07/07 08:50AM
[ Reply | Permalink | Report ]

bucksboy: You tell me. It would take literally millions of pounds worth of effort and time to bring RISC OS up to that kind of level, and it would also cost compatibility with many old pieces of software.

rjek on 26/07/07 09:07AM
[ Reply | Permalink | Report ]

In reply to Jwoody: I indeed have an other view on using Linux on an embedded ARM system, maybe because I use it.

For me, the most important thing is control. I want to have control over the system. I/O block: don't need it. You can just as easy write a simple loop to check things without blocking and you have more control over it. Debugging is simpler too. Multitasking is a pain. I know when my tasks can wait some time and don't want the OS to decide it. Getting a system to run at it's maximum speed is easier on RISC OS. But the most annoying thing is writing device drivers. In RISC OS I normally write a module in assemble but you can use C to. You can use most of the features of the OS using swi's. Using Linux you write a kernel module. You can only use a restricted subset of OS calls and the most annoying thing is the memory protection. You can not easily access user memory from a kernel module and kernel memory from user space. And you have to link it to the kernel which takes a lot more time.

All the unix features like multitasking, virtual memory, blocking I/O are great on a multi user system running different tasks but on an embedded system I'll have RISC OS any day.

Peter V

Peter on 01/08/07 09:42AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

How to create a modern desktop theme
More to life than drab 16 colours of 1994 [Updated]

47 comments, latest by jymbob on 13/10/06 6:38PM. Published: 4 Oct 2006

Random article

Yet more Omega mobo pics
Jules Zimmerle presents the Omega. Again

6 comments, latest by [mentat] on 20/3/03 11:30AM. Published: 10 Mar 2003

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"'Public interest' is what tabloids use to trot out all sorts of tat. It's turned into a meaningless term meaning 'I'm just trying to be sensationalist'"
Page generated in 0.2882 seconds.