Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ssokolow

Pages: [1] 2 3
Support / Re: Certain Games not working
« on: 07/Jan/2019 01:29:23 AM »
The first thing I do in a situation like this is to soak cotton swabs in the purest alcohol I have and clean the contacts on the cartridge until the swab comes away clean.

It should say something like denatured alcohol, isopropyl alcohol, or rubbing alcohol and the ingredients should not contain anything beyond some form of alcohol, aqua (water), and a bittering/denaturing agent like denatonium benzoate. (Be wary of "rubbing compound", which will often list stuff you don't want, like camphor, in the ingredients.)

If you're having trouble finding any of those at your local pharmacy or dollar store or equivalent, and you're of age to buy liquor, you can also use the stuff intended for adding alcohol content to mixed drinks, which is known variously as "rectified spirit", "neutral spirit" or "grain alcohol". In that case, try to find the stuff that's around 95% alcohol by volume (190 proof. Alcohol purer than this will actually pull moisture from the air to reach that balance).

I'm told there are also automotive products which are just denatured alcohol, but I can't remember which ones they are.

Whatever alcohol you use, I'd never settle for anything less than 70% alcohol / 30% water by volume and the higher the concentration the better.

Next, check dat-o-matic. It'll tell you the size and MD5/SHA1/etc. hashes for a good dump, so you can tell whether it's a problem with your dump or a problem with your emulator.

For all of them, you can try looking up the correct size on dat-o-matic and then setting the "force system" and "force size" options in case it's the Retrode's detection routines that are messing up.

I just recently suggested that to someone who was having problems with an unlicensed Genesis cart and that solved the problem.

For Kingdom Hearts: Chain of Memories, there are two things that come to mind:

1. GBA ROM headers don't specify the ROM size, so the Retrode has to guess. It could be you need to set the "force size" option to whatever dat-o-matic tells you, then truncate the file to get rid of garbage bytes at the end if it's between two sizes the Retrode will dump and you had to round up.

2. There are a lot of counterfeit GBA carts out there and they don't generally play nicely with the Retrode. If you've got a tri-wing screwdriver, the easiest way to identify them is usually to open them up and discover a battery in something that dat-o-matic doesn't list as using battery-backed SRAM. (And, in such a case, the game might be gone. Counterfeit GBA carts often store the game itself in the same battery-backed SRAM as the save data in order to cut costs.)

Here's a thread (with photos) on how to identify fake GBA carts. (Note that, though there's no corresponding photo, one reply points out that some fakes say AGB-004 on the back, which is a charger, not AGB-002, which is a GBA cartridge shell.)

I have no specific experience with SMS games, so I can't offer anything beyond the general advice for Zaxxon 3D.

P.S. To complete the set, here are my links for identifying fake GB/GBC, and fake SNES cartridges. (Sorry that some of the pics on the latter one are gone. The explanations of what they were showing should still be helpful though.)

Glad I could help. :)

The first thing I'd do is try to get more information to narrow things down.

For example, see if you can find solid information on whether the emulator you're trying can play a known-good dump of that specific game.  If not, or if you can't be sure, try to find another emulator which is confirmed to work with known good dumps of it.

I've only ever dumped three ROMs for Genesis with my Retrode (Sonic 2, Sonic & Knuckles, and Sonic 2 & Knuckles), but I know Gameboy Advance ROMs are susceptible to overdump, since they don't specify their size internally. Maybe something about the cart's header is confusing the Retrode into dumping the wrong range of memory addresses.

Check the sizes listed on dat-o-matic to see if what you're dumping is the right size.

If it's too big, try truncating the file and re-hashing it. If it's too small, try using the Retrode option to override auto-detection and force a dump size. (You may need to dump more and then truncate the result, since the retrode's forced dump sizes don't let you specify a size down to individual bytes.)

Check sites like dat-o-matic for evidence of either the hash you have now or any hashes you get from experimenting with size-forcing and truncating. (If nothing else, maybe you'll find dat-o-matic reporting that it's a broken dump that various members managed to independently confirm as broken.)

Also, I can't endorse piracy, but, if you have a way to get a known good dump through other means, you could try comparing the contents of the two files in various ways to see if you can identify contents of one file within the other, but incomplete or misaligned somehow.

Support / Re: Connecting official N64 controllers to Retrode 2
« on: 10/Dec/2018 12:17:52 AM »
Sorry for the delay in getting back to you and thank you for responding to my forum thread, I don't know why I didn't get a notification email in my inbox as I set up the forum thread to send email notifications as soon as new posts are  uploaded.

