abrugsch / gbcartslurp

Raspberry Pi gameboy cart dumper

NOTICE:

This project may be deprecated as I can't really get the transfer speed up to where I'd like it for a RPi 1/ZERO. I'm going to experiment with SPI however after playing with a JoeyJoebags the speed difference between using a microcontroller as the interface is phenominal. a cart that takes 9-ish minutes to dump using I2C takes mere seconds on a joebags. I know the interface on that is a microcontroller so I'm considering switching totally to a teensy as the interface, unless SPI/23S17 chips can make a significant difference. If the switch to SPI is acceptable, then there are actually minimal changes to the circuit after swapping over to the SPI versions of the chips
The above has changed in the past year. I have got the SPI 23S17's working but they were unreliable. I have found an implementation of SPI reads that does work reliably and will port my code into it when time permits.

GBCartSlurp

Dumps Gameboy and Gameboy color cartridges with a suitable reader. Code is based on the original @insidegadgets GBCartRead for arduino but modified to work with the wiringPi library on the Pi. The hardware consists of a Raspberry Pi and 2 MCP23017 I2C 16 way port expanders. See GBCartSlurpWiringDiagram.svg for how to connect the Pi and configure the 23017's. Full configuration to be documented once the design is finalised.

Status:

the code works with the published schematics but is quite slow however it is functional and once I've tried SPI, I'll have an idea what direction this project is going to head in.

here's a vid: (sorry for the long setup time. skips to 3:50 for the meat)

PCB:

if you want to order a PCB form OSHPark for the I2C variant in the most recent state I had them made then the link is here:

You'll need the SSOP variant of MCP23017 to fit the PCB and the 0805 LED's and resistors (anything from 330R to 1K should be fine. just depends on how bright you want them!!) are entirely optional, as are the decoupling capacitors though they are recommended

Deps:

wiringPi specifically the header file 23x017.h for the port name defines

Improvements:

higher speed may be acheived with the SPI version of the MCP23S17 port expander

gbcartslurp's Issues

Documentation on wiring

Love your project and I'm really happy I found it through Reddit.
I've been working on a similar solution for two month without getting it to work properly so I'm really looking forward trying yours. Do you have some better pictures of the circuit or schematic on how to wire those two expanders?

banks don't change when reading multi-bank carts

just needs writePins changing to 0x6

"Save SRAM data to cart" does not use the input filename.

From what I can tell in the source, the WriteRam function only uses a file named "TETRIS.sav", and not the input from the program. This should either be noted in the program (ie: tell the user to have a .sav file with a specific name), or take the input from the user.

speed improvements

TODO: cleanup redundant operations in main loops, drop dependency on wiringPi and enable fast sequential mode (see https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=141142&p=935145 )
work so far on this has seen a ~10% boost in dump speed with further gains from sequential mode to come.

[Possible Issue] Larger games not dumping correctly

I finished wiring the dumper, and it seems to work well with most games. I cannot for the life of me, however, to get a working dump of either pokemon silver or crystal. I have been able to make multiple clean dumps of everything from Tetris to the Oracle games (sha1sum matched those of clean dumps), so I don't want to attribute it to the fact that it is on a breadboard. The weird thing to me is the fact that the Nintendo header and such are completely intact, and show the correct values. By comparing a previously obtained ROM to the ones made during the dumps, no values in the incorrect parts of the ROM seem to match any with the clean one, but the ends of the incorrect ROMs match; part of the ROM almost seems to have random bytes. Both silver and crystal have 128 banks, and I don't have another game with that size to test. The largest successful dump was Oracle of Ages, which has 64 banks. Any ideas?

Abrugsch, if it would help, I can send the dumps to you, but I can't post them here.

Add interactive mode

At the moment the code will just dump the cartridge and SRAM contents in a fixed manner.
Add a menu to select dumping the cart or the SRAM or both, or writing SRAM from a file.

add GBA support

port the arduino code from https://github.com/shinyquagsire23/GBA-GB-ROMDumper to work on the RPi

make GBCartSlurp into a FUSE module

Use FUSE to allow the cartridge ROM and .sav be represented as a file system readable file.
see http://www.maastaar.net/fuse/linux/filesystem/c/2016/05/21/writing-a-simple-filesystem-using-fuse/

Inconsistency with wiring diagram.

Attempting to make this with a breadboard, but I'm confused by the diagram. For the middle addr bus, the top shows it goes through pins 14-21, which is 8 pins. The connection to the chip shows that it connects to pins 1-7 on the chip, which is 7 pins. The connections labeled between these connections are labeled both A8-A15 and A8-A16, which is 8 and 9 pins respectively. Is this a diagram issue?

EDIT: [off topic and figured out so removed]

EDIT 2: It appears that the correct number of connections is 8, but the issue of the wiring diagram still stands, so I'll leave this open.

~RESET pin forced high - this is CS2 for GBA

In the schematic the ~RESET pin has been attached to Vsc which means that for GBA it will cause problems related to CS2 devices (certain savegame types use CS2) so instead of tying it to Vsc it needs to be controlled by U2 GPB3. This needs to be reflected in the code (even for GB/GBC) otherwise it will be uninitialized and float