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
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

I had to force the file size to get a good dump on Paper Mario

Good news there.

While I can't confirm it because Paper Mario is still on my to-get list, a fix for that showed up in the changelog for the v0.23e-beta firmware that was sent to me so I could test the EEPROM save dumping support.

Since I got tired of having to keep refreshing my memory on the procedure for updating a Retrode's firmware on Linux, I wrote a little shell script to automate the process as much as possible.

...and, being the risk-averse perfectionist with a focus on UI/UX design that I am, I also built as many safety checks into it as I could without turning it into a massive project.

I've posted it as this GitHub Gist and, in case I ever move it from there and forget to leave a note on the new location, here's the blog post I used to announce it.

It hasn't been tested on OSX but, in theory, it should work. It has been used successfully on macOS 10.12.6 and 10.13.4. (I only rely on dfu-programmer and POSIX-specified commands.)

I hope this helps someone. :)

P.S. If anyone's interested in helping me to improve this, here are the things I need help with:

  • Getting a copy of the output a Retrode 1 produces from the various "dfu-programmer at90usb646 get ..." commands to see if there's any way I can tighten the safety checks so they verify that the detected at90usb646-based device in programming mode is actually a Retrode. (I only have a Retrode 2)
  • Determining whether it's safe to automate the final "please press Reset" using "dfu-programmer at90usb646 reset", given that the instructions I worked from only explicitly warn against "dfu-programmer at90usb646 start".
  • Identifying the exact maximium filesize(s) to limit to in order to safely die with an informative "Too big to be a valid image for this Retrode" message.
  • Finding more ways to detect invalid or mismatched firmware images before attempting to write them. (eg. Is there a reliable way to tell Retrode 1 and Retrode 2 images apart by their contents, rather than expecting a human to parse the filenames?)

General Discussion / Re: Progress on N64/GBA save support?
« on: 25/Sep/2017 05:03:54 AM »
when an n64 randomly reboots it usually means its overheating

That, or the memory expansion has gone bad, or the power supply block's connection to the console itself is loose.

Those are the three candidates I looked up but I've been too busy resolving more pressing concerns (eg. I just built some new wall-mounted shelving and I need to finish building the first of two wood sheds before winter comes around) to dig up my jumper pack and extractor tool and break out my line-drive ("game bit") bits and try to identify the problem.

General Discussion / Re: Progress on N64/GBA save support?
« on: 18/Sep/2017 12:40:29 AM »
N64 Cart EEPROM save support is complete.  The production N64 plugin supports EEPROM saves.  If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA.  I'll post pictures of a modified prototype adapter if anyone is interested.

The next BETA firmware release is on hold pending the resolution of the Paper Mario heuristics code.  Once I'm able to fix Paper Mario, then I'll release the BETA to the test group.  A public firmware release will follow after the testers have thoroughly tested the BETA firmware.

[Insert fangirlish manly squeal of delight here]

(I've got some old saves that it'll be nice to see again without having to find the time to diagnose my N64's reboot problem.)

General Discussion / Re: PC Engine/Turbografx plug in?
« on: 31/Aug/2017 06:12:34 PM »
I'd also be interested in buying a pre-built one.

Support / Re: Super 3d Noah's Ark
« on: 31/Aug/2017 06:02:55 PM »
Just wanted to give an update. I took the case off the retrode and was able to successfully dump the ROM. Haven't played it too much yet, but when I started the game in an emulator it gave a bad checksum error but seemed to still play.

For the record, the ROM included in the version sold on Steam also gives a bad checksum error and I'm pretty sure that's intentional because this is what ucon64 has to say about it:

Checksum: Bad, 0xbf8b (calculated) != 0x0000 (internal)
Inverse checksum: Bad, 0x4074 (calculated) != 0x0000 (internal)

(It looks like they just didn't bother to calculate a checksum while mastering, since it wasn't necessary to get the thing to boot in a real SNES.)

Support / Re: SNES controller support, Linux
« on: 31/Aug/2017 05:53:54 PM »
OK, here's what progress I've made.

I'm still trying to figure out the proper way to trigger generation of a /dev/input/jsX device node in [HIDMode] 1;, but I've figured out how to keep it from waggling the mouse around if you want the "4Joy+Mouse" mode without the mouse. (I wasn't thinking "shell script" enough. Using ="" rather than ="0" to disable the "is a mouse" indicators works.)

Here's the updated udev rule...

Code: [Select]
SUBSYSTEM=="input", ATTRS{name}=="Retrode UG Retrode", MODE="0666", ENV{ID_INPUT_MOUSE}="", ENV{ID_INPUT_TABLET}="", ENV{ID_INPUT_JOYSTICK}="1"
...and here's what I tested with it:
  • A Super Famicom controller with AntiMicro (an example of something based on SDL2)
  • An N64 controller with Blast Corps in Project64 (an example of a Windows application in Wine)
  • A Super Famicom controller with Super Mario World in Snes9x-GTK (because it's a combination you might actually want to use)

I couldn't test under Retroarch because I have no idea how I got it configured in the first place (it's ignoring input from mouse, keyboard, and unrecognized joysticks for me).

As for mednafen, it doesn't recognize /dev/input/eventX input, but it should be possible to work around that by using xboxdrv in the mode where it acts as a Linux equivalent to x360ce. (Raw /dev/input/eventX in, fake XBox 360 controller /dev/input/jsX and /dev/input/eventX out.)

I'd offer a config to do that, but I'd like to see if I can come up with a proper fix before I resort to that. (I have dedicated NES, SNES, Genesis, N64, etc. controller adapters that I normally use because I can mount them to the underside of my desk, and a genuine Microsoft XBox 360 controller, so I've never bothered to learn how to configure xboxdrv to remap things.)

That said, I thought I remembered the Retrode working as a non-bothersome way to use a Genesis controller with mednafen and it turns out that switching to [HIDMode] 2; (2Joy) produces the working /dev/input/jsX that I remembered. (If you want a simple way to edit it, Leafpad works for me.)

HIDMode 2 also works with the link you posted, so I can only assume that browsers are depending on the legacy interface on Linux.

Finally, I did test [HIDMode] 1;'s /dev/input/eventX nodes with a Genesis controller and it appears that, while the raw input is detected by SDL2 and does show up in AntiMicro's joystick-mapping UI, everything but the D-Pad is on such high button numbers (eg. 50) that neither the Wine joystick control panel nor AntiMicro itself are compatible. (xboxdrv may be a solution, though I haven't tested it.)

Pages: [1] 2