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.

Emulation & ROM Hacking

Anatomy of an e-Reader Mystery Event - Page 3

Re: Anatomy of an e-Reader Mystery Event

Posted by: Team Fail
Date: 2015-06-10 20:39:00


They do have the e-Reader code, it's just skipped out on. Normally, if a Wireless Adapter is not detected, it will default to e-Reader mode in the Japanese versions (Otherwise go to Mystery Gift if it is attached), but this check simply errors out on you and tells you it's not attached (Or if attached, it does go to Mystery Gift), so it never does jump to the code responsible for e-Reader usage in the international releases. However, by editing the Main Menu option to allow the original Japanese behaviour, you can connect to an e-Reader, all the code is still there and completely functional:


[img]http://i.imgur.com/Fg42lhj.gif[/img]
(Note that the text is not actually in the ROM, so I had it ripped from the Japanese games and translated. This is how it looks without the text.)


I see, thanks. So, to clarify, the Japanese FireRed and LeafGreen will load the same Mystery Gift screen as the localizations when the Wireless Adapter is attached and detected by the game, correct?



Yes, that would be correct. They made use of the Wireless Adapter as well.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Háčky
Date: 2015-06-13 20:18:17
I figure that Team Fail has a better handle on the FR/LG side of this than I do, so I decided to look into how the program run on the e-Reader works.

It uses the e-Reader API to load the VPK data of a scanned card into a buffer at $2005C6D, and decompress it into another buffer at $200645C. It then grabs a $3D4-byte Trainer Tower data structure from offset $100 of the card data. (It ignores everything else on the card, which is just a Z80 program that displays the error screen I posted earlier.) The data from up to 8 cards is stored consecutively starting at $200749C.

The data is sent to the game using a very similar protocol to the R/S/E Mystery Events. First the GameFreak inc. packet is sent, which, as Team Fail noted earlier, has the value $02 instead of $01 at offset $24. The second packet contains the card data preceded by two dwords: the first is the number of cards, and the second is a bytewise checksum of all the card data.

The Trainer Tower data structure appears to be the same as the one on Bulbapedia except that the trainer names are 8 bytes instead of 11, and consequently an alignment byte is added at offset $3CF. The dword at $3D0 is a bytewise checksum. (Its possible that if the English FR/LG can be made to accept Trainer Tower e-Reader data, it will expect the trainer names to be 11 bytes.)

It seems that the language code at offset $2A of the GameFreak inc. packet is the only method of language lockout used. Theres nothing in the card data indicating which language version of FR/LG its for, although the Japanese cards can only be scanned on a Japanese e-Reader+. Curiously, the program contains the string Region error, but its unreferenced. (つくくなま is also unreferenced.)

Theres also no apparent indicator that Trainer Tower data, rather than some other type of data, is being sent, unless this is what the $02 at offset $24 of the GameFreak inc. packet means. It could be that FR/LGs Mystery Gift will accept only Trainer Tower data over the link cable, and any other kind of Mystery Gift requires the wireless adapter.

The Japanese FR/LG is able to communicate with this program even if its already running on the e-Reader; its not strictly necessary for the game to send the program to the e-Reader first before it receives the data. This implies that it would be possible to write an e-Reader dotcode application that can send data to the game without using the built-in program.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Háčky
Date: 2015-06-14 23:08:43
It looks like the e-Reader side of Mystery Gift is in fact limited to Trainer Tower data, and everything else goes through the Wireless Adapter.

The functions of R/S/Es Mystery Events are present in FR/LG (see the jump table at $81DBCF0 in the English FireRed), with the exceptions of $0B (gift item when mixing records) and $0E (in-game clock adjustment), which understandably display the message This data cant be used in this version. It appears that this system is somehow tied into the Wireless Adapter side of Mystery Gift. The upside is that these functions ought to work in the English version without alteration; the downside is that I have no idea how to go about accessing them.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Team Fail
Date: 2015-06-15 01:57:28

It looks like the e-Reader side of Mystery Gift is in fact limited to Trainer Tower data, and everything else goes through the Wireless Adapter.

