Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Delving inside a RiscPC emulator

By Chris Williams. Published: 20th Jan 2006, 23:09:36 | Permalink | Printable

If emulation upsets you, look away now

Someone peering through a magnifying glassOf all the various Acorn hardware emulators out there, two in particular are supplied with source code: ArcEm and Arculator, plus its new cousin RPCemu. Created by university undergraduate Tom Walker, Arculator emulates a generic early Archimedes-class computer with either an ARM2 or ARM3 processor. RPCemu is a recent development effort and features ARM610 and ARM710 emulation along with A7000-class chipset and IDE hard disc support. Both programs are available for Microsoft Windows users, bringing the RISC OS platform into a window on a PC desktop.

Being a RiscPC emulator with source code gives an interesting insight into the task of reverse engineering the legacy Acorn computer, which Tom had to go through and without access to the various relevant datasheets. Although VirtualRiscPC successfully emulates a RiscPC environment on PCs, its internals are rightfully protected as being commercially sensitive.

Over a decade old, the technology inside the RiscPC is now old hat enough to the point where it can be more or less emulated with a handful of C source files. At the heart of the application is the ARM emulation engine that works as an interpreter, analysing each machine code instruction in the RISC OS software running on the imaginary RiscPC and deciding what action needs to be taken. As much of the RiscPC hardware is controlled and monitored through memory accesses, the emulator has to obviously be aware of the organisation of the Acorn computer's memory and perform the roles of the keyboard controller, 82C711, IOMD and VIDC20 chips to trick the operating system and application software into believing they are running on real hardware. The emulator also appears to simulate the ARM processor's pipeline and some of the finer points of the way in which the hardware manages and caches memory.

Screenshot of RISC OS 3 running on RPCemuTo a seasoned programmer, Tom's source code will appear to be particularly hairy in places, but it certainly gets the job done: his Athlon 2400 powered PC, RPCemu manages without optimisation to achieve up to some 20 MIPS, at which RISC OS 3 is said to be usable. Early Arculator source even includes a crude simulation of the operating system's software interface, implementing basic functions used by application software.

"Thinking about it I can't remember why I started Arculator," said Tom.

"It was probably a logical progression from my BBC emulator, and I thought at the time that emulating a RISC chip such as the ARM would be easier than emulating a 68k machine - which it was. Certainly I wanted to run Lemmings properly, at the time Archie had awful sound and didn't emulate video properly, and RedSquirrel was becoming less and less accurate in terms of video timing with each release, so I wanted to create an accurate emulator to run these sorts of games."

After copying the contents of his RISC OS 3.6 ROMs from his RiscPC to a PC, Tom spent three days getting the beginnings of his emulator working.

He continued: "RPCemu was designed totally differently to Arculator - rather than aim for accuracy, speed was the main agenda, simply because to emulate the system at a good speed with an interpretive emulator required a lot of shortcuts. This has led to issues - what memory protection exists in RISC OS isn't emulated at all, and it's probably the reason why RISC OS 3.x has problems starting up sometimes. On the other hand, these shortcuts allow RPCemu to be around twice the speed of Arculator."

When it began life four years ago, Arculator's development eventually lead to bringing classic old school games back to life. Tom says he had plenty of help along the way from RedSquirrel and VirtualRiscPC author Graeme Barnes, and found many odd bugs in his emulation engine that, through knock on effects, stopped systems such as disc handling from working. Born late last year, RPCemu turned into an endeavour to provide a working RISC OS desktop.

"The Acorn chipset actually turned out to be fairly dull - there's nothing particularly special about VIDC, IOC and MEMC, the most interesting thing was trying to figure out why Acorn designed the MEMC's page table as they did," commented Tom.

"There are few fun tricks unlike say the Amiga or ST chipsets - not even a blitter. I still remember being totally shocked when I figured out how sound worked. The RiscPC chipset is even more basic as no programs attempt to access it directly. The few tricks that worked on VIDC, such as the scrolling hack used in many games, don't work on VIDC20 and were never implemented as such.

"Certainly I don't intend to emulate the Iyonix or the A9home. What would probably be a better method towards emulating these newer machines is just to implement a new HAL for RISC OS 5, writing specific drivers to access the Windows DirectX interface, and get hardware acceleration into the bargain, much in the same way that Acorn wrote Windows drivers for the 486 second processor card. Such an implementation would be suitable possibly for a commercial emulator, which RPCemu isn't at the moment."

