Introduction to Amiga Emulators

The Original Amiga

The original Amiga 1000 computer was built around a Motorola 68K series CPU, with the addition of Amiga-specific custom chips (named Agnus, Denise and Paula). This combination made it a very powerful multimedia computer in 1986. The original chip set is often referred to as OCS. Newer releases include the ECS and AGA chip sets.

The Amiga operating system runs on top of this hardware. Early Amiga operating system versions required the full set of Amiga custom chips, including the parts responsible for the graphics rendering. Newer operating systems (e.g. 3.X) also support RTG (ReTargetable Graphics) display cards, which are more powerful (i.e. faster and with a broader variety of video modes) than the custom chip graphics.

Amiga software (e.g. productivity applications, games, and demos) was originally not only allowed, but encouraged, to fully use both the operating system and the underlying custom chip features. This resulted in impressive software, which however also had a strong dependency on the hardware.

Amiga Emulation

The Amiga environment as included in Amiga Forever consists of a combination of emulated Amiga CPU and custom chips, plus an operating system which runs on top of the emulated hardware. The hardware emulation itself is in large part based on open source projects such as UAE and Fellow, which are seamlessly integrated within Amiga Forever (source code is included).

Additional components licensed for use in Amiga Forever include enhancements that used to be optional add-ons on the original Amiga (e.g. AHI audio, TCP/IP, SCSI, etc.), as well as software modules which the former Amiga companies had originally licensed themselves, but the licenses for which would otherwise have expired.

Even Amiga Forever has some limitations. Because Amiga Forever is software-based, it cannot emulate the physical hardware interfaces of the original Amiga. This is normally not a problem, as the emulation supports several hardware options to use original Amiga peripherals, to read old Amiga floppy disks, and to otherwise transfer software and data from an existing Amiga, if necessary.

Other Approaches to Emulation

Other approaches to achieve different degrees of compatibility with the original Amiga exist, for example the AROS project aims to be compatible with the Amiga operating system by re-writing the operating system itself (i.e., without using the original operating system, and running either on "real" or emulated Amiga hardware, or on an entirely different system), while other emulation projects (e.g. Amithlon) tried to make newer versions of the Amiga operating system run on an emulated Amiga hardware with limited custom chip emulation. Because Amiga Forever includes a full emulation of the original Amiga hardware, plus add-ons, plus a selection of operating systems, we believe that Amiga Forever offers a superior solution for running Amiga software on modern hardware.

Several types of emulators have been developed for a variety of system, with more or less different approaches to the emulation of the target systems (Mac, Atari ST, etc.). Basically, to different extremes, some emulators emulate a computer's hardware, while others emulate its operating system (OS). Emulating the operating system means that the original operating system is replaced with an "imitation", which makes it possible to avoid copyright and other legal issues regarding the "look and feel" and the original code, for example, and often also allows for faster execution of the (replaced) system functions, because the new functions can be written specifically for the host environment, and are not running in emulation mode. In the case of the Amiga, also considering that the original Amiga patents have expired, it is generally believed that an unlicensed "imitation" could be a viable approach to avoid legal conflicts.

The major drawback of this approach is the reduced compatibility with respect to the original operating system because, by definition, the replacement operating system is not exactly the same as the original operating system, with all its more or less documented idiosyncrasies, side effects and, in some cases, even little bugs exploited by applications which may be aware of them, or even not. Additionally, in the case of the Amiga, emulating the operating system would solve only a relatively small part of the task, because ever since the Amiga was released, programmers were encouraged directly by Commodore, and were inspired by the exciting Amiga architecture itself, to directly access and exploit hardware features such as the "blitter" and "copper" chips, sprites, HAM screen modes, etc. These features, which made the Amiga so special and superior when it appeared, are not provided by the operating system, but are instead part of the Amiga custom chips, which can be accessed directly by the software. The various implementations of Amiga emulation software included on Amiga Forever try to perfectly emulate the Amiga hardware. This allows not only existing games and productivity software to continue to run on new computers without changes, but it also makes it possible for the original Amiga operating system and ROMs to run on the emulator, and to be accessed by existing as well as by new Amiga software, with predictable and trusted results.

Amiga Forever not only includes original ROM and operating system components and their updates, but it also includes and supports operating systems that can run on the original Amiga hardware, but which were not developed by the former Amiga companies. For example, Amiga Forever includes the Dialoga 2.0 ROM by Logica (a diagnostic system used by Amiga repair centers), and it can run the 68K version of AROS, as well as other 68K-based operating systems.

Interaction with the Host

