snega2usb: USB Reader for SNES / Sega Genesis Cartridges

[Matthias_H]

Hi!

I just wanted to introduce a project of mine, the snega2usb. It is a USB Mass Storage wrapper for SNES (and Sega Genesis) cartridges that makes the ROM/SRAM contents appear as SMC/SRM files, allowing you to legally play your good old SNES games in an emulator, and even to rescue/modify your battery-backed game states. Of course, it also works in ZSNES since all it does is fake some ROM/SRAM files on a virtual thumbdrive.

Here's how it looks right at the moment:


The project got a lot of press (featured on Hack A Day, Engadget, Gizmodo, etc.), but since I haven't found it in here, I thought you might want to hear about it. Otherwise, I apologize for the spam

More info:

Project website: http://www.snega2usb.com
Crappy Demo Video #1: http://www.youtube.com/watch?v=Pwq6vRM8U7k
Crappy Demo Video #2: http://www.youtube.com/watch?v=QNBg_jWjBmI

In case you are interested, I will be ordering a batch of prebuilt units very soon. Details will be announced on the project web site.

Enjoy!
Matthias_H

[byuu]

That's really neat. I've actually wondered why someone didn't make something like this before, it's a much nicer interface for dumping cartridges than using floppy disks or Windows-only closed source apps.

Obviously, it's not quite my dream as I'm sure you're buffering the cartridge for very obvious reasons. So emulators still need to support the special chips, ruling out three titles at present from working with this device.

I do have one concern, though. There are literally dozens of different formats for SNES PCBs, each one mirrors ROM and RAM in different places, some have CIC chips that require a handshake before they respond with ROM data, and two may even require you to write to certain MMC registers to access all the data.

Does your device allow for firmware updates, or a full linear 16MB address space dump (where unmapped regions would obviously not return valid data), in case the convenience SMC/SRM pair mode doesn't quite work?

[Matthias_H]

Obviously, it's not quite my dream as I'm sure you're buffering the cartridge for very obvious reasons. So emulators still need to support the special chips, ruling out three titles at present from working with this device.

The file access follows whatever the emulator is doing. Due to the nature of the USB Mass Storage standard and the parameters of my FAT16, files are read one "cluster" (512 bytes) at a time. As for the special chips, I am only reading the ROM and SRAM, following whatever I managed to reverse engineer using the cartridges I have at my disposal. So yes, special chips will have to be emulated.

I do have one concern, though. There are literally dozens of different formats for SNES PCBs, each one mirrors ROM and RAM in different places, some have CIC chips that require a handshake before they respond with ROM data, and two may even require you to write to certain MMC registers to access all the data.

Well, I am aware of the sheer multitude of different cartridge formats, and believe me, I had my share of fighting with them. So I doubt the snega2usb is ever going to work with ALL games in existence, but something like 98% works fine for me. I am sure a lot of stuff can be added at some later point through firmware updates -- the most important RESET, /CS, /RD, and /WR lines are in principle freely programmable --, but the CIC and extension chips will have to remain unwired for now, until someone decides otherwise.

As for the firmware itself, at the moment I'd rather keep it closed at least until I'm through with the first batch of mass-produced units. I'm reasonably positive that will go open-source sometime in the future, though.

Cheers,
Matthias_H
www.snega2usb.com

[byuu]

Due to the nature of the USB Mass Storage standard and the parameters of my FAT16, files are read one "cluster" (512 bytes) at a time.

Right, I completely understand that it'd be next to impossible to read/write to the cartridge in real-time. The only way to do that would be via something like the famiclones.

As for the firmware itself, at the moment I'd rather keep it closed at least until I'm through with the first batch of mass-produced units. I'm reasonably positive that will go open-source sometime in the future, though.

I don't think even most open-source advocates mind if the firmware source is available, just the ability to flash new ones in case certain carts are found not to dump for some reason.

There's too many carts to test, your 98% estimate could turn out to be 90% if you were really unlucky. If a quick flash could fix it, then there's no cause for concern.

---

Anyway, it sounds really nice. If you sell enough of them, it could be a fun novelty to have emulators detect the device and allow direct booting without using the file open dialog.

