Emulation General Wiki

Emulation issues and roadblocks

Revision as of 14:00, 10 July 2026 by Ahayri (talk | contribs)
For modern techniques and methods used for emulation, see High and low-level emulation#Future Outlook.
For ways to support or contribute to an emulation or similar project, see Support emulation projects.

placeholder text

Platforms that need attention

Main article: Category:Partially emulated
There are several systems that require more attention from the emulation community. While multiple emulators may exist, none of them appear particularly promising. These systems for which a PC cannot yet fully replicate the experience, because emulators are incomplete, or lack support for key hardware features, peripherals, or specialized components. As a result, certain software or functions remain usable only on original hardware.

Windows XP

Main article: Windows NT 5.x emulators

For PC games up to roughly 1997, emulators such as 86Box and DOSBox#Forks accurately recreate the hardware environment of the era. Beginning around 1998, however, PC games increasingly depended on hardware-accelerated 3D graphics, SSE instructions, and substantially more CPU performance. A fully cycle-accurate implementation of an entire Windows XP-era PC including the CPU, chipset and graphics hardware is impractical due to the computational cost of faithfully reproducing that generation of x86 systems.

Instead, modern PC emulation generally relies on either hardware-assisted virtualization (such as KVM or WHPX) or dynamic binary translation (DBT). Hardware-assisted virtualization executes guest code directly on the host processor and therefore provides substantially higher CPU performance, but requires compatible host hardware and introduces a dependency on the host operating system's virtualization facilities. Generic dynamic binary translation engines such as QEMU's TCG/MTTCG provide a flexible software-only foundation but generally do not deliver sufficient performance in their standard form. Nevertheless, projects such as Xemu, RPCS3 and Cemu demonstrate that carefully optimized, workload-specific dynamic recompilers can achieve practical performance even for systems that very complex.

Unlike console emulators, Windows XP emulation targets the same general x86 instruction set used by modern desktop processors. Although privilege levels, segmentation, paging, exceptions, self-modifying code and other architectural differences still require translation, guest instructions can often be mapped to relatively efficient native host code. Rather than attempting cycle-accurate execution, a specialized recompiler could instead optimize frequently executed code paths through techniques such as larger translation blocks, aggressive block linking, profile-guided optimization and guest operating system-aware fast paths. The performance target is also substantially lower than native execution on modern processors. Many games released in that era were designed to run on hardware comparable to a Pentium 4 or Athlon XP paired with a DirectX 8 or DirectX 9 graphics accelerator. Consequently, a software emulator does not necessarily need to approach native CPU performance; it instead needs to provide performance broadly comparable to contemporary hardware while minimizing translation overhead. The largest remaining technical challenge for the 1998–2005 era is efficient 3D graphics acceleration. While projects such as QEMU 3dfx demonstrate that application-level API pass-through is feasible, these solutions typically rely on guest-side wrapper libraries, manual configuration, and external translation layers. Other projects including SoftGPU, Gallium Nine, and experimental virtio-gpu implementations explore different approaches to accelerating legacy graphics APIs. A fully integrated software emulator combining a high-performance dynamic recompiler with a paravirtualized graphics architecture remains an area of active research rather than an established solution.

Approach 1: User-Space API Pass-Through

Historically, developing complete virtual graphics drivers for closed-source legacy Windows environments (particularly Windows 9x and XP) has been significantly more complex than implementing user-space API forwarding. Projects such as QEMU 3dfx therefore adopted an API Pass-Through (or Forwarding) approach.[1]

  • This approach injects custom user-space library stubs into individual game directories or system locations to intercept graphics API calls before they reach the guest's virtual display driver.*
  • For Direct3D acceleration, this method relies on a complex manual "ddthru" configuration. Users must modify Windows ACPI settings through Device Manager, install proxy libraries (such as ddraw.dll, ddrawwq.dll, and dsound.dll) into %SYSTEMROOT%\system32, and use tools such as wine-get to deploy matching WineD3D wrapper DLLs into individual game directories. Because the guest desktop is rendered through a virtual 2D display driver such as BoxVNT, which provides no native 3D acceleration, the pass-through layer intercepts graphics API calls before they reach the virtual display device and forwards them to host-side rendering backends.
  • When an application invokes a supported graphics API, the injected libraries intercept those API calls and forward them to compatible host-side wrapper libraries (such as dgVoodoo2, nGlide, or Mesa), where they are translated into graphics commands executable by the host GPU.
  • Drawbacks: Because interception occurs above the graphics driver layer, compatibility depends on successfully replacing or proxying application-visible libraries. The resulting configuration process is often complex, requiring manual installation of wrapper DLLs, per-game configuration, and system modifications. Compatibility can vary between titles, particularly for applications that rely on undocumented behavior or interact directly with graphics resources outside the expected API pathways. In addition, implementations frequently rely on host virtualization technologies (such as WHPX or KVM), introducing another software layer whose behavior and timing characteristics are outside the emulator's direct control.
+───────────────────────────────────────────────────────────────────────────+
|                           GUEST OS (Windows XP)                           |
|                                                                           |
|   [ Manual Device Manager Tweak ] ──► (Switches Kernel to ACPI PC)        |
|                                                                           |
|   [ 2D Desktop / GUI Pipeline ] ────► [ BoxVNT Virtual Display Driver ]   |
|                                                                           |
|   [ Target Retro Game Folder ]                                            |
|   ├── game.exe                                                            |
|   └── [ Injected Stubs ] (wine-get: d3d8.dll / d3d9.dll / ddraw.dll)      |
|            │                                                              |
|            ▼ (Intercepts graphics API calls before BoxVNT)                |
|   [ Global System Directory ] (%SYSTEMROOT%\system32)                     |
|   └── [ Proxy Wrappers ] (ddraw.dll, ddrawwq.dll, etc.)                   |
+─────────────────────────────────┬─────────────────────────────────────────+
                                  │
                                  ▼ (Forwards intercepted API calls)
    =====================================================================
                     HOST VIRTUALIZATION BOUNDARY
    =====================================================================
                                  │
                                  ▼
+─────────────────────────────────┴─────────────────────────────────────────+
|                            HOST OS / EMULATOR                             |
|                                                                           |
|   [ QEMU API Pass-Through Backend ]                                       |
|            │                                                              |
|            ▼ (Routes calls to host wrapper libraries)                     |
|   [ Translation Layer ] (dgVoodoo2, nGlide, Mesa, etc.)                   |
|            │                                                              |
|            ▼                                                              |
|   [ Host GPU ] ─────────────► [ Emulator Display Window ]                 |
+───────────────────────────────────────────────────────────────────────────+

Approach 2: Paravirtualized GPU Device

