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: 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.)

General Discussion / Re: Progress on N64/GBA save support?
« on: 30/Oct/2017 04:57:47 AM »
Hello, The following is based on BizHawk Mupen 64 Core exploration done a while back..  :)

Mupen64 uses its own format for savedata where all savetypes are stacked together into a single file.
To import a save, one needs to hack the raw save data into appropriate offset. I have included the Mupen64 method used for loading save ram and the offsets/file sizes needed.

Code: [Select]
EXPORT void CALL load_saveram(unsigned char * src)
memcpy(eeprom, src, 0x800);  --> Size 2048 bytes
memcpy(mempack, src + 0x800, 4 * 0x8000); ---> Size: 131072 + 2048 = 133120 bytes
memcpy(flashram, src + (0x800 + 4 * 0x8000), 0x20000); ---> Size: 131072 + 2048 + 131072= 264192 bytes
memcpy(sram, src + (0x800 + 4 * 0x8000 + 0x20000), 0x8000);  --> Size: 2 * 131072 + 2048 + 32768= 296960 bytes

One can use it by first creating an empty Mupen64 (stacked) save file and then separating and reconstructing the offsets with eg. gnu head/tail/pipe redirection commands.

Eeprom works just by renaming the raw save file because it is located first in the stacked save file.

The previous is of course after possible byte-swapping.

I think that's specific to the libretro core. I know my standalone copy of Mupen64Plus (as included in the repos for Ubuntu 14.04 LTS) handles it the same way PJ64 does and, while researching to write the Python script, I remember reading that the libretro Mupen64Plus core requires special provisions compared to other N64 emulators.

(That said, thank you for clarifying what it's actually doing differently. I never did get around to tracking that information down. Once I have time to get back to working on it and finish the nearly-completed optional GUI frontend, I'll install the libretro core, do some testing, and add an option to convert to/from that.)

There's a device called the INL Retro which claims to dump NES and Famicom games as well as program the NES and SNES repro boards sold by the vendor but I don't have any personal experience with it.

(I'm a Linux guy, Kazzo-family boards like the INL Retro require a client on the host machine, and, while separate unsupported Linux ports of the dumping and programming support supposedly exist, they're sort of unicorns as far as actually finding them. Also, from what I've read elsewhere, it seems like support for automatically identifying carts and setting the correct mapper modes has been one of those "planned but too busy to deliver" things for a while now.

General Discussion / Re: Progress on N64/GBA save support?
« on: 16/Oct/2017 01:16:34 AM »
Also if you are using Project64: make sure to give it the name Project64 needs.
If you are not sure, run the game once in Project64. Copy that name from the new file.
Rename your Retrode imported file using that name and replace that file in your Project64 save directory.
Sometimes you may have to add spaces or capitalize letters.

Same thing for Mupen64Plus. (Mupen64Plus appears to be using names from GoodN64)

On Linux, the saves are in ~/.local/share/mupen64plus/save

Pages: [1] 2 3