Editing High/Low level emulation

'''High-level emulation''' ('''HLE''') and '''low-level emulation''' ('''LLE''') refer to methods used when emulating components or entire systems. They're used to differentiate approaches to system implementations by how each emulator handles a given component; a higher-level emulator abstracts the component with the goal of improving performance on the host, sacrificing the thorough measures needed to guarantee [[Emulation Accuracy|the correct behavior]]. The simplicity of most classic consoles allow low-level emulation to be feasible, but the exponential increase of processing power in newer consoles has necessitated the need for abstraction. Because high-level emulation can often be seen as a simulation, BIOS dumps and other machine-specific code that would normally enter the legal gray area of backups are usually not required.

As an example, a console has a 3D graphics chip called by the CPU to render games. An accurate low-level emulator would use a software renderer to ensure that the component's output is 1:1 with the original console. However, the software renderer runs on the host's CPU, which isn't designed for 3D applications; performance will be sluggish if the CPU isn't powerful enough to handle accurate 3D rendering in realtime. Fortunately, modern 3D APIs can alleviate this problem by redirecting 3D computations to the host's GPU, so a high-level emulator will make calls to the host's graphics chip in order to render the game faster. And HLE doesn't just speed up 3D rendering, it can also act like components that don't require accurate emulation for the original software to properly use it. As another example, a console has a system management interface separate from the rest of the hardware that programs will call to in order to interact with the system, ranging from save files to configuration settings. Accurately emulating this as a discrete component would slow down the emulation severely for no real benefit, because this data can easily be given to the software without having to jump through all the hurdles taken by the original hardware. These two respective examples are demonstrated by most graphics-accelerated [[Nintendo 64 emulators|Nintendo 64]] emulator plugins that target the Reality Display Processor, and [[Dolphin]]'s handling of the [[Wii emulators|Wii]]'s Starlet co-processor.

Contrary to popular belief, the idea behind HLE has been around for longer than N64 emulator [[UltraHLE]] first premiered. Some systems of the past can only be simulated on computers today as they were not designed with conventional hardware (i.e. a CPU, memory bank, video chip, etc.), but instead [[Discrete Circuitry-Based Arcade Games|discrete circuits]]. UltraHLE did begin the discussion of whether or not HLE is a good approach for preserving hardware and how it responds. Today, the debate continues.

