Re: Constructing a PLL for MFM-reading

Rikard Bosnjakovic wrote:
> Now, the implementations I've read about is that the Amiga uses a PLL
> to sync the floppy-reads. I have little knowledge of PLL:s, just a
> vague theorethical hint of how they work, but since the clock stream
> is not a plain "010101010101..." one I cannot think of a way to
> determine how to implement this, or why.

You don't need a PLL if you have a PIC, which back then they didn't have.  I
did a floppy drive emulator a bunch of years ago.  At the time, the fastest
PIC ran at 20MHz, meaning 5MHz instruction rate.  That's not fast enough to
decode MFM and then still do something meaningful with it.  To get around
this, I used a separate PIC as a MFM to synchronous data stream converter.
The synchronous data stream was fed into the MSSP of the main controller
PIC, which dealt with whole chunks of 8 half-bits at a time.  That gave it
just enough time to store them to a external memory and do the associated
loop control and bookeeping.

Today there are much faster PICs available, so you should be able to do some
interpretation of the data on the fly.  The concept of using a small PIC
just as a synchronous data converter still makes sense though.  Attached is
the main module for this converter PIC.  It should be useable on any 14 bit
core PIC you can hang a 20MHz crystal on, like a 12F629 for example.  It
originally ran on a 16F628.

> Half the bits (every second) need to get ridden of.

Not quite.  There are special cases (at the beginning of sectors if I
remember right) where the normal MFM scheme is violated.  You do have to
look at each half bit to interpret the stream, even though most of the time
two half bits will simply make a single data bit.


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist