----- Original Message -----
From: "Pat Finnegan" <pat_at_purdueriots.com>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, January 06, 2002 11:25 AM
Subject: Re: MFM IC's (Was RE: Any AMIGA users?)
> On Sun, 6 Jan 2002, Richard Erlacher wrote:
>
> > ----- Original Message -----
> > From: "Pat Finnegan" <pat_at_purdueriots.com>
> > >
> > > OK, With all this talk of drive controllers, I've got two questions that
> > > I've had little luck finding answers to:
> > >
> > > 1) Are there any IC's available today that will do MFM and
> > > write-precompensation, but very little else? Basically it'll need to do
> > > the MFM, have a PLL for decoding the MFM, some sort of 'start read' and
> > > 'start write' inputs I can trigger from a sector pulse, and a
> > > write-precomp. Another question: Is write-precomp that important?
> > >
> >
> > Either of these, and a wide range of others can easily handle floppy disk
> > interface by conventional "bit-banging" techniques, while the faster ones
I've
> > mentioned can easily process a hard disk too. All that's required is a
> > thorough understanding of the task requirements and thorough understanding
of
> > the controller's operation.
> >
> > Write precompensation is definitely necessary. With floppy disks, it
required
> > imposing a bit shift of about between 1/16 and 1/8 the bit rate. With MFM
> > hard disks, the most common amount was about 60 ns against a 200 ns bit
> > window. The most common compromise I observed in FDC's intended for both
500
> > and 250 MHz bit rates was about 160ns, or, essentially a 6 MHz clock. For
> > hard disks of the '80's a 16 MHz clock would have worked just fine.
>
> OK, Well I was hoping not to play that game, but I might just end up doing
> it. Here's a snippet of tech info I've learned about the drives that
> might be useful in deciding a better method (if possible):
>
> 1) Bit-clock is 4.2MHz
> 2) Write precomp on the RL-8A (pdp-8 native) controller goes from -15 to
> +15ns
> 3) There's a sector pulse (no index pulse as far as i can tell) which
> 'falls' at the start of the first data bit of the header... The header
> is composed of 3 8-bit words of 0's a '1' marker bit, address, etc, and
> then a crc, followed by the data
>
> Basically I want to have something that will 'start' on the falling sector
> pulse, and mfm-decode the data, and make it available 8 bits at a time
> (simple 8-bit shift reg should do that nicely).
>
> In order to do the mfm decoding/encoding, I was planning on programming a
> PAL with a simple state machine (perhaps more than one... but that depends
> on how many I'll end up needing). I just didn't want to end up with a
> drive controller the size of the origional RL-8A, RL(V)11, or RLV12...
>
I can send you some PAL equations that will fit both functions into a 22V10 if
you like (and I can find 'em again).
Once you get to the point of programming a PAL and building hardware, I think
you'll find it attractive to run an SX, as I mentioned before, at a convenient
harmonic of the data rate you want to support and have it kick the data out in
parallel format into a RAM buffer driven with some external counters. One
advantage of using the DALLAS 50 MIPs part is that it has sufficient data
memory space (64KB) to hold an entire track, even if it's oversampled, and
then process it into NRZ or parallel format. It even has a built-in serial
port so it can send the data to your host system as a block of data formatted
for sync or async, however you like. You can combine the PLL and SIPO
function by sampling the data each time the counter overflows and resetting
the counter each time, or some similar scheme.
A 66 MHz clock should produce the precomp you want, but if you want precisely
that interval, it will probably have to happen externally to the MCU. If all
you're doing is recovering the data, you won't need to deal with precomp. If
you want to write, you absolutely want to precompensate.
Picking a sample rate is, for me, a choice between 8x and 16x the nominal bit
rate. 8x falls within the capbilities of the SX but is a stretch for the
Dallas part. Sampling might have to be done in external hardware. Once
you're to that point there's another approach you may want to examine. OTOH,
many drives of that era produced both data and clock when they presented read
data. You might find that helpful.
These microcontrollers would mean a really small circuit. One of about three
or four components. That would appeal to me.
Another option would be to try to fit the schematic-based design of the
original controller into a CPLD. (NOT and FPGA!!!) I've found that
schematics of "old" logic seem to yield useable circuits in CPLD's, while
FPGA's totally seem to want to ruin the timing. That would lead to a circuit
about the size of half a dollar, that's easily modifiable, since the parts are
in-circuit-reprogrammable.
Dick
Received on Sun Jan 06 2002 - 19:19:03 GMT