Go Down

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

Pirateiro_Digital

Thank you sanni!
Yes, you can use both directly:
https://www.aliexpress.com/item/FREE-SHIPPING-1PCS-LOT-Reading-and-writing-module-SD-Card-Module-Slot-Socket-Reader/32262829840.html
https://www.aliexpress.com/item/Micro-SD-card-mini-TF-card-reader-module-SPI-interfaces-with-level-converter-chip/1000001126725.html
Thank you!

Newbie2

Sanni, really appreciate your guidance in response to my questions. The erase didn't work, I am going to reach out to BennVenn to see if he has thoughts on what actions are necessary to get it to erase. Irregardless of whether I suceed, I very much appreciate your assistance.

Merix347

Hi There! I am looking into building my own 64 rom reader and was excited to see this project! I was looking at the github for the code and the specs and noticed there was no pcb file for 64 hardware variant.


This is the cart reader variant I want to build:
https://github.com/sanni/cartreader/wiki/Cart-Reader-64

Am I missing something? Thanks

sanni

The erase didn't work
Try to replace the erase command block with this, basically just adding the " << 1":
  // Erase flash
  writeByte_GB(0x555 << 1, 0xaa);
  writeByte_GB(0x2aa << 1, 0x55);
  writeByte_GB(0x555 << 1, 0x80);
  writeByte_GB(0x555 << 1, 0xaa);
  writeByte_GB(0x2aa << 1, 0x55);
  writeByte_GB(0x555 << 1, 0x10);

Then check if it gets erased now.

This is the cart reader variant I want to build:
https://github.com/sanni/cartreader/wiki/Cart-Reader-64
That is a very old design. Only the newest PCB with the 4 slots is available on github. If you only need N64 just leave the other slots off.

Merix347


Newbie2

Try to replace the erase command block with this, basically just adding the " << 1":
  // Erase flash
  writeByte_GB(0x555 << 1, 0xaa);
  writeByte_GB(0x2aa << 1, 0x55);
  writeByte_GB(0x555 << 1, 0x80);
  writeByte_GB(0x555 << 1, 0xaa);
  writeByte_GB(0x2aa << 1, 0x55);
  writeByte_GB(0x555 << 1, 0x10);

Then check if it gets erased now.
No change, and the erase happens very quick, which to me suggests nothing is actually happening. I emailed BennVenn to see if he had any thoughts and he stated that the standard WE pin on the cart edge is for bank control and whatnot, but any flash commands to be issued are using the Audio pin. To me it seemed the code that had the PH5 portions were only about issuing the flash commands, but is that not the case (ie does changing from the WR pin to the Audio pin in those sections also change what pin is used for bank control)?

Edit: He also suggested that using both pins at the same time wouldn't upset the IC and thus might be an option, if bank control and the write commands are tied to the same pin in your code

sanni

That makes sense, in this case in setup_GB leave WR(PH5) as is and add WE(PH4):

Quote
// Set Control Pins to Output CS(PH3) WE(PH4) WR(PH5) RD(PH6)
  DDRH |= (1 << 3) | (1 << 4) | (1 << 5) | (1 << 6);
  // Output a high signal on all pins, pins are active low therefore everything is disabled now
  PORTH |= (1 << 3) | (1 << 4) | (1 << 5) | (1 << 6);
In writeByte_GB toggle both WE(PH4) and WR(PH5)
Quote
void writeByte_GB(int myAddress, uint8_t myData) {
  PORTF = myAddress & 0xFF;
  PORTK = (myAddress >> 8 ) & 0xFF;
  PORTC = myData;

  // Arduino running at 16Mhz -> one nop = 62.5ns
  // Wait till output is stable
  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");

  // Pull WE(PH4) WR(PH5) low
  PORTH &= ~((1 << 4) | (1 << 5));

  // Leave WE/WR low for at least 60ns
  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");

  // Pull WE(PH4) WR(PH5) HIGH
  PORTH |= (1 << 4) | (1 << 5);

  // Leave WE/WR high for at least 50ns
  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");
}

makho

Hey sanni,

I've been working on a project based off of your reader for a few weeks now and I'm struggling to get it working. The end goal is to use a dedicated ATMEGA2560 with all accompanying hardware such as the power regulators, battery, screen, switches, etc and just have some edge connectors to hook up to the cart reader modules such as Game Boy, N64, etc. I just made my first prototype using the embed version of the Arduino Mega 2560 and I can't get it to read any Game Boy games. GB/C games are partially recognized but the title is wrong and I am unable to get a clean dump. ROM dumps are invalid and do not boot in an emulator and the checksum fails when dumping. GBA games just report cartridge error. All the other hardware seems to work just fine, including power management, voltage switching, charging, screen, buttons, SD reader, etc. I used the spreadsheet with the pinouts to make the schematic for this.

