You are invited to Log in or Register a free Frihost Account!

Emulator - A Hardware Based Learning Model


A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.

In computers, an emulator is a hardware device or a program that pretends to be another particular device or program that other components expect to interact with. For example, using a 3270 emulator, a program written to be used with the 3270 workstation can communicate with and control a personal computer as though it were a 3270. Typically, an emulator is provided when a popular hardware device becomes outdated and no longer marketed but legacy applications exist that still need to communicate with the older device. The practice of using an emulator to make an older program work with a new end-use device is called terminal emulation.

What is emulator?

An emulator, in the most general sense, duplicates (provide an emulation of) the functions of one system with a different system, so that the second system appears to behave like the first system. Unlike a simulation, it does not attempt to precisely model the state of the device being emulated; it only attempts to reproduce its behavior.

In practice, it can be quite difficult, particularly when the exact behaviour of the system to be emulated is not documented and has to be deduced through reverse engineering. It also says nothing about timing constraints; if the emulator does not perform as quickly as the original hardware, the emulated software may run much more slowly than it would have on the original hardware.

A common form of emulation is that of a software emulator, a piece of computer software that allows certain computer programs to run on a platform (computer architecture and/or operating system) other than the one they were originally written for. It does this by "emulating", or reproducing, the behavior of one type of computer on another by accepting the same data, executing the same programs, and achieving the same results.

Most emulators just emulate a hardware architecture - if a specific operating system is required for the desired software, it must be provided as well (and may itself be emulated). Both the OS and the software will then be interpreted by the emulator, rather than being run by native hardware. Apart from this interpreter for the emulated machine's language, some other hardware (such as input or output devices) must be provided in virtual form as well: if writing to a specific memory location should influence the screen, for example, this will have to be emulated as well.

Instead of full emulation of the hardware, a compatibility layer may suffice. This translates system calls for the emulated system into system calls for the host system.

A popular use of emulators is to run software and games, often referred to as ROMs, written for hardware that is no longer sold or readily available, such as the Commodore 64 or early Amiga models. Emulating these on modern desktop computers is usually less cumbersome than relying on the original machine, which may be inoperational. However, software licensing issues may require emulator authors to write original software that duplicates the functionality of the original computer's bootstrap ROM and BIOS, often through high-level emulation.

Developers of software for embedded systems or video game consoles often design their software on especially accurate emulator called a simulator before trying it on the real hardware. This is so that software can be produced and tested before the final hardware exists in large quantities, so that it can be tested without taking the time to copy the program to the hardware, or so that it can be debugged at a low level without introducing the side effects of a debugger.


Typically, an emulator is divided into modules that correspond roughly to the emulated computer's subsystems. Most often, an emulator will be composed of the following modules:

a CPU emulator or CPU simulator (the two terms are mostly interchangeable)

a memory subsystem module

various I/O devices emulators

Buses are often not emulated, either for reasons of performance or simplicity, and virtual peripherals communicate directly with the CPU or the memory subsystem.

A detailed description of the internals of a specific emulator can be found in the ElectrEm article.

Memory subsystem

It is possible for the memory subsystem emulation to be reduced to simply an array of elements each sized like an emulated word; however, this model falls very quickly as soon as any location in the computer's logical memory does not match physical memory.

This clearly is the case whenever the emulated hardware allows for advanced memory management (in which case, the MMU logic can be embedded in the memory emulator, made a module of its own, or sometimes integrated into the CPU simulator).

Even if the emulated computer does not feature an MMU, though, there are usually other factors that break the equivalence between logical and physical memory: many (if not most) architecture offer memory-mapped I/O; even those that do not almost invariably have a block of logical memory mapped to ROM, which means that the memory-array module must be discarded if the read-onlyness of ROM is to be emulated.

As a result, most emulators implement at least two procedures for writing to and reading from logical memory, and it is these procedures' duty to map every access to the correct location of the correct object.

