As has been discussed previously, the current Famicom Disk System file format (*.FDS) is flawed in several ways. It does not archive the GAP periods, block start marks, or CRCs. While it is a marginally acceptable format for interoperability with emulators, it falls far short as a format for archival and preservation. This is an especially important issue since Disk Cards are not only notoriously prone to failure, but in many cases it is impossible to get a clean dump if the game has ever been played (since additional files are written to the disk). That means that clean dumps are dependent on the ever-dwindling supply of sealed Disk Cards. If the community does not act soon, these may be lost forever. And if people are to go to the trouble of buying expensive sealed games and dumping them, then it's important to do it right. The dumps should be 100%, bit-for-bit congruent with what is actually on the disk.
I am not going to define a new file format specification at this point. Instead, I am going to bring up several thoughts I have had, while carefully reading existing documentation on the FDS. Brad Taylor's document was especially helpful.
*To get accurate dumps, the RAM-adapter would probably have to be bypassed. The RAM-adapter does its own processing on the data, and we want to get exactly what is on the disk, no more and no less.
*This means hooking the FDS cable up to the parallel port. /WRITE would be tied high, because only read operations would be desired. The program on the PC side would have to pulse the /SCAN_MEDIA line, then wait for the falling edge of /READY. The READ DATA line would be hooked up to the parallel port's ACK line, so that an IRQ would be generated whenever the drive put out a pulse. The program would measure the timing between pulses and use that to reconstruct the FDS bitstream.
*As per Brad's FDSLoader document, IRQ would be the only reliable way to read the microsecond-length pulses on a LPT port. And this means the dumping program would have to run in DOS.
*According to Brad's document, "The "-ready" signal is based on a mechanical switch inside the drive which is activated when the head is brought back to the outer most edge of the disk (the beginning). Because the switch will usually be triggered prematurely, the first 13000 bits (approx.) of data the drive will send out immediately after this switch is activated will be invalid." Does this mean that it is impossible to accurately measure the length of the initial GAP period at the start of a Disk Card?
*Reading the documentation, I am not quite clear if the start mark is a single high bit, or a byte $80. Or, since data is sent in low-endian bit format, does the adapter see the lone high bit and then derive the $80 byte from that bit plus the previous seven zeroes from the GAP period? I suppose if I actually built the thing I could look at some dumps and see what the format actually was, but right now this is all hypothetical.
I'm still trying to puzzle out how to reverse the pulse timing back into a coherent data stream. I had a few ideas but they don't seem to account for all the cases.
I am not going to define a new file format specification at this point. Instead, I am going to bring up several thoughts I have had, while carefully reading existing documentation on the FDS. Brad Taylor's document was especially helpful.
*To get accurate dumps, the RAM-adapter would probably have to be bypassed. The RAM-adapter does its own processing on the data, and we want to get exactly what is on the disk, no more and no less.
*This means hooking the FDS cable up to the parallel port. /WRITE would be tied high, because only read operations would be desired. The program on the PC side would have to pulse the /SCAN_MEDIA line, then wait for the falling edge of /READY. The READ DATA line would be hooked up to the parallel port's ACK line, so that an IRQ would be generated whenever the drive put out a pulse. The program would measure the timing between pulses and use that to reconstruct the FDS bitstream.
*As per Brad's FDSLoader document, IRQ would be the only reliable way to read the microsecond-length pulses on a LPT port. And this means the dumping program would have to run in DOS.
*According to Brad's document, "The "-ready" signal is based on a mechanical switch inside the drive which is activated when the head is brought back to the outer most edge of the disk (the beginning). Because the switch will usually be triggered prematurely, the first 13000 bits (approx.) of data the drive will send out immediately after this switch is activated will be invalid." Does this mean that it is impossible to accurately measure the length of the initial GAP period at the start of a Disk Card?
*Reading the documentation, I am not quite clear if the start mark is a single high bit, or a byte $80. Or, since data is sent in low-endian bit format, does the adapter see the lone high bit and then derive the $80 byte from that bit plus the previous seven zeroes from the GAP period? I suppose if I actually built the thing I could look at some dumps and see what the format actually was, but right now this is all hypothetical.
I'm still trying to puzzle out how to reverse the pulse timing back into a coherent data stream. I had a few ideas but they don't seem to account for all the cases.