TapeDump v1.0 - a tool to dump carts without extra hardware
Moderator: Moderators
-
infiniteneslives
- Posts: 2100
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
I wouldn't expect it to happen. Not that it's not a good idea or anything, I just don't see why he'd bother with it.Jagasian wrote:How long before RetroUSB sells a "CopyNES Lite"? It would be a device similar to the Game Genie, but with a TapeDump bootloader. That way your NES would not need to have its lockout chip disabled, you wouldn't have to mod a Game Genie, and you wouldn't have to hot swap cartridges.
If it was compatible with the NES clones that are common place these days, it would make dumping accessible to many more people.
A couple things:B00daW wrote:Chris Covell:
Hope I'm not too late, but you may wish to grab your plugins from BootGod's website. They are the most up-to-date and some of Kev's previous plugins are fixed for better cart compatibility.
http://bootgod.dyndns.org:7777/plugins.php
Another note of interest... If you take a look at the TC-112.BIN plugin for NTDEC carts, I'm wondering if TapeDump would be a viable dumping method for it. I have a War in the Gulf cart that I could try dumping to see if it would be a good alternative to the CopyNES; since I also was not able to dump it with the CopyNES.
Kev,
I know we talked about the theory behind why the 74LS00 IC's made it difficult for the CopyNES to dump its CHR, but the conclusion escapes me, do you remember why?
Also how common are 74LS00's in NES carts, and could TapeDump -- if proven to be a viable alternative -- be an alternative solution for dumping such carts in the future?
Does bootgod have source code up for the plugins he modified? I remember awhile back using someone else's plugins but they did not include source, and one of them ended up being buggy on top of it.
The "7400" chip (quad NAND) is found in many carts, but war in the gulf used it in an odd way. I think my consensus about it was that it works by the grace of god. Rendering and reading via 2007 use two separate state machines, with different timing. This is most likely why copynes cannot read the cartridge's CHR ROM properly. The 2007 read/write is slower than rendering reading by at least 1.5x
That game is the only one I know of that uses that funky ROM enabling setup which shouldn't work very well (and turns out it really doesn't).
There is no alternative to dumping carts like this, except desoldering the ROMs. The hardware's pretty much undumpable otherwise. Something like this but more refined would make "undumpable" cartridges maybe, hehe. (at least CHR wise, without desoldering the ROM). It'd be kinda dicey too, since ROM speed would come into play I think.
/* this is a comment */
Cool, I'm glad someone kept the copynes fires burning all these years besides me. Ironically, I cannot use my copynes any more because I had to swap out my mobo and the parallel port doesn't work with copynes any more. blah. oh well, I guess it gives me an excuse to figure out once and for all, why. I did do a little bit of poking and determined that I don't think it's 3.3V logic levels.BootGod wrote:Yep, all sources are available on page boodaw linked. Not sure if you've used any of mine before, though wouldn't be surprised if they coulda had bugs, I still find and fix them from time to time.
/* this is a comment */
I'm working on the mappers, but as a side-topic, I'm also trying to get a higher dumping speed while staying in KCS spec. I know some suggested other methods, but I was hoping to keep the dumping conforming to some well-supported format (thus Supercharger is out).
The KCS08 program works well, but has low tolerance for speed and offset variance. I'm trying to get the bps up to 2400 and 5200 by halving (or more) the 1200/2400 hz delay loops, and having the user record at 44100 or 96000 hz, running such files as-is into the 22050 Hz-only KCS decoder.
Unfortunately, it's not working great. The NES' uh.... capacitance?... tendency to leak back to inverted 0V offset in its digital channel makes low Hz tones much louder than high Hz tones. Plus everything wants to leak back to 0V (or whatever) too fast, skewing the waveform, meaning no dumping at 5200 bps, and slightly buggy dumping at 2400.
Am I imagining this, or is this an actual property on the NES? Any way to correct it?
The KCS08 program works well, but has low tolerance for speed and offset variance. I'm trying to get the bps up to 2400 and 5200 by halving (or more) the 1200/2400 hz delay loops, and having the user record at 44100 or 96000 hz, running such files as-is into the 22050 Hz-only KCS decoder.
Unfortunately, it's not working great. The NES' uh.... capacitance?... tendency to leak back to inverted 0V offset in its digital channel makes low Hz tones much louder than high Hz tones. Plus everything wants to leak back to 0V (or whatever) too fast, skewing the waveform, meaning no dumping at 5200 bps, and slightly buggy dumping at 2400.
Am I imagining this, or is this an actual property on the NES? Any way to correct it?
In the early 8-bit microcomputer days, storage systems based on a tape modem and communications based on a telephone modem ran at fairly slow speeds. Later storage systems upgraded the physical medium to a faster disk, but communication was still limited by the incumbent physical medium of POTS, so phone modem makers researched more sophisticated methods to pack more data into the POTS channel.
The old phone modems and old tape modems used frequency shift keying, the extreme case of frequency modulation (FM). Later phone modem standards used quadrature amplitude modulation (AM with two carriers 90 degrees out of phase), which is twice as fast as plain FM or AM. They also used forward error correction, which adds extra information to a signal by treating it as a polynomial over a finite field.
There is a way to cancel out the frequency response of the NES audio path, and it's called deconvolution. On the NES, generate some narrow pulses before the dump begins. On the PC, deconvolve the signal with these pulses. Modem DSPs have been deconvolving received signals for a long time.
The old phone modems and old tape modems used frequency shift keying, the extreme case of frequency modulation (FM). Later phone modem standards used quadrature amplitude modulation (AM with two carriers 90 degrees out of phase), which is twice as fast as plain FM or AM. They also used forward error correction, which adds extra information to a signal by treating it as a polynomial over a finite field.
There is a way to cancel out the frequency response of the NES audio path, and it's called deconvolution. On the NES, generate some narrow pulses before the dump begins. On the PC, deconvolve the signal with these pulses. Modem DSPs have been deconvolving received signals for a long time.
Okay, here's a newer version that dumps entire carts, but it's a work-in-progress. (NROM, AxROM, MMC1, MMC3 supported.)
http://www.chrismcovell.com/data/TapeDump_V050.zip
I used Kevin Horton & BootGod's CopyNES plugins for mapper dumping. It's possible simply to jump to the CopyNES code for a full dump from my program, but the dumping format would be the CopyNES' one. Since I wanted to be able to dump just PRG, just CHR, just a header & vectors, or also a proper iNES file, I had to make each part into a subroutine. Also, since figuring out an iNES header means calculating PRG/CHR/SRAM size before dumping anything, I had to move those off into separate subroutines too.
But anyway, my dumping program sends these requests by jumping to a jump table at $0400, and the rewritten CopyNES code does the rest, accessing a couple of my functions in turn. So anyone could add another mapper if they're in a real hurry; just remember to move things around as in the example mappers.
The controls are explained on-screen, basically. Choose a mapper with U,D, and press A to continue. After swapping carts, you can press A several times to check that the program is still running normally.
Next, you might want to check that the cart is inserted correctly by pressing B, which sends a 16-byte iNES header with PRG, CHR count, and 48 bytes from $FFD0-$FFFF showing the cart vectors (and even the name in many cases). If it all looks good, press Start to dump the whole cart. If the integrity is intact, the resulting dump can be run as a regular .NES ROM.
Dumping times for the average cartridge:
________300_600_1200_2400_5200 bps
128K ROM 80m 40m 20m 10m 4m41s
256K ROM 160m 80m 40m 20m 9m
Note about the bps rate: 300-1200 bps are "standard" in the KCS format, and can be recorded at 22050 Hz, 8-bit, as the KCS08 program requires. The 2400 and 5200 bps rates are experimental and thus less reliable. For 2400, you should record at 44100 Hz and save the audio file at that sample rate (save as 8-bit for the KCS program.) KCS08 requires a 22050 Hz file, but at twice the pitch and twice the sample rate, it's fooled into thinking it's a regular 1200 bps dump. Same goes for the 5200 bps. Record at 96000 Hz, and save the file at that rate.
The 2400 and 5200 bps audio quality is not optimal, due to the frequency response of the NES, so you will probably have to have a nice, quiet audio line for recording. Watch out (in a waveform editor) for spikes in amplitude between the 5-second continuous tone and the data stream, as this might introduce unwanted bits in the data. Also, if KCS gives you a big fat error, try using the -G2 switch to help with the pitch adjustment, and -F10 or -F20 to help readjust the DC offset.
Let me know how dumping works for you.
http://www.chrismcovell.com/data/TapeDump_V050.zip
I used Kevin Horton & BootGod's CopyNES plugins for mapper dumping. It's possible simply to jump to the CopyNES code for a full dump from my program, but the dumping format would be the CopyNES' one. Since I wanted to be able to dump just PRG, just CHR, just a header & vectors, or also a proper iNES file, I had to make each part into a subroutine. Also, since figuring out an iNES header means calculating PRG/CHR/SRAM size before dumping anything, I had to move those off into separate subroutines too.
But anyway, my dumping program sends these requests by jumping to a jump table at $0400, and the rewritten CopyNES code does the rest, accessing a couple of my functions in turn. So anyone could add another mapper if they're in a real hurry; just remember to move things around as in the example mappers.
The controls are explained on-screen, basically. Choose a mapper with U,D, and press A to continue. After swapping carts, you can press A several times to check that the program is still running normally.
Next, you might want to check that the cart is inserted correctly by pressing B, which sends a 16-byte iNES header with PRG, CHR count, and 48 bytes from $FFD0-$FFFF showing the cart vectors (and even the name in many cases). If it all looks good, press Start to dump the whole cart. If the integrity is intact, the resulting dump can be run as a regular .NES ROM.
Dumping times for the average cartridge:
________300_600_1200_2400_5200 bps
128K ROM 80m 40m 20m 10m 4m41s
256K ROM 160m 80m 40m 20m 9m
Note about the bps rate: 300-1200 bps are "standard" in the KCS format, and can be recorded at 22050 Hz, 8-bit, as the KCS08 program requires. The 2400 and 5200 bps rates are experimental and thus less reliable. For 2400, you should record at 44100 Hz and save the audio file at that sample rate (save as 8-bit for the KCS program.) KCS08 requires a 22050 Hz file, but at twice the pitch and twice the sample rate, it's fooled into thinking it's a regular 1200 bps dump. Same goes for the 5200 bps. Record at 96000 Hz, and save the file at that rate.
The 2400 and 5200 bps audio quality is not optimal, due to the frequency response of the NES, so you will probably have to have a nice, quiet audio line for recording. Watch out (in a waveform editor) for spikes in amplitude between the 5-second continuous tone and the data stream, as this might introduce unwanted bits in the data. Also, if KCS gives you a big fat error, try using the -G2 switch to help with the pitch adjustment, and -F10 or -F20 to help readjust the DC offset.
Let me know how dumping works for you.
I haven't tried myself, but here's the first thing I'd try:
The AOROM dump routine might be able to dump mapper 34 (BxROM). If so, it can probably dump UNROM (not UOROM), producing an overdump compatible with mapper 34 (BxROM). Then you can correct the dump by dropping half of each 32 KiB bank: the second half for mapper 2 or the first half for mapper 180.
The AOROM dump routine might be able to dump mapper 34 (BxROM). If so, it can probably dump UNROM (not UOROM), producing an overdump compatible with mapper 34 (BxROM). Then you can correct the dump by dropping half of each 32 KiB bank: the second half for mapper 2 or the first half for mapper 180.
(NROM, AxROM, MMC1, MMC3 supported.)Dwedit wrote:Does it do UxROM or CNROM?
I wonder if it's safe to hotswap a cartridge with save ram?
It's not safe to hotswap, period, as my disclaimer said. I dumped my Zelda cart and had to swap the cart in maybe 6 times, and my save file was still intact. Your mileage may vary.
This seems to have been offline for several days now. Does anyone have a backup server?B00daW wrote:http://bootgod.dyndns.org:7777/plugins.php
Do you plan to explore the Game Genie replacement ROM for dumping without hot swap?ccovell wrote:(NROM, AxROM, MMC1, MMC3 supported.)Dwedit wrote:Does it do UxROM or CNROM?
I wonder if it's safe to hotswap a cartridge with save ram?
It's not safe to hotswap, period, as my disclaimer said. I dumped my Zelda cart and had to swap the cart in maybe 6 times, and my save file was still intact. Your mileage may vary.
