Hi, folks. Last weekend, I received a Famicom Proto/Sample cart in the mail which had its EPROMs soldered to the game PCB, making the usual EPROM dumping a bit treacherous. So, after a little thought, I decided to write up a Famicom dumping program that sent cartridge data to a PC as an audio stream.
The dumping worked pretty well, so if this program sounds useful to anyone else, please feel free to try it out.
Explanation and controls are here:
http://www.chrismcovell.com/TapeDump_Controls.html
And the .NES ROMs (NTSC and PAL versions) and source are here:
http://www.chrismcovell.com/data/TapeDump.zip
Comments, complaints welcome.
ccovell wrote:
Hi, folks. Last weekend, I received a Famicom Proto/Sample cart in the mail which had its EPROMs soldered to the game PCB, making the usual EPROM dumping a bit treacherous. So, after a little thought, I decided to write up a Famicom dumping program that sent cartridge data to a PC as an audio stream.
The dumping worked pretty well, so if this program sounds useful to anyone else, please feel free to try it out.
Explanation and controls are here:
http://www.chrismcovell.com/texts/TapeD ... trols.htmlAnd the .NES ROMs (NTSC and (untested on hardware) PAL versions) and source are here:
http://www.chrismcovell.com/data/TapeDump.zipComments, complaints welcome. I was considering adding a menu front-end to automate dumping of a cart, but if few people really care, maybe I won't...
What a fantastic idea. I'd love to hear some of the results! Probably a bit like playing a data CD in an audio CD player? Or, more likely, listening to a 300baud modem communicating on a voice line.
EDIT: Just noticed the example WAV in the download. Wow what memories!
The Apple II cassette interface worked at about 1000 baud using frequency shift keying. I'd bet with a decent sound card, transfer rates comparable to a 56K modem would be feasible.
The page mentions the usual pak-swap gotchas:
- Interfacing with the game's NMI handler and CHR banks in order to detect the start of vblank in order to display the UI (avoided here by using solid colors)
- Having to cut pin 4 if using a front-loading NES
tepples wrote:
Interfacing with the game's NMI handler in order to detect the start of vblank in order to display the UI
For such a simple program I think you can get away with just disabling NMIs and polling $2002. I mean, since you can't rely on what's mapped to the CHR area you can't have much of an UI anyway.
Quote:
Having to cut pin 4 if using a front-loading NES
Yeah, no way around that, I guess. Although I imagine that if you are into activities like dumping carts you probably own a few consoles and wouldn't mind modding one of them.
Cool idea! Now if I only had any carts to dump...
thefox wrote:
Cool idea! Now if I only had any carts to dump...
I just dumped the dumper itself just to hear it.
I then thought about implementing a "Disable CIC" feature in nesicide so I could "insert a cartridge hot" and listen to dumps of some other ROMs.
Then I thought hell if I'm going that far, I mightaswell record the output of a ROM, pass it through the decoder he referenced, and see what kind of results I get.
Then I went off looking for my tape player to bring it even more retro.
Then the kids needed to go to bed so I got sidetracked.
Ahh well. ccovell, I am envious at the simplicity and beauty of your project. Nice work!
This is a crazy awesome idea. I may just have to try it out when I get a simple dev cart running.
I can confirm that the PAL-version works well on a PAL machine, just tried dumping Excitebike on my PAL NES and registered here just to tell about it.
With a cable connected directly to the stationary PC the 1200 bps option didn't work very well in the conversion process, had no problems at all with 600 or 300. Well, it's not hooked directly... there's some gadgets on the same line so if I had hooked it directly maybe the 1200 would have worked as well.
Just to make sure I got it out right I had another dump to compare with, the dumper then gave me four parts of PRG before repeating (as expected), I didn't really have to do anything. Assembling them though needed to be done 4+1+2+3 and the 8kB CHR part was dumped in one piece and added last - it ended up as an exact match to the dump I already had.
Nice to know that it works, I guess you would need to be somewhat of an expert to make good use of it if the cart you want to dump has any kind of a mapper or maybe some work could be done on the interface so you could choose a mapper before starting the dump with automatic switching of the areas getting all the data out at once would also be nice.
Super-great idea that requires almost no modification to the unit (I already had the CIC disabled and also a PowerPak) - I wish I had something odd to dump - I guess I can check if my own carts are the same as other known versions of course...
Very good idea and extremely well executed, works like a charm!
I agree that this may help dumping some of those rare carts that noone wants to open, solder on or send away. I'm not much of a NES-guy myself but it's a small part of my overall collection - and hacking is always fun!
EDIT:
Tried it again and pushed out all four parts of the PRG into the sampler program on the PC without stopping in between and then ran all of them through KCS08. Apart from the $C0, 00 first I got the entire 16kB in one go.
This is a pretty nifty creation. Could it be combined with the Game Genie hack that was made awhile back to avoid swapping and the need to disable the lockout?
Tried the 1200 bps again on my PAL-machine, no problem at all with a direct connection. The entire Excitebike cart dumped in less than 5 minutes.
This is brilliant, thank you.
Does it support any mappers?
It says in the texts that it's built for the "Konami VRC2" mapper so I guess it supports that and similar ones (if any). Currently you have to add other mappers yourself, let's hope ccovell wants to add a nice front end and some mappers in a future version.
Such a "nice front end" would probably have to involve autodetecting the mapper and then searching CHR ROM for a blank tile and a solid tile in order to write messages directly in the nametable. Then sprite 0 could be used to build a ghetto vblank detector.
Sounds like you know what to to tepples, go right ahead.
Is there enough room in the NES internal RAM to do all that?
You can have any graphics you want until you swap carts, selecting mapper manually perhaps and so on, maybe set and be able to test dumping speeds instead of doing it blindly and then send the whole cart out in a single sweep maybe including a proper iNES header as well. Everything would be set in RAM and then you'd swap carts.
That rudimentary text by using a filled or the most filled char could be used after that I guess for better information in case someone has trouble seeing colors.
Great start here anyway, the idea is brilliant, I hope it's developed further and that everyone who likes it also registers here and leaves a comment.
If I want to make a TapeDump cart, what donor cart should I use?
Anyway, this technique seems awesome. Thanks a lot for sharing.
Thanks e5frog for sharing your experience with it. It will be useful when I try it.
How does it connect to CIRAM when there's no cartridge in there? I'd think you'd get no graphics at all without a cartridge in there, except maybe for open bus patterns for nametables and CHR data?
Of course, after the cartridge goes back in the slot, you can use the nametables and CHR memory again.
That's one thing that's nice about the clone systems, CIRAM is always enabled
Dwedit wrote:
I'd think you'd get no graphics at all without a cartridge in there
You'll get the background and the crap that was left there after ejecting the cartridge that loaded it, new graphics appear when you plug the other cart in. That's where you could tell it to check the CHR for an empty and a filled char to display rudimentary information maybe.
Kreese wrote:
If I want to make a TapeDump cart, what donor cart should I use?
As the program stands right now, any NES/FC cart will do. The TapeDump.nes file is NROM with only 16K of ROM and no CHR at all so it's extremely minimal.
There's also a lot of empty space in the cart rom, so there's room for more code in the same space.
BTW how do you get nesasm to use $00 as a filler instead of $FF when you compile? I only found nesasm3 and I got the normal $FF when I used that. Just wanted to set the default speed to 1200 so I didn't have to change it after I started. I noticed after I changed it that it's an easy hex-edit in the .nes file, I believe it was byte $401 that was changed from $08 to $02 instead.
That's a pretty cool idea.
This reminds me too, if anyone wants to read and write tape audio, sepi made a simple expansion port circuit that works with Excitebike and Wrecking Crew (hardware required of course):
http://nesdev.com/tapedrv.PNG
With this, now anyone can make their cartridge able to dump itself. No excuse for anyone to lose the game to bitrot. Like how old PC games told you to make a backup disk before playing. But this time, you could do it to tape.
e5frog wrote:
It says in the texts that it's built for the "Konami VRC2" mapper so I guess it supports that and similar ones (if any). Currently you have to add other mappers yourself, let's hope ccovell wants to add a nice front end and some mappers in a future version.
Why not just include all of the copynes plugins? the plugins are designed to be fairly software-agnostic and load into RAM to run (though I guess they could be put in ROM too). All access is done through a simplistic "input byte" and "output byte" routine, along with a few other minor routines (CRC mainly for ROM size detection). The code could probably be fairly easily hacked to just dump without any frills. You could have it make a CRC for integrity checking too. The copynes software pack should have the source code for the plugins and the bios with the routines needed.
I like the idea of using a hacked game genie for the process. Could call it "Ghettodump", hehe. It'd be pretty decent though, since you can actually try the game out first (it IS a game genie, after all) to make sure all the connections are good, and use the GG CHR logic to put some basic text/messages up before and after dumping with a colour cycling blank screen during dumping (blank screen, and dork with the background colour) like many C64 disk copiers used to do.
Check out how the atari 2600 "supercharger" works, too. It can send 6K of data in around 15ish seconds quite reliably using a simple format. It sends a short high/low or a long high/low depending on if the data bit is 0 or 1. This is much more efficient (and you can adjust timing to speed up or slow down the process) and using 4011 would be quite easy to do. Just output 0 or 7f for low/high. The 'charger uses a preamble of 010101010101 to start with, then the data just follows that. The preamble's around 2-3 seconds long to let the audio chain (back then a tape player) to reach a steady state before the data came out. Cycle timed 6502 code then decoded that data in real time, as it was fed in. It could adjust to nearly any data rate, too. There was no need to have a fixed baud rate or anything, the decoder software figured out the baud rate by monitoring that preamble and checking for "11" which indicated the start of the data from what I recall. i.e. "0101010101011data"
Could the reliability be increased with some sort of forward error correction?
Yes, you could do a whole lot of things, or just buy a CopyNES for $70...
I got this demonstration as a poor mans dumper, it's easy and requires no extra hardware. Only thing missing is some more programming with support for more mappers. If that was chosen in some menu before uploaded to internal ram then it wouldn't require much space.
I guess it's free for anyone to continue the programming, the code is included in the package.
e5frog wrote:
Yes, you could do a whole lot of things, or just buy a CopyNES for $70...
I got this demonstration as a poor mans dumper, it's easy and requires no extra hardware. Only thing missing is some more programming with support for more mappers. If that was chosen in some menu before uploaded to internal ram then it wouldn't require much space.
I guess it's free for anyone to continue the programming, the code is included in the package.
And then you have to install the CopyNES. With this you could modify a Game Genie for anywhere from free to maybe $10 to get an EPROM/FlashROM to install in the GG.
Adding more mappers isn't that hard given that the source includes VRC4 support which is enough for someone to go on to add support for other mappers.
kevtris wrote:
Why not just include all of the copynes plugins? the plugins are designed to be fairly software-agnostic and load into RAM to run
That sounds like a good idea. I'm giving the CopyNES plugins a look now. Since some of them use $300-$3FF for scratch RAM, and all of them are loaded into $400 and go up to about $680 maximum (right?) so there's not much space left for fancy graphics stuff, and definitely no space for CRC routines.
Everything looks straightforward; Kevin, any advice or gotchas I should look out for?
ccovell wrote:
kevtris wrote:
Why not just include all of the copynes plugins? the plugins are designed to be fairly software-agnostic and load into RAM to run
That sounds like a good idea. I'm giving the CopyNES plugins a look now. Since some of them use $300-$3FF for scratch RAM, and all of them are loaded into $400 and go up to about $680 maximum (right?) so there's not much space left for fancy graphics stuff, and definitely no space for CRC routines.
Everything looks straightforward; Kevin, any advice or gotchas I should look out for?
Not really, it was all pretty cheap and nasty code that was done via cut and paste, hehe. The CRC routine could be replaced with some other simpler hashing function and it'd work the same, like a sumcheck. Also, yes, most of the plugin space tends to be empty. Only a few like MMC1 and MMC3 used most of it due to all the different configurations. These could be stripped down and/or separated to make them take up less space. Nothing at all had been optimized, and if I had it to do over again I'd probably have optimized things much better than it currently is.
Then again, when I wrote many of those plugins was over 10 years ago, and I have become a much better 6502 coder in the interim decade.
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?
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.
That would depend on how easily bunnyboy could get a female Game Pak connector made.
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.
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.
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.phpAnother 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?
A couple things:
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.
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.
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.
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.
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?
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.
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.
Does it do UxROM or CNROM?
I wonder if it's safe to hotswap a cartridge with save ram?
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.
Dwedit wrote:
Does it do UxROM or CNROM?
I wonder if it's safe to hotswap a cartridge with save ram?
(NROM, AxROM, MMC1, MMC3 supported.)
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.
B00daW wrote:
http://bootgod.dyndns.org:7777/plugins.php
This seems to have been offline for several days now. Does anyone have a backup server?
ccovell wrote:
Dwedit wrote:
Does it do UxROM or CNROM?
I wonder if it's safe to hotswap a cartridge with save ram?
(NROM, AxROM, MMC1, MMC3 supported.)
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.
Do you plan to explore the Game Genie replacement ROM for dumping without hot swap?
Yes, after a good number of plugins are finished, a 16K GG version can be made up. Tiles 0-15 of my latest TapeDump NES CHR are already the Game Genie CHR pattern.
Problem there is sourcing 72 pin connectors....so far NO ONE has been able to find them with the right pitch.
edit: woops that was aimed at the comment on the previous page.
A newer version of my program with more mappers:
http://www.chrismcovell.com/data/TapeDump_V060.zip
Now supports: NROM, SxROM (MMC1), UxROM, CNROM, TxROM (MMC3), AxROM, Konami VRC2a 2b 4a-e, VRC6a.
2400 bps mode works pretty reliably; 5200 less so, but it's good for a size & full dump test.
Please let me know if you come across any errors.
I do have one idea, which is to display a menu when the program starts to set up mappers and a few other things, and then you must push START to write the program to do that into RAM and then it is ready to swap the cartridge and do the program as explained in the manual. Another question, can it be used to dump save game files?
What you wrote is what my program does: It displays a choice of mappers, which one confirms by pressing A, and it then loads the mapper software into RAM and is ready for swapping.
For now, there is no facility to dump save games, as this is intended by me to be a poor-man's dumper for prototype cartridges and the like, and not a full suite like CopyNES. Also, with the most common mapper files like MMC1 and MMC3, the CopyNES bankswitching code is so large that there is little to no space in RAM for WRAM dumping (so I removed it, as you can see from the source code.)
ccovell wrote:
What you wrote is what my program does: It displays a choice of mappers, which one confirms by pressing A, and it then loads the mapper software into RAM and is ready for swapping.
OK. (Note I have only read the documentation; nothing else.) You should probably correct the documentation. (It doesn't even mention 2400 bps mode and 5200 bps mode, even though this forum says so)
ccovell wrote:
Documentation is now on-screen for the most part...
Remember this is a work in progress, so updates will be posted here and only here for now while I field your comments.
Tried it out finally, works like a charm. You should maybe update the first post with the latest version.
The only problem I had was that it crashed very easily when switching carts. You could try using something like the method proposed by blargg
here to make crashes less likely (and easier to detect, as the tone would stop).
A nice idea, but on the Famicom, the audio line is cut when no cartridges are present anyway...
I was just about to post a long-awaited update to this program here, coincidentally.
Heh, the constant sprite DMA is a pretty clever trick.
ccovell wrote:
A nice idea, but on the Famicom, the audio line is cut when no cartridges are present anyway...
I guess the write to $4011 could be replaced with a write to $2001 to switch between normal and monochrome mode to produce a visible, moving pattern.
Okay, I released my updated version with a few more mappers, FDS disk dumping, and a retroish front-end:
Explanation and controls are here:
http://www.chrismcovell.com/TapeDump_Controls.html
And the .NES ROMs (NTSC and PAL versions) and source are here:
http://www.chrismcovell.com/data/TapeDump.zip
Thanks for your comments and help!
This is one AWESOME project you've made! Thank you so much! I don't have the funds to buy a copyNES so this alternative is a real blessing!
I was just recently working with my PMD-85 computer where the only input is the audio input
so I'm fresh ready for trying this! THANKS!
(by the way, cool front-end!!!)
Just when you thought it couldn't get any better...
WOW
The front-end is especially bad-ass.
Working marvelously on my Famicom! Wonderful programme! I managed to exchange the cartridges in 10 out of 10 tries successfully!
Very impressive work, Chris. I especially love the graphical style choice you made of using fake "double-wide" pixels, looks quite reminiscent of the C64 and A8 machines. I could see this concept being useful on the MD, too - there's already a cable that connects to port 2 and allows dumping of carts, but requires a Sega CD to load the software from. A tool like this would mean that all one would need would be a (fairly cheap) EPROM cart with the dumper tool (or a flashcart, since the code would be revolving in RAM for one to switch carts), and an audio cable. Cart support (for dumping) would be greater in the first release than it was on the NES, as one banking system will cover all licensed carts, and support could be coded for some of the weird-ass pirate mappers that are out there. Drawbacks would include the much longer dumping time that carts upwards of 5MB would incur, but the audio response of the MD may be more favorable to the 5200bps speed than the NES.
Try dumping it using NROM, this should get you the menu code which should be possible to reverse engineer to figure out how it's selecting the games.
Hello! I need help! I have two questions.
1. What program better to use for writing sound? (link)
2. Kcs.exe
Help me to write bat file. I have a file 1.wav - what parameters need write in bat file?
Kcs.exe 1.wav and .............. ???
The Program is written for dos. I can not full-fledged its use.
Or possible start it from command line? That there to write? what parameters?
P.S. Forgive for my bad english.
1) Audacity is a good, free program. Perhaps other people can recommend some other, better, commercial programs.
http://audacity.sourceforge.net/
2) What type of computer OS are you using? Usually in Windows, RUNning a program and then typing "CMD" (full shell) or "COMMAND" (old DOS shell) works. If you have no choice (?) but making a BAT file, then the usage is:
Code:
KCS [options] infile[.typ] [outfile[.typ]]
-X strict decoding -M make wavefile
-C console output -O odd parity
-Bn baud 1=600 2=1200 -E even parity
-U CUTS mode (1200 baud) -D 7 data bits
-V VOC wavefile -S 1 stop bit
-R RAW wavefile -Ln leader (sec)
-Fn offset -127 to 127 -Pn pacing (msec)
-Hn hysteresis 0 to 127 -T sine tone
-Gn timing -2 to 2 -I invert output
-Nn nulls (after CR if n<0) -Y ignore errors
default: decode WAV file, Kansas City Standard,
300 baud, 8 data, 2 stop bits, no parity
eg:
KCS -B2 -G2 -F10 96000.wav game.nes
Programs compiled for MS-DOS can be run in the Command Prompt of 32-bit Windows. They cannot be run at all in the Command Prompt of 64-bit Windows without some sort of virtualization, which Microsoft unfortunately does not provide out of the box on Windows Vista or home editions of Windows 7. But both versions of Windows can run command-line Windows programs, and a DOS program might also be available compiled for Windows.
I used DOSBox to run it on 64-bit Win7.
Thank you for advices, guys. Like all work but I faced several problems:
1. Cartridge wrote themselves! (for test). Possible so do? I choose mapper 0 and "orange" bps. But I can not recall, I dump only PRG or something else, but this not it is important...
2. Here is my recorded file:
http://zalil.ru/32095830
This file - *.wma and stereo, my computer does not want to save the audio file in the other type. Shall Try to find the program for this...
I have tried wma transform to wav (8 bit mono), but... Result always alike - I get Rom NES 1 or 0 bites.
Guyver2011 wrote:
This file - *.wma and stereo, my computer does not want to save the audio file in the other type.
That's the problem. The WMA encoder is not designed for modems like the software modem implemented by this dumping program. It assumes that a human will be listening to the recording and discards information that it thinks won't have a negative effect on perceived sound quality.
Quote:
Shall Try to find the program for this
The other program is called Audacity.
OK... Shall Try to write immediately wav...
Please, give me anyone correct wav file for example, that I could his check and get code from wav file.
Yes! I do it! But I took the sound a stereo, since mono was not work... 22050 8 bit stereo.
Wrote sound by means of utilities sndrec32.exe (windows/sistem32) XP.
We're telling you: Download Audacity. Sound Recorder has a recording limit of 1 minute, making cartridge dumps impossible.
No. I have unlimited version :о) I modified program
http://s017.radikal.ru/i406/1111/c1/5732d6bda329.png
I want to find optimum parameters. If I write the sound 5 once, that whole 1 once from he is "good". Shall Try to do the speed less "orange".
Rom which I have dump:
http://zalil.ru/32100921
(pirate Road Fighter)
I have understood that better to write on speed 1200bps.
ccovell, you plan the improvement of the program? New mappers or something else? I have a cartriges 1000in1, 999999in1, 35in1 and so on... There get the interesting hacks. What mapper can be beside like cartriges? What pull out part of games of them at least? I was able to write only menu these carrtiges.
How hard would this be to make into a pass-through device like a Game Genie? It sounds like it would solve the issue of having to swap carts without having to build something big (perhaps even just a ROM swap?)
I think Loopy, blaarg, or someone else had something going about a Game Genie BIOS replacement ROM. It should be possible to preserve both Game Genie function as well as add TapeDump functionality to Game Genies.
thefox wrote:
Try dumping it using NROM, this should get you the menu code which should be possible to reverse engineer to figure out how it's selecting the games.
Thanks for the tip, I have recorded the dump as 44100Hz Mono WAV (audacity) with 1200bps setting in TapeDump (pressing Start) but when using KCS (kcs.exe -B2 file.wav file.nes) I'm always getting message "Bad pattern at position 46955". What can be wrong? I have tried to lower the recording volume because the amp meter was out of range, but still same result (different position number).
What am I doing wrong? Using command line in Win7. Wav file is 35MB. When using -Y (ignore errors) I get "15401 bytes decoded, 2173 decode errors" and output is a 16kB file which is only garbage, no iNes header.
PS When dumping the cartridge mentioned above, I'm getting sound from Famicom for some 6:35 minutes, then sound stops. That can't be the whole cart, it has all the Rockman games on it.
For 300-1200 bps you have to save the recording as 22050 Hz, 8-bit. Make sure it's never 16-bit. Only for 2400 bps is the recording supposed to be saved as 44100 Hz.
Win7. 1200bps setting in TapeDump.
Kcs.bat: KCS -B2 -G2 -F10 record.wav game.nes
44100Hz Mono WAV 8bits - errors... no iNes header and 0 or 1 or < 16kB
22050Hz Mono WAV 8bits - OK
As for the Rockman multi dump getting cut off early, are you sure TapeDump supports this mapper?
jpx72 wrote:
PS When dumping the cartridge mentioned above, I'm getting sound from Famicom for some 6:35 minutes, then sound stops. That can't be the whole cart, it has all the Rockman games on it.
You won't get the full dump when dumping it as NROM. That would be just used to dump the menu part, which you/somebody would then need to reverse engineer to find out how the menu selects different games, and then write add support to TapeDump based on that.
Thanks everybody for identifying the problem. I forgot about the 22000 AND 8-bit requirement, I'll re-record it and upload the working (menu) rom somewhere. [there shouldn't be anything illegal about pirate menu system dump being released]
By the way, why do you suggest -F10 ? Is this offset specification needed?
-F10 is not necessarily needed for 1200 bps, but it may be for 2400 and 5200. After I record at a lower bps, I usually remove any pops at the beginning of dumping and then normalize the waveform to maximum volume. Thus, adjusting the offset (DC bias, really) is not necessary. Anyway, for 5200 bps, the waveform is much more rounded and misshapen, any kind of massaging can help KCS to decode it.
Nice! i have tried it two times and every time I got exactly the same file (compared in hexeditor)! Now for the harder part - is there somebody who will have the time and knowledge to look at
THIS dumped file to discover the mapper system of this (Rockman 1-6 Multi) cartridge? It'll be great if someone can do this... Thank you!
EDIT: I have flipped the mirroring switch on my tapedump cartridge and recorded the thing again, now I got a smaller file...??? Here's the decoded
FILE.
EDIT2: although on second try, I got the same file as I got before switching the mirroring. This second file must be some mistake.
jpx72 wrote:
EDIT: I have flipped the mirroring switch on my tapedump cartridge and recorded the thing again, now I got a smaller file...??? Here's the decoded
FILE.
EDIT2: although on second try, I got the same file as I got before switching the mirroring. This second file must be some mistake.
You are getting different results semi-randomly because the lower bank registers of the mapper start at random values. For figuring out the mapper this doesn't matter, only the last 8K of the ROM matters in this case, so both ROMs are fine. As for why the graphics are garbled, the CHR banking regs are random at startup as well. This also doesn't matter for this task.
I'll see if I can find time to take a look at this later.
Thank you for the explanation! It would be great if you can look at it further!
I think it's as speculated before, a MMC3 with master bank registers.
Looks like it has atleast 3 control registers, 5010, 5011, 5012.
This is a data table of the values written when loading games. The first value goes to $A000, then to the 50xx in order. It writes these registers from a small code segment loaded into the 2K WRAM which then clears RAM, resets various registers, and does a JMP ($FFFC).
Code:
$A000,$5010,$5011,$5012
XX,00,00,20, Menu, CHRROM?, 8K PRG?,8K CHR?
00,22,10,55, Rockman, CHRRAM, 128K PRG
80,21,20,AA, Rockman 2, CHRRAM, 256K PRG
00,11,30,20, Rockman 3, CHRROM, 256K PRG & 128K CHR
80,20,40,55, Rockman 4, CHRRAM, 512K PRG
00,01,00,00, Rockman 5, CHRROM, 256K PRG & 256K CHR
80,20,60,AA, Rockman 6, CHRRAM, 512K PRG
And it seems the games are in order they appear on the menu. So to read any game, the MBR can be set to these values, and then you read all the banks as though they are MMC3 games most likely.
The most interesting thing about this being dumped will be seeing the MMC3 hacked Rockman 1 and 2 since the rest of the games all use MMC3.
Update: I added some info next to the table incase anyone wants to speculate what the values written likely do.
$20 to $5010 seems likely to enable CHRRAM. The lower nibble could be related to PRG Block size, x0 being 512k, x1 256K, x2 128K.
Not sure what the deal with $A000 is since that is the MMC3 mirroring register and they only write clear or set of the highest bit.
If you are using TampDump via PowerPAK you can edit the TxROM plugin and remove something not needed, like detecting Mirroring since we know it'll be mapper controlled, and add in code then to set the MBR (5010,5011,5012, and maybe A000) and then have the plugin try dumping each game normally as if its TxROM.
---
$5011 could be selecting a block of a large PRG-ROM if they mirror Rockman 1 to 256K I think. $5012 maybe CHRROM page with junk values for the CHR-RAM games?
Thanks MottZilla! That is an impressive ammount of work! Unfortunatelly that's where my participation ends, because I don't understand anything from that, except the first line.
Anyway I don't have a PowerPak, I'm using custom NROM cartridge made of pirate NROM board. So I cannot edit anything. I would need the TapeDump software to be edited with these specifications, so I can burn it to my devcart.
TapeDump comes with its own source, and the mapper files come with their own assembler, so there's nothing stopping you from assembling your own version of the ROM; Powerpak or no Powerpak.
ccovell wrote:
TapeDump comes with its own source, and the mapper files come with their own assembler, so there's nothing stopping you from assembling your own version of the ROM; Powerpak or no Powerpak.
Yes, thank you I am now aware of that and I'm thankful that you released those. Nevertheless I must try to find someone who will help me edit them, because I simply don't understand that. All I want is to dump this pirate for anyone who's interested.
If I get some time I can try editing it. But I still don't full understand the registers and what they are doing on a hardware level. But as I said before we know enough to dump each game on the cart. RM1&2 will be most interesting since they were most likely hacked to MMC3.
MottZilla wrote:
we know enough to dump each game on the cart
That would be great!
I was in a hurry as I have to leave soon but try this.
http://www.megaupload.com/?d=JW6GADRY
Basically I modified the driver as I mentioned to bankswitch Rockman 1 into place and then the driver will continue on to try to dump the game as a TXROM game normally would. I think I did this correctly, try it out and let me know. If it works I'll make 5 more to dump the rest of the games.
Thanks, it's working like a charm! I'll let you all know how it ends!
Anyway I wanted to ask one thing, since the project of replacing the Game Genie rom with TapeDump is dead (and I have a glob-top GG anyway), I was curious, what about cutting the current for the cartridge slot between cartridge exchanges? I can cut the lines and insert a switch to my Famicom, turn off the power to the cartridge slot when pulling out the TapeDump cart and powering it back on after the dumped cartridge is inserted. Would this work? I'm starting to worry about my Rockman multicart, since I already killed one glob-top pirate with the swap-trick.
Thanks!
Game Genie replacement ROM for the TapeDump is dead? Did Chris say it wasn't possible or just not going to happen or something?
I'm not sure if a switch like what you suggest would work or not since I'm not an electrical engineer. It's worth a shot.
Well I assumed it's dead because I haven't heard about it in a while... but I should not say dead, just currently not-worked-on.
I'm not working on it right NOW, but that doesn't mean it's dead. Perhaps I'll have some more time as I have winter holidays from Dec. 23rd to Jan 5th.
jpx72 wrote:
Thanks, it's working like a charm! I'll let you all know how it ends!
Anyway I wanted to ask one thing, since the project of replacing the Game Genie rom with TapeDump is dead (and I have a glob-top GG anyway), I was curious, what about cutting the current for the cartridge slot between cartridge exchanges? I can cut the lines and insert a switch to my Famicom, turn off the power to the cartridge slot when pulling out the TapeDump cart and powering it back on after the dumped cartridge is inserted. Would this work? I'm starting to worry about my Rockman multicart, since I already killed one glob-top pirate with the swap-trick.
Thanks!
Even if you did that I still wouldn't consider it "safe" in fact it might be worse. I'm not certain here but I'm imagining if damage is actually occurring it's because for a split second when pulling the cart you've broke contact with a power pin but some address/data pins are still connected. And in that situation normal power is removed but there is still the potential to power/ground some ICs through the address/data lines. and if you did that wonky things will happen and it's conceivable something could be improperly biased and burn out. I wouldn't think it's very likely but conceivable.
If my guess is correct you'd actually be making the issue worse by removing the Vcc for a few seconds vice a few milliseconds. But I'm not certain why your cart broke, it could have been coincidental and not related to hot swapping it, I'm only speculating really.
Thanks for the info Chris!
infiniteneslives - Thanks for the opinion, I haven't considered the power at A/D lines. My pirate cart that is no longer working was the one in
thistopic. Actually I managed to dump
something, but after the sound stopped, I was not able to make this cart work. The console behaves like there's nothing inserted at all.
part of Rom (this works!):
http://zalil.ru/32179767
NICE! I have at least this screen to remember the cart... Thank you!!!
Some more information about the Rockman Multicart. Thanks to jpx72 for dumping the data for me to examine to figure this out. Some bits are speculated until more testing can be done. PRG is probably concrete but CHR is a bit fuzzy. I think the upper nibble of $5010 and $5012 are related to CHR configuration.
PRG-ROM is a 16 Megabit / 2 Megabyte ROM with data arranged as follows:
Rockman 5 (256K)
Rockman 1 (128K)
Duplicated Rockman 5 Data (120K)
Menu Program (8K)
Rockman 2 (256K)
Rockman 3 (256K)
Rockman 4 (512K)
Rockman 6 (512K)
CHR-ROM is probably a 4 Megabit / 512 Kilobyte ROM:
Rockman 5 (256K)
Rockman 3 (128K)
Menu CHR (8K)
Duplicated Junk Rockman 5 Data (120K)
The upper nibble of $5011 most likely sets address lines on the PRG-ROM. The lower nibble of $5010 probably affects the effective size of the PRG viewable to the MMC3, 128K/256K/512K.
Upper nibble on $5010 is probably bit 1 set CHR-RAM Enabled, clear CHR-ROM enabled. bit 0 is probably a CHR ROM size 128K/256K switch.
The upper nibble on $5012 is probably CHR-ROM address lines.
Again I haven't confirmed some of this but I'm pretty sure that most of it should be correct.
Update:
Retrieved the Menu CHR and confirmed the data ordering.
Help me! I have a cart "38 in 1". This cartridge much looks like "9999999-in-1 [p2].nes". The mappers same (looks like that). It is Difficult will add support of the mapper 213 in Tape Dump? Or other mappers, for instance 225 or 227? What mappers are used in multicartridges? The Interesting games are found in them. Chinese games and hacks...
In archive are found 2 Roms, "menu 38 in 1" and 9999999-in-1 [p2].nes
http://zalil.ru/32187747
Or will possible do in Tape Dump manual entering importances? The choice of the banks graphs and code...
Beside I was got pull out some graphics from my cart. I simply inserted and took out the cart in dendy (famiclon). And if I saw the necessary graphics - I wrote her. But with code so is not got.
Pirate multicarts' mappers have to be reverse-engineered by analyzing the menu code. That's something that any cart dumper has to get used to doing by himself (or with the help of some kind Samaritans). Look at Kevtris' homepage (
http://kevtris.org/nes/pirate.html ). That's a large part of his NES work: analyzing mappers so that carts can be dumped.
But realy it is impossible study the mapper on working rom? If they alike...
It is impossible do something universal? Without assembly of the ready rom. But with possibility something save...
P.S. link is dead?
http://kevtris.org/nes/pirate.html
The main link work but all the link related to multicart are down and has been for a long time. You can find detail on this page:
http://kevtris.org/mappers/bmc_fam/index.html
I also have multiple pirate cart that I would love to dump but you have to understand that reverse engineering pirate mapper is a lot of work and you can't really expect someone to come forward and do it for you unless there is something major on the cart you are trying to dump.
For anyone interested this is more on the Rockman 6-in-1 mapper.
Code:
REGISTERS:
$5010 - Chip Config
xxSC-xxPP
S = Select CHR ROM/RAM
0 CHRROM. 1 CHRRAM.
C = CHR-ROM Size
0 256K. 1 128K.
PP = PRG-ROM Size
00 512K. 01 256K. 10 128K.
$5011 - PRG Chunk 256K Base Select
xBBB-xxxx
BBB = Selects 256K Base of PRG-ROM for MMC3 to Use
$5012 - CHR Chunk Base Select
xxBB-xxxx
BB = Selects 128K Base of CHR-ROM for MMC3
Only values 00 and 10 are used but bit 0 may be
valid too.
On Powerup PP of $5010 is zeroed, BBB of $5011 also zeroed. This causes the first 512K of PRG-ROM to be seen by the MMC3 which puts the Menu program in control.
$5011 really controls upper address lines on the PRG-ROM. $5010 controls address lines too, by deciding which ones the MMC3 can control and which ones it holds in a constant state to effectively set bounds for the ROM data seen by the MMC3.
That should cover most of the mapper and how it works.
---
Stuff about hardware. I'm not sure this is all exact as I'm no hardware expert.
PRG-ROM Connections
A16 and Below Connect Normally to MMC3
A17 - HELD HIGH in 128K Size Mode, otherwise connects normally
A18 - Connects to MBR if Size isn't 512K. If it is then it connects to MMC3
A19 - Connects to MBR
A20 - Connects to MBR
MBR being Master Bank Register. It controls the upper PRG lines. The upper most 2 are always connected to the MBR. A18 is used in 256K and 128K PRG modes by the MBR. In 512K mode the MMC3 needs this as the ROM is 512K and needs that to switch between the first and last 256K of data. A17 connects normally to MMC3 unless the mode is 128K in which case its I think held high (+5v) so the lower 128K of the selected 256K block is all that is visible. This is used for Rockman 1.
I think all this is correct. CHR-ROM has a similar setup. I imagine you could built your own cartridge with a TxROM cart and additional hardware for the MBR.
ccovell wrote:
We're telling you: Download Audacity.
There is another program which can record sound files, known as SoX (Sound Exchange), if you prefer the command-line program.
Can somebody help me with "ironing" the wav file recorded by Tapedump? I'm getting great results when the recording time is less than 1 hour, but at larger files, I'm getting decoding errors when using KCS to decode the wav file.
I have done everything humanly possible to perfect my recording setup (using Famicom, recording from pin #46 of cartridge connector, disconnected II. player controller, using shielded cables and disabling any sound-altering plugins of my soundcard, using SoundForge soft).
I have recorded both at 300 600 and 1200 bps, with same results. Running out of options here...
I don't know which normalising settings to use, or what different methods of "cleaning" the audio recording can be applied.
I'm using the same settings with KCS: kcs.exe -Bn -G2 -F10 file.wav file.nes ("n" being bps speed). Maybe I can use different settings or other decoding software...
Any help highly appreciated!
Here's a question: are you using an NTSC Famicom, or a clone, or a PAL clone? I've tested PAL in emulators, but since I don't have the hardware, I don't know of any problems that come up with any recording above 5 minutes.
60 minutes even at 1200 bps???!? How big is the cartridge you're dumping??
One piece of advice is: if the cart you dump has PRG and CHR ROMs, split up the recording between dumps of PRG and CHR (the 5-second leader is played again before CHR.) Then use KCS to decode each PRG and CHR recording.
3600 seconds * 1200 bits per second / 11 bits per byte = very close to 384 KiB, the size of Super Mario Bros. 3 or Big Bird's Hide and Speak.
A few games have 512 KiB of PRG alone: Kirby's Adventure, Mega Man 6, Dragon Warrior 3 (U), Dragon Quest/Warrior 4.
As you
may have
noticed a couple of posts earlier, MottZilla is helping me dump my Rockman 1-6 multicart. By tweaking the TapeDump itself, I was trying to dump each game by itself (128,256,384,512,512 and 512 kB) and by one tweak, I was dumping a data chunk of 768kB (containing the whole Rockman 3 data) to get the idea how the whole menu system works (this one took 8 hours at 300bps with 7 decoding errors, I got only one dump at 1200bps/2hours with no errors).
I succesfully dumped Rockman 1 and 2 (MMC3 hacks), but I'm unable to correctly dump Rockman 3 to 6 (yet).
I am using original Japanese Famicom (NTSC/HVC-CPU-GPM-02C) with NTSC version of TapeDump, connected to a quadcore/4GB_RAM/Win7 PC.
Any other help? Something about editing the finished recording?
ccovell wrote:
if the cart you dump has PRG and CHR ROMs, split up the recording between dumps of PRG and CHR (the 5-second leader is played again before CHR.)
There's always only one decoding error in the Rockman3 dump, couldn't it be because of this sound between PRG and CHR?
NESASM don't work in Win7 and NESASM3 don't work in Win7. - Rom Tape Dump don't compile.
asm6 work in Win7. ccovell, please, give me sourse code for asm6. This will it is difficult to do?
NESASM3 workz in Win7, unless I've not been compiling stuf over the last year with it.
He works, but there is some problems. asm6 work in Win7 100%.
What kind of problems? There's zero problems for me, it's 100% functional on both X64 and X86-64 computers with what I work on.
Wow, 8 hours to dump a ROM?
The tape dump idea is definitely cool, but you guys do know it's only $2 in parts to interface the NES/FC to an RS232 port, right? Sounds like it would save a lot of time if you want to copy large amounts of data.
Should be a bit more reliable too right? But then again this has its advantages, and has the software to do it actually developed. If someone developed a serial link and programs to go with it, maybe that would be used instead.
Memblers wrote:
Wow, 8 hours to dump a ROM?
..at least you can see how dedicated I am
(and that's 8 hours just for the menu system to understand, add to that dumping of the next 5 games and you have a nice full-weekend job)
Memblers wrote:
The tape dump idea is definitely cool, but you guys do know it's only $2 in parts to interface the NES/FC to an RS232 port, right? Sounds like it would save a lot of time if you want to copy large amounts of data.
There's no problem building it but can you provide the software for it? Something understandable (English) and relatively easy to controll? Last time I asked about this I was pointed towards some Japanese web, couldn't even get the right schematics...
But if it's that simple, why then the need of CopyNES? Profit?
I've been thinking about doing a controller port serial dumping software, but haven't done it so far because I have no use for it. It would be pretty easy to do using blargg's NRPC library (the same one I used for the PC2NES PowerPak transfer software). It's too bad NRPC was never officially released, but if somebody want's to use it you can get it from the PC2NES sources.
jpx72 wrote:
There's no problem building it but can you provide the software for it? Something understandable (English) and relatively easy to controll? Last time I asked about this I was pointed towards some Japanese web, couldn't even get the right schematics...
But if it's that simple, why then the need of CopyNES? Profit?
CopyNES was from 12 years ago, and was cheaper too when kevtris sold them.
I've used these
XMODEM routines, usually loaded in WRAM on cartridge, but think it would fit in NES RAM (though taking out the 512 bytes of lookup tables might help).
You could also perhaps change only the Send_a_Byte routine in TapeDump to use a 19200 baud send from xmodem.asm. Then you would just need a program that can save all data coming in the serial port (I'm sure there are many). Sounds easy, maybe it could work? I haven't tested this at all, but I modified it so it should assemble OK.
Code:
;----
Put_Chr:
send_at_19200:
sta <LOOP_CN2 ;Save A temporarily
sta <LOOP_CN3 ;Save A temporarily
txa ;Save our X reg
pha
tya
pha
lda <LOOP_CN2
; eor #$FF
lda #0
sta $4016 ; start bit
ldx #16
@b1:
dex
bne @b1
nop
ldy #8 ; send 8 data bits
@send_data_bits:
lda #0
lsr <LOOP_CN3
rol
sta $4016
ldx #13
@b2:
dex
bne @b2
nop
nop
nop
dey
bne @send_data_bits
lda #1
sta $4016 ; stop bit
ldx #15
@b3:
dex
bne @b3
pla
tay
pla
tax
lda <LOOP_CN2 ;Get A again... bummer
rts
;--------
On the Rockman pirate subject, I added support for emulating it in my own emulator based apon the information previous posted and it works fine. If jpx72 chooses to release the ROM dump I helped him clean up and assemble then others can certainly add support for it too.
Just a pretty basic MMC3 based multi-cart.
After a long search based on an information that Rockman 6in1 cartridge was dumped before by some Chinese guys, I finally found it. It's much more accurate dump than I and MotZilla made, because it was dumped by a kazzo rom dumper. It's all there, the extra 30 lives in Rockman 3 and removed Capcom logo in Rockman 4. And it has been already emulated in CaH4e3's FCEU port under UNIF header. If anyone wants, I can provide link to the dump via PM. Would be nice to see it emulated in Nestopia.
this is a great tool
i got an strange idear for an alternative transfering mode.
Could we maybe use the background color + some time based scanline + midscanline code for sending data over a simple data matrix like barcode?
that can be captured with an webcam?
greetings marcel
I guess it should be possible to output a QR code or something like that, but you'd still need several frames to transfer games... I guess over a minute worth of video for larger games (if you use a video capture card to get all 60 frames per second, obviously more than that if you use a webcam). Still a much better time than what is possible with audio, but we'd most likely need a custom tool to convert the video back into a ROM file.
I've looked into Denso Wave's QR Code as a way of automatically submitting high scores that the player achieves in a video game. The problem is that it takes a while for a 6502 to encode all the Reed-Solomon error correction that makes up part of each frame of a QR Code. Furthermore, it presupposes CHR RAM.
I still believe that much more is possible with audio if you abandon FSK in favor of QAM.
mrm78 wrote:
this is a great tool
i got an strange idear for an alternative transfering mode.
Could we maybe use the background color + some time based scanline + midscanline code for sending data over a simple data matrix like barcode?
that can be captured with an webcam?
greetings marcel
You mean like this?
I've done it (see above), but it's most useful with games/embedded roms that have CHR-RAM. It works fine over a video capture card but then there's post-processing and cutting of image captures, etc. that the user needs to do.
Basically, it's more fiddly. Audio decoders are much more widespread and require less hardware/knowledge to get a working dump. Easiest = best deserving the label of 'poor-man's dumper'.
I wouldn't mind playing wih the image output, it's easier to clean an image than to clean a wav file.
I found this:
NES/Famicom serial cable specification
http://slack.net/~ant/old/nes-code/serial/spec.htmlcode:
http://slack.net/~ant/old/nes-code/I'ts a easy and faster way to dump famicom/nes cartridge!
maybe easier than kcs.
I want to you can improve your tape to suport serial cable,thanks!
That's another good idea alongside the parallel port idea I'm working on
here. They both still invalidate the general "without extra hardware" idea. And it being easier is quite debatable -- not only do you have to build a cable, you have to wire together an RS-232 level converter!
Update: Castle Excellent's KCS reading functions seem to work OK, even through the rather hysteretic Famicom microphone circuit, so the next version of TapeDump might be able to keep its lack of required hardware for data uploading as well. Fingers crossed!
Someone needs to port the "KCS"-program to a more modern environment. It obviously requires Dosbox on x64 systems.. :/
Is the source code for this KCS program available? Is its author contactable?
Here is some code from alternative en/decoders:
http://brainwagon.org/2011/07/22/the-ka ... -standard/The KCS08 program was written in 16-bit FORTH, so I'm not so sure the code would even be recompilable by us. Anyone know FORTH?
ccovell wrote:
Here is some code from alternative en/decoders:
http://brainwagon.org/2011/07/22/the-ka ... -standard/The KCS08 program was written in 16-bit FORTH, so I'm not so sure the code would even be recompilable by us. Anyone know FORTH?
I know about Forth. You might be able to run it on Gforth (although it is 32-bits); any differences in the system can be programmed in Forth itself (this is one of the features of Forth!).
However, I am also interested in if the encoder/decoder could be written in
Csound.
If you want to try to implement KCS in csound, it's really simple:
The 1200 baud variant is 1200 baud 8N2 serial, where 1 bits (including stop) are 2 full cycles of 2400Hz, and 0 bits (including start) is 1 full cycle of 1200 Hz. Microcomputers often use a 1-bit ADC, so their implementation is almost always just limited to "count the amount of time between zero-crossings, and see if it's two 833µs periods or four 417µs periods". I don't know how much more sophisticated you could get using a greater-depth ADC.
... Also, the source for the kcs08 program (KCS.SCR) is hilariously awful in that it doesn't have line endings, the entire thing is just a 64-column textmap.
Perhaps this might be an opportunity to get out of the FSK that is KCS/CUTS and into
MFM or
(0,2)RLL or
QPSK, which would drastically increase the data rate. The first step in implementing these would involve some sort of equalization pass to correct phase errors at the decoder.
I've been tempted to try to write a RLL(2,7) encoder-decoder for maximal data rate, except that I have no place where I'd actually use it.
For an audio system that can reliably record 2400Hz-and-lower square waves, it would just break down to counting whether it's been (3..7)÷3×417µs since the last zero-crossing.
Tepples: I am uncertain whether QPSK could be decoded using just a 1-bit ADC?
Yes, as QPSK is just 0011, 0110, 1100, or 1001 from the ADC. A greater-depth ADC primarily helps with the higher data rates as it allows finding more precise transition times with cubic interpolation. But in this case, MFM or some other advanced RLL is probably the better choice.
lidnariq wrote:
If you want to try to implement KCS in csound, it's really simple:
The 1200 baud variant is 1200 baud 8N2 serial, where 1 bits (including stop) are 2 full cycles of 2400Hz, and 0 bits (including start) is 1 full cycle of 1200 Hz. Microcomputers often use a 1-bit ADC, so their implementation is almost always just limited to "count the amount of time between zero-crossings, and see if it's two 833µs periods or four 417µs periods". I don't know how much more sophisticated you could get using a greater-depth ADC.
OK. I could try.
Quote:
... Also, the source for the kcs08 program (KCS.SCR) is hilariously awful in that it doesn't have line endings, the entire thing is just a 64-column textmap.
Forth programs are often stored like that; the source-code is split into pages each of which has a fixed number of rows and columns, so line-endings need not be stored because they are implied.
We're going to include TapeDump in a second printing of the Streemerz bundle. Any objections?
I like this idea, please say yes
Perhaps include a small program to LOAD code over the controller ports as well? (into ram)
edit: Does the cart use chr ram? That would make this idea even more interesting because you could actually load graphics. Could lead to a fun "minigame competition" platform to strive for.
edit2: I have a strange sense of deja vu...did we discuss this before?
edit3: I'm apparently smoking crack, I typed usb instead of controller!
Jeroen wrote:
Perhaps include a small program to LOAD code over the usb ports as well? (into ram)
What USB ports?
Quote:
Does the cart use chr ram? That would make this idea even more interesting because you could actually load graphics.
It doesn't matter whether this cart uses CHR-RAM or CHR-ROM, once you swap carts the CHR you have access to is the one in the cart being dumped. If it's RAM, you can indeed upload some patterns from main RAM (the code/data decated to this should be minimal though, since there's only 2KB of RAM and most of it should be dedicated to dumping, not graphics), but there's nothing you can do if the new cart uses CHR-ROM.
Woops...fixed that little error.
The chr ram would be for the LOAD feature I suggested, not for tapedump of course. (presumably the load feature would load a chunk of code into the 2kb internal ram)
Jeroen wrote:
Woops...fixed that little error.
Ah, controller ports. Well, the EXACT opposite of what TapeDump does would be to use the Famicom microphone to load programs...! Too bad the NES doesn't have one. Anyway, what would the other end of the cable connect to? Hopefully not something that makes the cable hard to build for those not very experienced with building hardware.
Quote:
The chr ram would be for the LOAD feature I suggested, not for tapedump of course.
Ah, I see. So, minigames under 2KB? Sounds cool, specially considering you can use self-modifying code (and you can use .db for initializing variables, saving you the space of a few LDAs/STAs). You could even decompress tiles to VRAM and then decompress the game program to occupy the space that was previously used by compressed graphics.
If someone were to figure out exactly what sort of filtering the Zapper's demodulator circuit is doing, it'd become possible to load data in through an LED and a Zapper.
Would it be possible to dump to a tape and then use the tape port on the keyboard to load data?
That should be possible (after all its what the tape drive port on the keyboard was for). However this would mean that people without a keyboard are out of luck. (and they'd need some way to hook it up to a ntsc/pal NES). It's probably easier to aquire a keyboard than building your own custom controller cable though.
I like tepples's zapper idea, this would really match the tapedump program. And it is very accesible, anyone with a crt tv and a zapper should be able to get it working. (if we do it right, any device with a controllable light should work if it can match the right frequencies)
edit: before this gets out of hand. Split?
Jeroen wrote:
And it is very accesible, anyone with a crt tv and a zapper should be able to get it working.
I see two problems with the use of a CRT TV:
1- It would be slow as hell! Since the picture is updated at 60Hz (NTSC) and the only information you can convey through the zapper is light/dark, you'll only be able to transfer 60 bits per second. That would mean 4 1/2 minutes to transfer a measly 2KB of data, not considering extra control and error correction data!
2- How are you going to get the information to show up on the TV? You can generate a video on the PC and put it in a thumb drive or a DVD and play it on your DVD player, but that's hardly efficient. Because of the low popularity of CRT TVs these days we can hardly find video cards that can output composite/s-video, so we really don't have many options.
It wouldn't exactly be practical, but I don't think that was the point of this in the first place.
Granted, other methods would stil be apreciated. Dammit nes, y u no haz tape port!z
Controller port is stil an option of course.
Jeroen wrote:
Perhaps include a small program to LOAD code over the controller ports as well? (into ram)
I am working on 2 methods of loading code onto the NES/FC, in case you missed the thread here:
viewtopic.php?f=2&t=9909The PAR Port loader can use the controller pins, but the Microphone loader requires a real Famicom with mic (cable is dead simple, however.)
Jeroen wrote:
Perhaps include a small program to LOAD code over the controller ports as well? (into ram)
Pretty sure I suggested the very same thing for the last cart, but tepples didn't want to include it without being able to test it (he doesn't have a controller cable for it, I think).
Anyway, if such program is included, the ideal candidate (in my opinion) would be blargg's bootloader, because of how flexible it is:
http://slack.net/~ant/old/nes-code/boot ... usage.htmlObviously, more the merrier.
I've considered making those cables before. But due to the limited availability and cost of the nes controller cord I've dismissed it since usb is cheaper and more convenient with the assumption your buying a cart to go along with it.
tepples wrote:
If someone were to figure out exactly what sort of filtering the Zapper's demodulator circuit is doing, it'd become possible to load data in through an LED and a Zapper.
My preliminary experiments show it roughly equivalent to a modulation with a 16kHz carrier to demodulate, followed by a 1kHz lowpass filter.
tokumaru wrote:
I see two problems with the use of a CRT TV:
2- How are you going to get the information to show up on the TV? You can generate a video on the PC and put it in a thumb drive or a DVD and play it on your DVD player, but that's hardly efficient. Because of the low popularity of CRT TVs these days we can hardly find video cards that can output composite/s-video, so we really don't have many options.
The zapper does not need to be pointed at a CRT. We could hook up an LED to a (optionally USB) serial port and synthesize the carrier by sending carefully chosen bytes over the serial port.
For example, if a serial port can support 115200 baud and 5N1 serial, all bytes will take 1/(16.5kHz) to send—close enough to the horizontal retrace frequency. Then it's just a matter of picking two bytes (maybe 0 and 0x1C?) that count as "bright enough" and "not bright enough" to the demodulation circuit.
If we can't get 5N1 reliably, another possibility is 38400 8N1 where the bytes sent are specifically 0 (one pulse with 1/3.8kHz spacing) or 0xA5 (four pulses with ≈1/15.4kHZ spacing).
Failing all else, we could throw in a really cheap microcontroller that takes care of all the timing.
TL;DR: none of these require modifying the zapper or NES at all.
Since phones these days typically have a led on them for the camera flash...couldn't that be used as a half decent transmission source?
Assuming we can turn the LED on or off at ≈31kHz, it would be great.
thefox wrote:
I've been thinking about doing a controller port serial dumping software, but haven't done it so far because I have no use for it. It would be pretty easy to do using blargg's NRPC library (the same one I used for the PC2NES PowerPak transfer software). It's too bad NRPC was never officially released, but if somebody want's to use it you can get it from the PC2NES sources.
Good idea!
So let's do it!
byemu wrote:
thefox wrote:
I've been thinking about doing a controller port serial dumping software, but haven't done it so far because I have no use for it. It would be pretty easy to do using blargg's NRPC library (the same one I used for the PC2NES PowerPak transfer software). It's too bad NRPC was never officially released, but if somebody want's to use it you can get it from the PC2NES sources.
Good idea!
So let's do it!
I still think it's a good idea, especially if a Python library was made out of NRPC (the dumping plugins would then be Python scripts). Would be especially fun if it worked in real time (could probe the NES from a Python console...). But as previously said, personally I have no use for it.
thefox wrote:
byemu wrote:
thefox wrote:
I've been thinking about doing a controller port serial dumping software, but haven't done it so far because I have no use for it. It would be pretty easy to do using blargg's NRPC library (the same one I used for the PC2NES PowerPak transfer software). It's too bad NRPC was never officially released, but if somebody want's to use it you can get it from the PC2NES sources.
Good idea!
So let's do it!
I still think it's a good idea, especially if a Python library was made out of NRPC (the dumping plugins would then be Python scripts). Would be especially fun if it worked in real time (could probe the NES from a Python console...). But as previously said, personally I have no use for it.
I will try it!
I will write a new pc -client with dump
Now, if only I could record it into my VIC-20's 'datasette' drive
(and play it back into the system to load the game)
I'm sorry to bump this thread, but you guys seem to have been struggling with KCS for DOS. A few years ago I contacted the author and he recompiled it for me, using a Windows compiler, as I wanted to use it for retrieving data stored in old Astrocade BASIC tapes. This version can be found here, bundled with other Bally BASIC tools (for the Astrocade):
http://www.ballyalley.com/program_downl ... tools.html <- Software download page
http://www.ballyalley.com/program_downl ... _Tools.zip <- Direct download link
Both DOS and Windows versions are included
Thanks a lot for the link!
Hi I have a noob question . I have famicom carts and wanna dump them so what kind of powerpak should I get?
If you have a NES, get the NES PowerPak and use your Famicom carts through an adaptor. If you have a Famicom, use a Famicom Powerpak (??)
Oh, yeah, since you're in Egypt, TapeDump doesn't dump games from within multicarts.
It should be able to dump the menus, though. ;-D
There is no Famicom PowerPak. There is a Famicom version of the EverDrive N8.
It'd probably be cheapest if you can find an electronics repair shop and pay them to convert a random cartridge into a cartridge of TapeDump...
ccovell wrote:
If you have a NES, get the NES PowerPak and use your Famicom carts through an adaptor. If you have a Famicom, use a Famicom Powerpak (??)
Oh, yeah, since you're in Egypt, TapeDump doesn't dump games from within multicarts.
It should be able to dump the menus, though. ;-D
really?well I wanted to make it specially for multicarts
tepples wrote:
There is no Famicom PowerPak. There is a Famicom version of the EverDrive N8.
Isn't it too expensive?
lidnariq wrote:
It'd probably be cheapest if you can find an electronics repair shop and pay them to convert a random cartridge into a cartridge of TapeDump...
im country noone gives interest about retro stuff so which will be cheaper buying a famicom powerpak or buying Kazoo cartridge INL Retro Dumper?
ouso1999 wrote:
im country noone gives interest about retro stuff
But you don't need support here, just someone who's willing to burn a new 'PROM and replace the PRG on a donor ... at least, assuming you can find a donor.
Quote:
so which will be cheaper buying a famicom powerpak
The Everdrive N8 is about 100 USD. You can probably find a slightly-closer distributor –
http://shop.krikzz.com/aboutus.scQuote:
or buying Kazoo cartridge INL Retro Dumper?
The Kazoo was originally made by naruko (
http://sourceforge.jp/projects/unagi/wiki/order_ja ), but I don't know if he'll ship outside of Japan. Also he's currently out of stock.
INL sells his version for 20 USD (
http://www.infiniteneslives.com/aux3.php ).
How can one properly incorporate CopyNES plugins? I am trying to dump a GNROM/MHROM like game. I used the source file from the latest CopyNES distribution, compiled it with TASM included in the TapeDump src folder, and substituted the mapper by changing the appropriate lines in TapeDump.asm. Then I assembled it with NESASM3. I see in the sources for the TapeDump mappers that they include the options to dump the PRG, CHR, header or the full ROM, but the CopyNES plugins do not have these options in the source.
I have used this program to dump a Super Mario Bros. cart successfully but I cannot seem to obtain a working dump of my Mapper 66 game. I think I am only getting the first 32KB bank repeated and the program does not stop dumping well after the 64KB mark. (My cart has a 64KB EPROM for the PRG on it).
The CopyNES plugins aren't used as-is; I've hacked them quite a bit.
IIRC, all CopyNES plugins have a "dump all" command which I had to split up into their respective "dump CHR", "dump PRG", "dump iNES header", etc routines, which each get called from TapeDump.
You'll have to compare a CopyNES plugin to the same TapeDump mapper plugin to see what gets changed.
Could someone please do a UNROM version of TapeDump?
Thanks in advance.
But Tapedump already supports UNROM?
I mean, a version that can run on a UNROM board.
Is it already supported?
That'd need two changes:
- Ensure the reset handler is above $C000, and switch the first bank into $8000
- Put the UI graphics in PRG ROM, possibly compressed, possibly in otherwise unused space, and copy them to CHR RAM
Anyone up for such a mapper hack?
OK, here you go.
It's 32 KiB UNROM, uncompressed CHR is copied, and PAL is detected and patched at at run-time.
I would post sources but I literally hex edited the whole thing. It's also worth noting (provided that I wanted to spend time getting the original source to compile) that it looks like there's enough room to fit the original code, PAL differences, and compressed CHR into 16 KiB.
Great!!
Thank you!!