An alternative architectural approach is to virtualize the guest graphics device itself rather than modifying individual applications or replacing system libraries. Following the same general design philosophy as modern paravirtualized GPU implementations (such as VirtualBox's VBoxVGA or QEMU's VirGL), the guest OS exposes a virtual graphics adapter whose driver presents a standard graphics device to Windows while forwarding rendering commands to the emulator. Unlike existing virtual GPU implementations, however, this approach specifically targets legacy Windows 9x/XP graphics APIs within a software-emulated environment.

  • Guest-side virtual graphics driver: The guest installs an OS-compliant virtual graphics driver consisting of a User-Mode Driver (UMD) and a Kernel-Mode Miniport Driver (KMD). Applications continue using the original Microsoft Direct3D runtime (such as d3d8.dll or d3d9.dll) without modification. Rendering requests naturally flow through the registered virtual graphics device instead of requiring per-game DLL replacement or API hooks.
  • Shared-memory command transport: Rather than performing expensive hypercalls for every rendering operation, the emulator exposes a shared-memory command queue (such as a ring buffer). The guest graphics driver serializes rendering commands, resource updates, and synchronization events into this queue, allowing the host to consume them asynchronously with minimal virtualization overhead.
  • Host-side virtual GPU renderer: The emulator reconstructs the guest rendering state from the command stream and executes it using a dedicated virtual GPU renderer implemented on top of a modern graphics API such as Vulkan or OpenGL. Unlike application-level wrapper projects, the renderer operates entirely within the emulator rather than inside the guest operating system.
+───────────────────────────────────────────────────────────────────────────+
|                           GUEST OS (Windows XP)                           |
|                                                                           |
|   [ Retro Game ]                                                          |
|         │                                                                 |
|         ▼                                                                 |
|   [ Microsoft Direct3D Runtime ]                                          |
|   (d3d8.dll / d3d9.dll)                                                   |
|         │                                                                 |
|         ▼                                                                 |
|   [ Virtual Graphics Driver ]                                             |
|   (UMD + Kernel Miniport Driver)                                          |
+─────────────────────────────────┬─────────────────────────────────────────+
                                  │
                                  ▼
                  =================================
                   SHARED MEMORY COMMAND QUEUE
                  =================================
                                  │
                                  ▼
+─────────────────────────────────┴─────────────────────────────────────────+
|                           HOST OS / EMULATOR                              |
|                                                                           |
|   [ Command Queue Consumer ]                                              |
|            │                                                              |
|            ▼                                                              |
|   [ Virtual GPU Command Decoder ]                                         |
|            │                                                              |
|            ▼                                                              |
|   [ Virtual GPU Renderer ]                                                |
|            │                                                              |
|            ▼                                                              |
|   [ Vulkan / OpenGL Backend ]                                             |
|            │                                                              |
|            ▼                                                              |
|   [ Host GPU ] ─────────────► [ Emulator Display Window ]                 |
+───────────────────────────────────────────────────────────────────────────+

Unlike application-level API forwarding, the virtual graphics driver does not simply relay Direct3D API calls to the host. Instead, it implements a complete virtual graphics device whose command stream serves as the interface between the guest operating system and the emulator. The guest driver translates Direct3D operations into commands understood by the virtual GPU, while the emulator reconstructs those commands and executes them using a modern graphics backend such as Vulkan or OpenGL. This avoids the considerably more difficult task of emulating the register-level behavior and rendering pipeline of a physical GPU while still allowing Windows and applications to interact with what appears to be standard graphics hardware.

Since rendering is performed entirely on the host GPU, completed frames generally do not need to be copied back into the guest frame buffer except when required for compatibility (for example, guest software that reads the front buffer directly). Instead, the emulator presents the rendered output directly within its own display window while maintaining guest-visible synchronization state.

The primary challenge is implementation complexity rather than raw GPU performance. A complete virtual graphics device must faithfully virtualize Direct3D state management, resource creation, synchronization primitives, presentation, capability reporting, shader handling, and device-loss behavior so that Windows and applications observe behavior consistent with physical hardware. Although modern GPUs provide orders of magnitude more rendering performance than hardware from the Windows XP era, overall performance depends primarily on efficient command serialization, state tracking, and translation rather than GPU throughput alone.

Compared to application-level API forwarding, this approach offers several advantages:

  • The original Microsoft graphics runtime remains untouched, avoiding per-game DLL replacement and compatibility hacks.
  • Graphics virtualization occurs at the device-driver level, allowing all applications to use the same rendering pipeline automatically.
  • The virtual GPU provides a stable hardware abstraction for the guest while the emulator translates its command stream into modern graphics APIs, eliminating the need to emulate an entire legacy GPU architecture.
  • Shared-memory command transport minimizes synchronization overhead compared to frequent VM exits or hypercalls.
  • Rendering logic resides entirely within the emulator, resulting in a more centralized and maintainable graphics architecture.

For more information about PC emulation and their reverse engineering;

Other projects and emulated systems that have helped, or may potentially help, PC emulators in the future;

PlayStation

Rendering quirks

 
Left: Native resolution and unblended dithering. Right: Higher internal resolution and no dithering.
 
Jittering in games can stick out more when using higher internal resolutions. This full-color GIF may require you to view its page to see the animation.

The PlayStation takes shortcuts when rendering as a result of making most of the hardware available. This can cause some quirks that become even more noticeable when the internal resolution increases.

Polygons may jitter as a result of low-precision, fixed-point (to the native resolution) math, but this is mostly unnoticeable at native resolutions. Emulators that can increase the internal resolution of games have attempted to fix this.

There is no z-buffer in the hardware. This can cause things like polygons to pop over others; the limbs of Tekken characters are a good example of this. It is theoretically possible to implement this, but it wouldn't be accurate to the hardware.[2][3]

When perspective correction isn't applied to textures, certain viewing angles can make them distorted, more so when an object is near the edge of the camera up close. Tenchu: Stealth Assassins is particularly infamous for texture distortion, most noticeably in the   training level where floor textures appear wavy at oblique angles; developers usually mitigate this by adding polygons to walls, floors and other scenery, but at the cost of filling the PlayStation's geometry rate. In DuckStation, at least, this problem has been solved.

Many PlayStation games dither to varying degrees due to having a low color depth. On most TVs, this dithering would blend in order to make new colors and smooth gradients. Plugin-based emulators usually have graphical plugins that use a 32-bit color depth, which removes dithering, while software-rendered plugins and emulators tend to retain it. While higher color depth can be considered an enhancement since it results in less noise and smooth gradients, some think of dithering as seen on real hardware as added shading and texture, especially on untextured polygons. The emulators that use software rendering and can increase the internal resolution of games can retain dithering for the shading and texturing aspect, and it's made more subtle by shrinking the artifacts.