Huh. I have the opposite problem. It sends me a weekly digest whether or not there's actually anything to report in the threads I'm watching.

General Discussion / Re: Feature suggestions
« on: 24/Sep/2018 12:22:03 AM »
Any chance of looking into support for the Nintendo e-reader for Game Boy Advance? I'm not sure if it's officially supported or not, and I'd like to hear about it before I try anything.

The eReader is just a specialized matrix code scanner. (ie. similar to QR Codes)

You'll need emulator support for it either way, so a better option would be to just write something where you snap a picture of the code on the eReader card and it saves it to a format your emulator can load.

Thanks @ssokolow.  I actually tried for a goodly amount of time to use your solution first.
While I have in the past used dfu-programmer on my ElementaryOS (Ubuntu) laptop, the latest ElementrayOS release flat out was not usable with dfu.   In order to stick with using linux I feel I would have required starting up a fresh virtual machine for the purpose - and nearly did so - when I decided to try using my Windows 10 VM first.

Huh. Well, when I find time to upgrade from Kubuntu 14.04 LTS to Kubuntu 18.04 LTS, I'll remember to figure out what's going on there.

Support / Re: Connecting official N64 controllers to Retrode 2
« on: 17/Sep/2018 01:00:04 AM »
Hi skaman,

Thank you for responding to my forum thread and sorry for the delay in getting back to you. I will take your answer as a solution.

Many thanks,


Another option, if you don't feel comfortable modifying your N64 plugin or want to connect more than two N64 controllers, is to buy a Mayflash N64 Controller Adapter like this:

New Nintendo 64 Controller Adapter for PC Mac Dual USB to N64 Mayflash 2 Port

That eBay listing has them for $16.50 US with free worldwide shipping and mine works beautifully on my Linux machine. (I bought a Retrode when they still had a ready supply of N64 controller connectors to pre-install, but I like to keep my Retrode disconnected and boxed up when I'm not actually dumping ROMs, so I use the Mayflash for day-to-day play instead.)

If the seller stops re-listing it, you're looking for a Mayflash-branded USB-to-N64 controller adapter in a blister pack with a white and spring-green cardboard back. The adapter itself is black, with two N64 connectors side-by-side on the front and a USB cable out the back. I can take a photo of mine if that's not enough.

Support / Re: About to Buy A Retrode 2. A Few Questions.
« on: 17/Sep/2018 12:43:53 AM »
I have another question. Apparently the reason the GBX can't dump multi game gba carts is that it dumps only the game selector. In the thread I read, forcing the Retrode to detect the cart size via editing the [forcesize] option in the config file should produce a good dump. However, it would appear that it only supports integer values. So if I wanted to dump Super Mario Advance 4, which is apparently 2.43 mb according to No-Intro, would I just put 3 as the value in [forcesize]?

I remembered dumping my copy of Super Mario Advance 4 just fine, so I pulled it out, along with my Retrode and GBx plugin to verify.

My Retrode did overdump it when forceSize was set to the default of 0, but that was easily solved by using this Linux command to trim it down to the size that DAT-o-MATIC said it should be:

Code: [Select]
head --bytes=4194304 SuperMariod.AX4E.gba > trimmed.gba
...then it matched the DAT-o-MATIC signature perfectly well:

Code: [Select]
% ucon64 -rdat trimmed.gba
uCON64 2.0.1 UNIX (Linux) 1999-2006,2015
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License

Renaming "trimmed.gba" to "Super Mario Advance 4 - Super Mario Bros. 3 (USA, Australia) (Rev 1).gba"

You may also want to apply these IPS patches to undo the changes made when porting from SNES to GBA which weren't really improvements:


To apply them, if your emulator doesn't support auto-patching, you'll need either Lunar IPS (Windows), Multipatch (MacOS), UniPatcher (Android), (Linux CLI), or JIPS (GUI for anything with Java).

You might want to try the helper I wrote for Linux after I got fed up with having to re-learn the official instructions every time I needed to apply an update:,374.msg2888.html#msg2888

It provides a friendly, task-specific wrapper around dfu-programmer and does everything I could think of to be simple and mistake-resistant.

Sadly I don't know anything about hex editing so I'll just have to stick with using the config file to force the correct size of my gba games. Anyway I'm glad for your responses. I'm now able to play all my gba games on my computer via retroarch.

You don't strictly need a hex editor.

For example, if you've got a POSIX-compliant terminal environment (Linux, MacOS, Windows with WSL), you should be able to do what I do:

I check DAT-o-MATIC for the correct size, then try this command to verify that I looked up the right revision.

Code: [Select]
head --bytes=CORRECT_SIZE /path/to/dump.gba | md5sum
If the md5sums match, then I run this command:

Code: [Select]
head --bytes=CORRECT_SIZE /path/to/dump.gba > /path/to/fixed_dump.gba

I used this script on Mac OS X 10.13.4 and it worked great.

Thanks for telling me. I've updated the top post to mention that.

I tried out this script on my Mac with macOS Sierra (10.12.6) and it successfully updated my Retrode 2 to the 0.23 firmware. Thanks! :)

