As per the title... Any suggestions on a DOS utility to image and backup 360kb floppies to image files I can offload? Ideally something with some sector retry abilities and graceful handling of read errors rather than just crapping out.
Try firm.com (attached), it should run on an XT-class machine.
Swiego wrote on 2020-04-04, 05:39:Ideally something with some sector retry abilities and graceful handling of read errors rather than just crapping out.
"crapping out" is the only correct way to do it, because there is no way to tell that there were any read errors once the image is made. This is the source of many broken/non-working disk images floating around. If you have a disk that can not be imaged because of read errors, do a file copy instead. This way, you know at least which files are damaged.
Thats correct. Copying files is the better option.
Last time I made floppy images I used the attached program. Its output is quite informative and I kept the log files together with the image to know if it was OK or not.
Insert SOURCE diskette into drive a:
Press any key to continue . . .
Copying 2880 clusters, 1 sectors per cluster, 512 bytes per sector.
Relevant drive size is 1474560 bytes.
Creating image file . . . (0000/2880) (0032/2880)
Media error reading from disk, rescanning...
(0064/2880) (0096/2880) (0128/2880) (0160/2880) (0192/2880) (0224/2880) (0256/2880) (0288/2880) (0320/2880) (0352/2880) (0384/2880) (0416/2880) (0448/2880) (0480/2880) (0512/2880) (0544/2880) (0576/2880) (0608/2880) (0640/2880) (0672/2880) (0704/2880) (0736/2880) (0768/2880) (0800/2880) (0832/2880) (0864/2880) (0896/2880) (0928/2880) (0960/2880) (0992/2880) (1024/2880) (1056/2880) (1088/2880) (1120/2880) (1152/2880) (1184/2880) (1216/2880) (1248/2880) (1280/2880) (1312/2880) (1344/2880) (1376/2880) (1408/2880) (1440/2880) (1472/2880) (1504/2880) (1536/2880) (1568/2880) (1600/2880) (1632/2880) (1664/2880) (1696/2880) (1728/2880) (1760/2880) (1792/2880) (1824/2880) (1856/2880) (1888/2880) (1920/2880) (1952/2880) (1984/2880) (2016/2880) (2048/2880) (2080/2880) (2112/2880) (2144/2880) (2176/2880) (2208/2880) (2240/2880)
Media error reading from disk, rescanning...
(2272/2880) (2304/2880)
Media error reading from disk, rescanning...
Unreadable sector at position 2334.
(2336/2880) (2368/2880) (2400/2880) (2432/2880) (2464/2880) (2496/2880) (2528/2880) (2560/2880) (2592/2880) (2624/2880) (2656/2880) (2688/2880) (2720/2880) (2752/2880) (2784/2880) (2816/2880) (2848/2880) (2880/2880)
For data recovery, I only trust tools that I wrote myself anyway. 😁
Cool!
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//
As per the title... Any suggestions on a DOS utility to image and backup 360kb floppies to image files I can offload? Ideally something with some sector retry abilities and graceful handling of read errors rather than just crapping out.
On Windows, WinImage will do that. On DOS, not sure. Try QCopy 4 or Disk Copy Fast (video).
PS: I'm not sure if this is helpful, but I wa wable to read troublesome 5,25" floppies by holding the drive lever manually in position.
Sometimes a bit higher, sometimes lower. At some point, the drive was able to read the sector and WinImage was happy.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//
Thanks both - I'll try both Firm and dc. Will try qcopy too if the first two don't pan out so well.
I understand the risk of broken images but in this case I want to image disks that were part of a backup-to-floppy set (not sure the backup software originally used just yet) so I'd like to get the most complete image I can. I do have a drive connected to a modern computer with FC5025 but I have now found at least a couple of cases where the old 360kb drive on my old XT reads data that the NOS Teac 1.2MB cannot w/FC5025 / Windows 10 so I'd like to use the XT for secondary copy attempts.
For reference, qcopy and firm won’t work - both seem designed for more modern hardware. Firm’s docs focus on 1.2mb disks and it craps out after the first track. Qcopy thinks my a drive is a 1.44mb drive.
Dc... having an issue. It images 360kb disks just fine. However when I image the same disk twice, then do a binary compare, invariably FB hex words become FF and vice versa... randomly, not always, but often. This happens on multiple good disks, and happens whether or not I use the /r flag (recovery mode?) or the /v verify flag. I’m not sure what’s going on or if I’m getting good images. A bit frustrated...
Performing the binary compare with fc from Norton Utils 4.
Any ideas?
@Swiego
I hope you can post the results here. Like to know which program did fixed the job.
~ At least it can do black and white~
This is after freshly formatting a disk with DOS 5.0 (system transferred) then using DC twice back to back, then comparing the images.
I see the same behavior from my a: and b: drives for any disk with any data on it.
When I imaged the bunch of my 5 inchers I've used RESQFLPY. Don't know if that works on XT, but it's a super simple program and strictly writes to a specific filename and never autodetects disk types. I had better luck with that than VGACOPY etc.
and yeah it's weird how there's still no clonecd-esque format for floppy images that logs which sectors are bad/weak..
Swiego wrote on 2020-04-04, 22:26:CDDFFBE1-0FBE-498D-B9D0-0707CAE7C6F5.jpeg
This is after freshly formatting a disk with DOS 5.0 (system transferred) then using DC twice back to back, then comparing the images.
I see the same behavior from my a: and b: drives for any disk with any data on it.
Thats really strange....!?
And when comparing to an image made with another program..?
It may be explained with read errors on the disk. But when it happens with different known working disk..?
Looks like a bug to me...
Swiego wrote on 2020-04-04, 22:12:Firm’s docs focus on 1.2mb disks and it craps out after the first track.
That's odd. While I did not use FIRM on my XT so far, I dumped many of my original 360kb disks with it on a 286. So it should not have trouble with such disks.
On the other hand, if DC gives you random data each time, you may have some deeper hardware issue and FIRM may bail out because of this, too.
If you want persistence when trying to read a sector, try dskimage from the author of mTCP: https://www.brutman.com/PCjr/pcjr_downloads.html
From the readme: "DskImage is a little different than other diskette imagers in that it will retry a bad sector a few times before giving up on it."
I've used (and many others) with success.
konc wrote on 2020-04-05, 12:35:If you want persistence when trying to read a sector, try dskimage from the author of mTCP: https://www.brutman.com/PCjr/pcjr_downloads.html
From the readme: "DskImage is a little different than other diskette imagers in that it will retry a bad sector a few times before giving up on it."
I've used (and many others) with success.
I wrote DskImage when I was trying to image my original DOS diskettes from 1984. If the sectors are marginal a few retries often does the trick. DskImage can be told to retry a bad sector up to 10 times via an environment variable.
Other tricks include cleaning the heads often and trying different drives. Just a small variation in the drive heads, positioning or electronics can be the difference between a good read of a marginal sector or a failed read.
I found a tool called Test Drive that does a nice read/write/compare. Each time I run it I see a few compare errors in different locations. The number of compare fails increases over times then goes to zero after the PC has been powered off for some time.
So, I think there is another issue here I need to sort out... likely hardware related.