[badinsults]

Sounds pretty similar to the Mash Mods USB reader. Still, the question becomes, why run the game off the cartridge when you can simply dump the game ROM to your hard drive and not worry about having to interface with the cart while playing the game, which I imagine is very unreliable.

[Matthias_H]

Sounds pretty similar to the Mash Mods USB reader

Wow, I did not know that one, thanks for pointing this out. Looks like I have to revise the "best of my knowledge", for this is indeed some serious competition. Does it require special drivers / programming software? Which games does it support? My goal was to come up with a solution that runs under every modern operating system out of the box.

Still, the question becomes, why run the game off the cartridge when you can simply dump the game ROM to your hard drive and not worry about having to interface with the cart while playing the game, which I imagine is very unreliable.

You're absolutely right. However, since most emulators load the whole thing at once anyway, this should not be much of a problem. While I did want to replicate the "plug in cartridge and play" feeling, I somehow missed the "touch the cartridge to make game crash" feature

[byuu]

Still, the question becomes, why run the game off the cartridge when you can simply dump the game ROM to your hard drive and not worry about having to interface with the cart while playing the game, which I imagine is very unreliable.

It gives end users the ability to play their real cartridges. Those carts may already have their level 99 New Game+ saves, or they may be paranoid about the validity of the unverified dumps on the net.

And it's also a great defense for the use of emulators, as very few people have the technical know-how and resources to acquire copiers. It's still illegal to download images, even if you own the game. Now we have a tool that lets people play games right off the original format.

It's much the same argument as using a real PSX game over an ISO / BIN image.

But mostly the novelty :)

[Gil_Hamilton]

I'd seen a device that did this for MSX carts before. Now we have not one, but TWO for SNES carts as well. That's pretty sweet.

[creaothceann]

Some comments:
- the official extension for SNES ROMs is .sfc (.smc is used by a copier, just like .fig, .swc and so on)
- "savestates" is usually used for emulator saves, and "SRAM" is used for the cartridge's battery-backed RAM
- a list of SNES special chip games is here: link

[Gil_Hamilton]

Some comments:
- the official extension for SNES ROMs is .sfc (.smc is used by a copier, just like .fig, .swc and so on)

Official? I wasn't aware Nintendo had an officially-sanctioned file extension for SNES dumps.

[byuu]

Official? I wasn't aware Nintendo had an officially-sanctioned file extension for SNES dumps.

.WAD

Anyway, Super FamiCom makes a lot more sense than Super MagiCom at least. Best practice would be to make it .SFC, if at all possible. Even if other emu authors are fine with there being 20+ extensions, it'd still be nice to encourage the use of just one if we can.

[Gil_Hamilton]

Official? I wasn't aware Nintendo had an officially-sanctioned file extension for SNES dumps.

.WAD

Anyway, Super FamiCom makes a lot more sense than Super MagiCom at least. Best practice would be to make it .SFC, if at all possible. Even if other emu authors are fine with there being 20+ extensions, it'd still be nice to encourage the use of just one if we can.

Arguably, a generic .bin is the most logical.
But that has obvious convenience issues.

[badinsults]

Sounds pretty similar to the Mash Mods USB reader

Wow, I did not know that one, thanks for pointing this out. Looks like I have to revise the "best of my knowledge", for this is indeed some serious competition. Does it require special drivers / programming software? Which games does it support? My goal was to come up with a solution that runs under every modern operating system out of the box.

Right now, the Mash Mods only has Windows software, though Matthew Callis made some software that works in Mac. Apparently Linux software is coming pretty soon. I got a flash cart to along with it, and that works pretty well. I had some problems dumping some of the games I tried, though the first ones I threw at it were ones with special chips. I couldn't dump Super Mario RPG or Dirt Racer (a PAL Super FX game). I was able to dump a couple of prototypes I have, plus games Final Fantasy III, R-Type III (PAL), NBA Live 96 and Star Fox. Sometimes it took more than one try to dump a game. I haven't tried it a lot because I am working on some other things, and it requires me to boot up Windows, which is running at a base state because of the lack of drivers for my computer.