Less-notable games using special peripherals

ZXE-D: Legend of Plasmalite requires the use of a special peripheral to play the game. It is a robot with connectable parts that plug into the memory card slot, which is then replicated in the game. No emulator has ever focused on it, probably due to a number of reasons:

  • It's not a well-known game.
  • No third-party controller and memory card connector has gotten support from emulators the same way that Nintendo's official GameCube controller adapter has.
  • To emulate this purely in software means it has to be reverse-engineered, which can take a bit of time.

CD format

PS1 games use the CD-ROM XA (eXtended Architecture) format, which is based on CDi and allows developers to use both CD-ROM and CD-DA (audio) tracks on the same disc.[4]

Certain image formats and CD dumping methods don't support this format correctly and end up with the CD-DA tracks missing or corrupted, hence no audio. The ISO format in particular only stores the content of a CD-ROM filesystem and cannot store CD-DA tracks at all. So it's generally a very bad idea to use ISO for PS1 games (even though it should work for single-track games). Even running an ISO file based on a PS1 game (i.e., Ridge Racer, Tomb Raider 1-2) with CD-DA audio may often cause an emulator such as ePSXe and other peers to freeze and/or hang up, especially during loading of a saved data or in-game levels and transactions.

  • However, a mounted image (Using Daemon Tools), running from a CD-ROM or using the Mooby2 plugin can solve these CD-DA problems. The MDS/MDF format is good for backing up the CD-DA, audio-equipped PS1 games. However, the best Image format for any PS1 game is the CUE/BIN format. The reason being that almost all the burning programs can read it, and the relevant patching programs (i.e., PPF-O-Matic) are designed for that format. Clone CD images in IMH/CCD format provide another ideal option as it has virtually the same structure as CUE/BIN format (The IMH file is the same data as a BIN file at the hex level). However, the available burning programs are largely unable to read Clone CD format. ISObuster and ImgBurn are good tools for some of the aforementioned notes.[5]
  • The European regional versions of many PS1 games tended to have copy-protection embedded, so they could cause problems with backing up images. These game backups could cause hangs or show a black screen infinitely in a typical emulator. An easy way to avoid that problem is to try the US regional versions. Another way is to patch it using a .sbi file which contains the protection information needed to run the game, see #CD player section for more information about this.
