Note: This document was first written in 2007. Although the RiscPC/A7000 version of RISC OS 5 is still incomplete, it is in a significantly more usable state than it was in 2007. For more details about the current status, see this page. The original wiki article follows.
There still seems to be plenty of interest in building shared-source RISC OS for the Risc PC, but there is much confusion about what would be involved in doing so.
First, understand that this is not top priority for ROOL – ROOL’s policy is that it’s more important to focus on releasing all the components needed to do an Iyonix ROM and disc build first. Only after this will the remaining components be vetted for release, although those components that relate to Risc PC hardware support are probably good candidates to be the next on the list.
RISC OS as it stands today was of course developed from a version that ran on the Risc PC, and there is no fundamental reason why it cannot still be built for it, either by digging back for old versions – the repository contains source code back to RISC OS 3.60 – or by mixing recent versions of high-level modules with Risc PC hardware drivers. HAL and non-HAL builds for the Risc PC were still being done regularly until about 2001, but no version since then has been tested with the Risc PC, although nobody has deliberately removed support.
You should bear in mind the things you would lose by running shared-source RISC OS.
The issues involved in a Risc PC build are complex, but here’s an overview of the technical details.
The RISC OS modules and applications can generally be built either 26-bit only (APCS-R and 26-bit-only instructions), or 26-bit/32-bit neutral (APCS-32 and run-time switched 26-bit or 32-bit instructions). Nowadays, the only reason why you’d want to build a module for 26-bit modes only is if you’re creating a version that can only usefully be softloaded on a 26-bit OS.
The kernel is more of a complicated issue, though. There are three main active branches: the trunk, the Ursula branch and the HAL branch, and any of them can be used to build a Risc PC ROM, each with their own advantages and disadvantages.
The kernel’s Ursula branch split from the trunk at RISC OS 3.71 (the A7000+ / Risc PC J233 release) and is named after the codename for the OS for the Phoebe (Risc PC 2). RISCOS Ltd’s code snapshot was taken from the Ursula branch; the last revision on the Ursula branch kernel is very similar to the kernel of RISC OS 4.02. Due to Phoebe hardware production problems, the Ursula branch kernel was primarily developed on Risc PC hardware, and featured numerous performance optimisations over RISC OS 3.71, both pure software optimisations, and ones aimed at making better use of the Risc PC and Phoebe hardware. Development ceased on the Ursula branch after the code drop to RISCOS Ltd, partly because it is polluted with lots of now-redundant Phoebe support code, but the Ursula branch remains the only branch on which no major Risc PC hardware optimisations are missing from the kernel.
Soon after the cancellation of the Phoebe project, a move was made to merge useful features from the Ursula branch back onto the trunk. Useful, in the context, meant useful to the then-booming market for embedded RISC OS devices based around the ARM7500FE, which meant no StrongARM-specific features, and nothing that was considered desktop-specific. Things that were merged included accelerated service call and SWI dispatch, system variable lookup and command line parsing. The build-time switch allowing the ability to run the OS in 32-bit modes was first added on the trunk (though large application slots are still not available on the trunk). The HAL branch split off at this point, although development continued on the trunk at a much reduced rate. The much-hinted-at Pace homebrew RISC OS 4 ROM builds used the trunk kernel.
On the HAL branch, all peripheral support code was moved out of the kernel, leaving behind CPU control, memory management and other low-level but hardware-invariant code. Most of the remaining Ursula branch kernel optimisations were merged straight across to the HAL branch, including lazy task swapping, sparse dynamic areas and various dynamic area speedups, long command lines and large RAM discs. However, cached screen support was not merged across, this being a specific workaround for the poor performance of the StrongARM at uncached memory accesses in standard bus mode – required by a quirk of the Risc PC memory controller, IOMD – and neither was section-mapping of screen memory. Since maintenance of the OS was taken over by Tematic, all bugfixes and new features of the kernel have only been applied to the HAL branch kernel – this includes large application slots, the hardware device pool, and real-time threading support.
The HAL for Risc PC era Acorn-chipset machines (known as the IOMD HAL, although it includes support for VIDC and other supporting chips) is an implementation of the broader HAL API, including entry points that have not been publicly documented so far. This is not through any agenda to conceal information, it is simply that the only entry points useful to third party software are those relating to interrupts and timers. The extra features relate to system boot, video, I2C, NVRAM and machine unique ID.
As more and more HALs have been developed, extra entry points have been added. These have generally involved the hardware-specific parts of driver modules being moved into the HAL, and includes support for serial ports, DMA controllers and ATA controllers (hard discs / optical drives). The IOMD HAL has not been updated to work with HALised variants of Serial, DMAManager and ADFS (though it could be if someone fancied doing so). In the meantime, non-HAL variant builds of those modules should continue to function.
Some HAL entry points refer to peripherals that just don’t exist on the Risc PC, such as the PCI bus, USB controllers and touchscreens. By convention, the HAL is only used to drive motherboard devices, so if you wished to write drivers to interface any USB podule to the OS USB modules, you would do so as separate modules, not by integrating it into the HAL.
On the other hand, some Risc PC peripherals have no analogue on any of the systems that RISC OS has been ported to since the Risc PC, so no HAL interface has yet been defined for them. This includes PS/2 and parallel ports, but the existing drivers should continue to function using direct hardware access.
Other things to note are that the OS developers have never found sufficient similarity between the sound systems of different platforms to decide on a sensible common HAL API for them, so different SoundDMA modules have been written for each platform using direct hardware access. Also, some of the larger drivers, such as those for Ethernet controllers or MPEG decoders, are more complex than was judged to be suitable for the HAL, so these have also remained at the module level.
Finally, a couple more potential gotchas for people wanting to backport to the Risc PC. The sources have acquired a light sprinkling of ARMv4 instructions like UMULL, in SpriteExtend for one, which means they won’t work properly as-is on pre-StrongARM machines. And some places have started using halfword memory accesses for speed, which won’t work on the Risc PC memory bus, although hopefully they’re all accompanied at least by a check for running in 32-bit mode. For example, see the implementation of *Memory H in the Debugger module. Note that this presupposes that nobody would be running a machine with IOMD in 32-bit mode. This may present a small hurdle to be overcome if you’re determined to run a Risc PC in 32-bit mode.