Game Boy Cartridge Dumper - General and Python help needed

Alright, so, I got a Game Boy cartridge dumper. However, this is more of a homemade solution. I didn't make it myself, though - I got it from a guy in Australia (website here for more info and here).

Originally, he wrote the software in VB6, but later rewrote it in Python so that it could be multi-platform. He seems like a nice guy, but I'll be honest - I'm not sure how much work he's actually done on the software, at least as far as making it multi-platform. The Python scripts are far from complete (well, on the GBA side, anyway). The problem is, my abilities are still pretty limited. I've never really been able to "learn" coding or programming (aside from HTML, which somehow just came naturally), so I don't know where to start with Python, but I know pretty much all the basic programming principles and what-not. It's just language specifics that are often beyond me. In this case, I can mostly understand what the Python scripts do, but how to alter them to improve them gets tricky once I get past the basics. So, I've come here for help.

Please bear with me, because this is going to be very long-winded. There are several key features I'd like to add because they're important, so I'll mark each one (and edit this post if and when each one is resolved). I have also added the scripts to the bottom of this post so that you can download them and look at them yourself (that way, you have at least some point of reference for what I'm talking about). There are three included - my modified GBA one where I started working on #1, and the original one for comparison (with a few tweaks that were necessary to get it working in the first place, but it's still, for all intents and purposes, the "untouched" version).


I'll try to break it down a little:

