History MediaNotes / Emulation

In order to play games, emulators require the game software as well. These usually come in the form of [[UsefulNotes/ReadOnlyMemory ROM]]s (for cartridge-based games) and various disc image formats (for disc-based games). Publicly distributing [=ROM=] dumps (pirating copyrighted games) without permission is generally considered illegal, with possible, nebulous, and debatable exceptions for "fair use" in some cases. The veracity (and legal validity) of these beliefs have yet to be formally ruled on in either direction; and thus, talk about emulation (especially talk about [[UsefulNotes/ReadOnlyMemory ROM]]s themselves) is generally a [[FlameBait very dangerous subject on Internet fora]], such as the Website/{{GameFAQs}} fora and others, which may auto-delete posts that direct other users towards emulation sites, possibly even if they don't link to games themselves, partly due to legal reasons. Morality issues are even grayer, so it's probably best not talk about it, lest you start up rampant {{Flame War}}s, or worse yet, philosophy students bandying about terms such as "utilitarianism" or the dreaded "Kant's Categorical Imperative." There's really no reason to share such information anyway, since most web searches can provide it handily.

* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, the emulator intercepts the instructions the game sends to what it thinks is a GPU and translates it to a MediaNotes/GraphicsAPI that the host computer can run. This started becoming popular during the MediaNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a Platform/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a Platform/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of MediaNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity making it impractical to simulate the hardware directly

The most popular computers to emulate are UsefulNotes/{{Arcade Game}}s and games consoles, although emulators for other systems do exist. Most emulators are written by fans/enthusiasts, as a technical challenge, as a way of storing computing history (Platform/{{MAME}} and Platform/{{MESS}} have this as their primary goal), or as a way to run games on something other than what they were written for in the first place. A few emulators are written by the official manufacturers, such as Creator/{{Nintendo}}'s acNES for GBA (used for the eReader, Platform/GameBoyAdvance extras in ''VideoGame/AnimalCrossing'', and Classic NES Series) and the emulators used for Platform/VirtualConsole titles.

* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, the emulator intercepts the instructions the game sends to what it thinks is a GPU and translates it to a UsefulNotes/GraphicsAPI that the host computer can run. This started becoming popular during the MediaNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a Platform/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a Platform/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of MediaNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity making it impractical to simulate the hardware directly
* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. Or another way of putting it, these emulate just the software portions of a computer system. Compatibility layers take advantage of applications that make ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux by substituting Windows-based system calls for Linux based ones, while returning any data the application is expecting as it would get in Windows. Another one is partly how Platform/Xbox360 compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls that the 360 game makes can be mapped to something that the Xbox One can handle, to the point where the 360 game thinks that it's running on the 360's OS.

* Platform/{{MAME}} (UsefulNotes/{{Arcade Game}}s)

* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. Or another way of putting it, these emulate just the software portions of a computer system. Compatibility layers take advantage of applications that make ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux by intercepting Windows-based system calls for Linux based ones, while returning any data the application is expecting as it would get in Windows. Another one is partly how Platform/Xbox360 compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls that the 360 game makes can be mapped to something that the Xbox One can handle, to the point where the 360 game thinks that it's running on the 360's OS.

Emulation is using a computer program to simulate the function of another computer. Such a program is called an emulator.

* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. This takes advantage of software that makes ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux. Another one is partly how Platform/Xbox360 compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls that the 360 game makes can be mapped to something that the Xbox One can handle, to the point where the 360 game thinks that it's running on the 360's OS.

* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. This takes advantage of software that makes ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux. Another one is partly how {{Platform/Xbox360}} compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls that the 360 game makes can be mapped to something that the Xbox One can handle, to the point where the 360 game thinks that it's running on the 360's OS.

* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, the emulator intercepts the instructions the game sends to what it thinks is a GPU and translates it to a UsefulNotes/GraphicsAPI that the host computer can run. This started becoming popular during the UsefulNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a Platform/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a Platform/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of UsefulNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity making it impractical to simulate the hardware directly

