Go Down

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

darleiv

i installed a nvram on my mario world and sani can't add save smw 96% world - which sketch area would have to change to record NVSRAM :o

sanni

You have to edit the SNES Sram functions starting here: https://github.com/sanni/cartreader/blob/master/Cart_Reader/SNES.ino#L1278

Most likely nvram is slower than sram and you need to slow the writing down a little bit.

segmaster01

Hey Sanni! First time posting after using my reader for 2+ years with no issues at all-- I really appreciate your hard work on this project. It makes ordering games from eBay so much more fun.

I just recently acquired a collection of GB/GBA games and have never used the GB functionality of my reader before. I purchased the reader preassembled from a seller on Etsy and he guaranteed all the functions would work, which (as far as I was able to test) they did.

Unfortunately, I seem to be unable to dump GBA games properly. The reader sees the cartridges and even computes the checksum "correctly" but the resulting file is always corrupt. Looking at the files in a hex editor reveals that the first 1/8 of the file matches perfectly, but after a certain point there are big blocks of incorrect data and also blocks of just zeroes.

I tried dumping the same cartridge repeatedly and the resulting file was different each time -- the errors were in different places after each dump. Perhaps a bad connection?

I'm using a dedicated 5v/2A power supply, and am also running the latest firmware. SNES, N64, and Genesis cartridge dumping works perfectly. Even carts with SFX and SA1 chips work great too.

Any advice you can offer would be super helpful and appreciated. Thanks in advance!

sanni

You can test if it's the Cart Reader hardware by dumping a classic Game Boy game. If that works and only GBA doesn't then it's most likely a bug in my GBA code. The GBA code is the least tested code with the most bugs right now.

segmaster01

#1234
Jun 12, 2020, 02:12 am Last Edit: Jun 12, 2020, 02:12 am by segmaster01
I tested dumping both a GB and GBC game, both would not work. This time, however, the cart reader detected a bad checksum instead of "pretending" it worked, like with GBA. Repeated dumps resulted in different checksums each time.

What should I start looking at first to try and fix this issue? I have cleaned the contacts of the cart slot with alcohol already, with no change.

Thanks again for your help!

sanni

Can you make a picture of the solder connections of the GBA slot?
Also if you open the bad dumps in a hex editor, does the random data always start at the same offset?

hkcisonline_fr

Hello Sanni Community :)

I just acquired an old Sanni reader from 2017 with the "old" PCB with only the SNES/N64 slots it works great, it's really an impressive kit (HW version V11B from 23/8/2017) !

I was able to read about all my SNES cart with Success, but I have a problem trying to read my 2 NPower SF Memory card (SVHC-MMSA-JPN-1), each time i try to read i have the same msg :

"Hirom All Timeout
Powercycle SFM Cart
Press Button..."

while i spent some time reading the Wiki and some forum it is said that to allow reading of that kind of cart i need an Adafruit clock generator, it seems i don't have it, so... can i add this part to the old PCB or is there a way to run a different version of NP program that do not required the clock generator and where to find this old version of NP ?

thx in advance and This Sanni Reader is really wonderful !!!

sanni

This older Arduino program can read/write the flash of NP carts without the clock generator: https://github.com/sanni/cartreader/tree/ffc3e77dd4faf15612fc7435e824d1076fd145b6/extras/npwriter

But you can also just buy the Adafruit clock generator from eBay or Aliexpress and plug it into your Cart Reader. Step 3 in this old build guide shows the 1x7 female pin header the clock generator plugs into, just above the 4 switches. https://github.com/sanni/cartreader/wiki/PCB-Build-guide

jamiec

I had a quick question. I have been trying to dump a prototype DMG-MBC5-32M-R-FLASH, has anyone been successful using the Sanni Cart Reader? I always get Checksum Failure when reading this cart. It plays fine but I just cannot dump it.

I haven't had any issues with other ROMs I have dumped and I am able to Read and Write NP Power etc.

Thanks

hkcisonline_fr

#1239
Jun 17, 2020, 10:21 pm Last Edit: Jun 17, 2020, 11:21 pm by hkcisonline_fr
This older Arduino program can read/write the flash of NP carts without the clock generator: https://github.com/sanni/cartreader/tree/ffc3e77dd4faf15612fc7435e824d1076fd145b6/extras/npwriter
Thank you very much for your response and the link to npwriter, i'll test it ASAP.

OK test done, i'm new to Arduino but google is my friend :) so it worked perfectly that's great :)

But unfortunatly i was not able to get the npslit tool to export the menu from the 4MB binary, as it said 404 every time i try https://github.com/sanni/cartreader/tree/master/extras/npsplit :(

sanni

I just cannot dump it.
Does it write anything to the SD cart? Might be just that the checksum is missing because it's a prototype.

