On 8/11/2018 5:59 PM, Bill Beech (NJ7P) wrote: 
> Also, I hammered on the FM, MFM, and M2FM encoding disappearing at the 
> FDC chip or board.  What goes in or comes out of an FDC chip or board is 
> a byte stream.  These encodings exist on the media as transitions for 
> the data and the clock in various forms. The flux transition file of the 
> disk media represents this encoding in a file.  But note it takes a 
> special FDC to read or write these flux transition files.  The programs 
> others have written to convert these to IMG or IMD format actually 
> simulate a modern FDC chip.

Bill Beech also chatted with me, to clarify the relationships between what's recorded on the floppy diskette, versus what's encoded into the floppy disk controller hardware, and where and when the disk's information is established. 

It's a little subtle, to say "the flux transition file of the 
disk media represents this encoding in a file". There's many layers of control and representation going on; I'll try to summarize them for clarity. If I'm in error, please correct me of course. Decades ago, this used to be ordinary technical knowledge; these days it's hard to find this kind of description; I myself forgot some of the details until Bill and I discussed it after questions about "how M2FM is part of these Intel ISIS files".

A floppy diskette has a mylar disk with a magnetic coating, which is accessed by a read/write magnetic head of a floppy drive. Access is upon the rotating diskette, which forms a circular "track"; the head is "stepped" by a linear
motor from track to track. The action of the moving media across the head, produces changes in the head's magnetic field, which are read as currents. Or changes in current in the magnetic head, produce a change in the head's magnetic field, which produces magnetic changes in the diskette media. Collectively these are called "flux transistions on the diskette" 

Flux transitions are where low-level disk formats exist - FM, MFM, M2FM, and others. They are bit-encoding (and decoding) methods. The hardware of any floppy disk controller, encodes and decodes them, from the 1's and 0's streaming out from the controller to the drive; or the converse. 

When the diskette is formatted, the controller is driven by a formatting program; and there's some amount of controller hardware involved. For instance, a single-chip floppy disk controller has a limited choice of disk formatting methods. At that level *and time*, software and hardware are in play. And that's where and when, the track and sector schemes are established, like "IBM 3740 single-density format". 

That standard, and others of that sort, describes sectors and their size and numbering, and any information before and after sectors, and at the beginning of the track. The "format" is established by the format program, through the hardware of the controller. Thus every computer brand and model has its own format program, because formats and particularly hardware are unique in combination. 

With the development of "single chip" floppy disk controller IC's in the later 1970's, there were established a number of "disk formats" - the IBM 3740 8-inch single density format, and a number of double-density formats. Those are standards for both low level formats (FM, MFM) and track and sector level schemes (26 sequential sectors of 128 bytes per track for 3740). You can read the data sheets of such FDC chips for details; such as the Western Digital 1771 or 1791 families, or Intel's 8271. Floppy disk controllers prior to these devices, and some in the time period, used alternative schemes and bit-encoding schemes; read the controller documentation to understand those, such as Intel's iSBC201. Some early floppy disk drives documents (Shugart 800 or 801) discussed bit-encoding methods like M2FM.

Once a disk is formatted, an operating system accesses diskettes by track and sector at its lowest level - BIOS in the CP/M and MS-DOS world. The hardware controller, is just reading off tracks and sectors, and capturing or producing a sector's worth of data for the OS.

A BIOS or something similar, often has means of converting "physical sectors numbers" into "logical sector numbers" which is called "skew" or "interleave" (I may be confused on these). The purpose of converting sector numbers, is to create a time delay between sequential reads and writes of sectors. The next physical sector may be available under the read-write head, before the OS is ready. So a delay-by-sector-count, gives time to access a sector in "logical" order, when the OS is ready for it.

So the operating system at the "BIOS" or equivalent level doesn't see "MFM" or "flux" or "formats" - just tracks and sectors. At a higher level in the operating system, those sectors are arranged and purposed for disk directory, files, and "booting" information. Thus ISIS or CP/M at the OS level, "sees" the diskette as files referenced by a directory, The OS itself may be a file (ISIS), or may be part of the diskette that's loaded at "boot" time (CP/M). 

And so, programs running under an OS, generally open and close files, read and write "blocks" of data or individual characters and bytes. No knowledge of "disk format" or "flux changes" is needed.

So, a CP/M SSSD diskette and an ISIS SSSD diskette are "different" - they have different schemes for arranging sectors into files and directories and the OS on diskette. But "at the track and sector level", the diskettes are the same IBM 3740 "format" (or almost so, hopefully); and the same "FM" single-density "flux changes" as required by the IBM 3740 standard. Whew!

Herb