The Amiga environment as included in Amiga Forever can run side by side with the host environment (e.g. Windows, macOS or GNU/Linux).

The Amiga emulation environment in itself does not replace the operating system on which it runs (the "host environment"), but rather it takes advantage of the system's graphics, sound and file system drivers, of the memory protection, virtual memory, windowing, etc. In this way, the Amiga can run in a window, next to other applications, or it can run in full screen. In most cases, the emulated Amiga can read and write files on the host system, it can print, and it can crash and display a "Guru" message (but this will not cause the host environment or the emulator to go down with it), and then be reset, exactly like a normal Amiga. It is even possible to run an Amiga with Workbench 1.3 in one window, and one with Workbench 3.X in another window, next to it. In all cases, each emulated Amiga has one window or one full screen open in the host environment, and within that specific window or screen all Amiga action is rendered, as if that window or screen were the monitor connected to a "real" (silicon) Amiga.

Performance

The overhead associated with emulating different hardware components in software is such that the emulated parts are roughly between 5 and 20 times slower than the original components would be if they were running at the same speed as the hosting hardware. The Amiga operating system, which is as efficient and fast as it is elegant, was designed to run smoothly with hardware that was available around 1985. Since then, many platforms and CPUs doubled in speed every 12-24 months. As a result, the overall (subjective) feeling of the UAE and Fellow emulators is that a Pentium CPU running at 133 MHz (as in 1997, when Amiga Forever 1.0 was released) compares well with an Amiga 500, providing enough usability for tasks such as word processing and programs like Personal Paint. It certainly makes an impressive and very useful Amiga notebook. The use of sound and the type of frame refresh rates and custom chip effects used in many games require more powerful machines. Considering even maximum use of CPU and custom chip resources, a GHz-class PC makes it possible to run an Amiga 1000 in real time, whereby the custom chips run in real time (as required), and the emulated CPU may run faster (if so desired).

Other parts of the emulation, such as the file system, can easily be faster than an original Amiga when an Amiga partition on the emulation environment is mapped directly to the host file system. On such a 133 MHz Pentium system, the 68000 CPU is already emulated at more than twice the speed of an Amiga 500. The custom chips add to the overhead, resulting in an overall poorer performance if they are used intensively, as they are in some games. A Pentium Pro or Pentium II running at 200 MHz feels like an Amiga 3000/030, again with a very responsive file system, and even a faster windowing action when used with RTG drivers. To make an example of a CPU-intensive task, compiling Personal Paint with SAS/C in UAE emulation on a Pentium Pro/200 MHz system takes about twice as long as on an Amiga 4000/040. Intel systems running at 300 MHz have been tested running some of the most demanding games in real time, without missing a single frame, and with perfect audio. Very few games and demos require more powerful systems.

The Amiga custom chips have only one important emulation requirement, which is to be able to run in real time. For timing reasons, it would not be practical to speed them up beyond their original performance. Once this is achieved, all the power of the host CPU(s) can focus on emulating the Amiga 68K CPU. In practical applications, already in the 1990s the Unix version of UAE running on an Alpha CPU system had already shown to be faster than a similarly equipped Amiga 4000 with a 68060 CPU. Of the two, the Amiga 4000 was the more expensive system.

Compared to the superior performance of emulation components such as the CPU, the file system, and the RTG graphics subsystem, sound lies on the less fortunate end. On the Amiga, sound is synchronized with the display in such a way that unless a full video frame rate is achieved in real time (50 frames per second), then audio cannot be output smoothly. Again, audio emulation can be of acceptable quality on a 133 MHz  Pentium CPU, if the application does not make intensive use of other custom chip features. Also, Amiga Forever includes AHI drivers to produce high-quality audio without resorting to the emulated custom chips.

In 1997, when computers were much slower than they are now, Bernd Schmidt, chief designer and author of the UAE emulator, described some performance issues of the custom chips as follows:

All timings I give here were measured on my machine, a 90 MHz Pentium, using SVGAlib, with the FASTER_CPU and DONT_WANT_SOUND options... For games and demos, the CPU speed does not matter, but the average frame time is important... A real A500 has a constant frame time of 20 ms (50 Hz). If you have a game/demo that has lots of blitter activity, many copper/sprite effects, dual playfields and scrolling, no one can help you. Fortunately, this case is extremely rare. Normal games that have a number of blitter objects, scrolling and maybe some sprites run at 1/3-1/4 the speed of an A500 in the worst case, some run at 1/2 the speed. Lowering the frame rate helps enormously here, and at 1/5 frame rate, about everything runs somewhere between 50% and 100% the speed of an A500. This still isn't the full story (I bet you start to see why the question is hard to answer). A real A500 without fast memory gets slowed down to about half its speed in Hires 16 color mode. More bitplanes also slow UAE down, but not quite as much, so it can be several times faster than an A500 in that mode."

