In preparation of “mass production” (this sounds a bit weird for a project that started 6 weeks ago, doesn’t it?), I have decided to freeze the current set of hardware features. The firmware will of course be improved further, and there’s more SNES testing coming up soon. Let’s have a quick look at my personal check list, with some items added by popular request:
- Support reading of SNES and Genesis/MegaDrive ROMs (check)
- Detect removal/insertion of cartridge (check)
- Support simultaneous access to both slots (check)
- Support reading and writing of battery-buffered SRAM on SNES cartridge (check) Thanks to everyone who persuaded me to do this! This function is so cool…
- “Writable” root directory to make the operating system happy (check) No more complaints about read-only files…
So it looks as if most of the development is actually complete. The next step will be to source suitable parts, and to contact potential OEMs. Especially the SNES connectors are actually a bit hard to get hold of because of their unusual pitch (0.098″ or 2.50mm). Also, I want to get proper ones that are made for game consoles and specified for a zillion insertion cycles, instead of scraping the metal from your precious carts.
One remaining issue is that there will be no save state support for Genesis cartridges. Sorry folks, but after doing a little research I think it’s just not worth the hassle for a handful games. Hackers may still figure out how to do it and add this functionality later on.
Actually, it’s about time for another video demoing the current prototype with a couple of games. Maybe next week, so stay tuned. Also, at some point I will have to dig through the huge pile of contest submissions. If you have any more good ideas, keep ‘em coming till I close the gate :-)
Now that I think about it, showing the checksum value as the file name and having a supplemental text file is the BEST way to do this.
For example, the same game from a different region might have the same internal header name. This would cause conflicts with saved progress data, save states, recorded movies (save state + input events), cheat files, etc.
For quick identification, the text file could be named after the internal header name (ie: “SUPER MARIOWORLD.TXT”).
-Ichinisan
I have now chosen the name + checksum way: e.g. SUPERMARIOWORLD__E5D2.smc, so all ROM and SRAM file names should now be unique and free of special characters, while remaining human-readable. For Japanese titles, we still have the checksum :-)
That’s too bad about the feature freeze. I’ll go ahead and make my suggestions anyway…
I would actually prefer if the SNES / Genesis features were split into two SEPARATE products. Each should have ONE cartridge slot and TWO controller ports.
I realize that this would be like starting a second project from scratch, because you may not already have experience creating USB HID-compliant game controllers…but this would REALLY seal the deal and make this a must-buy product. Most people already want to use their favorite authentic controller / joystick with their emulators. My Ascii Fighter Stick SN, Fighter Stick SG, Capcom Pad Soldier (By Ascii), Capcom arcade stick, and AsciiPad (SNES) would all get some serious play-time if I could easily connect them to my PC!
I was reunited with my NES Advantage earlier this week and I have played for HOURS AND HOURS on my original NES. This is the only joystick I use with platformers like Super Mario Bros 3, and it’s BETTER than using a gamepad! Nothing else even comes CLOSE (though I haven’t tried the SNES Super Advantage, by Ascii).
I realize that asking for a direct-access controller API for emulators may be too much to expect…but I’d be happy anyway if the device simply allows me to use two regular controllers with my PC.
Also, if there was a tiny amount of writable storage on the device, you could store your emulator of choice on the device along with controller configuration settings, saved states, cheats, etc. An “autorun.inf” file could be generated automatically, and it would launch the emulator with a parameter specifying the .SPC filename.
This would be an AMAZING experience for newcomers to console emulation.
Please tell me: Is an “autorun.inf” file understood by operating systems other than Microsoft Windows? Even if it’s not supported in Linux / OSX / etc, I’m sure those operating systems would just ignore it and everything else would function just the same.
If the automatically-generated “headername”.spc causes problems with foreign games, etc…it might make sense if the game name always shows up as the unique checksum value “XXXXXXXX.SPC”. This way, each game would have a unique name and would always match up with its own SRAM saves, screenshots, recorded movies, and save states. In addition to the SPC and SRM files, a third file could appear in ASCII text format that contains readable information about the game, such as the internal ROM header information, size, etc. I believe the ROM’s internal header can identify the developer, region, size, checksum, title, co-processor type, etc.
-Ichinisan
I just added a bunch of extra pins to accommodate SNES connectors. This might turn out a really nice DIY-capable extension…
Unfortunately, the connectors themselves are a pain to get hold of. You’d have to disassemble multitaps from eBay, which is not much of an option on an industrial scale :-)