Still, the question becomes, why run the game off the cartridge when you can simply dump the game ROM to your hard drive and not worry about having to interface with the cart while playing the game, which I imagine is very unreliable.

You're absolutely right. However, since most emulators load the whole thing at once anyway, this should not be much of a problem. While I did want to replicate the "plug in cartridge and play" feeling, I somehow missed the "touch the cartridge to make game crash" feature

I guess it is true, once the game is loaded in the emulator, it is already in memory. How do you ensure it gets loaded properly? And how fast is the transfer rate?

If you need someone to test out your device, I have a collection of about 250 carts. I'm also listing off pcb types, if that is what determines how games are dumpable.

[paulguy]

Will it name the file based on it's header name? like SUPER MARIOWORLD.smc? Not much of a big deal, but a neat little feature.

I'll so buy one, though.

[whicker]

Matthias_H, two thoughts:

1) Are you including rubber feet for the 4 corners of the reader? Would seriously cut down on reports of failures because of coins, spills, etc.

2) How do you handle the names of Japanese games? The ASCII set goes above character 127, but gladly only is still one byte, but there could be a literal translation, like カ being KA, or マ リ オ being MA RI O. Don't know if you support long filenames...

[Matthias_H]

Wow, that's a lot of answers for a single night

Let me go through some of them:

@byuu: That's pretty much what I had in mind. You plug in your game, and ideally the emulator should boot it right away, as the console would do it. (Adding this functionality to existing emus should not be a big deal; they would only have to watch a given directory for changes) After you're done, everything is still on the cartridge, so you can take it to the next computer, or back to the console. Also, the ROM you're playing is guaranteed to be your own and hence 100% legal.

@creaothceann: I have seen more .smc than .sfc files. As long as the emulator finds the metadata field at address 0x7FC1, you can name your file hans.wurst and it should not matter. Besides, I don't think there is an "official" suffix. That said, I guess I will go and change the extension to .sfc, which does make more sense.
Thank you for the list of special chip games. Looks like there is a lot more SA-1 going on than I expected. I guess I'll leave this as a little exercise to the community after I release the source of the firmware

@badinsults: Glad to hear the Mash Mods causes a little trouble from time to time. So there is a future for the snega2usb after all No, really: if a game doesn't work at the first attempt, it might simply be a mechanical problem. I am getting this all the time; can't wait to get my hands on the proper connectors (the ones that will be part of the final version). Now if it still doesn't work, chances are that there is something fishy about the memory mapping. The loading of the game is usually verified using the checksum, a feature most emulators support. Loading times are reasonably fast: a 16Mbit cart gets read in 3-4 seconds, so it doesn't take too long to find out whether a game works or not.

@paulguy (and whicker): The files are named according to the name field. In order to distinguish between different regional versions with the same name, I am also adding the checksum: SUPERMARIOWORLD__E5D2.smc (or so). Since I have no Japanese titles, I have not run into Kanji/Kana characters yet. If anything, I would translate these to Unicode instead of transliterating them to Roman letters.

@whicker: The snega2usb will come in an enclosure so you can go ahead and place it on metallic parts...

[kode54]

If anything, I would translate these to Unicode instead of transliterating them to Roman letters.

Excellent, that may motivate some Windows emulator authors to add support for Unicode file paths to their emulators. As opposed to, say, setting the system default codepage to Shift-JIS so they work with the ANSI file functions.

(Yes, I realize that FAT long filenames are UTF-16, even though Win9x doesn't actually support the CreateFileW function... Or does it?)

[grinvader]

2) How do you handle the names of Japanese games? The ASCII set goes above character 127, but gladly only is still one byte, but there could be a literal translation, like カ being KA, or マ リ オ being MA RI O. Don't know if you support long filenames...

@paulguy (and whicker): The files are named according to the name field. In order to distinguish between different regional versions with the same name, I am also adding the checksum: SUPERMARIOWORLD__E5D2.smc (or so). Since I have no Japanese titles, I have not run into Kanji/Kana characters yet. If anything, I would translate these to Unicode instead of transliterating them to Roman letters.

