abrugsch / gbcartslurp Goto Github PK

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.

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.

just needs writePins changing to 0x6

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.

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

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/

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.

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.

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?

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