Compatibility Proposal
All information herein is the view of the author. Use at your own risk, no warenty of any kind is provided.

Conceptibility Proposal:

It is true that do to the limits of the API making RISC OS 5.2x API fully back compatible with the 3.7 API would require that only 512MB is mapped in for most things. That said, it is possible to still suport up to a 4GB address space directly in RISC OS with a RISC OS 3.7 compatible API, by being careful about what is mapped where, with the area above the 512MB limit being restricted to use for swapped out tasks, and special Dynamic Areas that can not be used as buffers for some system calls (mostely FS related).

As such I propose a version of RISC OS modified from the RISC OS 5.26 source code that is completely call compatible with RISC OS 3.7, including for calls that use up to 3 high bits of an address pointer as flags. For everything up to 512MB of the address space this will have no ill effect, for stuff that is above the 512MB there will be a few reasonable limits on the usage thereof.

In this vein I also propose that the kernel be broken into a few modules, to ease HW dependancy, and get rid of the HAL hack (we are not running CP/M, PC-DOS, OS/2, or other BIOS/HAL bound OSes), we have modules lets use them to our advantage.

The desired effect of the suggested changes is to ease the issue of being compatible with older software. This should help Adrian Lees improve Aemulor as well as make it easier for others to implement other compatibility layers.

Further I recommend, on systems where this is reasonable, to simulate the low color modes (16 color and fewer) where the HW does not natively support them. For example on BCM2835, BCM2836, and BCM2837 based computers the VideoCore IV can be used to translate a pseudo framebuffer to the physical frame buffer, without having any effect on the performance of the ARM side programs, and this is a reasonably doable operation to implement on systems having the VideoCore IV GPU.

These seem reasonable recommendations. I do not spend much time with GPU coding, so I knou that I can not do much to help with that part, though this is a task that has been done before, and shown how to do.

The RISC OS rework is something that is likely to take multiple people in order to pull off. Or one person and a decade of time. It would be nice if once this goal is accomplished a new 26-bit R15 version of RISC OS could be created from the newer source code of RISC OS 5.26 (or newer). It would be really useful if it could also be applied to a version that is capable of correctly running on the ARMv2 CPUs of the Archimedes / A series systems. We could hypothetically have one RISC OS for all RISC OS running computers, no more worry about API changes over multiple OS releases.