Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Floppy disk MFM low-level encoding

  1. #1
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    79

    Default Floppy disk MFM low-level encoding

    Hello ---

    I'm building a floppy disk interface. It's going pretty well. I can read and mostly correctly extract MFM pulse trains into IBM-scheme floppy disk records.

    I deeply dislike my encoder, though. It has to parse the records it finds so it knows how long they are, so it knows where to stop reading the record and start looking for the sync sequence which announces where the next record starts. I don't like this, as it means that I decode corrupted records correctly (e.g. what happens if a record gets partially overwritten with another complete record? I'll never see the second record start, as I think it's part of the first one); also, it ties me to the IBM floppy disk record scheme.

    Two questions:

    (1) am I right that there's no way to detect the end of a record? Obviously if there's an obviously invalid MFM pulsetrain then I can give up on the current record --- but usually there isn't.

    (2) are there any other MFM record schemes out there other than IBM's?

    Also, if anyone knows any definitive documentation on this stuff...

  2. #2
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,906
    Blog Entries
    1

    Default

    Would detecting the sector gap account for the end of the data record?

  3. #3
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    28,503
    Blog Entries
    20

    Default

    Quote Originally Posted by krebizfan View Post
    Would detecting the sector gap account for the end of the data record?
    And yes, there are dozens of MFM/M2FM schemes, particularly in the hard-sector category.

  4. #4

    Default

    You could keep looking for the A1h with missing clock pulse while decoding the current record (when shifting the raw clock+data bits through a register, the value will be 4489h). No valid data can have this sequence, so you know it should be the start of the next record.

    I'm not too sure about the analog hardware side of things, but I assume the PLL will keep locking on to the 010101... pattern of the sync bytes preceding the A1h.

    PC compatible floppy controllers actually aren't able to read all records as they are encountered, they normally scan for an ID Address Mark (which is only written once during formatting) with a matching record number. The only other commands available are "read ID", which returns the next IDAM, and "read track", which waits for the index pulse, then reads all the data fields in sequence - ignoring IDAMs entirely - with a fixed size specified in parameters. You can trick the controller to read more bytes than a record actually has, and double the data rate while you are reading to get clock bits as well, but it obviously isn't designed to do that - you will lose sync and get large gaps at random points in the track each time.

    Don't know about any different FM/MFM formats other than IBM and ISO standard, the only difference is whether there is an IAM at the beginning of the track. Soft sectored CP/M, PC and Atari disks all use the same patterns to mark index and data fields. Apple and Commodore disks use GCR instead of MFM.

  5. #5
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    79

    Default

    Hmm, did not get email notification from the forum software...

    The thing about detecting the sector gap is that there may not actually be one. I was expecting that each record would have a gap between them, a place where no MFM pulsetrain was generated, due to the erase head coming on before the write head --- those are easy to detect.

    But some of the disks I've found don't have these gaps. I suspect that when doing multisector writes they keep generating a continuous and valid MFM pulsetrain and simply rewrite the sector IDs and data records. Either that, or the drives are capable of replacing a data record so precisely that the pulsetrain simply keeps going!

    The other option, as I can see it, is that I detect the deliberately-incorrectly-encoded 0xC1/0xA1 marker bytes. But if I lose MFM cell sync, so that instead of getting cells like 01 00 10 I instead misread it as 10 01 0..., then those marker bytes parse absolutely correctly. Normally I'd expect to have the correct phase because I locked onto the sync sequence before each record, but obviously I have to have the sync lock system disabled when reading actual data. (Or else risk misinterpreting user data as a sync sequence.)

    Is there anything I'm missing?

    Postscript: I'm still struggling to make writes work reliably; I suspect because I haven't implemented write precompensation. Is that still a thing in modern 3.5" floppy disk drives? If so, how much and when? I can see that 125ns is recommended, but some references say only track 43 and above, and others say to use it everywhere; and nobody seems to say anything about which pulses to shift...

    Post postscript: I've scored a working Brother LW-30 word processor, in German. It has the LOUDEST FLOPPY DRIVE EVER, which formats disks in this weird-arse 240kB format. My tool can read them! Looks like they're single-sided but store all the data on side 1, some tracks are left unformatted (erased but no pulsetrain), and I only see two different flux transition times. I think it's FM! On a standard PC drive at 300rpm they're at 3.6us and 7.2us, so I bet the Brother's drive is 360rpm and that's actually 3 and 6us. If I can decode that I'll be well pleased. Next stop: Macintosh CLV disks!

  6. #6
    Join Date
    Sep 2006
    Location
    Silicon Valley
    Posts
    1,566

    Default

    Quote Originally Posted by hjalfi View Post
    But some of the disks I've found don't have these gaps. I suspect that when doing multisector writes they keep generating a continuous and valid MFM pulsetrain and simply rewrite the sector IDs and data records.
    Have you looked at these disks with something like the HcX Floppy Emulator tool track analyzer?
    What created these disks?

  7. #7
    Join Date
    Sep 2006
    Location
    Silicon Valley
    Posts
    1,566

    Default

    Quote Originally Posted by hjalfi View Post

    Postscript: I'm still struggling to make writes work reliably; I suspect because I haven't implemented write precompensation. Is that still a thing in modern 3.5" floppy disk drives? If so, how much and when? I can see that 125ns is recommended, but some references say only track 43 and above, and others say to use it everywhere; and nobody seems to say anything about which pulses to shift...
    the subject was discussed here:

    https://marc.info/?t=137607091900004
    https://marc.info/?l=classiccmp&m=137609524004633

  8. #8
    Join Date
    Jan 2013
    Location
    Marietta, GA
    Posts
    2,752

    Default

    Are we talking about MFM sector organizations like on IBM PC or similar disks, or something more exotic here?

    I don't know exactly what algorithms real FDCs use, but they are not really smart. My observation is that when reading, a real FDC first sits and waits for the desired sector header to come up. That tells it what size the expected sector is supposed to be. It then sits and waits for the appropriate data header. Once that comes up it just keeps reading bits until it fills the buffer up to the specified size. I expect reading would only otherwise stop if there were a very long timeout, or it hit the index mark.

    It is easy to see on copy protected disks where the header specifies, say, 1024 bytes but the actual size is 512. The sector it returns to the system will contain the 512 actual data bytes, the CRC bytes, possibly invalid bits from a write splice, the header for the next sector, and part of the data from the next sector.

    Of course, if it misses the beginning of the next sector before it is it instructed to read again or it is ready to read, then it just has to sit and wait again for the next sector to come back around again.

  9. #9

    Default

    FM usually starts with some synch bytes but MFM starts with, particular, illegal clock/data sequences. It isn't as likely that there will be such sequences needed to match MFM format. Also, don't confuse the MFM or FM signalling with a particular encoding method. One just describes the clock/data structure ( MFM has a could mentioned clock/data sequences ). Other than that there are other ways of encoding the magnetic data. Look at the Apple disk data of an Apple II.
    My Nicolet is hard sectored but only writes two sectors on a 32 hard sectored disk ( 16 sector marks per actual data sector ). It does use FM for the data/clock. but doesn't use IBM format.
    The Canon Cat formats the track as it writes data to it. It doesn't waste as much time formating track that it may never use.
    Also, not that there were different track to track spacings used.

  10. #10
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    28,503
    Blog Entries
    20

    Default

    Basically, the IBM System/3 MFM works this way. Unless otherwise specified, "filler" is bytes of 0x4e.

    So you have the index pulse at the start of the track. Note that the track starts at the leading edge of the index, not the trailing edge. You start off with a string of about 80 bytes of filler, followed by 12 bytes of 0x00, then three repeated bytes of 0xC2, then the IAM, (0xFc with a clock of 0x01) followed by ab out another 50 bytes of filler. You can ignore the IAM, because not everyone puts it there (WD 17/27xx controllers in particular, but at least one version of the NEC D765 omits the IAM).

    Okay, now you're into the sector data. You have 12 bytes of 0x00, followed by 3 bytes of 0xa1, followed by 0xFE with a clock of 0x00, the IDAM. so you can sync on the A1FE pattern, with clocks present on the A1 and the missing clock on FE.There follows the CHRN ID bytes followed by 2 bytes of CRC over the entire field, including the FE. The N byte will tell you how many data bytes to expect. There's at least 20 bytes of filler, followed by 12 bytes of 0x00, then 3 bytes of 0xa1 and either a DAM of 0xfb for normal data or 0xf8 for "deleted data" (a memento of the old key-to-disk systems), so you'd set your search for the DAM for no more than 50 bytes after the IDAM. Then follows the data and the 2 byte CRC (which includes both the data and the 0xfb DAM). After this is the "write splice" area or gap, which is usually filled with 0x4e until the next IDAM sequence. The bits immediately following the data CRC can literally be anything, as it's where the write current is switched off. Note that a soft-sector floppy track is never "empty"--there are always bit patterns going by, even if they're filler.

    That's why the format is fairly rigid--the space between IDAM and DAM is pretty rigidly fixed. One thing that's true is that on a 250Kbps MFM floppy, there are (more or less) 6,250 bytes recorded, no matter what their function might be. SImple math should tell you: 300 RPM and 250Kbit/second = 50,000 bits or 6,250 bytes.

    FM and MMFM recording formats are similar, differing only in details. Pre-LSI floppy controllers--i.e., those made from discrete SSI/MSI logic can have their own conventions, including bit ordering within a byte as well as address marks or lack of them, CRC, or lack of them; encoding (FM, MFM, GCR, etc.). In the early days of floppies, there was a tendency to invent one's own methodology. I think that OSI (IIRC) used a UART to encode data onto a track.

    Copy-protection formats often make use of mechanisms that can't be written by common floppy controllers, but can be read. Low-cost schemes, such as used on some lower-end word processors, use their own conventions.
    Last edited by Chuck(G); October 11th, 2018 at 01:53 PM.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •