CopyNESW bugs / feature request thread ...

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
CopyNESW bugs / feature request thread ...
by on (#8160)
I finally put my CopyNES together and tested it out under WindowsXP. CopyNESW is an EXCELLENT program! Really easy to use. Since I couldn't find a support thread/forum for it, I decided to start this one. :D

Here's a list of things I noticed:

- The copy SRAM memory back to cart feature doesn't seem to work (but I can dump the save game from the cart)
- When I dump a GAR, the BIN file is created in the done plugins directory rather than where normal ROM dumps are stored. Further more, the program doesn't ask me for the save filename.
- GAR bin dump files seems to be in "locked" mode until CopyNESW exits.

Lastly, has anyone else noticed that every time you dump a GAR you never get the same BIN file?? About 80% of the file is the same, but the other 20% keeps on changing. I've dumped 2 different GARs, and their SRAM memory is completly different!

by on (#8165)
Code:
I've dumped 2 different GARs, and their SRAM memory is completly different!


Maybe the game saves for the last person to use it are part of the file?

-Rob
Re: CopyNESW bugs / feature request thread ...
by on (#8173)
leonk wrote:
- The copy SRAM memory back to cart feature doesn't seem to work (but I can dump the save game from the cart)


I'll have to get a hold of an NES cart with SRAM on it so I can test this personally. I pretty much duplicated the logic from the QBASIC client, so I figured that it would work properly.

leonk wrote:
- When I dump a GAR, the BIN file is created in the done plugins directory rather than where normal ROM dumps are stored. Further more, the program doesn't ask me for the save filename.


The QBASIC client did exactly the same thing in this case. My priority was to get the code working and THEN find ways to improve it - now that I know it works, I can take care of this issue as well.

leonk wrote:
- GAR bin dump files seems to be in "locked" mode until CopyNESW exits.


Thanks for pointing that out - a new build is now available to fix this particular bug. I'll take care of the other GAR stuff in a bit.

by on (#10651)
I just updated to the newest version of CopyNES. I now get the following error when I try to use write WRAM:

unable to locate category - please update MAPPERS.DAT!

???

by on (#10652)
leonk wrote:
I just updated to the newest version of CopyNES. I now get the following error when I try to use write WRAM:

unable to locate category - please update MAPPERS.DAT!

???


Follow the instructions on the website - they tell you how to update mappers.dat to fix this problem.

by on (#10657)
ok. thanks!

I'm not too familiar with basic. Will it work under XP? Also, is there a reason why the modified file isn't shipped with your version? (name it something else, and tell users that they can rename it if they have problems).

by on (#10659)
It'll run well enough to update mappers.dat.

The reason I don't include mappers.dat is because some users have updated theirs, and I'd rather not cause them to lose their changes. Besides, the next release of the QBASIC client (whenever kevtris gets around to releasing it) will include these changes.
Re: CopyNESW bugs / feature request thread ...
by on (#108734)
Couldn't find a better thread, so I'll just say it here:

2 users are trying to backup prototypes on NintendoAGE. 32KB PRG, 32KB CHR. I checked the source for them and looked at T*ROM source. There was a bug fix note for the board they needed, but they're still having problems, so I doubt it was fixed. Anyone able to edit the copynes source and fix said dump problem?
Re: CopyNESW bugs / feature request thread ...
by on (#108740)
What about trying TapeDump from Chris Covell?
Re: CopyNESW bugs / feature request thread ...
by on (#108747)
Have they tried this version from this thread?
Re: CopyNESW bugs / feature request thread ...
by on (#109544)
3gengames wrote:
2 users are trying to backup prototypes on NintendoAGE. 32KB PRG, 32KB CHR. I checked the source for them and looked at T*ROM source. There was a bug fix note for the board they needed, but they're still having problems, so I doubt it was fixed. Anyone able to edit the copynes source and fix said dump problem?


Can you provide more specifics about the problem they are having? (or a link to the NA thread?) The original TXROM plugin would mess up on 32KB PRG because it would tell the client it was going to send 32K or PRG but it would actually try to send more than that, which the client then would try interpret as the next data block header and aborting because of a bad header.

First, make sure they are using the correct binary of the plugin: http://bootgod.dyndns.org:7777/plugins/TXROM1.BIN It's possible that the plugin package they are using has the "fixed" source file but the actual binary never got updated.

If the problem persists, I may be able to help if I have more info. PM me a copy of the bad dump if you can get it.
Re: CopyNESW bugs / feature request thread ...
by on (#143363)
Big ol' necrobump...

Regarding the parallel port version of this software, currently there is no way to flash PowerPak BIOS unless you have the USB version. If you have the time and/or interest can you please take a look at this?
Re: CopyNESW bugs / feature request thread ...
by on (#143423)
B00daW wrote:
Regarding the parallel port version of this software, currently there is no way to flash PowerPak BIOS unless you have the USB version. If you have the time and/or interest can you please take a look at this?


The parallel port version should support exactly the same features as the USB version, since it actually supports both parallel AND USB.

If I'm reading things correctly, you want to select "RAM Cart" mode and then choose the "PowerPak Boot" plugin, then upload a ROM image with mapper 2 (UNROM), 64KB PRG ROM, and 0KB CHR ROM.