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

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Wed Dec 10 09:47:50 2003

On Wed, 10 Dec 2003, Pete Turnbull wrote:

> --On Tuesday, December 09, 2003 20:45:45 -0800 "Peter C. Wallace"
> <pcw_at_mesanet.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.
> [...]
> > > I'm guessing that it won't be
> > > enough to cause reads to fail MOST of the time, but it will reduce
> > > the timing margins enough to that it could potentially cause
> > > occasional soft errors.
> >
> > Right, one option would be for the emulator to have a FM, MFM or RLL
> > front end and actually decode the bitstream. Then the write-precomp
> > could be undone...
>
> But then you need to know what the bitstream is, which goes against
> what we've been saying. And what about different encoding methods:
> what happens when someone wants to emulate a drive on a system you've
> not thought of?
>
> Actually, I don't think you need to know the encoding scheme at all. I
> believe the precomp (if/when applied) depends only on the sequence of
> transitions in the data.
>
> --
> Pete Turnbull
> Network Manager
> University of York, UK
>


        Usually you know the encoding scheme, and I dont see anything wrong
with using whatever knowledge you have of the interface to optimize it. If a
different encoding scheme is used, an FPGA based design could easily adapt.

        But you're right, its probably possible to undo write-precomp by
simulating the drives tendency to push close transitions apart. I do think
some adjustments are needed per drive type... The write Precomp value is
pretty small - in the order of 5-10 % of the data period.


Peter Wallace
Received on Wed Dec 10 2003 - 09:47:50 GMT