Xref: utzoo comp.sys.amiga.hardware:5900 comp.sys.amiga.programmer:429
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.hardware,comp.sys.amiga.programmer
Subject: Re: Decoding MFM
Message-ID: <18258@cbmvax.commodore.com>
Date: 29 Jan 91 19:19:21 GMT
References: <2786@gould.doc.ic.ac.uk> <18157@cbmvax.commodore.com> <1480@mpirbn.mpifr-bonn.mpg.de>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 25

In article <1480@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes:
>In article <18157@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>>	Decode is easy.  take the two halves of the longword, and each of
>>them with $55555555, shift the even bits 1 left, and or them together.
>
>That's true for the Amiga version of MFM. Plain IBM compatible controllers
>(that use MFM as well) use a different scheme.

	True.  On IBM MFM, the data is stored in sequential order with
timing bits.  So to get 16 bits of data, you take a longword, remove every
other bit, then compress the remaining ones down to 16 bits. (Actually more
likely you do a series of lsr #2,dn; ror #1,dm after a single lsr #1,dn;
ror #1,dm, or use a table-based routine).

	IBM format also uses gaps inbetween each sector header and sector
data, and gaps inbetween sector data and the next sector header, 3 sync
marks instead of 2, a different sector format type (amiga is 0xff), and of
course CRCs instead of checksums.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)