Props to innovating a solution. But since this is SNES related ...
I've been working with people over the years on an SNES<>PC interface. Idea being, you could dump SNES games from the cartridge port to the PC. Or you could upload hardware diagnostic/test programs (for emulator development) from the PC to the SNES, and then read back the results to the PC for analysis. Or just do crazy stuff like linking multiple SNES units together, support netplay on real hardware, download an unlimited amount of game level content, mix in audio from the PC via SNES commands, etc.
We started with the SNES controller port and used bit-banging code to a MAX232N, and connected the other serial end to a PC serial<>USB adapter. This worked out to around ~4KiB/s that we could transfer.
After that, I moved to a TTL-232R-5V cable, and spliced it directly to an SNES controller. Same speed, but a lot less bulky.
The speed killer was having to bit-bang everything. The SNES has DRAM refresh cycles that stall out the CPU for a short duration on every scanline, so that greatly impedes the maximum baud rate you can bit-bang at.
Then I found out about the Teensy, which has a synchronous UART mode. Just connect another line that you strobe when new data is available on your pin. They have software drivers that simulate USB serial UART, so you just compile that in and flash it onto the chip. This got us up to around ~30KiB/s, but that was still rather slow.
Finally, we moved on to targeting the expansion port on the bottom of the SNES. It exposes the entire 8-bit data bus. And so we connected that to an FT232H board, which has built-in 1024-byte smoothing buffers in each direction. From the SNES' perspective, it's just like a parallel port. From the PC's side, it's just like a virtual COM port. This lets us hit ~160KiB/s in both directions, and that's with code to verify data is available/can be sent from both ends of the connection on every single byte transferred either way.
The device itself is actually USB high-speed, so we could max out the SNES' 2.68MiB/s transfer rate, but we would lose the ability to ensure data or buffer space was available during DMA transfers, so it wasn't as reliable to do that.
...
Moving on to the Super Wild Card ... that thing is just a relic. It's unable to dump games that use the SA-1 coprocessor (Mario RPG, Kirby Super Star, etc), or memory map controllers (Star Ocean, Tengai Makyou Zero, etc), making it quite limited.
The device we've built can dump games over a USB interface. Takes about ~20 seconds a game, and can dump absolutely every game in the library. And the dumper is written in pure C/C++. About 200 lines of code to support every possible cartridge type.
When it comes to playing games, the SWC can't play anything with any coprocessors (all the aforementioned games; plus DSP games like Super Mario Kart, Pilotwings, Top Gear 3000, etc) [well, some of these copiers supported DSP-1 pass-through, not sure if the original SWC supported that or not]. On this front, the sd2snes is a vastly superior solution. You can put the entire SNES game collection onto a micro SD card, and run anything the SWC can, plus the DSP games as well.
All the same, even if it's not the optimal solution, I still give props to the author of this hack. It's definitely cool to restore these old copiers, if just for the novelty factor. I'm reminded of a guy who built his own SWC DX2 CD-ROM drive interface for loading games, because the CD drives are much less common.
The original Super Wild Card can actually play DSP games if you have a DSP cart inserted. It's the only enhancement chip that will work with pass-through on the SWC. Of course the sd2snes is a superior solution but we didn't have that 20 odd years ago when the SNES was still in its prime. ;) I've contemplated getting an sd2snes but my 32Mb SWC (original model, pre DX) is still working great after all these years and runs probably over 95% of available games. sd2snes doesn't actually support that many enhancement chips yet so I don't it's worth the investment over what I've already got. I'll probably end up getting one when more chips are supported.
I must say that your SNES<>PC interface sounds great. Do you have a website with more information?
Oh awesome, so the original SWC supported DSP pass-through as well? Thought that was a SWC DX2 feature only (the 'Rolls Royce of SNES copiers.') Super UFO actually had a NEC uPD DIP socket you could connect to its mainboard for DSP-1 support.
The chips that could never work with that design would be the SA-1, SuperFX, S-DD1, SPC7110, MCC, and ICD2 (Supe Game Boy.) These coprocessors sit between the SNES bus and the ROM/RAM, but copiers can only sit between the cartridge and the bus, so you won't be able to substitute the game mask ROMs inside the cart.
> sd2snes doesn't actually support that many enhancement chips yet so I don't it's worth the investment over what I've already got.
It does all the firmware-based ones we dumped except for the ST011/ST018 (two Japanese chess games.) So that's DSP-1/1B/2/3/4, ST010, Cx4. But so far, nothing does SA-1, SuperFX, S-DD1, SPC7110. I think the sd2snes could do the latter two, but so far it does not. ikari has been working on either SA-1 or SuperFX, but I don't think it's panned out thus far. Those two are more complex individually than the entirety of an NES.
I'm not sure if it does OBC1 or not. Nobody seems to care either way about poor Metal Combat ;)
> Of course the sd2snes is a superior solution but we didn't have that 20 odd years ago when the SNES was still in its prime.
Undoubtedly. I would have killed for a parallel port copier back in '04. I spent about 5-6 years developing an emulator using a Super UFO 8.3j that I paid $250 for in '01. Every time I assembled a new hardware test, I had to run this old DOS tool to generate a valid Super UFO copier header, split the game into 1MiB chunks to fit on a series of 1-4 floppy disks. Then I had to load each floppy onto the UFO, run the test, power cycle the UFO, put another floppy in, go through the menu to copy the save RAM back to the disk, then copy that file back to the PC for analysis. It took me about 10-20 minutes (floppy disks are slow) per hardware test. And I must have done over a thousand of them.
If I weren't poor back then, I'm sure I would have tried to purchase a parallel-port copier.
Byuu, if you wrote a book on all the SNES hacking and development you (and others) have done, I'd definitely buy it and read it. Thank you for all of your work.
I've always wanted to write a book that contained every last minutiae about the hardware titled, "Everything you never wanted to know about the SNES, thus you didn't bother to ask."
The problem is that it's been so long since I've had to work extensively on the emulation core, that I'm starting to forget a lot of this stuff as well >_<
That is alla amazing, and very impressive. Thanks for doing it all, and sharing.
A super-picky note from the embedded developer corner: a serial port with a clock signal is not asynchronous, so the "A" in UART becomes wrong.
Peripherals capable of doing both, which are common on modern microcontrollers, are often called USARTs, which of course means universal synchronous/asynchronous receiver/transmitter. Other names for more fancy capabilities are also common.
> I always thought it should be called USRT when strictly synchronous, but indeed, everyone else called it USART, so I called it the "USART controller"
Because the chips that do synchronous serial IME also do asynchronous, hence USART. Which makes sense: asynchronous is a far more widely accepted and used protocol, so one chip-placement covers connecting to those devices as well.
I've been working with people over the years on an SNES<>PC interface. Idea being, you could dump SNES games from the cartridge port to the PC. Or you could upload hardware diagnostic/test programs (for emulator development) from the PC to the SNES, and then read back the results to the PC for analysis. Or just do crazy stuff like linking multiple SNES units together, support netplay on real hardware, download an unlimited amount of game level content, mix in audio from the PC via SNES commands, etc.
Here's the history: http://i.imgur.com/ucxVbJa.jpg
We started with the SNES controller port and used bit-banging code to a MAX232N, and connected the other serial end to a PC serial<>USB adapter. This worked out to around ~4KiB/s that we could transfer.
After that, I moved to a TTL-232R-5V cable, and spliced it directly to an SNES controller. Same speed, but a lot less bulky.
The speed killer was having to bit-bang everything. The SNES has DRAM refresh cycles that stall out the CPU for a short duration on every scanline, so that greatly impedes the maximum baud rate you can bit-bang at.
Then I found out about the Teensy, which has a synchronous UART mode. Just connect another line that you strobe when new data is available on your pin. They have software drivers that simulate USB serial UART, so you just compile that in and flash it onto the chip. This got us up to around ~30KiB/s, but that was still rather slow.
Finally, we moved on to targeting the expansion port on the bottom of the SNES. It exposes the entire 8-bit data bus. And so we connected that to an FT232H board, which has built-in 1024-byte smoothing buffers in each direction. From the SNES' perspective, it's just like a parallel port. From the PC's side, it's just like a virtual COM port. This lets us hit ~160KiB/s in both directions, and that's with code to verify data is available/can be sent from both ends of the connection on every single byte transferred either way.
The device itself is actually USB high-speed, so we could max out the SNES' 2.68MiB/s transfer rate, but we would lose the ability to ensure data or buffer space was available during DMA transfers, so it wasn't as reliable to do that.
...
Moving on to the Super Wild Card ... that thing is just a relic. It's unable to dump games that use the SA-1 coprocessor (Mario RPG, Kirby Super Star, etc), or memory map controllers (Star Ocean, Tengai Makyou Zero, etc), making it quite limited.
The device we've built can dump games over a USB interface. Takes about ~20 seconds a game, and can dump absolutely every game in the library. And the dumper is written in pure C/C++. About 200 lines of code to support every possible cartridge type.
When it comes to playing games, the SWC can't play anything with any coprocessors (all the aforementioned games; plus DSP games like Super Mario Kart, Pilotwings, Top Gear 3000, etc) [well, some of these copiers supported DSP-1 pass-through, not sure if the original SWC supported that or not]. On this front, the sd2snes is a vastly superior solution. You can put the entire SNES game collection onto a micro SD card, and run anything the SWC can, plus the DSP games as well.
All the same, even if it's not the optimal solution, I still give props to the author of this hack. It's definitely cool to restore these old copiers, if just for the novelty factor. I'm reminded of a guy who built his own SWC DX2 CD-ROM drive interface for loading games, because the CD drives are much less common.