Hacking Yet another way to make GBA Backups with an NDS ;)

[Archerite]

A couple of days ago I discovered that from the 6 GBA games I owned for almost 15 years 4 were actually bootlegs!!! I was angry, frustrated, and ashamed that I had not discovered this in all these years. You can read my blog post about it if you like but it's quite long. One of my ideas was to write a homebrew app for the NDS that would allow me (and possibly others) to verify a cart on the spot! To do this the app would read the cartridge and calculate a hash to compare with a "known good database" I downloaded from the no-intro website. In my blog I have pictures of my own carts showing whats inside and it's quite obvious which are the fakes, but it requires a triwing screwdriver which maybe not every one has.

(there are seven games here, but minish cap I have only got since last week. So I did not count it above )

Just to see how difficult it was going to be a looked at the gba-link-cable-dumper on whats needed to read the ROM and which libraries I would need to do this. The database I downloaded has hashes in CRC32, MD5 and SHA1 but unfortunately no ready to use library for homebrew use is included for the DS in devkitpro. I really wanted to test the SLOT-2 reading speed so I started without being able to hash the data and to my surprise reading it completed in less than 1-2 seconds!! This was ofcourse just loading it into a buffer and doing nothing with it but still I expected it to take a while. What is included in libnds was a way to identify the game and display the GBA Header so I did:


This is a screenshot made with DeSmuMe and the ZELDA LTTP ROM in slot-2 which made it a lot easier to debug my simple app and fix small bugs and stuff. Then I found some source code to actually do SHA1 hashing without any hardware support or need for other libraries and it works perfectly! Reading the cart and calculating the SHA1 hash is done at around 800KB/s so for an 8MB game this takes 10 seconds to complete. Ofcourse it did not work right in a single try and I had to change the buffer's byte alignment and 16bit bus access and other fun stuff like that, but it works now and after a few seconds it shows the SHA1 hash on screen!

I did not have time yet to include the database into this NDS app yet so I had to manually compare the hashes but for the original Nintendo carts the hashes did match! Having this code that already reads the entire ROM anyway I was thinking...why not add writing to the slot-1 SD card and make my own cart backup's this way?? And also add a way to backup and restore the savegame while I am at it! Actually this whole idea was inspired by the reply's on my blog from @FAST6191 , so thanks you for that.

For making a cart backup I did had to disable the hashing since it takes A LOT longer when both are done at the same time. But checking the backup on my PC showed it was done correctly and the hash matched the database of known good dumps! My library of GBA games is not very large at the moment so I was done in about 15 minutes including taking out the SD card every time and removing the dumps. This was needed both because I used a fixed name "dump.gba" and because the super tiny 64MB sd card inside the only currently bootable and DLDI cabable DS flashcart I could find!
I have not started on adding savegame support yet but for that I will borrow even more code from the gba-link-cable-dumper since it has a library that detects the type of save and it's size. No need to reinvent the wheel on that and hopefully it is more reliable than anything I could come up with. Especially for writing a save back into a real cart!

So with this enormously long into the point of all this is to share my tool (eventually) if there is interest. I am also open to any ideas or features to add that might be useful ofcourse. And at somepoint I will share the code on GitHub but I need to sort out the licensing of the libraries that I am using and cleanup the code a bit more before doing that.

I am aware of the GBA Backup Tool but I do this mainly because it's a fun challenge

 

[FAST6191]

Don't think anybody expected you to do more than idle discussion there.

Anyway nice to have such things. Validation is an interesting one -- if I can touch it I can probably tell, though future stuff may be better here (though I would then expect matching ROM).

 

[Archerite]

Don't think anybody expected you to do more than idle discussion there.

Anyway nice to have such things. Validation is an interesting one -- if I can touch it I can probably tell, though future stuff may be better here (though I would then expect matching ROM).

I am not sure if you meant my post was to long, or you did not think anybody would expect I would actually go through with an app like this.

Digging through the NDS hardware information I gave making backups of savegames a try. Because of some differences between the GBA and NDS hardware the link cable dumper's code is not directly compatible. Most notably are the different memory addresses on the NDS which I had to change to get SRAM and FLASH dumping to work. For easier testing and debugging I wanted to get the DS connected to WiFi again which was not as easy as I hoped...see here

I also wanted to try and do this on the GBA itself using a multiboot cable. The protocol does not allow high speeds but savegames are small and verifying a cart should not be a problem. Making a backup of the ROM is going to take a while over a multiboot cable though but for completeness...I still want to try it. My calculations at the highest speed I was able to tweak the upload to it has a speed of 28KB/s, taking Zelda the minish cap as an example which is a 16MB game.....should take about 10 minutes. Unfortunalty this high speed is very unreliable and even multiboot fails 3 out of 5 times though

 

[duwen]

A very similar piece of DS homebrew already exists - I can't remember the name of it right now (quite possibly this one https://gbatemp.net/download/gba-backup-tool.3228/ ), but I've been using it for years to dump my GBA carts and save files (and restore them).
If this one ends up with the same functionality but also with in built hash checking I'll switch to this

 

[Archerite]

A very similar piece of DS homebrew already exists - I can't remember the name of it right now (quite possibly this one https://gbatemp.net/download/gba-backup-tool.3228/ ), but I've been using it for years to dump my GBA carts and save files (and restore them).
If this one ends up with the same functionality but also with in built hash checking I'll switch to this

I was aware of the GBA backup tool but from what I could see it's really old and not open source. My main goal for this is learning about both the GBA and NDS though and the hashing was just a crazy idea that actually worked out.

It's just an early prototype right now but thanks for your interest. saving and restoring savegames is going to take a LOT of testing before I trust it works reliable enough to even release a demo version I also might want to upgrade the GUI a bit more to make it look nice and modern, even though it runs on an NDS

In any case: use of this app or anything like it will be ON YOUR OWN RISK.

 

[FAST6191]

I am not sure if you meant my post was to long, or you did not think anybody would expect I would actually go through with an app like this.

Digging through the NDS hardware information I gave making backups of savegames a try. Because of some differences between the GBA and NDS hardware the link cable dumper's code is not directly compatible. Most notably are the different memory addresses on the NDS which I had to change to get SRAM and FLASH dumping to work. For easier testing and debugging I wanted to get the DS connected to WiFi again which was not as easy as I hoped...see here

I also wanted to try and do this on the GBA itself using a multiboot cable. The protocol does not allow high speeds but savegames are small and verifying a cart should not be a problem. Making a backup of the ROM is going to take a while over a multiboot cable though but for completeness...I still want to try it. My calculations at the highest speed I was able to tweak the upload to it has a speed of 28KB/s, taking Zelda the minish cap as an example which is a 16MB game.....should take about 10 minutes. Unfortunalty this high speed is very unreliable and even multiboot fails 3 out of 5 times though

Would probably be a bit hypocritical to note long posts in that way.

More that most such discussions for the time I have been here and other forums start out as "wouldn't it be nice" then we discuss the practical realities or requirements of the project and "urgh effort", possibly tempered further with "if you chain these 5 programs together you can get most of the way there".

Things do still happen but it is rather more notable when they do.

 

[Archerite]

Would probably be a bit hypocritical to note long posts in that way.

More that most such discussions for the time I have been here and other forums start out as "wouldn't it be nice" then we discuss the practical realities or requirements of the project and "urgh effort", possibly tempered further with "if you chain these 5 programs together you can get most of the way there".

Things do still happen but it is rather more notable when they do.

Thanks for clearing that up. I am really bad at giving short answers and tend to go into "too" much details. I'll try keeping my intro's shorter next time or refer to a blog post that has nearly the same info.

I think what you mean about "putting in effort" because talking about stuff is easy, but actually doing it is way more work than you think before you start. I found that out the hard way with my homebrew game two years ago. When things get difficult I do tend to postpone it but it always keeps going through my mind that I want to finish it. Some day.

To keep things moving with this backup app I have been doing more research on how to access the savegames. If what I have read here is true reading saves in NDS mode from EEPROM won't work because the DS is "too fast" for the required timings. Right now I have not explicitly used the ARM7 or ARM9 for this app and maybe I need to look into the differences of these cores a bit more. Maybe the ARM7 which is used when running in GBA mode is "slow enough" to read the EEPROM. I was also thinking about splitting the workload between the CPU's when making a ROM backup to speed things up. Reading the cart itself is really fast but writing to the SD card is very slow, combine that with hash calculations and you are looking at a long wait for the DS to do it's thing.

Looking at where to find the existing GBA backup tool I was not really successful at finding a reliable source to download it yet. It's here in the download section but it seems to be linking to filetrip...which says they have closed down. I think it's time to actually try out the gba-link-cable-dumper on my wii to at least make a savegame backup of the one game I currently care most about: Zelda Minish Cap . And then also try to see what kind of save types the other games have and then compare the results with my own tool.

This may look like "much talk" but it's more of a status update of what I have done.

 

[FAST6191]

Thanks for clearing that up. I am really bad at giving short answers and tend to go into "too" much details. I'll try keeping my intro's shorter next time or refer to a blog post that has nearly the same info.

I think what you mean about "putting in effort" because talking about stuff is easy, but actually doing it is way more work than you think before you start. I found that out the hard way with my homebrew game two years ago. When things get difficult I do tend to postpone it but it always keeps going through my mind that I want to finish it. Some day.

