Emulator: Wikis

Advertisements
  
  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Did you know ...


More interesting facts on Emulator

Include this on your site/blog:

Encyclopedia

Advertisements

From Wikipedia, the free encyclopedia

DOSBox emulates the familiar command-line interface of DOS.

An emulator in computer sciences duplicates (provides an emulation of) the functions of one system using a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to some other forms of computer simulation, which can concern an abstract model of the system being simulated.

Contents

Emulators in computer science

Basilisk II emulates a Macintosh 68k using interpretation code and dynamic recompilation.

Emulation refers to the ability of a computer program or electronic device to imitate another program or device. Many printers, for example, are designed to emulate Hewlett-Packard LaserJet printers because so much software is written for HP printers. By emulating an HP printer, a printer can work with any software written for a real HP printer. Emulation "tricks" the running software into believing that a device is really some other device.

A hardware emulator is an emulator which takes the form of a hardware device. Examples includes the DOS-compatible card installed in some old-world Macintoshes like Centris 610 or Performa 630 that allowed them to run PC programs and FPGA-based hardware emulators.

In a theoretical sense, the Church-Turing thesis implies that any operating environment can be emulated within any other. However, in practice, it can be quite difficult, particularly when the exact behavior 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, possibly triggering time interrupts to alter performance.

Emulation in preservation

Emulation is a strategy in digital preservation to combat obsolescence. Emulation focuses on recreating an original computer environment, which can be time-consuming and difficult to achieve, but valuable because of its ability to maintain a closer connection to the authenticity of the digital object.[1]

Emulation addresses the original hardware and software environment of the digital object, and recreates it on a current machine.[2] The emulator allows the user to have access to any kind of application or operating system on a current platform, while the software thinks it is in its original environment.[3] Jeffery Rothenberg, an early proponent of emulation as a digital preservation strategy states, “the ideal approach would provide a single extensible, long-term solution that can be designed once and for all and applied uniformly, automatically, and in synchrony (for example, at every refresh cycle) to all types of documents and media”.[4] He further states that this should not only apply to out of date systems, but also be upwardly mobile to future unknown systems.[5] Practically speaking, when a certain application is released in a new version, rather than address compatibility issues and migration for every digital object created in the previous version of that application, one could create an emulator for the application, allowing access to all of said digital objects.

Benefits

  • Emulators maintain the original look, feel, and behavior of the digital object, which is just as important as the digital data itself.[6]
  • Despite the original cost of developing an emulator, it may prove to be the more cost efficient solution over time.[7]
  • Reduces labor hours, because rather than continuing an ongoing task of continual data migration for every digital object, once the library of past and present operating systems and application software is established in an emulator, these same technologies are used for every document using those platforms.[3]
  • Many emulators have already been developed and released under GNU General Public License through the open source environment, allowing for wide scale collaboration.[8]

Obstacles

  • Intellectual property - Many technology vendors implemented non-standard features during program development in order to establish their niche in the market, while simultaneously applying ongoing upgrades to remain competitive. While this may have advanced the technology industry and increased vendor’s market share, it has left users lost in a preservation nightmare with little supporting documentation due to the proprietary nature of the hardware and software.[9]
  • Copyright laws are not yet in effect to address saving the documentation and specifications of proprietary software and hardware in an emulator module.[10]

Emulators in new media art

Because of its primary use of digital formats, new media art relies heavily on emulation as a preservation strategy. Artists such as Cory Arcangel specialize in resurrecting obsolete technologies in their artwork and recognize the importance of a decentralized and deinstitutionalized process for the preservation of digital culture.

In many cases, the goal of emulation in new media art is to preserve a digital medium so that it can be saved indefinitely and reproduced without error, so that there is no reliance on hardware that ages and becomes obsolete. The paradox is that the emulation and the emulator have to be made to work on future computers.[11]

Types of emulators

Windows XP running an Acorn Archimedes emulator, which is in turn running a Sinclair ZX Spectrum emulator.

Most emulators just emulate a hardware architecture — if operating system firmware or software 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 binary machine's language, some other hardware (such as input or output devices) must be provided in virtual form as well; for example, if writing to a specific memory location should influence what is displayed on the screen, then this would need to be emulated.

While emulation could, if taken to the extreme, go down to the atomic level, basing its output on a simulation of the actual circuitry from a virtual power source, this would be a highly unusual solution. Emulators typically stop at a simulation of the documented hardware specifications and digital logic. Sufficient emulation of some hardware platforms requires extreme accuracy, down to the level of individual clock cycles, undocumented features, unpredictable analog elements, and implementation bugs. This is particularly the case with classic home computers such as the Commodore 64, whose software often depends on highly sophisticated low-level programming tricks invented by game programmers and the demoscene.

