Defining Disk Image Dump Standard

From: Richard Erlacher <richard_at_idcomm.com>
Date: Wed May 31 20:54:52 2000

Yes! That's a stream of bits, blocked into a stream of bytes, and that
means one thing to you and me, but quite another to Sellam. The issue is
the sync-loss before and after each data field: the write splice. If you
want to manufacture/synthesize a reasonable facsimile of the original you
can't just depend on the "user" bytes, i.e. the data fields, but you have to
preserve the sector ID fields and you have to put something meaningful in
the write splices, which are, after all, sync fields.

If you want to replicate a diskette precisely, you have to oversample the
entire area of the diskette in which you have an interest, then store it in
whatever medium you desire. The beauty of this is that once it's in the
system, you can post process it, aligning the transitions in the file very
precisely and allowing for the need for write-precompensation if you like,
so that the product you write to the destination diskette is written in
complete synchronization with the underlying format, as though it were
written at once, which, of course, it will have been.

I've written you off-list describing an approach to doing this very thing.
Perhaps you can lend benefit of your many years' experience.

Dick

----- Original Message -----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, May 31, 2000 12:35 PM
Subject: Re: Defining Disk Image Dump Standard


> >
> > If only you understood how FDD's work, Sellam!
> >
> > You say "> A floppy diskette is a stream of bytes. "
> >
> > The stuff on a diskette is not a byte stream. It's a carefully
worked-out
>
> Well, it can certainly be represented by one....
>
> Suppose we know something about the data on the disk. That it's (say)
> recorded at a data rate of a maximum of 500k pulses/sec. That's to say,
> pulses appear (or not) at 2uS intervals.
>
> Fine. We sample the read data line every 2uS, resyncing the read clock as
> appropriate. We record whether or not there was a pulse (== a magnetic
> transition on the disk). In the end we have a stream of _bytes_. These
> are not the user bytes, they include the clock pulses, DAMs, etc. But it
> is a complete representation of what's on the disk.
>
> Suppose we don't know anything about the format. We either sample
> sufficiently fast that we record the position of each pulse to an
> acceptable accuracy (which produces a large archive file, true, but it is
> still a stream of bytes). Or more sensibly we say : Well, the disk goes
> round once every 200ms. Pulses can't ocurr closer than 20ns. We measure
> the time between the pulses (the pulse width is unimportant on every
> floppy drive I've ever seen) and record it as a 24 bit number in units of
> 20ns. That caters for everything from pulses closer together than any
> real floppy has ever used to 1 pulse/revolution. And we record those 24
> bit nunbers as (guess what...) a stream of bytes.
>
> -tony
>
Received on Wed May 31 2000 - 20:54:52 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:11 BST