MFM Codification

guili_23

Hi everybody,

I´m working in a project using 3.5" floppy and I`m having problems in finding a way[\B] to read MFM codification. I can`t figure out an efficient method to interpret the MFM data using the propeller.

Have anybody made a PUB for this ?? or perphaps have some idea to guide me.

Thanks in advance,

bill190

Might want to poke around the object exchange. There are some FAT objects and so forth.

OBEX...
(See Data Storage)
http://obex.parallax.com

bill190

Here is some info on that...
http://en.wikipedia.org/wiki/File_Allocation_Table

Also old MSDOS programmer's manuals would have information about reading/writing to a FAT formatted disk. That may not apply to the FAT objects in the OBEX? But would give you the general idea of how disk read/writes work in general.

Ding-Batty

I suspect you are asking about a lower-level challenge: converting a pulse stream from the drive, interpreted as an MFM encoding, back into a data bit stream, with indication as to where the sector headers and sector data start on the track, which are represented by otherwise valid pulse sequences that cannot be generated simply from an MFM-encoded bit stream.

I have looked at this, unfortunately, most of the information I have collected is on my other computer, which is not "nearby" at the moment.

You might also want to look at the "Prop-Floppy" project http://www.parallax.com/PropFloppy/tabid/851/Default.aspx, which is "An Honorable Mention in the 2009/2010 Propeller Design Contest". The diskettes in that project used FM encoding, which is much simpler to interpret.

I don't know of any ObEx objects that would be helpful, unless something was uploaded recently...

ericball

According to http://en.wikipedia.org/wiki/Modified_Frequency_Modulation Data the bitstream x,y,z is encoded as x, x NOR y, y, y NOR z, z . . .

So to read the data you could simply ignore every other bit and get the original bits. There's almost certainly some sync patterns which you'd need to handle bitwise. Writes are another matter.
A lot also depends on what your upstream interface is and what it expects.

tonyp12

user's data bit      MFM coded bits
    ---------------      --------------
        1                   01
        0                   10 if following a 0 data bit
        0                   00 if following a 1 data bit

MFM doubles the data size, but is a necessary evil for code to be stored on magnetic media.

So 1 is always stored as 01
0 is stored 10 or 00 depending if prior user data bit was a 0 or 1

You can see that in a mfm bit pair, the first bit is always 1 in a 1 and always a 0 in 0
So decoding would simple skip every other bit.


But is the data you are getting already synced ?
The PC uses the index hole to find the beginning of a track, Amiga uses a synchronization word.

http://www.amigahistory.co.uk/adfaq.html#p21

David B

Here's a floppy driver and test program I wrote that can read and write 3.5" and read 5.25" floppies (it should also be able to write to 5.25" floppies but I never developed and tested it that far)

It was just for hacking around, so it's not very polished code.

At one point, I added code to dump one full track of floppy flux transition timings to external RAM for serious debugging, but then disabled it, so you'll see commented-out code in the driver for that.

The hardest time I had was working around the speed of processing the flux transition pulses because they arrive so fast. I finally used one cog to build the 16 bit MFM words from the pulses and write them to the hub, and used another cog to read them from the hub and decode the MFM words into data.

I haven't run it for a while, but it worked the last time I ran it. The test program included with the driver reads and displays the $AA55 DOS signature from a floppy sector 0.

tonyp12

Questions for guili_23, is for the Amiga floppy?
Are you writing it in spin or pasm?

This guy uses a Pic32, it just begs to use a prop instead.
It needs vga, something the prop is good at.
http://retromaster.wordpress.com/ufe/

I think his product will be to costly, so propbably will never see production.

guili_23

Hi tonyp12.
The idea is to make an USB - Floppy disk emulator.

tonyp12 wrote: »

Questions for guili_23, is for the Amiga floppy?
Are you writing it in spin or pasm?

This guy uses a Pic32, it just begs to use a prop instead.
It needs vga, something the prop is good at.
http://retromaster.wordpress.com/ufe/

I think his product will be to costly, so propbably will never see production.

guili_23

Hi DavidB,

I tried to understand your code but I couldn´t figured out the logic to read a track (I focused in the mfmWordReader´s part)

1) Could you explain me how you acomplish the reading ??

....
:top         
        waitpne d_fluxBit, d_fluxBit            '         Wait for the next flux transition pulse
        mov     d_afterpne, cnt                 ' 4   4
        mov     d_pulsecount, d_afterpne        ' 4   8   Calculate clock counts since last pulse
        sub     d_pulsecount, d_start           ' 4  12
        mov     d_start, d_afterpne             ' 4  16
:bit0                                           '         Add 2-4 bits to the raw MFM word based on latest pulse interval.          
        shl     d_rawbits,  #1                  ' 4  20   First bit - mandatory one.
        or      d_rawbits,  #1                  ' 4  24   Place a "1" bit into the raw MFM word.
.....

2) When Does the reading of the track stops ??

David B wrote: »

Here's a floppy driver and test program I wrote that can read and write 3.5" and read 5.25" floppies (it should also be able to write to 5.25" floppies but I never developed and tested it that far)

It was just for hacking around, so it's not very polished code.

At one point, I added code to dump one full track of floppy flux transition timings to external RAM for serious debugging, but then disabled it, so you'll see commented-out code in the driver for that.

The hardest time I had was working around the speed of processing the flux transition pulses because they arrive so fast. I finally used one cog to build the 16 bit MFM words from the pulses and write them to the hub, and used another cog to read them from the hub and decode the MFM words into data.

I haven't run it for a while, but it worked the last time I ran it. The test program included with the driver reads and displays the $AA55 DOS signature from a floppy sector 0.