Do you double side your floppies?

[kufi]

Does the 15xx series drives use FM or MFM?

They use GCR, not MFM. One of the reasons that pc-style controllers cannot read commodore disks.

[ral-clan]

Does the 15xx series drives use FM or MFM?

They use GCR, not MFM. One of the reasons that pc-style controllers cannot read commodore disks.

GCR stands for what? Gap Code Recognition (just a guess )???

[kufi]

Group Code Recording

[carlsson]

Hm, so FM, MFM and GCR would be three different ways to represent data?

[kufi]

Yes, they are. There is also RLL (Run Length Limited), PRML (Partial Response/Maximum Likelyhood), and a few others, most of them are used in harddisks. All of these encodings have the goal of adding flux reversals into the data stream, because if you would simpy "dump" the raw data on the disk, you might end up with a bunch of 0-bits. They would be represented by a long period without flux reversals. You can not rely on timing to get a reliable reading from disks, because every drive motor has some slight fluctuation in its rotational speed. As an example: a bunch of 14 0-bits could actually be read as 13 or 15 0-bits, depending on drive type and condition.

Well, i hope that made sense to you

The 1571 and 1581 have a standard Western Digital "decoder-chip" for MFM-formats. The 1541 *can* read MFM disks if it is modified and suitable software is written for it (since all encoding and decoding is done in software). I found some info about a modification here: http://cmdrkey.com/cbm/genie/geniefiles ... 41-DOS.TXT

[saundby]

Does the 15xx series drives use FM or MFM?

They use GCR, not MFM. One of the reasons that pc-style controllers cannot read commodore disks.

In FM encoding, every other transition on the disk is a clock bit used to time data but which itself carries no data. This means half the transitions on the disk are used only for timing, and the other half contain data. The amount of data you can hold on a minifloppy recorded this way is 88K. The signal off the disk head looks like:

clock-one-clock-zero-clock-one-clock-zero...

In MFM and the various forms of GCR encoding the data use different means of turning the clocking into data. Basically, if you have no transition for zeroes then you can't have a long string of zeroes on a disk because you can't go for long without having timing errors in the data stream build up to the point where you've got no idea if your data timing still matches that on the disk. So with MFM and the various GCRs you translate the data stream so that there are always some transitions, no matter what the data is. Even a long string of zeroes has some "ones" in it. In Commodore GCR a nibble of 0000 gets translated into 01010. In MFM it becomes either 10101010 or 00101010 depending on whether the prior data bit was a one or a zero. In other words, MFM is a type of RLL code since it limits the run length of ones to 1 and zeroes to 3--making it a (1,3) RLL code.

If you can read the raw data of transitions off the disk you can translate the data for yourself from any of the formats. The data frequency is the same for all of them. The only question is what hardware lies between your software and the raw data stream--can you get at the raw data stream with your software or is it translated from raw form to the system's expected unencoded values before you can get to it?

If you can get to the raw data, then you can do your own decoding and read data to and from whatever encoding scheme you want--MFM, M2FM, Commodore GCR, Apple 3 and 5, whatever. If you can't, then you're limited to reading whatever formats use an encoding scheme that uses a set of states that are a subset of the states of your expected encoding scheme (since each format uses a subset of the possible states of flux transitions of the disk, to make sure that no data goes to the disk without a minimum number of flux transitions in a given period of time to maintain timing of the data.) In Commodore GCR, you can't have more than two zero bits of encoded data in a row. So if you want to read a format in which a sequence of 10001 would be legal and you can't get to the raw data you're out of luck since this would be an illegal sequence that isn't translatable by Commodore GCR. If the format you're trying to read has a set of states that are a subset of your drive's expected format's states then you can post decode it.

But, if you can get to the raw data of ones and zeroes off the disk you can read any disk type. There's nothing different about the different formats' data frequencies, disk speeds, etc. that would prevent it.

As to semantics, I pointed out the use of the term floppy as meaning the drive not as a suggestion that anyone change away from the common usage of referring to the media but as a way of helping people translate any technical documentation they may come across, as well as for understanding my post, where I tried to stick to the "standard" usages.

Yes, the terminology is confusing. This is what happens when engineers are coming up with terminology late at night after too much brain-numbing system testing. For myself, when I'm coming up with new terminology I try very hard to keep it all unofficial until I can try it out on a line assembly worker. If it makes sense to them on a first pass without complex analogies to justify it then I figure I won't be too embarassed by it later (and if I end up using an analogy to explain it I wait a day or two to see if they come back to me and ask something like "was it the sender carries the letter or was it the recipient comes to pick it up?" to make sure that any analogy makes sense.)

Unfortunately, reality doesn't always allow this level of care. "The reps from the manufacturer are here, so come by the conference room in ten minutes and tell them about how the thing you've been up all night testing works, and be prepared to be detailed, they brought their engineers with them."

-Mark G.

[Jeff-20]