Trivia question: Floppy Disk Controller "Read Deleted Data"

[tom9876543]

Hi,

I was reading the Intel 82077AA Datasheet.
1) Would someone know the purpose of the "Read Deleted Data" and "Write Deleted Data" commands? I guess it is related to bad sectors?
2) Does someone know precisely how sectors are arranged on the floppy disk? How does the 82077AA know if a sector is bad? Also there is mention of CRC, how is that managed?
3) If computer does "Read Deleted Data" on a good sector, I assume it returns an error? And presumably "Read Data" on bad sector returns an error?
4) If computer does "Write Deleted Data" on a good sector, does the sector also get marked as a bad sector?

Thanks

[Brendan]

Hi,

1) Would someone know the purpose of the "Read Deleted Data" and "Write Deleted Data" commands? I guess it is related to bad sectors?

The purpose of "Write Deleted Data" is to mark a sector as deleted (and write to it) such that the normal "Read Data" command will no longer read that sector; and the purpose of "Read Deleted Data" is to read a sector that was previously marked as deleted.

The intent may have been to use it to mark sectors as faulty, but it's not used for that by any OS (and as far as I know, it's not used at all by any OS). However, on OSs like DOS where applications can do whatever they like, it may have been used once upon a time for disk copy protection mechanisms (e.g. so that the disk's contents can't be read or copied without special software).

2) Does someone know precisely how sectors are arranged on the floppy disk? How does the 82077AA know if a sector is bad? Also there is mention of CRC, how is that managed?

The actual data written to the disk is mentioned in the relevant datasheet (including gaps, address marks, CRC field, sector data, etc). The floppy controller is responsible for calculating the CRC (for writes) and checking the CRC (for reads). The floppy controller assumes the sector is bad if the CRC is wrong; which means there's a chance that a sector is bad but the floppy controller didn't notice because the 8-bit CRC happened to match by accident (false positives); and also a chance that the data is correct and the CRC is bad (false negatives).

3) If computer does "Read Deleted Data" on a good sector, I assume it returns an error? And presumably "Read Data" on bad sector returns an error?

Yes. Specifically, it sets bit 6 (the "CM, Control Mark" flag) in Status Register 2.

4) If computer does "Write Deleted Data" on a good sector, does the sector also get marked as a bad sector?

Yes. Otherwise it'd be impossible for deleted data to exist.


Cheers,

Brendan

[alexfru]

This might give you some ideas (from 82078 doc):

6.1.5 WRITE DELETED DATA
This command is almost the same as the WRITE
DATA command except that a Deleted Data Ad-
dress Mark is written at the beginning of the Data
Field instead of the normal Data Address Mark. This
command is typically used to mark a bad sector con-
taining an error on the floppy disk.

Now, this is a command. It means, the controlling software must issue it, which, in turn, means the software must identify a sector as bad by failing to format, write or read it (write deleted data may fail too). The controller will report errors to the software.

I'm guessing, the command might also be used to mark unused sectors or sectors without data, so they can be skipped during reads.

[SpyderTL]

I think this is mentioned briefly on the FDC page:

http://wiki.osdev.org/FDC#Hardware_Cont ... _Cylinders

The FDC subsystem has a built-in method for handling unreliable media. However, it is probably not a good idea to use it. It involves finding a bad sector on the media, and then marking the entire track or cylinder as being bad, during the formatting process.

If you try to do this, then you cannot simply seek to a cylinder. All of the cylinders get "remapped" with new "TrackID"s. Whenever you seek to a cylinder, then you need to use the ReadID command to verify that the cylinder you seeked to contains the data that you actually want. So this eliminates any possibility of using implied seeks, and adds an extra step to most read/write operations.

[tom9876543]

Thank you for all the information.
I was looking at the floppy drive pinout, and it seems the pins are ANALOGUE? Is that correct?
The IDE 40 pin pinout has DATA pins, they would be digital (1 or 0).
I guess the cylinder head sector address is sent digitally via the DATA pins on IDE interface.
On the other hand, the floppy drive appears to have analogue pins.
Is RDATA an analogue signal sent from floppy drive to fdc?
This shows how primitive the interface is.

As the floppy disk controller has anologue output to the drive, how exactly does it seek to a specific head / track / sector?
The fdc would have to output a series of analogue signals??

[Nable]

No, data signals are digital but interface is serial (IDE is an example of parallel interface).
Seeking to specified track is rather easy: there are 2 digital inputs (I don't remember whether they are level- or edge-triggered but it's easy to find) - direction# and step#.
You set direction and then pulse the step input to move to next or previous track.

