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

Support / Re: SNES controller support, Linux
« on: 31/Aug/2017 02:13:32 PM »
Bear in mind that /dev/input/jsX is the legacy joystick interface, which a lot of modern, SDL2-based games don't support, so it's not a reliable indicator of whether the problem has been fixed.

That said, I've confirmed the problem with my Retrode and started poking at "aftermarket" fixes.

I haven't managed to unhook the mouse handler from it yet, nor get it to appear as a jsX node, but I did manage to get the eventX node to show up as a joystick in AntiMicro (a superior, cross-platform joy2key competitor which uses SDL2 for its backend that I sometimes prefer over games' internal joystick support).

To replicate my progress so far, create a file named /etc/udev/rules.d/99-retrode-controller.rules and put this line into it:

Code: [Select]
SUBSYSTEM=="input", ATTRS{name}=="Retrode UG Retrode", MODE="0666", ENV{ID_INPUT_MOUSE}="0", ENV{ID_INPUT_TABLET}="0", ENV{ID_INPUT_JOYSTICK}="1"
(the ENV{ID_INPUT_JOYSTICK}="1" is something I figured out after buying a Chinese NES controller adapter that wasn't showing up as a joystick.)

...then run this command...

Code: [Select]
sudo udevadm control --reload
...and then disconnect and reconnect your Retrode.

Normally, I wouldn't post until I'd finished experimenting, but I have to go AFK for several hours, so I thought I might as well give a status update now.

General Discussion / Re: RetroPi / more plugins
« on: 31/Aug/2017 02:12:05 PM »
EDIT: Oh yeah. The post I was replying to is a repost. I've moved this post to the original thread.

General Discussion / Re: Progress on N64/GBA save support?
« on: 31/Aug/2017 01:32:05 PM »
If you want to use your SRAM save in the PJ64 emulator, then you'll need to save swap the file.

You can use saturnu's ED64-Saveswap program:

If have an Ocarina of Time save and want to check it without using an emulator, you can use this page:

After saveswapping the OOT .SRA, then use the first option "Import save file".  The save data will show in the bottom.  Click on the File# to see the details on each save slot.

I'm going to work on adding FlashRAM save reads.

In case any non-Windows users want an option that doesn't rely on Wine and can be incorporated into scripts, I whipped up a Python-based, GUI-less alternative to ED64-Saveswap:

It's got a complete unit test suite and, aside from one minor usability wart I need to fix, it works with every save file I tested.

Given that some virus scanners seem prone to identifying EXE-ified AutoIt scripts (like ED64-Saveswap) as viruses, I'll probably put together a simple GUI version and py2exe it for Windows users at some point.

General Discussion / Re: SNES Enhanced Cart Support (BETA)
« on: 19/Jul/2017 08:36:07 PM »
No worries.  There's no modifications needed on the Retrode.  I'm using the adapter on a Dragonbox Retrode with only the center 46 pin connector.  I sent a prototype adapter to one of the beta testers and hope to confirm compatibility with the other Retrode hardware versions.


Thanks. That's a huge relief for me.

If these go into production, I'll definitely be getting one. If not, I'll find the cheapest possible way to hack one together that I feel I can trust and then hope they do go into production eventually so I can buy a proper one.

(I'd glady offer to beta-test if I had the means, but all of my childhood SNES stuff except a Spindizzy Worlds manual, Mario Paint manual, and Super Mario RPG strategy guide got thrown out after a basement flood and I've been putting off buying any carts which I can't dump and verify before the "not as described" return period is over.)

General Discussion / Re: SNES Enhanced Cart Support (BETA)
« on: 17/Jul/2017 01:13:58 AM »
I just realized a potential problem after looking at those photos.

My Retrode is from a batch manufactured based on the principle of "We've given up on supporting the SA-1, so we'll cut costs and only populate a connector for the central span of pins" and it doesn't have the two wings populated.

I'd been assuming that, given how long it's been since the original batches with the full connector ran out, you'd be ensuring that everything could be done without the wings. However, seeing them passed through on that photo, when I don't remember the adapter being compatible with anything but the Retrode, makes me worried.

Do those pins have to be connected for a successful dump or is passing them through just playing it safe? Can an SA-1 be coaxed into allowing ROM access with those pins left floating as long as there's a successful CIC sync?

If they have to be connected, I don't know what I'll wind up doing. I really don't trust myself to take a soldering iron to something I paid so much money for. (I've only ever soldered one device... a $3 PS2-USB adapter where one of the USB lines broke free of the PCB's solder pads.)

General Discussion / Re: SNES Enhanced Cart Support (BETA)
« on: 26/Jun/2017 01:10:37 AM »
I'm not sure if the adapter will go into production.  If it does go into production, then there might be design changes like replacing the VCXOs.  I built my circuit around the VCXOs after I found a supply of the 3.072MHz part.  I'm not an engineer so the VCXOs made things simpler for me.

I hope it goes into production. I'd certainly buy one.

(I never had time to build soldering skills I'd trust beyond "If I'd otherwise have to throw it out..." and, as mentioned, I'd really like to be able to stick a copy of Super Mario RPG into my retrode.)

General Discussion / Re: SNES Enhanced Cart Support (BETA)
« on: 16/Jun/2017 12:19:00 PM »
This evokes mixed feelings in me.

On the one hand, I'm very happy.

On the other hand, "Dammit! It took me far too long to stop dwelling on my desire to play Super Mario RPG again the first time around! Who knows how long it'll be until this is ready, ready-made adapters are available, I've ordered and received one, and I've re-bought an SMRPG cartridge!"

(I have a very strict policy about neither pirating nor paying for games unless they're available on my terms in order to ensure I can't contribute to companies' delusions that all they need is more DRM or that Steam-like eStores are acceptable... a policy that led me to buy a Retrode and to continue to eBay cartridges because I refuse to financially endorse the Nintendo Virtual Console... and I only play ROMs I personally dumped from my own cartridges in order to flip the bird at Nintendo's policy on emulation.)

Support / Re: My hashes don't match No-Intro. Is that normal?
« on: 19/Dec/2016 01:22:18 AM »
I just load the DAT files from DAT-o-MATIC into a swiss army knife for ROMs named ucon64 and run ucon64 -rdat *.n64 to rename them. Anything left un-renamed didn't match. (Or without the -rdat to get details)

Before I discovered ucon64, I used a little tool named Snarfblam ROM Hasher (which runs perfectly well in Wine on non-Windows systems) which gives MD5, SHA-1, and CRC32 for the file, the ROM, and the ROM after byte-swapping it.

Emulators don't care, so I've never needed to byte-swap my ROMs, but ucon64 can byte- or word-swap N64 ROMs too.

General Discussion / Re: Adaptors
« on: 04/Mar/2016 12:11:02 AM »
I would much rather see a Gamegear plugin personally.

From what I understand, the difficulty with the Game Gear is finding a supply of the cartridge sockets and, if you do, the SMS adapter has solder pads left open to add one.

(I'm lucky in that respect. The only Game Gear games I really care about are the Sonic ones and those are unlockable in my CD-ROM version of Sonic Adventure.)

Also, another tip: The Retrode 2 doesn't like counterfeit GBA carts. I learned that when I got lazy about double-checking an in-province eBay purchase.

Everything still works fine and I got my money back, but that counterfeit cart wouldn't even show a generic BIN file in the Retrode while GBA-dumping homebrew on a Nintendo DS dumps it as a 32MiB ROM. (...which does boot in an emulator but I never tested if it plays without crashing)

I thought that knowledge might be useful as something for others to learn from.

For those unfamiliar with identifying counterfeit carts, here are the tells for a GBA cart:

  • Go to Mobygames and check if the label is correct (this'll save you a lot of time if a picture is available there)
  • Does the AGB-xxxx-xxx part number on the label match what the game claims to be?
  • Are the rating mark, "Licensed by Nintendo" or "Nintendo" mark, and Seal of Quality present, in the right places, and the right size and shape?
  • Is the label straight and well-centered on the cartridge, with a glossy finish and edges cleanly cut from the larger sheet it was printed onto?

  • Are the contacts gold-plated?
  • Counterfeits often have a small vent in the protective plastic barrier just above the middle of the edge-card contacts.

  • Is the part number on the back of the shell AGB-002? (eg. AGB-004 is a Japanese GBA charger)
  • Compare the font for the back of the shell to a known-good cartridge. Some counterfeits do use AGB-002 but then have the Nintendo logo and the rest of the text too thin.
  • Is the cartridge held together by a tri-wing screw?
  • Counterfeits sometimes cover up their use of non-tri-wing screws with a scary warranty sticker. Nintendo trusted tri-wing screws to be enough.

If you've got a tri-wing screwdriver, you can also play it safe by opening the cartridge up and examining the PCB. Remove the tri-wing screw and then the front of the case can slide down and lift out using a mechanism similar to how you'd unmount a power bar you hung on the wall:
  • Genuine cartridges will open easily once the screw is removed. Fakes may have a large chip blocking the sliding mechanism.
  • Genuine cartridges will store the games on mask ROM (basically, each game's ROM is a custom part and changing even a single bit requires a new photolithography mask, so the setup costs are through the roof).
  • A genuine cartridge will have "Nintendo" silk-screened above the edge-card contacts. Fakes generally lack it or use the wrong font.
  • Only fakes will have chips with all labelling erased or with labels stuck onto them.
  • Check the save method on DAT-o-Matic. If it's not SRAM, then a battery is a guaranteed indication of a counterfeit because it means that the game itself is stored on battery-backed RAM to save money.
  • Genuine SRAM cartridges will use many different colours of insulating rings on their batteries (red, blue, etc.) while fakes seem to all use yellow.

...and, if you're really feeling lucky and want to risk sticking it into your Nintendo DS, the fakes are often the wrong regional version (eg. EU version with a US sticker) and, if dumped via DS homebrew, generally dump to something that DAT-o-Matic has never seen, even if you manually trim the dump file to the sizes it expects for the various versions.

(If anyone wants them, I can also point you to guides on how to identify fake original Gameboy carts, Nintendo DS carts and/or fakes of rare SNES carts.)

Pages: [1]