npslit tool to export the menu from the 4MB binary
https://github.com/sanni/cartreader/tree/ffc3e77dd4faf15612fc7435e824d1076fd145b6/extras/npsplit

jamiec

Does it write anything to the SD cart? Might be just that the checksum is missing because it's a prototype.

I have checked the SD and it does write to the card, when I compare multiple attempts with a HEX editor there is numerous bytes that are different. I would say about 95% are always the same and then some differ.

sanni

Then you probably have to play around with the source code in GB.ino to make the Cart Reader compatible with this dev cartridge.

There is a schematic of the cart and also a link to the flash's datasheet here: http://hentenaar.com/gb-dev-cart





First idea:
If this schematic is correct then the SRAM is connected directly to the cart edge without being controlled by the MBC5-D like you would suspect in a standard MBC5 cartridge.
So that is most likely your problem. The cart reader tries to read data from both the flash and the SRAM at the same time resulting in errors. You need to deactivate the SRAM by not pulling the CE/CS pin low during the read operation by changing the readByte_GB function in GB.ino like so:

Code: [Select]

byte readByte_GB(word myAddress) {
  PORTF = myAddress & 0xFF;
  PORTK = (myAddress >> 8) & 0xFF;

  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");

  // Switch RD(PH6) to LOW
  PORTH &= ~(1 << 6);

  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");

  // Read
  byte tempByte = PINC;

  // Switch and RD(PH6) to HIGH
  PORTH |= (1 << 6);

  __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t");

  return tempByte;
}



Second idea: It could be because of the reset pin.

From the datasheet:
Quote
3.1 Read
Information can be read from any block, identifier codes, query structure, or status register independent of the VPP voltage. RP# must be at VIH.
The first task is to write the appropriate read mode command (Read Array, Read Identifier Codes, Query or Read Status Register) to the CUI. Upon initial device power-up or after exit from deep power-down mode, the device automatically resets to read array mode.

Five control pins dictate the data flow in and out of the component: BE# (BE0#, BE1L#, BE1H#), OE#, WE#, RP# and WP#. BE0#, BE1L#, BE1H# and OE# must be driven active to obtain data at the outputs. BE0#, BE1L#, BE1H# is the device selection control, and when active enables the selected memory device. OE# is the data output (DQ0-DQ15) control and when active drives the selected memory data onto the I/O bus. WE# and RP# must be at VIH.
Figure 18, 19 illustrates a read cycle.
In the current GB.ino code the reset pin, which in the dev cart is connected to RP#, is not actively driven so you need to change the setup_GB() function so that the reset pin is actively driven high like so:

Code: [Select]

/******************************************
   Setup
 *****************************************/
void setup_GB() {
  // Set Address Pins to Output
  //A0-A7
  DDRF = 0xFF;
  //A8-A15
  DDRK = 0xFF;

  // Set Control Pins to Output RST(PH0) CS(PH3) WR(PH5) RD(PH6)
  DDRH |= (1 << 0) | (1 << 3) | (1 << 5) | (1 << 6);
  // Output a high signal on all pins, pins are active low therefore everything is disabled now
  PORTH |= (1 << 0) | (1 << 3) | (1 << 5) | (1 << 6);

  // Set Data Pins (D0-D7) to Input
  DDRC = 0x00;
  // Disable Internal Pullups
  //PORTC = 0x00;

  delay(400);

  // Print start page
  getCartInfo_GB();
  showCartInfo_GB();
}


Third idea: The flash chip has two banks controlled by the MBC5-D, if you're lucky the MBC5-D switches the flash's banks automatically, but it could also require a special command to switch the banks. You probably would need to hook-up a logic analyzer to find out if that is the case.

jamiec

Thank you very much for such a detailed reply.
I will give all that a try in the next hour and let you know how I get on. The cartridge I have looks the same as the website with the yellow housing.

Ill write back soon to let you know how I got on.

Thank you!

jamiec

First idea:
If this schematic is correct then the SRAM is connected directly to the cart edge without being controlled by the MBC5 like you would suspect in a standard MBC5 cartridge.
So that is most likely your problem. The cart reader tries to read data from both the flash and the SRAM at the same time resulting in errors. You need to deactivate the SRAM by not pulling the CE/CS pin low during the read operation by changing the readByte_GB function in GB.ino like so:

That was spot on! I was able to dump the game first time after implementing the code to deactivate the SRAM.
The checksum matches and the game runs fine on the emulator.

It had a rom of Ballistic on it, sadly it is actually identical to the Retail rom in every byte so its not a prototype but an actually retail rom.

Thank you very much for your help! I really love the work you have put into this, It has become my go to for any rom work.

Go Up