| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Also fixed offsets of gift ribbon descriptions in the RSE save data, and
added the offset for FRLG.
|
| |
|
|
|
| |
3000µs has been consistently safe in my tests. 2000µs caused incorrect
hashes to be read by the Wii, and 1000µs caused segfaults.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also changed the hash determiner format such that each IV, as well as
the Shedinja flag, has its own byte. This increases the size of the
determiner to 16 bytes, 33 bits of which are always unset. While this is
somewhat wasteful, it is useful for debugging purposes because it is
hard to predict the behavior of bitfields.
For testing purposes, the amount of time that the Wii waits for the GBA
to compute hashes has been increased. Given that BLAKE2s is a generally
faster algorithm than SHA-224, it will likely be safe to decrease this
delay in a future commit.
Because the hash algorithm has changed, all old hashes are now invalid.
refs #2
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extractor now uses libfat to read a config file off the root of the
SD card, a model for which is included in the repository. The extractor
is capable of negotiating an HTTPS connection, but it requires a
download of the target site's root CA certificate to be on the SD card
and pointed at by the config file. TLS/SSL functionality is provided by
wolfSSL. I had to make a couple of minor changes to wolfSSL for it to
work properly, and those changes are located in the devkitpro branch of
my fork, hatkirby/wolfssl.
The Wii program now arranges some of the information that the GBA sends
it into a JSON object, which is then sent off (along with some
authentication information from the config file) to the endpoint defined
in the config file. The code used to maintain the network connection is
from the WiiTweet project, which was licensed under the GPL. Some of the
code used to send the HTTP request also comes from said project.
|
| |
|
|
|
|
|
| |
The purpose of this hash is described in detail in pokemon.h. The hash
is computed using an implementation of SHA-224. To allow the GBA
sufficient time to compute this hash, a delay of 5 milliseconds was
introduced on the GC side before reading a Pokémon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GBA program now sends serialized data about the first pokemon in the
player's party over to the Wii. This data doesn't yet include all of the
information that we will eventually want. It does, however, not transfer
any private data, specifically IVs, EVs, and the personality value. It
does this by deriving the public information (stats, nature, gender,
shiny) before sending the pokemon over. Because of this, lookup tables
for things such as base stats were needed, and given that these are
large tables, it was easier to use the tables already existent in the
game's ROM. Thus, the addresses of the three lookup tables that are now
used are necessary for each ROM that this tool supports.
I derived the addresses for version 1 of English Pokemon LeafGreen by dumping
my own copy and searching through it with a text editor. Thus, at the current
time, that cartridge is the only one that is supported. I will supplement this
soon with addresses for the other four gen 3 carts that I have, but that will
still not provide a very large amount of coverage. I have not yet decided how
to address this issue.
There is one current bug with the serialized data: the Wii doesn't seem
to see the original trainer ID. Will fix.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now the link-specific stuff is abstracted into its own file, and the
code for negotiating the "different" multiboot protocol is in its own
file. Also, removed support for compiling for GC because eventually we
will be using Wii-only features. Also put the main extractor code into a
thread so that we can monitor for the user pressing the start button to
exit.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
-corrected the si transfer delay code to only have one properly set delay
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
