Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation II Glitch Discussion

Generation II's item 00h - Page 1

Generation II's item 00h

Posted by: SatoMew
Date: 2015-01-31 13:17:21
"?" (hex:00) crashes English Crystal when forced into the Bag and the player accesses it, while it loads fine in Japanese Crystal, where it has a garbled and meaningless description too.

Can anyone reproduce this or is it just me? I'm using BGB 1.5.1.

Japanese Crystal codes:
01xx85D8 (specifies the number of items in the Items pocket of the Bag; for this case, let's consider xx=01)
010086D8 (adds 00h item as first in the list)
01xx87D8 (specifies the amount for the first item on the list; using xx=01 here as example)
01FFxxD8 (ends the list; xx=88 in this particular situation)

The codes for English Crystal are already on the wiki.

Re: Generation II's item 00h

Posted by: Háčky
Date: 2015-01-31 15:04:15
Its not just you.

The pointer table of item descriptions is at $02C02D in Japanese Crystal or $1C8987 in English Crystal. In Gold and Silver, this table had 256 entries, giving a dummy description for every glitch item, but for some reason in Crystal it only has 255 entries, so the pointer to item $00s description is taken from the first two bytes after the end of the table, which is the first two characters of the text for the Master Balls description.

In English, that description is The best BALL. It never misses., which is read as a pointer to $A793 (T = $93, h = $A7), an SRAM location with undefined behavior. In Japanese, that description is 「なつまの」, which is read as a pointer to $1F54 (「」 = $54, 「」 = $1F), in ROM bank 0. The data at this location provides the nonsensical, but surprisingly short description 「きき」

Re: Generation II's item 00h

Posted by: pokechu22
Date: 2015-01-31 15:18:56
Tested with English version on console (using 91 versions of codes, not 01).  It crashes basically the same way it does on BGB.

I used these codes for that:


910192D8
910093D8


Note that unlike BGB, on-console it did the normal reset and then "HEY YOU NEED A CGB" screen.

I then did this:


910292D8
910193D8
910095D8
010594D8
010196D8


(that 05 in the 4th code was a typo, but it was what I typed on-console.  Same effect)

This causes a crash, but only once I scroll down.  It first it writes a bunch of stuff to the text box, then does the low-hp sound, and then does the CGB screen crash.

It's much easier to test this when walking out of bounds at the start of the game, since you happen to get a ?. 

Re: Generation II's item 00h

Posted by: Bert
Date: 2015-01-31 16:24:30

Tested with English version on console (using 91 versions of codes, not 01).  It crashes basically the same way it does on BGB.

I used these codes for that:


910192D8
910093D8


Note that unlike BGB, on-console it did the normal reset and then "HEY YOU NEED A CGB" screen.

I then did this:


910292D8
910193D8
910095D8
010594D8
010196D8


(that 05 in the 4th code was a typo, but it was what I typed on-console.  Same effect)

This causes a crash, but only once I scroll down.  It first it writes a bunch of stuff to the text box, then does the low-hp sound, and then does the CGB screen crash.

It's much easier to test this when walking out of bounds at the start of the game, since you happen to get a ?. 


Changing 05 in line 4 of the second code changes the Master Ball's value; 55 gives you 85 of 'em.

You can get rid of the "?" item by changing the 00 in line 3 to a different value, but I don't imagine that's the point.

Line 1 really fucks up your scrolling, though, since the cursor won't go past the 2nd item; changing it to a value greater than what's currently in your ITEMS pocket will let you keep scrolling down, until it starts showing information from the KEY ITEMS area.

This batch of information you probably already know was brought to you by SCIENCE!

Re: Generation II's item 00h

Posted by: SatoMew
Date: 2015-01-31 17:45:05
@Háčky, thanks for the explanation. I guess this also would explain the differences in the descriptions of HM08-10 and 12 between Gold/Silver and Crystal, which according to Bulbapedia, changed from "?" in Gold/Silver to the descriptions of other moves in Crystal.

@pokechu22, how far did you scroll down? Did you end the list using 01FFxxD8?

Re: Generation II's item 00h

Posted by: pokechu22
Date: 2015-01-31 17:50:53

@pokechu22, how far did you scroll down? Did you end the list using 01FFxxD8?


I scrolled down only one, and then the game froze when it attempted to load 00h's description.

I didn't terminate the list (though I probably should have).  Probably wouldn't make a difference though, since my goal was only to test what happen when viewing 00h's description. 

Re: Generation II's item 00h

Posted by: Háčky
Date: 2015-01-31 19:46:30

@Háčky, thanks for the explanation. I guess this also would explain the differences in the descriptions of HM08-10 and 12 between Gold/Silver and Crystal, which according to Bulbapedia, changed from "?" in Gold/Silver to the descriptions of other moves in Crystal.

Actually, theres a simple explanation for thatin Crystal, the Move Tutors moves are treated as HM08HM10. Even though the item descriptions table has entries for all the TMs and HMs (which all point to several copies of the description ?), the game looks up which move is taught by the TM/HM and uses that moves description instead. (For whatever reason, the list of TM/HM moves ends with HM11, and HM12 is read as Rollout in all Generation II games.)

Re: Generation II's item 00h

Posted by: SatoMew
Date: 2015-02-01 09:34:11

I didn't terminate the list (though I probably should have).  Probably wouldn't make a difference though, since my goal was only to test what happen when viewing 00h's description.


Well, if you don't terminate the list, it'll always crash after you scroll down to a position without a valid item, regardless of the item in question (this is my experience in BGB). But yes, it doesn't change in 00h's case.


Actually, theres a simple explanation for thatin Crystal, the Move Tutors moves are treated as HM08HM10. Even though the item descriptions table has entries for all the TMs and HMs (which all point to several copies of the description ?), the game looks up which move is taught by the TM/HM and uses that moves description instead. (For whatever reason, the list of TM/HM moves ends with HM11, and HM12 is read as Rollout in all Generation II games.)


Oh, I see. That means HM08-HM10 are similar to the Badge items of the Generation I games (which are used on the list shown by the man in Cerulean IIRC), correct?

Re: Generation II's item 00h

Posted by: Háčky
Date: 2015-03-29 19:45:37
It occurred to me to try using arbitrary code execution to read some data from $A793 on a real English Crystal cartridge, to see exactly how its different when done on a GBC or GBA. I wrote this program to read fifty bytes and store them as the quantities of items in the PC:

ld de, $A793  ; address of item $00 description

ld hl, $D8F1  ; quantity of PC items
ld a, $32    ; set it to 50
ld [hli], a

.readByte
ld a, $B4    ; overwrite all PC items with Brick Pieces, just to
ld [hli], a  ; make sure they all exist and will show a quantity

ld a, [de]
ld [hli], a  ; set item quantities to data from $A793 et seq.
inc de

ld a, l
cp $56        ; $D956 = end of PC items
jr nz, .readByte

ld [hl], $FF  ; be nice and give the PC items a terminator
ret


I used the following GameShark codes to put TM15 in my Items pocket and write the code to $DA10, where TM15 will execute it. (This is an unused area of WRAM between the end of the trainer rematch data and the start of the event flags. You can safely stash up to 98 bytes of code here.) Since external devices seem to affect how item $00s description behaves, I saved the game, then removed the GameShark before executing my program.

01CE93D8 011110DA 019311DA 01A712DA 012113DA 01F114DA 01D815DA 013E16DA 013217DA 012218DA 013E19DA 01B41ADA 01221BDA 011A1CDA 01221DDA 01131EDA 017D1FDA 01FE20DA 015621DA 012022DA 01F523DA 013624DA 01FF25DA 01C926DA

Anticlimactically, this program always reads fifty $FFs, regardless of whether its run in BGB, or on a GBC or GBA, or even with the GameShark plugged in. It seems there must be some difference between what happens when SRAM addresses are accessed through TM arbitrary code execution, and when theyre accessed to read the item description. The game is clearly reading something thats not all $FFs when it displays reams of glitch text on a GBA.

Re: Generation II's item 00h

Posted by: Háčky
Date: 2015-04-24 01:05:15
If at first you dont succeedtry calling a ROM function?

; Copy 2018 bytes of item $00s description into tilemap
ld de, TileMap              ; destination ($C4A0)
ld hl, $A793                ; source (address of item $00 description)
ld bc, TileMapEnd - TileMap ; length ($0168)
call CopyBytes              ; $3026
ld a, $1
ld [hBGMapMode], a          ; $FFD4

.waitForB:
; Keep displaying it until the B button is pressed
ld a, [hJoypadDown]        ; $FFA4
bit 1, a                    ; B button
jr z, .waitForB
ret


As before, I placed this program at $DA10 and executed it with TM15. GameShark codes:

011110DA 01A011DA 01C412DA 012113DA 019314DA 01A715DA 010116DA 016817DA 010118DA 01CD19DA 01261ADA 01301BDA 013E1CDA 01011DDA 01E01EDA 01D41FDA 01F020DA 01A421DA 01CB22DA 014F23DA 012824DA 01FA25DA 01C926DA

The result in BGB is to fill the screen with 9, which is tile number $FF. (Dont mind the colors; theyre left over from the items menu.) This matches the behavior of a Game Boy Color:

[img]http://i.imgur.com/rBCZqhL.png[/img] [img]http://i.imgur.com/K0VQrsZt.jpg[/img]

On a Game Boy Advance, this program produces something more intriguing:

[img]http://i.imgur.com/OHaOmoHm.jpg[/img]

The pattern is different each time, but the same handful of tiles always show up. Their hex values are:

: $2A (this tile is part of the word POCKET on the items menu)
S: $6A
k: $AA
l: $AB
é: $EA
: $EB

Bits 0, 6, and 7 of these numbers vary, but bits 15 are the same: $2A. Opcode $2A is [tt]ld a, [hli][/tt], which happens to be the instruction used in the CopyBytes function Ive called to read from disabled SRAM.

This is totally different from what is displayed when actually viewing the items description:

[img]http://i.imgur.com/BZfIadUm.jpg[/img]

Item descriptions are written into the tilemap using the PlaceString function ($1078, in pokecrystals home/text.asm). That function uses a different instruction to read the string: [tt]ld a, [de][/tt], which is opcode $1A. And indeed, the first few characters shown in the description can be derived from $1A by flipping a few bits from 0 to 1:

: $7A
4: $FA
5: $FB

It seems whats happening is that the GBA reads the opcode from the cartridge ROM, executes it, tries to read a byte from the cartridge SRAM, and doesnt get a response (because its disabled), but picks up a residual signal of the last byte sent on the data bus, which is the opcode. This explains why my last experiment didnt show anything useful: my code was executed from WRAM, which isnt in the cartridge, so there was no signal on the cartridge data lines and everything was read as $FF, even on a GBA.

Since bits are apparently only flipped from 0 to 1, and not from 1 to 0, it is impossible for the item description to include the string terminator $50 (until it runs past the end of SRAM and into WRAM, but its bound to crash the game or hit an infinite loop of text commands before then). But it canand inevitably willinclude the text command $5A, which is supposed to display the name of the attacking Pokémon in battle. Based on the value of hBattleTurn ($FFE4), it prints either BattleMonNick ($C621), or Enemy followed by EnemyMonNick ($C616).

Outside of battle, $C608C7E7 is some sort of scrolling tile buffer for the overworld map; its contents shift each time you cross a 22 map block boundary. Thus, standing in different locations changes how item $00s description is displayed on a GBA. In some places, the description will contain a line or paragraph separator which allows it to be paged through indefinitely. When it doesnt, itll usually crash the game in one way or another. (In one instance, it actually managed to corrupt my save file! Which is funny, since this glitch only happens because SRAM is locked to prevent save corruption)

In many places, the description will overflow the tilemap buffer and trashes enough of WRAM to crash the game. In other places, it will contain a line or paragraph separator which allows the text to be paged through indefinitely.

Text command $57 terminates a string from within another text command. (You may recall its improper use in the English Gold/Silver, where it isnt within another text command.) By standing in a location where tile $57 is near the top edge of the screensuch as the 22 space between the bookshelves in Prof. Elms lab (tile $57 is part of the healing machine)it is sometimes possible to properly terminate item $00s description on a GBA, and be able to scroll over the item, move it with the Select button, or open its Give/Toss menu:

[img]http://i.imgur.com/p1lGjmzm.jpg[/img] [img]http://i.imgur.com/ODpEwbgm.jpg[/img] [img]http://i.imgur.com/wVgI1MRm.jpg[/img]

Unfortunately, this isnt reliable, because the locations read by text command $5A are just past the end of the onscreen tilemap buffer ($C4A0C607) where the description is being printed. If the description overflows the tilemap buffer, it can overwrite the $57 byte and prevent itself from being terminated.


By the way, I checked the European localizations of Crystal, and they all have the same truncated pointer table that causes item $00s description pointer to be read from the first two bytes of the Master Ball text. As in the English version, the resulting addresses are in SRAM, so they should behave likewise:

German: $A483 (Der beste BALL. Erfolg garantiert!)
French: $A08B (La meilleure BALL. Ne rate jamais.)
Italian: $A08B (La BALL migliore: infallibile.)
Spanish: $B284 (Es la mejor BALL. Nunca falla.)

Re: Generation II's item 00h

Posted by: luckytyphlosion
Date: 2015-06-08 14:57:58
Just to make sure, did you remember to enable SRAM? (Write $0A to Address $0000)

Re: Generation II's item 00h

Posted by: Háčky
Date: 2015-06-08 15:07:39

Just to make sure, did you remember to enable SRAM? (Write $0A to Address $0000)

The game reads item $00s description from $A793 while SRAM is disabled. The point of my experiments was to understand what happens when it does that, so, obviously, I didnt enable SRAM.

Re: Generation II's item 00h

Posted by: TheICTLiker4
Date: 2019-08-14 13:37:38
If the item would have an English description, then it would be [font=courier]   tzxtzx .[/font], which is a mojibake for the Japanese description [font=courier]きき[/font].

Re: Generation II's item 00h

Posted by: Sherkel
Date: 2019-08-15 23:44:26
Is that meant to be some sort of neko no ko koneko type thing? :P

Re: Generation II's item 00h

Posted by: TheICTLiker4
Date: 2019-08-18 12:23:26
Hey! What is that 'neko no ko koneko' thing?