FDS Copying, dumping, loading, etc methods

This thread is a continuation of an accidental thread-jacking of Kevtris's CopyNES thread:

http://nesdev.com/bbs/viewtopic.php?t=642

Let's discuss FDS and its various methods for copying, dumping and loading disks. Also, whatever a gamer must know to get his/her FDS running in tip-top shape would be welcome here too.

For starters, here is a tototek thread that involved discussion of many of the FDS copying/dumping/loading methods:

https://tototek.com/phpBB2/viewtopic.ph ... 02f0e34f86

To continue where the thread-jacked thread ended off, a question: If the FDS can write to a small part of the disk, but must make a full pass due to it's inability to seek, how does it go about finding the small part of the disk to write to....like a save file? Does it basically have to start at the beginning of the disk to count to where it needs to be because of it's inability to skip disk sections?

Also, does a save file always get writtien to the same part of a disk, or is that software dependent?

-Rob

I don't know the low-low level but games generally call upon the BIOS' routines to read/write/modify/add/remove "files".

I suppose saves can be placed in any file on the disk including PRG files.

Brad Taylor's FDS doc covers just about everything:

http://nesdev.com/FDS%20techni ... erence.txt

One problem I found with dumping games with Brad's FDSloadr is that some games give an error when replayed after a dump due to bad CRCs. I understand other dumping methods (Pasofami, I-Line, maybe others...if anyone knows, please elaborate) were able to code around this.

I guess Brad wasn't really sure how to, though his techniques are excellent at loading and writing to disks.

I wonder if Tomy's upcoming product will find a way around this. I think Brad told me once he'd release a new version of FDSLoadr if there was a sure way around this. Anyone have any info on the CRC routines to defeat this software form of copy protection?

-Rob

Do you mean protection regarding track length or protection regarding data integrity?

-K

Not necessarily protection but you know what I mean

-K

Quote:

Do you mean protection regarding track length or protection regarding data integrity?

-K

Well, I guess I'm not sure what you mean by your question. However, I was mainly referring to dumped disks giving error messages on screen due to them not having been made by an "official" NOJ approved source. I guess I meant in general, but I'd like to know more about what you mean.

-Rob

Are you sure it's due to bad CRCs?

I remember hearing about how it couldn't properly detect data past a certain point which some games may fuss about.

Quote:

Are you sure it's due to bad CRCs?

I remember hearing about how it couldn't properly detect data past a certain point which some games may fuss about.

Well, I'm pretty sure, yeah. I remember speaking to Brad about this, and I believe that is what he explained to me. I think I remember reading about it on some sites too in my research, but I can't remember where for the life of me.

I thought only Bung disks and other copiers and maybe some pirate disks used data beyond the 64k per side (had data beyond what is normally read). No official images I know of go beyond the 128k.

-Rob

You're right only Bung disks (Venus/FFE) are that large.

See "Software disk copy protection" in Brad's doc for what I'm (pathetically) talking about.

PS, my GM dump is lost so I'll have to dump the BIOS again :( What's worse is that I'll have to convert it from ASCII "hex" format to binary since my only working programmer is from 1994 and stupid like that.

You know, Kyuusaku? You are absolutely right about the invisible files issue...damn, my memory completely failed me I realize as I went over Brad's original emails. Man, how could I mess up a thing like that in my head...oh well. Memory is so strange...sometimes it's like it makes things up without telling me. THANK YOU!

Brad's program does indeed calculate the CRCs itself. The 16 bit CRC after each file block are not present on the portable file format (disk image/rom), but are on the actual disks. For some reason my memory was telling me this wasn't compensated for in FDSLoadr, but it totally was. Anyway, I thought that was what caused the "SORRY...PLEASE USE
OFFICIAL DISK WRITER SHOP" errors, but I was wrong. Lol, lesson learned...never question Kyuusaku, heh heh

In Brad's doc:

Quote:

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.

I did manage to find one of his emails to me that basically explained the error message I got on screen was likely due to this.

Maybe I'm not totally crazy...maybe I was thinking that with these invisible files missing, the CRC check came out bad? Or am I really totally off?

Anyway, I hope Tomy's upcoming product is able to compensate for certain issues Brad's FDSloadr didn't address, first of which is timing issues that were extremely tricky for him to code due to the processor intensive timing necessary. Brad wanted to avoid making users use outside components other than the cable (like a custom board), as I understand it, so it was tricky to make up for this in softtware...I'm sure he could have easily made a hardware design to make up for this, but likely wanted it to be user friendly and make it as portable a package as possible.

