Emulation issues and roadblocks: Difference between revisions

(48 intermediate revisions by one other user not shown)

Line 8:

: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.

*[[Gizmondo emulators|Gizmondo]]

*[[IPod ~~Classic~~ emulators|Apple iPod]]

*[[IPod emulators|Apple iPod]]

*[[IOS_emulators|Apple iOS]]

*[[PlayStation Mobile]]

Line 32:

*[[Official emulators]]

=Home Computers=

==Windows XP==

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 [[Emulation accuracy|cycle-accurate]] implementation of an entire [[Windows NT 5.x emulators|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.

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 [[Emulation accuracy|cycle-accurate]] implementation of an entire 2001-2006 [[Windows NT 5.x emulators|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 [[wikipedia:Hardware_virtualization#Hardware-assisted_virtualization|hardware-assisted virtualization]] (such as [[Hypervisors#Type 1 hypervisors|KVM]] or [[Hypervisors#Hyper-V Subsets|WHPX]]) or [[High and low-level emulation#Modern Dependencies.2C Advancements and Optimization Strategies|dynamic binary translation]] (DBT). Hardware-assisted virtualization executes guest code directly on the host processor and therefore [[Hypervisors#Performance impact|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 [[Windows NT 5.x emulators#Other solutions|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 [https://github.com/JHRobotics/softgpu SoftGPU], [https://github.com/iXit/wine-nine-standalone Gallium Nine], and experimental [https://github.com/virtio-win/kvm-guest-drivers-windows/pull/943 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.

But unlike a typical console emulator, a Windows XP emulator could target 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 substantially lower than native execution on modern processors; many games and applications released during this period were designed to run on hardware comparable to a 32-bit Intel Pentium 4 "Prescott" CPU with SSE3 support.<ref>While the Prescott microarchitecture was designed with Intel 64 capabilities, the initial desktop models shipped with 64-bit support disabled. Consequently, these early variants do not qualify as x86-64-v1 processors and function strictly as 32-bit x86 processors with SSE3 support. Intel later enabled 64-bit support in subsequent Prescott revisions, such as the 5xxF and 6xx series.</ref> Consequently, the software emulator only needs to match this legacy performance while minimizing translation overhead. The most significant remaining technical hurdle for the 2001–2006 era is efficient 3D graphics acceleration; a DirectX 9.0c Shader Model 3.0 GPU would be the perfect target to run the vast majority of software from this generation. While projects such as [[Windows NT 5.x emulators#Other solutions|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 [https://github.com/JHRobotics/softgpu SoftGPU], [https://github.com/iXit/wine-nine-standalone Gallium Nine], and experimental [https://github.com/virtio-win/kvm-guest-drivers-windows/pull/943 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 ===

Line 48:

Line 49:

* '''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.

<pre>

+───────────────────────────────────────────────────────────────────────────+

Line 83:

Line 85:

+───────────────────────────────────────────────────────────────────────────+

</pre>

</div>

=== Approach 2: Paravirtualized GPU Device ===

Line 89:

Line 92:

* '''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 <code>d3d8.dll</code> or <code>d3d9.dll</code>) 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.

* '''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, low-level explicit graphics API backend such as Vulkan. Unlike application-level wrapper projects, the renderer operates entirely within the emulator rather than inside the guest operating system.

<pre>

+───────────────────────────────────────────────────────────────────────────+

Line 108:

Line 112:

▼

=================================

SHARED MEMORY COMMAND QUEUE

=================================

│

▼

+─────────────────────────────────┴─────────────────────────────────────────+

+───────────────────────────────────────────────────────────────────────────+

| HOST OS / EMULATOR |

| |

Line 120:

Line 124:

| [ Virtual GPU Command Decoder ] |

| │ |

| ▼ |

| ▼ (Unified Internal Rendering Representation) |

| [ Virtual GPU Renderer ] |

| │ |

| ▼ |

| ▼ (Shader Translation / Backend Interface) |

| [ Vulkan / ~~OpenGL~~ Backend ] |

| [ Vulkan / Direct3D 12 / Metal Backend ] |

| │ |

| ▼ |

Line 130:

Line 134:

+───────────────────────────────────────────────────────────────────────────+

</pre>

</div>

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.

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. 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.

Since rendering is performed entirely on the host GPU, completed frames generally do not need to be copied back into the guest frame buffer unless required for compatibility (such as guest software that reads the front buffer directly). Instead, the emulator presents the rendered output directly within its own display window while maintaining the guest-visible synchronization state. Consequently, the primary challenge is implementation complexity rather than raw GPU performance. A complete virtual graphics device must faithfully virtualize Direct3D state management, resource creation, explicit synchronization primitives, presentation, capability reporting, shader handling, and device-loss behavior so that Windows and its applications observe behavior consistent with physical hardware. To manage this complexity across multiple host operating system ecosystems (beyond just Windows machines), a modern implementation could rely on a unified internal rendering architecture. Under this approach, the virtual GPU command stream is decoded into an implementation-defined rendering representation describing pipeline state, resources, synchronization primitives, and draw commands independently of any particular host graphics API. Shader programs are translated separately into an appropriate intermediate representation for the selected backend, such as SPIR-V for Vulkan, or into DXIL or Metal Shading Language (MSL) for Direct3D 12 and Metal. This separation allows the same rendering architecture to target multiple host APIs while minimizing duplicated implementation effort. Legacy fixed-function features such as table fog or texture combiners that no longer exist on modern programmable GPUs can be reconstructed through generated shader programs or specialized rendering passes rather than game-specific compatibility hacks. Likewise, legacy implicit synchronization semantics can be mapped onto modern explicit primitives such as timeline semaphores and fine-grained synchronization barriers provided by contemporary graphics APIs.

~~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.

* '''Pristine Guest Environment:''' The original Microsoft graphics runtime remains entirely untouched, avoiding error-prone per-game DLL replacement, manual system tweaks, and compatibility hacks.

* Graphics virtualization occurs at the device-driver level, allowing all applications to use the same rendering ~~pipeline~~ automatically.

* '''Universal Virtual Pipeline:''' Graphics virtualization occurs at the device-driver level, allowing all legacy software, system components, and multimedia applications to use the exact same accelerated rendering infrastructure 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~~.

* '''Architectural Hardware Abstraction:''' The virtual GPU provides a stable, modern hardware abstraction for the guest while the emulator translates its command stream directly into explicit APIs, eliminating the need to emulate obsolete register-level structures or specific physical GPU architectures.

* Shared-memory command transport minimizes ~~synchronization~~ overhead ~~compared to frequent~~ VM exits or ~~hypercalls~~.

* '''Low-Overhead Command Flow:''' Shared-memory command transport paired with modern explicit timeline synchronization minimizes host-guest messaging overhead and prevents VM exits or hypercall stalls.

* Rendering logic ~~resides~~ entirely within the emulator, ~~resulting in~~ a ~~more centralized~~ and maintainable ~~graphics architecture~~.

* '''Centralized Rendering Architecture:''' All translation logic, shader recompilation pipelines, and backward-compatible fixed-function approximations reside entirely within the host-side emulator engine, creating a highly organized, modular, and maintainable subsystem.

For more information about PC emulation and their reverse engineering;

Line 172:

Line 175:

* [[Compatibility layers]]

* [[Windows NT 5.x emulators#Hypervisors|Hypervisor's Virtual GPU Adapters for legacy operating systems]]

* [https://github.com/libcdio/libcdio libcdio], [https://github.com/polpo/picogus picogus], Duckstation's [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_ccd.cpp cd image ccd], [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_cue.cpp cd image cue], [[Ymir]]'s [https://github.com/StrikerX3/Ymir/tree/main/libs/ymir-core/src/ymir/hw/cdblock low-level cd block] and [https://github.com/PCSX2/pcsx2/tree/master/pcsx2/CDVD PCSX2's CDVD] - Could be beneficial for implementing reading capability for [[Ripping games#Disc-based|capable disc image formats]].

* [https://github.com/libcdio/libcdio libcdio], [https://github.com/polpo/picogus picogus], Duckstation's [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_ccd.cpp cd image ccd], [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_cue.cpp cd image cue], [[86Box]]' [https://github.com/86Box/86Box/pull/7424 aaru support], [[Ymir]]'s [https://github.com/StrikerX3/Ymir/tree/main/libs/ymir-core/src/ymir/hw/cdblock low-level cd block] and [https://github.com/PCSX2/pcsx2/tree/master/pcsx2/CDVD PCSX2's CDVD] - Could be beneficial for implementing reading capability for [[Ripping games#Disc-based|capable disc image formats]].

* [https://github.com/aaronsgiles/ymfm ymfm]

==Mac OS X and macOS==

===PowerPC===

Currently, no 3rd-party Macintosh emulators support hardware graphics acceleration, due to [https://www.emaculation.com/forum/viewtopic.php?t=8396 certain CPU instructions left unimplemented in their upstream PPC softcores]. This means no GLIDE, RAVE, or OpenGL. Fortunately, though as was generally the case in every platform of the period significant visual and feature differences exist between the two, the majority of Mac-exclusive software using these APIs also included software fallback renderers. It is however possible to pass through a real GPU to a PowerPC Mac being emulated by QEMU provided you have one that's compatible with OpenFirmware

===x86===

Despite an x86-based Mac is very similar to a general non-Apple PC in hardware architecture (which makes [[wikipedia:/Boot_Camp_(software)|Boot Camp]] and [[wikipedia:Hackintosh|Hackintosh]] possible), it still contains Apple proprietary hardware such as closed-source EFI BootROM, System Management Controller (SMC) and later T1/T2 security chip that either requires bypassing or emulation in order to run macOS. macOS also contains countermeasures that prevent it from being run on a non-Apple PC such as the infamous [https://www.tonymacx86.com/threads/dont-steal-mac-os-x-kext.51175/ Don't Steal Mac OS X.kext].

Another big hurdle is that macOS only contains drivers for hardware components used in actual Mac computers, which means a large portion of PC users who use different hardware combinations than actual Mac computers need to bypass, patch, or port drivers for their hardware in order to boot macOS and promote it to a usable state, and might still with crippled functionalities due to no or imperfect solutions to drive some of the hardware.

===ARM===

Hurdles in emulating ARM-based Mac are basically the same as emulating iOS devices: Apple's proprietary M1/M2 SoC which has little to no documentation, and hardened security measures inherited from iOS devices. However if Apple discontinues support for x86 in XCode, there will be no way to code modern iOS apps on other platforms or use macOS apps in general. If an ARM macOS emulator is sucessful, modern iOS emulation will be "cracked" too (apart from Corellium though).

=Home Consoles=

==Pioneer LaserActive==

The LaserActive Project wishes to document all LaserActive media. On their FAQ page, they have this to say about the possibility of creating a LaserActive emulator:

<blockquote>Emulation of the LaserActive, if attempted at all, would be an incredibly difficult task – due to the hybrid nature of the system's hardware (utilizing Sega/NEC hardware in synchronization with the unique LD player hardware) and the analog-digital composite image (analog video background, digital in-game graphics generated by said Sega/NEC hardware).<ref>https://laseractive.wordpress.com/faq/</ref></blockquote>

Emulator developer Nemesis has made an effort to dump [https://segaretro.org/LaserActive#List_of_games the games for the system] (except for porn games).<ref name="Nemesis">https://gendev.spritesmind.net/forum/viewtopic.php?t=1647&postdays=0&postorder=asc&start=0</ref> Copies of the games sent to him were supposed to be dumped and then returned.<ref name="Nemesis"/>

[[ares]] has made the most significant progress to date, featuring active support for a majority of the LaserActive's [[LaserActive#PACs|expansion PACs]].

==Philips CD-i==

The accurate emulation of the Philips CD-i (Compact Disc Interactive) system presents several significant challenges for developers. These complexities have historically limited the availability and completeness of CD-i emulators. The primary difficulties can be categorized as follows:

*Limited Demand: Compared to highly popular gaming consoles and computer systems (such as the NES, SNES, PlayStation series, or Xbox series), the demand for a fully functional CD-i emulator is relatively low. This lower interest translates into a smaller pool of developers willing to invest the substantial time and effort required for such a complex project.

*Hardware Proliferation and Variation: The CD-i platform saw a wide array of hardware releases. There are at least 32 known distinct CD-i player models, many of which underwent major internal revisions. Nearly every model featured some degree of hardware difference. These variations ranged from minor (e.g., the Philips CD-i 550 model essentially being a CD-i 450 with a pre-installed Digital Video Cartridge) to complete mainboard overhauls (e.g., the CD-i 220 model is known to have at least five revisions, each with a different mainboard). Compounding this, a diverse range of peripherals was available for CD-i players. Consequently, for an emulator to be considered "fully functional," it would ideally need to accurately replicate the behavior of every known player model and peripheral.

*Scarcity of Technical Documentation: While foundational aspects of the CD-i standard and its players are understood – such as their common reliance on the Philips SCC68070 CPU (a specialized variant of the Motorola 68000) or its derivatives (like the MC68341 Integrated CD-i Engine), and the identification of many common support chips – detailed public documentation for critical components is scarce. CD-i players utilized numerous custom integrated circuits (ICs) that were often exclusive to the platform. The lack of public datasheets and technical information for these custom chips means that emulating their precise behavior often requires extensive and time-consuming reverse-engineering. The development of CD-i Emu, currently the most feature-complete CD-i emulator, exemplifies this challenge. Its developer, known as CDiFan, has made a significant personal investment of time, financial resources, and effort over nearly two decades. This includes amassing an extensive personal collection of CD-i hardware and software, which has reportedly been instrumental in the complex reverse-engineering process necessary to understand the functions of various player components. The developer has stated that CD-i Emu represents over 120,000 lines of hand-written code. This substantial individual effort highlights the barrier posed by the lack of public documentation. A core aspect of CD-i operation that influences emulation is that the entire player hardware must be simulated, not just the software environment for a game or application. This includes the player's boot sequence into its operating system shell (the menu). Therefore, emulators require a ROM image (firmware dump) from an original CD-i player to function, even for running "base-case" titles that do not require specialized add-on hardware. Further complicating emulation efforts is the optional [[CD-i_emulators#Digital_Video_Cartridge|Digital Video Cartridge (DVC)]]. The DVC provided two main benefits: an additional 1.5 MB of RAM and, more significantly, the hardware capabilities for decoding and playing back MPEG-1 video. This video processing was handled by yet more custom chips, which also suffer from a lack of comprehensive public documentation. The DVC contains its own ROM, distinct from the player's main ROM, which is necessary for emulating titles that utilize its FMV/video playback features (including [[Home_media_players#Emulators_that_support_multimedia_capabilities_of_the_system|CD-i Digital Video and VCD support]]).

As of early 2025, DVC MPEG-1 emulation support is largely in a proof-of-concept stage and is primarily, if not exclusively, found in CD-i Emu. Other emulators generally do not yet offer DVC functionality.

A notable consideration in the CD-i emulation landscape is that the source code for CD-i Emu is not publicly available. While this is the prerogative of the author, it means that prospective contributors to CD-i emulation who wish to build upon existing advanced work may be unable to do so directly with this codebase. Instead, new efforts often necessitate starting an emulation project from the ground up. The significant undertaking of managing an open-source project, particularly for a developer working largely solo as a hobby, is a factor in such decisions. Furthermore, the pool of developers possessing both the requisite skills and the specific interest in CD-i emulation may be inherently limited, potentially mitigating the impact of a closed-source approach on overall development velocity within the niche. The developer of CD-i Emu offers a full version of the emulator for a fee, a decision understandable in light of the extensive, long-term personal investment involved in its creation.

Despite these hurdles, progress in CD-i emulation continues, albeit concentrated. [[MiSTer|CDi_MiSTer core]] and the developer of CD-i Emu is actively working on improving the emulator.

==PlayStation==

Line 223:

Line 260:

* [https://psx-spx.consoledev.net/ psx-spx.consoledev.net]

* [https://problemkaputt.de/psxspx-contents.htm no$psx: Playstation Specifications]

==Sega Saturn==

:''This section was copied from Wikipedia in 2014. For an up-to-date explanation, see [[wikipedia:Sega Saturn#Technical specifications|Sega Saturn § Technical specifications]]''

The complexity of the system has made the creation of a proper emulator for it rather difficult.

<blockquote>One very fast central processor would be preferable. I don't think all programmers have the ability to program two CPUs — most can only get about one-and-a-half times the speed you can get from one SH-2. I think that only 1 in 100 programmers are good enough to get this kind of speed [nearly double] out of the Saturn. "Yu Suzuki reflecting upon Saturn's ''Virtua Fighter'' development<ref name="YuSuzukiNG">Next Generation (magazine) issue 2, 1995</ref>.</blockquote>

The Saturn had technically impressive hardware at the time of its release, but its complex design, with two CPUs and six other processors, made harnessing this power difficult for developers accustomed to conventional programming. The biggest disadvantage was that both CPUs shared the same bus and were unable to access system memory at the same time. Making full use of the 4 kB of cache memory in each CPU was critical to maintaining performance. One example of how the Saturn was utilized was with ''Virtua Fighter''<nowiki>'</nowiki>s use of one CPU for each character<ref name=YuSuzukiNG/>. Many of the Saturn's developers, such as Lobotomy Software programmer Ezra Dreisbach, found it difficult to develop for compared to the PlayStation because of its more complex graphics hardware<ref name=DreisbachCG>{{cite web|title=Interview: Ezra Dreisbach |publisher=Curmudgeon Gamer |date=July 9, 2002|url=http://curmudgeongamer.com/article.php?story=20021008212903265 |accessdate=July 19, 2007|archiveurl = http://web.archive.org/web/20070927211250/http://curmudgeongamer.com/article.php?story=20021008212903265  |archivedate = September 27, 2007}}</ref>. In order to port ''Duke Nukem 3D'' and ''PowerSlave'' to the Saturn, Lobotomy Software had to almost entirely rewrite the Build engine to take advantage of the Saturn's unconventional hardware<ref name=DreisbachCG/>. Third-party development was initially hindered by the lack of useful software libraries and development tools, requiring developers to write in assembly language to achieve good performance. During early Saturn development, programming in assembly could offer a two to fivefold speed increase over C language<ref name=YuSuzukiNG/>. Sega responded to these criticisms by writing new graphics libraries which were claimed to help make development easier<ref name="NextGenDec95">''So many 32-Bit Systems To Choose From'' Next Generation (magazine) issue 12, 1995</ref>. These libraries were presented as a new operating system by Sega of Japan<ref name="NextGenDec95"/>.

Unlike the PlayStation and Nintendo 64 which used triangles as their basic geometric primitive, the Saturn rendered quadrilaterals with forward texture mapping. This proved to be a hindrance because most of the industry's standard design tools were based on triangles, with independent texture UV coordinates specified per vertex. One of the challenges brought forth by quadrilateral-based rendering was problems with textured surfaces containing triangles. To make a triangular-shaped object, rendering had a fourth side with a length of zero. This technique proved problematic as it caused texture distortion and required careful reworking to achieve the desired appearance—Sega provided tools for remapping textures from UV space into rectangular tiles. These complications can be seen in the Saturn version of ''Tomb Raider''<ref name=DreisbachCG/>.

For more information about Sega Saturn hardware and its reverse engineering;

* [https://www.copetti.org/writings/consoles/sega-saturn/ Rodrigo Copetti: Sega Saturn Architecture analysis]

* {{YouTubeVideo|ODJl6U1lp_Q|MVG: How the SEGA Saturn CD Security was defeated}}

* [https://www.psdevwiki.com/ps4/Sega_Saturn_Emulation PSDevWiki: PS4's Sega Saturn Emulation]

* {{YouTubeVideo|jChtlWNIAL4|LGR: Oddware - Diamond Edge 3D (nVidia NV1+Sega Saturn Ports)}}

* [https://www.yabasanshiro.com/blog/2026-05-31_new_vdp2_emulation yabasanshiro blog: new vdp2 emulation]

==Sega Dreamcast==

Developer interest in Dreamcast emulation was previously hindered by the availability of the closed-source but "good enough" Chankast, and by less interest in the console relative to other 6th generation consoles. For the emulators that are either mature or maturing, a very large percentage of games work well, but some games still have problems and glitches.

For more information about Dreamcast hardware and its reverse engineering;

* MVG: {{YouTubeVideo|rj56VU_VmWg|How the Sega Dreamcast Copy Protection Worked - And how it Failed}}, {{YouTubeVideo|rN0vEa8Y4J4|The Sega Dreamcast 20 years later 9-9-99}}, {{YouTubeVideo|NMDpPRGuaq8|The Arcade Sega Dreamcast - Revisiting the Sega Naomi Arcade Hardware}}, {{YouTubeVideo|QKHSlBi5qok|What happened to Windows CE on the SEGA Dreamcast?}}

* [https://www.copetti.org/writings/consoles/dreamcast/ Rodrigo Copetti's Dreamcast Architecture Practical Analysis], {{YouTubeVideo|lWGiHgTdLBc|The Original Xbox is the Sega Dreamcast 2?}}

==PlayStation 2==

Line 257:

Line 319:

** '''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.

** '''[https://www.psdevwiki.com/ps2/DEV9C 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.<ref>https://pcsx2.net/blog/2025/pcsx2-2.4_2.2/#dev9-fixes</ref><ref>https://pcsx2.net/blog/2023/q1-2022-progress-report#dev9</ref>

** '''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.

** '''[[Disc_Drive_emulation#DVD|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.

::{| class="wikitable"

Line 283:

Line 345:

* '''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.<ref>https://github.com/PCSX2/pcsx2/pull/4274#issuecomment-795316629</ref><ref>https://github.com/PCSX2/pcsx2/pull/10836#issuecomment-1954866179</ref>

** '''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 [[#Arcade hardware variants|Konami Python 2]] sections.

** '''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 [[Disc_Drive_emulation#DVD|PS2's DVD player]] and [[PlayStation_2_emulators#Arcade hardware variants|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.

Line 297:

Line 359:

===CRT Output Video Quirks===

{{Main|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 [[deinterlacing|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.<ref>https://www.libretro.com/index.php/playstation2-and-the-crt-tv/</ref> Consequently, modern emulation depends heavily on ~~[[#Enhancements|~~enhancement implementations]] like post-processing layers, advanced [[deinterlacing]] algorithms and comprehensive shader injection frameworks like `[[Future_of_CRT_simulation#Librashader|librashader]]` to simulate those visual characteristics. Projects like paraLLEl-GS's CRT simulation aim to natively handle most of these cleanly.<ref>https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/</ref>

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 [[deinterlacing|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.<ref>https://www.libretro.com/index.php/playstation2-and-the-crt-tv/</ref> Consequently, modern emulation depends heavily on enhancement implementations like post-processing layers, advanced [[deinterlacing]] algorithms and comprehensive shader injection frameworks like `[[Future_of_CRT_simulation#Librashader|librashader]]` to simulate those visual characteristics. Projects like paraLLEl-GS's CRT simulation aim to natively handle most of these cleanly.<ref>https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/</ref>

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

Line 311:

Line 373:

* [https://www.implicitconversions.com/2023/08/01/implicit-conversions-the-origin-story/ Implicit Conversions: The Origin Story - From Self-Taught Developer to Emulation Expert]

* PCSX2: [https://pcsx2.net/blog Blog]

==Xbox==

[[File:Xbox_looking-good.png|thumb|250px|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 "[[:Category:X86-based|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 "[[:Category:X86-based|x86-based]]" consoles). Many aspects of the Xbox's architecture aren't openly documented, making it a major pain to figure out.<ref name="ngemu">{{cite web|url=https://ngemu.com/threads/why-is-xbox-emulation-premature.132032/|title=Why is XBOX emulation premature?|publisher=ngemu|accessdate=2017-05-22|date=2010-02-15}}</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><ref name="FrameRater">{{YouTubeVideo|97mQcus7wFI|Xbox Emulation: The History & Roadblocks}}</ref><ref>{{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> For example, the APU; one of two sound processors on the [https://xboxdevwiki.net/MCPX MCPX southbridge chip] of the Xbox chipset, is [https://github.com/JayFoxRox/xqemu-espes/pull/24 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 [https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/graphs/contributors Cxbx-Reloaded] and [https://github.com/xemu-project/xemu/graphs/contributors xemu] teams, current efforts are now making a real difference.

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

* [http://xboxdevwiki.net/ XboxDevWiki]; for Xbox hardware documentation.

* [https://www.copetti.org/writings/consoles/xbox/ Rodrigo Copetti: Xbox Architecture - A practical analysis]

* [https://github.com/Ryzee119/hawk hawk] - Open Source Recreation of the [[#Hardware_features_and_peripherals|Xbox Live Communicator]] for Original Xbox

* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]

* {{YouTubeVideo|x8zUdtexwTc|Code Not Magic: Archive Formats on the Xbox: Why and How with BLiNX 2}}

* [https://github.com/ergo720/lib86cpu lib86cpu project]

* MVG: {{YouTubeVideo|aiWH4TcFCAY|Original Xbox Emulation on the PC}}, {{YouTubeVideo|MfnbmXgLkzU|Original Xbox Emulation on the PC}}, {{YouTubeVideo|i1iIaSbK9bg|Xbox System-Link works across four console generations}}, {{YouTubeVideo|Da_ont-2AG0|Revisiting Original Xbox Backward Compatibility (Fusion) on the Xbox 360}}, {{YouTubeVideo|uY8KNl88Lqc|Secrets of The Scene: How Cracking Groups Ripped Original Xbox Discs}}, {{YouTubeVideo|lWGiHgTdLBc|The Original Xbox is the Sega Dreamcast 2?}}

* [https://discordapp.com/invite/26Xjx23 CXBX-Reloaded Discord server], [https://discord.gg/ayyjsuM xemu Discord Server] (For general and development discussions on OG Xbox emulation, especially for xemu, Cxbx-Reloaded and any legacy emulators.)

* [https://michaelbrundage.com/note/2005/05/15/xbox-360-emulator/ Personal Remarks about the Xbox Emulator (Fusion) by Michael Brundage]

* Digital Foundry: {{YouTubeVideo|LT1a6NXYy6E|Xbox Series X: Auto HDR Mode Tested - What Works and What Doesn't}}

==Xbox 360==

<blockquote>[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"!"<br>-Triang3l<ref>Triang3l (April 27, 2021). [https://xenia.jp/updates/2021/04/27/leaving-no-pixel-behind-new-render-target-cache-3x3-resolution-scaling.html Leaving No Pixel Behind: New Render Target Cache, 3x3 Resolution Scaling & Three Years in Xenia’s GPU Emulation]. Xenia.</ref></blockquote>

Despite being one of the most popular [[:Category:Seventh-generation_video_game_consoles|seventh gen home console]], due to requiring many resources as well as the hardware not being properly documented yet<ref>[https://web.archive.org/web/20230205112049/http://www.noxa.org/blog/category/projects/xenia/ Building an Xbox 360 Emulator]</ref>, 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.

<blockquote> 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.<br>[https://imgur.com/a/lMxL8gk -Gliniak]</blockquote>

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

* [https://www.copetti.org/writings/consoles/xbox-360/ Rodrigo Copetti: Xbox 360 Architecture Analysis]

* [https://www.xenonwiki.com/Main_Page Xenon Wiki]

* [https://xenonlibrary.com/wiki/Main_Page XenonLibrary]

* [https://consolemods.org/wiki/Xbox_360:Xbox_360_Mods_Wiki consolemods: Xbox 360]

* [https://free60.org/ Free60 Wiki]

* [https://github.com/emoose/xbox-reversing/tree/master emoose: xbox-reversing] - Information & parsers for some under-documented Xbox360 structures/file formats (STFS/GDFX/XDBF/XEX...)

* [https://github.com/OpenKinect/libfreenect libfreenect] - Drivers and libraries for the Xbox Kinect device on Windows, Linux, and OS X.

* [https://github.com/rexdex/recompiler rexdex: recompiler and references list]

* [https://github.com/hedge-dev/XenonRecomp XenonRecomp] and [https://github.com/hedge-dev/XenosRecomp XenosRecomp]

* [https://icode4.coffee/?p=1047 I Code 4 Coffee - Ryan Miceli: Hacking the Xbox 360 Hypervisor Part 1: System Overview]

* [https://github.com/InvoxiPlayGames/x360-research InvoxiPlayGames: research and reverse engineering notes/utilities relating to the Xbox 360]

* Discord: [https://discord.gg/TDvbdXRRQ6 Xenon] and [https://discord.gg/Q9mxZf9 Xenia] (For general and development discussions about Xbox 360 emulation)

:* [https://discord.com/channels/308194948048486401/532286526847975425 xenia-dev references on discord channel]

:* [https://discord.com/channels/308194948048486401/308194948048486401/1195389461186486322 Conversation about xenia CPU emulation on discord channel]

* [https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gallium/drivers/r300?ref_type=heads Mesa gallium R300~R500]

* Specs are the most Xenos related in terms of registers; the closest is the Adreno 200 registers from Qualcomm's Code Aurora Forum release (that <code>drivers/mxc/amd-gpu/yamato</code> directory in some Linux kernel forks). For the shader unit though, there are various specification versions in the exhibits at https://portal.unifiedpatents.com/ptab/case/IPR2015-00325 but they all are very preliminary. Many shader instructions are documented at http://web.archive.org/web/20100423054747/http://msdn.microsoft.com:80/en-us/library/bb313877.aspx but without the encodings. Also http://fileadmin.cs.lth.se/cs/Personal/Michael_Doggett/talks/unc-xenos-doggett.pdf for texture formats. https://www.slideshare.net/blackdevilvikas/next-generation-graphics-programming-on-xbox-360 for tessellation. R600 has some similarities, but it's more for conceptual referencing rather than [https://discord.com/channels/308194948048486401/308194948048486401/1405155461216342078 copying and pasting.]

* [https://www.phoronix.com/news/Terakan-HD-6000-VLK-Windows Open-Source "Terakan" Vulkan Driver For Radeon HD 6000 Series Shown On Windows] - Vitaliy Kuzmin "Triang3l": TeraScale GPUs working on Vulkan and leveraging the Mesa codebase.

* [https://pvs-studio.com/en/blog/posts/cpp/1177/ Aleksandra Uvarova: Realm of gaming experiments: potential developer errors in emulator creating]

* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]

* [https://github.com/billyhulbert/xbcsmgr Xbox Connected Storage Manager] - Accessing games using Xbox Live's save data requires authorization for the 'TitleStorage' service. This requires a device authenticated token and user token. However, the device token originally went through a Microsoft SOAP-based stage which required more effort than it was worth. Instead, using the 'wincred' storage was helpful as this is where the relevant Gaming Services on Windows caches tokens. This application to make the process more clean and easier.

* MVG: {{YouTubeVideo|xCuu-TMquhk|Xbox 360 Emulation on the PC with Xenia takes a huge step forward}}, {{YouTubeVideo|MsnZsgfVLqk|Why Microsoft switched from Intel to Power PC for the Xbox 360}}, {{YouTubeVideo|F1aVBEyqnxA|The Story of Xbox 360 PartnerNet Game Leaks}}, {{YouTubeVideo|RyW0lXnoFOA|How a Mini drill tool defeated security on the Xbox 360}}, {{YouTubeVideo|Vq1lxeg_gNs|How the Xbox 360 Hypervisor Security was Defeated}}, {{YouTubeVideo|8gduINQMxd0|Why YOU need a Modded Xbox 360 in 2018}}, {{YouTubeVideo|zFGz4aT1cgo|The Xbox 360 is still awesome in 2019}}, {{YouTubeVideo|qxtMii5UKVQ|Xbox 360 Blades Dashboard}}, {{YouTubeVideo|IUK__yGXmds|MVG: Any Xbox 360 can now be hacked with just a USB Flash Drive}}

* Digital Foundry: {{YouTubeVideo|LT1a6NXYy6E|Xbox Series X: Auto HDR Mode Tested - What Works and What Doesn't}}, {{YouTubeVideo|SzeBm0XBcOk|FPS Boost For Xbox 360 Games}}, {{YouTubeVideo|7oe1LUJyCCs|Xbox Series X Backwards Compatibility Tested}}

==PlayStation 3==

Line 341:

Line 454:

* [[Wikipedia:PSGL|PSGL API]]

==See also==

==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 {{YouTubeVideo|U7VwtOrwceo|"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 [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki].

At least part of the Xbox One's optical disc drive source code leaked in 2020 ([https://gbatemp.net/threads/xbox-one-internal-sdk-has-leaked-the-ms-equivalent-to-a-gigaleak.579751/ "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.[https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump-games.html][https://x.com/onebawbag/status/1789333419261821032]

It should also be noted that the vast majority of Xbox One games are also available on PC (similarly to [[PlayStation_4_emulators#Emulation_issues|PlayStation 4 (Pro)]], [[PlayStation_5_emulators#Emulation_issues|PlayStation 5 (Pro)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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;

* [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki]

* [https://consolemods.org/wiki/Xbox_One:Xbox_One_Mods_Wiki ConsoleMods: Xbox One]

* [https://www.reddit.com/r/XboxHacking/comments/1d775um/how_xbox_oneseries_emulation_can_come_around_and/ Reddit Thread: "Explanation on Xbox One/Series emulation"]

* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]

* [https://github.com/OpenKinect/libfreenect2 libfreenect2] - Open source Driver for Kinect for Windows v2 (K4W2) devices (release and developer preview). libfreenect2 does not do anything for either Kinect for Windows v1 or Kinect for Xbox 360 sensors. Use [https://github.com/OpenKinect/libfreenect?tab=readme-ov-file libfreenect1] for those sensors.

* [https://github.com/exploits-forsale/collateral-damage Collateral Damage] - Collateral Damage is a kernel exploit for Xbox SystemOS using CVE-2024-30088. It targets Xbox One and Xbox Series consoles running kernel versions 25398.4478, 25398.4908, and 25398.4909. The initial entrypoint is via the Game Script UWP application.

* [https://github.com/Kudayasu/Artifice Artifice] - A custom tool designed to achieve privilege escalation autonomously for Xbox One Developer Mode.

* [https://github.com/XWine1/XDLCompiler XDL Compiler]

* [https://www.eurogamer.net/digitalfoundry-2017-xbox-one-x-back-compat-how-does-it-actually-work EuroGamer - Xbox One backwards compatibility: how does it actually work?]

* {{YouTubeVideo|U7VwtOrwceo|835|Platform Security Summit: Guarding Against Physical Attacks: The Xbox One Story — Tony Chen, Microsoft}}

* {{YouTubeVideo|quLa6kzzra0|similar video}}

* WinDurango [https://discord.gg/mHN2BgH7MR Discord]

* {{YouTubeVideo|DXSEhCQxqEQ|MattKC Bytes: Xbox One emulation is making INCREDIBLE progress in 2025}}

==PS4==

Due to the PS4's [[POS_(Pong_Consoles)_CPUs_and_Other_Chips#x86_CPUs|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<ref>{{cite web | url= https://en.wikipedia.org/wiki/x86_instruction_listings | title= x86 instruction listings | Wikipedia}}</ref>, 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 [https://www.playstation.com/en-us/games/pc-games/ PlayStation 4 (Pro)-exclusive titles are now being ported to PC] with enhancements, so similarly to [[PlayStation_5_emulators#Emulation_issues|PlayStation 5]], [[Xbox One emulators#Emulation issues|Xbox One (X|S)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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<ref>[https://discord.com/channels/252023769500090368/1140403882309202050/1173616669072044032 RPCSX discord channel: Various resources for reverse-engineering PlayStation 4].</ref>;

*Modded Warfare: {{YouTubePlaylist|PLn7ji3VsPy3HCJZF4ivMhnpOt0vZA2g_j|PS4 Jailbreak Tutorials (9.00 or Lower)}}

;General

:;Graphics

:*[https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ A trip through the Graphics Pipeline 2011]

:*[https://vulkan-tutorial.com/ Vulkan Tutorial]

:;Reversing

:*[https://www.amazon.com/dp/0764574817/ Reversing: Secrets of Reverse Engineering (book)]

:*[https://beginners.re/ Reverse Engineering for Beginners (book)]

;PlayStation 4-specific

:;CPU

:*[https://software.intel.com/en-us/articles/intel-sdm#combined Intel® 64 and IA-32 Architectures Software Developer Manuals]

:*[https://support.amd.com/TechDocs/48751_16h_bkdg.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h Models 00h-0Fh Processors]

:*[https://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf Revision Guide for AMD Family 16h Models 00h-0Fh Processors]

:*[https://support.amd.com/TechDocs/52128_16h_Software_Opt_Guide.zip Software Optimization Guide for AMD Family 16h Processors]

:*[https://support.amd.com/TechDocs/48882_IOMMU.pdf AMD I/O Virtualization Technology (IOMMU) Specification]

:;GPU

:*[https://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture.pdf Sea Islands Series Instruction Set Architecture]

:*[https://developer.amd.com/wordpress/media/2013/10/si_programming_guide_v2.pdf Southern Islands/Sea Islands Family 3D/Compute Programming Guide]

:*[https://developer.amd.com/wordpress/media/2013/10/CIK_3D_registers_v2.pdf Radeon Sea Islands 3D/Compute Register Reference Guide]

:;Misc.

:*[http://www.psdevwiki.com/ps4/ PS4 Developer Wiki]

:*[https://github.com/fail0verflow/ps4-linux Linux kernel fork with PS4 support]

:*[https://github.com/fail0verflow/ps4-kexec Implementation of the kexec system call for PS4]

:*{{YouTubeVideo|QMiubC6LdTA|Console Hacking 2016 (33C3)}}

:*Open source projects (FreeBSD, AMDGPU drivers, etc.): [https://github.com/freebsd/freebsd-src/tree/releng/9.1 FreeBSD system calls], [https://github.com/GPUOpen-Drivers/pal GPUOpen-Drivers]

:*RPCSX: [https://discord.gg/M6DK5AXk Discord], [https://rpcsx.github.io/rpcsx-site/ Blogs]

:*ShadPS4: [https://discord.com/invite/bFJxfftGW6 Discord], [https://shadps4.net/all/1/ Blogs]

==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 emulators#Emulation issues|Xbox One]] and even [[PlayStation_4_emulators#Emulation_issues|PS4]] and [[PlayStation_5_emulators#Emulation_issues|PS5]] due to Sony's [https://www.techpowerup.com/332928/former-sony-exec-views-first-party-ps5-to-pc-porting-as-almost-like-printing-money 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;

* [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki]

* [https://www.reddit.com/r/XboxHacking/comments/1d775um/how_xbox_oneseries_emulation_can_come_around_and/ Reddit Thread: "Explanation on Xbox One/Series emulation"]

* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]

* [https://github.com/exploits-forsale/collateral-damage Collateral Damage] - Collateral Damage is a kernel exploit for Xbox SystemOS using CVE-2024-30088. It targets Xbox One and Xbox Series consoles running kernel versions 25398.4478, 25398.4908, and 25398.4909. The initial entrypoint is via the Game Script UWP application.

==PS5==

On top of PlayStation 4 emulation issues, there are additional obstacles for PlayStation 5 emulation such as [https://www.radgametools.com/oodlekraken.htm 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 [https://elektricm.github.io/amd-bc250-docs/ 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 [https://www.playstation.com/en-us/games/pc-games/ PlayStation 5 exclusive titles are now being ported to PC] with enhancements, so similarly to [[PlayStation_4_emulators#Emulation_issues|PlayStation 4 (Pro)]], [[Xbox One emulators#Emulation issues|Xbox One (X|S)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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;

*{{YouTubeVideo|5Cq3K9lBli0|MVG: The PS5 Jailbreak is here}}

*Modded Warfare: {{YouTubePlaylist|PLn7ji3VsPy3E0uxCPaId_-ySd0cXusnJ5|PS5 Tutorials}}

;General

:;Graphics

:*[https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ A trip through the Graphics Pipeline 2011]

:*[https://vulkan-tutorial.com/ Vulkan Tutorial]

:;Reversing

:*[https://www.amazon.com/dp/0764574817/ Reversing: Secrets of Reverse Engineering (book)]

:*[https://beginners.re/ Reverse Engineering for Beginners (book)]

;PlayStation 5-specific

:;CPU

:*N/A

:;GPU

:*N/A

:;Misc

:*[https://www.psdevwiki.com/ps5/Main_Page PS5 Developer Wiki]

:*Open source projects (FreeBSD, AMDGPU drivers, etc.): [https://github.com/freebsd/freebsd-src/tree/releng/9.1 FreeBSD system calls], [https://github.com/GPUOpen-Drivers/pal GPUOpen-Drivers]

:*[https://www.reddit.com/r/PS5/comments/juggo1/has_anyone_done_an_nmap_scan_of_the_ps5_to/ Reddit Thread: Has anyone done an nmap scan of the PS5]

==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. [https://github.com/punesemu/puNES/releases/tag/v0.111 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===

[[File:Retroarch_2013-08-16_06-32-24-62.png|thumb|250px|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, ''[[wikipedia:Super_Mario_Bros._3|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 ''[[wikipedia:Castlevania#Games|Castlevania]]'' games.

===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.

==PC Engine (TurboGrafx-16)==

===Color palette===

[[File:PCE_TG16_Composite_RGB_Palette.png|thumb|250px|An example of the color inaccuracy with the regular RGB color palette when compared to the Composite palette. Take note of the second blue gradient in the sky in both images.]]

The color palettes generated by the PC Engine for Composite and RGB actually differ due to its own color tables being non-linear. This can result in colors ending up looking wrong or blended when the system is emulated or played in RGB. A composite palette was eventually made mathematically and with some extra tweaks from the PC Engine's RGB to YUV lookup table after its HuC6270 video chip had been decapped. This palette is used by default in the PC Engine core for the [[MiSTer]]<ref>https://www.retrorgb.com/pc-engine-palette-improvements-the-amazing-people-behind-the-technology.html</ref>. It [https://github.com/Kitrinx/TG16_Palette can be downloaded] for use in other emulators and devices.

==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/Low level emulation|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 [[Recommended N64 plugins|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,<ref>[https://github.com/Themaister/parallel-rdp#disclaimer 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."</ref> 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.<ref name="gliden64_blog-1">{{cite web|url=https://gliden64.blogspot.com/2017/|title=Public Release 3.0|publisher=Blogspot|accessdate=2018-06-17|date=2017-12-29}}</ref><ref name="ZSortBOSS">{{cite web|url=https://github.com/gonetz/GLideN64/issues/1685#issuecomment-364436534|title=Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer)|publisher=GitHub|accessdate=2018-06-17|date=2018-02-10}}</ref> This means that {{YouTubeVideo|HfCOnmRHI0o|Factor 5's games are now working in high-level graphics mode}}.<ref name="Indiegogo">{{cite web|url=https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-level-emulation#/updates/all|title="Indiana J. & Infernal Machine" HLE|publisher=Indiegogo|accessdate=2018-06-17|date=2018-05-17}}</ref><ref name="gliden64_blog-2">{{cite web|url=https://gliden64.blogspot.com/2018/05/hle-implementation-of-microcodes-for.html|title=HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> 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).<gallery widths="300" mode="packed">

File:Majora's_mask_accurate.png|Low-level emulation of Majora's Mask using SoftGraphic

File:Project64_2013-07-26_14-20-17-55.png|High-level emulation of Majora's Mask using Jabo's Direct3D

</gallery>

=== [[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.<gallery widths="300" mode="packed">

File:Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen displaying issues with filtered text.

File:Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen displaying issues with filtering.

</gallery>

=== 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;

* [https://www.youtube.com/@ModernVintageGamer/search?query=n64 MVG videos about Nintendo 64]

* {{YouTubeVideo|xwls5SpNn1s|Kaze Emanuar: How we BEAT the Limitations that defined the N64s Artstyle}}

* James Lambert: {{YouTubeVideo|r4KGm7ixcqI|How I optimized Portal to run on the Nintendo 64}}, {{YouTubeVideo|Sf036fO-ZUk|How I implemented MegaTextures on real Nintendo 64 hardware}}

* [https://www.copetti.org/writings/consoles/nintendo-64/ Rodrigo Copetti: Nintendo 64 Architecture Analysis]

* [https://n64brew.dev/wiki/Main_Page N64brew Wiki]

==Nintendo GameCube and Wii==

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

* MVG: {{YouTubeVideo|Uxjl_kD3imQ|How the Nintendo GameCube Security was defeated}}, {{YouTubeVideo|up6Rm1Sw1ps|The Nintendo GameCube is still awesome - Games, Homebrew, Modding and More}}, {{YouTubeVideo|HJHb3ZJXJfw|Dolphin has been ported to the Xbox}}

* Dolphin: [https://dolphin-emu.org/blog/ Blog], [https://discord.gg/ZGbGN2mC Discord]

* [https://gamecube.dev/ Awesome GameCube Development]

* [https://www.copetti.org/writings/consoles/gamecube/ Rodrigo Colpetti's GameCube practical analysis]

* [https://www.gc-forever.com/wiki/index.php?title=Main_Page GC-Forever]

* [https://consolemods.org/wiki/GameCube:GameCube_Mods_Wiki ConsoleMods - GameCube]

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

* MVG: {{YouTubeVideo|4BlpONgj74A|How a pair of Tweezers defeated security on the Nintendo Wii}}, {{YouTubeVideo|F0EZQsFulJs|Homebrew Wars : Original Xbox vs Nintendo Wii}}, {{YouTubeVideo|VytQlGRq3jo|Online with the Nintendo Wii in 2019}}, {{YouTubeVideo|FHFuFuUFHagThe Nintendo Wii Shop is going offline forever. How to play WiiWare games in 2019}}, {{YouTubeVideo|hgMWtdayQxQ|Why did Nintendo Release the Wii MINI ? A look back}}, {{YouTubeVideo|rleF4f1dBVo|Hacking the Nintendo Wii Mini}}

* Dolphin: [https://dolphin-emu.org/blog/ Blog], [https://discord.gg/ZGbGN2mC Discord]

* [https://wiibrew.org/wiki/Main_Page WiiBrew]

* [https://www.copetti.org/writings/consoles/wii/ Rodrigo Copetti's Wii practical analysis]

==Nintendo Switch and Switch 2==

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

* MVG: {{YouTubeVideo|xQmN-cxg21M|How the Nintendo Switch Security was defeated}}

* Ryujinx: [https://web.archive.org/web/20241007214154/https://blog.ryujinx.org Blog], [https://discord.gg/ryujinx Discord]

* yuzu: [https://web.archive.org/web/20240304180918/https://yuzu-emu.org/entry/ Blog]

* Torzu: [http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/src/branch/master/blog Blog] (NotABug [https://notabug.org/litucks/torzu/src/master/blog mirror])

* [https://switchbrew.org/wiki/Main_Page SwitchBrew]

* [https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering dekuNukem - Nintendo Switch reverse engineering attempts]

* [https://reswitched.github.io/awesome/ ReSwitched - Awesome Switch: resources]

The Switch 2's custom processor, unlike the vulnerable Tegra X1 with pre-existing exploits, is likely built with stronger security measures. With Nintendo [[Legal_status_and_history_of_emulation#Nintendo| targeting emulators like Yuzu and Ryujinx]], and their forks, hacking and emulator development have been discouraged. Homebrew development faces issues in the current environment. Even if a Switch 2 emulator emerges in a few years, it will likely be tightly controlled within private communities, limiting accessibility. See [https://gbatemp.net/threads/best-practice-for-preserving-switch-2-exploitability.671473/ GBATemp thread] for rumors about Switch 2 exploitability.

=Handhelds=

==Game Boy (Color)==

===Oversaturation===

The Game Boy Color's screen is under-saturated. Game developers often work around this by using brighter colors knowing it'll be compensated for on hardware. This does not translate well in emulation, because standard LCD screens don't account for this sort of issue. Many emulators attempt to combat this issue with options that adjust accordingly; if not directly, then [[Shaders_and_Filters#Image_Adjustment|shader functionality]] may be implemented.

This issue also affects [[Game Boy Advance emulators#Oversaturation|Game Boy Advance emulation]].

====Emulator options====

'''mGBA:''' Under Tools > Settings > Shaders, you will find three customizable '''Desaturation''' parameters.

'''VBA-M:''' Under Options > Game Boy, you will find the '''GB color option'''. The recent nightly builds also include the '''LCD Filter''' option.

For more information about Game Boy hardware and its reverse engineering;<br>

* meganesu: [https://meganesu.github.io/generate-gb-opcodes/ Game Boy CPU Instructions]

* Rodrigo Copetti: [https://www.copetti.org/writings/consoles/game-boy/ Game Boy Architecture Practical Analysis]

* MVG: {{YouTubeVideo|zQE1K074v3s|How Graphics worked on the Nintendo Game Boy}}, {{YouTubeVideo|FzPTK91EJY8|Learn to code and write games on the Nintendo Game Boy}}, {{YouTubeVideo|I1cUIGHZLGA|Secrets of the Nintendo Game Boy Boot Logo}}, {{YouTubeVideo|gYQMdox5gzI|How Cartridges worked on the Nintendo Game Boy}}

* kOOPa and nocash: [https://problemkaputt.de/pandocs.htm Pan Docs]

* [https://gbdev.gg8.se/wiki/articles/Main_Page Game Boy Development Wiki]

==Game Boy Advance==

===Oversaturation===

The screen on the original Game Boy Advance is not backlit and can be hard to see in some conditions. To compensate, game developers often used oversaturated colors by default so that the result would look normal on hardware. On standard computer screens, saturation is not an issue, so this can look jarring and undesirable for gameplay. Some games made after 2003 may have also taken the Game Boy Advance SP model (AGS-001) into account, since its screen was actually frontlit; a newer model, AGS-101, was released in 2005 that was actually backlit. For everything else though, emudevs have given some solutions:

====Emulator Options====

'''No$GBA:''' Under "Emulation Options," select "GBA Mode". There are four modes.

* '''GBA (no backlight):''' Strong desaturation

* '''GBA SP (backlight):''' Strong desaturation

* '''Nintendo DS in GBA mode:''' Some desaturation

* '''VGA Mode (poppy bright):''' No desaturation

'''mGBA:''' Under Tools > Settings > Shaders > Load New Shader, select "gba-color.shader"

'''VBA-M:''' (nightly only): Under Options > Game Boy Advance, you will find the option, '''LCD Filter'''.

'''higan:''' Under Settings > Video Filter, you will find the "Color Emulation" checkbox.

* '''Color Emulation off:''' No desaturation

* '''Color Emulation on:''' Gamma correction and adjusted color range.

'''NanoBoyAdvance''': Enabled by default. Under Config > Video > Color Correction > GBA

'''SkyEmu''': Color Correction is set by default to 1.00 force in this emulator, and there are 2 types of desaturation methods. The first one is named SkyEmu and is selected by default, and the other one is named Higan and, as its name suggests, is based on higan's color correction. Change the desaturation type by pressing the ≡ button, then select GBA Color Correction Type. You can also change the intensity of the desaturation: slide the slider to 0.00 to brighten the screen a tad bit.

====Shaders====

Cg [[Shaders and Filters|shaders]] can be used in [[OpenEmu]] or [[RetroArch]] that adjust the colors to those of a real GBA screen, as well as other screen types. These are available in GLSL<ref name="GLSL">https://github.com/libretro/glsl-shaders/tree/master/handheld/shaders/color</ref> for OpenGL, and Slang<ref name="Slang">https://github.com/libretro/slang-shaders/tree/master/handheld/shaders/color</ref> for Vulkan.

For GBA, there is <code>gba-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/gba-color.cg</ref>, which simulates the color profile of a GBA screen under an external light source more accurately than VBA-M or No$GBA color options. If you prefer the darker color options that those emulators have, then use <code>vba-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/vba-color.cg</ref> instead.

There is also <code>nds-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/nds-color.cg</ref> and <code>psp-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/psp-color.cg</ref>, which simulates the color profiles of the original Nintendo DS frontlit screen and the PSP-1000/PSP-2000 backlit screen, respectively.

For Game Boy Advance shader presets, see the "Shader Presets" page;

===Horrible Sound Quality===

As a handheld rushed to the market (because of the WonderSwan Color competition), the Game Boy Advance had some cut corners. The sound hardware was affected the hardest: while it could play Game Boy Color sound in addition to samples and sequenced music like what would be heard on the SNES, the actual playback quality is awful compared to the sound samples stored internally in the ROM.

There were [https://www.romhacking.net/utilities/881/ tools] made to extract the internal high-quality music (as midi files plus a sound font, to be played on foobar2000); however, interest remains limited in implementing its playback in real-time on emulators. It's worth noting that NanoBoyAdvance includes an high quality audio mixer and there's a very experimental feature exists on [[mGBA]] (nightly versions) under Enhancements as "XQ GBA Audio", but it's very buggy and still limited to games using the standard sound engine, the so-called "Sappy" engine, which is still a big part of the GBA's software library.

===High Resolution Affine Transformation Graphical Effects===

Similarly to the scaling effects used on the Super NES known commonly as "Mode 7" graphics, the Game Boy Advance has affine transformation effects for some backgrounds and individual sprites that can be done in hardware. Due to the GBA's lower resolution, some detail may be lost.

The [[mGBA]] emulator added an Enhancements menu where you can change the resolution of those graphical effects, for a smoother effect. The graphical render engine will need to be OpenGL for those to take effect. It won't work on games where those effects are done in software instead of the hardware scaling features (like the 3D environment in Asterix & Obelix XXL)

===Save formats===

Originally, when saves were implemented, nobody settled on a format, so the Visual Boy Advance devs made their own. Because other emulators often went with raw data, having to exchange different saves caused problems. The original Visual Boy Advance tries to figure out which format a given save is but often fails at it. By explicitly telling the emulator to read it as a specific type using a file called <code>vba-over.ini</code>, VBA complies. VBA-M includes this config file by default, but older revisions like VBA 1.7.2 and VBALink don't.

The VBA-Next and VBA-M cores in Libretro have the file baked into the binary so that it can load raw .sav files. However, they convert the format to its own derivative at exactly 136 KB every time, with save type info contained within the file. This completely avoids the previous issues at the cost of incompatibility with standalone VBA and most others.

To solve this incompatibility, Libretro devs created a

[https://github.com/libretro/vba-next/blob/master/libretro/gbaconv/gbaconv.c command-line tool] to convert .srm save files made from these cores to raw .sav save data for other emulators. It takes standard input (i.e., drag and drop the .srm onto the executable) and outputs accordingly. It can also be done in reverse. A [https://thysbelon.github.io/gbaconv-web/ website version of this tool can be found here].

For more information about Game Boy Advance hardware and its reverse engineering;<br>

* Rodrigo Copetti: [https://www.copetti.org/writings/consoles/game-boy-advance/ Game Boy Advance Architecture Practical Analysis]

* MVG: {{YouTubeVideo|R43k-p9XdIk|The Story of Quake on the Game Boy Advance}}, {{YouTubeVideo|_Qqg4VCZ0k8|How the Game Boy Advance knew it was running a Game Boy Game}}, {{YouTubeVideo|_GVSLcqGP7g|Tomb Raider on the Nintendo Game Boy Advance is incredible}}, {{YouTubeVideo|mpNWEbZdXNw|How Graphics worked on the Nintendo Game Boy Advance}}

* martin korth: [https://problemkaputt.de/gbatek-contents.htm gbatek]

* [https://akkera102.sakura.ne.jp/gbadev/ akkera102.sakura gbadev (Japanese)]

* [https://gbadev.net/gbadoc/ gbadev - gbadoc]

* [https://en.wikibooks.org/wiki/GBA_Development/Resources WikiBooks - GBA Development Resources]

==PlayStation Portable==

For more information about PSP hardware and its reverse engineering;

* MVG: {{YouTubeVideo|nCzY-QhBxaE|PSP in 2023}}, {{YouTubeVideo|qIxKPu20R58|How the Sony PlayStation Portable PSP Security was defeated}}, {{YouTubeVideo|vY1j30jzRsE|A closer look at the Sony PSP DTP-T1000 Development Kit}}, {{YouTubeVideo|3HfaAlS7ons|Another look at the Sony PSP GO Handheld in 2018}}

* [https://www.copetti.org/writings/consoles/playstation-portable/ Rodrigo Copetti's PSP Architecture Practical Analysis]

* PPSSPP: [http://www.ppsspp.org/blog/ Blog], [https://discord.gg/5NJB6dD Discord], [https://www.ppsspp.org/docs/development/ Docs]

* [https://www.psdevwiki.com/psp/Main_Page PSDevWiki - PSP]

==Nintendo 3DS==

For more information about Nintendo 3DS hardware and its reverse engineering;

* MVG: {{YouTubeVideo|YAKujG8SXKY|The most important Nintendo 3DS Game Ever Made}}, {{YouTubeVideo|jjFGxIfDX70|Homebrew on a $100 New Nintendo 3DS LL}}, {{YouTubeVideo|-guh8hXo1bc|The Nintendo 3DS eShop Is Going Offline Forever. How to Play All Games After 2023}},

* Citra: [https://web.archive.org/web/20240304201632/https://citra-emu.org/tags/progress-report/ Blog]

* Tanuki3DS: [https://discord.gg/6ya65fvD3g Discord]

* Azahar: [https://azahar-emu.org/pages/bloglist/ Blog]

* [https://www.3dbrew.org/wiki/Main_Page 3dbrew]

* [https://wiki.gbatemp.net/wiki/3DS_Homebrew_Development GBATemp - 3DS Homebrew Development]

* [https://3ds.hacks.guide/ 3DS Hacks Guide]

* [https://fosdem.org/2024/schedule/event/fosdem-2024-1726-panda3ds-climbing-the-tree-of-3ds-emulation/ FOSDEM '24: Panda3DS - Climbing the tree of 3DS emulation]

=See also=

*[[Emulator scams]]

*[[Console-specific development wikis]]

*[[Emulation books and articles]]

*[[Legal status and history of emulation]]

*[[Licensing]]

*[[Copy protection]]

*[[Preservation projects]]

[[Category:FAQs]]

@@ Line 8: / Line 8: @@
 :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.
 *[[Gizmondo emulators|Gizmondo]]
-*[[IPod Classic emulators|Apple iPod]]
+*[[IPod emulators|Apple iPod]]
 *[[IOS_emulators|Apple iOS]]
 *[[PlayStation Mobile]]
@@ Line 32: / Line 32: @@
 *[[Official emulators]]
+=Home Computers=
 ==Windows XP==
 {{Main|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 [[Emulation accuracy|cycle-accurate]] implementation of an entire [[Windows NT 5.x emulators|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.
+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 [[Emulation accuracy|cycle-accurate]] implementation of an entire 2001-2006 [[Windows NT 5.x emulators|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 [[wikipedia:Hardware_virtualization#Hardware-assisted_virtualization|hardware-assisted virtualization]] (such as [[Hypervisors#Type 1 hypervisors|KVM]] or [[Hypervisors#Hyper-V Subsets|WHPX]]) or [[High and low-level emulation#Modern Dependencies.2C Advancements and Optimization Strategies|dynamic binary translation]] (DBT). Hardware-assisted virtualization executes guest code directly on the host processor and therefore [[Hypervisors#Performance impact|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 [[Windows NT 5.x emulators#Other solutions|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 [https://github.com/JHRobotics/softgpu SoftGPU], [https://github.com/iXit/wine-nine-standalone Gallium Nine], and experimental [https://github.com/virtio-win/kvm-guest-drivers-windows/pull/943 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.
+But unlike a typical console emulator, a Windows XP emulator could target 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 substantially lower than native execution on modern processors; many games and applications released during this period were designed to run on hardware comparable to a 32-bit Intel Pentium 4 "Prescott" CPU with SSE3 support.<ref>While the Prescott microarchitecture was designed with Intel 64 capabilities, the initial desktop models shipped with 64-bit support disabled. Consequently, these early variants do not qualify as x86-64-v1 processors and function strictly as 32-bit x86 processors with SSE3 support. Intel later enabled 64-bit support in subsequent Prescott revisions, such as the 5xxF and 6xx series.</ref> Consequently, the software emulator only needs to match this legacy performance while minimizing translation overhead. The most significant remaining technical hurdle for the 2001–2006 era is efficient 3D graphics acceleration; a DirectX 9.0c Shader Model 3.0 GPU would be the perfect target to run the vast majority of software from this generation. While projects such as [[Windows NT 5.x emulators#Other solutions|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 [https://github.com/JHRobotics/softgpu SoftGPU], [https://github.com/iXit/wine-nine-standalone Gallium Nine], and experimental [https://github.com/virtio-win/kvm-guest-drivers-windows/pull/943 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 ===
@@ Line 48: / Line 49: @@
 * '''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.
+<div style="font-size: 80%; line-height: 1.2;">
 <pre>
 +───────────────────────────────────────────────────────────────────────────+
@@ Line 83: / Line 85: @@
 +───────────────────────────────────────────────────────────────────────────+
 </pre>
+</div>
 === Approach 2: Paravirtualized GPU Device ===
@@ Line 89: / Line 92: @@
 * '''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 <code>d3d8.dll</code> or <code>d3d9.dll</code>) 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.
+* '''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, low-level explicit graphics API backend such as Vulkan. Unlike application-level wrapper projects, the renderer operates entirely within the emulator rather than inside the guest operating system.
+<div style="font-size: 80%; line-height: 1.2;">
 <pre>
 +───────────────────────────────────────────────────────────────────────────+
@@ Line 108: / Line 112: @@
                                    ▼
                    =================================
-                   SHARED MEMORY COMMAND QUEUE
+                     SHARED MEMORY COMMAND QUEUE
                    =================================
                                    │
                                    ▼
-+─────────────────────────────────┴─────────────────────────────────────────+
++───────────────────────────────────────────────────────────────────────────+
 |                           HOST OS / EMULATOR                              |
 |                                                                           |
@@ Line 120: / Line 124: @@
 |   [ Virtual GPU Command Decoder ]                                         |
 |            │                                                              |
-|            ▼                                                              |
+|            ▼ (Unified Internal Rendering Representation)                  |
 |   [ Virtual GPU Renderer ]                                                |
 |            │                                                              |
-|            ▼                                                              |
+|            ▼ (Shader Translation / Backend Interface)                     |
-|   [ Vulkan / OpenGL Backend ]                                             |
+|   [ Vulkan / Direct3D 12 / Metal Backend ]                               |
 |            │                                                              |
 |            ▼                                                              |
@@ Line 130: / Line 134: @@
 +───────────────────────────────────────────────────────────────────────────+
 </pre>
+</div>
-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.
+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. 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.
+Since rendering is performed entirely on the host GPU, completed frames generally do not need to be copied back into the guest frame buffer unless required for compatibility (such as guest software that reads the front buffer directly). Instead, the emulator presents the rendered output directly within its own display window while maintaining the guest-visible synchronization state. Consequently, the primary challenge is implementation complexity rather than raw GPU performance. A complete virtual graphics device must faithfully virtualize Direct3D state management, resource creation, explicit synchronization primitives, presentation, capability reporting, shader handling, and device-loss behavior so that Windows and its applications observe behavior consistent with physical hardware. To manage this complexity across multiple host operating system ecosystems (beyond just Windows machines), a modern implementation could rely on a unified internal rendering architecture. Under this approach, the virtual GPU command stream is decoded into an implementation-defined rendering representation describing pipeline state, resources, synchronization primitives, and draw commands independently of any particular host graphics API. Shader programs are translated separately into an appropriate intermediate representation for the selected backend, such as SPIR-V for Vulkan, or into DXIL or Metal Shading Language (MSL) for Direct3D 12 and Metal. This separation allows the same rendering architecture to target multiple host APIs while minimizing duplicated implementation effort. Legacy fixed-function features such as table fog or texture combiners that no longer exist on modern programmable GPUs can be reconstructed through generated shader programs or specialized rendering passes rather than game-specific compatibility hacks. Likewise, legacy implicit synchronization semantics can be mapped onto modern explicit primitives such as timeline semaphores and fine-grained synchronization barriers provided by contemporary graphics APIs.
-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.
+* '''Pristine Guest Environment:''' The original Microsoft graphics runtime remains entirely untouched, avoiding error-prone per-game DLL replacement, manual system tweaks, and compatibility hacks.
-* Graphics virtualization occurs at the device-driver level, allowing all applications to use the same rendering pipeline automatically.
+* '''Universal Virtual Pipeline:''' Graphics virtualization occurs at the device-driver level, allowing all legacy software, system components, and multimedia applications to use the exact same accelerated rendering infrastructure 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.
+* '''Architectural Hardware Abstraction:''' The virtual GPU provides a stable, modern hardware abstraction for the guest while the emulator translates its command stream directly into explicit APIs, eliminating the need to emulate obsolete register-level structures or specific physical GPU architectures.
-* Shared-memory command transport minimizes synchronization overhead compared to frequent VM exits or hypercalls.
+* '''Low-Overhead Command Flow:''' Shared-memory command transport paired with modern explicit timeline synchronization minimizes host-guest messaging overhead and prevents VM exits or hypercall stalls.
-* Rendering logic resides entirely within the emulator, resulting in a more centralized and maintainable graphics architecture.
+* '''Centralized Rendering Architecture:''' All translation logic, shader recompilation pipelines, and backward-compatible fixed-function approximations reside entirely within the host-side emulator engine, creating a highly organized, modular, and maintainable subsystem.
 For more information about PC emulation and their reverse engineering;
@@ Line 172: / Line 175: @@
 * [[Compatibility layers]]
 * [[Windows NT 5.x emulators#Hypervisors|Hypervisor's Virtual GPU Adapters for legacy operating systems]]
-* [https://github.com/libcdio/libcdio libcdio], [https://github.com/polpo/picogus picogus], Duckstation's [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_ccd.cpp cd image ccd], [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_cue.cpp cd image cue], [[Ymir]]'s [https://github.com/StrikerX3/Ymir/tree/main/libs/ymir-core/src/ymir/hw/cdblock low-level cd block] and [https://github.com/PCSX2/pcsx2/tree/master/pcsx2/CDVD PCSX2's CDVD] - Could be beneficial for implementing reading capability for [[Ripping games#Disc-based|capable disc image formats]].
+* [https://github.com/libcdio/libcdio libcdio], [https://github.com/polpo/picogus picogus], Duckstation's [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_ccd.cpp cd image ccd], [https://github.com/stenzek/duckstation/blob/master/src/util/cd_image_cue.cpp cd image cue], [[86Box]]' [https://github.com/86Box/86Box/pull/7424 aaru support], [[Ymir]]'s [https://github.com/StrikerX3/Ymir/tree/main/libs/ymir-core/src/ymir/hw/cdblock low-level cd block] and [https://github.com/PCSX2/pcsx2/tree/master/pcsx2/CDVD PCSX2's CDVD] - Could be beneficial for implementing reading capability for [[Ripping games#Disc-based|capable disc image formats]].
 * [https://github.com/aaronsgiles/ymfm ymfm]
+==Mac OS X and macOS==
+===PowerPC===
+Currently, no 3rd-party Macintosh emulators support hardware graphics acceleration, due to [https://www.emaculation.com/forum/viewtopic.php?t=8396 certain CPU instructions left unimplemented in their upstream PPC softcores]. This means no GLIDE, RAVE, or OpenGL. Fortunately, though as was generally the case in every platform of the period significant visual and feature differences exist between the two, the majority of Mac-exclusive software using these APIs also included software fallback renderers. It is however possible to pass through a real GPU to a PowerPC Mac being emulated by QEMU provided you have one that's compatible with OpenFirmware
+===x86===
+Despite an x86-based Mac is very similar to a general non-Apple PC in hardware architecture (which makes [[wikipedia:/Boot_Camp_(software)|Boot Camp]] and [[wikipedia:Hackintosh|Hackintosh]] possible), it still contains Apple proprietary hardware such as closed-source EFI BootROM, System Management Controller (SMC) and later T1/T2 security chip that either requires bypassing or emulation in order to run macOS. macOS also contains countermeasures that prevent it from being run on a non-Apple PC such as the infamous [https://www.tonymacx86.com/threads/dont-steal-mac-os-x-kext.51175/ Don't Steal Mac OS X.kext].
+Another big hurdle is that macOS only contains drivers for hardware components used in actual Mac computers, which means a large portion of PC users who use different hardware combinations than actual Mac computers need to bypass, patch, or port drivers for their hardware in order to boot macOS and promote it to a usable state, and might still with crippled functionalities due to no or imperfect solutions to drive some of the hardware.
+===ARM===
+Hurdles in emulating ARM-based Mac are basically the same as emulating iOS devices: Apple's proprietary M1/M2 SoC which has little to no documentation, and hardened security measures inherited from iOS devices. However if Apple discontinues support for x86 in XCode, there will be no way to code modern iOS apps on other platforms or use macOS apps in general. If an ARM macOS emulator is sucessful, modern iOS emulation will be "cracked" too (apart from Corellium though).
+=Home Consoles=
+==Pioneer LaserActive==
+The LaserActive Project wishes to document all LaserActive media. On their FAQ page, they have this to say about the possibility of creating a LaserActive emulator:
+<blockquote>Emulation of the LaserActive, if attempted at all, would be an incredibly difficult task – due to the hybrid nature of the system's hardware (utilizing Sega/NEC hardware in synchronization with the unique LD player hardware) and the analog-digital composite image (analog video background, digital in-game graphics generated by said Sega/NEC hardware).<ref>https://laseractive.wordpress.com/faq/</ref></blockquote>
+Emulator developer Nemesis has made an effort to dump [https://segaretro.org/LaserActive#List_of_games the games for the system] (except for porn games).<ref name="Nemesis">https://gendev.spritesmind.net/forum/viewtopic.php?t=1647&postdays=0&postorder=asc&start=0</ref> Copies of the games sent to him were supposed to be dumped and then returned.<ref name="Nemesis"/>
+[[ares]] has made the most significant progress to date, featuring active support for a majority of the LaserActive's [[LaserActive#PACs|expansion PACs]].
+==Philips CD-i==
+The accurate emulation of the Philips CD-i (Compact Disc Interactive) system presents several significant challenges for developers. These complexities have historically limited the availability and completeness of CD-i emulators. The primary difficulties can be categorized as follows:
+*Limited Demand: Compared to highly popular gaming consoles and computer systems (such as the NES, SNES, PlayStation series, or Xbox series), the demand for a fully functional CD-i emulator is relatively low. This lower interest translates into a smaller pool of developers willing to invest the substantial time and effort required for such a complex project.
+*Hardware Proliferation and Variation: The CD-i platform saw a wide array of hardware releases. There are at least 32 known distinct CD-i player models, many of which underwent major internal revisions. Nearly every model featured some degree of hardware difference. These variations ranged from minor (e.g., the Philips CD-i 550 model essentially being a CD-i 450 with a pre-installed Digital Video Cartridge) to complete mainboard overhauls (e.g., the CD-i 220 model is known to have at least five revisions, each with a different mainboard). Compounding this, a diverse range of peripherals was available for CD-i players. Consequently, for an emulator to be considered "fully functional," it would ideally need to accurately replicate the behavior of every known player model and peripheral.
+*Scarcity of Technical Documentation: While foundational aspects of the CD-i standard and its players are understood – such as their common reliance on the Philips SCC68070 CPU (a specialized variant of the Motorola 68000) or its derivatives (like the MC68341 Integrated CD-i Engine), and the identification of many common support chips – detailed public documentation for critical components is scarce. CD-i players utilized numerous custom integrated circuits (ICs) that were often exclusive to the platform. The lack of public datasheets and technical information for these custom chips means that emulating their precise behavior often requires extensive and time-consuming reverse-engineering. The development of CD-i Emu, currently the most feature-complete CD-i emulator, exemplifies this challenge. Its developer, known as CDiFan, has made a significant personal investment of time, financial resources, and effort over nearly two decades. This includes amassing an extensive personal collection of CD-i hardware and software, which has reportedly been instrumental in the complex reverse-engineering process necessary to understand the functions of various player components. The developer has stated that CD-i Emu represents over 120,000 lines of hand-written code. This substantial individual effort highlights the barrier posed by the lack of public documentation. A core aspect of CD-i operation that influences emulation is that the entire player hardware must be simulated, not just the software environment for a game or application. This includes the player's boot sequence into its operating system shell (the menu). Therefore, emulators require a ROM image (firmware dump) from an original CD-i player to function, even for running "base-case" titles that do not require specialized add-on hardware. Further complicating emulation efforts is the optional [[CD-i_emulators#Digital_Video_Cartridge|Digital Video Cartridge (DVC)]]. The DVC provided two main benefits: an additional 1.5 MB of RAM and, more significantly, the hardware capabilities for decoding and playing back MPEG-1 video. This video processing was handled by yet more custom chips, which also suffer from a lack of comprehensive public documentation. The DVC contains its own ROM, distinct from the player's main ROM, which is necessary for emulating titles that utilize its FMV/video playback features (including [[Home_media_players#Emulators_that_support_multimedia_capabilities_of_the_system|CD-i Digital Video and VCD support]]).
+As of early 2025, DVC MPEG-1 emulation support is largely in a proof-of-concept stage and is primarily, if not exclusively, found in CD-i Emu. Other emulators generally do not yet offer DVC functionality.
+A notable consideration in the CD-i emulation landscape is that the source code for CD-i Emu is not publicly available. While this is the prerogative of the author, it means that prospective contributors to CD-i emulation who wish to build upon existing advanced work may be unable to do so directly with this codebase. Instead, new efforts often necessitate starting an emulation project from the ground up. The significant undertaking of managing an open-source project, particularly for a developer working largely solo as a hobby, is a factor in such decisions. Furthermore, the pool of developers possessing both the requisite skills and the specific interest in CD-i emulation may be inherently limited, potentially mitigating the impact of a closed-source approach on overall development velocity within the niche. The developer of CD-i Emu offers a full version of the emulator for a fee, a decision understandable in light of the extensive, long-term personal investment involved in its creation.
+Despite these hurdles, progress in CD-i emulation continues, albeit concentrated. [[MiSTer|CDi_MiSTer core]] and the developer of CD-i Emu is actively working on improving the emulator.
 ==PlayStation==
@@ Line 223: / Line 260: @@
 * [https://psx-spx.consoledev.net/ psx-spx.consoledev.net]
 * [https://problemkaputt.de/psxspx-contents.htm no$psx: Playstation Specifications]
+==Sega Saturn==
+:''This section was copied from Wikipedia in 2014. For an up-to-date explanation, see [[wikipedia:Sega Saturn#Technical specifications|Sega Saturn § Technical specifications]]''
+The complexity of the system has made the creation of a proper emulator for it rather difficult.
+<blockquote>One very fast central processor would be preferable. I don't think all programmers have the ability to program two CPUs — most can only get about one-and-a-half times the speed you can get from one SH-2. I think that only 1 in 100 programmers are good enough to get this kind of speed [nearly double] out of the Saturn. "Yu Suzuki reflecting upon Saturn's ''Virtua Fighter'' development<ref name="YuSuzukiNG">Next Generation (magazine) issue 2, 1995</ref>.</blockquote>
+The Saturn had technically impressive hardware at the time of its release, but its complex design, with two CPUs and six other processors, made harnessing this power difficult for developers accustomed to conventional programming.  The biggest disadvantage was that both CPUs shared the same bus and were unable to access system memory at the same time. Making full use of the 4&nbsp;kB of cache memory in each CPU was critical to maintaining performance.  One example of how the Saturn was utilized was with ''Virtua Fighter''<nowiki>'</nowiki>s use of one CPU for each character<ref name=YuSuzukiNG/>. Many of the Saturn's developers, such as Lobotomy Software programmer Ezra Dreisbach, found it difficult to develop for compared to the PlayStation because of its more complex graphics hardware<ref name=DreisbachCG>{{cite web|title=Interview: Ezra Dreisbach |publisher=Curmudgeon Gamer |date=July 9, 2002|url=http://curmudgeongamer.com/article.php?story=20021008212903265 |accessdate=July 19, 2007|archiveurl = http://web.archive.org/web/20070927211250/http://curmudgeongamer.com/article.php?story=20021008212903265 <!-- Bot retrieved archive --> |archivedate = September 27, 2007}}</ref>. In order to port ''Duke Nukem 3D'' and ''PowerSlave'' to the Saturn, Lobotomy Software had to almost entirely rewrite the Build engine to take advantage of the Saturn's unconventional hardware<ref name=DreisbachCG/>.  Third-party development was initially hindered by the lack of useful software libraries and development tools, requiring developers to write in assembly language to achieve good performance. During early Saturn development, programming in assembly could offer a two to fivefold speed increase over C language<ref name=YuSuzukiNG/>. Sega responded to these criticisms by writing new graphics libraries which were claimed to help make development easier<ref name="NextGenDec95">''So many 32-Bit Systems To Choose From'' Next Generation (magazine) issue 12, 1995</ref>. These libraries were presented as a new operating system by Sega of Japan<ref name="NextGenDec95"/>.
+Unlike the PlayStation and Nintendo 64 which used triangles as their basic geometric primitive, the Saturn rendered quadrilaterals with forward texture mapping. This proved to be a hindrance because most of the industry's standard design tools were based on triangles, with independent texture UV coordinates specified per vertex. One of the challenges brought forth by quadrilateral-based rendering was problems with textured surfaces containing triangles. To make a triangular-shaped object, rendering had a fourth side with a length of zero. This technique proved problematic as it caused texture distortion and required careful reworking to achieve the desired appearance—Sega provided tools for remapping textures from UV space into rectangular tiles. These complications can be seen in the Saturn version of ''Tomb Raider''<ref name=DreisbachCG/>.
+For more information about Sega Saturn hardware and its reverse engineering;
+* [https://www.copetti.org/writings/consoles/sega-saturn/ Rodrigo Copetti: Sega Saturn Architecture analysis]
+* {{YouTubeVideo|ODJl6U1lp_Q|MVG: How the SEGA Saturn CD Security was defeated}}
+* [https://www.psdevwiki.com/ps4/Sega_Saturn_Emulation PSDevWiki: PS4's Sega Saturn Emulation]
+* {{YouTubeVideo|jChtlWNIAL4|LGR: Oddware - Diamond Edge 3D (nVidia NV1+Sega Saturn Ports)}}
+* [https://www.yabasanshiro.com/blog/2026-05-31_new_vdp2_emulation yabasanshiro blog: new vdp2 emulation]
+==Sega Dreamcast==
+Developer interest in Dreamcast emulation was previously hindered by the availability of the closed-source but "good enough" Chankast, and by less interest in the console relative to other 6th generation consoles. For the emulators that are either mature or maturing, a very large percentage of games work well, but some games still have problems and glitches.
+For more information about Dreamcast hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|rj56VU_VmWg|How the Sega Dreamcast Copy Protection Worked - And how it Failed}}, {{YouTubeVideo|rN0vEa8Y4J4|The Sega Dreamcast 20 years later 9-9-99}}, {{YouTubeVideo|NMDpPRGuaq8|The Arcade Sega Dreamcast - Revisiting the Sega Naomi Arcade Hardware}}, {{YouTubeVideo|QKHSlBi5qok|What happened to Windows CE on the SEGA Dreamcast?}}
+* [https://www.copetti.org/writings/consoles/dreamcast/ Rodrigo Copetti's Dreamcast Architecture Practical Analysis], {{YouTubeVideo|lWGiHgTdLBc|The Original Xbox is the Sega Dreamcast 2?}}
 ==PlayStation 2==
@@ Line 257: / Line 319: @@
 ** '''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.
 ** '''[https://www.psdevwiki.com/ps2/DEV9C 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.<ref>https://pcsx2.net/blog/2025/pcsx2-2.4_2.2/#dev9-fixes</ref><ref>https://pcsx2.net/blog/2023/q1-2022-progress-report#dev9</ref>
-** '''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.
+** '''[[Disc_Drive_emulation#DVD|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.
 ::{| class="wikitable"
@@ Line 283: / Line 345: @@
 * '''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.<ref>https://github.com/PCSX2/pcsx2/pull/4274#issuecomment-795316629</ref><ref>https://github.com/PCSX2/pcsx2/pull/10836#issuecomment-1954866179</ref>
-** '''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 [[#Arcade hardware variants|Konami Python 2]] sections.
+** '''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 [[Disc_Drive_emulation#DVD|PS2's DVD player]] and [[PlayStation_2_emulators#Arcade hardware variants|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.
@@ Line 297: / Line 359: @@
 ===CRT Output Video Quirks===
 {{Main|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 [[deinterlacing|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.<ref>https://www.libretro.com/index.php/playstation2-and-the-crt-tv/</ref> Consequently, modern emulation depends heavily on [[#Enhancements|enhancement implementations]] like post-processing layers, advanced [[deinterlacing]] algorithms and comprehensive shader injection frameworks like `[[Future_of_CRT_simulation#Librashader|librashader]]` to simulate those visual characteristics. Projects like paraLLEl-GS's CRT simulation aim to natively handle most of these cleanly.<ref>https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/</ref>
+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 [[deinterlacing|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.<ref>https://www.libretro.com/index.php/playstation2-and-the-crt-tv/</ref> Consequently, modern emulation depends heavily on enhancement implementations like post-processing layers, advanced [[deinterlacing]] algorithms and comprehensive shader injection frameworks like `[[Future_of_CRT_simulation#Librashader|librashader]]` to simulate those visual characteristics. Projects like paraLLEl-GS's CRT simulation aim to natively handle most of these cleanly.<ref>https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/</ref>
 For more information about PlayStation 2 hardware and its reverse engineering;
@@ Line 311: / Line 373: @@
 * [https://www.implicitconversions.com/2023/08/01/implicit-conversions-the-origin-story/ Implicit Conversions: The Origin Story - From Self-Taught Developer to Emulation Expert]
 * PCSX2: [https://pcsx2.net/blog Blog]
+==Xbox==
+[[File:Xbox_looking-good.png|thumb|250px|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 "[[:Category:X86-based|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 "[[:Category:X86-based|x86-based]]" consoles). Many aspects of the Xbox's architecture aren't openly documented, making it a major pain to figure out.<ref name="ngemu">{{cite web|url=https://ngemu.com/threads/why-is-xbox-emulation-premature.132032/|title=Why is XBOX emulation premature?|publisher=ngemu|accessdate=2017-05-22|date=2010-02-15}}</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><ref name="FrameRater">{{YouTubeVideo|97mQcus7wFI|Xbox Emulation: The History & Roadblocks}}</ref><ref>{{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> For example, the APU; one of two sound processors on the [https://xboxdevwiki.net/MCPX MCPX southbridge chip] of the Xbox chipset, is [https://github.com/JayFoxRox/xqemu-espes/pull/24 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 [https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/graphs/contributors Cxbx-Reloaded] and [https://github.com/xemu-project/xemu/graphs/contributors xemu] teams, current efforts are now making a real difference.
+<!-- The Nouveau project for Linux may be of help figuring out the GeForce hardware in the Xbox{{Cite}} -->
+For more information about the Xbox system and its reverse engineering;
+* [http://xboxdevwiki.net/ XboxDevWiki]; for Xbox hardware documentation.
+* [https://www.copetti.org/writings/consoles/xbox/ Rodrigo Copetti: Xbox Architecture - A practical analysis]
+* [https://github.com/Ryzee119/hawk hawk] - Open Source Recreation of the [[#Hardware_features_and_peripherals|Xbox Live Communicator]] for Original Xbox
+* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]
+* {{YouTubeVideo|x8zUdtexwTc|Code Not Magic: Archive Formats on the Xbox: Why and How with BLiNX 2}}
+* [https://github.com/ergo720/lib86cpu lib86cpu project]
+* MVG: {{YouTubeVideo|aiWH4TcFCAY|Original Xbox Emulation on the PC}}, {{YouTubeVideo|MfnbmXgLkzU|Original Xbox Emulation on the PC}}, {{YouTubeVideo|i1iIaSbK9bg|Xbox System-Link works across four console generations}}, {{YouTubeVideo|Da_ont-2AG0|Revisiting Original Xbox Backward Compatibility (Fusion) on the Xbox 360}}, {{YouTubeVideo|uY8KNl88Lqc|Secrets of The Scene: How Cracking Groups Ripped Original Xbox Discs}}, {{YouTubeVideo|lWGiHgTdLBc|The Original Xbox is the Sega Dreamcast 2?}}
+* [https://discordapp.com/invite/26Xjx23 CXBX-Reloaded Discord server], [https://discord.gg/ayyjsuM xemu Discord Server] (For general and development discussions on OG Xbox emulation, especially for xemu, Cxbx-Reloaded and any legacy emulators.)
+* [https://michaelbrundage.com/note/2005/05/15/xbox-360-emulator/ Personal Remarks about the Xbox Emulator (Fusion) by Michael Brundage]
+* Digital Foundry: {{YouTubeVideo|LT1a6NXYy6E|Xbox Series X: Auto HDR Mode Tested - What Works and What Doesn't}}
+==Xbox 360==
+<blockquote>[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"!"<br>-Triang3l<ref>Triang3l (April 27, 2021). [https://xenia.jp/updates/2021/04/27/leaving-no-pixel-behind-new-render-target-cache-3x3-resolution-scaling.html Leaving No Pixel Behind: New Render Target Cache, 3x3 Resolution Scaling & Three Years in Xenia’s GPU Emulation]. Xenia.</ref></blockquote>
+Despite being one of the most popular [[:Category:Seventh-generation_video_game_consoles|seventh gen home console]], due to requiring many resources as well as the hardware not being properly documented yet<ref>[https://web.archive.org/web/20230205112049/http://www.noxa.org/blog/category/projects/xenia/ Building an Xbox 360 Emulator]</ref>, 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.
+<blockquote> 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.<br>[https://imgur.com/a/lMxL8gk -Gliniak]</blockquote>
+For more information about Xbox 360 system and its reverse engineering;
+* [https://www.copetti.org/writings/consoles/xbox-360/ Rodrigo Copetti: Xbox 360 Architecture Analysis]
+* [https://www.xenonwiki.com/Main_Page Xenon Wiki]
+* [https://xenonlibrary.com/wiki/Main_Page XenonLibrary]
+* [https://consolemods.org/wiki/Xbox_360:Xbox_360_Mods_Wiki consolemods: Xbox 360]
+* [https://free60.org/ Free60 Wiki]
+* [https://github.com/emoose/xbox-reversing/tree/master emoose: xbox-reversing] - Information & parsers for some under-documented Xbox360 structures/file formats (STFS/GDFX/XDBF/XEX...)
+* [https://github.com/OpenKinect/libfreenect libfreenect] - Drivers and libraries for the Xbox Kinect device on Windows, Linux, and OS X.
+* [https://github.com/rexdex/recompiler rexdex: recompiler and references list]
+* [https://github.com/hedge-dev/XenonRecomp XenonRecomp] and [https://github.com/hedge-dev/XenosRecomp XenosRecomp]
+* [https://icode4.coffee/?p=1047 I Code 4 Coffee - Ryan Miceli: Hacking the Xbox 360 Hypervisor Part 1: System Overview]
+* [https://github.com/InvoxiPlayGames/x360-research InvoxiPlayGames: research and reverse engineering notes/utilities relating to the Xbox 360]
+* Discord: [https://discord.gg/TDvbdXRRQ6 Xenon] and [https://discord.gg/Q9mxZf9 Xenia] (For general and development discussions about Xbox 360 emulation)
+:* [https://discord.com/channels/308194948048486401/532286526847975425 xenia-dev references on discord channel]
+:* [https://discord.com/channels/308194948048486401/308194948048486401/1195389461186486322 Conversation about xenia CPU emulation on discord channel]
+* [https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gallium/drivers/r300?ref_type=heads Mesa gallium R300~R500]
+* Specs are the most Xenos related in terms of registers; the closest is the Adreno 200 registers from Qualcomm's Code Aurora Forum release (that <code>drivers/mxc/amd-gpu/yamato</code> directory in some Linux kernel forks). For the shader unit though, there are various specification versions in the exhibits at https://portal.unifiedpatents.com/ptab/case/IPR2015-00325 but they all are very preliminary. Many shader instructions are documented at http://web.archive.org/web/20100423054747/http://msdn.microsoft.com:80/en-us/library/bb313877.aspx but without the encodings. Also http://fileadmin.cs.lth.se/cs/Personal/Michael_Doggett/talks/unc-xenos-doggett.pdf for texture formats. https://www.slideshare.net/blackdevilvikas/next-generation-graphics-programming-on-xbox-360 for tessellation. R600 has some similarities, but it's more for conceptual referencing rather than [https://discord.com/channels/308194948048486401/308194948048486401/1405155461216342078 copying and pasting.]
+* [https://www.phoronix.com/news/Terakan-HD-6000-VLK-Windows Open-Source "Terakan" Vulkan Driver For Radeon HD 6000 Series Shown On Windows] - Vitaliy Kuzmin "Triang3l": TeraScale GPUs working on Vulkan and leveraging the Mesa codebase.
+* [https://pvs-studio.com/en/blog/posts/cpp/1177/ Aleksandra Uvarova: Realm of gaming experiments: potential developer errors in emulator creating]
+* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]
+* [https://github.com/billyhulbert/xbcsmgr Xbox Connected Storage Manager] - Accessing games using Xbox Live's save data requires authorization for the 'TitleStorage' service. This requires a device authenticated token and user token. However, the device token originally went through a Microsoft SOAP-based stage which required more effort than it was worth. Instead, using the 'wincred' storage was helpful as this is where the relevant Gaming Services on Windows caches tokens. This application to make the process more clean and easier.
+* MVG: {{YouTubeVideo|xCuu-TMquhk|Xbox 360 Emulation on the PC with Xenia takes a huge step forward}}, {{YouTubeVideo|MsnZsgfVLqk|Why Microsoft switched from Intel to Power PC for the Xbox 360}}, {{YouTubeVideo|F1aVBEyqnxA|The Story of Xbox 360 PartnerNet Game Leaks}}, {{YouTubeVideo|RyW0lXnoFOA|How a Mini drill tool defeated security on the Xbox 360}}, {{YouTubeVideo|Vq1lxeg_gNs|How the Xbox 360 Hypervisor Security was Defeated}}, {{YouTubeVideo|8gduINQMxd0|Why YOU need a Modded Xbox 360 in 2018}}, {{YouTubeVideo|zFGz4aT1cgo|The Xbox 360 is still awesome in 2019}}, {{YouTubeVideo|qxtMii5UKVQ|Xbox 360 Blades Dashboard}}, {{YouTubeVideo|IUK__yGXmds|MVG: Any Xbox 360 can now be hacked with just a USB Flash Drive}}
+* Digital Foundry: {{YouTubeVideo|LT1a6NXYy6E|Xbox Series X: Auto HDR Mode Tested - What Works and What Doesn't}}, {{YouTubeVideo|SzeBm0XBcOk|FPS Boost For Xbox 360 Games}}, {{YouTubeVideo|7oe1LUJyCCs|Xbox Series X Backwards Compatibility Tested}}
 ==PlayStation 3==
@@ Line 341: / Line 454: @@
 * [[Wikipedia:PSGL|PSGL API]]
-==See also==
+==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 {{YouTubeVideo|U7VwtOrwceo|"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 [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki].
+At least part of the Xbox One's optical disc drive source code leaked in 2020 ([https://gbatemp.net/threads/xbox-one-internal-sdk-has-leaked-the-ms-equivalent-to-a-gigaleak.579751/ "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.[https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump-games.html][https://x.com/onebawbag/status/1789333419261821032]
+It should also be noted that the vast majority of Xbox One games are also available on PC (similarly to [[PlayStation_4_emulators#Emulation_issues|PlayStation 4 (Pro)]], [[PlayStation_5_emulators#Emulation_issues|PlayStation 5 (Pro)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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;
+* [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki]
+* [https://consolemods.org/wiki/Xbox_One:Xbox_One_Mods_Wiki ConsoleMods: Xbox One]
+* [https://www.reddit.com/r/XboxHacking/comments/1d775um/how_xbox_oneseries_emulation_can_come_around_and/ Reddit Thread: "Explanation on Xbox One/Series emulation"]
+* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]
+* [https://github.com/OpenKinect/libfreenect2 libfreenect2] - Open source Driver for Kinect for Windows v2 (K4W2) devices (release and developer preview). libfreenect2 does not do anything for either Kinect for Windows v1 or Kinect for Xbox 360 sensors. Use [https://github.com/OpenKinect/libfreenect?tab=readme-ov-file libfreenect1] for those sensors.
+* [https://github.com/exploits-forsale/collateral-damage Collateral Damage] - Collateral Damage is a kernel exploit for Xbox SystemOS using CVE-2024-30088. It targets Xbox One and Xbox Series consoles running kernel versions 25398.4478, 25398.4908, and 25398.4909. The initial entrypoint is via the Game Script UWP application.
+* [https://github.com/Kudayasu/Artifice Artifice] - A custom tool designed to achieve privilege escalation autonomously for Xbox One Developer Mode.
+* [https://github.com/XWine1/XDLCompiler XDL Compiler]
+* [https://www.eurogamer.net/digitalfoundry-2017-xbox-one-x-back-compat-how-does-it-actually-work EuroGamer - Xbox One backwards compatibility: how does it actually work?]
+* {{YouTubeVideo|U7VwtOrwceo|835|Platform Security Summit: Guarding Against Physical Attacks: The Xbox One Story — Tony Chen, Microsoft}}
+* {{YouTubeVideo|quLa6kzzra0|similar video}}
+* WinDurango [https://discord.gg/mHN2BgH7MR Discord]
+* {{YouTubeVideo|DXSEhCQxqEQ|MattKC Bytes: Xbox One emulation is making INCREDIBLE progress in 2025}}
+==PS4==
+Due to the PS4's [[POS_(Pong_Consoles)_CPUs_and_Other_Chips#x86_CPUs|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<ref>{{cite web | url= https://en.wikipedia.org/wiki/x86_instruction_listings | title= x86 instruction listings | Wikipedia}}</ref>, 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 [https://www.playstation.com/en-us/games/pc-games/ PlayStation 4 (Pro)-exclusive titles are now being ported to PC] with enhancements, so similarly to [[PlayStation_5_emulators#Emulation_issues|PlayStation 5]], [[Xbox One emulators#Emulation issues|Xbox One (X|S)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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<ref>[https://discord.com/channels/252023769500090368/1140403882309202050/1173616669072044032 RPCSX discord channel: Various resources for reverse-engineering PlayStation 4].</ref>;
+*Modded Warfare: {{YouTubePlaylist|PLn7ji3VsPy3HCJZF4ivMhnpOt0vZA2g_j|PS4 Jailbreak Tutorials (9.00 or Lower)}}
+;General
+:;Graphics
+:*[https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ A trip through the Graphics Pipeline 2011]
+:*[https://vulkan-tutorial.com/ Vulkan Tutorial]
+:;Reversing
+:*[https://www.amazon.com/dp/0764574817/ Reversing: Secrets of Reverse Engineering (book)]
+:*[https://beginners.re/ Reverse Engineering for Beginners (book)]
+;PlayStation 4-specific
+:;CPU
+:*[https://software.intel.com/en-us/articles/intel-sdm#combined Intel® 64 and IA-32 Architectures Software Developer Manuals]
+:*[https://support.amd.com/TechDocs/48751_16h_bkdg.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h Models 00h-0Fh Processors]
+:*[https://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf Revision Guide for AMD Family 16h Models 00h-0Fh Processors]
+:*[https://support.amd.com/TechDocs/52128_16h_Software_Opt_Guide.zip Software Optimization Guide for AMD Family 16h Processors]
+:*[https://support.amd.com/TechDocs/48882_IOMMU.pdf AMD I/O Virtualization Technology (IOMMU) Specification]
+:;GPU
+:*[https://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture.pdf Sea Islands Series Instruction Set Architecture]
+:*[https://developer.amd.com/wordpress/media/2013/10/si_programming_guide_v2.pdf Southern Islands/Sea Islands Family 3D/Compute Programming Guide]
+:*[https://developer.amd.com/wordpress/media/2013/10/CIK_3D_registers_v2.pdf Radeon Sea Islands 3D/Compute Register Reference Guide]
+:;Misc.
+:*[http://www.psdevwiki.com/ps4/ PS4 Developer Wiki]
+:*[https://github.com/fail0verflow/ps4-linux Linux kernel fork with PS4 support]
+:*[https://github.com/fail0verflow/ps4-kexec Implementation of the kexec system call for PS4]
+:*{{YouTubeVideo|QMiubC6LdTA|Console Hacking 2016 (33C3)}}
+:*Open source projects (FreeBSD, AMDGPU drivers, etc.): [https://github.com/freebsd/freebsd-src/tree/releng/9.1 FreeBSD system calls], [https://github.com/GPUOpen-Drivers/pal GPUOpen-Drivers]
+:*RPCSX: [https://discord.gg/M6DK5AXk Discord], [https://rpcsx.github.io/rpcsx-site/ Blogs]
+:*ShadPS4: [https://discord.com/invite/bFJxfftGW6 Discord], [https://shadps4.net/all/1/ Blogs]
+==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 emulators#Emulation issues|Xbox One]] and even [[PlayStation_4_emulators#Emulation_issues|PS4]] and [[PlayStation_5_emulators#Emulation_issues|PS5]] due to Sony's [https://www.techpowerup.com/332928/former-sony-exec-views-first-party-ps5-to-pc-porting-as-almost-like-printing-money 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;
+* [https://xboxoneresearch.github.io/wiki/ Xbox One Research Wiki]
+* [https://www.reddit.com/r/XboxHacking/comments/1d775um/how_xbox_oneseries_emulation_can_come_around_and/ Reddit Thread: "Explanation on Xbox One/Series emulation"]
+* [https://github.com/MicrosoftDocs/xbox-live-docs Microsoft Xbox Live docs]
+* [https://github.com/exploits-forsale/collateral-damage Collateral Damage] - Collateral Damage is a kernel exploit for Xbox SystemOS using CVE-2024-30088. It targets Xbox One and Xbox Series consoles running kernel versions 25398.4478, 25398.4908, and 25398.4909. The initial entrypoint is via the Game Script UWP application.
+==PS5==
+On top of PlayStation 4 emulation issues, there are additional obstacles for PlayStation 5 emulation such as [https://www.radgametools.com/oodlekraken.htm 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 [https://elektricm.github.io/amd-bc250-docs/ 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 [https://www.playstation.com/en-us/games/pc-games/ PlayStation 5 exclusive titles are now being ported to PC] with enhancements, so similarly to [[PlayStation_4_emulators#Emulation_issues|PlayStation 4 (Pro)]], [[Xbox One emulators#Emulation issues|Xbox One (X|S)]] and [[Xbox_Series_X_and_Series_S#Emulation issues|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;
+*{{YouTubeVideo|5Cq3K9lBli0|MVG: The PS5 Jailbreak is here}}
+*Modded Warfare: {{YouTubePlaylist|PLn7ji3VsPy3E0uxCPaId_-ySd0cXusnJ5|PS5 Tutorials}}
+;General
+:;Graphics
+:*[https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ A trip through the Graphics Pipeline 2011]
+:*[https://vulkan-tutorial.com/ Vulkan Tutorial]
+:;Reversing
+:*[https://www.amazon.com/dp/0764574817/ Reversing: Secrets of Reverse Engineering (book)]
+:*[https://beginners.re/ Reverse Engineering for Beginners (book)]
+;PlayStation 5-specific
+:;CPU
+:*N/A
+:;GPU
+:*N/A
+:;Misc
+:*[https://www.psdevwiki.com/ps5/Main_Page PS5 Developer Wiki]
+:*Open source projects (FreeBSD, AMDGPU drivers, etc.): [https://github.com/freebsd/freebsd-src/tree/releng/9.1 FreeBSD system calls], [https://github.com/GPUOpen-Drivers/pal GPUOpen-Drivers]
+:*[https://www.reddit.com/r/PS5/comments/juggo1/has_anyone_done_an_nmap_scan_of_the_ps5_to/ Reddit Thread: Has anyone done an nmap scan of the PS5]
+==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. [https://github.com/punesemu/puNES/releases/tag/v0.111 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|Overscan}}
+[[File:Retroarch_2013-08-16_06-32-24-62.png|thumb|250px|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, ''[[wikipedia:Super_Mario_Bros._3|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 ''[[wikipedia:Castlevania#Games|Castlevania]]'' games.
+===Color palette===
+{{Main|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.
+==PC Engine (TurboGrafx-16)==
+===Color palette===
+[[File:PCE_TG16_Composite_RGB_Palette.png|thumb|250px|An example of the color inaccuracy with the regular RGB color palette when compared to the Composite palette. Take note of the second blue gradient in the sky in both images.]]
+The color palettes generated by the PC Engine for Composite and RGB actually differ due to its own color tables being non-linear. This can result in colors ending up looking wrong or blended when the system is emulated or played in RGB. A composite palette was eventually made mathematically and with some extra tweaks from the PC Engine's RGB to YUV lookup table after its HuC6270 video chip had been decapped. This palette is used by default in the PC Engine core for the [[MiSTer]]<ref>https://www.retrorgb.com/pc-engine-palette-improvements-the-amazing-people-behind-the-technology.html</ref>. It [https://github.com/Kitrinx/TG16_Palette can be downloaded] for use in other emulators and devices.
+==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/Low level emulation|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 [[Recommended N64 plugins|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,<ref>[https://github.com/Themaister/parallel-rdp#disclaimer 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."</ref> 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.<ref name="gliden64_blog-1">{{cite web|url=https://gliden64.blogspot.com/2017/|title=Public Release 3.0|publisher=Blogspot|accessdate=2018-06-17|date=2017-12-29}}</ref><ref name="ZSortBOSS">{{cite web|url=https://github.com/gonetz/GLideN64/issues/1685#issuecomment-364436534|title=Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer)|publisher=GitHub|accessdate=2018-06-17|date=2018-02-10}}</ref> This means that {{YouTubeVideo|HfCOnmRHI0o|Factor 5's games are now working in high-level graphics mode}}.<ref name="Indiegogo">{{cite web|url=https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-level-emulation#/updates/all|title="Indiana J. & Infernal Machine" HLE|publisher=Indiegogo|accessdate=2018-06-17|date=2018-05-17}}</ref><ref name="gliden64_blog-2">{{cite web|url=https://gliden64.blogspot.com/2018/05/hle-implementation-of-microcodes-for.html|title=HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.|publisher=Blogspot|accessdate=2018-06-17|date=2018-05-26}}</ref> 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).<gallery widths="300" mode="packed">
+File:Majora's_mask_accurate.png|Low-level emulation of Majora's Mask using SoftGraphic
+File:Project64_2013-07-26_14-20-17-55.png|High-level emulation of Majora's Mask using Jabo's Direct3D
+</gallery>
+=== [[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.<gallery widths="300" mode="packed">
+File:Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen displaying issues with filtered text.
+File:Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen displaying issues with filtering.
+</gallery>
+=== 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;
+* [https://www.youtube.com/@ModernVintageGamer/search?query=n64 MVG videos about Nintendo 64]
+* {{YouTubeVideo|xwls5SpNn1s|Kaze Emanuar: How we BEAT the Limitations that defined the N64s Artstyle}}
+* James Lambert: {{YouTubeVideo|r4KGm7ixcqI|How I optimized Portal to run on the Nintendo 64}}, {{YouTubeVideo|Sf036fO-ZUk|How I implemented MegaTextures on real Nintendo 64 hardware}}
+* [https://www.copetti.org/writings/consoles/nintendo-64/ Rodrigo Copetti: Nintendo 64 Architecture Analysis]
+* [https://n64brew.dev/wiki/Main_Page N64brew Wiki]
+==Nintendo GameCube and Wii==
+For more information about Nintendo GameCube hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|Uxjl_kD3imQ|How the Nintendo GameCube Security was defeated}}, {{YouTubeVideo|up6Rm1Sw1ps|The Nintendo GameCube is still awesome - Games, Homebrew, Modding and More}}, {{YouTubeVideo|HJHb3ZJXJfw|Dolphin has been ported to the Xbox}}
+* Dolphin: [https://dolphin-emu.org/blog/ Blog], [https://discord.gg/ZGbGN2mC Discord]
+* [https://gamecube.dev/ Awesome GameCube Development]
+* [https://www.copetti.org/writings/consoles/gamecube/ Rodrigo Colpetti's GameCube practical analysis]
+* [https://www.gc-forever.com/wiki/index.php?title=Main_Page GC-Forever]
+* [https://consolemods.org/wiki/GameCube:GameCube_Mods_Wiki ConsoleMods - GameCube]
+For more information about Nintendo Wii hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|4BlpONgj74A|How a pair of Tweezers defeated security on the Nintendo Wii}}, {{YouTubeVideo|F0EZQsFulJs|Homebrew Wars : Original Xbox vs Nintendo Wii}}, {{YouTubeVideo|VytQlGRq3jo|Online with the Nintendo Wii in 2019}}, {{YouTubeVideo|FHFuFuUFHagThe Nintendo Wii Shop is going offline forever. How to play WiiWare games in 2019}}, {{YouTubeVideo|hgMWtdayQxQ|Why did Nintendo Release the Wii MINI ? A look back}}, {{YouTubeVideo|rleF4f1dBVo|Hacking the Nintendo Wii Mini}}
+* Dolphin: [https://dolphin-emu.org/blog/ Blog], [https://discord.gg/ZGbGN2mC Discord]
+* [https://wiibrew.org/wiki/Main_Page WiiBrew]
+* [https://www.copetti.org/writings/consoles/wii/ Rodrigo Copetti's Wii practical analysis]
+==Nintendo Switch and Switch 2==
+For more information about Nintendo Switch hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|xQmN-cxg21M|How the Nintendo Switch Security was defeated}}
+* Ryujinx: [https://web.archive.org/web/20241007214154/https://blog.ryujinx.org Blog], [https://discord.gg/ryujinx Discord]
+* yuzu: [https://web.archive.org/web/20240304180918/https://yuzu-emu.org/entry/ Blog]
+* Torzu: [http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/src/branch/master/blog Blog] (NotABug [https://notabug.org/litucks/torzu/src/master/blog mirror])
+* [https://switchbrew.org/wiki/Main_Page SwitchBrew]
+* [https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering dekuNukem - Nintendo Switch reverse engineering attempts]
+* [https://reswitched.github.io/awesome/ ReSwitched - Awesome Switch: resources]
+The Switch 2's custom processor, unlike the vulnerable Tegra X1 with pre-existing exploits, is likely built with stronger security measures. With Nintendo [[Legal_status_and_history_of_emulation#Nintendo| targeting emulators like Yuzu and Ryujinx]], and their forks, hacking and emulator development have been discouraged. Homebrew development faces issues in the current environment. Even if a Switch 2 emulator emerges in a few years, it will likely be tightly controlled within private communities, limiting accessibility. See [https://gbatemp.net/threads/best-practice-for-preserving-switch-2-exploitability.671473/ GBATemp thread] for rumors about Switch 2 exploitability.
+=Handhelds=
+==Game Boy (Color)==
+===Oversaturation===
+[[File:Gbc over saturation2.png|thumb|right|350px|Comparison of saturation levels in [[VisualBoy Advance#VBA-M|VBA-M]] and [[Gambatte]].]]
+The Game Boy Color's screen is under-saturated. Game developers often work around this by using brighter colors knowing it'll be compensated for on hardware. This does not translate well in emulation, because standard LCD screens don't account for this sort of issue. Many emulators attempt to combat this issue with options that adjust accordingly; if not directly, then [[Shaders_and_Filters#Image_Adjustment|shader functionality]] may be implemented.
+This issue also affects [[Game Boy Advance emulators#Oversaturation|Game Boy Advance emulation]].
+====Emulator options====
+'''mGBA:''' Under Tools > Settings > Shaders, you will find three customizable '''Desaturation''' parameters.
+'''VBA-M:''' Under Options > Game Boy, you will find the '''GB color option'''. The recent nightly builds also include the '''LCD Filter''' option.
+For more information about Game Boy hardware and its reverse engineering;<br>
+* meganesu: [https://meganesu.github.io/generate-gb-opcodes/ Game Boy CPU Instructions]
+* Rodrigo Copetti: [https://www.copetti.org/writings/consoles/game-boy/ Game Boy Architecture Practical Analysis]
+* MVG: {{YouTubeVideo|zQE1K074v3s|How Graphics worked on the Nintendo Game Boy}}, {{YouTubeVideo|FzPTK91EJY8|Learn to code and write games on the Nintendo Game Boy}}, {{YouTubeVideo|I1cUIGHZLGA|Secrets of the Nintendo Game Boy Boot Logo}}, {{YouTubeVideo|gYQMdox5gzI|How Cartridges worked on the Nintendo Game Boy}}
+* kOOPa and nocash: [https://problemkaputt.de/pandocs.htm Pan Docs]
+* [https://gbdev.gg8.se/wiki/articles/Main_Page Game Boy Development Wiki]
+==Game Boy Advance==
+===Oversaturation===
+[[File:1406913527173-1-.png|400px|thumb|right|'''Left:''' The default game.<br>'''Right:''' The "Game Boy Colors" mode on [[VisualBoy Advance#VBA-M|VBA-M]].]]
+The screen on the original Game Boy Advance is not backlit and can be hard to see in some conditions. To compensate, game developers often used oversaturated colors by default so that the result would look normal on hardware. On standard computer screens, saturation is not an issue, so this can look jarring and undesirable for gameplay. Some games made after 2003 may have also taken the Game Boy Advance SP model (AGS-001) into account, since its screen was actually frontlit; a newer model, AGS-101, was released in 2005 that was actually backlit. For everything else though, emudevs have given some solutions:
+====Emulator Options====
+'''No$GBA:''' Under "Emulation Options," select "GBA Mode". There are four modes.
+* '''GBA (no backlight):''' Strong desaturation
+* '''GBA SP (backlight):''' Strong desaturation
+* '''Nintendo DS in GBA mode:''' Some desaturation
+* '''VGA Mode (poppy bright):''' No desaturation
+'''mGBA:''' Under Tools > Settings > Shaders > Load New Shader, select "gba-color.shader"
+'''VBA-M:''' (nightly only): Under Options > Game Boy Advance, you will find the option, '''LCD Filter'''.
+'''higan:''' Under Settings > Video Filter, you will find the "Color Emulation" checkbox.
+* '''Color Emulation off:''' No desaturation
+* '''Color Emulation on:''' Gamma correction and adjusted color range.
+ '''NanoBoyAdvance''': Enabled by default. Under Config > Video > Color Correction > GBA
+'''SkyEmu''': Color Correction is set by default to 1.00 force in this emulator, and there are 2 types of desaturation methods. The first one is named SkyEmu and is selected by default, and the other one is named Higan and, as its name suggests, is based on higan's color correction. Change the desaturation type by pressing the ≡ button, then select GBA Color Correction Type. You can also change the intensity of the desaturation: slide the slider to 0.00 to brighten the screen a tad bit.
+====Shaders====
+Cg [[Shaders and Filters|shaders]] can be used in [[OpenEmu]] or [[RetroArch]] that adjust the colors to those of a real GBA screen, as well as other screen types. These are available in GLSL<ref name="GLSL">https://github.com/libretro/glsl-shaders/tree/master/handheld/shaders/color</ref> for OpenGL, and Slang<ref name="Slang">https://github.com/libretro/slang-shaders/tree/master/handheld/shaders/color</ref> for Vulkan.
+For GBA, there is <code>gba-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/gba-color.cg</ref>, which simulates the color profile of a GBA screen under an external light source more accurately than VBA-M or No$GBA color options. If you prefer the darker color options that those emulators have, then use <code>vba-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/vba-color.cg</ref> instead.
+There is also <code>nds-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/nds-color.cg</ref> and <code>psp-color.cg</code><ref>https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/psp-color.cg</ref>, which simulates the color profiles of the original Nintendo DS frontlit screen and the PSP-1000/PSP-2000 backlit screen, respectively.
+For Game Boy Advance shader presets, see the "Shader Presets" page;
+{{Main|Shader_Presets}}
+===Horrible Sound Quality===
+As a handheld rushed to the market (because of the WonderSwan Color competition), the Game Boy Advance had some cut corners. The sound hardware was affected the hardest: while it could play Game Boy Color sound in addition to samples and sequenced music like what would be heard on the SNES, the actual playback quality is awful compared to the sound samples stored internally in the ROM.
+There were [https://www.romhacking.net/utilities/881/ tools] made to extract the internal high-quality music (as midi files plus a sound font, to be played on foobar2000); however, interest remains limited in implementing its playback in real-time on emulators. It's worth noting that NanoBoyAdvance includes an high quality audio mixer and there's a very experimental feature exists on [[mGBA]] (nightly versions) under Enhancements as "XQ GBA Audio", but it's very buggy and still limited to games using the standard sound engine, the so-called "Sappy" engine, which is still a big part of the GBA's software library.
+===High Resolution Affine Transformation Graphical Effects===
+Similarly to the scaling effects used on the Super NES known commonly as "Mode 7" graphics, the Game Boy Advance has affine transformation effects for some backgrounds and individual sprites that can be done in hardware. Due to the GBA's lower resolution, some detail may be lost.
+The [[mGBA]] emulator added an Enhancements menu where you can change the resolution of those graphical effects, for a smoother effect. The graphical render engine will need to be OpenGL for those to take effect. It won't work on games where those effects are done in software instead of the hardware scaling features (like the 3D environment in Asterix & Obelix XXL)
+===Save formats===
+Originally, when saves were implemented, nobody settled on a format, so the Visual Boy Advance devs made their own. Because other emulators often went with raw data, having to exchange different saves caused problems. The original Visual Boy Advance tries to figure out which format a given save is but often fails at it. By explicitly telling the emulator to read it as a specific type using a file called <code>vba-over.ini</code>, VBA complies. VBA-M includes this config file by default, but older revisions like VBA 1.7.2 and VBALink don't.
+The VBA-Next and VBA-M cores in Libretro have the file baked into the binary so that it can load raw .sav files. However, they convert the format to its own derivative at exactly 136 KB every time, with save type info contained within the file. This completely avoids the previous issues at the cost of incompatibility with standalone VBA and most others.
+To solve this incompatibility, Libretro devs created a
+[https://github.com/libretro/vba-next/blob/master/libretro/gbaconv/gbaconv.c command-line tool] to convert .srm save files made from these cores to raw .sav save data for other emulators. It takes standard input (i.e., drag and drop the .srm onto the executable) and outputs accordingly. It can also be done in reverse. A [https://thysbelon.github.io/gbaconv-web/ website version of this tool can be found here].
+For more information about Game Boy Advance hardware and its reverse engineering;<br>
+* Rodrigo Copetti: [https://www.copetti.org/writings/consoles/game-boy-advance/ Game Boy Advance Architecture Practical Analysis]
+* MVG: {{YouTubeVideo|R43k-p9XdIk|The Story of Quake on the Game Boy Advance}}, {{YouTubeVideo|_Qqg4VCZ0k8|How the Game Boy Advance knew it was running a Game Boy Game}}, {{YouTubeVideo|_GVSLcqGP7g|Tomb Raider on the Nintendo Game Boy Advance is incredible}}, {{YouTubeVideo|mpNWEbZdXNw|How Graphics worked on the Nintendo Game Boy Advance}}
+* martin korth: [https://problemkaputt.de/gbatek-contents.htm gbatek]
+* [https://akkera102.sakura.ne.jp/gbadev/ akkera102.sakura gbadev (Japanese)]
+* [https://gbadev.net/gbadoc/ gbadev - gbadoc]
+* [https://en.wikibooks.org/wiki/GBA_Development/Resources WikiBooks - GBA Development Resources]
+==PlayStation Portable==
+For more information about PSP hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|nCzY-QhBxaE|PSP in 2023}}, {{YouTubeVideo|qIxKPu20R58|How the Sony PlayStation Portable PSP Security was defeated}}, {{YouTubeVideo|vY1j30jzRsE|A closer look at the Sony PSP DTP-T1000 Development Kit}}, {{YouTubeVideo|3HfaAlS7ons|Another look at the Sony PSP GO Handheld in 2018}}
+* [https://www.copetti.org/writings/consoles/playstation-portable/ Rodrigo Copetti's PSP Architecture Practical Analysis]
+* PPSSPP: [http://www.ppsspp.org/blog/ Blog], [https://discord.gg/5NJB6dD Discord], [https://www.ppsspp.org/docs/development/ Docs]
+* [https://www.psdevwiki.com/psp/Main_Page PSDevWiki - PSP]
+==Nintendo 3DS==
+For more information about Nintendo 3DS hardware and its reverse engineering;
+* MVG: {{YouTubeVideo|YAKujG8SXKY|The most important Nintendo 3DS Game Ever Made}}, {{YouTubeVideo|jjFGxIfDX70|Homebrew on a $100 New Nintendo 3DS LL}}, {{YouTubeVideo|-guh8hXo1bc|The Nintendo 3DS eShop Is Going Offline Forever. How to Play All Games After 2023}},
+* Citra: [https://web.archive.org/web/20240304201632/https://citra-emu.org/tags/progress-report/ Blog]
+* Tanuki3DS: [https://discord.gg/6ya65fvD3g Discord]
+* Azahar: [https://azahar-emu.org/pages/bloglist/ Blog]
+* [https://www.3dbrew.org/wiki/Main_Page 3dbrew]
+* [https://wiki.gbatemp.net/wiki/3DS_Homebrew_Development GBATemp - 3DS Homebrew Development]
+* [https://3ds.hacks.guide/ 3DS Hacks Guide]
+* [https://fosdem.org/2024/schedule/event/fosdem-2024-1726-panda3ds-climbing-the-tree-of-3ds-emulation/ FOSDEM '24: Panda3DS - Climbing the tree of 3DS emulation]
+=See also=
 *[[Emulator scams]]
+*[[Console-specific development wikis]]
+*[[Emulation books and articles]]
+*[[Legal status and history of emulation]]
+*[[Licensing]]
+*[[Copy protection]]
+*[[Preservation projects]]
 [[Category:FAQs]]