Go Down

Topic: ROM-Reader for Super Nintendo / Super Famicom Game Cartridges (Read 389127 times) previous topic - next topic


PIC12F675 will not work with the snescic-lock-resync.hex

PIC12F629-I/SN is widely available.  Mouser, Digikey, Farnell, Newark, etc.
Hi skaman,

Thanks for the response, and I appreciate the detail. I was just trying to cut down on multiple orders. I'm looking forward to getting the parts in and I hope I can contribute to the project here in the future.



Seems like it's back in stock @lcsc again.



When trying to read cartridges with the cartridge reader, I'm getting a corrupted file (as well as a corrupted name in some places). Someone recommended I use 91% isopropyl alcohol to clean the cartridge contacts, but it doesn't seem to have made a difference. I think the problem may be a soldering issue, and I even have a multimeter to test connections, but I'm not sure what to test (I've already tested the 3.3V line per a previous post). Is there a visual that shows how everything is connected or a list of solder connections to test so I can make sure everything is connected as it should be?
I'm trying to dump N64, Genesis, and GB(C/A) games, but N64 is my first priority and so I've tried those the most.


I ordered the boards, and am in the process of ordering parts. Most of the parts are only available in bulk anyway, so I was wondering if I could find 9 people who want one and don't have one yet. If so, I can buy enough for 10 and then divide out and send them out at cost. I don't care about making a profit, but the inefficiency of 10 people buying parts, many of which are only available in bulk, and making 1 each and just... having 9 spare boards and 99 spare 100nf capacitors and 99 spare 1K resistors... it hurts me deep in my soul.

Anyway, the boards are blue, I also have the SD card conversion board, and the SNES to NES adapter. I won't be including the Mega, since it's easier for you to get your own, but I have a 3D printer so I will provide 3d printed parts to order. I won't even calculate the cost of the plastic because that's a pain. I only have red, blue, black, and white PLA, and clear PETG, although if enough of you want the same color I could probably be convinced to expand my palette.

Who's in?

EDIT: Oh, and I'll pre-program the pic, too
I'd like to be added to the list of people you're offering parts to, if there are still any available.  I've been thinking about ordering these parts myself since well before COVID-19, but that has now made ordering the various system's connectors from aliexpress much more daunting.

Blue PLA would be nice, but I did already buy a 3D printer with this project in mind.  All the boards you're offering were my intent as well.  I didn't buy a PIC programmer yet, so it would save some time if you still want to program it.  I probably should get one anyway, though, as you never know what will be needed for the next project.

I appreciate all the hard work that went into this, and continues to.  Even keeping an up-to-date BOM seems hard.  Thanks Sanni, and everyone else helping to improve and add to the functionality and compatibility!  I think it'll be quite a fun soldering project too, although I don't plan on using a heat gun.  I'm pretty good at soldering, though.  Sanni, your build video is quite an inspiration.  :)


The pinout can be found either:
- as an Excel file here https://github.com/sanni/cartreader/blob/master/pinout.xls
- as a picture here https://github.com/sanni/cartreader/blob/master/pcb/cartreader_schematics.png
- or in the Eagle PCB schematic/board files here https://github.com/sanni/cartreader/blob/master/pcb/eagle%20design%20files/cartreader.sch and https://github.com/sanni/cartreader/blob/master/pcb/eagle%20design%20files/cartreader.brd
In the Eagle schematic, it seems like there are some N64 pins that don't connect to anything. Am I misunderstanding the diagram, or are they unused pins?
Here's an example: https://photos.app.goo.gl/ks7DNUF1WRmwJhsT9


Yes some pins are unused. In this case Audio Left and Right.


Hello, anyone have any pcb for snes cart that i can use with it?



Using a multimeter, I checked the connectivity of every needed N64 pin to its respective pin directly above on the Arduino board pin. I saw no connectivity problems, but I am unable to dump cartridges of any type that I have. For N64 games, the title reads incorrectly (for example NEVTDTRIR for New Tetris and RTRWRRDP0RABER for Star Wars Pod Racer) and checksum checks fail (also different checksums on each dump). Genesis and Gameboy cartridges have similar issues, except on Genesis the title at least reads correctly. 
Does anyone know what may be causing the problem here or what I can do to get better information on what's going wrong? At this point I think there is one issue affecting all cartridge types, but I've tested N64 the most.


Open the dumped rom in HxD Hex Editor, maybe you can see a pattern that would point to a specific pin:

If the Cart Reader reads NEVTDTRIR instead of NEWTETRIS then:

W is read as V (hex converted to binary)
W: 0b1010111
V:  0b1010110

One E is read as D
E: 0b1000101
D: 0b1000100

