Constructing a PLL for MFM-reading

View: New views
3 Messages — Rating Filter:   Alert me  

Constructing a PLL for MFM-reading

by Rikard Bosnjakovic-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm going to extract raw-data from an old Amiga floppydrive without
using a floppy disk controller. That is, I'm reading the data-gate on
the floppy drive feeding it into a microcontroller and then perform
the MFM-decoding of the data myself.

There's not a lot of documentation available, but what I've been able
to dig out is this:

* How the MFM-data is laid out. The data itself is twice as large as
the actual data: '1' is encoded as 01, '0' is encoded as 10 (if
following a '0') or 00 (if following a '1'), according to the Amiga
Hardware reference manual. However,
http://au.geocities.com/redskulldc/transactor/disksys.pdf claims that
both data and clock bits are interleaved together in the stream, like
this:

  Number 18:    1   0   0   1   0
  Clock bits: 0   0   1   0   0
  MFM:        0 1 0 0 1 0 0 1 0 0

Extending this example to the number 89 I get this:

  Number 89:  1   0   1   1   0   0   1
  Clock:    0   0   0   0   0   1   0
  MFM:      0 1 0 0 0 1 0 1 0 0 1 0 0 1

I.e. the clock is not predeterminable (or whatever the word for it is).

* Each bitcell on the floppy is 2us big (or wide, or whatever you would call it)

* There's a "sync-word" (0x4489 which cannot be replicated by using
standard data-encoding) that starts each track.

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.

Half the bits (every second) need to get ridden of. How do I make sure
if bit 0 in the read stream is clock or data? Somehow by using the
syncword, but I cannot find any more in-depth documentation about
this. I guess that the syncword is some sort of a trigger for the PLL
to set up a proper clock generator. If anyone could shed some light of
how a PLL does its work in this situation I'd be grateful.

What other questions should I ask?


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

Re: Constructing a PLL for MFM-reading

by Alan B. Pearce-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>* How the MFM-data is laid out.

One of the best documents that defines this is the Shugart SA800/850 manual.
You can find it with Google.

Copy here http://vt100.net/manx/details/69,16127


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

Re: Constructing a PLL for MFM-reading

by Olin Lathrop :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

flw_main.aspic (5K) Download Attachment