RPCEmu ARM610 and ARM710
What a Risc PC 600 and 700 shipped with, and what RISC OS 3 and 4 generally want. If you are running the version you remember, this is the machine you remember it on.
The machine
Build the Risc PC you want
Choose the processor: an ARM610, an ARM710, a StrongARM, or the Kinetic card with 512MB of its own. Or an A7000 instead. Which one you want depends mostly on which version of RISC OS you intend to run.
Choosing one
The processor, and what it means for you
Four processors and two A7000 variants, selected per machine. The choice is not about benchmarks: it is mostly about which version of RISC OS you are going to boot.
StrongARM
A StrongARM processor card in an ordinary Risc PC, reaching main memory across the machine's own memory bus like the cards before it. Supported by RISC OS 3.7 onwards, and the straightforward way to make a Risc PC quick.
Kinetic
A different kind of upgrade: it puts the processor and its memory together on the card, close to each other, so the processor is not held back by the Risc PC's memory bus. That is the whole point: a StrongARM in an ordinary Risc PC was crippled by that bus, and on the Kinetic it is not. The 512MB is a consequence of the arrangement rather than the reason for it. RISC OS 5 supports it outright; under RISC OS 4 it needs a build that knows about it.
A7000 and A7000+
The cheaper machine without VRAM: video runs from main memory. Worth having when the software you care about was written for one.
The Kinetic in particular
Why it was a different kind of card
Worth knowing if you pick it, and safe to skip if you do not. A StrongARM card still reached main memory across the Risc PC's memory bus, and that bus was the limit on how fast it could go. Castle put a 233MHz StrongARM and its own SD RAM on one board, with chips of their own that reduced how much the machine leaned on Acorn's IOMD, so the processor and its memory sat together instead of talking across the motherboard.
Motherboard memory became overflow
The card's own RAM is used first, and the memory on the motherboard is what programs spill into once it is full. That is why a Kinetic machine has more memory in total than the IOMD can address on its own.
It came with its own RISC OS
The card shipped with RISC OS 4.03, a different strain from the 4.03 in other machines of the period. That is the concrete reason RISC OS 4 needs a particular build here and RISC OS 5 does not.
Castle claimed it was much faster
At launch they put screen redraws at up to two and a half times an ordinary StrongARM Risc PC on RISC OS 4. That was their figure and it was not independently verified at the time, so read it as the claim it was rather than as a measurement.
A separate region, not a bigger one
Emulating that meant threading the card's memory through address translation, the memory map and the recompiler alike, because guest code can execute from it. It is not the motherboard's memory with a larger number on it.
Detected the way RISC OS detects it
RISC OS does not ask a register whether it is on a Kinetic. It works it out from how the machine behaves, so the emulation has to behave that way rather than answer a question.
Set for you
Choose the Kinetic and the memory is fixed at 512MB, because on that card it is not a choice.
Speed
Recompiled, not interpreted
Guest ARM code is translated to your own processor's instructions and cached, so a loop is translated once and then run. That is the difference between an emulator you demonstrate and one you use.
x86-64 and arm64
Both have a recompiler, so an Intel or AMD machine and an Apple Silicon or arm64 Linux machine all run translated code rather than falling back to interpreting it.
Floating point in full
Complete FPA10 emulation, the floating point unit a Risc PC could be fitted with, timed to the cycle. Software that expects one finds one, and the debugger reads its instructions as instructions rather than as generic coprocessor traffic.
Drawing handed to the host
Where RISC OS asks for something this computer can do identically, such as plotting a sprite to the screen, it is done here and the guest's pixel-by-pixel loop skipped. Only operations that reproduce exactly are taken.
Fidelity
The fault that made ADFFS avoid RPCEmu
ADFFS runs the preserved commercial games, and it relies on the processor faulting when a program writes to protected memory. RPCEmu did not fault: once an address translation was cached it stopped checking permissions, so a write that should have aborted quietly succeeded.
That is why ADFFS told people to avoid RPCEmu from 2013 onwards, and why very few of the games that need it ran. It faults correctly here, and a regression test holds it, so the games work.
It is worth saying plainly because it is the kind of defect that never announces itself. Nothing crashed and no error appeared; software that depended on the fault simply misbehaved, and the emulator looked innocent.