the error is a result of a simple software-based copy protection scheme. here's more (from the "FDS technical reference" guide, available at nesdev.parodius.com):
************************************
Software disk copy protection
-----------------------------
Special thanks to Chris Covell for bringing this to my attention.
Apparently, some FDS disks implement a very simple copy protection scheme, which the game relies on in order for the game to refuse to work on the copied disk. Normally, the number of files that exist on an FDS disk is stored in the second block recorded on it. However, some games maintain "invisible" files, which are basically files that exist beyond what the file count number in the file count block indicates. This poses somewhat of a problem for copy software like FDSLOADR, since these tools rely on the file count block, and don't assume that there is any valid data past the last file found on the disk. This means that when these types of disks are copied, the invisible files will be lost, and when the game loads the files that do exist, the game's going to give the user heat about there being a file missing or somthing, gumming up the works. However in practice, when an FDS disk is programmed, the unused end of the disk is usually completely zeroed out, and this makes detecting the end of the disk simple: just wait to find a GAP period of extreme length. Except in rare cases, this model for detecting the true end of an FDS disk should generally provide the best results for copying the complete contents for all types of FDS disks.
**************************
so in other words, FDSLOADR can't really dump games of this type (I designed it before I was even aware of the software disk copy protection scheme). However, have you ever heard of
www.edgeemu.com? they host some 200+ FDS ROMs (along with ROMs for about 50+ other game platforms too), so you may not even need to dump your own FDS games (well, unless you want to preserve saved game files).
In the short run, I can't really help you. I've discontinued development of FDSLOADR quite some time ago. If I had someone/people to work/collaborate with, I may consider revising it with relivant updates (like circumventing the software copy protection), but these days I've been busy with more advanced projects (like starting an integrated NES/SNES emulator, and even designing a 3D-based operating system). It would be nice to be able to pass the torch on to others who want to improve the quality of the FDSLOADR software (and to be specific: produce a working program under modern OSes), but the program needs dedicated processor time (as this was the trade-off for using no discrete digital electronic parts), which doesn't really make it suitable for development on multitaskable OSes like Linux or that other one I hate.
The real problem is manpower here. I originally wrote FDSLOADR in assembly, but nowadays reading assembly code makes me cringe (as I now use schematic diagrams to display how software works with pictures, meanwhile maintaining the equivelant logic function granularity that assembly is famous for). At any rate, the whole program's architecture needs to be re-designed, and this not somthing that can be done in a short amount of time (as the existing version took 5 months to code, not to mention the time I spent changing the program to adapt to the speed of the PC it runs on).
Anyway, let me know of your progess,
peace.