Showing changes from revision #1 to #2:
Added | Removed | Changed
Edit in progress…
The AfterRISC OS modules 3.71 (the A7000+ / Risc PC J233 release) the kernel diverted into three main branches: the trunk, the Ursula branch and applications the can generally be built either 26-bit only ( APCS HAL -R and branch. 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 is split from the trunk codename at for the OS for the Phoebe (Risc PC 2).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 andSWI 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 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.
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.