Changes

Jump to navigation Jump to search

High/Low level emulation

403 bytes removed, 14:05, 28 November 2014
no edit summary
'''High-level emulation''' (HLE) is an approach for and '''Low-level emualtion''' (LLE) are approaches to the construction of [[emulator]]s, especially for [[video game console]]s, which attempts to simulate the response of the system rather than accurately recreating its internal designemulators.
Instead of trying to accurately create or recreate LLE just runs translates the hardware gate by gate, in HLE a software platform native code and is created on which the emulated code can be run traditional way of emulating. HLE in a host computer having different hardware and a different instruction set. The effort focuses on recreating contrast attempts to simulate the appropriate ''functionality'' provided by response of the system emulatedrather than accurately recreating its internal design. ThusHLE rewrites functions using native c/++ code, and then hooks into calls to that function, and runs the emphasis is shifted from the most efficient ''method'' HLE version instead of processing data to getting the same (or comparable) ''results'' as if the native platform was used. By contrast, the traditional way of emulating is termed ''Low-level emulation'', or ''LLE'' which is used to develop new computer hardware and execute legacy binary code.
The term HLE originates from [[UltraHLE]], the first emulator for the [[Nintendo 64]] console that ran commercial games. Initial discussion about HLE occurred Instead of trying to give context for accurately create or recreate the reasons behind some [[video game]]s not functioning properly with the emulator. The earliest (1962) high-level emulator was called a [[Emulator#Functional simulators|functional simulator]] for executing military flight programs written hardware gate by gate, in symbolic [[assembly language]] code, without generating binary code. == Criteria for High-Level Emulation == In order for HLE approach to work, the a software platform in question must meet certain criteria. Namely, there must exist a higher [[abstraction level]] than is created on which the raw binary [[machine emulated code]] to can be executed, realised directly run in the [[a host computer having different hardware|hardware]], or and a different instruction set. The effort focuses on recreating the appropriate ''functionality'' provided by the [[operating system]]emulated. In any caseThus, it must exist outside the emphasis is shifted from the most efficient ''method'' of processing data to getting the [[software]] intended to run on same (or comparable) ''results'' as if the emulated native platformwas used. By contrast, and have certain amount the traditional way of standardisation and [[semantics]] for HLE to succeed.emulating is termed
== Comparison to traditional models ==
Among the advantages of HLE technique, chiefly are the ability to utilise the existing host facilities much better and more easily, the ability to optimise the results as the code and hardware improves, and much less or no work at all needed to achieve the desired end result, if an appropriate function is already provided by the host, as would be common in 3D graphics functionality. The progress of implementations is also much more independent of the detailed hardware documentation, instead relying only on the listing of possible functions available to the programmer, which is already provided by a [[software development kit]] available for each platform.
The disadvantages include much higher reliance on standardisation standardization among target applications, and the presence of sufficiently high-level mechanisms in the emulated platforms. If there is no such mechanism, or applications fail to utilise utilize it in one of the already supported ways, they will not work correctly, even if other, superficially similar applications function with no problems. Thus a significant amount of [[tweak]]s might be required to get all of the desired titles to run satisfactorily.
As a side-effect, HLE removes the common source of legality issues, by not requiring the users to provide it with the [[bootstrap]] software used by the original platform to create an environment for applications to run in. Because the emulator itself provides such environment, it no longer needs system [[ROM image]]s, bootstrap cartridge images or other software obtained from a physical copy of the emulated system, a process which usually resulted in an unclear status in the light of [[copyright law]].
The state of consumer level PCs have also changed, newer computers are much faster than 20 years ago, and LLE is becoming possible at last for some of the very first consoles and CPUs that had to be emulated via HLE in the 90s. As a result, many emulators can opt for accuracy and cycle-accurate replication of the microchips which result in very precise software environments that can finally replace old consoles and computers. However, HLE has found a new purpose in smartphones, handheld devices, and other electronic gadgets that have much lower specs than the average computer, and for these devices the speed and simulated functionality translates to higher frame-rates.
 
==Examples==
 
The term HLE originates from [[UltraHLE]], the first emulator for the [[Nintendo 64]] console that ran commercial games. Initial discussion about HLE occurred to give context for the reasons behind some [[video game]]s not functioning properly with the emulator.
 
Dolphin uses HLE for various system functions, related to wiimotes, net, file access, wiimotes, usb, etc but mostly dolphin is fairly low level emulation, including for the gpu.
== External links ==
Anonymous user

Navigation menu