Happy to hear it. :)

I've updated the initial post's comment about macOS accordingly.

General Discussion / Re: N64 Save Support (FW v0.23)
« on: 13/Nov/2017 01:05:53 AM »
Thank you SO MUCH for figuring this out! My N64 plugin finally works and I can archive my cart saves to PC!

I do have to report that, after testing all the carts I own, Retrode did not detect a save file on my Majora's Mask cart.

EDIT: You said .EEP files didn't need to be altered in any way to work with emulators; this doesn't appear to be the case. Project64 couldn't read any of them.

Which region/version of Majora's Mask is the cart?  Try setting [saveReadonly] to 1 then read the Majora's Mask cart.

Do the .EEP files contain data or all FFs?  Are you using the early N64/GBx plugin or the later N64 plugin?
The Majora cart is the original NTSC release with the lenticular label. "Savereadonly" is already set to 1. I'm using Retrode 2 and the plugin built specifically for N64 carts (the one that says "Plug-In 64" on the label). I don't understand the "files" question.

I put the saves in the "Save" folder of Project64; it's where it gets them from. But I get a "Failed to open EEPROM" message when I try to use them.

You mentioned something about setting the voltage to 3.3V; that is something I forgot to do the first time. But when I dumped the saves again on the correct setting, I got the same results. The Majora cart did finally detect a save, though.

Of course it's an .FLA which means I can't test it immediately. That save-altering program you linked to is all Greek to me -- I have little experience with command line programs so I don't know how to use it. I do know that the .EEP files don't work.

I've got a gold, lenticular NTSC Majora's Mask, so I took the liberty of testing it with Retrode firmware v0.23, my Plug-in64 adapter, the 3.3v setting, and the "[saveReadonly] 1" that I just leave on all the time.

I play whatever I can with Mupen64Plus, so I only have Project64 installed in Wine right now, but my and my brother's old save files appeared and loaded just fine when I did the following:

1. Copy "ZeldaMajora'sMask.NZSE.fla" from the Retrode to /home/ssokolow/.wine/drive_c/Program Files/Project64 2.2/Save
2. Rename the save file to "ZELDA MAJORA'S MASK.fla"
3. Unset the read-only attribute that the Retrode puts on it
4. Run " ZELDA MAJORA'S MASK.fla" in the terminal

(Mine doesn't have a GUI yet, but ED64-Saveswap does if you want something simpler. As for the name to rename it to, create a new save in your game and see what filename appears in Project64's Save folder.)

General Discussion / Re: N64 Save Support (FW v0.23)
« on: 06/Nov/2017 12:57:44 AM »
It might be better to say that mine is a "portable" or "cross-platform" alternative, since there's nothing that should prevent it from working on Windows.

(ie. If it doesn't work on Windows, it's a bug that will be found and squashed when I have time to get back to working on it and set up AppVeyor CI testing.)

In fact, when I have time to get back to work on it, the partially written optional GUI was envisioned specifically to provide an alternative to ED64-Saveswap for people with over-sensitive virus scanners that hate AutoIt scripts.

General Discussion / Re: Progress on N64/GBA save support?
« on: 06/Nov/2017 12:43:45 AM »
Thank you! The script as it is today is fantastic and support for converting to the Libretro core would make it even greater!

Glad I could help. :)

Also, in case you missed it, I did some similar itch-scratching with regard to updating Retrode firmware on Linux.

(Basically, a convenient little shell-script frontend for dfu-programmer because I kept having to go back and re-read the instructions and it got tedious. Not tested on OSX but should theoretically work there too if you're going the dfu-programmer route.)

Pages: [1] 2 3