The '''Hybrid''' emulation approach has gained significant traction in recent software emulators for newer systems. This popularity stems from its ability to combine two techniques: Low-Level Emulation (LLE) for critical operating system services and High-Level Emulation (HLE) for complex/demanding components.<ref>[https://fosdem.org/2024/events/attachments/fosdem-2024-1726-panda3ds-climbing-the-tree-of-3ds-emulation/slides/22561/Panda3DS_FOSDEM_o9U1196.pdf FOSDEM 2024: Panda3DS presentation Page 34~36]</ref> This "synergy" offers several benefits;

:*Reduced development effort: By focusing LLE on essential aspects, developers can streamline the process.
:*Enhanced performance: HLE simplifies emulation of non-critical components, leading to faster execution.
:*Maintained accuracy: LLE ensures accurate emulation of core functionalities.

:Examples of hybrid emulation approach softwares: Xenia and RPCS3.

== Comparison to traditional models ==

Compared to LLE, HLE has a very different set of design decisions and trade-offs. As the complexity of modern (fifth generation and above) video consoles rapidly increases, so does their computational power; more importantly, the difference in computational power to consumer PCs, which are the most common host systems for the emulators, has shrunk over time. Thus, the requirements on the quality of the emulated services increases, together with the difficulty of doing so. Hardware chips in consoles are usually extremely specialized towards specific functionality needed by games written for them, often in directions which are completely different from those taken by the hardware in an average PC machine. For example, 3D graphics might be realized by an extremely fast integer processor, coupled with the assumption of main system memory being the same as graphics memory, taking away the separate step of loading textures.

Emulating such an architecture programmatically on a PC, characterized by the emphasis put on floating-point operations, and specialized graphics hardware with memory separate from the system memory would be extremely difficult, especially taking into account the scarcity of documentation typical for specialized, proprietary hardware. Even if such an emulator could be created, it may be too slow for use. An HLE emulator would take the data to be processed, along with the operations list, and implement it using the means available on the host systems. Floating-point math and GPU operations could be performed natively. The result is not only a much better match with the host platform but often significantly better results, as floating-point computation yields higher quality graphics suitable for high-resolution displays available for PCs. It is important to note, however, that the difference in resolution, shading, or processing of graphics memory, sound, and others will change the output from the native machine environment that the emulator is trying to replicate. Other than being less authentic, in some cases, this could be undesirable, for instance rendering portions of the game that were not meant to be seen, making seams in textures more evident because of higher resolutions, bi-linear filtering pixel layers, and at worst will cause software to crash or not execute certain instructions due to interrupts not correctly handled because of HLE simulation.

== Advantages and disadvantages of HLE ==

Among the advantages of HLE technique, chiefly are the ability to utilize the existing host facilities much better and more easily, the ability to optimize 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 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 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 tweaks 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 ROMs, 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.

HLE is easier to start and when optimized, can achieve great speed even on weaker hardware. But it does so by sacrificing authenticity. Also, the accuracy of HLE approach cannot be matched to proper LLE software. The speed of HLE is the greatest advantage, however, it is achieved by the simulations of the desired output, rather than a mathematically correct output timed properly. In many cases, a specific software can run 90% as close when compared to the emulated machine, and another case 50% or even 0% (may fail to boot or start) in the same emulator, because of software that depends on very precise timings or functions that do not output properly. In LLE, since the software is trying to replicate the original hardware chips down to the bugs and waits, most software should work bug-free and not break one another because of the extensive game-specific hacks and individual, sometimes per game tweaks that become necessary once an error is spotted in HLE. Thus, maintaining compatibility and accuracy on an HLE software that targets a machine that had many games released in its time, will prove much more work and testing of hundreds, sometimes thousands of individual software.

== Future outlook ==

As the console systems progress into more and more complexity, the importance of HLE approach increases. Modern (6th and 7th generation) video consoles are already far too complex and powerful to facilitate their emulation using the traditional approach. Additionally, some systems (notably [[Xbox 360 emulators|Xbox 360]]) have themselves little more than a standardized PC operating system, making it wasteful to try to recreate the hardware using PC as the host machine. Thus, HLE increasingly becomes the only sensible approach.

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. As well, Blueshogun, one of the developers of [[Cxbx]], has [https://www.reddit.com/r/emulation/comments/2u2k5i/last_console_to_crack_an_in_depth_interview_on/ stated] that making an LLE [[Xbox emulators|Xbox emulator]] ''would be MUCH more ideal and feasible'' <ref name="pulp365">{{cite web|url=http://pulp365.com/2014/05/last-console-crack-depth-interview-original-xbox-emulation/|title=Pulp365 interview with Blueshogun. Site inactive.|publisher=pulp365.com|accessdate=2017-06-11|date=2014-05}}</ref><ref name="Microsoft1">{{cite web|url=https://msdn.microsoft.com/en-us/library/xbf3tbeh(v=vs.140).aspx|title=/LTCG (Link-time Code Generation)|publisher=Microsoft|accessdate=2017-05-22}}</ref><ref name="Microsoft2">{{cite web|url=https://msdn.microsoft.com/en-us/library/bb985904.aspx|title=Under The Hood: Link-time Code Generation|publisher=Microsoft|accessdate=2017-05-22}}</ref> and he, along with others have been working on [[XQEMU]], an LLE Xbox emulator that has been slowly making progress. 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.

Currently, since mid-2016 and already well into the year 2017, there is a strange synergy between [[Cxbx-Reloaded]], a mainly HLE Xbox emulator, and [[XQEMU]], a purely LLE emulator. For more details on which one would be the best for aspiring developers to work on check these Reddit threads with more links to other threads & many detailed comments by JayFoxRox, one of the contributors on XQEMU, with the explanations that XQEMU is the best-suited emulator for developers to focus on in terms of improving accuracy and portability: <ref name="Reddit1">{{cite web|url=https://www.reddit.com/r/emulation/comments/6dl94y/why_is_there_a_lack_of_original_xbox_emulation/|title=Why is there a lack of Original Xbox emulation?|publisher=Reddit|accessdate=2017-06-11|date=2017-05-29}}</ref><ref name="Reddit2">{{cite web|url=https://www.reddit.com/r/emulation/comments/6f31na/do_you_prefer_low_level_emulation_or_high_level/|title=Do you prefer low level emulation or high level?|publisher=Reddit|accessdate=2017-06-11|date=2017-06-04}}</ref>.
JayFoxRox, a contributor to the open-source XQEMU emulator and regular commenter for that emulator's foundation and progress, has appeared at a Reddit thread<ref name="Reddit3">{{cite web|url=https://www.reddit.com/r/emulation/comments/6c93rg/xqemu_more_games_ingame/dhuakqc/|title=XQEMU - more games ingame|publisher=Reddit|accessdate=2017-06-11|date=2017-05-23}}</ref> stating the fact that many more original Xbox games have been able to get in-game and, in some cases, at decent speeds on XQEMU; in addition to more work on backend tooling and a [http://xboxdevwiki.net/Emulators dedicated wiki].

==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 games not functioning properly with the emulator.

[[Dolphin]] uses HLE for the Starlet co-processor and its various system functions, related to Wiimotes, networking, file access, USB, and the like but it retains low-level components for the CPU, GPU, and memory handling.<ref>Dolphin blogs: [https://dolphin-emu.org/blog/2014/11/12/the-rise-of-hle-audio/ The Rise of HLE Audio], [https://dolphin-emu.org/blog/2015/08/19/new-era-hle-audio/ The New Era of HLE Audio]</ref>

==See also==
*[[History_of_emulation|History of emulation]]
*[[Emulation_accuracy|Emulation accuracy]]

== External links ==
* [http://www.emulator-zone.com/doc.php/n64/ultrahle.html History of UltraHLE]
* [http://www.emuunlim.com/UltraHLE/old/techinfo.htm UltraHLE - Technical Information]: an overview of low-level CPU emulation and high-level co-processor emulation in UltraHLE
* [[Wikipedia:UltraHLE#The_Ultra_High-level_(UHLE)_technique|The Ultra High-level (UHLE) technique]]

==References==
<references/>