The functions of R/S/Es Mystery Events are present in FR/LG (see the jump table at $81DBCF0 in the English FireRed), with the exceptions of $0B (gift item when mixing records) and $0E (in-game clock adjustment), which understandably display the message This data cant be used in this version. It appears that this system is somehow tied into the Wireless Adapter side of Mystery Gift. The upside is that these functions ought to work in the English version without alteration; the downside is that I have no idea how to go about accessing them.
So at this point, all that the e-Reader can send over is trainers then, while other events use the Wireless Adapter?


Also, if you want a fixed copy of the ROM for testing with, I can probably provide you with a patch or something.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Team Fail
Date: 2015-07-07 22:27:40
I really hate double-posting, but I think this is a rather important development in this particular thing, so I'm going to go out on a limb here and do this.

I figure that Team Fail has a better handle on the FR/LG side of this than I do, so I decided to look into how the program run on the e-Reader works.

That I do, and I come bearing good news.


Prof9 and I were talking on Project Pokémon's IRC, and he told me of a way to activate e-Reader support for USA copies of Emerald, and funny enough it literally only requires you to change ONE BYTE to enable it.

"Change the byte at 0x02F97E to 0x02" as he said. Then, when on the Continue screen, select "Mystery Gift" to access a glitchy version of the application. It works in the same way as the FireRed one, although you'll still need a Japanese e-Reader to work with it. Scanning and sending cards seems to error out for some reason though.

Anyways, on the FRLG front, I finally got it working with the English e-Reader, yet again with Prof9's assistance (And in the process showing how little I know of No$GBA's debugger and how powerful it is). I'll probably issue a preliminary patch so people can try getting cards working, however, I think I'm encountering region errors, because I cannot scan in any FRLG cards, they all result in this:

[img]http://i.imgur.com/bbNeJAO.png[/img]
If I revert to a version that connects with a Japanese e-Reader, it will accept the cards, but when I go to transmit the data to FRLG, it errors out, same as Emerald, presumably because of a region error. I think at this point, a disassembly of the FRLG and Emerald cards may be necessary to change their region and get them working on English games.


Edit: I have a preliminary patch here if you wish to try this.

Edit 2: After looking at your first post in the thread again, I may be able to adjust the VPK data and get it working. I may know how to fix this.


Edit 3: Nothing yet. Haven't gotten it working. I do have the cards working on USA systems though, but the card scanning application still won't accept it for whatever reason.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Háčky
Date: 2015-07-09 09:19:17
I was able to read a card through the application on the English e-Reader after altering the card header to have the correct region code. (Specifically, I took card 15-A001, converted the .raw to .bin with nedcenc, and changed offset $0D [region code] to $F1 and offset $2E [checksum] to $0E.)

The remaining issue is that, as I suspected earlier, the English games expect a 992-byte Trainer Tower data structure as documented on Bulbapedia rather than the 980-byte structure used in the Japanese version. Attempts to send the Japanese card data will fail when the English game tries to verify the checksums. The cards and the application will both need to be modified to use the 992-byte structure.

As a test, I dummied out the function at $0815D6B4, which is called by the Mystery Gift routine to verify the checksums. With that alteration, I was able to successfully complete the Mystery Gift process. The data was stored in the save file, but had no apparent effect on the Trainer Tower. I then tried editing the saved data to match the 992-byte structure, but I still saw no effect. I would guess some further reprogramming is needed to restore the Trainer Towers original functionality.

(While editing the saved data, I noticed that on Trainer Tower cards with fewer than three trainers, the unused trainer slots have their names set to , which was previously used as a hidden default name in the Japanese Pokémon Blue.)

By the way, in case youd like to spell Pokémon properly in your translated application title and cards, $7F represents é in the English e-Readers pseudo-ASCII.



In unrelated news, after looking at the leftover Mystery Events functions in FireRed, I discovered that the header (chunk $01) has a totally different structure than what Id previously thought. I suppose it was purely accidental that my earlier German Eon Ticket experiment worked.

$0  4  Pointer base address ($02000000)
$4  2  Language group bitfield
        bit 0: Japanese
        bit 1: English
        bit 2: German, French, Italian, Spanish
$6  4  Language bitfield
        bit 0: Japanese
        bit 1: English
        bit 2: German
        bit 3: French
        bit 4: Italian
        bit 5: Spanish