At this point, I think it's just a silly mistake but I still cannot find the error. I know it's not the SD card or the carts themselves because my other, unmodifed reader can handle both with no issues. If I post the schematic or board files, can you help out?

Thanks


sanni

Seemingly random errors like this are often caused by either dirty/corroded cartridge pins, a bad solder joint, a shorted address or data line, too tight timings or a bug in the code.
So there might either be a hardware problem with your PCB or you encountered a bug in the code that only gets triggered in edge cases and your PCB made this bug more "visible".

Hardware:
So first I would make sure the cartridge's contacts look like new and if not clean them.
Then I would check with a multimeter that none of the GB slot pins are shorted to GND which can happen if the solder mask got misaligned in the factory by a tiny bit.
Then I would check that none of the GB slot pins are shorted to another GB slot pin.
Then I would measure the resistance of the power switch, I had slide switches with several Ohms resistance in the past that produced a similar error, although only with the 3.3V systems.
And finally, I would use a multimeter to measure each address/data pin's resistance from the Arduino to the GB slot to check for a cold solder joint. I had several of those in the past, they look like a good joint but if you measure the resistance it's higher than on the other lines.

Code:
In the code I would try if enabling/disabling the internal pullups for the data line in setup_GB() and in dataIn_GB() makes any difference.
Then in readByte_GB() I would double the amount of "nop\n\t" to slow down the code. And I would also check if switching  CS(PH3) and RD(PH6) high/low one at the time instead of at the same time does make any difference.

skaman

Interesting.  I have a possibly related issue with the Embed board.  My portable GB cart reader that uses the Embed board refuses to bankswitch the GB Memory carts.  All normal GB/C carts work perfectly.  I never looked hard into finding the problem.  Could be timing issues or possibly the lines need resistors.

makho

I wonder if there is just something about the embed boards in particular then. On my PCB, I am using external 5v and 3.3v regulators and using those to power the VCC rail which feeds the cart slot, arduino, and other peripherals. The only peripheral that does not run off the VCC rail is the memory card reader and that always gets 5v (or both 5v and 3.3v in the case of the full size SD slot). I made no modifications to the arduino module itself. Here is the schematic for the GB cart slot:



I double checked all of my solder joints and there are no shorts to ground or other pins or cold joints on either the cart slot or arduino, I visually inspected the cart reader pins and even though they checked out, I cleaned them anyway, and I checked the resistance of the power switch and it reads even lower than my full size reader (which checks out, it's a brand new switch from the same batch as my full size reader). Additionally, I tried modifying the code as suggested, but none of the suggestions appeared to make any difference.

So, that being said, I think I've narrowed down the issue to either a PCB quirk or design error or the arduino itself (but I'm leaning towards a PICNIC error). I've already drawn up a new revision of the PCB and fixed several issues that I had to correct by hand and I've reversed the orientation of the arduino so that the data lines to the cart slot are significantly shorter and no longer have to take the scenic route around the board and I already have another arduino on the way. Think I should go ahead and order the new boards? It's $10 USD for 10 of them.



Thank you, I appreciate your time.


Nonekiller001

#776
Apr 04, 2019, 09:39 pm Last Edit: Apr 04, 2019, 09:43 pm by Nonekiller001
Just ordered all my parts for a batch of my own. 8)  Hope to use this with my mister fpga.

Was developing my own cart reader but i decided not to reinvent the wheel. Plan on adding a addonboard for other carts too such as atari, colecovision, and Intellivision.

CZauX

hey Sanni, I see you're using an Arduino Mega for this which has 16 analog pins, but in the code are you using them digitally? Is this any different than the other non-analog digital pins? So a normal arduino Uno could be rigged to do backups for N64 cartridges?

sanni

If you look at the first post of this topic you'll see that the project started out on an Arduino Uno. So sure it's possible. And yes, all analog pins are used as digital input/output.

It just depends on how much your time is worth to yourself. The Arduino Uno does not have enough pins so you will need to add shift registers and do major changes to the current code.
Compare that to just buying an $8 Arduino Mega and I think you have your answer.


makho

Thanks for the help, Sanni.

I haven't reviewed the code, so I'm not sure exactly what changed, but with the 3.0 software, my cart reader seems to be working as expected. It still needs a few hardware tweaks, but this was just a proof of concept prototype anyway. I've already got the new revision in the mail anyway.


Go Up