He added: "As for the future, I'd like to get FDI support working better in Arculator, to allow for more copy protected games to run. I'd like to implement a filesystem similar to HostFS in RedSquirrel and VirtualAcorn, I actually started one a while ago but ran into problems. A dynamically recompiling CPU core in RPCemu would be very useful, hopefully boosting the speed to StrongARM levels on my machine. I wouldn't rule out a commercial version of RPCemu, since I'm a penniless undergraduate, but there would be a lot of issues to overcome before that would be possible."

Meanwhile, ArcEm continues to improve with, amongst other details, the addition of preliminary sound support and code to allow programs running within ArcEm to access the filesystem of the host platform. There has been the suggestion that the Archimedes-class hardware emulator should incorporate Nick Burret's work on QEMU, which has enabled simple RISC OS command line applications to run on GNU/Linux. Another tabled idea is to somehow bundle or distribute ArcEm with a set of RISC OS 3.10 ROM files, allowing non-RISC OS users to download and try out the operating system for themselves rather than, say, just looking at screenshots or reading a features list. Leaving aside the issue of how one gets distribution permission from the merchant bank holding RISC OS 3.10, whether or not the 13 year old operating system is a great advert and how much make up it will require to make it presentable is still a matter of debate.


Arculator and RPCemu website (downloads include source code)

Previous: Castle rattles licensing sabre at 32bit RISC OS 4
Next: PCI serial port card driver available


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Damn. Why can't a source version be released then us not using the evil from the borg can use it as well.

 is a RISC OS UserNodoid on 21/1/06 1:28AM
[ Reply | Permalink | Report ]

A source version of what? Arculator and RPCemu are available as source releases - that's the whole point of this article! With some effort, they could probably be run on Linux, although I don't see them bettering ArcEm (also available as source) just yet.

 is a RISC OS Userguestx on 21/1/06 2:37AM
[ Reply | Permalink | Report ]

"Leaving aside the issue of how one gets distribution permission from the merchant bank holding RISC OS 3.10"

No merchant bank owns RISC OS 3.10. Castle owns RISC OS 3.10. However, the terms of Castle's licensing agreement with Pace prevent Castle from taking any action that would diminish the value of Pace's license (such as giving RISC OS away for free).

 is a RISC OS UserWill! on 21/1/06 12:30PM
[ Reply | Permalink | Report ]


That's interesting, but isn't the argument from the article that giving it away for free might generate more RISC OS users, and ultimately increase the value of the license?

Perhaps this is just a case of me misunderstanding the legal meaning of "diminishing the value" of something?

 is a RISC OS Userflypig on 21/1/06 1:52PM
[ Reply | Permalink | Report ]

flypig: It would be up to Pace to decide whether RISC OS 3.1 being made available for free would diminish the value of its license. You could be right that making RISC OS 3.1 available for free could actually increase it. Personally I have no idea.

 is a RISC OS UserWill! on 21/1/06 4:33PM
[ Reply | Permalink | Report ]

Pace? What do they have to do with anything? -- Sprite

 is a RISC OS UserSpriteman on 24/1/06 3:41PM
[ Reply | Permalink | Report ]

I'm interested in the reference to developing a new HAL for RO5 to talk to Wintel hardware: could this be a better way than current emulation to access fast x86 hardware?

 is a RISC OS Userbucksboy on 25/1/06 8:57AM
[ Reply | Permalink | Report ]

bucksboy: Yes, the HAL means all calls to control the processor and core chipset are routed via a jump table at the base ROM. So instead of the emulator having to trap every memory read and write and check to see if is addressing a particular register, the calls to these routines can be trapped. Where as the native HAL code would perform several priviledged instructions or memory accesses to do the task, the emulation of it can do it all in one go, increasing the performance. However, this only holds for the core chipset and there are still plenty of memory mapped I/O devices in the Iyonix, so the trapping of all reads and writes still has to be done to pick specific addresses, rather than using a simple lookup to find the correct memory page.

My main area of interest was writing a far better dynamic optimising code translator (JIT) to turn ARM instructions in to something decent such as Power rather than x86 garbage. The Power with its 31 general purpose registers and 3 operand instructions is far more suited to ARM emulation than register staved, 2 operand x86. But alas with Apple ditching the PowerPC the only thing left is x64, more registers but still p1ss poor.

BTW: Who's the nice girlie in the photo? ;)

 is a RISC OS Userdruck on 25/1/06 9:28AM
[ Reply | Permalink | Report ]