Frequent questions about Amiga emulation include the performance impact of having to emulate custom chips, in addition to the CPU, and why the emulators don't try to emulate a more powerful "68K" CPU, like a 68060, or why the AGA chip set is not emulated, but only the original chip set is. As outlined above, most Amiga programs, first of all the operating system, make direct or indirect use of the Amiga custom chips. On the other hand, it must be considered that when a program does not make specific use of a custom chip's functionality, this does of course not need to be emulated, so there is little or no performance penalty. To the contrary, specifically emulating certain aspects of the Amiga custom chips allows the emulation software to recognize certain specialized tasks, and to better emulate these by using similar and specific capabilities on the host environment, if possible (e.g. for blitting, which for example is very fast using the RTG extensions for UAE). As for the CPU, it would not be very practical to try to emulate advanced parts of the CPU such as the cache RAM, or the MMU (memory management unit), because these are already fully provided (not emulated) to the entire emulation environment by the host CPU. As a result, it is for example possible to emulate an Amiga with 64 Mbytes of Amiga "fast" RAM and 8 Mbytes of "chip" RAM on a computer having only 32 Mbytes of RAM, and the host operating system (using the host CPU's MMU), will take care of disk-to-memory swapping as necessary. The Amiga operating system does not require a MMU, so apart from Amiga virtual memory utilities, which are not necessary because virtual memory is provided by the host environment, the main applications that could still benefit from an emulated MMU are development tools such as "Enforcer". Indeed, such useful functionality is part of the emulation engine.

As for the 68K CPU type, the Amiga emulation software supports the instruction set of the Motorola 68020 CPU with FPU (floating point unit), which makes it possible to run even programs designed for newer CPUs, since they share the same instruction set as the 68020 (which had major additions since the original 68000). A few new instructions and addressing modes have indeed been added to newer CPUs of the 68K line, but there is no known 68K Amiga software on the market which requires these without also being available in a 68000 or 68020 version. To the contrary, certain instructions which run properly even on the 68000 are "illegal" on the 68060, which results in many applications (including older versions of the operating system) failing to run on the 68060. This explains why several owners of Amiga computers with a 68060 CPU resort to an emulator to run old software which would otherwise fail. With consideration to different 68K microprocessors, such as the 68030, 68040 and 68060, it should be kept in mind that the major performance boost comes from the improved speed and efficiency of the newer microprocessors, and not from new instructions. Again, this increase in computing power can be provided not by emulation, but by a faster host CPU. Both the Fellow and UAE emulators come with special options and versions so that some very old software which absolutely requires a "pure" 68000 (and not a 68020) can run on the emulator.

Versions of the emulation software that run on x86 CPUs include a "just-in-time" (JIT) compiler, originally developed by Bernd Meyer, which can make the emulation of the CPU on average at least 10 times faster than without JIT.

The emulation software included with Amiga Forever also includes a virtual display card, which directly accesses the graphics hardware of the host system using high performance DirectX calls, and which can be used by all Amiga programs which support the Amiga RTG (Retargetable Graphics) specification, which was originally conceived at Commodore, and then became a de-facto standard with the help of several Amiga developers. Performance profiling tests have shown that some programs spend as much as 50% of their execution time not in their own code, but in the system graphics routines. Mapping these calls as efficiently as possible to the graphics system of the host environment (which can easily be 100 or more times more powerful than the original Amiga graphics hardware), rather than to the emulated Amiga custom chips, results in an impressive performance boost for the entire emulation environment.

Multiprocessing systems (i.e. with two or more CPUs, also referred to as "SMP") improve the performance of the emulation, because the load of the operating system and other applications can be better distributed, relieving the CPU(s) which run the emulation. This improvement always occurs, even if the emulation software itself does not actively exploit certain SMP features.

The RAM requirements to run the emulation software are not different than those of any other software. All Amiga Forever components have been successfully tested on a system with 16 Mbytes of RAM. The Amiga emulation requires about as much RAM as a real Amiga, plus some memory necessary to run the emulation software itself (a few Mbytes).

Operating systems such as Windows, which support virtual memory, make it possible to emulate an Amiga with more RAM than is actually available on the system. If the emulation is configured for more RAM than is available, then the operating system will swap unused RAM to hard disk, and then from hard disk to "real" RAM, as necessary. This is not the fastest way to run an Amiga, but it is better than not having the desired amount of RAM at all.