10 Dec
2003
10 Dec
'03
11:33 a.m.
On Thu, 11 Dec 2003, Tony Duell wrote:
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...
As I said in an earlier email, you could undo the write precomp by just
measuring the deltaT's
Peter Wallace
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.
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