druck: there was a plan at ART in Peter Bondar's day to port RO to the PowerPC processor, AFAIK: it was dealt with by Risc User (my back numbers are all in the attic and I don't think I'll be delving in there any time soon). Presumably Apple's abandonment of this platform doesn't mean it's not still available?

 is a RISC OS Userbucksboy on 25/1/06 11:19AM
[ Reply | Permalink | Report ]

Ironically Apple droping PowerPC comes just as architecture is gaing a massive increase in sales. Variants of the PowerPC core are being used for all the next generation games consoles - the XBox360 (Xenon is a 3 core PowerPC derived) is already shipping, soon to be joined by the Sony PS3 (Cell is a Power PC derrived plus 7 specialist units) and Nintendo's Revolution (standard Power PC). Plus of course the big dog Power5 multi core chips continue as the mainstay of the IBM RISC workstation and server line up.

However with Apple moving to <spit>x86</spit> means there wont be suitable PowerPC based desktop or laptop machines on which to run an emulator. Unless you particularly like Mac OS in order to pay the premium for the cludged hardware, you might as well buy any old box to run the emulator on. Far more important is that RISC OS emulators are available for *LINUX* to avoid the need for any Microsoft filth.

 is a RISC OS Userdruck on 25/1/06 11:41AM
[ Reply | Permalink | Report ]

I'm sure they had Project Vulcan on the drawing board at ART, given the amount of Peter Bondar hyped vapourware doing the rumour circuit.

 is a RISC OS Userguestx on 25/1/06 2:14PM
[ Reply | Permalink | Report ]

I am not convinced that Apple will abandon the PowerPC platform. From a strategical POV it is good to keep the competition up between CPU suppliers, so if I were Steve Jobs, I would use x86 based machines for the low-end and laptop market, and Multi-CPU PowerPC systems as high-end workstations. He could even add an extremely powerful workstation based on the Power5.

 is a RISC OS UserJGZimmerle on 25/1/06 4:27PM
[ Reply | Permalink | Report ]

Apple isn't the only one that has moved to the x86 platform: Sun is using (AMD) x86 compatible processors...

 is a RISC OS Userscl4c0rn on 25/1/06 5:02PM
[ Reply | Permalink | Report ]

scl4c0rn: Sun hasn't /moved/ to x86, they sell Solaris x86 power xeon and opteron boxes as low end servers along side their main SPARC RISC lines. They are continuing to develop SPARC with the 32 thread / 8 core Niagara.

JGZimmerle: I'm afraid Apple is moving, its a condition of getting their hands on Intels 100's of millions in marketing subsidies. Apart from that continued development of machines based on both architectures would expose how little other rational there is behind the decision. They need to encourage their software developers to move to native x86 code as quickly as despite claimed 2x-4x performance gains from the x86, emulated code runs at half the speed, and even fully native is only showing about 16% increase on real applications.

Which goes to show the problems with emulation when the performance of both architectures is similiar, rather than the much easier situtation for RISC OS emulators on processors which are theoretically up to 20x faster than even the IOP321 in the Iyonix.

 is a RISC OS Userdruck on 26/1/06 9:24AM
[ Reply | Permalink | Report ]

No sane developer would release x86-only products for MacOS in the next five years, simply because Macs are usually used for at least six to ten years. So just about all MacOS software will use the "new" binary format (wich isn't really new, IIRC it was introduced in NeXT). This includes code for both architectures, wich means that applications using it will run at full native speed on both architectures, without emulation. So even if Apple should move to x86 completely for say the next two or three years (wich I dought, because they still have supply contracts with Freescale wich run for a few more years, and maybe even with IBM), they could easily return to PowerPC, once their contracts with Intel run out. And of course they have other options, like licensing their PowerPC version of MacOS to some new sister-company (wich could even be controlled by Apple).

 is a RISC OS UserJGZimmerle on 26/1/06 7:00PM
[ Reply | Permalink | Report ]

All this Apple strategy speculation and suddenly it's as if this is OSNews (where such pointless activities are a celebrated pastime amongst the idle, but insight-free fashion-accessory worshippers).

 is a RISC OS Userguestx on 27/1/06 1:41AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Iyonix Review Part Two
    In this final part we look at RISC OS 5 and the bundled software
     4 comments, latest by hzn on 22/8/03 5:47AM. Published: 9 May 2003

  • Random article

  • Calling all coders, Codecraft III has begun

     Discuss this. Published: 17 Jan 2001

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Drobe's only failing is the sixth-form geek-journo tone with its lead balloon humour and occasional smugness and ugly personalty"
    Page generated in 0.1575 seconds.