Meeting: RISC OS Open Ltd

Report by Ian Macfarlane

Jack Lillingston, Castle’s MD, made the five hour hike from Ipswich to come and talk to us about the Iyonix kit that is available. He brought with him Steve Revill, who is a director of RISC OS Open Limited (ROOL) from Cambridge.

Iyonix Ltd

Jack familiarised us with the Iyonix motherboard, which was common to all the types of Iyonix PC. The board was built to the Micro ATX standard and so would fit into many PC cases. He showed where on his slide the major components where positioned, for example the processor chip, the Intel 80321, 600MHz, was situated near the centre of the board. This XScale processor used to be referred to as StrongARM 2.

Jack then went through the various Iyonix packages for sale. He reminded us that the Iyonix could be purchased as a kit for under £600 including VAT and a bundle of software. He put in a plug for their current promotion, a free 17" LCD monitor with the X100 and X200 models. The X100 is a desktop machine, similar to the RiscPC in size, but is limited in expansion; it will work in tower mode. The X200 is the original Iyonix and is known as the ‘Classic’. It is able to take Acorn podules. The X300 uses the smaller Flex ATX case and will also work in desktop or tower mode, but gives more expandability than the X100. The Aria is the latest Iyonix configuration and is a cube, whose sides and top come off for easy access. It is expandable, but smaller than the previously mentioned cases and is priced below them.

Jack went on to talk about the monitors that his company sells. The Iyonix has a maximum screen resolution of 2048×1536 in 16 million colours. The 17" and 19" monitors have a screen resolution of 1280×1024. There are also three wide screen monitors, the largest is a 24" screen with a resolution of 1920×1200. There is also a 22" monitor, which has dual input with a switch on the front, saving desktop space for those with two computers. He then talked about the current RISC OS version that could be obtained as an upgrade and for a fee.

Shared source RISC OS

Jack gave us an overview of the RISC OS Shared Source initiative. He first made the fundamental point that the basic operating system should be able to cope with new technologies and it was only the new drivers for new hardware that were valuable and saleable. There is no need for the operating system to be proprietary to just one company. Castle are making it available for the community to take the operating system forward; there have to be rules to make this work and these they have built into a business model. The first principle is that RISC OS is free to all non-commercial users. The second principle is that commercial users pay a fee which will support the regulation of the operating system and also pay back the original owners / investors.

Jack made it clear that there were benefits for Castle in its own marketing of RISC OS based technology to have a strong and forward moving development of the system and for this to be clearly seen, for example in the tools available for use by a new developer – in the Far East. The website access enables anyone to download any part of the system (that is currently available). No registration is necessary; there is no fee. The licensing is the heading of each source module. This was the obvious point to hand over to Steve Revill who is concerned with the day to day running of the initiative.

Steve believed that there were two distinct types of RISC OS user; these were developers and users. The RISC OS Open initiative had benefits for both of these types. The ‘user’ type had the most difficulty in understanding how the initiative would benefit them; buzzwords like source code didn’t mean anything to them. The aim was to get all of the source code of RISC OS out and available for public access. For a user type, the latest versions of ‘system’ applications such as Draw, Paint and Maestro are available for free download, no matter what hardware the user had.

RISC OS Open Ltd

Steve described the six months of hard work they had put in to arrive at the licence terms. This was an achievement that was not visible to the RISC OS community. Then in April the first fruits of their endeavours were placed on the website for public access. Among this tranche were the Edit, SciCalc and Paint applications. Recently more source code, Printer Manager, Font Manager and Filing system, had been added to the website and Steve thought that it would be another 12 months before the whole of the system’s source code and applications would be available for access.

Steve said it was important to know how the responsibilities divide between the three companies: Castle, RISC OS Open Ltd (ROOL) and Iyonix Ltd. Castle own RISC OS. ROOL are agents of Castle and do the hard work of checking the sources and publishing the data on their website. Iyonix Ltd is a products company and it licenses RISC OS from Castle in exactly the same way as any other commercial company does. Thus there is a clear dividing line between the owners of the intellectual property and those companies selling products that use it.

Steve stressed that ROOL was not taking over the development of RISC OS. Although the website had a forum for problems, bugs and questions about the OS, the answers and bugfixes would be undertaken by the RISC OS developer community. The repository for the source code of the system would remain with ROOL and would be available from their website. This would stop fragmentation of RISC OS. Any alterations to coding must be published by the developer and if ROOL liked the changes enough, then they would be able to take the changes and ‘fold’ them back into a new version of module or application to be available for public access.

Steve Potts asked for clarification here. Steve Revill assured him that it was not necessary for a copy of the new module and its sources to be sent to ROOL. The stipulation was that these items had to have public access.

Steve stressed that ROOL was being run on a ‘not for profit’ basis and that the directors were not taking any money out of it; they were doing it in their spare time. The proceeds of the sale of mouse mats and donations would go to paying the running costs of the venture.

Steve Potts wanted to know if Castle’s RISC OS was being developed. Jack outlined the methods by which the system was being developed. One was by developers doing their own thing and modifying the source code as indicated by Steve Revill before. This had already taken place. Another hypothetical example was if a company was developing a product that uses Firewire, which is not in RISC OS, then the driver and associated software would be required to be publicly accessible. The structure of the licence encourages companies to make such software available sooner rather than later.

New features and developments

Another member of the audience wanted to know about changes that already had been submitted. Steve said that he had prepared some items to show us, but because his MS Windows laptop had broken down, this was impossible. Steve told us of the new feature in Paint, where, by dragging a rubber band over several of the sprite icons in a sprite file, these sprites could be selected for further group editing/saving. Also in Paint the cutting and inserting of rows and columns had been improved. Other applications such as Maestro and Close-up had had adjustments to make them more Style Guide compliant. The Filer had had improvements made to it and he told us that there would be keyboard short cuts in a new version. The Pinboard has had many improvements. Martin Würthner has threatened to modify the Printer Manager to enable CMYK separations and high resolution printing.

The previous questioner followed up with a question about versions of modules in ROM. How would it be possible to ensure that the latest version was being used, he asked. Steve said that applications such as Edit were available as both modules for ROM and stand alone Filer run applications. There were instructions on the ROOL website relating to the use of the products within the archive.

I enquired about how the quality of the changes made to the source code would be controlled. Steve answered that initially the new source is test built and then test run. It is then put in the source tree. The community then take it upon themselves to test it and send back bug reports if necessary. However if a commercial developer uses that item in its system build, then it will be up to them to ensure that their system, which includes the change, is properly functioning before they put it on the market.

Steve Potts wanted to know at which point would new features be rolled up into a new version of the system. Steve Revill said that he envisaged it being much more dynamic than that and that changes would be subsumed as soon as there was confidence in the stability of those changes. Steve had proposed a community voting system for determination of the stability of an item. Jack said he liked this idea, for it promoted a quick response to bug reports and quick assessment of the stability of products.

Someone asked if it was envisaged that the RISC OS system would be in such a state that another company could alter it to run on different hardware. Steve concurred and said that that was a goal of the initiative and would be possible by the release of the Hardware Abstraction Layer (HAL). This had been done several times before in PACE. For example a small LCD touchscreen device driven by an ARM 7 chip was built and within two weeks they had the RISC OS desktop displayed on the screen with a game of Meteors running on it.

Chris Hughes was concerned about module version numbers not corresponding with the dates of issue. He quoted the toolbox modules debacle some years ago. With two major streams of development now going ahead there were problems. Surely it would be much more difficult in future with multiple streams of development. Steve said that they were talking to RISCOS Ltd to try to resolve the matter.

Finally, another member of the audience postulated a scenario where a developer had spent time and effort working on an item from, say version C, only to find when finishing his work that the goalposts had changed and that the item’s new version was F and was substantially different. Steve said that had happened all the time at Acorn and that it was a normal problem to face. This could be minimised by strong (project, in the Acorn case) management. The resolution was a merge of the two codes.