An Overview of Emulators for Linux
Programs that make one computer work like another are called 'emulators', and one of the greatest strengths of Linux is its library of emulators. Capable programmers have graduated to Linux from dozens of other computer platforms, and brought their expertise with them.
They have developed software to allow Linux enthusiasts to run programs originally written for very different machines. The Linux philosophy means that most of these packages are free, and developers pool their experience to capture every nuance of the original system, and derive fresh benefits from the new platform at the same time.VMac - click for detail ->
Emulators are as important to the future as to the history of computing. Emulators are at the heart of new systems like Crusoe from Transmeta, Linus Torvalds' workplace. They were crucial to the introduction of DEC's Alpha architecture, and Apple's shift from 68K to PowerPC chips.
The trendy programming language Java is based upon an imaginary computer, the Java VM (Virtual Machine). Java compilers do not generate machine-code for any particular processor, but byte code for that virtual machine, which is later translated to deliver compatible results. That's just how most emulators work.
Emulators help both designers and users. They allow users to stick with the software they know and understand, as hardware platforms come and go. They give hardware designers the freedom to innovate, without the fear that there will be no software for their new designs.
As computers advance it makes sense to use the hardware power of new machines to keep old software working, even if it runs slower than it might if rewritten from scratch. Most emulators must interpret and translate programs for one machine, instruction by instruction, to suit another, and it takes several new instructions to decode each old one. They also have to mimic the behaviour of other parts of the original system.
Computers keep getting faster so the emulation overhead is tolerable, as long as you upgrade your hardware every few years. That's usually cheap compared with replacing all your software, not to mention the hassle of learning how to use the new stuff.PCEmu colour text
Older programs were often written specifically for certain hardware, with strict expectations about timing, protocol and data organisation. A good emulator will appear just like the old hardware to the program it's running, but communicate with others in the standard Linux way - so networks, USB devices and modern drives are readily available to systems that would have no chance of connecting, let alone communicating, with them any other way.
The most popular platforms, including business computers and mass-market home computers, are supported by several emulators for Linux. Features vary depending on the aims of the programmers - some aim for maximum compatibility, while others emphasise speed or extensions to the original system.
The multi-tasking, windowing and device-independence of Linux means you can emulate several platforms at once, on one machine, and pass data between them. Linux device drivers and conversion tools let you use the latest hardware with programs finished long before that was invented - and this is true as much of peripherals as processors.
Emulators are often more capable than the machines they impersonate. Most are freely available. But hardware and software requirements vary, and some barely work at all. This feature, and regular columns that will follow, helps sift out the stars from the non-starters, explaining what sort of system you need to run each emulator, and where you can go for software and support.
The idea of emulation dates back to the first computer, designed - but never completed - by Charles Babbage in the 1840s. Babbage explained in his 'Life of a Philosopher' that his Analytical Engine could perform *any* sequence of analytical operations on an unlimited number of figures, trading time for capacity if necessary. Any computer can emulate any other, given unlimited time to do the job!
A century later Alan Turing documented a 'Universal Machine' that could perform any computable process. In 1937 this was just theory, but within a decade Turing and others built working digital computers - and the problems of software compatibility were beginning.
The classic computer science text 'The Art of Computer Programming' presents all its examples in a mythical machine language, MIX, intended to convey the essence of real machines without the architectural warts that complicate production computers.
Professor Donald Knuth documented MIX in volume 1 of his series by writing an interpreter for it, in its own language. That program is a peculiarly specialised and self-referential emulator.
It is a clever idea that serves a useful purpose, and indicates a lot of the reason why programmers find emulation a fascinating topic. Emulators demonstrate intimate knowledge of the computer they mimic, and epitomise one of the key concepts of computing - that the complex, man-made imaginary world in one computer is both distinct and equivalent to the world in every other.
MIXAL is a program that translates and runs MIX programs on Linux systems. If that's not interactive enough, you can use it to run Knuth's MIX interpreter, and use that to prototype extensions which MIXAL can integrate. The idea of emulation is fun, and fashionably post-modern, but it's also practical and useful in ways that self-referential conceits seldom are.PCEmu virtual PC hardware ->
In the late 1970s the University of California, San Diego promoted a dialect of the Pascal language by compiling it into p-code - pseudo- instructions for an imaginary processor which could be easily implemented on real computers. UCSD Pascal thrived in education, where compatibility was more important than speed, and students could run the same programs on big college machines and Apple ][s at home.
This was not just a matter of making the compilers compatible - the compiler itself was written in Pascal, and compiled into p-code, along with the entire program development and run-time environment. The only part of the system dedicated to a given platform was the p-code interpreter, a relatively small, well-defined collection of simple routines, and some basic (perhaps too basic) input and output channels.
P-code is now being touted commercially as a rival for Java on set-top boxes, on Linux among other platforms. There's also PJS, a p-code engine, ironically written in Java.
UCSD Pascal was slow, compared with languages that compiled to native code, but much more portable and compatible because of the extra layer that the p-code emulation provided. Soon academics realised that the abstraction provided by the p-code interpreter could be provided in hardware, rather than software.
They redesigned a DEC minicomputer to run p-code directly, eliminating the interpreter and most of the emulation overhead. The UCSD P-Engine still had some emulation properties, particularly for input and output, but the abstraction of pseudo-code meant that it did not matter whether it 'ran' in hardware or software for another chip. The only significant difference was execution speed.
Notice that the emulator came first. Only later, once it had proved itself, did someone go to the trouble of implementing it in silicon.
The Transmeta project that pays Linus Torvalds' bills relies totally on emulation. Crusoe hardware uses a pared-down parallel processor with an unique instruction set. Yet it 'runs' X86 instructions, and potentially Java and other codes, using scant power in proportion to its throughput.
'Code morphing' software dynamically translates blocks of Intel instructions into Transmeta's VLIW (Very Long Instruction Word) code, saving translations in a cache so it can run directly next time it's needed.
Despite the hype, this is a well-established approach. The innovation is that Crusoe chip was designed from scratch as an emulation engine. No one outside Transmeta is expected to program the VLIW engine, which may change from one chip to the next. Not before time, the software is calling the shots.
Emulating the future
Nowadays new processors are routinely emulated before anyone tries to implement them in silicon. This saves fortunes in hardware re-design, and makes it possible to develop architectures which would otherwise be impractical to test and debug.
Motorola's last hard-wired prototype, for the eight bit 6809 chip, spilled across several desks and demanded months of fine-tuning before it was committed to silicon. By the time it arrived, the much more capable 68000 was finished. That part was emulated in software before the chips were made, with no need to lash together its 68,000 transistors and sort out all the resultant mechanical problems, to prove that it would work.
Modern processors are emulated several times over before they're baked onto chips. First the instruction set is modelled, to break it down into internal operations and sequences that can be overlapped in hardware. Then a detailed simulation checks out the logic and interactions between parts, with subroutines for gates and variables mimicking the signal levels between them.
Exact timing becomes more important as the development proceeds, to the extent that a good VHDL (Virtual Hardware Description Language) simulator can tell you not only whether or not a chip will work before you bake it, but how fast it will go and how much power it will need.
General-purpose emulators seldom descend to this level of detail in order to run programs, but often have to simulate other hardware - ports, displays and peripheral chips - with very precise timing and interactions. This part of an emulator can often consume more processing power than reproducing the behaviour of the main processor.
This is particularly true of games consoles, where the display hardware is designed to minimise demands on the control processor and do lots of work for the programmer. It also applies to computers designed by experts with access to a chip fabrication plant, rather than cobbled together from off-the-shelf parts.
Emulators typically run programs written for a processor other than that which hosts the emulator. The original code can be translated in two ways - interpretation or compilation.
Interpretation involves looking up each instruction as it is encountered in the emulated program, locating a routine to do something equivalent in the host environment, and running that code before moving on to the next step. Typically the look-up process dominates the time, so it's not uncommon for an interpreter to use 50 or more native instructions for every one it emulates.
Compiling emulators aim to translate each instruction into corresponding native code. It's the difference between following a procedure by translating the instructions as you go along, and taking time out to translate the whole thing, then using that translation directly. There are pros and cons to each approach.Executor Mac emulation is surprisingly fast ->
Unlike high-level language compilers, emulators rarely attempt to translate the whole program at one go, because they can't be sure what is code and what is data. They have to step carefully at first, like interpreters, and only store translations of what actually turns out to be code.
These are called 'Just In Time' compilers. They're slower to start and need a lot more memory, for the translated code and tables to link it with the original, but deliver better performance as they don't re-translate instructions they've seen before.
Even so, they almost always need several native instructions for each one emulated. The ratio depends on the difference between the two machine-codes, the compilers used, and the style of the programmers concerned. Emulated code invariably runs slower than programs recompiled for the new platform from the original source.
Compiling emulators often run into trouble if the original program was self-modifying code. This was a common optimisation before CPU caches became popular; it makes compilation much more difficult because the emulator has to check for modifications to code it's already translated, and invalidate the translation if the code has changed in the meantime.
If you've already entered lots of data it can be difficult or time-consuming to convert it for a new package. With an appropriate emulator, you can carry on using your old software, and data. You might still need help to move the data onto the modern drives on your new machine, but a good emulator will make this relatively straight-forward.
If your existing hardware can't read the original media, homebrew adapters or specialised gadgets like Individual Computers' Catweasel may come to the rescue. If you own both systems, a serial cable may allow slow but automated transfers, with specialist software or a terminal emulator at each end.
Emulators introduce as well as cure some compatibility issues. They have to store files originally intended for tape or small disks with peculiar directory structures on a Linux file system. There are two main ways to do this, with a myriad variations. Either the contents of the entire emulated medium - tape or disk - can be wrapped up in a Linux file that appears to be a drive to the emulator, or the emulated system can be patched to look for individual files in a Linux directory.CPC4x on Corel Linux
Problems with file names and attributes make the first approach more compatible. A disk or tape image can store meta-information such as file types, headers and addresses that might need to be associated with the files but won't fit in a Linux directory. It's a trade-off between ease of access on Linux and from within the emulator.
Emulators also allow access to real and simulated hard drive partitions, which may be shared or exclusive to the emulator. Emulators generally come with programs to list, insert and remove individual files from such drive-images, and convert between formats. Emulator file formats, and conversion tools, will be discussed system by system in articles to come.
The limited memory and backing storage on older micros makes another approach practical. A 'snapshot' is a file containing the entire state of a machine - program, data, screen image, even the contents of hardware registers.
Emulators can load and save snapshots in many formats. Converters exist, but compatibility is not assured as the format is closely tied to the expected hardware, or its exact emulation.
Snapshots can bypass tedious registration and setup code, tape loading or problematic hardware probes. They're great if you want to pause a game part-way through and resume from exactly where you left off. But if the original title overlays several parts, a disk image is more efficient.
IBM clone and Apple Mac emulators fall naturally into two categories - those for systems with the same processor, and those which have to emulate that, as well as the rest of the required environment. The first group can deliver relatively fast emulation. The second are potentially more flexible but lag behind the performance of recent systems they aim to emulate, because of the overhead of interpreting code for a different type of CPU.
Strictly speaking, systems that work without code-translation are not emulators at all - they are alternative run-time systems. These invariably let you run Linux at the same time as the rival environment. Otherwise on an IBM-compatible you could just reset Linux and let LILO guide you into a Windows or DOS partition.
Such a 'dual boot' system eliminates the need for any type of emulator, but it's relatively clumsy because neither Linux or Windows are exactly quick-starting systems. BIOS limitations leave a lot of work to be done before you can start any of your own. It's more convenient and typically half as much hassle to run both at once, but to do that you need software to set up another 'virtual machine' inside the system you run by default.
The leader in this respect is VMware, a commercial product which can run Microsoft Windows in an X Window, or vice versa. This is custom-coded for IBM-compatible X86 systems.VMware - click for detail ->
There are similar packages for other processor architectures. Mac-On-Linux lets you run MacOS under PowerPC Linux. SheepShaver (scion of the Amiga ShapeShifter) can run MacOS by sharing a PPC with Linux. Basilisk 2 pulls a similar trick for 68K systems.Visit MacOnLinux?
All these are quick, as there's no CPU emulation overhead, but can only run code for the same processor family. The clever thing is not the way the two systems share the processor and memory - that uses the 'virtual machine' hardware which is common to most 32 bit processors - but the way they share other hardware like drives, ports and the screen. They can make a window on one system look like a graphics card to another, and a large file look like a hard drive - right down to emulation of the registers of non-existent hardware controllers.
In this sense, VMware is a true emulator. Intel's Virtual Memory (VM) design creates the virtual x86, with a few caveats; the 'ware' part emulates the rest of the IBM PC environment. Free software can easily do the former - each Linux process runs in a virtual machine by default - but FreeMware and its successor Plex86 so far lack the finesse of VMware in virtualising the rest of the PC.
Win4Lin, reviewed in LXF11, does a similar job at an intermediate price, but only for Windows 9X on Linux. Sun have WABI, a tool to run MS-Windows 3.1 programs on Linux, but this does not support MSDOS or 32 bit Windows code. DOSEMU is widely-distributed freeware, intended to create a 'DOS box' by virtualising Intel hardware; it can be coaxed into running Windows 3, but has many quirks even by the standards it sets out to emulate.
There are several true emulators that translate X86 code, but most of these only implement a subset of the hardware expected by 32 bit Windows. They're adequate for MSDOS applications, but not modern graphics. PCEMU is a text-mode-only emulation of 16 bit MSDOS. PCM offers interpretive emulation of MSDOS and VGA graphics, and XDOS runs MSDOS with mouse control.
Bochs is a particularly ambitious project that can use the X86 directly, or emulate it on otherwise incompatible machines. The name is a pun on 'box' - it offers a Windows box on a Linux box, or many other variations.Busy Bochs ->
The current translator interprets the 486 instruction set, with Pentium and cached compiling extensions planned. Kevin Lawton, the developer of this Linux PC emulator, is now working for Mandrake, mainly on the Plex86 virtual machine; those with other CPUs should encourage him to get back into his Bochs.
Another way to run Microsoft programs in Linux is to duplicate the software environment they expect. 32 bit Windows applications do not talk to hardware directly - they call Microsoft routines to do the dirty work. If someone writes equivalent routines, with the same interface, for Linux, the Windows application might not know the difference. It runs just as it might on some future version of Windows, with the same API (applications program interface) but a revamped system kernel.
The long-running WINE project slaps a Windows-compatibility layer on top of Windows. Corel's Linux 'versions' of PhotoPaint and WordPerfect use this to run essentially the same code as in their Windows products - even the dialogs and drive names use Windows conventions. WINE can also run Lotus Notes, and some relatively tame games.Visit WineHQ?
WINE might be assumed to stand for WINdows Emulator, but is officially a recursive acronym for 'WINE Is Not an Emulator'. The good news is that WINE does not include any Microsoft code, so you don't need to buy (and regularly upgrade) Windows to gain compatibility. The bad news is that it only supports some of the Windows system-calls.
The source is freely available - but in two versions, because Corel's changes to make their software run have diverged from the sources maintained elsewhere. So the effort is not just vast, but fragmented, giving VMware the edge for those more limited by time than money.
If you want to develop new software to suit both Linux and Windows, you can use compatibility toolkits like Willows (formerly TWIN), QT, Bristol and Mainsoft. Like WINE, these are not strictly emulators, but deliver similar benefits. We'll return to the tricky area of PC compatibility in a future column.
Emulation is a battleground for lawyers. It's likely to remain that way, because the law is a long way from catching up with the legal issues raised by software, let alone the Internet. Emulation itself is legal, and certain to remain that way. Every significant product upgrade that provides backwards-compatibility involves emulation, in hardware or software.
Linux majors on free software, but there are many thousands of good free programs for many other systems, which alone could justify their emulation, as long as the 'firmware' or ROM (Read Only Memory) code built-into the system is also obtainable. If you own the original you have the ROM - the challenge is to get it into your emulator.
Authentic ROM files for Vectrex consoles, MGT's SAM, Elan Enterprise, CST Thors and similar systems are freely available. Enthusiasts continue to develop ROM images like 'Minerva' and 'Chloe' for classic computer hardware and emulators. Apple system CDs from 8.6 onwards include a complete ROM image, so if you buy one of those you can legally use the code on other hardware.
Amstrad allow free non-commercial distribution of the ROM firmware from their 1980s home computers, legalising dozens of Spectrum, QL and CPC emulators. They even allow distribution of the original manuals, in facsimile and converted to modern word-processor formats, making the emulators complete and easy to use.Windows 3.11 still costs
If you own any other system you're still entitled to run the code, by emulation if you wish, but getting it from the mask-programmed chip soldered down on the original computer board may be problematic. It's easiest to download a copy that some hacker has already converted into a ZIP file and stuck on a web page. The problem is that not everyone who takes advantage of this service will own the original, or even know if the ROM they download matches the one they own.
Game rights are a minefield. Gameboy and other console titles remain commercially available, although Nintendo's production schedule means that back-catalogue titles are hard to find. A few cartridge images have been specially written to be bundled with emulators, or were otherwise unreleased and have been made freely available. But the classic titles, like Zelda and Sonic, are very much copyright, and even if a cartridge is no longer on sale, someone owns the right to determine who can use it.
The same goes for programs originally on disk or tape. If you own the original you should be within your rights in using a copy of it, however obtained, on an emulator, as long as you don't sell or give away the original or use both at the same time. Some emulator sites justify the 'backups' on their pages this way, although it is not a position that has been tested in court, and the limits on use of such files depend on where they come from as well as where they're used.
Unless you're a lawyer, the arguments are not helped by extreme statements on either side. The US Interactive Digital Software Association flatly claims that emulation is "illegal", while web hosts assert their right to upload anything for 'backup' or 'educational' purposes. Both positions thinly veil political agendas.Word without Windows, nor an x86 ->
Emulation is here to stay, but the legal framework is a mess while courts remain ignorant of computing practice and history. A UK court threw out claims that the Micro Ace ROM infringed the ZX-80 one, not because it was different but because the judge said "I cannot see it." Sinclair eventually won the case because the MicroAce also cloned the bizarre ZX keyboard layout, which even the judge could see was no accident.
Amiga, Amstrad, Gremlin, Palm, Vortex and many smaller firms have cleared up the position regarding the use of their code in emulators. As others follow their lead, emulation should become more fun and less furtive - but, for the time being, be wary when emulating code you don't already own.
Emulators for Java
Just as the supply of 'native' emulators for Linux was beginning to dry up - by the time we'd located about eighty - we realised that 'portable' emulators written in Java would also appeal to Linux users with Netscape or Conqueror browsers. You can run these directly from a web page, or download the Java code for off-line experimentation.
These are in effect double-emulations - the Java virtual machine emulates another system - which makes them relatively inefficient, but even so there are quite a few good ones around. Slow interpretation and limited output may be an issue. Only full Java programs, rather than applets, can save, and then you'll need to set security levels to let them loose on your local drive - but these may not matter if the emulator does what you need at acceptable speed on your system.
Incompatibility between Java systems is more problematic; some may need Microsoft's Bowdlerised version. And as it's easier to start in Java, but more difficult to get something really tight, expect more subset implementations.
Applelet emulates an Apple ][+ with a 16K RAM card and two disk-drives. According to the website each slot (except for the language card) is a Java object, so expansion will be easy ... you'll even be able to plug in stuff while the emulator is running, something you can hardly do with a real Apple!
Minus 4 is also a Java applet, so it cannot offer facilities to save, but it otherwise emulates the Commodore Plus 4 and C16 quite convincingly. A Celeron 500 with Netscape's JRE 1.2 and Red Hat Linux 7.0 had to be slowed down, using a built-in option, to the original 50 Hertz frame rate. If your machine or Java engine is relatively slow you can decrease the frame rate so game logic works at the expected speed but animation is not so smooth. Minus four redirects Unix cursor keys to the emulated joystick.
There's no room to list all the emulators written in Java, let alone their features, but you'll find several for Sinclair and Commodore machines, and Java emulations of the Apple ][ GS, Nintendo GameBoy and NES, Atari ST, Sinclair ZX-81, Tandy TRS-80, MSX, Chip-8 and vintage arcade consoles. Theoreticians may enjoy a couple of Turing machine emulators and even a Babbage tribute Applet Analytical Engine Emulator. These links should get you started:
Emulator files on CDs
The popularity of emulation and mountains of related files washing around on the net has encouraged CD publishers - especially Epic of Swindon - to collect them on CDs. Linux support is typically an afterthought, but these ten could save you spending days on line, trawling for fuel for Unix emulators.
Amiga Forever - Weird Science
The only legal collection of current Amiga programs and system software, this is a very comprehensive CD with history, patents, background information and even synthesised speech - plus Amiga applications, extensions and the latest 'Kickstart 3.1' system ROM images. Presentation is slanted towards Windows PCs; the main emulator is WinUAE, based on the Unix original. License fees make Amiga Forever pricey but this CD is uncommonly well-organised and packed with extras you should not find on the Web. A cheaper, condensed 'Cross-Platform Online Edition' is downloadable from http://www.cloanto.com.
Atari 2600 ClassiX - Epic
This CD contains the Linux port of Stella, which has particularly accurate sound, and the generic Unix/X version, with source code, and 507 games. These are from 2K to 16K in size so this leaves a lot of unused space on the disk - if you can find these on the web it's probably cheaper to download them, as documentation is scant- not even the 2600 FAQ is on the CD.
C64 Sensations - Epic
This collection includes thousands of demos and disk magazines ready to run on C64 emulators, but no games. There are also hundreds of Commodore 64 music files in SID player modular format, system ROMs for VIC and C64 - and oddly for Oric, Apple ][ and CPC micros too. The CD was put together by the maintainers of Commodore library PD Soft, and draws on more than a decade of their work. The bundled emulators all expect to run on Amiga, Mac or MSDOS so you'll need to supplement this CD with Linux executables.
C64 Classix - Epic
This companion to C64 Sensations contains almost all the published C64 games, collected from web and FTP sites over the last few years. It lacks Linux specifics, but is the definitive resource if you're looking for a particular Commodore 64 game, with over 3,000 to choose from and 10,000 SID tunes.
CPC Classix - Epic
This CD contains over a thousand games for Amstrad CPC emulators, along with system ROMs - with Amstrad's blessing - but not a lot else. Documentation and emulators for Linux would have made this more attractive.
Flash ROM 1 - Epic
A rather patchy multi-platform Emulation compilation, with hundreds of programs for MSX, VIC, ZX-81, Dragon and C64 but a dearth of emulators to run on Linux. Oric owners will find this CD most interesting - Euphorix for Unix+X11 and over 100 games, a good history of the machine, illustrations, Lisp and Forth language interpreters, It has two Coleco emulators for Unix (AdamEm and Colem) and over 100 games, and INES for Linux but no Nintendo software.
Flash ROM 2 - Epic
This multi-emulator CD includes large Atari 8 bit, C64, Dragon and ZX-81 software collections, and a fair amount of files for CPC, Coleco, MSX, Oric and VIC nostalgics. It has XCoupe, the 'Super Spectrum' emulator, but a lot of the emulators for Linux and Unix/X on this CD are rather out of date.
MSX Nostalgia - Epic
This CD contains fMSX 1.5 for Unix/X and about 300 MSX programs, but with a lot of duplication so there's only about 20M of unique material - mostly games, plus a few utilities.
Qdos Emulators - Q-Celt
This freely-copyable disk includes QLAY and UQLX emulators for Linux, utilities, original and updated system ROMs, OCRed QL manuals and other documentation, plus over 300 Mb of Qdos software. It's mastered in Eire; email firstname.lastname@example.org if you're curious but don't fancy phoning abroad. Q-Celt also have a Z88 emulation CD, but I'm not aware of any Unix or Linux emulator for that Sinclair portable - yet?!
Retro Gold - Weird Science
This CD holds a mixture of programs for Commodore 64 and ZX Spectrum emulators. Around 3,000 ZX files appear in a couple of common snapshot formats. There's a lot of duplication but the CD includes almost all the well-known Spectrum games (including ten copies of Manic Miner, unhelpfully all saved at the same point) plus graphics, small business and programming tools, adventure writers and a smattering of educational and utility programs. The same CD contains about 1,200 distinct C64 games, but precious little other software for that machine.
Epic Direct: 08700 110015
Q Celt (Eire) 00353 404 45319
Weird Science: 0116 2350045
Most emulators have their own home pages which we'll list as we explore them later in this series. Here are some starting points if you want to know more about Unix emulators in general.
This is the closest we've found to a general Linux Emulator site, but it is still quite incomplete.
You'll find a couple of dozen emulators for Linux here, but often not the latest versions.
This site has a collection of emulators for X11 and Unix
This informative page is by Marat Fayzulin, who's CPU engines power a substantial proportion of Linux emulators.
Marcel de Kogel
Marcel de Kogel has also written more than his fair share of emulators and CPU engines.
(( TABLE )) Games Console and arcade emulators
"Games console emulators are plentiful, but software for them is not so easy to find"
CPU, Emulator - Details
Z80, Boycott - Nintendo GameBoy
Z80, ColEm - ColecoVision
multi, DarcNES - multi-platform
Z80, Daphne - laser disk games
68K, DGen - Sega Megadrive
68K, Generator - Genesis/Megadrive
6502, iNES - Nintendo NES/Famicom
Z80, KCemu - KC 85/4 home micro
Z80, MasterGear - MasterSystem/GameGear
multi, MAME - arcades and consoles
multi, MESS - many home micros
6502, nestra - Nintendo NES compiler
Z80, P2000 - European home micro
V810, Reality Boy - Nintendo 3D portable
SH2, SEMU - Sega Saturn
multi, System16, Sega arcade
65816, snemul - Super Nintendo
65816, snes9x_linux - Super Nintendo
MIPS, SOPE - Sony PlayStation
6502, Stella - Atari 2600
Z80, VGB - Nintendo Game Boy
CHIP8, Vision-8 - TV games
6502, V2600 - Atari VCS
6502, VPCE - PC Engine
6502, x2600 - Atari VCS
68K, XGenEm - Genesis/Megadrive
65816, XNES - Nintendo
Computer emulators for Linux
Five dozen general-purpose computer emulators for Linux
CPU, Emulator - Details
6502, ACE - Atari 8-bit
Z80, AdamEm - Coleco Adam
Z80, Amstrad CPC - Amstrad 8-bit
6502, apple2-emul - Apple ][+ and //e
ARM6, ArcEm, Acorn Archimedes
6502, Atari800 - Atari 400/800/XL/XE
68K, Basilisk II - Macintosh 2
6502, Beeb - Acorn BBC Micro
6502, BeebEm - Acorn BBC Micro
X86, Bochs - 486 IBM PC clone
6502, ComeBack64 - Commodore 64
Z80, CPC - Amstrad CPC
Z80, CPC4X - Amstrad CPC
Z80, cpm - Digital Research CP/M
X86, DOSemu - virtual MSDOS
Z80, Enterprise - Elan Enterprise
6502, Euphorix - Oric and Atmos
68K, Executor - ARDI Apple Mac
6809, flexemu - Motorola FLEX OS
Z80, fmsx - ASCII MSX range
6510, Frodo - Commodore 64
Z80, FunzyTo7 - Thompson TO7
Z80, fuse - Spectrum 48K/128K
Z80, mz700em - Sharp MZ700
Z80, NC100 - Amstrad notebook
6502, Oric 48K - Oric and Atmos
X86, PCEMU - MSDOS MDA PC
X86, PCM - MSDOS VGA PC
6502, Pfau Zen - Commodore VIC-20
68K, POSE, Palm Pilot portable
68008, QLAY - Sinclair QL
Z80, SimCoupe - MGT SAM
X86, SoftWindows, MS Windows
Z80, Spectemu - ZX Spectrum
Z80, Spectrum - French 48K Spectrum
68K, STonX - 16 bit Atari ST and STe
9900, ti4linux - Texas TI-99/4A
68K, UAE - Commodore Amiga
Z80, unnamed - Sinclair Spectrum
68K, UQLX - extended Qdos
6502, vice - 8 bit Commodores
68K, vMac - Classic Macs
Z80, X128 - Spectrum 128
8510, X128 - Commodore 128
HP, X48, Hewlett Packard HP48
6502, X64 - Commodore 64 (x2)
6502, xapple - Apple ][, X86 only
6502, xbeeb - BBC Micro
6510, xc16emu - Commodore C16/C116/+4
6502, XCBM2 - Commodore 610 series
68K, XCoPilot - Palm Pilot portable
Z80, XCoupe - MGT SAM
X86, XDOS - MSDOS and mouse
6502, XPET - Commodore PET
Z80, XTRS - Tandy TRS-80
6502, XVIC - Commodore VIC-20
Z80, XZ80 - Sinclair Spectrum
Z80, XZX - ZX Spectrum 48/128/+3
Z80, XZX2 - Spectrum and compatibles
Z80, yaze - CP/M v2.2 systems
Z80, Z81 - Sinclair ZX80 and ZX81
Z80, zxsp-x, Spectrum 16/48/128K
Links and reviews follow in other parts of this series.