The cartridge dumper uses an ATMEL ATMega128A, programmable via USBASP (although firmware is preinstalled but he has made updates - I haven't been able to confirm if mine is the latest or not) and connects to a computer via a Prolific 3032 serial-to-USB adapter.

It has two modes - GB(C) and GBA. That should be pretty self-explanatory.

There are two Python scripts (they use PySerial) - one for GB(C) and one for GBA. Again, self-explanatory. I have had no luck getting the VB6 program working on Windows 7. The best I've managed is to get it running, but I can't seem to do anything with it. He claims that this is the software he has been working on the most (I should mention the VB6 application only does the GB(C) mode), and that it has had a bunch of improvements, but since I can't get it working, I can't test it.

I've added some basic functionality to the scripts to allow Python to detect the OS instead of requiring different versions of the scripts for different operating systems.
The reason separate scripts would normally be required is because of how the device port is specified in the script. It's virtually the same between Linux and Unix (primarily OS X), but it's different for Windows. I'm not sure if other people he has sold these to have had problems (I suspect they're primarily using Windows, regardless, although I've heard that someone did use it with Linux successfully), but for both Mac and Windows, I had to manually add port locations - Python wouldn't find them itself. To this end, I implemented the OS detection, although currently, it only detects OS X or Windows, and has an else option for Linux (I have yet to actually do any Linux testing, but that'll happen in due time).


#1: Headers

The Game Boy (Color) script allows one to read the cartridge header to get useful ROM information (game title, MBC, ROM size, RAM size). Recently, it has stopped displaying the game's title on OS X, but the exact same script still displays the game title on Windows. It WAS working on OS X, so I'm not sure what stopped it. Maybe it was the Yosemite update (which has been a bit of a mess, frankly). The weirdest part is that if a cartridge isn't lined up properly or cleaned properly or whatever (you know, the sort of thing that might cause some glitchy graphics or sound on actual hardware), the name of the game will show up (jumbled, of course, but it shows up nonetheless). It would be nice to fix this, but I don't really know what the problem is, so I don't know what to look for.


However, the biggest problem is that the Game Boy Advance script doesn't have this header-reading functionality, and I have been fruitlessly trying to add it. I don't understand what the strings at the very top of the scripts are (other than that they're addresses, but I'm not sure what the addresses are for - the ATMega128A or the cartridge?) and even with all the cartridge information available to me, I can't figure out how to read from the specific places I want to read from (in this case, the header of the ROM).

This is where things start to get really confusing, at least for me. In the GB(C) script, he has used the variable "Address", but in the GBA script, he has used the variable "Blocks". These SEEM to be interchangeable, except that their base unit of measurement seems to be different. "Blocks" seems to be 1 Megabit, whereas "Address" seems to be equal to 1 Kilobyte - I've extrapolated this from the way he has used them throughout the rest of the scripts. Of course, at least in the case of reading the header, the range for these variables is specified. I don't think I need to explain why you specify a range and not a single number, but the problem here is that the numbers I specify don't seem to work.

The GBA ROM header is, if I'm reading this correctly, only 192 bytes. If the variable is measured in Megabits, I don't see how I can change the unit of measurement nor specify it in Megabits when the next smallest number after 0 will be 1, and that's 1 Megabit - far too much more than 192 bytes.

On the subject of changing the units, I'm not even sure how it can be different between the scripts to begin with. I must be missing something that specifies that, so if someone could point out how this is done, I'd appreciate it. I want to learn how to do all this by myself i.e. I don't want someone to just rewrite the scripts for me, else I won't learn anything. I just need to learn how to actually do it... if that makes any sense.

By the way, in the GBA script, I've added a "ReadHeader" part to the bottom. I was fiddling around, trying to get it working, so that's why that is there. I've commented out a lot of stuff that is either irrelevant or, for now, getting in the way. The only part that currently works is the MBC, which returns a huge number that is obviously incorrect. If I understand correctly, though, GBA cartridges don't even have an MBC. Maybe they have an equivalent. I'm not sure.


#2: ROM size (GBA)

As far as I can tell, the GB(C) script is fairly complete. I'm sure there is plenty that I can improve down the line, but the biggest problem is that the GBA functionality just isn't there. Case in point: when dumping GBA ROMs, they will ALWAYS be 16,777,216 bytes (128 Megabits - OS X tells me they're 16.8 Megabytes, which is obviously rounded up slightly). Obviously, not all ROMs are this size, and correct me if I'm wrong but I thought there were a few that were bigger (i.e. 32MB, but it seems that's actually 32Mb - it's really confusing when people write Megabits as MB. I guess it's not horribly incorrect, but it sure makes my head spin, hence why I've mostly typed them out in full here). Anyway, the GB(C) script handles different ROM sizes fine when dumping. The GBA script does not. I cannot for the life of me work out why. I assume it has to do with the dumping code's address range, but how one script can dump ROMs with the correct file size but the other not, I'm not sure. If someone can enlighten me so that I can finally dump the GBA ROMs correctly, I'd appreciate that so much.


#3: GB(C) Dumping... in general

So I know I said this one was fairly complete, but I never said it was perfect. There's one glaring problem that stands out to me, though: GB(C) games that I dump refuse to work in NO$GBA. It will throw header errors at me all day long. VBA works fine, but I believe VBA is a lot less picky, anyway. I have NO idea what the cause of this is so... this one is pretty short. Help, please?


#4: Flash Carts

I don't have any GB(C) flash carts, but I have two GBA ones. The creator of the dumper has made his own flash cartridges for all three systems as well. I assume they're rewritable ones although I'm not sure how his boot menu works. That is, I assume he wrote it himself and it isn't based on pre-existing software, but I'm not really sure. I guess you just keep writing ROMs to the cartridge, and once it's full, it replaces them in order? I don't really know. I don't have the money to find out, frankly.

Anyway, the two GBA flash cartridges I own just happened to be two of the biggest pain-in-the-ass carts to program. One is an EZ Flash 3-in-1 (GBA-sized, because duh), which of course is only programmable (for now) via a DS and DS flash card. Problem is, my DS died a horrible death and has yet to be replaced.
The other one is a cart that I should really made a separate thread about in the future because it is the biggest oddity (to me, at least). It's called "GBA Link", and claims to be a "64M Flash Card". There's only one problem - I've never got it working, because to program it, you have to use a parallel cable, and I currently don't have any PCs with a parallel port. Now, the website that is written on the linker is defunct, but I managed to find it through web archives. Most of the information is in Chinese, and that's one language I don't speak (on top of pretty much every other language but English). I managed to track down all the software mentioned on the website, though, so I have all that. I just can't use it without a parallel port. Hell, I don't even know if the linker works or WHAT the linker is. My first guess was that it was a multi-boot cable, since it connects to the GBA's link cable port and you're meant to program it by putting the cartridge in, turning on the GBA and... well, you know the drill. I'm unaware of whether or not there are cables that do this that AREN'T multi-boot cables. I'm hoping what I have is indeed a multi-boot cable, because it could be invaluable to me in the future. But anyway, I can't program this cart, either, so I want an easy way to do it.

Okay, with that lengthy explanation out of the way, it should be obvious that the Python scripts have writing/burning functionality. However, they can't dump from nor write to these cartridges (the GBA Link has nothing on it - I tried using the EZ Flash 3-in-1 tools to write something to it a while back and had no luck - but the EZ Flash has a game on it, so I know there's a working ROM sitting there). I want to change that... and I have no idea where to start. From what the creator told me, it sounds like I'll have to change address values. Sounds pretty simple except, well, at this point, it should be clear that I have no idea how to do that (nor what is so different about these cartridges). I'm going to need a boatload of help on this one.


#5: Making a single script (also the last... for now)

Having two scripts is cumbersome. Hell, having one is cumbersome (at least when you have buggy TCL/Tk thanks to Apple refusing to update OS X to a non-buggy version and having a secondary version installed causes more problems than it's worth), and I'm looking into finding a way to change that, even if it means I have to make separate executables for different platforms. There are ways. I just need to learn how. But for now, I'd like to make one script. Obviously, that means combining the two and having Python detect which mode the dumper is in... and I have absolutely no idea where I'd even start with that. My guess is that the ATMega128A would need to be specifically programmed to send this information back to the computer, and I presume it doesn't do this (but I don't know any of this for sure). I've replaced the jumper with a switch, although it'd be even better if the cartridge dumper could detect the type of cartridge and switch modes that way... but even if that's possible, it's far from easy. Even Nintendo stuck a switch in the GBA to change cartridge modes. I'm happy with a switch. Beats having a jumper.


That's all I can think of for now. I realise that this is a (very) tall order, but any help is appreciated. I want to learn more, and I want to improve the functionality of this awesome little device that I own. I'm hoping that in the future, I can recommend it as a cheap, foolproof solution, but for now, the kinks need to be worked out. The creator is a little hard to talk to - I don't want to harass him with emails, but when I have emailed him, he hasn't always given me straight answers. I'm not blaming him - like I said, he seems like a nice guy, and obviously, this is more of a pet project than his day job, so I don't mind doing some of the work for him so that others can reap the benefits. I just need a little lot of help to get me going. Heck, even if you can't help and you read all of this, I appreciate it.

Download the Python scripts here.

 

Glad I saw this thread! I went to the site you linked and he said that it works with the Game Boy Camera, which I just bought about 2 week ago (I bought the red one). I wonder if it would let me dump my GB Camera pics to my PC... I'm seriously considering buying this now!

I always had trouble using NO$GBA on my Windows PCs. Mostly when using DS software. Whenever I need to emulate the Game Boy line, I use VBA because it actually works for me and it gave me some cool options like controller inputs and SGB features.

 

Just be aware that all the problems I am trying to correct are still present. It does indeed work with the Game Boy Camera and there is software to extract the pictures from the saves. I'll dig out my camera and try it later then let you know what to do.

 

Ok and thank you! I've been wanting to get my pictures off of it but couldn't find a cheap solution.

 

There are two tools that you can use - GBCamera Dump and Funtoshop. Try them both and see how they work from you. I'm not on Windows right now so I can't try them out but they should both work fine. You'll have more luck with the former if you're on Windows XP or lower, from what I can tell, but Windows 7 should be able to handle it. Windows 8 MAY cause trouble, but I'm not sure - I don't currently have my Windows 8 installation working, so I can't try it out.

I found this which may prove interesting to anyone who wants to know a bit more about GBCamera Dump, including the source code and a little bit about its origin: http://www.quora.com/Where-does-the-program-GBCamera-Dump-come-from

Otherwise, you can download the tools here:

Funtoshop
GBCamera Dump (via gameboycarts.com)

Alternatively, there is an online Game Boy Camera save file converter here: http://gieskes.nl/gameboy-camera/sav-converter/

Here's a guide for Windows: http://alt.pathawks.com/gameboy-camera

Also, a guide for dumping photos on OS X instead of Windows: http://thretris.blogspot.co.nz/2009/12/how-to-gameboy-camera-dump-on-mac.html

I strongly suggest that if you're not familiar with Python or at least know that you're unlikely to to be able to figure it out relatively easily, that you go with a slightly more expensive solution (GB Smart Card, a 64M card, a GB Everdrive or whatever - basically, a Game Boy flash cart that can be connected directly to a computer, as well as a Mega Memory Card/Magic Memory Card/some equivalent (check out Tototek or gamedoctorhk. I know Tototek has an equivalent relatively cheap). It's not as efficient but it's arguably a lot easier, especially if you have no idea about scripts and Python and code and ports and the like.



And now, back on topic.... I still need a LOT of help... :\

 

Thank you for the GB Camera info. I really want to help but I don't know how to program software yet. I'm planning on going to college for it later this year. I have a Raspberry Pi Model B that included some Python tools but I haven't used them yet. Where can I start learning how to write scripts and use Python or coding in general?

 

Good luck with that. Personally, I find it easier to teach myself. University bored me to tears... As for where you can learn now, I can't give any solid recommendations, because honestly, I'd like to know myself. Off the top of my head, I'd say good sources are probably Code Academy and W3Schools.

 

Ok, thank you. I'll take a look at them. I posted a new thread asking if someone could make a GB Camera to PC USB device so it can simplify getting those pictures to a PC. I used a Capcom-style name for it too.

 

There honestly isn't much point in such a specific device. You'll either have to build a USB interface directly into the Game Boy Camera, which would most likely entail similar hardware to that of a cartridge dumper, or you'd need to use a cartridge dumper. Therefore, just buy a cartridge dumper.

 

I was going to buy a dumper anyway but I figured something designed specifically for the GB Camera would be neat.

 

I sympathise with your idea - I've wanted to do similar things before. The problem is, it's unlikely that you'll find a practical solution that isn't a cartridge dumper, or if you do, it'll probably be a lot more effort than it's worth.

EDIT: I tried to give you a more detailed explanation in your own thread.

 

Bumping because I'm crying on the inside. =3

 

Hi TankedThomas,

Thanks for the deep review, I'd like to offer some assistance.

OK, so the 'DualMode' version of my hardware originated from someone asking for GBA dumping support. I added GB support because a lot of my routines ported across easily. It was designed with GBA in mind (in particular, flashing my GBA flash carts)

Onto Python. I hate python. I hate it so very very much. This was a necessity because people were having issues running VB code on their modern PC's. (This problem is now gone, I've included an installer) and needed a cross platform language.

The VB program will not work with the DualMode firmware. There are few discrete discrepancies between the two firmware versions which prevent this from happening. Originally the DualMode code was written in VB6 (Its on my HDD somewhere).

As for the Reader/Writer doing what it was intended, I believe it is. It dumps GB/C Carts, Reads and Writes their saves (and GBcam support) and the GBA side of the code will Dump 16mbytes of GBA ROM (If the cart is smaller than 16mb, it will mirror to fill the 16mb buffer - this was coded for my flash carts) Flash to compatible carts and read/write their SRAM.

This can be changed in the script (apologies for the structure of my code. I learnt all that python in around 3 days so it is far from perfect)

So, I can send you a firmware update (for GB/C mode) which will let you use the VB program (which has had around 15 revisions over the last 2 months) but this will not let you dump GBA carts.

If all you are after is GBA code improvements, we can work through this on here if you like. I've started a new position at work recently and ALL my spare time has vanished. I'm starting to get on top of this new work so I'll be available a bit more.

Hope I haven't caused you too much grief!

Look forward to hear from you soon.

Ben

 

Hey Ben, thanks for your reply. You didn't respond to my last email (and it's evident why), so I didn't want to harass you because I assumed you'd be busy anyway. Glad to hear things are working out for you. I was going to wait a bit longer before sending you another email, once I actually had some progress, at least on the physical side (I'm slowly constructing a casing for it which is coming along pretty well, although replicating it may prove difficult). Looks like you beat me to it!

I can totally understand why you don't like using Python. It seems like a poor substitute for something like Visual Basic. However, since my coding skills are mostly limited to HTML, I can't really do much about that myself.

I'd prefer to keep the DualMode firmware, as I like having the ability to use GBA cartridges. I was wondering, though, if the firmware offered any other improvements that could be added to the DualMode firmware. If not, then it's irrelevant.

Since you asked me about developing for OS X, I was going to look into porting the Python scripts over to Swift, because it seems relatively easy, but I haven't looked into it much yet, so I'm unsure how heavily it still relies on Python. Doing something from scratch would be pretty hard for me right now, but if anyone, including yourself, wants to help out in any way, I'm totally open to giving it a try.

The code structure is good enough - it's fairly modular and the scripts are relatively short, so I can understand most of what is going on. All the addresses and what not is where I start getting confused, though. I would definitely love to remove that buffer, just to get accurate ROM dumps. You said once before to me that it should theoretically be possible to add support for an unsupported flash cart, so I want to do that. I'd love to grab some of your flash carts, too, but I have no money at the moment, so that won't be happening any time soon, unfortunately.

I do want to increase as much of the GBA functionality as possible. I don't want to tell thousands of people to go buy your cartridge dumper because, at least as far as I know, that would be difficult for you to produce so many and would be overwhelming. If, however, you would be fine with that, then that's when I'd start recommending them to people. Still, as a cheaper alternative to other cartridge dumpers, it's not complete (at least, GBA-wise), so I wouldn't want to recommend it to just anyone yet, since some people will have less of a clue than I do.

I'm not sure if you've looked at my modified scripts, but I've done some minor improvements on them, so that's at least a start. I'm still not sure why, when run on OS X, I can't see the title of a GB(C) cartridge, though. I'm also unsure why NO$GBA complains about header problems on the ROMs. You're write that it does what was intended, and the ROMs seem to dump fine for me, but as to why NO$GBA complains, I'm not sure. It says that the ROMs would likely fail to run on regular hardware, although how much such an error could be trusted, I'm not sure. It's just odd that the ROMs dumped with your cartridge dumper (frankly, I just call it a dumper because it's quicker than typing reader/writer, and most everyone knows what "dumper" means, anyway) don't work in NO$GBA but ROMs dumped via other means do. I should grab some different ROMs for the games I have dumped and compare them. Maybe then I'll figure it out. I might do that in a few hours, then I can report back.

Anyway, don't worry, you haven't caused any grief. I just want to help improve this little device because it is a good, cheap alternative, and I'd love for it to be fully-featured, especially so more people can get ahold of one. I was under the impression that the GBA mode was indeed an afterthought, so to speak, so I assumed it wasn't your main focus (especially if, correct me if I'm wrong, the primary purpose, at least originally, was for use with LSDJ and perhaps the Game Boy Camera). That's why I wanted to pursue it, but it seems, in the end, I'm making you do all the work instead. Haha, sorry about that.