sanni / cartreader Goto Github PK

This is not really a bug specific to this project, but which should be worked around to prevent some head-scratching.

The Arduino bootloader used in the chip targeted by this project has a bug which causes it to never erase the last flash page. As a result, all writes to that last page can only ever clear bits, never set them. In practice, this means that out of the intended maximum usable flash space of 248kiB, 8kiB are usable only once, and then will forever cause verification failure (and incorrect operation) when the programmed image is larger than 240kiB.

I see a few possible workarounds:

• fix the bootloader. This is hardly within the scope of this project. There is an outstanding merge request on the corresponding Arduino repository since 2020 addressing this bug. Visibly, the submitter did not sign the contributor agreement, leaving us to deal with this bug.
• get the Arduino build environment to deduce 8kiB from the usable flash space. From what I can see, the Arduino build environment is extremely rigid (no real way to set compiler options, so I do not expect a way to tweak a chip model's linker mapping), so this seems unlikely to lead anywhere.
• add 8kiB of bloat at a fixed address in the resulting image. I think this must be possible in a few inline assembly lines, but so far I am failing to get gcc to comply. The idea would be to fill that bloat with 0xff bytes, so avrdude would ignore them (it looks like it has a feature which never even sends trailing 0xffff words to the chip, so this would take no extra programming time). This way, if the firmware crosses that boundary, the build will fail rather than produce an image that cannot be reliably used.

Maybe someone on this project has the know-how to implement a working solution ?

I'm having an issue dumping the SA1 chip game PGA Tour 96 for the SNES. I'm using a HW5 Rev3 cart reader with V12.3 firmware and I can dump Super Mario RPG, Kirby Super Star, and Kirby's Dream Land 3 without any issues. When I try to dump PGA Tour 96 it gives me this error:

ERROR
Rom header corrupt
or missing

Press button for
manual configuration
or powercycle if SA1

I get the same error with two different PGA Tour 96 cartridges, both of which play fine on an SNES. One of the cartridge PCB's is SHVC-1L3B-01 and the other is SHVC-1L3B-02.

Hello, trying to dump the NES cartridge Impossible Mission II though the Sanni does not detect the cartridge. Manually selecting the cartridge results in a 64KB dump where it should be 128K. Cartridge edge connector is clean and the cartridge has no damage. Successfully dump other NES cartridges. Any advice welcome, thank you for your time.

The PCB version is NINA-002 REV. A, identical to:
https://nescartdb.com/profile/view/1241/impossible-mission-ii

Log as follows.

OSCR HW5 V12.4

[+] NES/Famicom


Searching database
for 21BF845C or 64B86EED...

CRC not found in database
Using manual selection

Select Mapping from List

NES CART READER

CURRENT SETTINGS

MAPPER:   34
PRG SIZE: 64K
CHR SIZE: 64K
RAM SIZE: 0K

Press Button...

[+] Read iNES Rom


Saving to NES/ROM/ImpossibleMissi/6/...
[*******************]
CRC32... 0142560B -> Not found

Press Button...

Originally posted by @N30Avalon in #769

Well I have this bad identification of Super Mario RPG, it should be Lowrom. Dump works but CRC fails and I can't read rom file in an emulator.
I use HWrev 5 and tried 2 diferent boards of SNES Cic and 2 different clock generators, one working perfectly on HW rev3

Hey there. I recently got my hands on the Open Source Cartridge Reader. I put Kirby Tilt 'n' Tumble into the Game Boy slot, and I was able to dump the ROM. But, when I attempted to backup the save file, I get an error message.

Cart has no Sram

Press Button...

Any chance this issue can be fixed? I really need to backup my save file. As far to my knowledge, this is one of the few Game Boy (Color) games to not use battery-backed SRAM for saving, and instead utilizing EEPROM. And this is one of two Game Boy Color games to have a tilt sensor. The other game that has it is Enix's Command Master.

Trust me, I followed the guide on the PCB. Made sure the voltage switch was in 5V, and the EEP, CLK0, and CLK1 switches are off. Do I also need to turn the EEP switch on, since the cart used EEPROM?

Cheat devices, Xplorer64 (Xploder64) not read.

Hello,
I have a problem with downloading .stl files form "Adding an enclosure" section. Same problem have with files in section "3d printed case files". Most cases there is no "download" button. Can You please fix this or ?
Thank You for Your time.
Lucas

I am trying to clear all build warnings, and for this one I have no idea how to resolve it.

The function's general structure is:

void flashRepro_N64() {
  unsigned long sectorSize;
  byte bufferSize;

  if (cartSize != 0) {
    // does not initialise sectorSize and bufferSize
  } else {
    // initialises sectorSize and bufferSize by user input
  }
  // this part uses sectorSize and bufferSize
}

So it looks like they are only initialised in the exceptional case (unknown flashcart ?). I suspect this is a "true" bug, but I have no such cart so I cannot check.

Is this where I should report missing titles? Apologies if not.
CRC32 23a9616d is Flashback: Quest for Identity, US version, but comes up as not found.
Also listed here: https://segaretro.org/List_of_Mega_Drive_ROM_dumps

Hey, the 5mm_standoff.stl is the only file without download button. I find out how to download, but PrusaSlicer can´t open the file. Can you please fix the file?

thanks

Discussed in #399

In six slot adapter, snes slot pin 25 connects to D40, but in HW4 or HW3 it connects to CIC_RESET.
After rewiring pin 25 back to CIC_RESET, I can dump SA1 games with HW5 flawlessly.
Is there any reason that pin 25 connects to D40?

Latest merges in NES.ino brought a little issue (got it with hw3 and today's version) :

• go into NES module
• the game autodetection starts
• a game is found, mapper settings are set
• I don't want these settings, so go to Changer Mapper
• set new values for PRG, CHR, RAM
• and at this point autodection is launched again. The game is found again. Manual settings are overwritten etc.

This comes from checkStatus_NES(), calling getMapping();

currently on version 9.4, it will auto name your dumps and then if you try to flash them it cant display the file as the name has characters that it can't print or are too long(idk the issue) manually renaming the file fixes the issue.

To reproduce dump pokemon blue, then try to write it to a flashcart and it doesn't exist as an option until you manually rename the file.

Is there any reason not to have 32x checksums in either md.txt or a dedicated 32x.txt? I tested dumping Star Wars Arcade and it passed internal checksum but not CRC as expected. I can submit a PR if we are ok to add it

After updating the cart reader from 9.1 to 9.4 I noticed that when trying to pull games it keeps giving a clockgen not installed/found error. Upon looking it seems in 9.1 the following was defined:
#if (defined(HW2) || defined(HW3))
#define enable_OLED
#define enable_Button2
//#define clockgen_installed
//#define fastcrc
#endif

But in 9.4 it changed to:
#if (defined(HW2) || defined(HW3))
#define enable_OLED
#define enable_Button2
#define clockgen_installed
//#define fastcrc
#endif

Which I suspect is triggering the error. Commenting clockgen_installed out and uploading again does fix the error.

Hi,

I am having an issue flashing to a Nintendo Power Gameboy memory Cartridge.

I purchased the cartridge with only one large ROM file so I had to start from scratch. I am trying to load Pokemon Blue alone w/o the menu but when I try and flash the ROM or MAP files, the Cart reader reboots.

When I "Erase Flash" I get the warning message and press to confirm, the next page shows Erasing... but no "OK" and then asks to press the button.

Next, I Blankcheck which immediately says "Blankcheck...OK" and asks to press the button to continue..

Pressing Read Flash and Read Mapping, generate corresponding files in the NP folder of the SD card.

Please help me, literally purchased this cart and built your reader for each other.

Thanks!

Daniel G.

There are reports of contact issues with some (early?) NES PCB versions that have shorter contact pins, and I can confirm this myself.

bad contact "no data found" when fully inserted:

same game, different (newer?) PCB, good dump:

It seems like the 72-pin slot isn't deep enough to allow proper contact with these shorter pins.
I'm trying to find a different slot than the one recommended on the wiki, but they all look the same and rarely specify their exact dimensions.

Meanwhile you can force the pins to make contact but I don't like pushing/yanking the PCB in the slot and the results are random.

Discussed in #691

Both the automatic mapper setup using the iNES header from nes.txt and the manual mapper setup don't allow a PRG size smaller than 16K and therefore the OSCR doesn't dump games with 8K PRG like Galaxian correctly.

The resulting ROM looks like this: iNES header - 8K PRG - 8K PRG(mirror) - 8K CHR

Hello,
I have just build Card Reader Version 3 few minutes ago. I have problem with screen that displays on OLED. It looks like not all horizontal lines are drawn. The bottom of the screen is not affected. Everything is fine there. I have shown it in the photo. I resoldered the connections from both sides of the OLED PCB again, but it didn't change anything. Is the screen damaged and needs to be replaced? Please help.

From SNES.ino:

  uint16_t c = 0;
  uint16_t currByte = 0;
  byte buffer[1024] = { 0 };
  PORTL = 192;
  while (c < 1024) {
    PORTF = (currByte & 0xFF);
    PORTK = ((currByte >> 8) & 0xFF);
    // a few NOPs
    buffer[c] = PINC;
    c++;
    currByte++;
  }

buffer is never used outside of this loop. The first easy cleanup step is to drop it, but this loop has side effects: it writes to ports F and K. Are these writes expected to have any effect on the gamecart state ? Otherwise I can just drop this entire loop.

I tried playing the NES games on my emulator, and it doesn't work. Yes, I did add the emulation header and cleaned the cartridges/72-pin connector port. Yet it just results in a grey screen in all games I've tested. I've tried a ROM from the internet, and that worked fine, so its not a problem with the emulator. Do you guys know of a solution?

Hi Sanni,

I think I might have just discovered an issue with the six-slot PCB Rev. 3.

I have been trying, w/o success, for the past week to get Mega Drive/Genesis Carts to read but the moment I plug one in and try to turn the reader on, it just stays off. I disconnect the game and try again and the reader powers on like usual. If the reader is powered on and I try to connect the game, it just shorts out and turns off.

I had a bit of free time and decided to see if I could find a short on my PCB but did not find a defect from my soldering. Well after a few hours of testing/probing for shorts and looking over your schematics/ Sega PCBs I physically have, I noticed that D40 which has continuity to VCC goes connected to the /cart pin of the genesis port which on all of my games is actually a ground pin.

I confirmed the result by applying a piece of tape to the /cart pin to avoid getting VCC to the pin as it shares ground on the game itself and the reader stays on as well as successfully pulls the ROM and passes the checksum.

Can you confirm if this is a one-off or a design issue?

Wiki What To Buy page says N64 slot should be 2.5mm pitch, warns about sellers sending 2.54mm pitch, links to a 2.5mm pitch item.

Revision on 6 slot board 2 months ago states N64 slot changed from 2.5 to 2.54mm?

Which pitch do we need?

Is the individual N64 slot board same pitch as the 6 slot board?

Thanks, Steve

When using the flashrom PCB adapter with a 29L3211 inside, plugged into the SNES port, I've got no result.
Blanckcheck, reading, etc takes 0sec and dumped files are blank.
When the first operation is complete, and after "Press Button..." prompt, I've got a
"MenuError
Mode = 255
Press BUtton..."
Then to the tiel screen.

Did someone managed to flash a flashchip with 12.4 HW5 ?

Thanks !

this is my first project like this and i thought everything was going fine i was able to dump some GB carts and SNES carts

but the moment i try and turn it on with the switch set to 3v the screen either looks glitchy or nothing at all

5V

3v

Hi!

I was dumping several hucard with a custom adapter and noticed the name of files doubled the extension, as you can see below:

I suppose it is a easy fix into the code.

I recently purchased all the items on the list, assembled my cart reader, and realized those long male pin headers are actually too long?

Male pin headers:
two 1x40 2.54mm 20mm long(total length) 

The PCB can't sit flush with the 18mm spacers, because male pin headers + female pin header combined are 18.5mm. I triple checked, I did order according to the list, my male pin headers are indeed 20mm long.

At that point, I would advise either to change the list to 19mm long spacers, or 19mm long male pin headers :)

Some NES carts (aftermarket, pirate, multicart, etc.) cannot be dumped because the mapper number isn't supported.
I tried adding mapper 268 manually but it did not work, I don't understand the inner-workings enough.
Is there a way to implement all the missing headers? Or at least making it possible to add mapper numbers >255?
Reference: https://www.nesdev.org/wiki/Mapper#Plane_1

I am unable to read the Limited Run Games SCAT NES cart. It seems to read fine at first (finds the entry in the database), but then gives an error on the CRC check at the end. The file created is not usable. Using HW V3 and Firmware beta V12.0 (I also tried 10.2). I am guessing the fact that this is not an actual mapper 1 board but an FPGA simulation of one is the issue. I am not sure if this is a bug or a feature request. Just FYI.

SCATSpecialC.txt

Every time I try to dump a Master System cart I get a different CRC value which is not found. I have the HW5 R3 board with the Rev1 Six Slot Board. The one cart I tried to dump was Mono Poly which is in the database on the SD card but the CRC value is different every time I dump. When I open what is dumped it does have some plaintext that is definitely from the game.

I select SMS and then the first option and click to read rom but each dump yields a different CRC value.

I have no issues dumping SNES games including SA1 games and as far as I can tell the solder joints look good so I'm not quite sure what is wrong.

Also the WIKI NEEDS to be updated with instructions for using the HW5 boards since there are a number of differences between HW3 and HW5.

Example:

Bonkers - Hollywood Daisakusen! (Japan).sfc
9401D956,0321,08,032

Marvel Super Heroes - War of the Gems (Japan) (Beta).sfc
4EC91D9C,0321,32,064

Super Street Fighter II - The New Challengers (Japan).sfc
26CA246B,0321,32,064

I inserted "Super Street Fighter II - The New Challengers (Japan)" cart but based on checkAltConf function logic,
it matches "Bonkers - Hollywood Daisakusen! (Japan)" first and shows game with 8 Mbits size which is incorrect.

In v11.4, when a dump doesn't get a match in nes.txt, the header applied to CART.nes is wrong (hex stored as text):

SNES carts (Original, Repro, and SF Memory) will refuse to read correctly on software v8.0 and higher when configured for V3 hardware (with snescic + clockgen enabled.) Issue is present regardless if clockgen is enabled or disabled when compiling.

Pin PC7 (SNES pin D7) is pulled high when attempting to read cartridges and results in an invalid CRC (CB9E instead of 4B9E for Mario Paint.) Repro carts will fail to detect at all and prompt for manual settings input, and SF Memory carts will fail with a "Hirom All Timeout" error.

Last working software version that did not have this issue was v7.3
Cartridges Tested: Mario Paint (US), Mario All Stars + Mario World (US, Repro), SF Memory

Note: I am completely new to arduino in general, so I may be missing something.

I cannot get the latest source (as of 9d80d24) to fit with all modules enabled. On its own this may not be a big issue (I guess this is why they are optional and selectable to begin with). The linker complains that the code is 2444 bytes too large.

Then I took a look at the produced binary (after disabling the NES module just to have a file to analyse) to check what is going on. And here is an extract of what I found:

$ strings Cart_Reader.ino.bin | sort | uniq -c | sort -nr | head -n30
     70 Press Button...
     44 SD Error
     36 Reset
     30 did not verify.
     28 m/|/
     28  bytes
     27 Error:
     27 A,Q,2
     26 /...
     23 (_?O
     22 /)/3'
     21 Saving to
     21 Can't create file on SD
     18 Can't open file on SD
     18 Can't open file
     17 File size exceeds flash size.
     17 Done
     16 Press left to Change
     16 and right to Select
     15 ROM Size:
     13 Verifying...
     13 Saved to
     12 Flashing file
     11 Verified OK
     11 Read ROM
     11 /_?O
     11 Erasing...
     10 ATTENTION 3.3V
      9 Writing...
      9 This will erase your

The first obvious finding is that -fmerge-constants (which is supposed to be enabled in -Os, which is used in the build) is somehow doing a terrible job. I tried editing my platform.txt to explicitly add -fmerge-constants, without any improvement.

So, how much space is used by these ? Ignoring the few strings above which are likely accidental finds by strings and not "true" strings, I get:

>>> 70 * len("Press Button... ") + 44 * len("SD Error ") + 36 * len("Reset ") + 30 * len("did not verify. ") + 28 * len(" bytes ") + 27 * len("Error: ") + 26 * len("/... ") + 21 * len("Saving to ") + 21 * len("Can't create file on SD ") + 18 * len("Can't open file on SD ") + 18 * len("Can't open file ") + 17 * len("File size exceeds flash size. ") + 17 * len("Done ") + 16 * len("Press left to Change ") + 16 * len("and right to Select ") + 15 * len("ROM Size: ") + 13 * len("Verifying... ") + 13 * len("Saved to ") + 12 * len("Flashing file ") + 11 * len("Verified OK ") + 11 * len("Read ROM ") + 11 * len("Erasing... ") + 10 * len("ATTENTION 3.3V ") +  9 * len("Writing... ") +  9 * len("This will erase your ")
6770

Of course, one copy of each strings would still be necessary, and this ignores the (low ?) probability that some of these would actually be non-constant but actually local variable initial values, so the final gain would not be strictly this much. Still, this is 3 times larger than the extra space needed to fit all modules in the available program space. Also, it obviously ignores any possible duplication from the NES module.

I do not have a magic solution. The best idea I can come up with is terrible: put all constant (including inline) strings in some header file and reference them everywhere. But at least this should not leave gcc the chance to mess things up. This will not help if these duplicate strings come from libraries, but the strings visible above seem to be rather specific to this project, so the losses from libraries seems likely to be low.

NES game detection is broken in v11.3

working fine in v10.2 (release zip)

broken in v11.3 (present version at commit 8dcb841)

edit: I updated the files on SD card too

Admittedly, this may be beyond the scope of this project but figured it might be something that someone may have stumbled upon and knows how to fix. I've put together a Sanni v5 hw3 and after it was together, the backlight on the display didn't work Everything else worked great, including dumping data. Swapping the arduino with a new one resolved the issue. Do you know what I may have done wrong or what to check on the arduino?

I'm having issues with getting the STL files for the frame and N64 sleeve printed. I ordered my PCBs from JLCPCB and also tried to order the 3D prints from them as well.

Here's what they said about...

frame.stl
Automated: https://prnt.sc/Ea2gph5ZHrud
Human reviewed: https://prnt.sc/nEG_2CumNznb

n64sleeve.stl
Automated: https://prnt.sc/C4l1jcY--la5
Human reviewed: https://prnt.sc/0hOJn1jjVEEA

I'm not sure if I'm doing something wrong as I'm not super familiar with 3D printing so I apologize in advance if this is some sort of user error. Also, since I'm posting anyway, what's the recommended material/method for these?

When too many modules are enabled you can experience the following issues:

• blank screen on boot
• a screen just saying "Press Button" instead of displaying the menu
• when dumping Mega Drive or N64 the screen gets scrambled at the end of the dump process.
• CRC32 calculation for N64 failing

This can be fixed by disabling modules you don't need to save a little bit of SRAM.

Don't know much about NES in general, but I had a thought: AFAIK, dumping NES is difficult because it requires knowing PRG/CHR size beforehand. Hence the need for manually sourcing and inputting these values from places like http://nes.dnsabr.com. Cart dumper automates this by storing a database of hashes of globally known seekable sections of the PRG ROM. However, this does not always work because there can be conflicts when these sections are identical between different games.

My mind immediately jumps to a b-tree index type strategy: Progressively scan and hash the PRG and CHR ROMs using the current match set to increase the seekable area and narrow down possibilities.

Let's pretend we have a database of the entire NES library which contains hashes for the first n bytes of each PRG ROM:

Now we are dumping a cart. We know the minimum size is 16k so it is safe to read and hash the first 16k. Doing so produces a3b3e36e. This matches Zelda, Contra, Kirby, and Tetris. Of the 4, the smallest size is 128k, so we continue reading and hashing to 128k. Now we produce 2864f7cc which matches Kirby and Tetris. Both games are 512k, so we continue reading and hashing to 512k and produce d2dce641 which matches Tetris.

Theoretically this would resolve all ambiguity except for (very rare) cases in which both the PRG ROM and CHR ROM begin with the entirety of another PRG ROM and CHR ROM.

The database could be minimized drastically to only hashes required to resolve conflicts. For example, there is no reason to store the 128k and 512k hashes for Gradius because its 16k hash is unique. Same with the 128k hashes for Frogger and PacMan as they provide no disambiguation. In fact, rather than storing a flat lookup table, you could store an index-tree-like structure instead that contained disambiguation instructions:

Read 16k
├ 9f115a9e: Mario
├ a3b3e36e: Read 128k
│ ├ 53b88a7a: Zelda
│ ├ b0c8c11e: Contra
│ └ 2864f7cc: Read 512k
│   ├ 4f3ad289: Kirby
│   └ d2dce641: Tetris
├ dd611655: Gradius
└ 4bf93c55: Read 512k
  ├ 12c70afd: Frogger
  └ 8c7869e6: PacMan

I tested this theory on a headerless no-intro ROM set using NES2.0 DB. It was able to index and distinguish all but 21 of the 3,560 ROMs. The Virtual Console and cassette dumps can be excluded which brings the number down to 9, only 3 of which are "standard" games:

9FFE2F55 PRG:65536 CHR:131072
  ├─ 9FFE2F55 Sky Shark (USA) - PRG:65536 CHR:131072
  └─ 4AF742FA Sky Shark (USA) (Rev 1) - PRG:131072 CHR:131072
 E41220D8 PRG:262144 CHR:0
  ├─ E41220D8 Assimilate (USA) (RetroUSB) (Aftermarket) (Homebrew) - PRG:262144 CHR:0
  └─ 7145F667 Assimilate (USA) (RetroUSB) (Aftermarket) (Homebrew) (Alt) - PRG:524288 CHR:0
 CD8233EF PRG:16384 CHR:8192
  ├─ 2F55BE88 Lunar Ball (Japan) - PRG:16384 CHR:8192
  ├─ 80CBCACB Golden Game 100-in-1 (Asia) (En) (Pirate) - PRG:1048576 CHR:0
  ├─ 6175B9A0 Golden Game 150-in-1 (Asia) (En) (Pirate) - PRG:2097152 CHR:0
  ├─ 46A1AE7B Golden Game 210-in-1 (Asia) (En) (Pirate) - PRG:2097152 CHR:0
  └─ 4E5668A9 Golden Game 260-in-1 (Asia) (En) (Pirate) - PRG:3145728 CHR:0
  
20F98977 PRG:16384 CHR:16384
  ├─ 20F98977 City Connection (Japan) - PRG:16384 CHR:16384
  └─ D20775DA City Connection (Japan) (Virtual Console, Switch Online) - PRG:32768 CHR:16384
0F05FF0A PRG:32768 CHR:8192
  ├─ 0F05FF0A Seicross (Japan) (Rev 1) - PRG:32768 CHR:8192
  └─ 3413E33B Seicross (Japan) (Virtual Console) - PRG:32768 CHR:16384
E37A39AB PRG:131072 CHR:65536
  ├─ E37A39AB Yoshi's Cookie (Europe) - PRG:131072 CHR:65536
  └─ CAA76927 Yoshi's Cookie (Europe) (Virtual Console) - PRG:131072 CHR:131072
A2623BC1 PRG:131072 CHR:131072
  ├─ A2623BC1 Nantettatte!! Baseball (Japan) - PRG:131072 CHR:131072
  ├─ 6C039D11 Nantettatte!! Baseball + Nantettatte!! Baseball - Ko-Game Cassette - '91 Kaimaku Hen (Japan) - PRG:147456 CHR:131072
  └─ A5275B36 Nantettatte!! Baseball + Nantettatte!! Baseball - Ko-Game Cassette - OB All Star Hen (Japan) - PRG:147456 CHR:131072
ADFAD6B6 PRG:131072 CHR:0
  ├─ ADFAD6B6 Karaoke Studio (Japan) - PRG:131072 CHR:0
  ├─ 4B6EF399 Karaoke Studio Senyou Cassette - Top Hit 20 Vol. 1 (Japan) - PRG:262144 CHR:0
  └─ 50F3E338 Karaoke Studio Senyou Cassette - Top Hit 20 Vol. 2 (Japan) - PRG:262144 CHR:0

All of these are instances in which the original/parent ROM is included in its entirety at the start of the child ROM.

I attached the generated index in JSON. Right now it's just a map of partial CRC32 to full CRC32, but it could instead map to game name, PRG ROM size, mapper, etc.

nesIndex2.json.txt

Thoughts?

If I try to dump the SRAM of an NES/FC game without first having dumped the ROM, it won't actually dump the SRAM. Choosing the Read SRAM option without dumping the ROM first will instantly show only Press Button... on the screen and no save file exist on the SD card. However if I first dump the ROM and then chose Read SRAM afterwards it does show that the SRAM was dumped properly on the screen, and the file exists on the SD card.

So far I've only tested this with SNES games as well, and there it does dump the SRAM correctly without first having to dump the ROM.

Here's some relevant lines from my log where I first try to dump the SRAM without dumping the ROM, followed by dumping the SRAM after dumping the ROM.

OSCR HW5 V12.4

[+] NES/Famicom


Searching database
for 470814D0 or B3CD71E2...

NES CART READER

CURRENT SETTINGS

MAPPER:   1
PRG SIZE: 128K
CHR SIZE: 128K
RAM SIZE: 8K

Press Button...

[+] Read Sram


Press Button...

[+] Read iNES Rom


Saving to NES/ROM/ZeldaIITheAdven/7/...
[*******************]
CRC32... 47B6A39F -> Zelda II - The Adventure of Link (Europe) (Rev 2).nes

Press Button...

[+] Read Sram

RAM FILE DUMPED!

CRC: B8B04237

Press Button...

Probably a timing issue. Seems to be unrelated to the HW4/5 PCBs since it also doesn't work when only using the Mega 2560 Pro as standalone with the controller port soldered to D7.

After trying to get in touch to see if you had a solution on the original Arduino thread, I, luckily, was able to solve this myself. So that it may be better noticed, and added to the project code, I'm posting it here too.

I'm sorry if diff/patch files aren't the usual format for patches here. It's the first change I've suggested to a github project, but should be simple to incorporate as it's only a few lines. Thanks for everything!

The cartridge was reading as 4 Mbit, until I added another case for "Zero Wing (E)", and now it happily reads the full 8 Mbit, with this patch (renamed to .txt to be uploaded here):
V10.2_Portable.edited.txt

Here's the log file created by the patched V10.2 (portable) software while successfully reading the ROM:
ZEROWING.txt

This solution was originally posted at https://forum.arduino.cc/t/rom-reader-for-super-nintendo-super-famicom-game-cartridges/155260/1570?u=jaffa225man

Thanks again!

I have an Open Source Cartridge Reader V3-ALTER (bought through the build service) and have updated the firmware to v9.5
I can dump the game ROM fine for both of these, but when I try to dump the save it seems stuck on "Saving eep....". I have tried with the 1K pull-up resistor switch both off and on.
If I boot these cartridges on my N64 the saves are there and can be loaded, so they're not corrupted.

txt files from the ROM dumps:

OSCR HW3 V9.5


Searching database...

N64 Cartridge Info

Name: BanjoKazooie
ID: NBKP Size: 16MB
Save: 4K Eeprom
Version: 1.0
 

Saving to N64/ROM/BanjoKazooie/15/...
CRC32... 525899C9 -> Banjo-Kazooie (Europe) (En,Fr,De).z64
Done (214s)

and

OSCR HW3 V9.5


Searching database...

N64 Cartridge Info

Name: SUPERMARIO64
ID: NSMP Size: 8MB
Save: 4K Eeprom
Version: 1.0
 

Saving to N64/ROM/SUPERMARIO64/9/...
CRC32... 03048DE6 -> Super Mario 64 (Europe) (En,Fr,De).z64
Done (109s)

Just tested dumping a game gear game using the retron 3-in-1 adapter and it appears to work! CRC check matches dat-o-matic and I was able to play the rom in an emulator that recognizes .sms as game gear games (like pico). I just used the SMS/Mark 3 raphnet mode and had the adapter plugged into the megadrive slot.

If code was added to match game gear crcs in that mode I think that's all that's needed.

Please let me know if I can assist in testing.

Just a heads up. While it detected the game just fine, it selected mapper 32 which would result in an unplayable game.

Double checked nescartdb and confirmed it's actually mapper 4. Same CHR and PRG #'s

Changed it to mapper 4 and worked just fine. - https://nescartdb.com/profile/view/426/image-fight

The Cart Reader seems to fail at creating the game specific numbered folder and instead just saves to the root dir.
From my tests it's unrelated to the actual ROM as the same game can dump fine one time and then another time it fails to create the folder.

Discussed in #485

Example :

Metroid - Zero Mission (USA) (Beta).gba
922C4A10,BMXE,16,3

Metroid - Zero Mission (USA) (Virtual Console).gba
8825294A,BMXE,08,3

Metroid - Zero Mission (USA).gba
5C61A844,BMXE,08,3

I inserted the USA retail cart of course. The dumper takes the first "BMXE" entry in txt and set size to 16MB. All logical... but giving in an overdump for the real retail cart. Dunno if a couple of serial + header checksum would help here ?

Originally posted by @PsyK0p4T in #383 (comment)

Software

• Release 9.5 (then downgraded to 9.4 to solve the issue)
• Portable method used for flashing the Arduino via the "How to Flash"
• Windows OS used for the Arduino flashing operations

Hardware (PCB from JLPCB and Parts from "What to order" links)

• 2 slot configuration (GBX, N64)
• HW5 R3
• N64 Adaptor
• KeyStudio MEGA PRO 2560
• SI5351 clock generator
• MKS MINI12864 V3 LCD

Please excuse me for I am new to GitHub. If this is not the right place to report issues, I apologize.

5volt worked perfectly, no screen issues and was able to read the ROMs of Tetris (Gameboy) successfully

3volt, however, showed corruption on the letter "b". (attached 2 photos) and would have a checksum error when trying to look up GBA Games from the database file (Tested 3 cartridges, all failed)

I decided to re-flash the Arduino with Version 9.4 with NES module disabled and Megadrive disabled in the code

Refreshing the Adrino with Version 9.4 solved the corruption and I was to dump GameBoy, GBA, and N64 cartridges no problem.

Could this be an issue only in release 9.5?

Edit 1: Fixed spelling of Arduino