Data mining arbitrary code execution tools
Data mining arbitrary code execution tools were created as a means of data mining Generation I and Generation II Pokémon games for the discovery of new glitches, without having to own a copy of the ROM on a computer.
The player can data-mine the ROM with ACE and view it with the existing memory viewer ACE programs.
A common buffer to redirect to items is player party (D163 or D168 non EN EU ; or D123 all JP versions) for the '5kai/8F family'.
The player can also write these bytes with GameShark; so at D163 something like (01C363D1, 012264D1, 01D365D1); at D322 the below bytes e.g. from the examples. So it would be 3+15 codes which is not too bad.
This allows the player to data-mine even on cartridge. If the player can't do the glitches, it is good to insert the data-mining code using a cheating device or through a save file uploader. Installing offgao/TheZZAZZGlitch editor however is tricky as that is at least 173 codes currently.
If installing it is too much time/e.g. the player make typos when entering the codes or their cheat device can't handle it, they can still deconstruct a region of the memory by hand with the table at The Big HEX List, e.g. if glitch item 0x80 is at the start of PC items, it's read as the "add a,b" opcode. If an operand follows (i.e. "xx", "yy", etc.) then the next byte is the operand; so Lemonade x 1 is 3E 01 or ld a,01 etc.
These methods currently give bad items (as some cannot be tossed); so until the code is rewritten, the only way to get (permanently) key items with specific quantities is to use another ACE code to get them or potentially find them at specific maps in the expanded inventory. Another way might be to trick the game with ACE into 'thinking' they are tossable?
EN, non English EU RBY versions
(4F ($59)/8F ($5D)/etc.)
(For Yellow, ACE has taken a different path to 8F. The primary exploit to bootstrap to items has been ws m ($63) which is at DA7F)
d322 3e (bank) 21 (source) 01 (bytes to copy; 2 bytes - end byte first e.g. 6400 is 0x64 bytes) 11 (destination) cd 9d 00 c9
Example (copy 0x64 bytes from 01:4000 to PC items)
FR, DE, IT, ES RB RBY are mainly the same; all sharing the same FarCopyData pointer at 009D (7eme etage etc.; S7; 7P; P7 respectively, are the $5D items. The 0x63 family is ws l' m (FR/DE) or ws & m (Italian/Spanish)) Yellow. For Yellow, -1 should be done on most of the addresses (so D53B becomes D53A etc.) and for non-English EU versions; +5 as well.
d327 3e (bank) 21 (source) 01 (bytes to copy; 2 bytes - end byte first e.g. 6400 is 0x64 bytes) 11 (destination) cd 9d 00 c9
In JP RG, the FarCopyData pointer is now at 01a3. Between Japanese RGBY RAM not subject to address changes (generally), however offset differences sometimes exist (commonly with ROM addresses). The player will want something like D2A6 (instead of D322/D321) or wherever they want the code to start in items.
3E0121004001640011BAD4CDA301C9 for Red/Green v1.0 and v1.1
3E0121004001640011BAD4CD0317C9 for JP B (FarCopyData at 1703)
JP Yellow v1.0 through v1.3
In these versions, the 0x63 equivalent is かいがらバッヂ; where stored Pokémon begins at $D9B2. The player can also use はやぶさバッヂ (FalconBadge) if this is not v1.0 to run PC item 9 ($D4CA) straight away, with no bootstrap necessary.
Use for v1.0; Rev A; Rev B; Rev 3
EN/FR/DE/IT/ES Gold/Silver (Silver research incomplete sorry, EN Silver confirmed) (fa6a/da6a for tm25) d5b8 item 1=d8
EN (v1.0 and v1.1)/FR/DE/IT/ES Crystal (fa69/da69 for tm25) d893 item 1=d8
KO Gold (Silver not tested sorry) (d6d2 for tm49) d66b item 1=f1 (copies duplicates of each byte for some reason; keep this in mind e.g. a 3E would appear in TMs as x64 followed by x64) 3E012100400132001131D6CDCB0DC9
JP Gold (v1.0 and v1.1) (fa6d/da6d for tm25) d5ab item 1=d8
JP Crystal (fa10/da10 for tm10) d886 item 1=ce
- ChickasaurusGL (article text)