The perfect solution possible, at least for the ePSXe emulator—and perhaps other similar plugins-based emulators—would be (No virtual drive mounting needed)::
1. Use the Mooby2 2.8 CD-ROM plugin, and uncheck 'subchannel reading' in the plugin's settings.
(Just in case: also make sure 'repeat all cdda' is checked, and 'cdda volume' is set to something like 50 or 60, or else you won't hear anything.)
2. Launch the game with File → Run CDrom (browse, find and select your CD image as the window pops up.)
It's recommended you use the Eternal 1.41 sound plugin with default settings along with this. The SaPu CDRom Plugin v.1.0/1.3 is good if you're running official CDs. It especially works well with Daemon Tools Lite or Alcohol 120% when mounting an image.
  • If running ePSXe or a similar emulator on an old Windows OS (E.g., 9x, ME, 2000, XP), use ForceASPI to initialize the ASPI layer (For your disc drive) and a plugin like P.E.Op.S. CDR Version 1.4 plugin or similar. Then set the plugin to "W2K/XP IOCTL scsi commands" before running your PS1 CDs.

For more information about PlayStation hardware and its reverse engineering;

PlayStation 2

Despite a large interest in sixth generation consoles as a whole and the PlayStation 2 in particular, it remains one of the more difficult consoles to emulate accurately. The PlayStation 2's main processor, the Emotion Engine (EE), is built around the 64-bit R5900 running at 294MHz (299MHz on later revisions). Although derived from the MIPS architecture, the R5900 is not a standard MIPS III or MIPS IV implementation; instead, it is a heavily customized design featuring proprietary Multimedia Instructions (MMI), non-IEEE-754 floating-point behavior, and numerous architectural extensions unique to the PlayStation 2.

Architecturally, the R5900 exposes the standard MIPS coprocessor interface consisting of COP0 (system control), COP1 (Floating-Point Unit), and COP2 (Vector Unit 0). Beyond the CPU core, the Emotion Engine also incorporates numerous dedicated hardware engines, including Vector Unit 1 (VU1), the Image Processing Unit (IPU), Vector Interface Units (VIF0/VIF1), the Graphics Interface (GIF), the Direct Memory Access Controller (DMAC), on-die instruction and data caches, and 16KB of scratchpad RAM. These components operate largely independently, communicating through DMA and dedicated internal interconnects while synchronizing only at specific execution points. Accurately reproducing their execution order, synchronization behavior and timing requires considerable computational resources.

Furthermore, the proprietary extensions and execution semantics of the R5900 differ substantially from conventional x86 and ARM processors, creating significant challenges for dynamic recompilation. Beyond instruction translation itself, many PlayStation 2 titles depend on subtle interactions between otherwise independent hardware blocks. Consequently, interrupt timing, DMA scheduling, VIF/GIF packet processing and bus synchronization are often just as important to compatibility as correct instruction execution. The PS2's heavily parallel design frequently leads to the misconception that its emulation should scale linearly across modern multi-core CPUs. In practice, many hardware components require extremely precise synchronization, limiting how aggressively emulator developers can distribute workloads across threads without introducing timing inaccuracies or race-condition-related bugs.[6]

Vector Units (VU0 / VU1)

The Emotion Engine derives much of its computational performance from its two programmable Vector Units. Within emulation, these processors represent one of the architecture's primary computational bottlenecks, much like the SPUs in PlayStation 3 emulation. Because they execute independently of the main R5900 core while maintaining strict synchronization requirements, reproducing their behavior accurately without sacrificing host performance remains one of the emulator's most demanding tasks.

  • VU0 can operate either as the R5900's COP2 vector coprocessor or independently through its own microprogram execution mode. It was commonly used for matrix mathematics, collision detection, physics calculations (which was vital for the physics-driven design trends of the sixth generation) and general gameplay logic.
  • VU1 is a fully programmable vector processor dedicated primarily to geometry processing. Fed through VIF1, it transforms and prepares vertex data before forwarding command streams to the Graphics Synthesizer through the Graphics Interface (GIF). This forward-thinking programmable geometry pipeline contrasted sharply with contemporary PC graphics cards from NVIDIA and ATI, which relied on rigid, fixed-function pipelines before eventually adopting programmable shaders years later.

Both Vector Units receive data through dedicated Vector Interface (VIF) processors, which unpack DMA streams, perform data conversions and execute microcode commands before dispatching work to the VUs. Correctly reproducing VIF behavior (including DMA interactions, unpacking rules and synchronization semantics) is essential for both rendering accuracy and game logic.

PCSX2 maps many Vector Unit operations onto host SIMD instruction sets such as SSE and AVX to improve performance. One of the project's largest architectural improvements was replacing the older SuperVU implementation with the significantly more accurate microVU recompilers. Additional optimizations such as Multi-Threaded VU (MTVU) and "Instant VU1" were introduced to offset the increased computational cost. However, because the EE's floating-point implementation and vector arithmetic differ substantially from standard IEEE 754 behavior, efficiently translating VU programs still requires handling numerous hardware-specific edge cases.

Floating-Point Accuracy & The "SoftFPU" Solution

A major hurdle in PlayStation 2 emulation is accurately reproducing floating-point behavior. Neither the Emotion Engine FPU nor the Vector Units implement IEEE 754 arithmetic; instead, they exhibit unique behavior for underflows, overflows, rounding and exceptional values such as NaNs and infinities. Even minor inaccuracies can result in exploded geometry, broken collision detection, corrupted animation or failed game logic. [2]

Historically, PCSX2 relied on configurable clamping and rounding modes to approximate hardware behavior. While these database driven per-game compatibility hacks resolved many visual and gameplay issues, they did not faithfully reproduce the hardware.[7][8][9][10]

To eliminate these approximations, developers introduced accurate software implementations of the hardware FPU.

  • SoftFPU (Interpreter): A software implementation that reproduces EE floating-point behavior at the bit level, aims to eliminate many legacy game-specific floating-point hacks. While highly accurate, its interpreted execution incurs a substantial performance penalty, making it impractical as the default floating-point backend for general emulation, although it remains useful for debugging and titles with known floating-point accuracy issues.
    • SoftFPU Recompiler (JIT): A long-term approach that translates SoftFPU semantics directly into optimized native machine code. By preserving accurate floating-point behavior while retaining dynamic recompilation performance, aims making it practical as the default floating-point backend for general emulation. Developer DiscoStarslayer has already experimented with this concept within his pcsx2-reliquary fork.[3]

Subsystems & Security

  • IOP (I/O Processor): A MIPS R3000A core (originally the PlayStation 1 main processor) running at 36.864 MHz or 33.8688 MHz. It manages peripheral communication, file I/O, and backward compatibility. In later slim revisions (SCPH-7500X and onward), it was replaced by a PowerPC 405 core running a MIPS emulation layer.
    • USB Controller: Provides USB 1.1 connectivity for peripherals such as keyboards, mice, microphones, EyeToy cameras, storage devices and specialty controllers. Although the controller itself is well understood, accurate emulation depends on faithfully reproducing USB device behavior and timing. Modern versions of PCSX2 support a broad range of USB peripherals through integrated device emulation.
    • IEEE 1394 (i.LINK): Early PlayStation 2 models included an IEEE 1394 interface intended primarily for multiplayer connectivity. Only a small number of commercial titles utilized the port, making it a relatively low priority for emulator development compared to other subsystems.
    • DEV9C: The expansion interface controller responsible for the network adapter and hard disk drive (HDD) systems. Emulating its sub-registers is documented extensively across historical progress reports.[11][12]
    • CDVD: The PlayStation 2's CD/DVD subsystem is responsible for reading game data from optical media and exposing it to software through the I/O Processor (IOP). The CDVD hardware works alongside several system modules such as `CDVDMAN` and `CDVDFSV`, allowing games to access files, stream assets, and read disc metadata. While optical drive emulation is generally considered a more mature area of PlayStation 2 emulation than the Emotion Engine, Vector Units, or Graphics Synthesizer, accurate CDVD behavior remains important for compatibility. Some titles continuously stream data from disc during gameplay, requiring the emulator to provide data at rates and timings consistent with software expectations. Improper handling of disc reads can lead to loading issues, audio synchronization problems, or streaming-related bugs in affected titles. The PlayStation 2 supported multiple media formats, including CD-ROM, DVD-5, and DVD-9 discs. Internally, PCSX2 emulates the system software interfaces used by games to communicate with the CDVD hardware rather than attempting to model every physical characteristic of the optical drive at a mechanical level. Modern versions generally provide highly compatible CD/DVD emulation, and CDVD behavior is no longer considered one of the primary obstacles to PlayStation 2 emulation.
Media Type Typical Capacity Emulation Considerations
CD-ROM ~650–700 MB May require preservation of raw sector layouts and auxiliary disc data depending on the title.
DVD-5 ~4.7 GB The most common PlayStation 2 format and generally straightforward to emulate.
DVD-9 ~8.5 GB Dual-layer media requiring correct handling of layer transitions and disc layout information.
  • Emotion Engine peripherals
    • IPU (Image Processing Unit): A dedicated hardware MPEG-2 macroblock decoder used primarily for full-motion video (FMV), home media playback, and real-time texture decompression. Because the IPU operates asynchronously alongside the main CPU core, matching its exact decoding throughput and signaling timing is vital. Edge-case and minor bugs in IPU emulation still persist within PCSX2 (skipped or stuttering FMVs, out-of-sync audio during cutscenes, or total system lockups when a game attempts to initialize a movie sequence).
    • SPU2 (Sound Processing Unit 2): A dedicated dual-core audio processor handling digital sound effects, streaming ADPCM audio, and real-time reverb processing. Maintaining tight synchronization loops between the SPU2 and the main CPU (Emotion Engine) represents one of the architecture's complex emulation hurdles.
  • System Controllers & Security
    • MechaCon: A dedicated security microcontroller responsible for console authentication, boot security, optical disc authentication, and coordinating security features such as MagicGate memory card authentication and KELF decryption. Because portions of its operation rely on proprietary cryptographic material, complete emulation presents unique legal and technical challenges.[13][14]
    • MagicGate: Sony's authentication and encryption technology used primarily by PlayStation 2 memory cards. Community projects have implemented varying degrees of MagicGate support, although these generally require user-supplied cryptographic material dumped from original hardware. See the #DVD player and Konami Python 2 sections.
    • Syscon: A dedicated system controller responsible for power management, the real-time clock, thermal monitoring, and coordinating system startup and shutdown. Most commercial software interacts with Syscon only indirectly through the BIOS.

Graphics Synthesizer (GS) & paraLLEl-GS Solution

The Graphics Synthesizer (GS) acts completely differently from traditional graphics card architectures. Commands reach the GS through the Graphics Interface (GIF), which arbitrates multiple rendering paths and packet streams originating from the Emotion Engine and VU1. Correctly emulating GIF packet processing, state tracking, and path interactions is necessary for accurate rendering behavior. Crucial to feeding the GS is the Direct Memory Access Controller (DMAC), which routes data packets across the system bus. On real hardware, games frequently relied on massive, precisely timed bursts of data to transfer vertex textures and geometry data without stalling the processors.

Rather than utilizing a conventional fixed pipeline or complex shader cores, the GS achieved its results through raw, uncompressed fill rate power. It used a massive 2,560-bit internal data bus hooked directly to 4 MB of embedded DRAM (eDRAM), pushing an unprecedented 48 GB/s of bandwidth. This allowed developers to bypass standard hardware bottlenecks and implement intricate visual anomalies such as real-time frame buffer read-modify-write operations, which allowed for visual effects that contemporary PCs struggled to reproduce like the heat-haze distortion in Gran Turismo 3.

Translating this extreme bus width and eDRAM behavior into high-level emulation (with the GSdx renderer) using hardware APIs like DirectX, OpenGL, or Vulkan historically forced PCSX2 to rely on lots of hacks (such as offset hacks, skipdraw functions, and frame-buffer blending approximations). While PCSX2 eventually abandoned its legacy plugin architecture entirely, and internal core GS emulation has significantly improved in recent years with introducing robust solutions for notoriously difficult hardware behaviors like complex alpha blending and render-to-texture targets[15][16], some accuracy and compatibility issues remain. This ongoing reliance on game-specific hacks creates a cumbersome maintenance burden for developers and testers similar to clamping and rounding modes situation, who must constantly update and manage the database-driven compatibility database. On top of that, a notable subset of titles still strictly require a pure CPU Software Renderer to avoid game-breaking visual bugs, forcing a heavy reliance on the host CPU's single-threaded performance, significantly increasing hardware requirements while stripping away modern visual enhancement options such as high-resolution upscaling.

The introduction of paraLLEl-GS represents a major step toward addressing this fundamental issue. Similar to other low-level compute renderers for other projects, paraLLEl-GS reconstructs the GS inside Vulkan compute shaders instead of forcing it through a traditional rasterization pipeline. This approach achieves the absolute precision of a CPU software renderer while simultaneously providing upscaling, super-sampling, and high-performance execution on mainstream GPU hardware. It has been integrated directly into custom standalone builds and the LRPS2 Libretro core.[17]

CRT Output Video Quirks

Main article: Shaders, presets, and filters#6th and 7th Generation (PS2, GameCube, Xbox, Wii, Xbox_360)

The PS2 frequently leveraged standard-definition CRT video techniques to save memory or compensate for performance limits. Techniques included aggressive dithering patterns, low color depth channels, inter-field blurring (proto-FXAA), non-standard vertical resolutions and continuous interlacing. When outputted onto high-definition flat panels, these features result in noticeable pixel combing and a loss of visual characteristics of the PlayStation 2.[18] Consequently, modern emulation depends heavily on enhancement implementations like post-processing layers, advanced deinterlacing algorithms and comprehensive shader injection frameworks like `librashader` to simulate those visual characteristics. Projects like paraLLEl-GS's CRT simulation aim to natively handle most of these cleanly.[19]

For more information about PlayStation 2 hardware and its reverse engineering;

Xbox

 
The pratfalls of Xbox emulation

The Xbox is infamous in the emulation scene for being the worst case of false advertising. For the projects currently available and active, there is a high barrier to entry for the effort involved, and it is the same reason why consoles using off-the-shelf hardware (or reused hardware) are easier to emulate. To users, being "basically a PC" and "x86-based" is a selling point despite that not being the case, as the Xbox has a number of proprietary elements that are nothing like standard PC hardware (like the eighth-gen "x86-based" consoles). Many aspects of the Xbox's architecture aren't openly documented, making it a major pain to figure out.[20][21][22][23][24] For example, the APU; one of two sound processors on the MCPX southbridge chip of the Xbox chipset, is incredibly powerful and uses complex processing steps that are difficult to figure out using clean-room reverse engineering.

Original Xbox emulator development took a long time to show major results, but thanks to the Cxbx-Reloaded and xemu teams, current efforts are now making a real difference.

For more information about the Xbox system and its reverse engineering;


Xbox 360

[Xenos] was a playground for experiments — it was developed near the end of the Direct3D 9 era, but still before Direct3D 10, and contained many features not standardized or even available at all on the PC, but when they ended up on the PC, the actual implementation could be significantly different; it also included completely unique features. […] Contrarily to a common misconception, the Xbox 360 [isn't] just a “DirectX 9 box.” It essentially contains a [tile-inspired] mobile-like GPU with much more raw power than a comparable mobile GPU. If you compare the registers of the Xenos and the Qualcomm Adreno 200, you can see that most of them are the same, as they are almost the same GPUs — the Adreno 200 was called the AMD Z430 before having been acquired by Qualcomm and was even referred to as the "mini-Xenos"!"
-Triang3l[25]

Despite being one of the most popular seventh gen home console, due to requiring many resources as well as the hardware not being properly documented yet[26], Xbox 360 emulation development has unfortunately lost momentum in recent years, with updates becoming less frequent. That, plus the fact that Microsoft's own implemented official emulation (Fission) of the system through the Xbox One and Series S/X ended with a November 2021 update. Fortunately, Xenia is making slowly but surely progress on that front.

I wouldn't say that Xenia has developers, we're just a bunch of community members with enough skills to do something. […] It is easier to slowly fix the emulator than write GUI, and I personally prefer having more games working than GUI.
-Gliniak

For more information about Xbox 360 system and its reverse engineering;

PlayStation 3

PlayStation consoles were always notorious for system complexity. Sony's technology being developer-unfriendly makes it emulator-unfriendly as well, and RPCS3's steep system requirements prove it. Even if done properly, an LLE approach would be performance suicide, as some things just have to be abstracted enough to get high framerates in games.

Sony has never released an official PS3 emulator or native backwards compatibility for the PS4 or PS5. Instead, it offers select PS3 titles through cloud-based streaming on PlayStation Plus Premium. The primary technical challenge is the PS3's Cell Broadband Engine architecture, which differs significantly from the x86-64 architecture used in the PS4 and PS5 (especially considering the PS4's very weak hardware even at the time of its announcement, let alone its release). This makes accurate and performant software emulation considerably more difficult. While the PS5's hardware seems sufficient (as some independent experiments have shown some success running PS3 code through custom emulation efforts)[27][28], the prevailing narrative still falls back on the old assumption that achieving broad compatibility would just be too big of an engineering hurdle. Sony has opted for cloud streaming (which runs games on actual or virtualized PS3 hardware in data centers) rather than investing in a full native emulator for consumer devices. Additional factors likely include development and long-term maintenance costs, although these maintenance costs are often claimed by some to be a major issue when they are not actually a huge factor. Other potential reasons may stem from the difficulty in justifying the complex copyright and licensing situation for hundreds of old titles, diminishing returns for a relatively niche audience (based on Sony's experience with previous generations' backwards compatibility through PSN titles),[29][30] and potential political or investor pressure to avoid re-releasing older games that could be perceived as controversial under today's Overton window. On top of that, there is a strong monetary appetite for remakes and remasters (which often leads to poor releases, heavy censorship of the original games, and turning them into soulless re-releases aimed at younger audiences, delisting the original and unaltered versions of the game from digital storefronts) sold at full retail price instead of affordable offering emulation software. Despite these hurdles, the PlayStation 3 emulation scene (much like the Switch emulation scene) possesses two major advantages. First, unlike many proprietary "black box" systems, the Cell architecture was thoroughly documented by IBM. Furthermore, the RPCS3 project has benefited from over a decade of continuous development; since its early stages, it has maintained a dedicated donor base that provides the consistent financial support.

There are two major bottlenecks at play:

  • Cell Broadband Engine - consists of two architectures that developers have to program for; PowerPC, and... whatever the SPEs really are; and you have a great formula for high system requirements, SPU hardware environment is the furthest thing from a x86 PC processor. "Cell Broadband Engine" (i.e. the PS3 CPU) leaned into SIMD with the SPUs recklessly, ease of programming be damned, but it broke records in 2006. Four pipelines of 512-bit wide ALUs per core is an absolute bonkers amount of computational capability. The main issue is that SPU code is stored as data blobs anywhere the game shoved it into: main executable constants, resource files, generated on the fly...anything goes, and it’s impossible to extract before it is submitted to SPEs for processing (same with the RSX shaders). Another half is that a way SPU are utilised in later games is a sort of microservices with context switching and load balancing (i.e several microtasks code can be uploaded/replaced/switched into single SPE memory at runtime during one frame cycle of game logic). Like SPURS for example. Old style SPE programming from early games with fixed systems bound to specific cores and not changed since works well with static recompilation. Unfortunately, this way was suboptimal for games and developers quickly went into "microtasks" design. SPEs are closer to VUs from the PS2 than a GPU. They're a SIMD cluster, don't be fooled by their apparent similarity to GPUs. GPU are low throughput but very wide. SPEs are also wide, but not nearly as much so. However, their individual thread throughput is insane even compared to a something like an RTX 4090. It's not possible to beat SPUs 1:1 (it's ALL vector, it doesn't have scalar registers at least not general-purpose ones), they have 128 registers and very low latency SRAM, almost no memory fetches and everything is async. Although AVX-512 comes close in performance (at 5+ GHz). GPUs on the other hand are around 10-100x slower, but that's just because of how their cores are designed and the fact that SPU kernels are optimized to run in much smaller groups. There's too much working against emulation at 3.2 GHz rate since most SPU instructions need many instructions on PC (like dozens in some cases), so the PC side needs to be an order of magnitude faster.
  • RSX (Reality Synthesizer): The PlayStation 3 GPU went unemulated for a long time, simply because of how many components were undocumented; the RSX Reality Synthesizer is a custom-designed chip similar to the GeForce 7800 GTX developed by Nvidia specifically for the PlayStation 3. It's not well-documented, and developers have to figure out how it displays graphics and graphical effects. Without access to Nvidia's resources, which would normally be included with an SDK, this is very difficult.
Something of note is that this GPU was also managed by two different memory units with very disparate frequency speeds; 1) 256 MB of GDDR3 RAM clocked at 650 MHz with an effective transmission rate of 1.4 GHz, and 2) up to 224 MB of the 3.2 GHz XDR main memory via the CPU (480 MB max).