* '''Low-level emulation (LLE)''' seeks to simulate the original hardware. They simulate the inner workings of the console or computer, sometimes even gate-by-gate or down to the last processor cycle. Higan is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the original input clock speed of the SNES at ~21-24 [=MHz=] where most other emulators sync at a much slower rate. This synchronization rate allows games with programming tricks (such as messing with the PPU while it's drawing something on the screen) or odd timing bugs to actually work.

[[caption-width-right:350:[=NESticle=], one of the first and most influential video game emulators of all time, running the 1984 UsefulNotes/NintendoEntertainmentSystem game ''VideoGame/BalloonFight'' on Windows 95[[note]]if you ''really'' wanna get technical, it's a 2012-era Mac virtualizing an older PC, running an emulated version of Windows 95 to run [=NESticle=] to emulate ''Balloon Fight''[[/note]].]]

Not surprisingly, emulation does take more processing power than the original, varying wildly depending on how similar the original platform and the one running the emulator are. For example, 80x86 emulators like UsefulNotes/DOSBox run at nearly native speed on typical 80x86 [=PCs=], while emulators for exotic architectures like [[UsefulNotes/PlayStation2 PCSX2]] and [[UsefulNotes/PlayStation3 RPCS3]] will drag all but the mightiest multicore 80x86 rig to its knees.

The most popular computers to emulate are UsefulNotes/{{Arcade Game}}s and games consoles, although emulators for other systems do exist. Most emulators are written by fans/enthusiasts, as a technical challenge, as a way of storing computing history (UsefulNotes/{{MAME}} and UsefulNotes/{{MESS}} have this as their primary goal), or as a way to run games on something other than what they were written for in the first place. A few emulators are written by the official manufacturers, such as Creator/{{Nintendo}}'s acNES for GBA (used for the eReader, UsefulNotes/GameBoyAdvance extras in ''VideoGame/AnimalCrossing'', and Classic NES Series) and the emulators used for UsefulNotes/VirtualConsole titles.

Emulation services such as Nintendo's UsefulNotes/VirtualConsole and Time-Warner's [=GameTap=] are an attempt to replace illegal emulation by offering something similar legally: Cheap versions of classic games that you can download directly to your system. Nintendo has even called the Virtual Console “iTunes for video games,” referring to Apple's attempts to reduce Internet music piracy with the use of a similarly functioning but legal substitute. On the fans' side, UsefulNotes/ZXSpectrum fans at the [[http://www.worldofspectrum.org World Of Spectrum]] have gone all out to ask the original producers of the games for permission to [[{{Abandonware}} distribute them freely]], which has been granted in the majority of cases, the exceptions mostly being games published by companies that still exist and fear that they would compromise the integrity of their current catalogues by allowing free download of something that ceased to be profitable to them in 1993.

* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, the emulator intercepts the instructions the game sends to what it thinks is a GPU and translates it to a UsefulNotes/GraphicsAPI that the host computer can run. This started becoming popular during the UsefulNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a UsefulNotes/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a UsefulNotes/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of UsefulNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity making it impractical to simulate the hardware directly
* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. This takes advantage of software that makes ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux. Another one is partly how {{UsefulNotes/Xbox360}} compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls that the 360 game makes can be mapped to something that the Xbox One can handle, to the point where the 360 game thinks that it's running on the 360's OS.

The choice between high or low-level emulation has led to some arguments from casual players and purists, the former arguing that [=HLEs=] could be developed faster and often could potentially run better on lower-end hardware or can run games better than the original hardware (e.g., the {{UsefulNotes/GameCube}}/{{UsefulNotes/Wii}} emulator Dolphin can play games at HD resolutions just fine even though the original consoles can't). So long as popular titles can be played, HLE is enough. LLE proponents argue for preservation and conservation of what can now be seen as a cultural legacy-- as [=HLEs=] don't provide an accurate reference on the inner workings of a device, it therefore is unsuitable for purposes of recreating and/or documenting vintage hardware. They also argue that while HLE is easier to get start running, time spent on LLE pays itself better in the long run. In practice most modern emulators use some combination of both approaches. Typically the CPU portion is LLE while everything else is HLE.

* UsefulNotes/DOSBox (MS-DOS)
* UsefulNotes/{{MAME}} (UsefulNotes/{{Arcade Game}}s)
* UsefulNotes/{{MESS}} (Various consoles and computers)

-->--Introduction to the Hercules IBM mainframe emulator

Nevertheless, the lure of [[RetroGaming classic games]] is too much for many gamers to resist, especially for [[{{Abandonware}} games that are long out of print]], [[NoExportForYou were never sold in one's part of the world]], were never (or were [[BlindIdiotTranslation poorly]]) [[FanTranslation translated]], or do not exist in a portable format. In addition, emulators tend to add lots of comfort features such as state freezing, upscaling, control remapping, cheats, etc., and also allow gamers to study, [[GameMod modify]], and [[SpeedRun find interesting things to do with]] these games.

* '''Compatibility Layers''' are an even higher form of emulation, although it's generally not considered emulation as they don't typically simulate another hardware platform. This takes advantage of software that makes ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux. Another one is partly how {{UsefulNotes/Xbox360}} compatibility works. While there's still some re-translation of Xbox 360 code to the Xbox One, system calls the 360 game makes can be mapped to something the Xbox One can handle to the point where the 360 game thinks it's running on the 360's OS.

Emulators are also a popular way to make a port or UpdatedRerelease on sufficiently powerful hardware, especially given that making a native port can be far more difficult for a variety of reasons. Many older games were coded using assembly language or other platform-specific tools, meaning that porting them to run natively on other systems would essentially require rewriting them from scratch. The source code for some games--even big ones--is outright lost (either due to misplacement, uncontrollable damage, human error, or just plain throwing it out due to it not being seen as practical to keep) further makes emulation a favorable method of porting, provided that the emulator itself can faithfully run the game(s) in question[[note]]to give an idea of how much work it takes to make a good-quality native port without using source code, it took several years for a downright massive team of fans to port ''VideoGame/SuperMario64'' to PC-- most of that time was spent decompiling the game's files into something that could be converted to C code (the high-profile leak of part of the game's actual source code only occurred after the port was already complete), and it was considered an ''easy'' project to take on given that it didn't use any particularly fancy compilation techniques; taking that long to port even an old game to a current console risks releasing the port once the target system is already obsolete, given that most consoles are only relevant for a handful of years, and when factoring in the likely greater time needed to decompile a more complexly put-together game, the risk only increases[[/note]]. This can be done officially, or sometimes unofficially in the case of [[GameMod ROM hacks]] that expand a game beyond the original size of its cartridge, for example. Emulation can also make {{Compilation Rerelease}}s or services like Virtual Console easier to implement, as it means only having to create one piece of new software instead of porting each game individually.

Emulation services such as Nintendo's UsefulNotes/VirtualConsole and Time-Warner's [=GameTap=] are an attempt to replace illegal emulation by offering something similar legally: Cheap versions of classic games that you can download directly to your system. Nintendo has even called the Virtual Console “iTunes for video games,” referring to Apple's attempts to reduce Internet music piracy with the use of a similarly functioning but legal substitute. On the fans' side, UsefulNotes/ZXSpectrum fans at the [[http://www.worldofspectrum.org World Of Spectrum]] have gone all out to ask the original producers of the [[{{Abandonware}} games]] for permission to distribute them freely, which has been granted in the majority of cases, the exceptions mostly being games published by companies that still exist and fear that they would compromise the integrity of their current catalogues by allowing free download of something that ceased to be profitable to them in 1993.

* '''Low-level emulation (LLE)''' seeks to simulate the original hardware. They simulate the inner workings of the console or computer, sometimes even gate-by-gate or down to the last processor cycle. Higan is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the original input clock speed of the SNES at ~21-24 [=MHz=] where most other emulators sync at a much slower rate. This synchronization rate allows games with programming tricks (such as messing with the PPU while its drawing something on the screen) or odd timing bugs to actually work.

Emulation services such as Nintendo's UsefulNotes/VirtualConsole and Time-Warner's [=GameTap=] are an attempt to replace illegal emulation by offering something similar legally: Cheap versions of classic games that you can download directly to your system. Nintendo has even called the Virtual Console “iTunes for video games,” referring to Apple's attempts to reduce Internet music piracy with the use of a similarly functioning but legal substitute. On the fans' side, UsefulNotes/ZXSpectrum fans at the [[http://www.worldofspectrum.org World Of Spectrum]] have gone all out to ask the original producers of the {{Abandonware|games}} for permission to distribute them freely, which has been granted in the majority of cases, the exceptions mostly being games published by companies that still exist and fear that they would compromise the integrity of their current catalogues by allowing free download of something that ceased to be profitable to them in 1993.

Emulation services such as Nintendo's UsefulNotes/VirtualConsole and Time-Warner's [=GameTap=] are an attempt to replace illegal emulation by offering something similar legally: Cheap versions of classic games that you can download directly to your system. Nintendo has even called the Virtual Console “iTunes for video games,” referring to Apple's attempts to reduce Internet music piracy with the use of a similarly functioning but legal substitute. On the fans' side, UsefulNotes/ZXSpectrum fans at the [[http://www.worldofspectrum.org World Of Spectrum]] have gone all out to ask the original producers of the {{Abandonware games}} for permission to distribute them freely, which has been granted in the majority of cases, the exceptions mostly being games published by companies that still exist and fear that they would compromise the integrity of their current catalogues by allowing free download of something that ceased to be profitable to them in 1993.

Emulation services such as Nintendo's UsefulNotes/VirtualConsole and Time-Warner's [=GameTap=] are an attempt to replace illegal emulation by offering something similar legally: Cheap versions of classic games that you can download directly to your system. Nintendo has even called the Virtual Console “iTunes for video games,” referring to Apple's attempts to reduce Internet music piracy with the use of a similarly functioning but legal substitute. On the fans' side, UsefulNotes/ZXSpectrum fans at the [[http://www.worldofspectrum.org World Of Spectrum]] has gone all out to ask the original producers of the games for permission to distribute them freely ({{Abandonware}}), and permission which has been granted in the majority of cases, the exceptions mostly being games published by companies that still exist who fear that they compromise the integrity of their current catalogues by allowing free download of something that ceased to be profitable to them in 1993.

In terms of accuracy or faithfulness to the system being emulated, emulators can generally be classified into two major types:
* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, the emulator intercepts the instructions the game sends to a "GPU" and translates it to a UsefulNotes/GraphicsAPI that the host computer can run. This started becoming popular during the UsefulNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a UsefulNotes/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a UsefulNotes/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of UsefulNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity.
** An even higher form of emulation, although it's generally not considered emulation, is the '''Compatibility Layer'''. This takes advantage of software that makes ''system calls'' to an OS or firmware to perform some functionality (such as "get inputs from a controller"). Since the signature of these system calls can be known, the compatibility layer looks to see if the signature is trying to be executed, replacing it with a native system call. A famous example is {{UsefulNotes/WINE}}, which allows Windows applications to run on Linux. Another one is Apple's Rosetta 2, which blurs the line a little between compatibility layer and an emulator as it allows [=x86=]-based [=macOS=] apps to run on ARM-based [=macOS=] computers.
* '''Low-level emulation (LLE)''' seeks to simulate the original hardware more faithfully instead of trying to emulate its features. They simulate the inner workings of the console or computer, sometimes even gate-by-gate or down to the last processor cycle. Higan, formerly known as bsnes, is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the original input clock speed of the SNES at ~21-24 [=MHz=] where most other emulators sync at a much slower rate. This synchronization rate allows games with programming tricks (such as messing with the PPU while its drawing something on the screen) or odd bugs (mostly timing related issues) to actually work.

* '''High-level emulation (HLE)''' implements the system's features rather than the hardware itself. For example, rather than emulate a UsefulNotes/GraphicsProcessingUnit of a console, intercept the instructions the game sends out to it and translate it to a UsefulNotes/GraphicsAPI that the host computer can run. This started becoming popular during the UsefulNotes/TheFifthGenerationOfConsoleVideoGames, made famous by [[https://en.wikipedia.org/wiki/Bleem! Bleem!]], a UsefulNotes/PlayStation emulator, and [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a UsefulNotes/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time. Used almost exclusively by emulators of UsefulNotes/TheFifthGenerationOfConsoleVideoGames and after due to increasing hardware complexity.
* '''Low-level emulation (LLE)''' seeks to simulate the original hardware more faithfully instead of trying to emulate its features. They simulate the inner workings of the console or computer, sometimes even gate-by-gate or down to the last processor cycle. Higan, formerly known as bsnes, is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the original input clock speed of the SNES at ~21-24 MHz where most other emulators sync at a much slower rate. This synchronization rate allows games with programming tricks (such as messing with the PPU while its drawing something on the screen) or odd bugs (mostly timing related issues) to actually work.

* '''Low-level emulation (LLE)''' seeks to simulate the original hardware more faithfully instead of trying to emulate its features. They simulate the inner workings of the console or computer, sometimes [[UpToEleven even gate-by-gate]] or down to the last processor cycle. Higan, formerly known as bsnes, is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the original input clock speed of the SNES at ~21-24 MHz where most other emulators sync at a much slower rate. This synchronization rate allows games with programming tricks (such as messing with the PPU while its drawing something on the screen) or odd bugs (mostly timing related issues) to actually work.

Emulators are also a popular way to make a port or UpdatedRerelease on sufficiently powerful hardware, especially given that making a native port can be far more difficult for a variety of reasons. Many older games were coded using assembly language or other hardware-specific tools, meaning that porting them to run natively on other systems would essentially require rewriting them from scratch. The source code for some games--even big ones--is outright lost (either due to misplacement, uncontrollable damage, human error, or just plain throwing it out due to it not being seen as practical to keep) further makes emulation a favorable method of porting, provided that the emulator itself can faithfully run the game(s) in question[[note]]to give an idea of how much work it takes to make a good-quality native port without using source code, it took several years for a downright massive team of fans to port ''VideoGame/SuperMario64'' to PC-- most of that time was spent decompiling the game's files into something that could be converted to C code (the high-profile leak of part of the game's actual source code only occurred after the port was already complete), and it was considered an ''easy'' project to take on given that it didn't use any particularly fancy compilation techniques; taking that long to port even an old game to a current console risks releasing the port once the target system is already obsolete, given that most consoles are only relevant for a handful of years, and when factoring in the likely greater time needed to decompile a more complexly put-together game, the risk only increases[[/note]]. This can be done officially, or sometimes unofficially in the case of [[GameMod ROM hacks]] that expand a game beyond the original size of its cartridge, for example. Emulation can also make {{Compilation Rerelease}}s or services like Virtual Console easier to implement, as it means only having to create one piece of new software instead of porting each game individually.

* '''Low-level emulation (LLE)''' seeks to simulate the original hardware more faithfully instead of trying to emulate its features. They simulate the inner workings of the console or computer, sometimes [[UpToEleven even gate-by-gate]] or down to the last processor cycle. Higan, formerly known as bsnes, is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games. Another key point in Higan is it syncs up every piece of hardware its emulating at the same bus speed as the SNES, i.e., ~24MHz.

Emulators are also a popular way to make a port or UpdatedRerelease on sufficiently powerful hardware, especially given that making a native port can be far more difficult for a variety of reasons. Many older games were coded in hardware-specific assembly language, meaning that porting them to run natively on other systems would essentially require rewriting them from scratch. The source code for some games--even big ones--is outright lost (either due to misplacement, uncontrollable damage, human error, or just plain throwing it out due to it not being seen as practical to keep) further makes emulation a favorable method of porting, provided that the emulator itself can faithfully run the game(s) in question[[note]]to give an idea of how much work it takes to make a good-quality native port without using source code, it took several years for a downright massive team of fans to port ''VideoGame/SuperMario64'' to PC-- most of that time was spent decompiling the game's files into something that could be converted to C code (the high-profile leak of part of the game's actual source code only occurred after the port was already complete), and it was considered an ''easy'' project to take on given that it didn't use any particularly fancy compilation techniques; taking that long to port even an old game to a current console risks releasing the port once the target system is already obsolete, given that most consoles are only relevant for a handful of years, and when factoring in the likely greater time needed to decompile a more complexly put-together game, the risk only increases[[/note]]. This can be done officially, or sometimes unofficially in the case of [[GameMod ROM hacks]] that expand a game beyond the original size of its cartridge, for example. Emulation can also make {{Compilation Rerelease}}s or services like Virtual Console easier to implement, as it means only having to create one piece of new software instead of porting each game individually.

* '''High-level''' emulation basically approximates the system's reaction to software instructions, e.g. intercept instructions by the game, and respond to it using [=APIs=] by the operating system, as opposed to simulating the hardware in a granular and more detailed manner. Made infamous by [[http://www.emulator-zone.com/doc.php/n64/ultrahle.html [=UltraHLE=]]], a UsefulNotes/Nintendo64 emulator which [[http://books.google.com/books?id=-0zuAAAAMAAJ made]] [[https://books.google.com/books?id=LrYxAQAAIAAJ&q=ultrahle&dq=ultrahle&hl=en headlines]] for running (major) Nintendo 64 titles at a playable framerate on hardware of the time, and is used by post-SNES era emulators due to increasing computational demands. The official emulators used on the UsefulNotes/Xbox360, UsefulNotes/XboxOne, along with UsefulNotes/PlayStation3 and UsefulNotes/PlayStation4, are said to make use of HLE, mostly for reasons of complexity. Even if the Xbone and [=PS4=] is several times faster than their predecessors, it still takes considerable resources to emulate them at a low level.
* '''Low-level''' emulation seeks to simulate the original hardware more faithfully, as instead of merely reacting to an instruction by the game or software, they simulate the inner workings of the console or computer, sometimes [[UpToEleven even gate-by-gate]] or down to the last processor cycle[[note]]i.e. cycle-accuracy[[/note]]. Higan, formerly known as bsnes, is one such example of an LLE, where author byuu took the herculean effort of reverse-engineering every single enhancement chip used on SNES games.

The choice between high or low-level emulation has led to some arguments from casual players and purists, the former arguing that HL emulators could be developed faster and often could potentialy run better on lower-end hardware, and so as long as popular titles can be played, HLE is enough, while the latter campaign for preservation and conservation of what can now be seen as a cultural legacy-- as HLE emulators don't provide an accurate reference on the inner workings of a device, it therefore is unsuitable for purposes of recreating and/or documenting vintage hardware. They also argue that while HLE is easier to get start running, time spent on LLE pays itself better in the long run. In practice most modern emulators use some combination of both approches.

Emulators are also a popular way to make a port or UpdatedRerelease on sufficiently powerful hardware, especially given the far greater difficulty of making a native port. Many older games were coded in hardware-specific assembly language, meaning that porting them to run natively on other systems would essentially require rewriting them from scratch. The source code for some games--even big ones--is outright lost (either due to misplacement, uncontrollable damage, human error, or just plain throwing it out due to it not being seen as practical to keep) further makes emulation a favorable method of porting, provided that the emulator itself can faithfully run the game(s) in question[[note]]to give an idea of how much work it takes to make a good-quality native port without using source code, it took several years for a downright massive team of fans to port ''VideoGame/SuperMario64'' to PC-- most of that time was spent decompiling the game's files into something that could be converted to C code (the high-profile leak of part of the game's actual source code only occurred after the port was already complete), and it was considered an ''easy'' project to take on given that it didn't use any particularly fancy compilation techniques; taking that long to port even an old game to a current console risks releasing the port once the target system is already obsolete, given that most consoles are only relevant for a handful of years, and when factoring in the likely greater time needed to decompile a more complexly put-together game, the risk only increases[[/note]]. This can be done officially, or sometimes unofficially in the case of [[GameMod ROM hacks]] that expand a game beyond the original size of its cartridge, for example. Emulation can also make {{Compilation Rerelease}}s or services like Virtual Console easier to implement, as it means only having to create one piece of new software instead of porting each game individually.

Emulators are also a popular way to make a port or UpdatedRerelease on sufficiently powerful hardware, especially given the far greater difficulty of making a native port. Many older games were coded in hardware-specific assembly language, meaning that porting them to run natively on other systems would require essentially rewriting them from scratch. The source code for some games--even big ones--is outright lost (either due to misplacement, uncontrollable damage, human error, or just plain throwing it out due to it not being seen as practical to keep) further makes emulation a favorable method of porting, provided that the emulator itself can faithfully run the game(s) in question[[note]]to give an idea of how much work it takes to make a good-quality native port without using source code, it took several years for a downright massive team of fans to port ''VideoGame/SuperMario64'' to PC-- most of that time was spent decompiling the game's files into something that could be converted to C code (the high-profile leak of part of the game's actual source code only occurred after the port was already complete), and it was considered an ''easy'' project to take on given that it didn't use any particularly fancy compilation techniques; taking that long to port even an old game to a current console risks releasing the port once the target system is already obsolete, given that most consoles are only relevant for a handful of years, and when factoring in the likely greater time needed to decompile a more complexly put-together game, the risk only increases[[/note]]. This can be done officially, or sometimes unofficially in the case of [[GameMod ROM hacks]] that expand a game beyond the original size of its cartridge, for example. Emulation can also make {{Compilation Rerelease}}s or services like Virtual Console easier to implement, as it means only having to create one piece of new software instead of porting each game individually.

[[caption-width-right:350:[=NESticle=], one of the first and most influential video game emulators of all time, running the 1984 UsefulNotes/NintendoEntertainmentSystem game ''VideoGame/BalloonFight'' on Windows 95[[note]]if you ''really'' wanna get technical, it's a 2012-era Mac running an emulated version of Windows 95 to run [=NESticle=] to emulate ''Balloon Fight''[[/note]].]]