So, aside from that and the invisible files issue, Brad wanted to make is useable on modern OSs (which wasn't possible partly due to the timing issues). I can't wait to see Tomy's design.

BTW you mentioned your Game Master and GameMaster Boy bios images were completely identical, right? Did you mean in appearance or byte for byte? Any idea how similar they are to thhe GM Kid proto bios I sent ya?

-Rob

From what I understand, Tomy's thing is some sort of "passthrough" device, like a GD. It was going to have some sort of hacked Copy Master built in and the ability to remotely access the RAM via parallel. I can't remember if Copy Master can read a disk (store it) then write it or if it has to copy a disk in 1 operation. If it can do it in 2 steps, his IPL may have revolved entirely around Copy Master. Operation would have been like: read disk on Copy Master, transfer to/from PC I think, write with Copy Master. If it still has all the ability of Copy Master, it should be able to make bitwise perfect copies of games.

Game Master (Doctor) and the earlier Game Master BOY use literally the same BIOS, only the hardware is (very) different between them. I haven't compared the GM Kid yet but will when I get the BIOS dumped again.

Quote:

I can't remember if Copy Master can read a disk (store it) then write it or if it has to copy a disk in 1 operation.

Hmm, you mean you don't remember if Copy Master reads both sides (one then the other), and then writes both sides (one then the other)?

Or if it goes like this: read side 1, write side 1, read side 2, write side 2?

I guess I'm not sure what you mean by "copy a disk in one operation"....

I'm not sure how it worked either, since I don't have a GD6+ yet to test Copy Master on (it did require this, right? Or could Copy Master work without the GD6+?).

When you say a hacked Copy Master program is built in, do you mean it is integrated into the hardware, or it comes seperately on a disk? Since Copy Master is an FDS disk program, it would be quite genius to have it somehow integrated in hardware...turn the unit on and Copy Master automatically loads. But, just dreaming here, if that's the case, awesome.

Was Copy Master only compatible with various GD-like devices, or did Bung limit it to the GD 6+? Is there a difference between GD6 and 6+?

Does Copy Master work in conjuntion with a PC, or was it strictly limited to FDS-centric copying?

-Rob

Can't remember if it has a single "Copy Disk" function or if it has "read disk" (and then "write disk" functions) so that you can for instance write as many times as you want at your leisure. I'm starting to think it reads then immediately writes (ie "Copy disk" function only), it wouldn't be hard to hack it into two seperate operations but this complicates what I thought was Tomy's Tool's operation. Any screen shot will prove what it does, I just forget, it's not something I used often.

Yup, I mean integrated into the hardware as a ROM.

Copy Master doesn't need a TGD6+, it will run on any Doctor units except possibly Game Converter and GD1M (1987 units) also may not on FFE units because FFE tried to make their disks proprietary. BTW, the GD6+ is a rival unit by Venus. When someone says GD6, GD6+ etc, they're talking about the same unit, there are two different cases for the TGD6 (one has a sticker and one has the name engraved in the plastic) but they are exactly the same.

Quote:

Yup, I mean integrated into the hardware as a ROM.

WOW! Great move on Tomy's part...sure will save a lot of time, effort, disk wear and frustration, heh heh.

Cant wait to see the PC side software too.

Quote:

BTW, the GD6+ is a rival unit by Venus.

Oh yeah, forgot about that. AKA the TURBO Game Doctor. They certainly tried to play off of Bung's product name. What was the equivalent Bung unit (or was there one)? Afaik the GD6 was as good as it got for fds based 'copier' units.

-Rob

I can't seem to download the newly translated FDSCOPY links that memblers posted. I downloaded emule but I can't connect to the server. Is this typical?

ChimyFolkButter

Do you have emule?

-Rob

Yes, I tested the ports and opened up my firewall. It can't connect to the server.

Here is the log:

11/2/2005 12:58:40 PM: Connecting to NESDEV (69.136.7.34:4900)...
11/2/2005 12:59:01 PM: NESDEV (69.136.7.34:4900) appears to be dead.
11/2/2005 12:59:01 PM: Failed to connect to all servers listed. Making another pass.
11/2/2005 12:59:01 PM: Automatic connection to server will retry in 30 seconds

Oh yeah, you're right...those links aren't working. Memblers, any ideas on that?

-Rob

Worked for me the day after he posted them

I haven't had emule running much the last few days (forgot). Got it running now, but at odd hours.

Oh well, I can't download the file. I do have a question about the circuit. I can make out most of the circuit but I can tell where the collector of the transistors connect to on the FDS drive board (not the power supply). Can someone describe which points they connect to?

The circuit layout I am referring to is page 6 of FDS-COPY. I see the WRITE GATE, WRITE DATA, GND, Vcc, and READY wire. The collector connection are in Kanji. I can't really make out what soldering point the wire are connected to.

Thanks,

-Al

Simplynes was awesome enough to offer to host the files too. For those that had trouble getting them from emule, here's another solution for you. WinRAR required.

http://simplynes.emucamp.com/copytool.html

THANKS, Simplynes!

Folks, please let me know if you see any innaccuracies or things I need to correct in these docs.

-Rob

THanks!

Hello everyone!

Sorry that i write in this old thread...

But can anyone upload the files from simplynes,who discribe "remove the write protection" ?
I could find anything in the net=(

And btw, sry for my english, im from austria

thanks

NESler, are you talking about the translated article from Backup Technique? I did that translation and I still have that if that's what you need. Send me a PM and I'll remember to post a download link.

-Rob