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

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Wed Dec 10 19:33:20 2003

On Thu, 11 Dec 2003, Tony Duell wrote:

> > Right, one option would be for the emulator to have a FM, MFM or RLL front end
>
> Oh for %deity's sake... I am sure it was regarded as a Good Thing (if not
> essential) that the emulator works with all controllers _without
> modification_. In other words, no separate MFM and RLL versions.


If its done with a FPGA, the modification is "stiffware only" and does not
require new hardware. Plus there are some substantial benefits of decoding the
bitstream, one is that now the front end can run much faster (say even 200
MHz) without requiring large and wasteful raw bitstream storage...

Since write precomp is in the area of 10-20 ns, if we are worried about
undoing write precomp, maybe we should also worry about our recording
resolution - preprocessing the input stream makes improving the timing
resolution easy...


>
> In any case, do you know the exact encoding details of every ST506
> controller ever made? I certainly don't, and I've repaired a heck of a
> lot of them.

No, but 95% of older ones will be MFM...

Other than FM, MFM, RLL and some newer ones what other magnetic disk encoding
schemes are there?


>
> If you're going to go far enough to decode the MFM (or whatever)
> encoding, you might as well also recognise sectors, etc and just store
> the user data (and any filesystem pointers in the headers, etc). This is
> very efficient of emulator RAM, but it means you need a different
> emulator for each controller/system. And you need to know a lot about how
> the controller actually encodes the data.

No, I just need the (programmable) front end to do the MFM --> RZ (or RLL -->
RZ or GCR --> RZ) data conversion...


>
> > and actually decode the bitstream. Then the write-precomp could be undone...
>
> However, for udoing write precompensation, I am not conviced that you
> need to know details of the encoding. Precompensation is a kludge to
> correct for a magnetic effect on the disk. How the pulses in the
> bitstream are shifted should only depend on that bitstream, and not on
> the data in encodes or how it encodes it. Therefore it should be possible
> to undo it without knowing the encoding method.
>
> -tony
>

As I said in an earlier email, you could undo the write precomp by just
measuring the deltaT's


Peter Wallace
Received on Wed Dec 10 2003 - 19:33:20 GMT