$A  2  Game region bitfield
        bit 0: FireRed, LeafGreen
        bit 2: Ruby, Sapphire, Emerald
$C  4  Game version bitfield
        bit 0: FireRed
        bit 1: LeafGreen
        bit 7: Ruby
        bit 8: Sapphire
        bit 9: Emerald

This data cant be used in this version. will appear if any of the four bitfields dont have the necessary bit set.

All versions of FireRed, LeafGreen, and Emerald expect Mystery Events data to be marked as Japanese, regardless of the actual game language. (I still dont know of a way to actually send Mystery Events to FireRed/LeafGreen or non-Japanese Emerald.)

It seems fairly pointless to have used four bitfields for this rather than two, and fairly obvious what the unassigned version bits might have represented.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Team Fail
Date: 2015-07-09 13:36:31
Well, I'll keep my eyes out for other cards, like the trainer cards for the house on Seven Island. That's the card type that I'm wanting to be able to import, at least for now. I'm also trying to figure out on what part of the data the checksum is calculated so I can import my edited e-Reader file with the original header data intact, in case there's anything important that's read from there. Or would using nedcmake be perfectly fine for turning the VPK data into valid card data, and would the FRLGE application still accept it?

Re: Anatomy of an e-Reader Mystery Event

Posted by: Háčky
Date: 2015-07-09 18:41:46

Well, I'll keep my eyes out for other cards, like the trainer cards for the house on Seven Island. That's the card type that I'm wanting to be able to import, at least for now.

The Trainer Tower cards were the only kind of card released for FireRed/LeafGreen, and Im fairly sure Trainer Tower data is the only type of data accepted by the e-Reader version of Mystery Gift. The house on Seven Island, by analogy to those in Mossdeep and Sootopolis, would likely house a Mystery Events trainer if there were some way to send Mystery Events data to FireRed/LeafGreen, but I still dont know if there is. The Pokémon Wiki article on Seven Island seems to say that the house was unused: 家には箱にの解とはなくなどは起な

I'm also trying to figure out on what part of the data the checksum is calculated so I can import my edited e-Reader file with the original header data intact, in case there's anything important that's read from there. Or would using nedcmake be perfectly fine for turning the VPK data into valid card data, and would the FRLGE application still accept it?

For some reason, nedcmake generates a completely different type of card header than what the original cards usecompare GBATEKs documentation, which matches the original cards (and tells you how the checksums are calculated), to nedclibs documentation. The format generated by nedcmake works with Scan Card, but apparently not with the Mystery Gift application.

Re: Anatomy of an e-Reader Mystery Event

Posted by: Team Fail
Date: 2015-07-11 10:47:27
Hm. I was hoping to be able to import other things, like perhaps an unofficial gift for the special tickets, but it looks like that won't be possible then. I did notice though, that there were special FRLG cards that changed the layout of Trainer Tower. Are those still undumped?


As for the header issues, perhaps if I can figure out how to re-calculate the checksum programmatically, I can simply import VPK data into a ripped header and perform any necessary calculations on the checksum that are needed rather than making a new header completely.

Re: Anatomy of an e-Reader Mystery Event

Posted by: SatoMew
Date: 2015-08-27 16:32:24
I'm linking to these PokéCommunity threads here since they're helpful.

Tutorial on how to reinstate Mystery Events in non-Japanese Emerald

Team Fail's research on e-Reader content

Re: Anatomy of an e-Reader Mystery Event

Posted by: Stackout
Date: 2017-02-24 11:58:27
Whilst reversing Gen III and adding the save structures of the various games to my payload code, I noticed something.

The Enigma Berry structure is different in FR/LG/Emerald!

It's only [tt]0x30[/tt] bytes long; the sprite, palette and tag description elements were removed, leaving only the base Berry structure ([tt]0x1C[/tt] bytes), the item-usage-by-trainer structure ([tt]0x12[/tt] bytes), the hold item effect (2 bytes) and bytewise checksum (4 bytes).

edit: the change was made in FR/LG, not Emerald (Emerald just inherited it)

Re: Anatomy of an e-Reader Mystery Event

Posted by: Parzival
Date: 2019-04-08 17:26:21
>games are always garbage at error-checking
>e-Reader ends up using game's CRC algo

why isn't the algo used anywhere else???