Distribution floppies (Was: Microsoft OSs (was: Install Floppies)

[Fred Cisin]

Thank you.   I'm pleased that there is stillsome interest.

There might be some typos in that.  So, I'd especially be grateful if 
Chuck or ARD, or anybody else, let me know what could be fixed or improved.


None of the content is current.
It's mostly just a recap off of the top of my head of one of the lectures 
that I gave in my disk operating system class, back when all of those 
formats were active and common.  I also drew bit patterns on the board and 
explained FM, MFM, GCR.  And I also went into considerable length to 
make sure that everybody in the class throughly understood the head width 
problem for RE-writing sectors of 360K disks in a 1.2M drive, etc.

--
Grumpy Ol' Fred     		cisin at xenosoft.com

On Mon, 26 Jul 2021, Randy Dawson wrote:

> LOT'S OF GOOD INFORMATION HERE!
>
> I am keeping this one Fred, and thank you.
>
> ________________________________
> From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Fred Cisin via cctalk <cctalk at classiccmp.org>
> Sent: Saturday, July 24, 2021 3:27 PM
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
> Subject: Distribution floppies (Was: Microsoft OSs (was: Install Floppies)
>
>> On Sat, Jul 24, 2021, 10:41 AM Grant Taylor via cctalk <
>> cctalk at classiccmp.org> wrote:
>>> Maybe someone who is more versed in the possible disk sizes and more
>>> accurate (non-rounded) count.  I'm extremely foggy when it comes to
>>> 5-1/4 inch disk capacities.  720 kB and 1.44 MB disks I can deal with.
>>> But the minutia between 320 kB and 360 kB, combined with rounded
>>> measurements, things get foggy for me.
>
> OK, I am going to take a chance that you, or others here, want to
> know more about it.
>
> The sizes that would be used were:
> 360K
> 1.2M
> 1.4M
> DMF  1.64M
> XDF  1.8M
>
>
> TLDR:
> Other PC formats:
>
> "160K"  5.25":
> August 1981, the 5150 ("PC") was released with 5.25" "industry
> standard" Tandon TM100-1 drives.  IBM was not ready to use double sided.
> DOS 1.00
> 300 RPM, 48 Tracks Per inch, 250,000 bits per second
> 1 side,  40 tracks,  8 sectors per track, 512 bytes per sector
> 163,840   160K
> Please note: This is not "rounded", it is based on K meaning Kibibyte of
> 1024 bytes.
>
> "320K":
> DOS 1.10
> Same, but double sided.
> 2 sides * 40 cylinders (trackse per side) * 8 Sectors per track * 512 BPS
> 327,680   320K
>
> "180K":
> DOS 2.00
> Change from 8 sectors pr track to 9 sectors per track.
> Single sided version:
> 1 side * 40 tracks * 9 SPT * 512 BPS
> 184,320  180K
>
> "360K":
> Same but double sided.
> 2 sides * 40 cylinders * 9 SPT * 512 BPS
> 368,640   360K
>
> Some software distribution continued to be on 180K, to allow for customers
> who still used single sided drives.
>
> "720K" 5.25":
> NON-USA PC-DOS 2.10
> IBM PC-JX (not sold in USA) had an 80 track per side 5.25" drive (what
> some CP/M companies called "Quad Density")
>
> "720K":
> MS-DOS 2.11
> OEM versions of MS-DOS were sometimes provided with 720K support,
> primarily companies that had implemented 3.5" drives, such as Gavilan,
> Zenith, Data General, etc.  They did not all use the same numbers of
> sectors in the file system overhead.  For example, Gavilan, when switching
> from 2.11J to 2.11K changed to be compatible with the later IBM 3.5"
> format.
>
> "1.2M"/"HD 5.25":
> PC-DOS 3.00
> IBM PC/AT (5170) supported a "High Density" 5.25"
> 96 tracks per inch, 360 RPM 500,000; bits per second.
> 2 sides * 80 cylinders * 15 SPT * 512 BPS
> 1,228,800   1,200K   1.17MiB    1.2 MARKETING-MEGABYTES (1,000 * 1,024)
> The AT controller ALSO supported
> 250,000 bits per second, for 300 RPM 360K drives   and
> 300,000 bits per second, for 360K disks in the 360RPM 1.2M drive.
> (Many companies then came out with two speed (300RPM and 360RPM) drives,
> 300RPM in the 1.2M drive permitted 250,000 bits per second for 360K disks)
> Weltek developed a kludge o 180RPM at 250,000 bits per second.
>
>
> MSCDEX   (drive related, but not floppy)
> 3.10
> The "network redirector" (undocumented for a while) permitted MSCDEX to
> fool DOS into thinking that a CD-ROM was NOT A DRIVE ON THE MACHINE, but
> was, instead a remote service on a network.   Attempting to CHKDSK a
> CD-ROM gave "Can not CHKDSK a network drive".
>
>
> "720K 3.5":
> PC-DOS 3.20
> 135 tracks per inch, 250,000 bits per second
> 2 sides * 80 cylinders * 9 SPT * 512 BPS
> 737,280   720K
> (could also be added to PC (5150), XT (5160) machines)
> DOS 3.20 added DRIVER.SYS that added 720K support to DOS, and DRIVPARM
> that changed the drive parameters without an additional driver.
> I can not fully explain why DRIVPARM worked with PC-DOS and MS-DOS on
> aftermarket ATs, but FAILED on ATs with IBM AT BIOS, with either DOS.
>
> "1.4M":
> PC-DOS 3.30
> "High Density" 3.5"
> 135 tracks per inch, 500,000 bits per second
> 2 sides * 80 cylinders * 18 SPT * 512 BPS
> 1,474,560  1,440K  1.40625 MiB;     1.44 MARKETING-MEGABYTES
> Note that the only way that you can get 1.44 is if you define "Megabyte"
> to be 1,024,000   1000 * 1024
> (So, yes, "1.4M" is ROUNDED)
>
>
> HDD >32M  (not floppy)
> MS-DOS 3.31, PC-DOS 4.00
> Note that IBM did not warn Norton in advance, so the Norton fUtilities had
> difficulties on PC-DOS 4.00, which was usually reported as "DOS 4 is not
> compatible and buggy".  Most of those "bugs" went away with the next
> release of Norton.
>
>
> "2.8M"
> PC-DOS 4.00
> 1,000,000 bits per second (or could be kludged with 500,000 bits per
> second at 150RPM)
> 2 sides * 80 cylinders * 36 SPT * 512 BPS
> 2,949,120;  2880 K;  2.8125 MiB;  2.88 MARKETING MEGABYTES
> It never really caught on.
>
>
> "DMF":
> Microsoft Distribution Media Format
> By cheating on the intersector-gaps, Microsoft managed to get 21 sectors
> per track, instead of 18 on "1.4M" disks!
> 2 sides * 80 cylinders * 21 SPT * 512
> 1,720,320;  1680 K;   1.640625MiB;   1.68 MARKETING MEGABYTES
> Floptical, USB, and other drives that have their own firmware can't handle
> them.  Older versions of DOS need a device driver.
> https://en.wikipedia.org/wiki/Distribution_Media_Format
> https://web.archive.org/web/20110914232540/http://support.microsoft.com/kb/120348
>
>
> "XDF":
> IBM chose a different approach.  Because the inter-sector gaps are
> relatively standard, you can fit more on a disk using larger sectors.
> Eight 1024 byte sectors will fit on a HD 3.5" track.  There isn't enough
> room for a ninth one.
> But, what about bigger than 1,024?
> An 8K sector will fit on a track; certainly not enough room for a second
> one.  BUT, there is enough room left for a 2K! and then enough for a 1K,
> and then enough for a 512 byte sector.
> Their driver software fooled DOS into thinking that it was seeing
> Twenty-three 512 byte sectors!
> http://www.os2museum.com/wp/the-xdf-diskette-format/
> 2 sides * 80 cylinders * 23 "virtual sectors" * 512 BPS
> 1,884,160;  1840K;  1.796875 MiB;  1.84 MARKETING-MEGABYTES
>
>
>
> FOOTNOTES:
> 1) All sizes are the total size on the disk; I did not deal with
> [here] the space taken up by fle directory and other file system overhead.
> I also didn't mention that some systems used 35 of the 40 tracks, or 75 or
> 77 of the 80 tracks  (77 tracks was the standard for 8")
>
> 2) There were other choices besides what IBM picked for bytes per sector
> and sectors per track.  Some systems ued TEN 512 byte sectors per track.
> That required minimizing the gaps between sectors, which sometimes create
> read problems with NEC 765 type FDCs.  (temporarily running the drive
> slightly slower than the standard 300 RPM could sometimes get a successful
> read).  Therefore, 40 track double sided double density could be anywhere
> from 300K to 400K, depending on layout, NOT just 360K.
> Different density calls for different sensitivity or coercivity of the
> media.  5.25" is available in 300 and 600 Oersted.  They do NOT
> interhange reliably!  The color of the cookie is different.  Some say to
> look for a hub ring.  EARLY 5.25" did not have a hub ring, and sometimes
> the drive mangled the hub, so they started reinfocing the hub.  By the
> time of 1.2M, the drives had been improved, and it was decided that hub
> rings weren't necessary any more.  hence, a disk with a hub ring is
> probably a late 360K; a disk without a hub ring is either EARLY 360K, aor
> 1.2M.
> 3.5" is available with 600 or 720-750 Oersted.  The difference is close
> enough that one can often get away with the wrong one.  Both types have a
> write protect hole, but the 1.4M has an additional hole to indicate "high
> density". 2.8M also has a hole, but it is in a slightly different place.
>
> 3) MS-DOS/PC-DOS version numbers are ALWAYS a major version number, a
> period, then a TWO DIGIT minor version number.   DOS 2.10 sees itself as
> DOS 2, 0Ah.  YES, it is a TEN, not a ONE!  3.31 intenally is 3,1Fh.
> There is no version 3.3; it is internally 3.THIRTY
>
> 4) There is some confusion regarding number of tracks on drives with
> multiple heads, does a 720K disk have 80 tracks or 160 tracks?  A
> work-around for that confusion is to use "CYLINDERS", or "TRACKS PER SIDE".
>
> 5) 67.5 tracks per inch 3.5 inch drives, with 40 tracks per side, EXISTED.
> Epson Geneve PX-8 is the only system that I am aware of that used them.
>
> 6) "Kilobyte" is widely accepted as meaning 1,024 bytes, although the 'K'
> prefix means 1,000 in most other contexts.  "KibiByte" is one attempt to
> solve that.
> BUT, 'M' means 1,000,000 in most contexts, and [rarely] 1,000.
> MebiByte is the unambiguous term for 2 to the tenth power, 1,048,576
> "MegaByte" has at least three definitions.
> 1,048,576   ("MebiByte"   2^20)
> 1,000,000   (which lets barketing claim more "megabytes")
> 1,024,000   ("MARKETING MEGABYTE" of 1,000 * 1,024 (10^3 * 2^10)
>
> 7) What does "HIGH density" mean?  Was that the mental state of those that
> named it?
> In the beginning, there was FM "Frequency Modulated" - clock pulses with a
> '1' pulse or '0' no pulse in between.
> When there were multiple '1' pulses with their clock pulses in a row,
> there were limits to how close they could be, and therefore how fast, or
> how many per inch.
> But, SOME bit patterns didn't have any tight spaces.  By finding 32 or 64
> different patterns that COULD be squeezed, it was possible to choose
> ones to represent 5 or 6 bit patterns very tightly.  With a translation
> table between the 8 bit values and multiple "sueezable" patterns, one
> could get about 40% more data in a given space; hence GCR "Group Coded
> Record" coding, as used on Apple and Commodore, and a few others.
> Going back to FM, . . .
> Clock pulses weren't really needed between adjacent '1' pulses.  If you
> simply left out THOSE clock pulses, then the resulting pattern was less
> dense, and the stream could be squeezed (higher data transfer rate) to
> almost twice as much data per time or space.  Hence MFM "Modified
> Frequency Modulation".  The marketing people called that "DOUBLE DENSITY",
> But, it oversimplified enough that it
> caught on.  Now that "DOUBLE DENSITY" existed, it was inevitable and soon
> that FM became known as "SINGLE DENSITY", even though some engineers said
> that FM was "half" density (one data bit for every two pulse spaces), and
> that MFM ought be called "single density".
> THUS, if you look at historical records, the term "DOUBLE DENSITY" came
> into being BEFORE the term "SINGLE DENSITY"!  (Cf. "World War II" V "World
> War I" (previously "The Great War"))
>
> 8) SOME/MANY companies referred to double density with twice as many
> tracks (such as the 720K format) as "QUAD DENSITY".
> Intertec/Superbrain) used "QUAD DENSITY" to refer to double density 40
> tracks per side with 2 sides.  THAT certainly created confusion.  But,
> there's MORE! When they came out with an 80 track double sided double
> density format, they called that "SUPER Density".  Thet abbreviated that
> "SD", which just about everybody else used as abbreviation for "SINGLE
> DENSITY"!
>
> 9) In addition to squeezing ten 512 byte sectors on a track, some people
> even tried using additional tracks.  Since there usually isn't a hard stop
> after track 39 (or 79), most drives could handle 41 or 42 (81 or 82)
> tracks.  John Henderson (March/9/1944 - January/31/2017) of Tall Tree
> Systems created a popular program called JFORMAT to squeeze ten sectors
> and more tracks.  He is also remembered for JRAM, some of the first
> expanded memory boards.  "Extended" used OS modes that understood more
> memory; "Expanded" worked in 1M/640K by moving a block of high memory at a
> time into a space in the 1M address range.  He was then shut out of the
> negotiations when Lotus/Intel/Microsoft developed their LIM/EMS standard.
> I remember when he came out with the JRAM boards, he asked everybody at
> the West Coast Computer Faire, "DO you do any software that uses lots of
> memory?"  Not looking for a contractor for a specific project, he was
> trying to create a market for big memory boards.
>
> --
> Grumpy Ol' Fred                  cisin at xenosoft.com