On Tue, 2005-07-26 at 15:54 -0700, Dwight K. Elvey
wrote:
From: ard
at p850ug1.demon.co.uk
[1] 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
amplifier/filter.
Hi
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.
I was worried about the precomp too. However I think that for ST412
drives at least, the precomp's done within the drive; the controller
knows nothing about it.
I *think* it's only relevant for ST506 drives (<= 8 heads), and even
then not all drives used it.
At least that's what I gathered from some googling earlier - haven't had
a chance to look at the docs mentioned on here earlier yet.
I wonder what the bit density of one of these drives is? I mean, is it
possible to simulate a whole raw track in memory, so that it doesn't
matter about timing as you're essentially digitising the disk surface at
1 bit / sample. Maybe that requres a *huge* amount of storage though,
but I'm presuming the bit density figure is the smallest transition that
the drive can handle, and no amount of messing around through external
write precomp will change that?
Again, it's wasteful - but it really would be a raw snapshop the drive.
cheers
Jules
Even at 16X sampling (80 MHz) a 1/60 second snapshot is only 1.33 million
samples per track. You probably only need one track buffer so this is < 256k
Bytes of RAM. With say 32 bit data storage thats only a 2.5 MW/sec data rate
so the controller could be easily done with a FPGA or even CPLD and a
dedicated fairly fast CPU.
Peter Wallace