Replacements for ST-406/ST-512 drives

From: Dwight K. Elvey <>
Date: Mon Feb 7 19:25:23 2005

>From: "Eric Smith" <>
>Dwight wrote about ST506 emulation:
>> As I stated before, if you place a simple toggle flip-flop that
>> is clocked by the pulse from the drive, the rate of sampling
>> is reduced by a large factor ( at least about 10 ).
>I don't see how that helps. If the drive emulator is not going to
>decode the MFM (or RLL, etc.) to store the bits in a decoded form,
>then it has to preserve the timing of the pulses with very good
>resolution in order to make sure that on playback they are where
>the host's disk controller expects them. It's nowhere near good
>enough to sample at 2x or even 4x the data rate (10 Mbps or 20 Mbps,
>based on a nominal bit rate of 5 Mbps). For MFM, the bit cells occur
>at a 10 Mbps rate, and I doubt that good results would be had from
>sampling at less than 5x that rate (50 Mbps). For RLL, the timing
>is even more critical.
>And that's not even considering the way the controller applies
>precompensation to account for peak shift in the recording channel.
>A really good drive emulator would model the peak shift.
>Since the highest-capacity drive ever made with the ST506/ST412
>interface, the Maxtor XT2190, had a formatted capacity of only 150 MB
>(225 MB w/ RLL), there seems to be little reason when building an
>emulator using a modern drive as the storage to try to sample at less
>than 50 Mbps. I'd probably be inclined to sample at 100 Mbps to make
>sure that RLL works reliably. That results in a total storage
>requirement of 3.825 GB, which is small enough to fit in even a
>Hitachi Microdrive.

Hi Eric
 The only info that needs to be stored is the distance between
rising edges of the pulse from the drive. For that information,
one only needs to store a binary info of short/long. At least
this is true for MFM. I've not looked into RLL but suspect
that it is also similar. The sampling frequency only needs to
be fast enough to detect the difference between a short or
long time between rising edges. It doesn't need to know anything
about the pulse width, which requires at least a 4X-5X increase in
the sample rate. This is because the pulses are so short and
have a lot of variability. Feeding it through a toggling flip-flop
removes the pulse width information and leaves only the time between
rising edges to be sampled. Maybe I overstated the 10X better
but when I looked at it, I could see at least a 4X improvement.
Received on Mon Feb 07 2005 - 19:25:23 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:36 BST