Verifying console/emulator behavior with 8F
Posted by: TheZZAZZGlitch
Date: 2016-07-20 02:50:32
If my request gets some interest, this table will be filled with data regarding the most important systems.
Also let me know if someone thinks of another relevant test to add.
Last updated 2016-07-22
[table]
[tr]
[td]Platform[/td][td]UnknownOpcodes[/td][td]InvalidBanks[/td][td]VRAMAccess[/td][td]EchoRAM[/td][td]InvalidStop[/td]
[/tr]
[tr][td]Game Boy Color (CGB-001) [/td]
[td]PASS4[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td][/tr]
[tr][td]Game Boy Advance SP (AGS-001) [/td]
[td]PASS4[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td][/tr]
[tr][td]Game Boy Player [/td]
[td]PASS4[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td][/tr]
[tr][td]3DS Virtual Console [/td]
[td]FAIL5[/td]
[td]FAIL6[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]FAIL[/td][/tr]
[tr][td]Stadium 2 GB Tower [/td]
[td]PASS7[/td]
[td]PASS[/td]
[td]FAIL8[/td]
[td]FAIL9[/td]
[td]FAIL[/td][/tr]
[tr][td]bgb 1.4.1 [/td]
[td]PASS1[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td][/tr]
[tr][td]VBA-RR v24 svn440 [/td][td]PASS2[/td][td]PASS[/td][td]PASS[/td][td]PASS[/td][td]FAIL[/td][/tr]
[tr][td]VBA 1.7.2 [/td][td]PASS2[/td][td]FAIL3[/td][td]FAIL[/td][td]FAIL[/td][td]FAIL[/td][/tr]
[tr][td]MyOldBoy v1.1.0 [/td]
[td]FAIL[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]FAIL[/td][/tr]
[tr][td]LameboyDS v0.12 [/td]
[td]FAIL[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS[/td]
[td]PASS10[/td][/tr]
[/table]
1 - the emulator breaks into a debugger every time an undefined opcode is encountered
2 - brings up the infamous message "unknown opcode xx at yyyy"
3 - the result is 127 instead of 124 - this behavior needs to be more thoroughly investigated
4 - the game hangs without any message
5 - unknown opcodes are ignored, most likely because of the emulator hooking them to communicate with the hardware
6 - (probably) always returns 0
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
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
9 - some other data seems to be stored in the echo RAM area
10 - some corrupted stops work, some not - this is to be expected with undefined behavior
The tests themselves:
UnknownOpcodes
Self-explanatory. This is intended to test whether the target system ignores invalid opcodes, or crashes/halts when they are executed. This behavior could potentially affect any glitches that execute data as code (invalid sound banks, invalid item/move effect pointers).
[tt]8F
(Any)
TM27 x201[/tt]
opcode_e3
ret
If the game continues running after executing the script - FAIL
If the system brings up an error message or the game hangs or crashes - PASS
InvalidBanks
This checks how the system handles switching to non-existent ROM banks. This determines the behavior of glitches that cause invalid bank switches - most commonly invalid sound banks or invalid predefined commands.
[tt]8F
(Any)
Lemonade x65
Repel x32
X Speed x79
Ultra Ball x198
Fire Stone x71
Moon Stone x35
Water Stone x201[/tt]
ld a,41
ld e,20
ld b,e
ld c,a
ld (bc),a
add 20
ld b,a
ld a,(bc)
inc hl
ldi (hl),a
ret
The third item's quantity changes to 124 - PASS.
Third item's quantity changes to something other than 124, like 255 or 0 - FAIL.
Remember to reset item 3's quantity if you want to repeat the test.
VRAMAccess
VRAM data can only be read or written during V-Blank, H-Blank, or when the LCD screen is turned off. Otherwise, the write operation will be ignored, and all read operations will return FF. This test checks this behavior. Emulation of VRAM inaccessibility is essential for correct behavior of a lot of popular glitches, including Cooltrainer, Super Glitch, Brock Through Walls and any other glitches that attempt to "search through the entire address space".
[tt]8F
(Any)
Lemonade xAny
Repel x144
X Speed x175
PP Up x35
Moon Stone x34
TM01 xAny[/tt]
ld a,??
ld e,90
ld b,e
xor a
ld c,a
inc hl
ld a,(bc)
ldi (hl),a
ret
Run the script multiple times in a row and observe the quantity of the third item.
If it changes seemingly randomly between 255 and any other value - PASS
If it never becomes 255, even after trying multiple times - FAIL
EchoRAM
Because of how GB's address line works, RAM addresses $C000~$DDFF are mirrored at $E000~$FDFF. This repeated section of memory is called the echo RAM. Because this feature was hardly used by anyone, several emulators don't support it. This test is intended to verify whether echo RAM is emulated correctly. Emulation of this feature changes the behavior of glitches that cause extensive memory corruption, like Pokemon beyond the sixth slot, or Dokokashira Door Glitch. Also, Coin Case arbitrary code execution won't work without echo RAM emulation.
[tt]8F
(Any)
Lemonade xAny
Repel x241
X Speed x44
Fresh Water x175
TM06 x88
PP Up x10
Water Stone x201[/tt]
ld a,00
ld e,f1
ld b,e
inc l
inc a
xor a
adc a,58
ld c,a
ld a,(bc)
ldi (hl),a
ret
Run the script and check the quantity of item 3.
If it changes to the code of the first letter in the player's name - PASS
If it doesn't change, or changes to a wrong value, like FF or 00 - FAIL
InvalidStop
This is to test how the system reacts to invalid STOP opcodes. This behavior could affect some of the non-ACE Coin Case glitches, along with all glitches that execute data as code (invalid sound banks, invalid item/move effect pointers)
[tt]8F
(Any)
Full Restore x??
TM01 xAny[/tt]
stop ??
ret
Start with an arbitrary amount of Full Restores.
Run the 8F script. If the game crashes/halts whenever the script is executed - PASS
If not, try running the script with a different amount of Full Restores and repeat the process.
If after several tries the game is still running - FAIL.