Disk hardware emulation, was Re: Grandfather system RTE6/VM?

From: Pete Turnbull <pete_at_dunnington.u-net.com>
Date: Wed Dec 10 06:23:48 2003

--On Tuesday, December 09, 2003 22:16:54 -0500 John Lawson
<jpl15_at_panix.com> wrote:

> On Tue, 9 Dec 2003, Eric Smith wrote:
>
> > The part of the ST-506 disk emulation that's of most concern to me
> > is whether anything needs to be done about write precompensation.
> > The controller shifts the pulses on write to compensate for the peak
> > shifts that happen on magnetic media when flux changes are recorded
> > close together.
>
> Is it not true that the precomp circuits are driven by head position
> info - thus the 'solid' version (emulation) of any drive would just be
> permanently 'stuck' in one mode or the other would the controller
> care, or even know, what track and cylinder the actual 'data' were
> coming from?

Some drives don't need the controller to do write precomp -- presumably
it's done by the drive electronics. In such cases, you typically
program the controller to apply precomp at a cylinder number equal to
the number of cylinders the drive has. Some drives do need the precomp
done, and then you program the controller to apply it to the data for
every cylinder above a certain value, and it gets applied before the
data reaches the drive interface.

> I don't know if this would cause the emulator qua emulator to fail
> at some perhaps subjective level - but I can't see where one would
> need to actually legislate write precomp into a block of RAM.

I think Eric's concern is that the emulator would receive
write-precompensated data, record it verbatim, and play it back
verbatim for a read. The precomp has the effect of shifting some of
the data transitions by a fraction of a bit cell. This would result in
the timing between some bits being wrong. There's no signal on an
ST506/412 interface to tell that write-precomp is being applied, so the
emulator won't know.

My solution would be to program the emulator with the cylinder number
(if any) above which to do the opposite bit shift, and undo it. I
wouldn't try to decode the bitstream, only look at the sequence of bits
in the same simplistic way a controller does when it turns on its
internal EARLY/LATE signals.

I think that you'd want to be able to program certain of the drive
characteristics into the emulator anyway. Some controllers try to
guess which "supported" drive is connected by doing things like seeing
what happens if they select certain heads, step past a certain
cylinder, etc. Therefore you'd possibly want to be able to tell the
emulator to behave as if it had a certain number of heads and
cylinders,

-- 
Pete Turnbull
Network Manager
University of York, UK
Received on Wed Dec 10 2003 - 06:23:48 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:50 BST