Jump to content


New Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About superguideguy

  • Rank
    New Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Long-winded story in the spoiler tag. TL;DR: Rather than the games checking the compatibility header, the distribution ROM does. Patch instructions below. (If anyone wants to make an IPS/UPS/BPS patch, go ahead! I just don't feel like downloading one more program for this project to make one.) Due to space constraints, it is impossible to patch a fix in to the same location. However, it is possible to patch out the check completely. Replacing 0x714C through 0x7173 (inclusive) with 0x00 patches out the region, game, and language checks. It leaves the sanity check, however. (Also, see below regarding the language check.) Why does this matter? Using direct injection, I already knew that it is possible to use "comparefarbytetobyte 0x80000AE 'E'" (ASCII 'E', not the proprietary encoding 'E') to check for whether a game is Emerald or not. "comparefarbytetobyte 0x80000AF" can also be used to check for language. Thus, while scripts for both versions - and texts for all languages - would need to fit into 1000 bytes, it is now possible to make a multi-version multi-language distribution ROM. One last thing. I found a glitchcity forum post (Reply #35 at https://forums.glitchcity.info/index.php?topic=7114.30) that confirmed my suspicions regarding the CheckCompatibility function. FireRed, LeafGreen, and Emerald act as Japanese cartridges, regardless of their actual language. This carries over to ValidateMEventClientHeader. Thus, all games can receive the Mystery Gift, regardless of the language of the distribution. This does leave a question as to how the European distribution ROM knew which version to send. It may be the case that only English carts act as Japanese carts. However, without a European decompilation, and without a European cart of my own, I'm left without means to test this hypothesis.
  2. I've been lurking for a while now, but I think I'm finally ready to add what information I know about the distribution ROM. I apologize if I repeat something that was already known, but I checked the last 5 or so pages, and I didn't find the information I have. The actual script data for the Aurora Ticket distribution starts at 0x12728. It is the raw data - unencrypted and uncompressed. Noteworthy is the fact that the checksum and header are not stored here. I edited the script to give me both the Aurora Ticket and Mystic Ticket, and it worked! This means the checksum is calculated dynamically, rather than stored elsewhere on the ROM. The Wonder Card starts at 0x14FB8. At least, that is where the checksum would be. I haven't confirmed if the checksum is calculated dynamically, but I can't find it stored anywhere in the ROM, so I'm assuming it's dynamic. I tried my hand at disassembly. Here's what I've learned: The disassemblers designed for generic ARM7-TDMI code don't like disassembling THUMB code. The disassemblers designed specifically for the GBA (e.g. luvdis) don't like disassembling ARM code. Overall, I'm bad at reading assembly code. Something (maybe) useful: the Wireless Adapter uses the 32-bit "normal" serial communication mode. (It sends data by writing to register 0x04000120.) Not strictly about the distribution ROM, but the "virtual" script functions (opcodes B8 through BF) can access data in the Wonder Card and Wonder News sections. Thus, a properly crafted Wonder Card could add an additional 320 bytes of script data. Finding a way to distribute Wonder News would add another 440 bytes of usable script data. I've been doing some digging into the decompilation projects, and I've found two functions that might be responsible for Emerald rejecting the distribution: "ValidateMEventClientHeader" / "sub_801B6A0" FireRed: https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mevent.c#L788 Emerald: https://github.com/pret/pokeemerald/blob/4dd3cc7b7691afb8ecd2e8af8b2ebfa717dd2414/src/mevent2.c#L380 "CheckCompatibility" Ruby: https://github.com/pret/pokeruby/blob/f839afb24aa2c7b70e9c28a5c069aacc46993099/src/mystery_event_script.c#L38 FireRed: https://github.com/pret/pokefirered/blob/2880cf2a51ea36fa36f00d9ecf07177e5955c882/src/mystery_event_script.c#L30 Emerald: https://github.com/pret/pokeemerald/blob/4dd3cc7b7691afb8ecd2e8af8b2ebfa717dd2414/src/mystery_event_script.c#L28 Given that "ValidateMEventClientHeader" appears in FRLG and Emerald, but not RS, I suspect it is this function that is used for the Wireless Adapter, while "CheckCompatibility" is used for the eReader. Regardless, as long as it is one of these two functions, the remedy is the same. Replace a 0x1 somewhere with 0x5, and replace a 0xF with 0x20F or 0x38F. Unfortunately, like the checksums, these values do not appear to be stored directly on the ROM. They are likely caused by MOVS or ADDS instructions, instead. I hope this helps, and let me know if there's anything else I can do to help.
  • Create New...