In practice, smaller devs use the PPE most of the time, but AAA use everything what PS3 had. It took an eternity for AVX-512 to arrive, with Intel releasing their first implementation only in 2016; but wide availability in consumer grade PCs only started with AMD's Ryzen 7000 series in late 2022. Fortunately, most of the optimizations in RPCS3 still apply for AVX2, e.g., the 512bit checksum is still much faster than a full comparison, and the LTO, rotated checksum, and the other optimizations added also apply for machines without AVX-512. The RPCS3 developers use ahead-of-time recompilation via an LLVM. RPCS3 is not just compiling the code it runs, it also needs to compile a real-time environment simulator e.g. the 128x128bit register file, LS SRAM, the very weird memory flow controller, etc.

For more information about PlayStation 3 hardware and its reverse engineering;

Xbox One

With the Xbox One, Microsoft had two important security goals in mind, to prevent piracy and cheating (these can be seen in the their   "Guarding Against Physical Attacks" video. To achieve this, much of the hardware was modified to prevent tampering. On the software side, the Xbox One used a new XVD (Xbox Virtual Drive) format to store its operating systems, SystemOS (runs a cut-down version of Windows), HostOS (manages the other two) and GameOS (runs game titles). For the storing of Xbox One titles, the console used another format (XVCs or Xbox Virtual Containers) to store games on Blu-ray discs. With all this security, it became a challenge to homebrew the console. For technical Xbox One research, see the Xbox One Research Wiki.

At least part of the Xbox One's optical disc drive source code leaked in 2020 ("Damien's XDK leak", "XSec", "xsec.rar" leak). Damien confirmed this came from wack0's 2017 Microsoft hack. It is impressive how long the Xbox One held up compared to literally any other console in history. However, on May 15, 2024, baw released an Xbox One dumping exploit. This was used to dump games when Collateral Damage came out. Now, Xbox One games have been dumped and decrypted.[4][5]

It should also be noted that the vast majority of Xbox One games are also available on PC (similarly to PlayStation 4 (Pro), PlayStation 5 (Pro) and Xbox Series X|S situations in recent years), so there is increased lack of interest to emulate the console. Having said that, there are still a considerable number of games exclusive to those consoles, this includes games for both PlayStation 4 (Pro) and Xbox One (X|S) that haven't been ported and titles lacking enhanced/next-gen update for PC. See List of notable ports#Console multi-platform exclusives section for all of those games.

Running UWP apps without emulation

By going to X:\ and copying app files, users could dump a range of system packages such as the Xbox One version of the Microsoft Store. To run these apps, all a user needed to do was to change the application's information file, or AppXManifest from Windows.Xbox to say, Windows.Desktop as well as removing Xbox only parts of the manifest, and certain applications would run, but issues would occur, such as a lack of input. The same dumping methods don't work for important system packages or games, as they're placed in a more secure location and need compatibility layers to run.

For more information about Xbox One (X|S) system and its reverse engineering;

PS4

Due to the PS4's x86 architecture and FreeBSD-based operating system, emulators for the device will, by and large, be very unconventional. Despite the x86's instruction set being huge[31], a trait that would typically lead to years of development time by emulators, it opens the ability for hypervisor to do the heavy lifting, eliminating the need for a recompiler. In recent years many PlayStation 4 (Pro)-exclusive titles are now being ported to PC with enhancements, so similarly to PlayStation 5, Xbox One (X|S) and Xbox Series X|S situations this could lead to a decreased interest in development. Having said that, there are still considerable amount of games exclusive to those consoles, this includes games for both PlayStation 4 (Pro) and Xbox One (X|S) that haven't been ported and titles lacking enhanced/next-gen update for PC. See List of notable ports#Console multi-platform exclusives section for all of those games.

Reverse-engineering PlayStation 4

See these resources for reverse-engineering PlayStation 4[32];

General
Graphics
Reversing
PlayStation 4-specific
CPU
GPU
Misc.

Xbox Series X/S

It should be noted that the vast majority of Xbox Series X|S games are also available on PC with ports of usually high quality (similarly to Xbox One and even PS4 and PS5 due to Sony's enduring will to port PlayStation exclusives to PC), so there is a greater lack of interest in emulating 8th and 9th-gen Xbox, especially compared to consoles with a rich backlog of exclusives such as the PS3 or Switch. Having said that, there are still a considerable number of games exclusive to modern consoles, this includes games for both PS5 and Series X|S that haven't been ported and titles (such as Devil May Cry 5, Dragon Ball Z: Kakarot, and some sports games) lacking next-gen versions for PC. See List of notable ports#Console multi-platform exclusives for more information.

Similar OS structure

Since the Xbox Series family uses the same operating system as the Xbox One, there is considerable intersection between Xbox One and Xbox Series X|S development and their reverse engineering. The Xbox One Research GitHub has a few interesting articles for the Xbox Series consoles.

For more information about the Xbox Series X|S system and its reverse engineering;

PS5

On top of PlayStation 4 emulation issues, there are additional obstacles for PlayStation 5 emulation such as Kraken, different custom APIs compared to prior generation and different GPU drivers to reverse-engineer all over again. As of this time, the PS5's APU can now be found as the AMD BC-250, which gives direct confirmation that the Playstation 5 uses a hybrid GPU, "Cyan Skillfish"/gfx1013 with no support for certain machine learning operations and with some desktop RDNA 2 features cut out such as Variable Rate Shading. Otherwise, it supports most RDNA 2 features and enhancements over RDNA 1. This does not mean the AMD BC-250 itself can help PS5 emulator development in any way.

In recent years many PlayStation 5 exclusive titles are now being ported to PC with enhancements, so similarly to PlayStation 4 (Pro), Xbox One (X|S) and Xbox Series X|S situations this could lead to a decreased interest in development. Having said that, there are still considerable amount of games exclusive to those consoles, this includes games for both PlayStation 5 and Xbox Series X|S that haven't been ported such as Astro Bot and Ghost of Yotei and titles lacking enhanced/next-gen update for PC See List of notable ports#Console multi-platform exclusives section for all of those games.

Reverse-engineering PlayStation 5

See these resources for reverse-engineering PlayStation 5;

General
Graphics
Reversing
PlayStation 5-specific
CPU
  • N/A
GPU
  • N/A
Misc

Nintendo Entertainment System

QD FDS support

Games dumped off the Famicom Disk System come into two major types:

  • .fds format: Most common format. Ubiquitous in ROM sets (GoodSets, No-Intro). Omits some checksum data.
  • .qd format (stands for QuickDisk): Only ever used in official Nintendo re-releases. Almost identical to FDS, except QD is a full dump with checksum data. May omit padding.

The checksum data in question would be checked at BIOS startup to verify the integrity of the image and whether it was tampered with, in which case it will throw an anti-piracy error. puNES added QD support in v0.111. As of now, no other NES emulators support the alternate, more complete dumps and fudging that check's result to always return a negative. To emulate a .qd image with those, stripping the checksum data with a custom script is needed.

Overscan

Main article: Overscan
 
Example of faulty visuals that are exposed when no overscan is cropped. Note the blank blue area to the left and the green garbage on the right. On NTSC CRT TVs, these areas may or may not be visible

Several NES games need their overscan to be cropped to look proper. Unfortunately, there is no standard level of overcropping. Many games require different levels for the best results. For example, Super Mario Bros. 3 requires quite a bit of cropping. However, the same level of cropping will obscure the letters of the status bar in Castlevania games.

Color palette

Main article: Famicom color palette

Unlike consoles such as the SNES, which natively generate their image in pure RGB, the Famicom normally generates and outputs an encoded NTSC video signal. This must then be decoded by the TV's built-in NTSC decoder, which means the resulting color palette often varies depending on the display's decoder. For this reason, NES games will appear to have different colors on different TV sets. To properly emulate this part of the NES experience, many Famicom emulators have a variety of different palettes to choose from.

The Wii and Wii U versions of Virtual Console use extremely dark color palettes. This is apparently not an accuracy issue, but rather an anti-epilepsy measure. For the Nintendo Switch Online service, the games were directly edited to remove seizure-inducing patterns, allowing it to use a normal palette.

Nintendo 64

Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.

High-level vs. low-level graphics

One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get higher performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from the PC graphics cards of the day. To complicate matters further, API standards available on PCs two decades ago were nowhere near as flexible as they're today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.

UltraHLE offered a compromise. In contrast to earlier consoles (whose video chips, in hindsight, had been easy to render to the host CPU's framebuffer), performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, and the host graphics card could reproduce a functional equivalent rather than the exact method. This also gave way to prettier, higher-resolution graphics, though whether this is an improvement is subjective and a common point of discussion. Unfortunately, it proved to be hit or miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.

Low-level RDP emulation was continually improved in that time, most notably by MESS up until its merger with MAME, where its RDP code was turned into a plugin by Angrylion. Compatibility-wise, Angrylion's RDP was considered flawless by the community. Though the reception wasn't as warm overall, since it ran only on the CPU and was thus painfully slow on mid-grade machines. A dozen forks attempted to bring the system requirements down, and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation would only come to the GPU in 2020 when a new version of the Mupen64Plus-based ParaLLEl libretro core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Though it isn't a direct fork of Angrylion, Themaister says the Angrylion code was the central point of reference for developing the plugin,[33] meaning ParaLLEl uses the same strategies that Angrylion does to emulate the RDP while running on the host GPU (as long as said GPU supports Vulkan).

On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling throughout 2016-2018.[34][35] This means that   Factor 5's games are now working in high-level graphics mode.[36][37] Other games may still have issues with RDP quirks like frame buffer/depth buffer access (including issues with how the framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).

  •  
    Low-level emulation of Majora's Mask using SoftGraphic
  •  
    High-level emulation of Majora's Mask using Jabo's Direct3D

Texture filtering

The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than they would on real hardware.

Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images, such as pre-rendered backgrounds or menu screens, may look as though they're separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). Some plugins allow the user to turn off texture filtering to remedy this, but, unfortunately, this also applies to textures in the game world, exposing their often low resolutions.

Modern emulators and plugins have taken some steps that help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It can also render at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP don't have these problems at all.

  •  
    Conker's Bad Fur Day copyright screen displaying issues with filtered text.
  •  
    Ocarina of Time's menu subscreen displaying issues with filtering.

Timing issues

One of the biggest remaining problems in N64 emulation is the lack of accurate core timings, which, in practice, means games don't always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree. In some instances (particularly in Rare games) this can actually result in fewer framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not emulating them properly can result in considerable to major issues. Some notable examples include the following:

  • Intros and cutscenes playing too fast and not correctly syncing up with musical cues. Seen in GoldenEye's intro and Body Harvest's beginning cutscene.
  • Gameplay demos running at hyper speeds. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.
  • Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.
  • Possibly the most affected game is Knife's Edge, which runs like it is on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.
Fortunately, tackling these problems has recently become a core focus of development in some N64 emulators, and attempts are underway to improve the situation. ares currently has the most accurate timings overall and already runs Earthworm Jim 3D's demos much better than other emulators. Meanwhile, simple64 has recently pushed various timing-related commits aimed at improving accuracy, and as a result, it may now be the only emulator that runs Donkey Kong 64 properly. As these efforts progress, it should be noted that a side effect of improved timings may be greater in-game lag. This shouldn't be seen as the emulator becoming slower, but rather as the emulator behaving exactly like the real hardware does, as many N64 games were notorious for framerate drops.

For more information about Nintendo 64 hardware and its reverse engineering;

Nintendo GameCube and Wii

For more information about Nintendo GameCube hardware and its reverse engineering;

For more information about Nintendo Wii hardware and its reverse engineering;

See also

  1. ↑ https://github.com/xemu-project/xemu/blob/master/target/i386/ops_sse.h
    https://github.com/xemu-project/xemu/tree/master/hw/xbox/nv2a
    https://github.com/xemu-project/xemu/blob/master/hw/xbox/xbox_pci.c#L47
  2. ↑ Plugin info, news. / Information about the plugin, news. (gpuBladeSoft discussion). forum.emu-russia (2011-09-16)
  3. ↑ Playstation 1 does not have z-buffer and floating points, yet how could it play 3D games?
  4. ↑ List of PlayStation games with CD-DA (From deprecated Wikipedia article - dated 11/27/2016)
  5. ↑ ECM And APE Guide. www.epforums.org (2011-Feb-16; Last edited: 2017-Jan-15)
  6. ↑ https://forums.pcsx2.net/Thread-Why-is-PCSX2-slow
  7. ↑ https://wiki.pcsx2.net/PCSX2_Documentation/Nightmare_on_Floating-Point_Street
  8. ↑ https://github.com/PSI-Rockin/DobieStation/issues/51
  9. ↑ https://github.com/PCSX2/pcsx2/issues/2990
  10. ↑ https://github.com/PCSX2/pcsx2/issues/5137
  11. ↑ https://pcsx2.net/blog/2025/pcsx2-2.4_2.2/#dev9-fixes
  12. ↑ https://pcsx2.net/blog/2023/q1-2022-progress-report#dev9
  13. ↑ https://github.com/PCSX2/pcsx2/pull/4274#issuecomment-795316629
  14. ↑ https://github.com/PCSX2/pcsx2/pull/10836#issuecomment-1954866179
  15. ↑ https://pcsx2.net/blog/2021/q3-2021-progress-report#gs-improvements https://pcsx2.net/blog/2022/q4-2021-progress-report#gs-improvements https://pcsx2.net/blog/2023/q1-2022-progress-report#gs-improvements https://pcsx2.net/blog/2025/pcsx2-2.4_2.2/#will-it-blend https://pcsx2.net/blog/2025/pcsx2-2.4_2.2/#rt-in-rt-support https://github.com/PCSX2/pcsx2/pull/13795 https://github.com/PCSX2/pcsx2/pull/13681 https://github.com/PCSX2/pcsx2/pull/13792 https://github.com/PCSX2/pcsx2/pull/13754 https://github.com/PCSX2/pcsx2/pull/13854 https://github.com/PCSX2/pcsx2/pull/13923
  16. ↑ https://pcsx2.net/blog/tags/progress-report/
  17. ↑ https://themaister.net/blog/2024/07/03/playstation-2-gs-emulation-the-final-frontier-of-vulkan-compute-emulation/
  18. ↑ https://www.libretro.com/index.php/playstation2-and-the-crt-tv/
  19. ↑ https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/
  20. ↑ Why is XBOX emulation premature?. ngemu (2010-02-15)
  21. ↑ /LTCG (Link-time Code Generation). Microsoft
  22. ↑ Under The Hood: Link-time Code Generation. Microsoft
  23. ↑   Xbox Emulation: The History & Roadblocks
  24. ↑ Why is there a lack of Original Xbox emulation?. Reddit (2017-05-29)
  25. ↑ Triang3l (April 27, 2021). Leaving No Pixel Behind: New Render Target Cache, 3x3 Resolution Scaling & Three Years in Xenia’s GPU Emulation. Xenia.
  26. ↑ Building an Xbox 360 Emulator
  27. ↑   I Ran PS3 Games on PS5 Silicon to Prove Sony Wrong
  28. ↑ PS3 Emulation Tested on PS5 under Linux with RPCS3
  29. ↑   Why PS4 Doesn't Have Backwards Compatibility and Xbox One Does
  30. ↑   MVG: Sony's complicated history with Backwards Compatibility
  31. ↑ x86 instruction listings
  32. ↑ RPCSX discord channel: Various resources for reverse-engineering PlayStation 4.
  33. ↑ README for parallel-rdp repository on GitHub. § Disclaimer. "While paraLLEl-RDP uses Angrylion-Plus as an implementation reference, it is not a port, and not a derived codebase of said project. It is written from scratch by studying Angrylion-Plus and trying to understand what is going on. The test suite uses Angrylion-Plus as a reference to validate implementation and cross-checking behavior."
  34. ↑ Public Release 3.0. Blogspot (2017-12-29)
  35. ↑ Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer). GitHub (2018-02-10)
  36. ↑ "Indiana J. & Infernal Machine" HLE. Indiegogo (2018-05-17)
  37. ↑ HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.. Blogspot (2018-05-26)
Retrieved from "https://emulation.gametechwiki.com/index.php?title=Emulation_issues_and_roadblocks&oldid=145966"