snega2usb: USB Reader for SNES / Sega Genesis Cartridges
Moderator: ZSNES Mods
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
snega2usb: USB Reader for SNES / Sega Genesis Cartridges
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
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
Last edited by Matthias_H on Mon Aug 10, 2009 7:04 pm, edited 1 time in total.
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?
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?
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
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.byuu wrote: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.
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.byuu wrote: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.
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
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.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.
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.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.
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.
-
- "Your thread will be crushed."
- Posts: 1236
- Joined: Wed Jul 28, 2004 1:49 am
- Location: Not in Winnipeg
- Contact:
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.
<pagefault> i'd break up with my wife if she said FF8 was awesome
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
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.badinsults wrote:Sounds pretty similar to the Mash Mods USB reader
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" featurebadinsults wrote: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.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.
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 :)
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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
- 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
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
.WADGil_Hamilton wrote:Official? I wasn't aware Nintendo had an officially-sanctioned file extension for SNES dumps.
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.
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
Arguably, a generic .bin is the most logical.byuu wrote:.WADGil_Hamilton wrote:Official? I wasn't aware Nintendo had an officially-sanctioned file extension for SNES dumps.
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.
But that has obvious convenience issues.
-
- "Your thread will be crushed."
- Posts: 1236
- Joined: Wed Jul 28, 2004 1:49 am
- Location: Not in Winnipeg
- Contact:
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.Matthias_H wrote: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.badinsults wrote:Sounds pretty similar to the Mash Mods USB reader
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?Matthias_H wrote: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" featurebadinsults wrote: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.
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.
Last edited by badinsults on Tue Aug 11, 2009 4:21 am, edited 1 time in total.
<pagefault> i'd break up with my wife if she said FF8 was awesome
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...
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...
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
One for all
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...
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...
Re: One for all
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.Matthias_H wrote:If anything, I would translate these to Unicode instead of transliterating them to Roman letters.
(Yes, I realize that FAT long filenames are UTF-16, even though Win9x doesn't actually support the CreateFileW function... Or does it?)
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Re: One for all
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.Matthias_H wrote:@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 wrote: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...
You have to use the weird ansi-forcing functions for that in win9x, iirc. And then of course handle all the byte manip yourself.kode54 wrote:(Yes, I realize that FAT long filenames are UTF-16, even though Win9x doesn't actually support the CreateFileW function... Or does it?)
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
Re: One for all
Developers sent their ROM images on DOS-formatted floppy disks to Nintendo, and the file extension was supposed to be .sfc.Matthias_H wrote:I don't think there is an "official" suffix.
If you have no concerns about looking at official documentation, you can read about it here: link
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
Try using a Japanese name for your Windows profile, not even Winamp or Firefox will run at all (they use appdata/). Quite sad.Excellent, that may motivate some Windows emulator authors to add support for Unicode file paths to their emulators.
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.
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.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)
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.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.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
No problem.Matthias_H wrote:Wow. I did not even know about this document. Another thing learned, thank you.If you have no concerns about looking at official documentation, you can read about it here
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?)
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
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 フウスイカイロウキ").byuu wrote:I'm also not personally aware of any commercial titles with kanji, hanzi or hangul in them, but I'm sure they exist.
Might even be a guideline from the big N.
Last edited by grinvader on Tue Aug 11, 2009 6:26 pm, edited 1 time in total.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Rookie
- Posts: 11
- Joined: Mon Aug 10, 2009 3:57 pm
- Location: Saarbrücken, Germany
- Contact:
Well, first of all, the checksum is only included in the name for uniqueness, so using CRC32 would be a total overkill.creaothceann wrote: And you could use NSRT (link) to test with something more reliable than header checksums. (How about using CRC32 in the file names?)
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.
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!
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!