How to at least partially read damaged sectors of floppy disk?

At secondary school I was dealing with Agat computers at school computer class (exactly, this was Agat-7), approximate clones of Apple II series. Their 5″ diskette drives were also clone of 140kB drives designed by Steve Wozniak and Shugart for Apple II, with hardware adjusted to what could be produced in the socialism camp. One may find a deeply detailed description of the drive here. There were some weird design choices, as the absense of an zero track sensor. To seek to the zero track (after reset or I/O error), it unconditionally performed 160 steps of the head position stepper motor. This caused gradual disbalancing of the head positioner through regular impacts into seeking limiter (with a loud, machinegun-like burst sound). As result, at my final class at the school, the computer lab consisted of 3 groups of 3 computers each, where one computer can easily read diskettes written by another computer in the same group, but struggled with diskettes from other groups. And, this issue was known throughout the entire Agat park.

To solve the readability problem, a program called COPYTREK was developed (by a Moscow firm associated with the factory that produced these computers) to recover unreadable diskettes. It tried to read all sectors of a track in the following manner:

1. It applied brief affections to the stepper motor to make it turn to an angle less than a single step, positioning the read-write magnetic head at offsets like "1/8 of the track interval", or kept two neighbor phases turned on to position the head just between them. A sector was being read multiple times with different head offsets, to find a best reading result.
2. Besides (1), multiple readings were applied to find unstable bits and statistically determine a most probable variant.

There were no algorithmic recovering due to lack of redundant bytes (as most current drives utilize Reed-Solomon or similar methods), only a single XOR CRC byte, but this was enough in most cases. After reading, user could command the program to write a track back to diskette, according to the current drive "tuning". (It would ask if you wanted to replace the diskette with a target one, if you preferred to preserve the original.)

All this weird magic was specific to so-called 140kB Shugart drive (35 tracks of 16 sectors of 256 bytes). Just after my graduation from the school (1990), it had got a few computers of a new model, with 840kB drive that was saved of this issue due to adding of zero track sensor. (But this was time of a speedy decline of Agat usage due to import of MSX and IBM PC series.)

I hope this will answer your question, despite this was not PC specific.

In most cases yes.

Utilities were available for most computer systems of the '80s and '90s that would read the disk at a low-level and attempt to deduce the track/sector information. These reads would bypass the filing system software - going directly to the controller.

For example, the Intel PC had Norton's Disk Doctor, amongst others. The BBC Micro had Computer Concept's Disc Doctor. Such utilities would have commands to read at low level as best they could. The recovered data could then be examined and edited reconstruct the valid information. This could then be saved.

The example Disc Doctor command to read was *RECOVER, an extract from the instruction manual is below.

Of course, if the disk were too badly corrupted, you couldn't recover anything.

What you really want is SpinRite by Steve Gibson (Gibson Research Corporation), which reads the surface of the disk repeatedly, until it derives the data from a failing byte structure, giving a very high degree of data integrity.

Typical software for drive recovery only makes a single pass, but SpinRite is user-configurable to run a large number of repeated attempts on a single sector.

Quite often the magnetic properties of a single byte survive, but at too low a level for traditional software to reliably detect it with a single pass on the sector, but Spinrite uses a special algorithm which, in my experience, is particularly effective.

The first version was released in 1987. The final stable release for DOS/FAT filesystems was version 6.0, released June 7th 2004.

If the actual task at hand is recovering such data at any cost and effort, there is still the possibility of directly recording the read head signal on some recording and visualization device, eg a secondary PC with an analog data acquisition card, or a storage oscilloscope, then decoding it manually. Triggering the recording at the right moment could prove tricky, forcing the computer into a repeated read attempt for that sector could help. If the recording device can hold the analog data representing a whole track, using the signal from the index hole sensor as a trigger and making sure the track the damaged data is on is seeked to and not left could help.

Linux/Unix/Cygwin/winUnix utilities - has a command that will will read sector information regardless of it's integrity, security, purpose or format. If a storage device is physically capable of reading the data, the DD command will capture it. The DD command uses raw low level hardware requests directly to the storage devices hardware (when available) to get the information.

copy floppies

Linux dd cmd

dd disk cloning examples

Actually reading a disk is easy with ST Recover, it uses a special method of reading the disk that reads disks that are damages , ie unstable. it then trys to read bad secors and recover sufficient information from the damaged sector. The program ST Recover works on Atari ST disks and creats an image called a .ST file ,which then can be read on either Omniflop of FloImage (these two programs require an internal floppy drive in your PC), but ST recover can read normal 720 K disks whether they be Atari or PC. It will write a PC disk out as an Atari file but that is easy to write back out as A PC file. I will of course post the zip file for ST REcover here if allowed. Russ

Some floppy controllers only let you access the disk with sector/track level. So they succeed or fail at that level. You don't have any control at a lower level.

The Apple ][ and Macintosh floppy access was all done in software in the standard processor addressable memory like any other program. Additionally in the Apple ][ the code only knew where one nibble on the disk started and ended because the code was written taking the account of how every machine code instruction took. So, at that level, sectors didn't really exist and where only created by the patterns written to the disk. This meant you could read a whole track of data into memory no matter how corrupt. Whether it could be recovered would only depend on our skill and what remained.

Nowadays, the best hope for recovering data would be to use some kind of data acquisition subsystem to continuously sample the data output from the drive at a rate at least 4x the hardware's bit rate for a few seconds while the drive is spinning and the proper track and head have been selected. This will make it possible to observe some things about the nature of the corruption which would be invisible to an ordinary controller. Among other things, if one reads data for e.g. 3 seconds, then most sectors will appear about fifteen times. If one takes those traces and lines up the start of each sector, any data bits before the corruption will appear in almost precisely the same place on all fifteen times. Further, there may be some bits after the corruption which again show up identically on all fifteen reads.

If there's a glitch that clobbers a dozen bits, but the weaker domains cause the drive to produce signals that only look like it saw eleven bits, nothing past the glitch will be readable by a normal controller, but looking for parts of the data which have consistent repeatable timing will make it possible to identify exactly what parts are glitched, and how many bits would need to be in the glitched section to make everything else line up.