To keep things moving with this backup app I have been doing more research on how to access the savegames. If what I have read here is true reading saves in NDS mode from EEPROM won't work because the DS is "too fast" for the required timings. Right now I have not explicitly used the ARM7 or ARM9 for this app and maybe I need to look into the differences of these cores a bit more. Maybe the ARM7 which is used when running in GBA mode is "slow enough" to read the EEPROM. I was also thinking about splitting the workload between the CPU's when making a ROM backup to speed things up. Reading the cart itself is really fast but writing to the SD card is very slow, combine that with hash calculations and you are looking at a long wait for the DS to do it's thing.

Looking at where to find the existing GBA backup tool I was not really successful at finding a reliable source to download it yet. It's here in the download section but it seems to be linking to filetrip...which says they have closed down. I think it's time to actually try out the gba-link-cable-dumper on my wii to at least make a savegame backup of the one game I currently care most about: Zelda Minish Cap . And then also try to see what kind of save types the other games have and then compare the results with my own tool.

This may look like "much talk" but it's more of a status update of what I have done.

Do a search on my post history and tell me if you think I don't do all the asides, off topic and whatever else. I usually have to force myself not to, and it is more a habit from the rest of life where "you didn't tell this could be an issue" is a thing.
That said I would much rather pick out info from posts than at the end of a search encounter "solved my issue", indeed "sign in and pay $10 a month to view the replies" would probably be less infuriating.

EEPROM is usually a pain in whatever save game dumping stuff we do (see most flash carts in the GBA era with linkers) and while I am not in a hurry to contradict gbatek I do have to wonder if some choicely inserted NOPs and say a few multiple reads to confirm accurate might be able to get somewhere even if it is impractical for say the commercial ROMs that read GBA saves to feed info to DS games.

Yeah the end of filetrip made things quite a bit harder. It was supposed to gracefully fold back in to the download section (indeed it started life as the download section here, though development of/changes to both happened extensively since then) but seems some unexpected stuff cropped up.
I will have a wander through my archives one day as I have a lot scattered across drives here.

 

[Archerite]

Do a search on my post history and tell me if you think I don't do all the asides, off topic and whatever else. I usually have to force myself not to, and it is more a habit from the rest of life where "you didn't tell this could be an issue" is a thing.
That said I would much rather pick out info from posts than at the end of a search encounter "solved my issue", indeed "sign in and pay $10 a month to view the replies" would probably be less infuriating.

EEPROM is usually a pain in whatever save game dumping stuff we do (see most flash carts in the GBA era with linkers) and while I am not in a hurry to contradict gbatek I do have to wonder if some choicely inserted NOPs and say a few multiple reads to confirm accurate might be able to get somewhere even if it is impractical for say the commercial ROMs that read GBA saves to feed info to DS games.

Yeah the end of filetrip made things quite a bit harder. It was supposed to gracefully fold back in to the download section (indeed it started life as the download section here, though development of/changes to both happened extensively since then) but seems some unexpected stuff cropped up.
I will have a wander through my archives one day as I have a lot scattered across drives here.

Looking at how long you've been here reaching level 25 and your message counter, I think it's not my place to tell you anything. While reading the exiting threads I do see your name quite a lot and you always seem willing to help out with the questions asked. And I did notice a lot of them ending without solutions or even a "thank you" a few times. Anyway, my whole point mentioning you by name was to thank you for the encouragement to create this app.

Like I said last time I have tested making a backup of the EEPROM saves with the gba-link-cable-dumper using my Wii and that worked perfectly! Finally have a backup of my progress in Zelda Minish Cap and it loads without issues in emulators and on the 3DS! Even on the DS with GBARunner2 it loads perfectly and I even continued playing it there long enough to be "out-of-sync" with my cartridge. So I might give restoring the save a try later since it's supported. And as I said on my blog already I also tested the speed of making a ROM backup with gba-link-cable-dumper to see how long it would take. Ofcourse the cable protocol makes it really slow, but for a 8MB game it took 12min which I guess is not bad if it's your only option. It's not like you would be making daily ROM backup's of every game you have right? Backing up savegames is less than 3 seconds and I think that's reasonable.

Doing some more searching for the GBA Backup Tool I found one of your posts actually with a direct link to filetrip. Ofcourse the link did not work anymore but with that I could look it up in the internet archive and it actually had "captured" a snapshot of the zip file. So without much effort you pointed me to the download, thanks! I have not tried it yet because I want to do that on a fresh SD card without anything important on it just to be save . But hovering my phone and google lens over the "Readme" to translate Japanese into English I could make out that it supports reading EEPROM's from NDS mode. Wiithout sourcecode, examples or more detailed info it will be difficult to reproduce that feature, but at least this shows it's indeed possible to do it somehow.