It is now 2020 and the world is quaking at the feet of the Coronavirus global pandemic. For many years I've been threatening to pen some words on the story of how Aemulor, which I still consider to be my greatest creation, came to be. Now, with time on our hands and the country on lockdown, I have decided to travel back to 2002...
Cue wobbly-screen effect...
Around March 2002 I quit full-time employment at a CCTV design/manufacture company in Surrey and I cycled on a North-Westerly heading, up the country, stopping as it turned out in the bucolic town of Clitheroe in Lancashire, near the Forest of Bowland and an area of the country that can fairly be described as 'cycling heaven.'
For some time I'd had an interest in processor design, particularly RISC architecture and of course ARM, my 'native' platform having been writing in assembly language for ARM2 and later processors since the age of 15. What started out as a hardware design at the level of logic gates soon led to a software emulation of the processor as I realised just how useful an ARM emulator could be as a development tool. I had looked at and experimented with ARMulator but it was far too slow to be practical.
In the early summer of that year the Wakefield Show occurred and I cycled over from Clitheroe, through the wonderful rolling hills of Yorkshire to the show, to see Neil who was exhibiting. Many people will remember that at the time, following the demise of the Phoebe project, all hopes of new hardware for the RISC OS platform were pinned on the Omega from MicroDigital, an aptly-chosen name as it turned out, sadly.
In the cafe, Neil and I discussed the future of RISC OS with newer ARM-compatible processors such as the Intel XScale range dropping support for 26-bit addressing modes, mainly I think in the context of MicroDigital's efforts, and at that time we had no knowledge of the ongoing development of the IYONIX pc or of RISC OS 5. I was still using a 202MHz StrongARM RiscPC with 8 + 1MiB of RAM and RISC OS 4.02, the machine upon which Aemulor came to life.
By around September I had a mostly-functional ARM2-compatible emulator capable of running simple applications and their support modules, written in C and compiled with Norcroft, but it was itself still 26-bit code. The ability to write and build C without relying upon the SharedCLibrary or other run-time library code relied upon past experience from other low-level projects, and the code for handling 26-bit modules actually borrowed source from an earlier project. At that time, though, it was mostly an experimental effort with no specific direction beyond a vague notion that it might one day form the basis of a powerful debugging and development tool for the RISC OS platform (something that, alas, has yet to materialise *sigh*.)
Neil emailed me to say that he had heard of hush-hush development work at Castle Technology and Tematic, bringing a new 32-bit only machine to market, which I thought was great news. I replied that I had been developing an ARM emulator and that it was now capable of running complete applications on RISC OS 4.02. If memory serves, this was about a week before the developer day to which Neil had been invited, introducing a small group of people within the RISC OS world to the new machine under a signed NDA.
Over the course of that week, I beavered away to push the emulator development to the point where it was capable of running as a module (I think it had still been application code up until that point) and could successfully run Scribe, a multi-document WYSIWYG wordprocessor that I created in ARM assembly language when I was 15/16. I think it also had the ability to run StrongED but - I'm a bit rusty here - I don't think it had at that point enough functionality to run Impression Style on my RiscPC.
Late at night, or more likely very early in the morning - I have a history of last-minute releases and people picking up the latest build in the morning, rather than the evening before! - I emailed a build of my emulator which then bore the imaginative working title of 'ARM26Emu' and a couple of test applications, including Scribe, and Neil bravely carried it untested to the developer day to show Castle. Their machine needed an emulator to ease its adoption, and my emulator needed a home. Truly a serendipitous confluence.
At the Developer Day itself, despite ARM26Emu having never been run on the XScale CPU, or in a 32-bit CPU mode, it was able to run Scribe properly on the IYONIX pc. I should say that Scribe is purely USR mode application code with no reliance upon support modules, and of course I had access to its source code, but it was enough to prove the concept and to gain the interest of Castle who let Neil purchase one of the ten pre-production IYONIX pcs which I have to this day, although its hard drive has alas not stood the test of time.
The IYONIX pc remained with Neil until the Guildford show a couple of weeks later, with me still developing ARM26Emu on my StrongARM RiscPC and sending him builds to try on the IYONIX pc. At that time, there was still no hardware acceleration on the machine and dragging large windows or scrolling the screen was really rather painful, but the emulator was getting there. It was now capable of running Style and Publisher - which of us ever suspected that it would still be required to serve in that capacity almost two decades later? - and the emulator had been modified to sidestep some compatibility issues in the XScale CPU.
At one point, as Neil surely remembers, we had a phone conversation in which I had the poor guy typing cryptic Debugger commands and hexadecimal addresses into this new arrival to find out what had changed and to investigate what was not working. By the time that the Guildford Show arrived I had at last made its acquaintance at Neil's house and ARM26Emu had, after some back and forth discussion, acquired its new name 'Aemulor' at Neil's suggestion, from the Latin verb 'to emulate.'
It was a name choice that was to lead to much confusion over both spelling and pronunciation, and even to the creation of its own verb, 'to aemulate.'
So that's the story of how Aemulor came to be. It was all still C code at that point and, though each instruction was emulated using a dedicated function and carefully crafted to avoid unnecessary work, over the ensuing weeks batches of these functions would be switched out and replaced with handcoded assembly language equivalents to eliminate any inefficiencies in the compiler output, and the overheads of function calls.
Later in the year, it occurred to me that I could exploit the debugging hardware of the XScale CPU to offer a substantial performance increase, creating the 'breakpointing' engine (referred to now as 'StrongARM mode'). This emulation mode avoids emulating the vast majority of instructions, by pre-scanning the code to be executed and setting a breakpoint at the next 'unsafe' instruction. Unsafe instructions are ones that, when executed natively in 32-bit modes, can produce different behaviour, or lead to Aemulor 'losing control' of execution. Although I had deliberately been poring over the XScale datasheet in search of anything that might be useful to Aemulor, that was one of only a very few ideas that could perhaps be considered inspired and patent-worthy.
Other technical hurdles faced by Aemulor later in its development included the ROM image and RMA etc moving to higher addresses, and the unavailability of low-colour screen modes on the IYONIX pc hardware. Previously both Aemulor and the 26-bit modules it supported had resided in the 32-bit RMA which had its old address at &2100000. In order to avoid translating addresses, which would have a considerable impact not just on performance but also upon compatibility, to this day it is necessary for Aemulor to limit the size of the application space and to set up memory areas which mirror the 26-bit world of RISC OS 4.02 (System heap, RMA, SVC/IRQ stacks, I/O and VIDC hardware access and the OS ROM).
Additionally, since the graphics driver and hardware did not offer support for 1, 2 or 4 bits/pixel screen modes (2, 4 and 16 colours), Aemulor Pro was released a few months after the original Aemulor, and included support for emulated low-colour screen modes, operating both within and outside the desktop, as well as supporting 26-bit audio code, low-level interrupt handlers and hardware emulation etc with a particular focus upon running 26-bit games and importantly for some people, the music composition/typesetting package Sibelius. The support for emulating very low-level 26-bit software such as interrupt handlers, voice generators etc presents some very difficult technical challenges, because at any moment during Aemulor's operation, it may be necessary to 're-enter' Aemulor to run some 26-bit code in the background.
When Aemulor Pro was released, for fun I included an Easter Egg which resides in the code base to this day. The first person to discover this received a free copy of Aemulor Pro, although I suspect Neil must have offered some hints. At the time my only non-RISC OS box was a Windows NT Pentium III PC that was used primarily for dial-up (yes!) Internet access and web browsing. Do save your work before trying this: As a bit of a dig at Microsoft for its infamous Blue Screen of Death (BSOD), if you add an entry 'MS.Windows' into Aemulor's Application window, select it and click 'Run' it will faithfully reproduce an IRQL_NOT_LESS_THAN_OR_EQUAL blue screen error. I will admit I have always been baffled by the decision to catch a software error in software and then render the entire box unusable, discarding any and all unsaved work. Clearly the choice of a developer and not an end user!
Aside: whilst Windows itself tends to get the blame for BSODs, and sometimes it is reporting an issue with the hardware, I suspect that most are actually caused by incorrectly-written device drivers, and these faults can be very subtle. Trust me, I have committed and subsequently fixed a couple myself!
It's been a long journey. Aemulor has hopped from its original home on the IYONIX pc, to the BeagleBoard, PandaBoard, WandBoard | ARMX6, Raspberry Pis of all flavours and most recently the ARMbook. New builds of Aemulor have been brought to life at the Wakefield Show on the A9home, and on the Cortex-A15 (IGEPv5) and the Raspberry Pi 4 at the South West Show.
Thanks to Castle Technology, Stuart Tyrell Developments and Andrew at R-Comp for providing the hardware, often free or at discounted prices.
Aemulor Pro was released for free at first on non-Pi targets and later, as Aemulor Ultimate, for all RISC OS targets and it remains so to this day.
Well, some of it may happen one day...Faster emulation on all targets, not just the IYONIX pc. CPU architectures have changed a lot over the past two decades so what once worked well now may not. One new feature that has always had definite appeal, though it's no small amount of work, would be to execute non-desktop programs within a window, effectively providing windowed, multitasking operation of any 26-bit game/other program and conveniently sidestepping the issue of old-style game modes being unavailable (these often have very specialised resolutions and/or fewer than 256 colours). And, of course, the removal of the application size limit for which Aemulor is sadly infamous; whilst the most recent version (2.53) does manage to relax that constraint somewhat, allowing 52MiB application slots rather than the historical 28MiB limit, I can't really see the limitation disappearing at any point because aside from the huge amount of work involved, I think it would too greatly impact the compatibility and transparent operation of Aemulor. The ability to interwork freely between 26-bit and 32-bit programs was a key design criterion that has admittedly backfired somewhat in that Impression still depends upon it and sometimes people have reported a program failing because unbeknownst to the user and to myself, some of its code had been running under the auspices of Aemulor and could not run without it.
At some point if, in years and decades to come, RISC OS continues to be used, I think the compatibility issues will become too great for the Aemulor approach to remain viable and it will instead be necessary to employ some form of machine emulation rather than a compatibility layer. To close, some people will be aware that future ARM processors are likely to be 64-bit only (Aarch64) and to drop support for the 32-bit instruction set (Aarch32), and they may be drawing parallels with the migration from 26-bit to 32-bit. I feel I should point out that this is a much more significant change and whilst at some point down the line there may be an analogous situation of running part of the system natively as Aarch64 code, dropping into an emulation layer for running modules of code that remain in Aarch32, that really is a different prospect and an entirely separate project.
If you have any questions about Aemulor, or polite suggestions - ;) - about where it might go in future, feel free to get in touch.
Back to the present...Copyright © Adrian Lees 2020-2021