![](bg4.png)
Table 2: Emulator Selection Criteria.
Criteria The bad The good Hints
Ease of installa-
tion and configu-
ration
Need to compile, find ROM, con-
figure keyboard,...
Platform bundles/pre-configured
Running in browser
[e.g. Internet Archive]
Multi-system more difficult
Easy All-in-one distribution on
Raspberry Pi
Ease of use Raw emulator, poor media man-
agement
Power utilities integrated (media
mgt, snapshots, debugger,...)
Nice front-end
Machine/constructor specific
can bundle utilities
Providing libretro API
Accuracy Abstraction of many components Circuit/Cycle exact
(but higher CPU)
Check forum, game compatibil-
ity
Long term
support
Recent project
closed or small community
exotic technology
Long history
large community
VM approach
Check repository activities
and OpenHub statistics
ease of use, the emulator accuracy (which may impact
the resource required), its long term support, and re-
quired resources. For each criteria, some benefits and
drawbacks are identified. Some hints are also pro-
posed in order to guide in the assessment of the cri-
teria. For example, specific software (such as highly
optimised games) may require high accuracy such as
cycle exact emulation. In order to help assessing the
maturity and support for an open source emulators,
open source monitoring website such as OpenHub are
also helpful (Black Duck, 2006).
Note that the emulator choice does not need to be
restricted to a single solution. Actually complemen-
tary emulators may be selected as long as they can in-
tegrate in a common toolchain, for example through
the sharing of disk images. This can allow the use of a
specialised emulator for specific scenarios, for exam-
ple a more accurate emulator can complement a more
generic one for running some tricky software written
in assembly language at the price of more computing
power and maybe also more configuration time. As
more emulators means more maintenance work, it is
recommended sticking to a minimal number.
3.2 Example of Emulator Selection
In order to illustrate the selection process, we take
the case of the Amstrad CPC (covering CPC 464, 664
et 6128 machines and “plus” variants, depending on
memory and tape vs disk). Those 8-bits machines
are based on a Z80 CPU and were quite widespread.
There are more than 30 emulators (including vari-
ants but not considering browser ports) available from
multi-system platforms, such as MAME, to totally
specific emulators such as JavaCPC. We will use
those two extremes as candidates and compare them
using the list of criteria detailed in Table 2.
Table 3 summarises our comparison work and
also illustrates the respective emulators running the
same BASIC program using the integrated ROM in-
terpreter. The program was loaded using the same
disk image showing the interoperability between the
emulators. The installation was largely more easy
with JavaCPC as long as a JVM is installed it will
directly boot and provide a full desktop interface with
advanced utilities such as bidirectional copy/paste, in-
tegrated debugger with breakpoints or a virtual line
printer. On the other hand, MAME required to find
a ROM and to go through a more painful keyboard
configuration. Looking at the support, MAME is ac-
tively maintained while JavaCPC has not been active
for many years according to OpenHub. Emulators
produced by computer fans may face that risk. In this
case, it is mitigated by the fact the project is Open
Source and compiled to JVM bytecode meaning it can
run on many platforms supporting Java. In contrast,
MAME offer more guarantees of long term support.
In the end, using a combination of emulators is in-
teresting as JavaCPC provides a complete toolchain
at no cost while MAME guarantees a longer support.
Many other features are common such as disk and
tape emulation, snapshots or accelerated modes.
3.3 Elaborating a Complete Digital
Toolchain
Depending on the emulator, more or less utilities
might be available in order to provide all the useful in-
tegration capabilities with physical or virtualised de-
vices such as tape or disk storage. It is interesting to
build a graph of dependencies between various util-
ities to check if there is a good interoperability be-
tween physical and emulated devices. In the case of
our CPC, but also for many other micro-computers,
disk images in a standard format can be exchanged
across emulators. They can also be installed on disk
emulator directly connected to the physical interface
to experience the software on the real hardware.
Meeting Digital Preservation Requirements for Software through an Emulation Strategy
321