The japanese characters you will encounter that way belong to the half-width katakanas block (ｱｲｳｴｵ). They are encoded using sjis, so they are one-byte large, using the extended ASCII room $A1 to $DF. No kanjis.

(Yes, I realize that FAT long filenames are UTF-16, even though Win9x doesn't actually support the CreateFileW function... Or does it?)

You have to use the weird ansi-forcing functions for that in win9x, iirc. And then of course handle all the byte manip yourself.

[creaothceann]

I don't think there is an "official" suffix.

Developers sent their ROM images on DOS-formatted floppy disks to Nintendo, and the file extension was supposed to be .sfc.

If you have no concerns about looking at official documentation, you can read about it here: link

[Matthias_H]

If you have no concerns about looking at official documentation, you can read about it here

Wow. I did not even know about this document. Another thing learned, thank you.

[byuu]

Excellent, that may motivate some Windows emulator authors to add support for Unicode file paths to their emulators.

Try using a Japanese name for your Windows profile, not even Winamp or Firefox will run at all (they use appdata/). Quite sad.

That said, I'd be somewhat careful for Linux. Does its FAT driver convert UTF-16 to UTF-8, the standard format for Linux filenames?

I'm also not personally aware of any commercial titles with kanji, hanzi or hangul in them, but I'm sure they exist. Still, unicode would be nice for the half-width katakana to work everywhere.

The files are named according to the name field. In order to distinguish between different regional versions with the same name, I am also adding the checksum: SUPERMARIOWORLD__E5D2.smc (or so)

That's good, it's possible some carts, especially protos, will have a name of all 0x00s or 0xffs. The __checksum part will make sure we don't end up with .sfc alone -> hidden files on Linux and maybe Mac.

1) Are you including rubber feet for the 4 corners of the reader? Would seriously cut down on reports of failures because of coins, spills, etc.

I know it'd add a lot to the cost, but it really should be encased somehow. Even if it has to be hand-cut and glued polycarbonate or something.

[creaothceann]

If you have no concerns about looking at official documentation, you can read about it here

Wow. I did not even know about this document. Another thing learned, thank you.

No problem.

Oh, and here's also a list saved from Nach's site when it was online: link
It has some info about detecting special games by header bytes.

And you could use NSRT (link) to test with something more reliable than header checksums. (How about using CRC32 in the file names?)

[grinvader]

I'm also not personally aware of any commercial titles with kanji, hanzi or hangul in them, but I'm sure they exist.

I'm sure they don't. Seriously, even the titles where storing the name in kanji would have used less bytes have them in katakanas in the internal header (like "CHAOS SEED ﾌｳｽｲｶｲﾛｳｷ").
Might even be a guideline from the big N.

[Matthias_H]

And you could use NSRT (link) to test with something more reliable than header checksums. (How about using CRC32 in the file names?)

Well, first of all, the checksum is only included in the name for uniqueness, so using CRC32 would be a total overkill.

Then, of course I could do some serious testing, but how much of a problem really are checksum tests in practice? I don't know much about problems with emulators and checksums, but my guess would be that most of them stem from the fact that, given an arbitrary ROM file that comes your way, you can't really tell if it is a clean, unmodified rip or something odd that has gone through various stages of modification, watermarking etc.
There should be a lot less trouble when you obtain your data directly from a commercial cartridge, where you know it has been through all the Nintendo authorization process.

[Eyedunno]

I just have to say that this thing is awesome. I won't be buying one, since I've already bought the Mash Mods device for backing up my surviving savegames (all I really wanted to do), but this will doubtlessly be a nicer unit.

All I'm waiting for now is a decent multi-ROM flashcart to totally remove any worry of SRAM loss. The first person/company to come out with a flashcart that stores at least 128 megabits (and 256 megabits is way more than enough for my purposes - I have only nine games totalling 124 megabits that I really want this for) and uses only USB (or removable flash media) will get my business. Given how long they took on the Megadrive front, it seems less and less likely that this will be Neoflash, and more and more likely that this will be Mash Mods again (who are apparently working on such a device).

But I digress. Best of luck on this, Matthias!