sanni / cartreader Goto Github PK
View Code? Open in Web Editor NEWA shield for the Arduino Mega that can back up video game cartridges.
License: GNU General Public License v3.0
A shield for the Arduino Mega that can back up video game cartridges.
License: GNU General Public License v3.0
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 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)
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.
Originally posted by Mythris29 August 20, 2022
So I think the dump is working for sram on my copy of Famicom Wars because it has info in it if I look at it in a hex editor but I can't seem to write the file back to the cartridge.
I don't get any errors during the process so I'm unsure what the issue is. I have 2 famicom carts and both dump the carts just fine so I don't think the slot and or ver5 cart reader is the issue but I only have a sample size of 2 and only a sample of 1 for this sram issue so I'm unsure if this is a hw5 issue or an issue just with my setup
I'm attaching a copy of the sram dump is case it helps.
RAM.zip
.
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?
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
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.
Software
Hardware (PCB from JLPCB and Parts from "What to order" links)
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
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?
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...
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:
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 ?
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
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
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.
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
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.
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.
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?
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
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,
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
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
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.
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
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:
name | PRG ROM size | 16k CRC | 128k CRC | 512k CRC |
---|---|---|---|---|
Mario | 16k | 9f115a9e |
- | - |
Zelda | 128k | a3b3e36e |
53b88a7a |
- |
Contra | 128k | a3b3e36e |
b0c8c11e |
- |
Kirby | 512k | a3b3e36e |
2864f7cc |
4f3ad289 |
Tetris | 512k | a3b3e36e |
2864f7cc |
d2dce641 |
Gradius | 512k | dd611655 |
f5525447 |
707c2b2f |
Frogger | 512k | 4bf93c55 |
3b2dc183 |
12c70afd |
PacMan | 512k | 4bf93c55 |
3b2dc183 |
8c7869e6 |
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.
Thoughts?
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!
Latest merges in NES.ino brought a little issue (got it with hw3 and today's version) :
This comes from checkStatus_NES(), calling getMapping();
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.
When too many modules are enabled you can experience the following issues:
This can be fixed by disabling modules you don't need to save a little bit of SRAM.
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
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?
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)
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.
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 :)
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.
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
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 !
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?
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.
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.
Cheat devices, Xplorer64 (Xploder64) not read.
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.
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.
Originally posted by ryaneallen3 July 6, 2022
Dumped Phantasy Star IV and got a checksum error. Tried loading it in BizHawk and I see the Sega logo and music before it freezes. I tried the FixCheckSum tool, as that worked for me to get Beyond Oasis dump to work, but PSIV does the same thing after checksum fix. How can I dump?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.