New idea for a cart dumper, would it be useful?

[LocalH]

I was reading over at NESDev, and I saw where Chris Covell had released a dumping tool that only requires a non-copier way to run the dumping software on the system (dev cart, flash cart, etc) and an audio cable. It's called TapeDump. It works be loading the dumping software into RAM, revolving on an infloop (that polls for input) while executing from RAM, and requiring the user switch cartridges with the system on (which, granted, is a bit risky, but in situations like this where it can make dumping capabilities more widespread, it's worth it). We have the advantage of 64KB of RAM vs. the NES' 2KB (albeit with bigger code), fewer mappers to support (official SEGA banking and a few weird-ass pirate mappers), and 64KB of VRAM to load UI assets into (whereas the NES has none, carts either have CHR ROM or CHR RAM so one can't assume anything visually except for background color). Also, depending on the target MD's frequency response, the 5200bps dumping rate may be more reliable than on the NES.

I know we have MoD's transfer suite, but it requires a Sega CD. This concept could easily be cheaper than even that, and would require no manufacturing of any specific cables, just a standard audio cable works fine. If one wanted additional hardware, one could design a cart with a switch and a slot passthrough, that would remove the need to physically swap carts, thus being much safer for both carts and hardware. This could potentially also be used to dump MS carts on either an MS or MD. You could even make the MD version of the cart include the MS dumping software and another switch, and thus dump the "elusive" Phantasy Star MD *runs*

[Eke]

Using audio output is genius, though I don't know how much accurate the final dump can be this way (also depends on each console sound chip I guess).