[Brendan]

Hi,

Thank you for all the information.
I was looking at the floppy drive pinout, and it seems the pins are ANALOGUE? Is that correct?

Yes and no (yes if you accept that digital signals are a special case of "analogue").

Is RDATA an analogue signal sent from floppy drive to fdc?

No, "RDDATA#" is a (digital) signal that uses some sort of "one bit at a time" serial communication.

As the floppy disk controller has anologue output to the drive, how exactly does it seek to a specific head / track / sector?
The fdc would have to output a series of analogue signals??

FDC provides a direction signal (DIR#, where low means "towards center of disk" and high means "towards edge of disk") and a step signal (STEP#). When the disk drive sees a pulse on STEP# it moves the heads in the direction indicated by DIR#. It's up to the FDC to keep track of how many pulses are needed (in which direction) to seek to a specific track.


Cheers,

Brendan

[tom9876543]

Hi,
Thanks for explaining the physical operation of the fdc / floppy drive.
Brendan provided excellent description of DIR# and STEP#.

After the correct track has been selected, I guess the fdc uses SIDE1# to select the correct head on floppy drive.

How does the controller seek to the correct sector?
Does it have to read all the sectors on the track until it gets to the right one?
Example, to read sector 4, the the FDC must read sectors 1,2,3 first?

[Brendan]

Hi,

How does the controller seek to the correct sector?
Does it have to read all the sectors on the track until it gets to the right one?
Example, to read sector 4, the the FDC must read sectors 1,2,3 first?

Internally the FDC keeps track of which cylinder it thinks the drive's heads are are on. For example, if the FDC thinks the drive's heads are on cylinder 5 and you ask it to seek to cylinder 9, then it knows it needs 4 STEP# pulses to get from where it thinks the heads are to where you want the heads to be.

Now; sometimes the FDC doesn't know where the heads actually are (and/or where it thinks the heads are is wrong). In this case it's your device driver's responsibility to issue a "recalibrate" command so that the FDC can correct itself. For "recalibrate", the FDC keeps doing STEP# pulses until the drive's TRK0 signal says that the heads are on track zero.

This means that your driver should send a "recalibrate" command when it's first started (after resetting the FDC, for each drive connected) to ensure the FDC has knows where the drive's heads are; and that your driver should also send "recalibrate" as part of your error recovery routines (especially if it gets an "address mark not found" error from the FDC, as that can be a sign that the FDC lost track of where the drive's heads are).

If you think about all of this, you'll see that it's possible for the FDC to seek correctly to any cylinder, without ever reading any data from the disk in the drive.

Once the FDC knows (or thinks it knows) that it's on the right cylinder, it uses the HDSEL signal to tell the drive which head it wants.

After that; near the start of each sector on the floppy disk there's an "address mark" (before the sector's data) - these address marks are created when the disk is formatted. The address marks are read until one of the address marks matches the "cylinder, head and sector" that you're looking for; and then the FDC can start reading or writing the sector's data. Also note that there's a hole in the floppy disk that lines up with an special "hole detector" that is connected to the INDX signal. If the FDC sees 2 pulses on the IDX signal, then it knows that the heads have read every address mark on the track and none matched what you're looking for, so it stops trying and gives you an "address mark not found" error.

Note that there's no need for sectors to be in any specific order within a track. If the sectors are created in a strange order with the format command (e.g. sector numbers 9, 1, 5, 7, 2, 6, ...) then it will all still work fine (the FDC will find the address mark it's looking for before getting 2 IDX pulses).

There are various "interleaving" schemes that use this fact to improve timing (in certain situations). For example, if you read one sector, then do something else for a little while, then read the next sector, then do something else for a little while, etc; then sequential order will mean that after reading sector 1 and doing something else you've missed the start of sector 2 and have to wait an entire disk rotation before the start of sector 2 comes around again. This situation can be improved by formatting sectors using a non-sequential order (like 1, 9, 2, 10, 3, 11, 4, ...).

Also, because you get to specify the details stored in the address marks when you format a track; this can also be abused for various non-standard purposes (e.g. disk copy protection again). For example, there's no real reason why you can't use sector numbers 11, 22, 33, 44, 55, 66, 77, ...; and this would be enough to confuse most disk drivers (but not your own which would be designed to accept this strange sector numbering scheme).


Cheers,

Brendan