In contrast, some other platforms have had very little use of direct hardware addressing. In these cases, a simple compatibility layer may suffice. This translates system calls for the emulated system into system calls for the host system e.g., the Linux compatibility layer used on *BSD to run closed source Linux native software on FreeBSD, NetBSD and OpenBSD.

Developers of software for embedded systems or video game consoles often design their software on especially accurate emulators called simulators 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 be debugged at a low level and without introducing the side effects of a debugger. In many cases, the simulator is actually produced by the company providing the hardware, which theoretically increases its accuracy.

Math coprocessor emulators allow to run programs compiled with math instruction support on machines that haven't the math coprocessor installed, but making the program and the system be slow. e.g. the Linux i386 emulator that can be compiled on the kernel, or some MS-DOS compilers like Turbo C and DJGPP that includes math emulator compiled on the program. Currently the math emulator isn't necessary, because all current computers have math instruction support. The method of emulate the coprocessor is the following: If the math coprocessor isn't installed on the computer or on the CPU, when the CPU executes any coprocessor instruction it will make a determinated interrupt (coprocessor not available), calling the math emulator routines. When the instruction is successfully emulated, the program continues executing.

Structure of an emulator

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 in this case)
  • 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.

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-only nature of ROM is to be emulated. Features such as bank switching or segmentation may also complicate memory emulation.

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.

On a base-limit addressing system where memory from address 0 to address ROMSIZE-1 is read-only memory, while the rest is RAM, something along the line of the following procedures would be typical:

void WriteMemory(word Address, word Value) {
    word RealAddress;
    RealAddress = Address + BaseRegister;
    if ((RealAddress < LimitRegister) &&
        (RealAddress > ROMSIZE)) {
        Memory[RealAddress] = Value;
    } else {
        RaiseInterrupt(INT_SEGFAULT);
    }
}
word ReadMemory(word Address) {
    word RealAddress;
    RealAddress=Address+BaseRegister;
    if (RealAddress < LimitRegister) {
        return Memory[RealAddress];
    } else {
        RaiseInterrupt(INT_SEGFAULT);
        return NULL;
    }
}

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.

The following example illustrates how CPU simulation can be accomplished by an interpreter. In this case, interrupts are checked-for before every instruction executed, though this behavior is rare in real emulators for performance reasons.

void Execute(void) {
    if (Interrupt != INT_NONE) {
        SuperUser = TRUE;
        WriteMemory(++StackPointer, ProgramCounter);
        ProgramCounter = InterruptPointer;
    }
    switch (ReadMemory(ProgramCounter++)) {
        /*
         * Handling of every valid instruction
         * goes here...
         */
        default:
        Interrupt = INT_ILLEGAL;
    }
}

Interpreters are very popular as computer simulators, as they are much simpler to implement than more time-efficient 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 impractical 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 modified while in RAM, even if it is modified only by the emulated operating system when loading the code (for example from disk)
  • there may not be a way to reliably distinguish data (which should not be translated) from executable code.

Various forms of dynamic recompilation, including the popular Just In Time compiler (JIT) technique, try to circumvent 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.

Speed may not be desirable as some older games were not designed with the speed of faster computers in mind. A game designed for a 30 MHz PC with a level timer of 300 game seconds might only give the player 30 seconds on a 300 MHz PC. Other programs, such as some DOS programs, may not even run on faster computers. Particularly when emulating computers which were "closed-box", in which changes to the core of the system were not typical, software may use techniques that depend on specific characteristics of the computer it ran on (i.e. its CPU's speed) and thus precise control of the speed of emulation is important for such applications to be properly emulated.

I/O

Most emulators do not, as mentioned earlier, emulate the main system bus; each I/O device 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 tailored 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-out, 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 constraints and a need for hardware concurrency management that can mostly be ignored in a software implementation.

Even in 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 simulator 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)

Emulation versus simulation

The word "emulator" was coined in 1957 at IBM, as an optional feature in the IBM 709 to execute legacy IBM 704 programs on the IBM 709. Registers and most 704 instructions were emulated in 709 hardware. Complex 704 instructions such as floating point trap and input-output routines were emulated in 709 software. In 1963, IBM constructed emulators for development of the NPL (360) product line, for the "new combination of software, microcode, and hardware"[12].

It has recently become common to use the word "emulate" in the context of software. However, before 1980, "emulation" referred only to hardware emulation, while "simulation" referred to software emulation[13]. For example, a computer especially built for running programs designed for another architecture is an emulator. In contrast, a simulator could be a program which runs on a PC, so that old Atari games can be run on it. Purists continue to insist on this distinction, but currently the term "emulation" often means the complete imitation of a machine executing binary code.

