|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Constructing a PLL for MFM-readingI'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>* 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-readingRikard 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 |
| Free embeddable forum powered by Nabble | Forum Help |