Emulator behavior differences: Difference between revisions

From Glitch City Wiki
Jump to navigation Jump to search
Content added Content deleted
(→‎Overview: Added the "Non-executable memory sections" column, changed the column header format (spaces and capitalization), and used red color to mark up the fail (different) cases.)
(→‎GB/GBC: Trying to put the footnotes (detailed explanations) into separate subsections with hyperlinks for navigation.)
 
Line 6: Line 6:


{| class=wikitable
{| class=wikitable
! Platform !! Unknown opcodes !! Invalid banks !! VRAM access !! Echo RAM !! Invalid stop !! Non-executable memory sections
! Platform !! Invalid opcodes !! Invalid banks !! VRAM access !! Echo RAM !! Invalid stop !! Non-executable memory sections
|-
|-
| Game Boy Color (CGB-001) || PASS<sup>4</sup> || PASS || PASS || PASS || PASS || None
| Game Boy Color (CGB-001) || [[#gb-invalid-opcode-consoles|Hang]] || PASS || PASS || PASS || PASS || None
|-
|-
| Game Boy Advance SP (AGS-001) || PASS<sup>4</sup> || PASS || PASS || PASS || PASS || None
| Game Boy Advance SP (AGS-001) || [[#gb-invalid-opcode-consoles|Hang]] || PASS || PASS || PASS || PASS || None
|-
|-
| Game Boy Player || PASS<sup>4</sup> || PASS || PASS || PASS || PASS || None
| Game Boy Player || [[#gb-invalid-opcode-consoles|Hang]] || PASS || PASS || PASS || PASS || None
|-
|-
| 3DS Virtual Console || {{color|red|FAIL<sup>5</sup>}} || {{color|red|FAIL<sup>6</sup>}} || PASS || PASS || {{color|red|FAIL}} || {{color|red|VRAM, SRAM}}
| 3DS Virtual Console || [[#gb-invalid-opcode-vc|{{color|red|Ignore}}]] || {{color|red|FAIL<sup>2</sup>}} || PASS || PASS || {{color|red|FAIL}} || {{color|red|VRAM, SRAM}}
|-
|-
| Stadium 2 GB Tower || PASS<sup>7</sup> || PASS || {{color|red|FAIL<sup>8</sup>}} || {{color|red|FAIL<sup>9</sup>}} || {{color|red|FAIL}} || ?
| Stadium 2 GB Tower || [[#gb-invalid-opcode-gb-tower|Message]] || PASS || {{color|red|FAIL<sup>3</sup>}} || {{color|red|FAIL<sup>4</sup>}} || {{color|red|FAIL}} || ?
|-
|-
| bgb 1.4.1 || PASS<sup>1</sup> || PASS || PASS || PASS || PASS || None
| bgb 1.4.1 || [[#gb-invalid-opcode-bgb|Debugger]] || PASS || PASS || PASS || PASS || None
|-
|-
| VBA-RR v24 svn440 || PASS<sup>2</sup> || PASS || PASS || PASS || {{color|red|FAIL}} || ?
| VBA-RR v24 svn440 || [[#gb-invalid-opcode-vba|Message]]|| PASS || PASS || PASS || {{color|red|FAIL}} || ?
|-
|-
| VBA 1.7.2 || PASS<sup>2</sup> || {{color|red|FAIL<sup>3</sup>}} || {{color|red|FAIL}} || {{color|red|FAIL}} || {{color|red|FAIL}} || ?
| VBA 1.7.2 || [[#gb-invalid-opcode-vba|Message]] || {{color|red|FAIL<sup>1</sup>}} || {{color|red|FAIL}} || {{color|red|FAIL}} || {{color|red|FAIL}} || ?
|-
|-
| MyOldBoy v1.1.0 || {{color|red|FAIL}} || PASS || PASS || PASS || {{color|red|FAIL}} || ?
| MyOldBoy v1.1.0 || [[#gb-invalid-opcode-ignore|{{color|red|Ignore}}]] || PASS || PASS || PASS || {{color|red|FAIL}} || ?
|-
|-
| LameboyDS v0.12 || {{color|red|FAIL}} || PASS || PASS || PASS || PASS<sup>10</sup> || ?
| LameboyDS v0.12 || [[#gb-invalid-opcode-ignore|{{color|red|Ignore}}]] || PASS || PASS || PASS || PASS<sup>5</sup> || ?
|}
|}


1 - the result is 127 instead of 124 - this behavior needs to be more thoroughly investigated
1 - the emulator breaks into a debugger every time an undefined opcode is encountered


2 - (probably) always returns 0
2 - brings up the infamous message "unknown opcode xx at yyyy"


3 - (probably) always returns 255 - so VRAM access is enabled not during the V-Blank period, but during the V-Blank interrupt, which changes things dramatically
3 - the result is 127 instead of 124 - this behavior needs to be more thoroughly investigated


4 - some other data seems to be stored in the echo RAM area
4 - the game hangs without any message


5 - some corrupted stops work, some not - this is to be expected with undefined behavior
5 - unknown opcodes are ignored, most likely because of the emulator hooking them to communicate with the hardware


=== Invalid opcodes ===
6 - (probably) always returns 0
Out of all 256 possible values for a byte, most are defined as the opcode for some GB ASM instruction (as a special case, 0xCB is defined as the first byte of a group of two-byte ASM instructions). However, there are 11 '''invalid opcodes''', i.e. byte values that don't correspond to any assembly instruction, namely 0xD3, 0xDB, 0xDD, 0xE3, 0xE4, 0xEB, 0xEC, 0xED, 0xF4, 0xFC, and 0xFD.

* {{anchor|gb-invalid-opcode-consoles}}On real consoles, invalid opcodes hangs the game completely, hard-locking the CPU. The screen freezes as is, and the game audio becomes "stuck" on the note that was playing at the time of the freeze, if any.
7 - displays a message: "The saved data has been corrupted, so it is impossible to CONTINUE. Please reset the game and choose NEW GAME", the save is not corrupted though
* Some emulators display an error message upon encountering an invalid opcode, in addition to freezing the game. Since the real console would be unable to take input or generate meaningful output anyway, this is not considered an emulation inaccuracy.

** {{anchor|gb-invalid-opcode-gb-tower}}Stadium 2 GB Tower displays the following message: "The saved data has been corrupted, so it is impossible to CONTINUE. Please reset the game and choose NEW GAME", even though the save data is not actually corrupted (unless, of course, it is a corrupt save that causes the invalid opcode to be encountered).
8 - (probably) always returns 255 - so VRAM access is enabled not during the V-Blank period, but during the V-Blank interrupt, which changes things dramatically
** {{anchor|gb-invalid-opcode-vba}}VBA displays the infamous message "Unknown opcode xx at yyyy".

** {{anchor|gb-invalid-opcode-bgb}}BGB breaks into a debugger every time an undefined opcode is encountered.
9 - some other data seems to be stored in the echo RAM area
* {{anchor|gb-invalid-opcode-ignore}}Some emulators silently ignore invalid opcodes, which '''is''' considered an emulation inaccuracy since this may cause glitches to exhibit behaviors that do not happen on real hardware, possibly destructive (e.g. corruption of the save file).

** {{anchor|gb-invalid-opcode-vc}}In particular, the 3DS Virtual Console ignores invalid opcodes, probably because the emulator hooks them to communicate with the hardware, essentially using them as an extension of the GB ASM instruction set.
10 - some corrupted stops work, some not - this is to be expected with undefined behavior


== References ==
== References ==

Latest revision as of 04:48, 8 April 2024

Most game console emulators are never intended to emulate the real hardware perfectly, as their goal is just to provide a "good enough" emulation to play games on. Even in cases where the emulator does want to replicate some certain feature, emulation accuracy bugs can be difficult to avoid due to the intricacies of the hardware. This page documents some known behavior differences between emulators and real consoles.

GB/GBC

Overview

The following table[1] summarizes some features on GB/GBC where emulators commonly behave differently from the real hardware.

Platform Invalid opcodes Invalid banks VRAM access Echo RAM Invalid stop Non-executable memory sections
Game Boy Color (CGB-001) Hang PASS PASS PASS PASS None
Game Boy Advance SP (AGS-001) Hang PASS PASS PASS PASS None
Game Boy Player Hang PASS PASS PASS PASS None
3DS Virtual Console Ignore FAIL2 PASS PASS FAIL VRAM, SRAM
Stadium 2 GB Tower Message PASS FAIL3 FAIL4 FAIL ?
bgb 1.4.1 Debugger PASS PASS PASS PASS None
VBA-RR v24 svn440 Message PASS PASS PASS FAIL ?
VBA 1.7.2 Message FAIL1 FAIL FAIL FAIL ?
MyOldBoy v1.1.0 Ignore PASS PASS PASS FAIL ?
LameboyDS v0.12 Ignore PASS PASS PASS PASS5 ?

1 - the result is 127 instead of 124 - this behavior needs to be more thoroughly investigated

2 - (probably) always returns 0

3 - (probably) always returns 255 - so VRAM access is enabled not during the V-Blank period, but during the V-Blank interrupt, which changes things dramatically

4 - some other data seems to be stored in the echo RAM area

5 - some corrupted stops work, some not - this is to be expected with undefined behavior

Invalid opcodes

Out of all 256 possible values for a byte, most are defined as the opcode for some GB ASM instruction (as a special case, 0xCB is defined as the first byte of a group of two-byte ASM instructions). However, there are 11 invalid opcodes, i.e. byte values that don't correspond to any assembly instruction, namely 0xD3, 0xDB, 0xDD, 0xE3, 0xE4, 0xEB, 0xEC, 0xED, 0xF4, 0xFC, and 0xFD.

  • On real consoles, invalid opcodes hangs the game completely, hard-locking the CPU. The screen freezes as is, and the game audio becomes "stuck" on the note that was playing at the time of the freeze, if any.
  • Some emulators display an error message upon encountering an invalid opcode, in addition to freezing the game. Since the real console would be unable to take input or generate meaningful output anyway, this is not considered an emulation inaccuracy.
    • Stadium 2 GB Tower displays the following message: "The saved data has been corrupted, so it is impossible to CONTINUE. Please reset the game and choose NEW GAME", even though the save data is not actually corrupted (unless, of course, it is a corrupt save that causes the invalid opcode to be encountered).
    • VBA displays the infamous message "Unknown opcode xx at yyyy".
    • BGB breaks into a debugger every time an undefined opcode is encountered.
  • Some emulators silently ignore invalid opcodes, which is considered an emulation inaccuracy since this may cause glitches to exhibit behaviors that do not happen on real hardware, possibly destructive (e.g. corruption of the save file).
    • In particular, the 3DS Virtual Console ignores invalid opcodes, probably because the emulator hooks them to communicate with the hardware, essentially using them as an extension of the GB ASM instruction set.

References

This article or section is a stub. You can help Glitch City Wiki by expanding it.