Logic simulators

Logic simulation is the use of a computer program to simulate the operation of a digital circuit such as a processor. This is done after a digital circuit has been designed in logic equations, but before the circuit is fabricated in hardware.

Functional simulators

Functional simulation is the use of a computer program to simulate the execution of a second computer program written in symbolic assembly language or compiler language, rather than in binary machine code. Programmers can trace selected sections of code to search for programming errors (bugs). This is distinct from simulating execution of binary code, which is software emulation.

The first functional simulator was written by Autonetics about 1960 for testing assembly language programs for later execution in military computer D-17B. This was so that flight programs could be written, executed, and tested before D-17B computer hardware had been built. Autonetics also programmed a functional simulator for testing flight programs for later execution in the military computer D-37C.

Console emulators

Console emulators are programs that allow a computer or modern console to emulate a video game console. They are most often used to play older video games on personal computers and modern video game consoles, but they are also used to translate games into other languages, to modify existing games, and in the development process of homebrewed demos and new games for older systems.

Terminal emulators

Terminal emulators are software programs that provide modern computers and devices interactive access to applications running on mainframe computer operating systems or other host systems such as HP-UX or OpenVMS. Terminals such as the IBM 3270 or VT100 and many others, are no longer produced as physical devices. Instead, software running on modern operating systems simulates a "dumb" terminal and is able to render the graphical and text elements of the host application, send keystrokes and process commands using the appropriate terminal protocol. Some terminal emulation applications include Attachmate Reflection, IBM Personal Communications, Stromasys CHARON-VAX/AXP and Micro Focus Rumba.

Legal controversy

See article Console emulator — Legal issues

See also

  • Antenna emulator

References

  1. ^ "What is emulation?". Koninklijke Bibliotheek. http://www.kb.nl/hrd/dd/dd_projecten/projecten_emulatiewatis-en.html. Retrieved 2007-12-11. 
  2. ^ van der Hoeven, Jeffrey, Bram Lohman, and Remco Verdegem. “Emulation for Digital Preservation in Practice: The Results.” The International Journal of Digital Curation 2.2 (2007): 123-132.
  3. ^ a b Muira, Gregory. “ Pushing the Boundaries of Traditional Heritage Policy: maintaining long-term access to multimedia content.” IFLA Journal 33 (2007): 323-326.
  4. ^ Rothenberg, Jeffrey (1998). "“Criteria for an Ideal Solution.” Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation.". Council on Library and Information Resources. Washington, DC. http://www.clir.org/pubs/reports/rothenberg/contents.html. 
  5. ^ Rothenberg, Jeffrey. “The Emulation Solution.” Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation. Washington, DC: Council on Library and Information Resources, 1998. Council on Library and Information Resources. 2008. 28 Mar. 2008 http://www.clir.org/pubs/reports/rothenberg/contents.html
  6. ^ Muira, Gregory. “ Pushing the Boundaries of Traditional Heritage Policy: maintaining long-term access to multimedia content.” IFLA Journal 33 (2007): 323-326.
  7. ^ Granger, Stewart. Digital Preservation & Emulation: from theory to practice. Proc. of the ichim01 Meeting, vol. 2, 3 -7 Sept. 2001. Milano, Italy. Toronto: Archives and Museum Informatics, University of Toronto, 2001. 28 Mar. 2008 http://www.leeds.ac.uk/cedars/pubconf/papers/ichim01SG.html
  8. ^ van der Hoeven, Jeffrey, Bram Lohman, and Remco Verdegem. “Emulation for Digital Preservation in Practice: The Results.” The International Journal of Digital Curation 2.2 (2007): 123-132.
  9. ^ Granger, Stewart. “Emulation as a Digital Preservation Strategy.” D-Lib Magazine 6.19 (2000). 29 Mar 2008 http://www.dlib.org/dlib/october00/granger/10granger.html
  10. ^ Rothenberg, Jeffrey. “The Emulation Solution.” Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation. Washington, DC: Council on Library and Information Resources, 1998. Council on Library and Information Resources. 2008. 28 Mar. 2008
  11. ^ "Echoes of Art: Emulation as preservation strategy". http://www.variablemedia.net/e/echoes/index.html. Retrieved 2007-12-11. 
  12. ^ Pugh, Emerson W.; et al. (1991). IBM's 360 and Early 370 Systems. MIT. ISBN 0-262-16123-0.  pages 160-161
  13. ^ S. G. Tucker, "Emulation of Large Systems", Communications of the ACM (CACM) Vol. 8, No. 12, Dec. 1965, pp. 753-761

External links


Strategy wiki

Up to date as of January 23, 2010
(Redirected to Category:Emulators article)

