ST-506 hard drive emulation
Dwight K. Elvey
dwight.elvey at amd.com
Tue Jul 26 17:54:44 CDT 2005
>From: ard at p850ug1.demon.co.uk
>> >On Jul 26 2005, 14:42, Jules Richardson wrote:
>> >> I don't think there's a need to handle anything complex in the virtual
>> >> drive. I believe an ST506 drive's purely a data store/replay device and
>> >> it knows nothing of the actual data stored on it - most of the circuirty
>> >> on board is presumably just motor control and head amplifiers / filters.
>> You'd need to encode the bits correctly so the data/clock seperator
>That's just what I'd not want to do. You can't make any asumptions about
>the clock/data encoding scheme if you want this emulator to be universal
>(after all, a real ST506 doesn't do anything to the pulse stream other than
>record it on the disk, unchanged ).
>That was the reason for the high (10*, 8* would probably be OK as well)
>sampling rate. Just record the pulses to memory, then play them back.
>Yes, it's wasteful of memory, but it means it should work with any ST506
>controller (and there are some very strange ones in classic computers).
> THat is a simplfication. IIRC, a rising (falling?) edge of the write
>data line causes a flux transition on the disk. The opposite edge is
>ignored. On read, a flux transition on the disk causes a pulse on the
>read data line, the width of this pulse is fixed (determined by a
>one-shot on the drive logic board). There are restrictions as to how fast
>and how slowly you can send pulses, due to the design of the read
This is my understanding as well. This means that you can't
just play back the signal written. The write signal
has compensation for the timing shift caused by signals
being close together on the disk surface. This tends to
alter the edge timing. This is the information that you are
trying to recover or play back. The sampling systems used
to read the data back would not work well with the unprocessed
write data going into them because of the compensation used.
You'd need to provide a filter that is the equivalent of
the writing and reading of data through the disk. Then you'd
need to find the leading edges and generate the pulses
that are read. I would say that 8X to 10X is a reasonable
sampling rate but you'd still need to process the data
before sending it back as read data.
More information about the cctech