Emulation accuracy: Difference between revisions

(17 intermediate revisions by 2 users not shown)

Line 1:

{{for|detailed explanation of emulation approach and which methods are implemented for mimicking the original hardware behavior|High and low-level emulation}}

;It's important to know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See [[#Perfection.3F|"perfection"]] and [[#Controversy|"controversy"]] sections.

;In the world of computing, terms mentioned below are often used interchangeably, leading to confusion. While they share some similarities, each technology serves a distinct purpose and operates at different levels. Within the realm of computer science, emulation occupies a niche distinct from virtualization or other techniques;

If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds [[Shaders,_presets_and_filters|CRT shaders]] as well. Not to mention the [[Computer_specifications#Recommended_Specifications|hardware intensive nature of very accurate emulators]] for later consoles may be at odds with the emulator's usability, especially with the recent collapse of [https://emulation.gametechwiki.com/index.php/Computer_specifications#Architecture_Recommendation:~:text=CGP%20Scaling%20and%20Microprocessor%20Law%20Eras Moore's Law] (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more.

*'''[[Hypervisors|Hypervisors/virtualization]]''' usually used for partitioning physical hardware resources among multiple guest operating systems

*'''[[Simulators]]''' where developers build virtual replicas of specific environments or processes

*'''[[:Category:Emulators|Emulation]]''' endeavors to recreate an entire historical architecture. This digital reconstruction seeks to faithfully capture the instruction set, timing behaviors, hardware features and even peripheral nuances of a bygone hardware platform. In years, lots of techniques and other technologies come in useful to emulator development which is mentioned in [[High/Low level emulation#Future Outlook]] section. Thanks to this, emulators achieve impressive levels of [[Frames_per_second|performance]] and compatibility, further unlocking the doors to historical software [[Preservation_projects|preservation]].

*'''[[Compatibility_layer|Compatibility/translation layers]]''' allow software written for one operating system to run on a different OS, often by translating system calls made by an application to their equivalent calls in the host operating system.

*'''[[Wrappers]]''' is a reimplementation of a library, where the goal is to substitute the original API with a better-supported interface. It works as a drop-in replacement for the original library, since a lot of software usually bundled it as-is without any fine-tuning. Wrappers are most common for proprietary interfaces that are either abandoned or otherwise platform-specific.

*'''Sandboxing''' creates a restricted environment for running applications on your Host operating system. Within this "sandbox," applications can't make permanent changes to your system files or registry.

*'''Docker''' is a containerization platform. It creates isolated containers that share the host operating system kernel but have their own set of files and configurations. Docker is primarily used for deploying and isolating applications, particularly microservices, for development, testing, and deployment purposes.

*'''[[FPGA]]''' is a type of microchip that can reconfigure itself after it has been manufactured, hence "field-programmable". The technology has found use in alternative to software emulation as it can reimplement the hardware without having to resort to any kind of binary translation to a computer platform's native code. Instead of adhering to an instruction set or a programming language, FPGA chips are instead programmed using a hardware descriptor language (HDL) that describes the components and logic needed to run the software. This programming isn't permanent; corrections and other changes can be made afterwards so that it isn't limited to one application like an ASIC.

If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds CRT shaders as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more.

==Types==

Line 26:

Line 17:

===High accuracy===

High accuracy is a level of ~~precision~~ that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or ~~even~~ [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. This approach focuses on replicating the original system's components as closely as possible, aiming to faithfully reproduce its behavior while staying mindful of hardware demands. ~~Though~~ it may ~~demand~~ more processing power compared to lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio/visual glitches and better handling of niche scenarios that creative programmers often implement. ~~Though they don't mimic~~ every clock cycle as precisely as cycle-accuracy, highly accurate emulators capture the essence of the original hardware very well. Also achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy. Some ~~of these~~ emulators ~~represent~~ an even more meticulous level of precision in replicating the original system compared to other ~~highly accurate~~ emulators, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources.

High accuracy is a level of emulation accuracy that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. This approach focuses on replicating the original system's components as closely as possible, aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Even though it may require more processing power compared to lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio/visual glitches and better handling of niche scenarios that creative programmers often implement. Despite not mimicking every clock cycle as precisely as cycle-accuracy, highly accurate emulators capture the essence of the original hardware very well. Also, achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy.

Some highly accurate emulators may display an even more meticulous level of precision in replicating the original system compared of other emulators of its category, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources.

===Cycle accuracy===

Line 44:

Line 37:

In summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and "full cycle-accuracy". These can be considered as subsets of "cycle accuracy." Due to technical challenges and [[Frames_per_second|performance]] considerations, emulators often employ either "partial cycle-accuracy" or "cycle-based accuracy" depending on the specific requirements.

Mesen, BlastEm, NanoBoyAdvance, Azayaka, MartyPC and Stella are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research.

[[Mesen]], [[BlastEm]], [[NanoBoyAdvance]], [[Azayaka]], [[MartyPC]] and [[Stella]] are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research.

====Partial cycle-accuracy====

Line 57:

Line 50:

This aims to mimic every aspect of the CPU's timing and behavior, including internal operations and interactions with other components like memory and I/O devices. This demands the highest processing power for emulation among the cycle level accuracy subsets.

:[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ Examples of fully cycle-accurate emulators: higan and ares].

====M-cycles vs. T-cycles====

Many systems differentiate between multiple types of hardware "cycles", which can cause confusion when discussing cycle-accuracy. Two of the most common terms used in emulation, especially for systems like the Game Boy, are the '''machine cycle (M-cycle)''' and the '''clock cycle (T-cycle)'''.

; '''T-cycle''' (clock cycle)

: A T-cycle (sometimes called a *T-state*) is the smallest timing unit generated by the hardware clock.

: For example, the Game Boy’s CPU runs at ~4.19 MHz, meaning it completes ~4.19 million T-cycles per second.

: Some hardware events (memory access phases, interrupt sampling, or PPU timing) occur at specific T-cycle boundaries.

; '''M-cycle''' (machine cycle)

: An M-cycle is a higher-level cycle composed of multiple T-cycles.

: On the Game Boy, '''1 M-cycle = 4 T-cycles'''.

: CPU instructions are usually measured in M-cycles (e.g., a 1-byte load instruction may take 2 M-cycles = 8 T-cycles).

Emulators that simulate only M-cycles group all four T-cycles into a single unit of work, which simplifies execution but may obscure timing-sensitive behavior.

Emulators that simulate T-cycles can update hardware every single clock tick, enabling more precise behavior such as correct interrupt timing, LCD effects, and edge-case hardware interactions.

In short:

* '''T-cycle accuracy''' = updates each clock tick → highest timing precision.

* '''M-cycle accuracy''' = updates once every group of clock ticks → simpler, faster, but less precise.

These concepts are important when distinguishing between partial cycle-accuracy, full cycle-accuracy, and subcycle accuracy.

{| class="wikitable" style="text-align:center; width:80%; margin:auto;"

|+ '''Comparison of M-cycles and T-cycles'''

! Feature

! T-cycle (Clock Cycle)

! M-cycle (Machine Cycle)

|-

! Basic definition

| Smallest unit of time generated by the hardware clock

| A group of T-cycles used by the CPU to perform a complete internal operation

|-

! Typical duration

| 1 clock tick (e.g., on Game Boy ≈ 238 ns)

| Several T-cycles bundled together (Game Boy: '''4 T-cycles''')

|-

! Hardware significance

| Memory access phases, interrupt checks, PPU/graphics timing, bus states

| CPU instruction steps such as fetch, decode, or execute phases

|-

! Example (Game Boy)

| CPU runs at ~4.19 MHz → ~4.19 million T-cycles per second

| 1 M-cycle = 4 T-cycles → ~1.05 million M-cycles per second

|-

! Emulation cost

| Highest performance cost – must update every clock tick

| Lower performance cost – allows batching of work

|}

===Subcycle accuracy===

Line 69:

Line 117:

Impinging upon chip accuracy, some chips, such as the Commodore 64's [[wikipedia:MOS_Technology_SID|SID]] are part digital and part analog. The analog part can be emulated in a discrete fashion, but it is often desirable to take those discrete steps at a multiple of the clock rate. However, the difference is usually not observable to other components in the emulated machine so although this is subcycle accuracy as some part of the state of the chip is known as a precision of greater than one cycle, it doesn't tend to affect the design of the emulator as a whole.

Example of a subcycle accurate emulator is BeesNES.[https://github.com/L-Spiro/BeesNES?tab=readme-ov-file#accuracy]

Example of a subcycle-accurate emulator is BeesNES.[https://github.com/L-Spiro/BeesNES?tab=readme-ov-file#accuracy]

===Gate-level accuracy===

Line 83:

Line 131:

===DICE===

This type is unique in that its method, [[DICE]], emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level and, although the results are accurate, [[Computer_specifications|you need a fast 64-bit CPU (for single thread performance)]] to run these arcade games at [[Frames_per_second|full speed]]. It's not as deep as gate or transistor-level emulation for other systems because chips are still treated as black boxes, though.

This type is unique in that its method, [[DICE]], emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level and, although the results are accurate, [[Computer_specifications|you need a fast 64-bit CPU (for single-thread performance)]] to run these arcade games at [[Frames_per_second|full speed]]. It's not as deep as gate or transistor-level emulation for other systems because chips are still treated as black boxes, though.

==Perfection?==

While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (i.e. [[PS1 Tests]]) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the [[wikipedia:MOS_Technology_6502|6502]], where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet.

While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle-accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (i.e. [[PS1 Tests]]) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the [[wikipedia:MOS_Technology_6502|6502]], where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet.

While any given emulator may not be perfect, that does not mean that the emulator is bad by any means. Writing an accurate emulator is extremely hard work, and while perfection may be nearly impossible at the moment, that doesn't mean that games can't be enjoyed. Work on archival via emulation has come a very long way since the emulators of the 1990s, and things are only getting better from here, with excellent emulators such as the previously mentioned [[higan]] and kevtris's [[FPGA]] cores being available to use right now. In other words, "good enough" goes a long way.

Line 102:

Line 150:

==Console revisions==

Many consoles have different internal hardware revisions which degrade accuracy or change the consoles' behavior in another way, such as the SNES 1CHIP (various games have minor issues, such as a small mess of pixels at the top of the screen in games such as ~~Super Ghouls 'n Ghosts or~~ Demon's Crest), Genesis Model 3 (fixed a bug that some games such as Gargoyles used), or PS2 SCPH-750XX (less compatibility with some PS2 games and PS1 games). These specific consoles are not generally emulated in their respective emulators, and those emulator developers tend to focus only on one revision.

Many consoles have different internal hardware revisions which degrade accuracy or change the consoles' behavior in another way, such as the SNES 1CHIP (various games have minor issues, such as a small mess of pixels at the top of the screen in games such as Demon's Crest), Genesis Model 3 (fixed a bug that some games such as Gargoyles used), or PS2 SCPH-750XX (less compatibility with some PS2 games and PS1 games). These specific consoles are not generally emulated in their respective emulators, and those emulator developers tend to focus only on one revision.

==Further reading==

Line 128:

Line 176:

*[http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html SNES Accuracy Tests]

[[Category:FAQs]]

~~===Projects===~~

*[https://github.com/aappleby/MetroBoy GateBoy]

*[https://github.com/iaddis/metalnes MetalNES]

*[https://sourceforge.net/projects/dice/files/DICE/ DICE]

@@ Line 1: / Line 1: @@
+{{for|detailed explanation of emulation approach and which methods are implemented for mimicking the original hardware behavior|High and low-level emulation}}
 ;It's important to know that emulation accuracy and compatibility are two different things; while how closely an emulator mimics the original hardware is important, don't mistake that for compatibility. Whether games run properly is a separate concern, accuracy can sometimes influence it. See [[#Perfection.3F|"perfection"]] and [[#Controversy|"controversy"]] sections.
-;In the world of computing, terms mentioned below are often used interchangeably, leading to confusion. While they share some similarities, each technology serves a distinct purpose and operates at different levels. Within the realm of computer science, emulation occupies a niche distinct from virtualization or other techniques;
+If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds [[Shaders,_presets_and_filters|CRT shaders]] as well. Not to mention the [[Computer_specifications#Recommended_Specifications|hardware intensive nature of very accurate emulators]] for later consoles may be at odds with the emulator's usability, especially with the recent collapse of [https://emulation.gametechwiki.com/index.php/Computer_specifications#Architecture_Recommendation:~:text=CGP%20Scaling%20and%20Microprocessor%20Law%20Eras Moore's Law] (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more.
-*'''[[Hypervisors|Hypervisors/virtualization]]''' usually used for partitioning physical hardware resources among multiple guest operating systems
-*'''[[Simulators]]''' where developers build virtual replicas of specific environments or processes
-*'''[[:Category:Emulators|Emulation]]''' endeavors to recreate an entire historical architecture. This digital reconstruction seeks to faithfully capture the instruction set, timing behaviors, hardware features and even peripheral nuances of a bygone hardware platform. In years, lots of techniques and other technologies come in useful to emulator development which is mentioned in [[High/Low level emulation#Future Outlook]] section. Thanks to this, emulators achieve impressive levels of [[Frames_per_second|performance]] and compatibility, further unlocking the doors to historical software [[Preservation_projects|preservation]].
-*'''[[Compatibility_layer|Compatibility/translation layers]]''' allow software written for one operating system to run on a different OS, often by translating system calls made by an application to their equivalent calls in the host operating system.
-*'''[[Wrappers]]''' is a reimplementation of a library, where the goal is to substitute the original API with a better-supported interface. It works as a drop-in replacement for the original library, since a lot of software usually bundled it as-is without any fine-tuning. Wrappers are most common for proprietary interfaces that are either abandoned or otherwise platform-specific.
-*'''Sandboxing''' creates a restricted environment for running applications on your Host operating system. Within this "sandbox," applications can't make permanent changes to your system files or registry.
-*'''Docker''' is a containerization platform. It creates isolated containers that share the host operating system kernel but have their own set of files and configurations. Docker is primarily used for deploying and isolating applications, particularly microservices, for development, testing, and deployment purposes.
-*'''[[FPGA]]''' is a type of microchip that can reconfigure itself after it has been manufactured, hence "field-programmable". The technology has found use in alternative to software emulation as it can reimplement the hardware without having to resort to any kind of binary translation to a computer platform's native code. Instead of adhering to an instruction set or a programming language, FPGA chips are instead programmed using a hardware descriptor language (HDL) that describes the components and logic needed to run the software. This programming isn't permanent; corrections and other changes can be made afterwards so that it isn't limited to one application like an ASIC.
-If emulators are accurate enough, it produces much fewer audio and video glitches, usually at the cost of more processing power needed. It's often achieved by using tighter synchronization. This means the more accurate an emulator is, the lesser deviations there are from real hardware behavior but the more demanding it is. In another way, instructions given to both the program and the hardware (original intentions) results in both outputting the same result (mimics). Ironically, that aspect might at times be at odds with how authentic the experience is, when it introduces [[input lag]]. A similar debate surrounds CRT shaders as well. Not to mention the hardware intensive nature of very accurate emulators for later consoles may be at odds with the emulator's usability, especially with the recent collapse of Moore's Law (in layman's terms, you can't just "buy a better PC" if semiconductor technology does not catch up fast enough with what it takes for accurate emulation that makes zero compromises for optimizing speed). As a result, accuracy and emulator authenticity continue to be controversial subjects and highly a matter of opinion depending on what aspect of the experience the user values more.
 ==Types==
@@ Line 26: / Line 17: @@
 ===High accuracy===
-High accuracy is a level of precision that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or even [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. This approach focuses on replicating the original system's components as closely as possible, aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Though it may demand more processing power compared to lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio/visual glitches and better handling of niche scenarios that creative programmers often implement. Though they don't mimic every clock cycle as precisely as cycle-accuracy, highly accurate emulators capture the essence of the original hardware very well. Also achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy. Some of these emulators represent an even more meticulous level of precision in replicating the original system compared to other highly accurate emulators, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources.
+High accuracy is a level of emulation accuracy that emulator developers strive for when achieving [[#Cycle_accuracy|cycle accuracy]] or [[#Partial cycle-accuracy|partial-cycle accuracy]] is not practical or necessary. This approach focuses on replicating the original system's components as closely as possible, aiming to faithfully reproduce its behavior while staying mindful of hardware demands. Even though it may require more processing power compared to lowly accurate emulators, pursuing a more accurate emulation experience can pay off in the form of fewer audio/visual glitches and better handling of niche scenarios that creative programmers often implement. Despite not mimicking every clock cycle as precisely as cycle-accuracy, highly accurate emulators capture the essence of the original hardware very well. Also, achieving 100% compatibility with commercially released games is a common goal for emulators with high accuracy.
+Some highly accurate emulators may display an even more meticulous level of precision in replicating the original system compared of other emulators of its category, this heightened level of accuracy often involves more sophisticated techniques, demanding increased computational resources.
 ===Cycle accuracy===
@@ Line 44: / Line 37: @@
 In summary, we can talk about three types of cycle emulation: "partial cycle-accuracy", "cycle-based accuracy" and "full cycle-accuracy". These can be considered as subsets of "cycle accuracy." Due to technical challenges and [[Frames_per_second|performance]] considerations, emulators often employ either "partial cycle-accuracy" or "cycle-based accuracy" depending on the specific requirements.
-Mesen, BlastEm, NanoBoyAdvance, Azayaka, MartyPC and Stella are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research.
+[[Mesen]], [[BlastEm]], [[NanoBoyAdvance]], [[Azayaka]], [[MartyPC]] and [[Stella]] are recognized for their cycle-accurate emulation, though for knowing the specific degree of cycle-by-cycle precision for each needs further research.
 ====Partial cycle-accuracy====
@@ Line 57: / Line 50: @@
 This aims to mimic every aspect of the CPU's timing and behavior, including internal operations and interactions with other components like memory and I/O devices. This demands the highest processing power for emulation among the cycle level accuracy subsets.
 :[https://old.reddit.com/r/emulation/comments/vy8cg7/ares_v129_has_been_released_crossplatform/ig4da06/ Examples of fully cycle-accurate emulators: higan and ares].
+====M-cycles vs. T-cycles====
+Many systems differentiate between multiple types of hardware "cycles", which can cause confusion when discussing cycle-accuracy. Two of the most common terms used in emulation, especially for systems like the Game Boy, are the '''machine cycle (M-cycle)''' and the '''clock cycle (T-cycle)'''.
+; '''T-cycle''' (clock cycle)
+: A T-cycle (sometimes called a *T-state*) is the smallest timing unit generated by the hardware clock.
+: For example, the Game Boy’s CPU runs at ~4.19 MHz, meaning it completes ~4.19 million T-cycles per second.
+: Some hardware events (memory access phases, interrupt sampling, or PPU timing) occur at specific T-cycle boundaries.
+; '''M-cycle''' (machine cycle)
+: An M-cycle is a higher-level cycle composed of multiple T-cycles.
+: On the Game Boy, '''1 M-cycle = 4 T-cycles'''.
+: CPU instructions are usually measured in M-cycles (e.g., a 1-byte load instruction may take 2 M-cycles = 8 T-cycles).
+Emulators that simulate only M-cycles group all four T-cycles into a single unit of work, which simplifies execution but may obscure timing-sensitive behavior.
+Emulators that simulate T-cycles can update hardware every single clock tick, enabling more precise behavior such as correct interrupt timing, LCD effects, and edge-case hardware interactions.
+In short:
+* '''T-cycle accuracy''' = updates each clock tick → highest timing precision.
+* '''M-cycle accuracy''' = updates once every group of clock ticks → simpler, faster, but less precise.
+These concepts are important when distinguishing between partial cycle-accuracy, full cycle-accuracy, and subcycle accuracy.
+{| class="wikitable" style="text-align:center; width:80%; margin:auto;"
+|+ '''Comparison of M-cycles and T-cycles'''
+! Feature
+! T-cycle (Clock Cycle)
+! M-cycle (Machine Cycle)
+|-
+! Basic definition
+| Smallest unit of time generated by the hardware clock
+| A group of T-cycles used by the CPU to perform a complete internal operation
+|-
+! Typical duration
+| 1 clock tick (e.g., on Game Boy ≈ 238 ns)
+| Several T-cycles bundled together (Game Boy: '''4 T-cycles''')
+|-
+! Hardware significance
+| Memory access phases, interrupt checks, PPU/graphics timing, bus states
+| CPU instruction steps such as fetch, decode, or execute phases
+|-
+! Example (Game Boy)
+| CPU runs at ~4.19 MHz → ~4.19 million T-cycles per second
+| 1 M-cycle = 4 T-cycles → ~1.05 million M-cycles per second
+|-
+! Emulation cost
+| Highest performance cost – must update every clock tick
+| Lower performance cost – allows batching of work
+|}
 ===Subcycle accuracy===
@@ Line 69: / Line 117: @@
 Impinging upon chip accuracy, some chips, such as the Commodore 64's [[wikipedia:MOS_Technology_SID|SID]] are part digital and part analog. The analog part can be emulated in a discrete fashion, but it is often desirable to take those discrete steps at a multiple of the clock rate. However, the difference is usually not observable to other components in the emulated machine so although this is subcycle accuracy as some part of the state of the chip is known as a precision of greater than one cycle, it doesn't tend to affect the design of the emulator as a whole.
-Example of a subcycle accurate emulator is BeesNES.[https://github.com/L-Spiro/BeesNES?tab=readme-ov-file#accuracy]
+Example of a subcycle-accurate emulator is BeesNES.[https://github.com/L-Spiro/BeesNES?tab=readme-ov-file#accuracy]
 ===Gate-level accuracy===
@@ Line 83: / Line 131: @@
 ===DICE===
-This type is unique in that its method, [[DICE]], emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level and, although the results are accurate, [[Computer_specifications|you need a fast 64-bit CPU (for single thread performance)]] to run these arcade games at [[Frames_per_second|full speed]]. It's not as deep as gate or transistor-level emulation for other systems because chips are still treated as black boxes, though.
+This type is unique in that its method, [[DICE]], emulates arcade machines from the early 1970s. The architecture of these systems is different from a modern architecture, mostly because they don't have a CPU. DICE emulates the discrete logic components of the machines at a circuit level and, although the results are accurate, [[Computer_specifications|you need a fast 64-bit CPU (for single-thread performance)]] to run these arcade games at [[Frames_per_second|full speed]]. It's not as deep as gate or transistor-level emulation for other systems because chips are still treated as black boxes, though.
 ==Perfection?==
-While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (i.e. [[PS1 Tests]]) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the [[wikipedia:MOS_Technology_6502|6502]], where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet.
+While it may be theoretically possible to have a 100% perfect emulator, that feat is very rare (if not nearly impossible), even for some highly regarded emulators such as [[higan]] or kevtris's work on the various FPGA-based consoles by Analogue. Just because an emulator claims to be "cycle-accurate" or "100% compatible" does not mean that said emulator is flawless. This even includes situations in which all emulator accuracy tests (i.e. [[PS1 Tests]]) are passed, as these tests cannot cover every single edge case, and some of these tests may even fail on real hardware, leading to even more confusion. Some things are nearly impossible to perfectly emulate, such as some of the illegal opcodes of the [[wikipedia:MOS_Technology_6502|6502]], where the results are completely unpredictable on hardware, and different hardware revisions have different results and different illegal opcodes. The closest one could get to writing a perfect emulator would be if someone were to exactly copy an original ASIC map or a decap onto an FPGA, and even then, that isn't always a magic bullet.
 While any given emulator may not be perfect, that does not mean that the emulator is bad by any means. Writing an accurate emulator is extremely hard work, and while perfection may be nearly impossible at the moment, that doesn't mean that games can't be enjoyed. Work on archival via emulation has come a very long way since the emulators of the 1990s, and things are only getting better from here, with excellent emulators such as the previously mentioned [[higan]] and kevtris's [[FPGA]] cores being available to use right now. In other words, "good enough" goes a long way.
@@ Line 102: / Line 150: @@
 ==Console revisions==
-Many consoles have different internal hardware revisions which degrade accuracy or change the consoles' behavior in another way, such as the SNES 1CHIP (various games have minor issues, such as a small mess of pixels at the top of the screen in games such as Super Ghouls 'n Ghosts or Demon's Crest), Genesis Model 3 (fixed a bug that some games such as Gargoyles used), or PS2 SCPH-750XX (less compatibility with some PS2 games and PS1 games). These specific consoles are not generally emulated in their respective emulators, and those emulator developers tend to focus only on one revision.
+Many consoles have different internal hardware revisions which degrade accuracy or change the consoles' behavior in another way, such as the SNES 1CHIP (various games have minor issues, such as a small mess of pixels at the top of the screen in games such as Demon's Crest), Genesis Model 3 (fixed a bug that some games such as Gargoyles used), or PS2 SCPH-750XX (less compatibility with some PS2 games and PS1 games). These specific consoles are not generally emulated in their respective emulators, and those emulator developers tend to focus only on one revision.
 ==Further reading==
@@ Line 128: / Line 176: @@
 *[http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html SNES Accuracy Tests]
 [[Category:FAQs]]
-===Projects===
-*[https://github.com/aappleby/MetroBoy GateBoy]
-*[https://github.com/iaddis/metalnes MetalNES]
-*[https://sourceforge.net/projects/dice/files/DICE/ DICE]