X-Copy: Verify error copying real disk to ADF image #519
Comments
|
8 is a verify error. Interesting. Is it always the same track regardless of writing to HFE or ADF? |
|
I don't get the verify error on HFEs, only on ADFS, but the resulting HFEs still don't work. |
|
Okay, so it's a copy with verify enabled, copies to HFE with no verify error, but the HFE is still bad anyway? Can you share an HFE image? |
|
One thing you might want to try is v4 prerelease: https://github.com/keirf/FlashFloppy/suites/3437359731/artifacts/81480541 |
|
And it might also be interesting to try a smaller USB drive if you have one. The larger ones don't always like small writes and can be slow on them. Sandisk is obviously a good brand though. |
|
Ok, I will try when I get off work. |
|
Sorry for the delay, but I've done some more testing. Tried the v4 prerelease - didn't help. Tried a 16GB Sandisk Cruzer Blade - didn't help. I discovered that the HxC Emulator Software won't recognize any non-empty HFE-image I throw at it. Don't know what that is about. The Track Analyzer shows CRC errors. Don't know if this means all the HFEs my Gotek writes to become corrupted or what. Anyway, it means I cannot easily convert the HFE images back to ADFs. I tried, but then I get a read/write error after booting from the resulting ADF. What does seem to work, however, is using the RAM copy mode in X-Copy, meaning the tracks are first read from DF1: into RAM: then from RAM: to an ADF in the Gotek. There was a track or two during the writing from RAM to disk that temporarily showed the 8 (verify) error, but they quickly resolved into 0s. Track Analyzer shows no errors on the resulting ADF image. This may thus be a temporary workaround. The fact that switching from disk-to-disk copy to disk-to-ram-to-disk copy rather leads me to suspect a timing issue, but I'm no expert. I'm attaching a zip file containing the following four files: Copied DF1-ADF without verify.adf --> Straight from disk to ADF The disk in question is a copy of Tools for Fools 2, a utility disk by Equinox. I tried writing the RAM-copied ADF back to a physical floppy, and found I could do a straight disk-to-ADF copy of this disk with verify enabled without a problem. So maybe there is something about my copy of TFF 2 that makes X-Copy read it slower, for some reason, even though there is no straight up error per se? If it was just this one disk, it wouldn't be that big of a problem, really, but I have had it happening to several disks, and I was kind of hoping to use the Gotek to transfer all of my floppies to ADFS for safe keeping. |
|
I've checked both HFE images and although HxC complains about sectors which cross the index mark, the HFE images are both perfect and convert to bit-identical ADF images. I used my own Disk-Utilities tool (github:keirf/Disk-Utilities): |
|
The ADFs you supplied are also both bit-identical with each other, and with the ADFs I converted from your supplied HFEs. |
|
A good way to create ADF images by the way is a device like Greaseweazle and a PC floppy drive attached to your everyday PC. This can dump good disks fast to ADF. |
|
The issue with X-Copy may be that it makes assumptions that the track it wrote reads back identically: Whereas in ADF we throw away all but the sector data and then re-create a "perfect" index aligned track. I already made one tweak for X-Copy: until the heads are stepped I remember the order in which sectors were written and read them back to X-Copy in that order. However they will still be aligned to index. My guess is that perhaps that would need to be fixed here, to get a track that is "close enough" to what X-Copy originally wrote. |
keirf
changed the title
|
Yes, I know there are better ways of dumping floppies, like Kryoflux, Greaseweazle etc, and I didn't buy the Gotek primarily as a backup solution, but as an easy means of launching disk images from my Amiga. I just thought perhaps it might also be used as a quick and easy way to transfer disks between an Amiga and a PC. Besides, I like how X-Copy makes it easy to discover, and sometimes even help make a good copy of, tracks containing errors. Not to mention the warm fuzzy feeling of nostalgia from seeing the old familiar X-Copy interface. I may eventually see about acquiring a Greaseweazle, though. I have Amiga Explorer and a null modem cable, of course, but that is slooow. Didn't notice those disk utilities of yours. Add a link from the FF project, perhaps? Would be nice to have binaries, though. 😊 Since my images are all bit identical, I guess that means it's just the verify process that fails in X-Copy. I suppose I could throw caution to the wind and do without the verify step altogether, but I'm a bit wary of that. |
|
I wouldn't do without verify. Apart from the lack of verification, it means X-Copy storms ahead copying data to the Gotek without ever checking if the Gotek is keeping up (ie. it is writing "open loop" aka no flow control). Thus if there is a slow write or two to the USB drive, you can run out of buffer RAM in the Gotek and start losing data. This could theoretically happen even with verify enabled, especially on Artery Goteks, but it's less likely and the verify step should notice it and redo the write. |
|
I'll leave this ticket open. Ultimately probably need to try to reproduce it myself and then investigate if it's fixable. It will be something to do with the ADF track handling I'm sure. |
|
Which version of X-Copy are you running exactly? And this is in both DOSCOPY and DOSCOPY+ modes? |
|
Yes, although I've mostly used DOSCOPY+. I am currently using version 6.4, but I have also tried versions 2, 3.1, 3.4 and 5.21 from here: http://jope.fi/xcopy/masterdisk.html and they all produce the same error. The RAM copy mode seems to be working ok with verify at the moment, though, so I'll probably be using that as a workaround for the time being. |
|
...on a related note for the record: I have found that write operations will consistently fail at about the same place (about 75% in) when copying disks on an Amiga .adf file image to the Gotek. I was able to duplicate this for many flash drives on two different Atery gotek units running 3.37 code. I found the problem was due to USB write-latency, i.e., using slower USB 2.0 flash drives. |
|
The 415 Artery goteks are tough for supporting whole track writes as on Amiga. The best solution is probably a 435 based Gotek. |
Hi!
I recently purchased a Gotek with FlashFloppy preinstalled, it’s the Artery version, unfortunately. Currently running firmware 3.28.
My problem is I am experiencing write corruption when copying from a floppy disk to an ADF or HFE image in X-Copy on my Amiga 500 (Kickstart 1.3). I have the Gotek installed as DF0: and I am trying to copy from my external drive (DF1:) to a disk image on the Gotek.
When I use the Diskcopy or Diskcopy+ modes in X-Copy I sometimes get an “8” error during verify. Restarting the copy process or retrying only the affected track(s) gives the same verify error. It doesn’t happen on all disks, only on some, but I haven’t been able to discover any pattern to it. However, the problem occurs consistently on the same disks. Other disks are fine. The “problem disks” have no read/write errors or bad blocks (according to X-Copy anyway). The blank destination images were downloaded from the Flashfloppy Image Library on the FF github. The USB stick is a 64GB Sandisk Ultra, formatted as FAT32.
Oftentimes it’s track 0, side 2, sometimes it’s other tracks, but the error number is always “8”. If I run Checkdisk after copying, there’s no read error on the destination disk.
If I try to copy the same disk to an HFE image, I get no verify error. I can then list the directory (if it is an AmigaDOS disk) in X-copy. If I then try to load the HFE image in the HxC Emulator software, however, the image is unreadable and I can’t browse the directory. ADF images with the verify error can be browsed from the HxC software, but the Track Analyzer reveals that the image doesn’t match the original.
The text was updated successfully, but these errors were encountered: