Been taking a break on this for a bit, but I have updates for what I have done! The custom PCBs have arrived and I already found tweaks to make for the next version of them, but they are workable in the meantime. The custom PCBs make the setup much cleaner than it was in the past.
I’m headed back to college shortly for my final semester, so work on this project and updates may slow down. This project is still something I am still interested in completing though. I hope to have the software complete by the end of the year so that I can make the finishing touches on the hardware and start designing a case for the electronics.
After resolving some issues with legitimacy (legends/Unown/Ditto so far, mythical aren’t entirely resolved yet), including PID mismatches based on encounter type, I have moved onto real hardware! The first steps, to read data off the cartridge and recognize what game is connected, are complete. As expected, some minor tweaks are necessary for the code to work on Arduinos as well, but nothing major has been required, yet.
I dug back out the hardware I was working on previously using a breakout board for a DMG cartridge slot and some chips to give the Arduino some more IO pins and got it working once again using some of the existing code for the emulated version. I am now going through the process of working out the kinks that aren’t even a thing in emulation, like the different memory controllers used as well as swapping RAM banks so that I can access all the information I need.
I am confident enough in my wiring as it is that I have designed a custom PCB to act as a daughterboard to the Arduino that only requires 5 connections to interface with the cartridge, so that will make things much easier going forward as the software comes together and the time arrives to design a case for the thing.
I am by no means an expert in PCB design, in fact, this is my first try at it, so it probably has some overall design oversights and obvious optimizations, but as long as it works, it’s fine by me for a first iteration.
Also, my mention previously about doing testing as to where illegal movesets will become an issue has not yet been done so I don’t have any updates on that yet. Until then, have a good one!
There has been more work in terms of legitimacy checks! The first check was to go through and make a list in the code of each Pokemon with only one possible ability in generation 3 as opposed to two abilities. This was an issue as if I randomly assigned a Mew for instance to have its second ability, it would then have no ability instead of defaulting to its first ability.
The other major thing to verify was the met location for each Pokemon migrated in. I would need to assign legitimate met locations for each Pokemon possible to migrate in, or each of all 251 Pokemon available in generations 1 and 2. That would be a lot of work. Instead, I assigned them all as if they were hatched, which makes no difference in the visuals anyways as the actual met location is only displayed if the player checking location is the Pokemon’s original trainer. The exception to this is legendaries and Unown (as they can’t breed).
While thinking about how to handle this, I made the discovery that the generation 3 games use game origin markers from ID 0-15, but only 6 of these are used. For Ruby, Sapphire, Emerald, FireRed, LeafGreen, and Colosseum/Gale of Darkness (those last two use the same ID). Coincidentally, HeartGold and SoulSilver are identified using different IDs within that same 0-15 range. After doing some testing, I realized that I could set the flag for them to have originated from HGSS and that flag is maintained through Pal Park, all the way through up to Pokemon HOME without issue, and still showing the origin of Johto in Pokemon HOME. This made the origin game issue very easy, as I could assign the proper region for each Pokemon as it is migrated through without any issues regarding legitimacy. But I would still need to sort out legendaries and Unown if levels don’t match, as well as mythical distributions.
Mythicals obtained via distribution get more complicated as OT, OT ID, met location, and met level all need to be accurate to pass legitimacy checks. Luckily, there are only 2 mythical Pokemon to be migrated in so it shouldn’t be too much of an obstacle, OT just may not match as it was in generation 1 and 2 as it would need to be updated to retain legitimacy.
The last issue regarding legitimacy I have encountered so far is changes in movesets. There are multiple Pokemon that cannot legitimately learn specific moves in generation 3 that they could in generation 1 and 2. Due to the amount of data I would need to store to check this, I will likely leave this untouched, and anyone moving Pokemon further forward would simply need to take the Pokemon to the move deleter or replace the move my learning a new one to then make it legitimate once more. I will do some testing to verify what stage in the migration it will stop these Pokemon and whether deleting the move at the last possible stage mitigates the issue or if it is still determined to be illegitimate.
After I resolve the issue with legendaries/mythicals and do some further testing regarding movesets, I should be ready to start testing on real hardware! There will likely be issues when moving the code over to the Arduino, but hopefully it is without any further major rewrites.
I was going a bit of digging and realized that generation 4 games use the same origin game flags as generation 3, and the generation 4 game flags are handled gracefully when on Pokemon in generation 3. So, I tried putting the game origin of HeartGold on an Unown as I transfered it from Gold to Emerald, and then moved the emulated save onto a real cartridge. From there, I was able to transfer it through Pal Park, and the origin flag was maintained. At this point I was super hopeful and finished the transfer up to Home, and the flag was maintained the whole way!
This means that I can maintain the proper region of origin for any Pokemon transferred through Lanette’s Poke Transporter!
There has been an update on the code porting! With a few exceptions, the new code works just as well as before it got ported to the new language! Pokemon can be imported on emulator from generation 1 games into generation 3 games once more. Still need to do a bit more testing on making sure gender is maintained after the transfer, but as of now movesets, nickname, OT, level, shiny status, etc are maintained! After the additional testing, I can work on testing combinations of different input and output games, and well as testing inter-language transfers, and then finally testing with real hardware!!!
Successful transfer of a handful of Pokemon from Blue into Emerald!
I haven’t gotten as much work done on this project lately due to a variety of reasons, but one of the bigger ones was a realization that I need to change how I wanted to run the code. My initial plan was to have the program run on a computer and communicate with an Arduino to read/write from the cartridges. After having some problems with the communication itself and some thinking, I decided I would rather have the program run solely on the Arduino and have it be a standalone device.
This means I had to change the code from being in C# to being in C++. The languages are similar, ish, but still was a massive overhaul. This put a damper on how much I actually wanted to work on this and I put it off for quite a while. When I was working on it, none of the progress was really that interesting for an update here. But yesterday, I finally got the code to compile for Arduino C++! Now, for a bit of background before this image, one of my major concerns for putting the entire program on the Arduino itself was how much space I would have for program code. I am using an Arduino Leonardo, which has 32k bytes for program space. Now, that isn’t a ton, but it isn’t nothing. But I am pretty inexperienced with writing code for Arduinos, so that doesn’t mean much to me either.
Unfortunately, until I get the code to compile, I will have no idea how large it will be and how much space will be left on the Arduino. Thankfully, when I got to compile, I saw it would fit! But… just barely.
Another concern was how much RAM I would have to work with. After seeing I would only have 955 bytes to work with, I started getting even more worried and started doing some math. If a generation 3 Pokemon uses 100 bytes in the games themselves to be stored, and an entire box loaded at once for transfer would take 3k bytes. That is a little bit more than 955. So now my next plan is to rework the process so that it transfers one Pokemon at a time rather than loading the entire box. Operating in this fashion should be much more memory efficient with minimal change on execution time.
I also need to make sure this new code actually operates as intended as well. Hopefully the form it is in currently works, or is very close to functional, and any tweaks I need to make cut down on overall program size rather than increasing it. That may end up still being an issue as the program currently only supports English games as well, and I am expecting adding more language support will also increase program size.
Getting the code to compile now though is likely more beneficial for my desire to work on it than negative, so expect more updates soon!
I knew this would happen, but its been a while since I posted an update to this project. I was able to fix the personality value issues in the meantime (so shinies and gender work as expected). The current issue is trying to read from the SRAM (save file) on a real cartridge, but I can read the game’s code, so its a step in the right direction!
While working on fixing up transfer into generation 3 games, I accidentally created some strange glitch Pokemon, like this one I call “Mark”. Doesn’t seem to do a whole lot. In the box, it doesn’t even have a sprite. I didn’t realize it was there until I was moving Pokemon around and happened to try and place a Deoxys onto it (don’t ask, needed filler so I have a bunch of Deoxys now).
Another oddity that I didn’t capture was what looked like a “normal” bad egg, but when the summary is opened, it would crash the game about 3/4 of the way through the egg animation. But it gets stranger. A few minutes later the game would restart to the title screen. I don’t know if that was a strange “feature” of the crash, or the emulator acting strange with it, but it was odd none the less.
Overall, these glitch Pokemon arose to due issues writing Pokemon into the PC and how the generation 3 games store Pokemon box data. I ended up abandoning placing Pokemon into boxes other than the first box, which works around this issue. Now, if the first box of the generation 3 game isn’t empty, the transfer will fail until it is emptied, similar to the Transfer Box for the normal Poke Transporter that goes into Pokemon Bank.
Now that I can transfer multiple Pokemon in at once without issue, the next two objectives are fixing the personality value for shininess and gender, as well as updating the Pokedex for Pokemon transferred in, which could also be an issue.
Lots of progress since the earlier update regarding yesterday’s progress. Since then I have been able to get the first successful transfer from Pokemon Yellow into Pokemon Emerald! This Mew has been the first Pokemon to be brought from a generation 1 game into a generation 3 game (that I know of and published about online). From here, it should only get easier (but I probably just jinxed myself). The next goal is to get personality value generation working correctly so that shiny Pokemon can be brought up and have the shiny trait preserved.
Yesterday I was finally able to recreate the checksum algorithms used in the generation 3 games to verify if the save was corrupted. This means I can start injecting Pokemon into boxes without the game freaking out when you start it up next. The Pokemon save data format is a bit off (which is why the are bad eggs) but it is one step closer to the final goal.