S is read as R
S: 0b1010011
R: 0b1010010

The pattern I'm seeing here is that something is wrong with N64 pin AD8 connected to Arduino Pin A8 (PK0). Since it only seems to affect the first bit of the high byte.

Now you can dump a Gameboy Classic game and check if the dumped rom also shows errors on Arduino pin A8 in an hex editor. Since the Gameboy doesn't use the Arduino pin A8 for data but only for the address, a pattern should be more visible there.


I'm not sure exactly what to look for to tell if the problem always lies with one pin, but I attached two screenshots of the beginnings of ROMs: Tetris Plus for Game Boy and New Tetris for N64. Tetris Plus is called "ong" but another ROM I just tried (Aladdin for GB) has a blank name. What do I need to look for to determine if a pattern suggesting a problem with A8 exists in both ROMs? Is there a way I can make HxD show binary?


Ok, this is a very good example.

So the Game Boy has both address and data lines. Address lines can be either 0 or 1. So if you only had one address line, like A0, then the ROM could only be 2 bytes long. If A0 is 0 then the first byte is addressed, if A0 is 1 the second byte is addressed.
Now with each additional address line we can double the ROM size, so with 2 address lines the ROM can be 4 bytes long, with 3 address lines the ROM can be 8 bytes long and so on.

This is how Tetris Plus is supposed to look.

This is how your Tetris looks:

If you compare the two you notice it's perfect up until address 0x100, then it weirdly just starts from the beginning again. 0x100 is 256 in decimal. Now we just count at which address line the bytes hit the fan.

A0: 2
A1: 4
A2: 8
A3: 16
A4: 32
A5: 64
A6: 128
A7: 256
A8: 512

So if everything up to A7: 256 is fine then your problem is A8.

So yes that confirms my previous guess. You got A8 shorted to GND. Get a multimeter put it in diode/short circuit mode, put one probe to A8 on the Arduino, put the other to GND and it should beep or display a short.

Now your goal is to remove this short. It could be on any of those pins:

If you got a desoldering gun, desoldering pump or some desoldering braid and some Flux you should desolder the circles pins and check again if the short to GND is still present after.


(I already made a similar reply once, but it doesn't seem like it's showing up on the forums, and I need to add new information anyway) 
I looked for a short but could not find one, although I'm not sure I understood exactly which pins to check; however, it seems that a short was not the problem. The problem was a weak connection at AD8 on the pin directly above the Arduino's corresponding pin. When testing, I was inadvertently pushing the pin just enough to make contact, so the test seemed fine, but there was only a good connection when pushing against the pin. 
I soldered the pin better, and now all of my GB(C/A) games passed checksum, and Genesis games seem to work as well (I haven't tested all of mine yet and I expect that some might not work anyway because of special mapper chips). N64 games show the title properly as far as I can tell, but the cart reader acts like checksum fails (and the checksum claims to be different each time). When checking the md5 manually, however, it seems to match no-intro and other online data (I got 7A28179B00734C9AA0F0609FAFAAFD5F as MD5 for New Tetris). The games boot in an emulator. I tested another cartridge, Namco Museum, and got 3 different CRCs (2e9524a3, c41a93ab, and 0a903011), but when I used HashTab to check the CRC32, it was CE361F92, which matches the value in n64.txt. 
Thank you so much for your help in identifying the problematic pin. It was much easier to fix the problem knowing where the problem was. The behavior when reading N64 cartridges is bizarre, but the output files seem to be fine, so I'm happy with this result, but I'm also happy to keep testing if you want to figure out exactly what's happening (especially if there's a chance the problem is something that could be fixed software-side). What do you think the checksum problem might be and have you ever heard of something like this happening?


Could be the SD card. Since the ROM is fine your Cart Reader probably works ok but when reading the ROM back from the SD card it gets read errors. You can test this theory by reducing the sdSpeed in Cart Reader.ino from SPI_FULL_SPEED to SPI_HALF_SPEED and reupload the code afterwards:

// Basic Libs
#include <SPI.h>
#include <Wire.h>
#include <avr/pgmspace.h>
#include <avr/wdt.h>

// SD Card
#define sdSpeed SPI_HALF_SPEED
Or by trying out another SD card preferably made by Sandisk.


Aug 04, 2020, 10:46 pm Last Edit: Aug 04, 2020, 10:59 pm by jaffa225man
@DieKatzchen Please see PM. Would love to start building this soon
@DieKatzchen Please see my PM too

I seemingly haven't been noticed, although I was a bit later than you.  Did you get a response?  Thanks!

Edit: Ah, I checked my forum settings and the defaults don't notify through email, so that probably explains it.

Go Up