I created RAW images from a 40 Track DD disk containing FM 125 KBit/s tracks, 18 sectors by 128 bytes, original drive RPM 288.
The drive used to create the image is DD 40 tracks 300 RPM.
When I write back the stream files to disk on the 300 RPM drive, the last sector of half of the track results in CRC error.
Using the -w parameter does not seem to have any influence.
What may I be doing wrong?
Command used to create the image:
DTC -p -e39 -g0 -fD:\myimage_ -i0
Command used to write back the image to disk:
DTC.exe -f"D:\myimage_00.0.raw" -e41 -d0 -dd1 -we2 -w
The kryoflux system doesn't control the motor speed of the floppy drive, basically, with a 300 RPM drive to write a disk normally written with a 288 RPM drive, you get a sector chopped up, hence the CRC error.
Maybe DTC changes bit width to the next matching standard? For example, if the orginal bit width was 8us, they would come out of the 300 RPM drive with 7,7 us. If they were blown up to 8 us before writing, the track would need more space, so the last stuff would not fit on disk again. It would either overwrite the original start of the track (but then, the last sector would be okay) or the index pulse stops the writing to disk.
Another idea: if writing the track starts with the falling edge of the index pulse and stops with the rising edge, then there would be a small area where data is not written.
IF the index pulse width is maybe 200 us (I did not yet measure it) this makes 40 bytes ...
What do you think?
As far as the KF hardware is concerned, a disk written at 300RPM or 288RPM makes no difference - the flux reversal width read will change for the same bitcell proportionally to the RPM difference.
e.g. as an easy example a 4us bitcell read at 300RPM would be 2us at 600RPM or 8us at 150RPM - but it's still the exact same bitcell.
The KF software has many pipeline stages that make sure that data read from a track at any speed can be written back at any speed. During writing the host constantly measures the RPM and modulates the bitcells to match their original size read as close as possible given the RPM measured.
If the drive speed varies wildly, that can be a problem indeed, but if it's reasonably consistent, or predictably changing it should work.
All bitcells present in a stream read will be written back to the disk - so data shouldn't be missing.
Some drives have pretty bad index signal jitter - if the actual track data is fairly close to the index signal that can cause problems. It's not a problem during reading (other than incorrect index signal location), but stream writing is currently index synced, therefore a few bitcells very close to the index signal can get split during writing. This is not an issue since that data is not legit, however, if the index signal position was incorrect that means at least 1 legit bitcell will be split. Note, that this is not a problem during reading, as the host continuously samples the same track without interruption (ie, not from index-to-index) for several revolutions, so no matter where the real write splice is on the track all bitcells will be present in the stream as is.
Could you please post the original track data read, written and re-read as stream files?
Writing back IPF and G64ext files works differently - they do support having a write splice anywhere in the track. This information is simply not available in a stream (so stream write has to resort to using index syncing), it requires very complex analysis which is in fact being worked on.
It does not bother DTC while it's decoding a track - it picks up the best parts available even from pretty badly readable track data.
However, writing back such data will simply replicate the bad data.
Again, this is something that the upcoming DTC will be able to deal with - it can actually measure sampling consistency and it will be able to stitch the most consistent flux reversal samples together for writing.
As a side note, keep in mind that consistently read data can be consistently bad data - so while this feature will be able to work out the most likely "correct" flux reversals present on the track, there is no guarantee that it is actually correct (just very likely). Correctness can be checked to some degree by considering that outliers are less likely to be correct and the host software takes that into account when it encounters ambiguous flux reversals - but nothing compares to the correctness of actual data decoding and reconstruction for writing.
The good news is that if you convert them to Imagedisk or similar format you can re-create index aligned stream files, using some third party tools or even a real PC, and if there is no copy-protection involved then the resulting copies should be readable on an Atari drive.