From StrategyWiki, the free strategy guide and walkthrough wiki

Note: This category is not intended to catalog every emulator in existence, only those emulators which stand out and which people wish to write about and support on StrategyWiki. For the links to known emulators and headlines about new emulators, please visit Emulation 9. (Please be aware that while Emulation 9 is a Japanese page, it is entirely navigatable by an English speaker.)

Definition

From the point of view of games, an emulator is a piece of software that makes it possible for a game (or other program) to run on a different platform than the the one for which it was written. The emulator aims to make the program behave in exactly the same way on the new platform as it would have on the original one. Two main types of emulator are relevant to games: processor emulators and operating system emulators.

A processor emulator aims to work round the fact that different processors, especially if they are of different generations, have different machine languages and therefore a program produced for one processor is unintelligible to another. The processor emulator reads the instructions that were produced for processor A and translates them into processor B's machine language "on the fly". It also has to do some translation in the other direction, for example by translating processor B's interrupts (event signals) and presenting them to the program in the format used by processor A.

The most prominent processor emulator among emulation fans is MAME, which allows you to play on your personal computer many programs that were written specifically for arcade machines. Besides arcade games, emulators have been written for a variety of home console systems (such as the NES, Super Nintendo, and Sega Genesis), and a great number of earlier home computer systems (such as the Atari 800, C64, and Sinclair ZX Spectrum.)

An operating system emulator aims to work round the fact that that different operating systems have different APIs (application programming interfaces, i.e. conventions for requesting services from the operating system, such as allocating memory, drawing on the screen and detecting keyboard, mouse and joystick actions), incompatibilities that would otherwise be crippling even though the processor can handle the program's machine language. One of the best-known operating system emulators is DOSBox, which makes it possible to run most MS-DOS games on 32-bit Windows systems and on Mac OS and Linux.

Both types of emulation use much more processor power and memory than the games would have required on their original platforms, but they perform well enough because modern computers are vastly more powerful than those for which the games were written.

The word "emulator" has other computer-related meanings outside the context of games, but they are in fact very similar. Large computers sometimes have the ability to mimic the functioning of other computers, either to facilitate upgrades from one range to a successor produced by the same manufacturer or to entice another manufacturer's customers to switch. In fact these days computer power is so cheap that the controllers built into peripherals sometimes have emulation facilities, for example many printers are designed to emulate Hewlett-Packard LaserJet printers so their users can take advantage of the large amount of software written for HP printers.

Subcategories

This category has the following 3 subcategories, out of 3 total.

M

R

S

Pages in category "Emulators"

The following 3 pages are in this category, out of 3 total.

D

M


Gaming

Up to date as of January 31, 2010

From Wikia Gaming, your source for walkthroughs, games, guides, and more!

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.

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.

Contents

Legality of emulators

Most emulators are perfectly legal under United States and international law, protected by laws that cover reverse engineering. However, emulators can be illegal if they use copyrighted code from the original console, computer, or program.

Legality of ROM images

ROM images are copyrighted code and are protected by international law. The only legal images are homebrew games created by programmers, images released into public domain, or images downloaded with the permission of the copyright holder.

Common legality myths

  • 24-hour rule: Many emulation download sites like to claim that you can keep unlawfully downloaded ROMs for 24 hours and then delete them, and still "stay legal". This rule has no basis in real law.
  • Owning the game: Owning the game in its original form does not make downloading a ROM image of it legal, according to the letter of the law. The only fully legal way is to make a backup image yourself using special hardware. But this hardware can be expensive, and many gamers consider it ethically correct to download an image as long as you own the original game.

Console Emulators

Arcade

PlayStation

SNES

  • ZSNES
  • Snes9x

NES

  • NESticle
  • VirtuaNES
  • NEStopia
  • JNES

Handheld Emulators

See also

  • Reverse engineering
  • High-level emulation
  • ROM image
Stub
This article is a stub. You can help by adding to it.

Stubs are articles that writers have begun work on, but are not yet complete enough to be considered finished articles.


This article uses material from the "Emulator" article on the Gaming wiki at Wikia and is licensed under the Creative Commons Attribution-Share Alike License.

Simple English

Emulators are things that make one kind of computer behave like a different one, so that it can use the same programs or do the same things. They are best for using old software and games on newer computers. They can be hardware that you add to the computer, or software that you use on it. Some types of emulators require newer computers that have the right system requirements. For example, you need a processor that is fast enough to meet the demands of the emulator. Memory (both RAM and hard drive space) may be another factor to help it run smoothly and more accurately. With the more advanced emulators, if your computer is too old, the emulator or even the operating system may crash[needs proof].


Advertisements






Got something to say? Make a comment.
Your name
Your email address
Message