8272 FDC commands, release of dmklib (was Re: Reading old disks on Linux)

From: Fred Cisin <cisin_at_xenosoft.com>
Date: Mon Oct 21 18:22:01 2002

> > A: If you read a header, can you process the data, and be ready to read
> > again in less than 1/50 of a second? Ifnot, then you could read even
> > numbered headers on one revolution, and odd numbered on another.

On Sat, 19 Oct 2002, Eric Smith wrote:
> The READ ID HEADER command doesn't give you a choice as to what header
> you're going to read; it just grabs the next one that comes around. So
> if you want to know the exact sequence of headers on the track, you have
> to be able to process them in real time.

Absolutely right.
That's why I said that you'd have about 1/50 of a second. (1/2 that for
256 bytes per sector).


> You also don't inherently get any information on the positioning of the
> IDs with regard to the index pulse. If you want that information, you
> should do a read track, and then start reading IDs as soon as the read
> track completes.

For reading data, the physical sequence of the sectors normally won't
matter. much. Some machines were too slow to be able to handle a 1:1
interleave, so they would rearrange the sequence of the sectors, so that
there would be another sector between #1 and #2 to give you more time to
process a sector before looking for the next one. Using a 1:1 interleave
on a machine that was too slow for it would result in needing one full
revolution for each sector.

Another approach was to keep the physical sector numbering sequential, but
to use sectors in a non-sequential order. THAT requires study of the
code of the system, or looking at the contents of sectors to try to
determine what sequence they were probably used in.


Another minor gotcha: machines that used WDC179x disk controller chips
were capable of starting their first sector sooner after the index pulse
than those using NEC 765 series. Reading those with a 765 required
disabling ther index pulse.
Received on Mon Oct 21 2002 - 18:22:01 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:34 BST