ST-506 hard drive emulation
julesrichardsonuk at yahoo.co.uk
Tue Jul 26 18:20:29 CDT 2005
On Tue, 2005-07-26 at 15:54 -0700, Dwight K. Elvey wrote:
> >From: ard at p850ug1.demon.co.uk
> > 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.
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.
More information about the cctech