Contents copyright Herb Johnson . Last update Dec 23 2021. Quoted material is copyright by me, including quotes from others as used with permission. For more info or for reuse or questions, email me via this Web link. Corrections are appreciated.
"M2FM" or "MMFM" are references to "modified modified FM", or "modified squared FM" (the two as a superscript), which was a means of encoding 1's and 0's onto 8-inch floppy diskettes in the 1970's. It's an early form of "double density" floppy disk formatting which was only used by a few companies (Intel et al). Controllers which provided this means of encoding and decoding, were made with discrete, small-scale IC's. Later, when floppy controller large-scale IC's (LSI) chips were available as floppy controllers, this method of encoding was NOT available. Those chips either implemented FM (single density) or MFM (what became "standard" double density" bit encoding. Information on this Web page, discusses ways to read MMFM or M2FM diskettes. - Herb Johnson
This Web page was created in 2010 thru 2012 and is updated on occasion. It's related to the Web pages below. They may have more information and be more current.
drive.html - a collection of tech info on floppy drives, diskettes, formats, etc. - Herb Johnson
flux changes and M2FM At the lowest physical level of a floppy diskette, it's simply a rotating magnetic medium on a "plastic" (Mylar) disk. The
magnetic medium encodes binary information as magnetic domains - little magnets - arranged in concentric circular tracks. Patterns
of magnets represent binary values - bits - as "flux changes". Which patterns are a bit? That's one of the encodings referred to as "MF" or "MFM" or "M2FM". Those patterns and bits are produced at different data rates and thus at different "densities" of flux-changes per inch. Also there's patterns of binary data which vary for different "formats". If you are unfamiliar with these descriptions of floppy diskettes,
here's a document which describes floppy diskette "binary encoding" and how diskettes "work" magnetically.
So, computer and drive manufacturers established
a number of "standards" for encoding bits, density of bits, and binary data and called those standards "single density", "double
density" with FM, MFM or M2FM encoding. The bit-encoding of MF, MFM or M2FM is done by hardware logic, a handful of flip-flops and gates. Diskette formating is performed by the hardware (and sometimes firmware) of floppy diskette controllers. On this Web page, I discuss an early double-density bit-encoding and disk-format called "M2FM" (em two eff em) which was only used on and with the earliest floppy-diskette controllers; and not implemented on later single-chip floppy disk controller (FDC) IC's.
In September 2006, Jay Jaeger obtained many Intel ISIS 8-inch diskettes from me. He soon discovered that many
of them were written in a unique format, down to the bit level. Intel's earlist double-density
floppy disk controller used a bit format
called "M2FM" or modified, modified FM (MMFM). It's not single density FM, the bit rate is faster.
It's similar to double density MFM bit encoding but is decoded with different hardware at the bit level.
This recording scheme is not readable by many floppy controllers because 1) the M2FM
bit encoding scheme won't decode with a MFM decoder, and 2) M2FM sector and track standards (preambles, postambles, etc.)
are different from what became "standard" double density or MFM. This very early format is documented in the
earliest Shugart floppy diskette drive manuals, such as the Shugart SA800 and SA801 drive; documented in Intel's earliest floppy-controller manuals. IBM, the "gold standard" for floppy disk formats, refers to M2FM and GCR in their early
documents as "encoding alternatives" from other manufacturers.
A Shugart document, "SA800 Diskette Storage Drive - Theory Of Operations", has a few pages on M2FM / MMFM,
which IT calls "double density". The document describes the track format but only pictorially; the M2FM scheme
itself is well described. "The only reliable method to seperate M2FM encoded data is through the use
of a phase locked loop (VCO) type of data seperator. The VFO, once synchronized, tracks the data and
generates clock and data windows, improving the bit shift tolerance over the conventional "hard" data
seperators commonly used in FM recording, which use windows of fixed timing...." Prior to that reference,
the document says "Shugart Associates will provide design information, as required, to SA800/801 users
who desire to incorporate double capacity diskette drives in their end products."
Manuals I have, or available on the Web, which describe or mention M2FM / MMFM include:
"The IBM Diskette and Diskette Drive" by James T Engh- follow my Web link At the bit level, the hardware issue was described by Jay at the time as follows: "Reading a
track['s bit] cell image still depends on the controller being capable of correctly decoding
the bit cells and clock. FM and MFM are not really density by themselves,
but are instead different ways of recording self-clocking data streams." He provided
some quoted text and references to on-line documents as below. He said
In my introduction to M2FM, I referenced and discussed some early Intel floppy-disk controllers and
documents. Intel implemented M2FM on their early double-density floppy controllers as a two-board
set. Here's a "field guide" document for Intel's earliest
Multibus floppy controllers, which I'll refine over time. Intel's first floppy disk controllers were a two-board
set: a "controller" with its own microcoded processor to operate the floppy drive and perform "format"; and a "decoder" to process the binary data. One decoder board implemented FM or single density; another implemented M2FM double-density. Each
required their own microcode to support track and sector formatting. Later, Intel developed a single-chip floppy-disk controller (FDC), and so a single Multibus card was both controller and decoder, for either FM or MFM - not M2FM.
In 2018, I was part of a discussion of Intel's early floppy controllers. A number of current owners of Intel development systems weighed in, about operating the SBC 202 M2FM-supporting double-density controller and decoder boards for MFM. Eric Smith noted: "The jumper on the SBC 202 interface board can select MFM channel encoding [instead of M2FM encoding], but that doesn't make it compatible with anything other than another similarly jumpered SBC 202, i.e., incompatible with anything that actually exists and is in use in the world. The jumper does not change the [controller board's microcoded implementation of the] index, address, and data marks, and other details of the track format, which are still the non-standard Intel format, as is the CRC computation (initialized wrong compared to normal formats). A lot of this is [also] hardwired on the interface board and not easily changed; in particular, changing the microcode can not "fix" this. The SBC 202 can't be made to support industry-standard MFM format (derived from IBM System/34) without major changes."
Eric added, "I think the only FDC chip that can handle SBC 202 M2FM format is the Signetics 8X330, which is why it's used on the Zendex ZX203." That controller is mentioned in my "field guide" document linked a few paragraphs before.
In late 2021, while looking for other M2FM controllers, I was reminded that Eric
Smith also worked on disassembling code for the Zendex ZX-200A Multibus floppy controller. It has an onboard 8085 and 8257 DMA controller and various logic to replicate Intel's FM and M2FM Multibus controllers.
2021 Web search finds a reconstructed Zenex manual from 2015. There's a user's manual
at bitsavers.org in their Zendex archive.
Further search on the Signetics 8X330 yields the following.
bitsavers.org has has 18 pages on the 8X330 in an 8X300-series
document. It notes support for FM, M2FM and MFM. But details are not included, certainly no circuits. bitsavers.org has some related documents. - Herb
The Catweasel Mark 4 was a PCI card produced by Individual Computers of Germany and sold by them and a few other
vendors in the USA and other countries. The company produced earlier Catweasel cards for the ISA bus. Neither card is in
production as of 2018, but they were and are in use and traded. I discuss the Catweasel and provide current information on my "drives" Web page.
In Dec 2009, Jay Jaeger referred me to the following post in "classiccmp" (a vintage computing mail list):
Steve found an archive for his diskette images, at "bitsavers.org", as described below.
The software mentioned, "cwtool" and also "cw", are from Karsten Scheibler's web site. These are parts of a Linux based software package for the Catweasel Mark 4 floppy disk controller. The site has links to providers of other software tools for the Catweasel. The cw and cwtool programs are reported to copy into the image file, the sectors per track in LOGICAL order, not merely copying their PHYSICAL order. Put another way, there is no
"interleave" in the image copy.
Allison Parent posted about M2FM, as part of the Catweasel discussion above. Bottom line,
DEC did not use M2FM, they used a mix of single and double density, as will be described here.
Allison posted:
I discussed privately with her the recent advance in reading M2FM Intel disks with a Catweasel Mark 4
PCI controller and new software. She said:
I discussed with her the Intel version and she said:
But I know of no other way to read Intel M2FM disks except with
original hardware. If you have an old MDS "blue box", I think you'd
spend $150 to buy an old Intel DD card for it (actually you need two
cards), plus time to make it work. If your MDS is the pre-Multibus
box, I'm not sure they came with double density floppy controllers.
She said:
"S-100" refers to a 100-pin microcomputer bus initially developed as the MITS Altair
bus for the Altair 8800 computer in 1975. It became an IEEE-696 standard several years
later as a 24-bit address, 16-bit data bus for products built well into the 1990's.
Check my S-100 Web pages for a lot a lot of details.
S-100 systems started as ROM based or (audio used for data) cassette systems; then
became floppy-based as floppy diskette technology developed. First they were hard-sectored floppy systems with UART or state-machine based floppy controllers. Later they used the range of single-chip floppy disk controllers, and supported FM and MFM (single and double density) formats. I was not aware that any S-100 M2FM controllers were developed.
In late 2021, my attention was drawn to the Technical Design Labs (TDL) DDDC floppy controller board. It supported the Western Digital 1781
floppy controller chip to control 8-inch floppy drives under CP/M or equivalents. I learned through looking at WD 1781 documentation, that the 1781 supported FM, MFM and/or M2FM with external decoders designed accordingly. I am one of the few who have
documentation for the TDL DDDC.
When searching for 1781 documentation - and it's a little scarce, since WD moved
on to the 179X series with internal FM/MFM decoders - I found another S-100 1781
controller card. Dynabyte 5010 floppy controller. I and
others have documents for that controller.
Another Catweasel program in common use for single and (MFM) double density diskette imaging is
Tim Mann's program "cw2dmk" for the Catweasel, available at this Web link.
Disk image files are produced with the ".DMK" extentions, and there's a "signature" with the program name at the beginning of each image file. Another program is Dave Dunfield's "imagedisk", which runs on ordinary personal computers with floppy disk controllers. It produces image files with the ".imd" extension and which have the signature "IMD 1.XX" depending on revision.
In Jan 2010 Jay Jaeger provided images of the ISIS disks he obtained from me, to
Al Kossow's bitsaver.org Web site in an Intel/MDS subdirectory.
Some images have been "tar"ed into collections of disk images at this link.
Other disk images from my former collection may be in that "Intel" archive area. See this Web page
for a reference list or catalog of the Intel diskettes I owned in 2006.
In 2018 Eric Smith said "I've successfully extracted Intel M2FM ISIS-II files from Kyroflux images using two of my own Python software, fluxtoimd to convert from Kyroflux (or DiscFerret) flux-transition images to ImageDisk images, and isisutils to extract the ISIS-II files from the ImageDisk image." Eric also has other classic microprocessor works) on his Github pages.
As of 2017, "catweasel" controllers don't seem to be in production. Other bit-level floppy controlling hardware is available, such as "Kyroflux" and "DiskFerret", see notes in the previous section.
Bill Beech's Web site at nj7p.org shows some results, specifically
this page on Bill's Web site. "On my site is the program MAKIMG-I which will create IMG, read IMG, extract files from IMG, etc. The source is there and the utility is written C. I use it on the PC take apart these ISIS-II images and to build new ones."
Eric Smith's work with Intel ISIS software and M2FM interpretation is noted in the previous section.
In 2016, I was pleased when Richard Main, formerly of Zendex, had rebuilt and restored some Intel Multibus development systems. He read Intel M2FM 8" diskettes, and worked with Bill Beech and other Multibus owners on recovering M2FM disks from Jaeger's collection and/or the imaged disks on bitsavers. However: his results became unavailable in 2017.
However, he worked with other people, including some mentioned in this section, and they are
moving forward with his work and their own works. Since 2017, I follow the work of these several people and more, on my Web page about recent work on Intel's early development systems. That page will likely have newer information; I'll try to maintain this "M2FM" Web page about specific progress with INtel's version of that disk encoding scheme.
Thanks to Al Kossow, for his archive work and his correspondence with me about part of his Intel/ISIS archive. Thanks of
course to Jay Jaeger for restoring the MDS IV system and imaging the diskettes, to Steve Hirsch and his support to Karsten Scheibler
who created/adapted the M2FM tools for the Catweasel. Thanks to my friend and colleage Allison Parent for permission to put our discussion on this page. And thanks to Richard Main and Bill Beech, and others listed on this Web page, for their Multibus interests and in recovery of ancient Intel disks.
- Herb Johnson
Copyright © 2021 Herb Johnson
8inch_cctech.txt - a 2005 discussion about diskette formats and controller "chips".
s_intel.html - Some Intel Multibus hardware I have, and had. Also Intel original diskettes.
isis_coll.html - a specific collection of Intel "ISIS" disks I had, now sold and archived online.
s_drives_howto.html - information on older and newer hardware to read old disks including MMFM M2FM
20th century history of ISIS and Intel
21 century restoration of ISIS-II Intel systems
M2FM by INtel, Shugart, IBM
M2FM / MMFM and Intel, ISIS
Catweasel and M2FM / MMFM
DEC and M2FM / MMFM
S-100 and M2FM / MMFM
Other tools, disk image archive
Work in 2016 on Multibus hardware, MMFM images
flux changes and M2FM
M2FM by Intel, Shugart, IBM
....IBM Journal of Research and Development, Volume 25, 1981.
link to IBM site
Shugart, "SA800 Diskette Storage Drive - Theory Of Operations", 33 pages
Shugart "SA800 Series - Application Bulletin", 33 pages
CDC Application Note: PLO and Write comp, 40 pgs.
Intel iSBC 202 manual, intel #9800420A - links above
INtel, Intellec Double Density Diskette Operating System Hardware Reference Manual,
Intel, Diskette Hardware System, Hardware Reference Manual, intel # 9800349B
">In looking at what Google pointed me to [when searching for
> "Intel M2FM"], I found [that]....
> all Intel did was to use the same basic 3270 format and double the number
> of sectors to make the OS changes easy. The gaps between real data did not
> get as big from SD to Intel's DD.
>
> "[But] Intel made more changes than that. In addition to the use of M2FM and
> and different gap sizes, the index mark, ID address mark, data mark, and
> deleted data mark don't match standard FM or MFM. The gap and PLO sync
> bytes are different as well.
>
> "It's documented in the disk controller manuals. For instance, see
> pages 4-25 through 4-31 of the iSBC 202 manual at Bitsavers.org."
>
> "Or pages 1-4 through 1-11 of the Intellec Double Density Diskette
> Operating System Hardware Reference Manual at Bitsavers.org."
M2FM / MMFM and Intel, ISIS
Catweasel and M2FM / MMFM
Subject: Catweasel support for Intel M2FM working!
From: Steven Hirsch
Date: 2009-10-08 23:23:41
I'm pleased to announce that the maintainer of Linux cwtool has
implemented working support for reading and writing Intel M2FM "DD"
diskettes as used with the Intellec development systems :-).
Karsten did some analysis of raw bit images I sent him and produced a
working driver within a week! As a "smoke" test (my MDS800 is not
functional at the moment), I duplicated the ISIS-II system diskette and
sent the copy to a person with a working system. It boots, catalogs and
otherwise looks fine.
I have about 20-25 original distribution diskettes for the MDS800 and will
get busy imaging them ASAP. Who would be willing to host these?
They are "cooked" images, so it would be possible to extract the files
from them with a bit of work. However, they're obviously of the most use
to folks with access to a Catweasel board (and an Intellec system).
Steve
DEC and M2FM / MMFM
They must have confused RX01 (8" SD easily read) with the custom
mixed format SD and DD (and DD as M2fm) that no current
or previous floppy chip can do. All the controllers (DEC, DSD and
other third party) all use bit slice or 8x305 to do the format. I
have all the known working varients (DEC, DSD, Plessy/Harris,
sigma systems, Crislin.) as examples in working systems.
The DEC and clone RX02s can do both RX01 format and the oddball 2D format.
I'm sure the CW can, but DEC hardware is far easier to use than CW
and I already preserved and use that system. It's far easier to boot the PDP-11
(and faster than a PC bootup) and it can handle the high level formats
that are different.
For example RX02 was used on PDP-8 (12bit mode)
PDP-11, VAX, and PDP10 and the lost of OSs include RTS, OS8, MUMPS
(PDP8,10 and pdp11), UNIX (PDP11, VAX) and more. For example PDP11
PDP-11 ran unix, RT11, RSX11, RSTS, MUMPS, TSX11. DOS, XXDP/X11,
POS, and I'm certain I forgot a few.
Reading the RX02 is small peice
of the battle as all of those systems and software used the disk
differently heck even RT-11 can't read a unix-11 disk without a
utility. The CW doesn't solve this though higher level filesystem
level tools can. Fortunatly most of the DEC RX02 users knew to
make RX01 disks that can be read on any soft-sector 8" system for
portability sake. When you consider those OSs also supported other
removable media so the overlying format is usually the important
issue.
It's multibus, I have one of the two boards, but in the last 12 years I've never needed
to read a DD disk. But having 500K per disk would be nice as 241K is cramped.
[So while] the Catweasel is really the only game in town...
In my case I enjoy running and maintaining the old hardware so being able to read
their disks is inherent. Since I have systems with 1771/1791/765 that covers most all
but the oddball formats that are married to specific hardware. In the case of NS*
I have Horizon SD/DD and an Advantage as well so I've covered all the needed cases.
This problem was more real for me back in the 75-81 time frame when [my] system
was only NS* SD and the rest of the world was 8"SSSD. Even than the few [diskette formats]
I can't read [now] are a minority and not something I collect. - Allison Parent
S-100 and M2FM / MMFM
Other tools, bitsavers disk image archives, later work
Work in 2016 and later on Multibus hardware, MMFM images
Thanks
Herb Johnson
New Jersey, USA
to send email @ me, follow this link.