Re: Did Commodore cheat with the quad density floppies?

From: smf <smf_at_null.net>
Date: Fri, 4 Jan 2019 19:56:49 +0000
Message-ID: <679d55f6-d8ae-b05e-be03-e583ed63991a@null.net>
On 04/01/2019 19:13, afachat@gmx.de wrote:
>
> You are mixing up FM and MFM.
> See https://extrapages.de/archives/20190102-Floppy-notes.html

FM and MFM both require two transitions per bit.

https://en.wikipedia.org/wiki/Modified_Frequency_Modulation#MFM_coding

Both FM and MFM encodings can also be thought of as having data bits 
separated by clock bits, but with different rules for encoding the bits. 
Still, both formats encode each data bit as two bits on disk (because of 
delimiters that are required at the beginning and end of a sequence, the 
actual density is slightly lower).

The basic encoding rule for FM is that all clock bits are 1: zeros are 
encoded as 10, ones are encoded as 11. The number of magnetic 
transitions per bit is on average 1.5 (50%*1 + 50%*2).

The basic encoding rule for MFM is that (x, y, z, ...) encodes to (x, 
xNOR <https://en.wikipedia.org/wiki/Logical_NOR>y, y, y NOR z, z, z 
NOR...). A zero is encoded as 10 if preceded by a zero, and 00 if 
preceded by a one (each of these cases occurs 25% of the time); a one is 
always encoded as 01 (which happens 50% of the time); thus the number of 
magnetic transitions is on average 0.75 (25%*1 + 25%*0 + 50%*1).


> The misunderstanding here is probably due to the fact that "data bit cell" and
> "encoded bit cell" are all different between FM, MFM, and GCR.

In practice they usually are, but not all systems used those exact sizes 
and there is nothing to say you have to use those particular sizes with 
GCR or MFM as they are just encoding schemes.

People often squeezed in as much as they thought they could. Chuck 
peddle did an even more insane GCR floppy at Sirrius.

> Data bit cells in FM are 8us, and 4us in MFM, while there are no real data bit
> cells in GCR.

Right, because GCR is coded in groups. Each FM and MFM bit requires 
double the space, while GCR is more efficient.
Received on 2019-01-04 21:01:33

Archive generated by hypermail 2.2.0.