Actually, I had a similar but simpler idea some time ago, using Everdrive SD access (it's managed through the !TIME signal). My idea was also to have code running from RAM, swap Everdrive with cartridge, then dump as much kB as possible to RAM (depends on remaining available size, could use Z80 RAM as well), swap Everdrive again, writes part to SD , swap cartridge back, etc...

Never even tried it as I thought all it would do is damaging the console or, more likely, my Everdrive (I even considered putting a switch to control the power signals on cartridge port when swapping). But in theory it should work, if you don't mind the long dumping process and merging all the ROM parts together at the end

It initially came up to me because available dumpers are generally compatible only with generic cartridges, which are quite all dumped anyway. Those unlicensed ones that remain undumped all use some banking hardware or uncommon 68k signals from the cartridge port, which makes a custom program running directly on console the only way to dump them, unless you have some kind of reprogrammable micro-controller.

[Charles MacDonald]

If one wanted additional hardware, one could design a cart with a switch and a slot passthrough, that would remove the need to physically swap carts, thus being much safer for both carts and hardware. This could potentially also be used to dump MS carts on either an MS or MD.

At the point where you start designing hardware, you can just make a stand-alone cartridge dumper.
MikeG made a version of the SMS Reader to dump MD cartridges so low-cost solutions exist.

You could even make the MD version of the cart include the MS dumping software and another switch, and thus dump the "elusive" Phantasy Star MD *runs*

I thought this had been dumped some years ago and was identical to the SMS version?

I think dumping data as audio is a great idea, and it is applicable to probably every system. Having to hot-swap the cartridges is risky though, so I can't see it as a method for people to use to dump rare games.

[LocalH]

Using audio output is genius, though I don't know how much accurate the final dump can be this way (also depends on each console sound chip I guess).

Yeah, it mostly depends on dumping speed (hence why the 2400 and 5200bps rates are problematic sometimes on the NES). It uses the KCS standard for storing data on audio cassette tapes, so the technology is robust and mature =P On an aside, the SC-3000 uses a 600 baud variant of KCS, not that it helps us at all but just an interesting footnote.

Actually, I had a similar but simpler idea some time ago, using Everdrive SD access (it's managed through the !TIME signal). My idea was also to have code running from RAM, swap Everdrive with cartridge, then dump as much kB as possible to RAM (depends on remaining available size, could use Z80 RAM as well), swap Everdrive again, writes part to SD , swap cartridge back, etc...

Never even tried it as I thought all it would do is damaging the console or, more likely, my Everdrive (I even considered putting a switch to control the power signals on cartridge port when swapping). But in theory it should work, if you don't mind the long dumping process and merging all the ROM parts together at the end

Yeah, that's a pretty ingenious idea as well, although it reminds me of copying a floppy on an original 128K Mac and running up against the bug where you have to swap about 20 or 30 times =P Dumping with TapeDump is quite slow anyway, even at 5200bps it takes 9 minutes to dump 256KB of ROM and now imagine us with our 4MB and more ROMs. Especially if we end up needing to use the 1200bps speed for reliability due to the audio frequency response. 2400 and 5200bps are essentially "hacks" where the audio is recorded at 44KHz and the pitch is increased such that the KCS decoder will accept it as a 22KHz file at normal speed.

It initially came up to me because available dumpers are generally compatible only with generic cartridges, which are quite all dumped anyway. Those unlicensed ones that remain undumped all use some banking hardware or uncommon 68k signals from the cartridge port, which makes a custom program running directly on console the only way to dump them, unless you have some kind of reprogrammable micro-controller.

That was exactly my thought in proposing the idea, after seeing Chris's project, since the NES already has tons of mappers and so his tool already supports a large number of cart boards.

At the point where you start designing hardware, you can just make a stand-alone cartridge dumper. Very Happy
MikeG made a version of the SMS Reader to dump MD cartridges so low-cost solutions exist.

Heh, yeah, I was kinda being facetious there in a way, thinking about how the idea could be enhanced if one did use additional hardware. It definitely would be much safer on the system, though, to have a cheap, all-pins-connected passthrough with two slots. Shouldn't even need any logic, maybe some buffers to help prevent the switch itself from introducing nastiness into the signals. As an aside, one could sell this device additionally as a way to get Sonic 3's level select active without having to swap carts *runs again, further*

I thought this had been dumped some years ago and was identical to the SMS version?

Yeah, I know, hence "elusive" in quotes, heh. I wouldn't ever expect to see a combo MD/MS unit for this purpose (especially since AFAIK, the only MD carts that have MS games on them are PSMD and I think I've seen a few pirate MD multis with MS games on them), but it could be useful for there to be an MS version too, which could run on any MS-compatible console. Although Bock, et al. tend to have that side of things very nicely covered for preservation's sake so that wouldn't be such a big deal. Could be handy in situations where someone with no knowledge of SMS Power comes across an undumped prototype or something.

I think dumping data as audio is a great idea, and it is applicable to probably every system. Having to hot-swap the cartridges is risky though, so I can't see it as a method for people to use to dump rare games.

Yeah, the ingenuity is very sound indeed. It reminds me of something I'd seen Chris do a while back. I can't remember for the life of me which ROM he actually dumped this way, but he wrote a program to actually display X number of bytes on-screen, in hex, with a checksum, and wrote a program to accept the hex input and the checksum, really similar to the old "program checkers" from the old computing mags to help people prevent errors from creeping into their typed-in listings.

The riskiness to the hot-swap method was the only reason I suggested a two-slot extension with a switch. Although when done properly, it's not that big of a risk IMO, some people may not wish to take that risk. I've actually hotswapped in my Sonic 3 EPROM cart to enable level select, without any problems

Another possibility, also requiring cart swapping but potentially higher-bandwidth would be to use the concepts of the old Amiga "video backup software", that would allow you to use a standard VCR and VHS tape to back up data. It did this by basically opening a 1-bitplane screen, using each chunk of X number of pixels as one bit, and checksumming each scanline appropriately. The beauty of using black and white "composite" video is that the device to read back the data into the Amiga was quite simple, only needing to sample the voltage of the signal (and the software can ignore the samples generated from the blanking [and color burst, should one be using an A1000 or A1200] but use them for synchronization). Perhaps something similar could be done for the Genesis, using the native video output in interlace mode (since we only care about the amplitude of the signal, the horrible chroma output won't matter, or one could hack together a custom video cable and treat any of the RGB lines as Y, leaving out C altogether and essentially making it monochrome) and then capturing it through something like a capture card or DVD recorder and extract the ROM by writing a program to analyze the individual video frames.

[Eke]

Heh, yeah, I was kinda being facetious there in a way, thinking about how the idea could be enhanced if one did use additional hardware. It definitely would be much safer on the system, though, to have a cheap, all-pins-connected passthrough with two slots. Shouldn't even need any logic, maybe some buffers to help prevent the switch itself from introducing nastiness into the signals.

I don't have much electronic knowledge on that side but wouldn't my idea of a switch that connect/disconnect VCC lines to the cartridge port works the same as the power switch, but with only the cartridge port switching OFF ? Or maybe additional signals on cartridge port need to be handled by that switch...

[TmEE co.(TM)]

When you need a cart to boot the machine you make a Sonic & Knuckles like lock-on cart which has your cart of interest sitting on top...

Audio out is fun idea, but I can imagine how slow it will be...

[HardWareMan]

Check it out! Soviet homebrew computer "Spetsialist" with manchester tape coding at 1200 bods Lode Runner game load simulation. :3

[Huge]

Audio dumping is a fun idea, but it needs a lot of checksumming and it's hella slow. The KOF95 cart for Saturn was dumped that way too a year or two ago.

However, you still need some way to load your code on the hardware. Which in our case would be a Sega CD or an Everdrive - For Sega CD, that would leave the cart slot open, so dumping could be done without swapping carts (provided that the Sega CD boot order allows for this, and it won't just run the cartridge instead).

And doesn't the Everdrive allow for writing to the memory cart? I don't see why it shouldn't be able to do that.

[HardWareMan]

And doesn't the Everdrive allow for writing to the memory cart? I don't see why it shouldn't be able to do that.

Here. Just upgrade my ECARD to hardware SPI machine.

[GManiac]

This idea is not new Not hot-switching of carts nor "audio dumping". For example,
http://www.emu-land.net/forum/index.php ... 1753.0;all
(in Russian).

[Chilly Willy]

This idea is not new Not hot-switching of carts nor "audio dumping".

Back in 1985, I put a switch on the /CART line of my other Atari 400 so that I could hot-switch carts for dumping. Flip the switch to "no cart", boot DOS, flip the switch to "cart in", and bsave the cart region. So, yes, hot-switching carts is OLD, but effective.

[Eke]

This idea is not new Not hot-switching of carts nor "audio dumping". For example,
http://www.emu-land.net/forum/index.php ... 1753.0;all
(in Russian).

I don't read russian, can you explain how this works ?

[HardWareMan]

In a nutshell, this device complete with a cartridge in which the control program allows you to load any program into console RAM and run it.

[tristanseifert]

Why use the audio out port? I'm pretty sure you could just use one of the MD's controller ports (or the EXT port on early model 1's) as an UART and hook that up to a PC's serial port. It'd be much more reliable, and you could probably get 9600 baud depending on how the code on the MD side is written.

[Chilly Willy]

Why use the audio out port? I'm pretty sure you could just use one of the MD's controller ports (or the EXT port on early model 1's) as an UART and hook that up to a PC's serial port. It'd be much more reliable, and you could probably get 9600 baud depending on how the code on the MD side is written.

That would be a good trick since the MD only does a max of 2400 baud on the serial lines.

But I agree with the rest - 2400 baud serial would be much better than trying to use the audio out. You could also make a parallel interface - that would give you maybe 30KB/sec.