Software version 2.32
Using Aemulor from the Command Line
Aemulor Pro's Tasks display
Aemulor Pro and Screen Modes
Games under Aemulor Pro
Manual version 1.32
Aemulor allows you to run old 26-bit applications and modules (written before
the days of 32-bit RISC OS) on the IYONIX pc
26-bit code cannot be executed directly by the XScale and ARM9 processors used in
these machines because they do not support the old 26-bit addressing modes.
Aemulor is supplied as an archive/zipfile containing a single RISC OS module
that can either be loaded
manually by double-clicking on the module, or be installed in the Iyonix's
boot sequence so that it starts automatically. The archive also contains a ReadMe
detailing the latest information about the release not included in this manual.
To extract the software from the file you download from Aemulor.com, set the
filetype of the resulting module to &DDC or "Archive", then double click on
it. A read-only SparkFS was included with your computer so you do not need any
additional software to install Aemulor.
If you wish to run 26-bit code automatically on startup, eg. to have a 26-bit
application launch itself every time you switch on the computer, then you will
have to install Aemulor in the boot sequence. (Also, some applications may
require Aemulor to be started before the desktop starts up.) To do this,
simply copy the Aemulor module from the archive into the directory
!Boot.Choices.Boot.PreDesk and then restart your machine.
Note: some people have reported that on a few machines, they've had
to rename the Aemulor module in PreDesk so that it's called !!!Aemulor.
This shouldn't really be necessary, but it may be worth trying if you
The !Aemulor application, accessible via Apps on the icon bar once the Aemulor
module is running, provides an interface that allows you to configure the
emulator and to see what code is being run under emulation. If you want to
close the user interface without stopping the emulator, so that 26-bit code
will continue to run, just choose Quit on the icon bar menu. Choosing
'Emulator too' on the Quit submenu will stop the emulator as well, thus also
closing all 26-bit applications and modules.
This window allows you to configure the way that Aemulor behaves. Aemulor
stores its configuration settings in Choices:Aemulor in the conventional
manner. (So on a normal machine they can be found in $.!Boot.Choices.Aemulor)
This option allows you to choose whether Aemulor should automatically detect
and intercept all attempts to run 26-bit code (eg. double-clicking on old
applications or modules). If you choose this option Aemulor will work entirely
transparently, as if the 26-bit applications were running normally; and you can
even close the Aemulor user interface by choosing Quit on the menu.
There are some limitations, however, because it isn't always possible to tell
whether code needs to be emulated or not, ie. whether it's old 26-bit code. In
these cases we have taken the decision that it is important for Aemulor not
to interfere with the normal operation of 32-bit applications, so Aemulor will
only run something automatically if it is definitely 26-bit code.
If you choose to "Run all 26-bit code automatically" and find that a 26-bit
application does not work properly, you can drag the application's icon from
the Filer and into Aemulor's "Applications" window to tell Aemulor that any
'ambiguous' code found within that application directory is to be treated as
26-bit code. Programs that can't be run automatically are usually fairly
complex applications using a number of modules, and often report that they
need "version x.yz of module A" if you try to run them without telling
Aemulor that they are 26-bit code.
Just in case there is a problem with Aemulor that causes it to interfere with
32-bit applications running natively, there is an alternative option of only
emulating applications that are manually dragged onto Aemulor's icon on the
icon bar. If you encounter such problems please contact us and we will
investigate and fix them so that Aemulor's operation is once again
Please note that if your boot sequence includes 26-bit code then you should
choose the 'run all 26-bit code automatically' option because otherwise the
26-bit code will not be run under emulation and errors will occur when the
If Aemulor is unable to recognise an application as 26-bit code, as described
above, then you can drag that application into Aemulor's 'Applications' window
to tell Aemulor that it should be treated as 26-bit code. You will then be
able to start it in the normal way by double-clicking on it.
An 'Add' button is provided so that you can enter a pathname that contains
wildcards. For example,
*.!Schema2 means that Schema2 will be treated as
26-bit code wherever it's running from, allowing you to move the application
without reconfiguring Aemulor.
The Applications window also serves the secondary purpose of telling Aemulor which
emulation engine to use for each 26-bit program. Aemulor contains three different
- the StrongARM engine that uses unique hardware features of the XScale processor
and thereby offers much greater performance.
- the ARM610 engine which will also run some older applications that are not
- the ARM3 engine which is much slower but will also run some pre-RiscPC
Since the StrongARM engine is typically about 3.5 times faster than the
ARM610 engine it should be tried first, and only if an application fails to
run (often with an 'abort on instruction fetch' or an 'undefined instruction'
error) should the ARM610 engine be used for that application.
A9home Note: The StrongARM engine is the same speed as the ARM610 engine
on the A9home because the required hardware features of the XScale processor are
not available on the A9home's ARM9 processor.
Some very old software, especially games, won't run with the ARM610 engine
because it makes heavy use of self-modifying code, a practice which is frowned
up nowadays. For these programs it's worth trying the ARM3 engine which offers
the best compatibility with old code at the expense of much speed.
The ARM3 engine can also be useful for old games which expect to be running
on slow hardware and are therefore too fast to be playable when emulated
using the StrongARM and/or ARM610 engines.
When an application is started, Aemulor reads downwards in the applications
window trying to match the application's filename against each of the entries
in this window. Entries may contain wildcards, eg.
*.!Style will match any
copy of Impression Style, wherever it may be located on the system.
At the bottom of the Applications window is an entry "All other applications"
which will be used for any 26-bit programs that don't match any of the earlier
entries. By selecting this entry and clicking on 'Edit' you can choose the
default emulation engine. This should normally be left as the StrongARM engine,
but if for some reason you have a lot of old programs then you may wish to
Aemulor also allows you to specify, for each application, whether dynamic
areas should be created at low addresses. As noted earlier, some 26-bit
applications cannot cope with the areas being allocated at high addresses,
but since the size of the low memory is only 448MB, only those apps which
are known to fail otherwise should have the "Use low addresses for dynamic
areas" option ticked.
All changes in the Applications window take effect immediately and are
automatically remembered. There is no need to tell Aemulor that the
changes must be saved.
To help you find a particular application in the Applications window,
Aemulor provides a 'Find' dialogue, which can be opened by pressing F4
when the Applications window has focus. You can then type in the application
name (without the '!') or just the first few characters to quickly skip
to the appropriate line in the window:
Also included are buttons to skip to the next and previous matches and
the ability to specify case-sensitive or insensitive matching.
Press Escape to close the window or click on the close icon.
Lastly, as a convenience, the Applications window provides two further
buttons 'Run' and 'View' which mimic the corresponding buttons in the Filer's
Find window, ie. they start an application and open the directory containing
an application, respectively.
Ordinarily you should choose 'Do not produce a log file' in the Config window,
because applications could contain bugs that would cause Aemulor to produce
a fault report, wasting space on your hard drive.
If, however, you report a suspected fault/incompatibility of Aemulor to us
then we may ask you to change this option temporarily and send us the
resulting log file(s) to help us study and correct the problem.
Please bear in mind that applications which fail on a RiscPC running RISC OS 4
will probably fail in the same way under Aemulor. However, if you find that
your application is failing in a different way or more frequently, then this
may be due to a limitation of, or fault within, the emulator. So please report
the problem to us at the address given below so that we can improve Aemulor
for the benefit of other users.
Some applications such as StrongED 4.64 and Schema 2 do not work properly
if their dynamic areas are allocated at high addresses. This can occur even
on RISC OS 4 but with the altered memory map of RISC OS 5 and the larger
amount of RAM fitted to the IYONIX pc it is much more likely now. Aemulor
can therefore provide dynamic areas at low memory addresses for applications
that require this. The Applications window allows you to specify which
applications should use this low memory area, but it should be noted that
the area is of finite size (448MB) so the Config window allows the size of
individual areas to be restricted. If you specify a maximum size of 0 then
no limit is imposed.
Hiding the Aemulor icon
Aemulor is designed to operate transparently, so once you've told Aemulor
which of your applications are 26-bit (by dragging them into the Applications
window), you probably won't need to use the user interface very often.
By un-ticking the 'Display the Aemulor icon after booting' and clicking on
'Set' you can save some space on your icon bar. (Obviously you should only
do this if you've also told Aemulor to run 26-bit code automatically.)
The user interface can still be accessed via the 'Apps' icon on the icon bar.
Note that this option only applies when Aemulor starts up during the
machine's boot sequence. If you start Aemulor manually by double-clicking on
the module, the icon is always displayed ready for use.
Aemulor provides support for loading and using 26-bit modules within 26-bit
applications. This is necessary because 32-bit versions of RISC OS do not support
The modules window shows you which 26-bit modules are currently loaded under
Aemulor, their version numbers and locations as a graphical equivalent of the
*Modules command provided by the OS. This window also serves as a
handy way to load 26-bit (or 32-bit) modules by dragging them into the window.
If a 32-bit module is loaded in this way then any 26-bit equivalent that is
already loaded will be killed first.
The modules window can also be used to kill one or more of the loaded 26-bit
modules. Aemulor will warn you if the module is being used by one or more
26-bit applications; if it is, be sure that you know what you're doing,
because killing the module could cause failures or loss of work.
A command called
*Modules26 allows you to view the 26-bit modules from a
command line prompt, and the optional
*Modules26 -all parameter shows you the
modules that are visible to 26-bit applications, ie. all of the 32-bit modules
are backwards-compatible and can be used by 26-bit code, and the 26-bit
modules that are currently loaded under Aemulor.
Once you have run Aemulor you will find a directory called Modules located
!Boot.Choices.Aemulor into which you can place any 26-bit modules that
you wish to be loaded automatically when Aemulor starts up. This facility is
useful when a 32-bit module is found to be not backwards-compatible; the older
26-bit version can be copied into the Modules directory and will thus 'hide'
the 32-bit version from any 26-bit code wishing to use that module - the
26-bit version will be run under emulation instead.
The Tasks display window shows you the applications that are currently running
under emulation, and the emulation engine(s) being used. Additionally you can
see how much memory Aemulor is using to emulate each application. This will
be a fixed amount for the basic version of Aemulor but Aemulor Pro can compile
26-bit code into equivalent 32-bit code to give extra speed but at the expense
of using more memory.
Clicking the Menu button over on an application will select it and display a
menu that allows you to get further information or to quit that application.
Also shown are the dynamic areas that are being emulated by Aemulor, ie. those
which were created in the 'low memory area'. (See application
Clicking the Menu button over a dynamic area allows you to delete that area
which can be useful if a task has terminated abruptly and left its dynamic
area behind. Be careful not to delete areas that are still being used by an
application because doing so will almost certainly cause it to fail.
Aemulor allows two special filetypes to be used to also indicate that an application
should be run under emulation.
To indicate that a BASIC program contains 26-bit assembly code, and should
be run under Aemulor, set the filetype to BASIC26
This is designed for allow an application (regardless of language) to be run
under Aemulor by changing its !Run file to filetype OBEY26.
For both of these filetypes, if you want the application to no longer be run
under Aemulor, just change the filetype back to BASIC or OBEY.
Using Aemulor from the command line
If you need to run a 26-bit application from a command line and Aemulor isn't
automatically detecting that the application needs to be emulated, you can
prefix the command with
AemuExecute to force it to be emulated.
This is, in fact, how the 26-bit filetypes
BASIC26 are implemented
and it can be used to ensure that other files are executed under emulation.
For normal desktop applications this isn't necessary because double-clicking
a document file causes the application to be started and Aemulor already knows
that the application is 26-bit code.
AemuExecute should work for any *command, including module commands - eg. you
can 'enter the 26-bit world' by typing "
AemuExecute BASIC" within a TaskWindow,
and then any commands/programs that you run using the BASIC interpreter are
'emulated' by Aemulor so that they behave the same as they do on RISC OS 4.
Be warned that if you use AemuExecute to run code that is already 32-bit
compatible then it will also run under emulation, and will therefore suffer
a performance hit; since such code is 26/32-bit neutral and will run either
under Aemulor or natively.
Help on 26-bit modules and their commands is available from the command line
(32-bit or 26-bit) by typing *Help as normal. Note that Aemulor will match your
query against the 26-bit modules first and then let RISC OS check the 32-bit ones.
If RISC OS finds no matches it will display No Help found even if Aemulor has
already displayed some 26-bit help text.
For convenience when calling 26-bit command-line utilities, Aemulor provides
a TaskWindow via its icon bar menu. Choosing this option will open a 26-bit
TaskWindow and everything executed within this window will run under Aemulor
including *commands and, after typing 'BASIC' to invoke the BASIC interpreter,
any BASIC commands or programs that you enter.
Aemulor Pro and Screen Modes
Aemulor Pro is able to emulate in software the low-colour screen modes that
are not available natively on the IYONIX pc, namely 2-,4- and 16-colour modes.
It does not, however, provide new screen resolutions and frame rates at present,
so any screen modes required by games that you want to run must be included in
your Monitor Definition File (MDF).
The MDF for your monitor can usually be found in
and it will be necessary to edit this to include new mode definitions. A sample
MDF containing many useful screen modes is supplied on the Aemulor website.
The emulated low-colour screen must be converted to the native 256-colour
screen by Aemulor Pro. Although this operation must be performed in software,
it incurs a fairly minimal performance hit, by translating the pixel writes
as they occur rather than repeatedly converting the entire screen in software.
Although this feature is intended for use with old educational software and
games, it will also work in the desktop.
Games under Aemulor Pro
Aemulor Pro is able to run a large number of the games that have been published
for the Acorn Archimedes and RiscPC machines over the years. Since games are
a much more demanding use of Aemulor than desktop applications, here are a
few hints and tips that may help to get old games working:
- Change the processor type (StrongARM/ARM610/ARM3) for that game.
Some games will only work on certain processors; as a rough guide the
game's age should be a clue:
- 1987-1994 = ARM3 Archimedes
- 1994-1996 = ARM610 RiscPC
- 1996- = StrongARM RiscPC
It can also be helpful to use an older processor type if you find that
a game is too fast under Aemulor.
- Many games require specific screen modes which are not normally provided
on the Iyonix. Often one or more screen mode definitions (called 'MDF' or
'Modes') can be found inside the application itself and these should be
copied into the Monitor Definition File (MDF) that you use for your
monitor. (Inside $.!Boot.Resources.Configure.Monitors..)
It's worth checking the game's !Help file, if it has one, for further
After modifying the file, you should double-click on '!Boot' and then
'Screen' to open the Screen Configuration utility. This provides an easy
way to test the new screen mode on your monitor to make sure that it
- A related problem is that often the frame rate of the native screen mode is
much higher than the game expects, causing the music and/or game itself to
play too quickly. This problem is compounded by the fact tha RISC OS will
normally choose the highest frame rate available for a given resolution.
You may find that you have to comment out/remove high frame rate,
low-resolution modes. A future release of Aemulor Pro will aim to make the
use of non-native screen resolutions and frame rates a lot simpler.
- Spheres Of Chaos performs a lot better if the Vision option 'Draw to buffer'
is used rather than 'Draw directly to screen.' Other games may benefit from
similar settings where available.
- Some games assume that they can write directly to low memory addresses
(particularly &4000-&7FFF). These addresses are protected on RISC OS 5 and
it is necessary to run a small patch that removes this protection before
the game will run. The 'Unprotect' patch is available on the website and
can be copied into the game's application directory. The following command
should then be inserted at the start of the game's !Run file:
Technical Details and Limitations
Whilst Aemulor is running, all applications (including 32-bit ones) will be
restricted to a maximum of 28MB each as for RISC OS 4. This is necessary
because 26-bit code can only be executed below the 64MB addressing limit
and 26-bit modules and utilities need somewhere to run.
A future version of Aemulor may find a way around this restriction but
it's very difficult to solve from a technical standpoint and, even if
possible, will likely have a significant impact upon the speed of emulation.
Remember that whilst Aemulor Pro emulates some of the hardware present in
older machines, it is not a full machine emulation and there will therefore be
some games and applications that do not work as expected.
Aemulor Pro's Task Display window cannot be used to resize memory
areas at the moment.