about summary refs log tree commit diff stats
path: root/source/encoding.c
Commit message (Collapse)AuthorAgeFilesLines
* Increased stability and added support for non-English namesKelly Rauchenberger2017-09-101-8/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GameCube side of the program now can convert from the propietary character set to UTF-8. This is useful for representing names of Pokémon and players in a neutral way. The propietary character set is mostly compatible between the six languages supported by the games (as in, the hiragana and katakana characters unique to Japanese occupy spaces not used by the other languages for names, as do the letters with umlauts unique to German). However, six codepoints differ between the Japanese and non-Japanese character sets, and an additional two differ even amongst the non-Japanese sets. Because of this, the function that converts to UTF-8 takes a language as a parameter, and uses the correct characters for that language. From there, the behavior of this function differs slightly to that of the games. In the non-Japanese games, the Japanese encoding is used if the Pokémon in question originated in a Japanese game, and the non-Japanese encoding (disregarding the regional differences in the two codepoints mentioned earlier) otherwise. In the Japanese games, the Japanese encoding is used regardless of the Pokémon's origin. The decoding function I wrote always uses the character set corresponding to the language of the Pokémon's origin, because that most accurately represents the name given to it, and will not change just because the Pokémon was traded to a different game. The character set used for the name of the player is the one corresponding to the language of the cartridge. Additionally, a number of changes were made to the communication protocol between the GameCube and the GBA that appear to have dramatically increased stability. The most significant of these is likely that the transfer delay was increased tenfold. This causes the multiboot image to take slightly longer to download to the GBA, but the difference is not large enough to outweigh the benefits of the increased stability.
* Fixed indentationKelly Rauchenberger2017-07-111-6/+6
|
* Major reformatting, cleaning up black magicKelly Rauchenberger2017-07-111-0/+9
|
* Things are semi-reliably working now!Kelly Rauchenberger2017-07-111-0/+14
A good portion of the time, the Wii will display: Pokemon LeafGreen Trainer: Starla (34182) which is the correct data on the cartridge I am testing with. Most of the GBA changes are within comments and are unimportant. I did uncomment the portion where it sends over the trainer's name, and I fixed how it reads the trainer ID from memory. The Wii changes involve properly cooperating in the message sending protocol I'm having the GBA and Wii use. More description regarding protocol: I'm not super familiar with the JOY BUS protocol because it's undocumented, but there seems to be this issue where the Wii reads the same value multiple times from the cable, and since the cable is used to negotiate the multiboot image, I need to make sure that the Wii and GBA are on the same page. Since the last message that the GBA sends is nonzero, I have the GBA image start by sending a zero and waiting for a response, and I have the Wii wait for a zero. The Wii then sends a zero in response to the GBA. From then on, the message sending protocol works like so: Wii: waits for non-zero value GBA: sends non-zero value, waits for any response Wii: reads message, sends 0 response, waits for 0 response GBA: receives response, sends 0 response, waits for any response Wii: reads 0, continues on with program The reason for this is to prevent incorrect communication caused by the Wii reading the same value from the GBA multiple times by essentially delimiting the message. This is currently pretty slow because I have debugging messages and sleeps everywhere. I will clean this code up, but this project is slightly dark magic right now and I wanted to commit something that worked in the slightest. Also added a debug function that transcodes from the proprietary gen 3 encoding to ASCII in the domain of characters that can actually be used in names (except for the 6 special German ones). Thanks to Bulbapedia (https://bulbapedia.bulbagarden.net/wiki/Character_encoding_in_Generation_III) for this. It's used for now to display the Trainer name on the console. It assumes that the cartridge is non-Japanese; this will be addressed. I'm not currently planning on transcoding names before transmitting them, because of the fact that there are characters in the character set that are not present in any other character set, and thus transcoding them spuriously (like PK -> P,K) is a loss of data. However, it is true that no such characters exist in the set of characters that can be used for names (in either the Japanese or non-Japanese encoding), so I may later decide to transcode to Unicode on the Wii before transmitting.