CPU simulator

The CPU simulator is often the most complicated part of an emulator. Many emulators are written using "pre-packaged" CPU simulators, in order to concentrate on good and efficient emulation of a specific machine.

The simplest form of a CPU simulator is an interpreter, which follows the execution flow of the emulated program code and, for every machine code instruction encountered, executes operations on the host processor that are semantically equivalent to the original instructions.

This is made possible by assigning a variable to each register and flag of the simulated CPU. The logic of the simulated CPU can then more or less be directly translated into software algorithms, creating a software re-implementation that basically mirrors the original hardware implementation.

Interpreters are very popular as CPU simulators, as they are much simpler to implement than more performant alternative solutions, and their speed is more than adequate for emulating computers of more than roughly a decade ago on modern machines.

However, the speed penalty inherent in interpretation can be a problem when emulating computers whose processor speed is on the same order of magnitude as the host machine. Until not many years ago, emulation in such situations was considered completely inpractical by many.

What allowed breaking through this restriction were the advances in dynamic recompilation techniques. Simple a priori translation of emulated program code into code runnable on the host architecture is usually impossible because of several reasons: code may be self-modifying there may not be a way to reliably distinguish data segments (which must not be translated) from text segments (code segments) there may not be a way to communicate with the emulated operating system in order for the emulator to be aware of newly loaded (for example from disk) code

Various forms of dynamic recompilation, including the popular Just In Time compiler (JIT) technique, try to cicumvent these problems by waiting until the processor control flow jumps into a location containing untranslated code, and only then ("just in time") translates a block of the code into host code that can be executed. The translated code is kept in a code cache, and the original code is not lost or affected; this way, even data segments can be (meaninglessly) translated by the recompiler, resulting in no more than a waste of translation time.


Most emulator do not, as said above, emulate the main system bus; each I/O devices is thus often treated as a special case, and no consistent interface for virtual peripherals is provided.

This can result in a performance advantage, since each I/O module can be fine-taylored to the characteristics of the emulated device; designs based on a standard, unified I/O API can however rival such simpler models, if well-thought, and they have the additional advantage of "automatically" providing a plug-in service through which third-party virtual devices can be used within the emulator.

A unified I/O API may not necessarily mirror the structure of the real hardware bus: bus design is limited by several electric contraints and a need for hardware concurrency management that can mostly be ignored in a software implementation.

Even emulators that treat each device as a special case, there is usually a common basic infrastructure for

managing interrupts, by means of a procedure that sets flags readable by the CPU simplator whenever an interrupt is raised, allowing the virtual CPU to "poll for (virtual) interrupts"

writing to and reading from physical memory, by means of two procedures similar to the ones dealing with logical memory (although, contrary to the latter, the former can often be left out, and direct references to the memory array be employed instead)


Thus, Emulators are computer programs that translate instructions for one type of processor to instructions that your own computer can execute. For example, there are emulators available that understand the instruction sets of video game processors and allow you to play video games on your computer.

Similarly, there are emulators which can simulate your calculator. Emulators are advantageous because they can run much faster than the original processor (in this case, your calculator) and they allow you to view detailed information about the code that's being executed, which is especially helpful for programmers. To get started, first download a ROM image from your calculator. Then find an emulator for your calculator and operating system.
looks like copy-paste to me

atleast the last part of the "article" was pasted from

this kinda shit will only get u banned...
Related topics
Minimum hardware requirements for mp3
What do you think about Mac OS X?
Projects VS Exams
parent control software
Simple(?) probability question
the internet and learning
Making Dance Music ?
Free firewalls better than paid ones??!!
Any Good Online University?
Games in linux!
Is there a cosmologist in the house?
Best Firewall
Norton Internet Security vs. AVG
Something wrong in my PC
Reply to topic    Frihost Forum Index -> Computers -> Software

© 2005-2011 Frihost, forums powered by phpBB.