Floppy Drive Interface Tinkering

[FyberOptic]

Hiya folks! Due to my constant need to do somewhat useless things just
to see if I can, I decided I want to better learn the workings of a
floppy drive by making a parallel port interface for one. I might also
implement something like this in a homebuilt computer design I've
played around with.

First of all, there's a couple things I'm unsure about on the
connector, so to the pinout!

http://pinouts.ru/Storage/InternalDisk_pinout.shtml (Modern floppies
would use the top pinout table, correct?)

I think there's an error in the signal direction for DSKCHG. I would
assume you read this pin, yet they have it indicated that you write to
it, which makes no sense. The other thing I'm curious about is what
the INDEX signal is for. I guess this might have been used for 5.25"
disks which had that little hole in'em, and I don't even entirely
understand what it'd use that for, but this seems to be a useless
signal for 3.5" if this is the case, since they seem to be lacking such
a hole as far as I can tell.

Now for the meat of the matter. I thought I had the general idea of
how the drive worked down, up until I started writing this post, then I
realized I don't understand a lot more than I realized. I intially
thought it went something like: enable drive select for the drive in
question, enable the motor, set direction, step to track you want.. but
then I realized, how does one actually READ the disk? I mean, I can
step to the track I want, but how do I read off the bits of that track?
I don't see any signals on the connector which could indicate anything
I need to clock. The Drive Select, perhaps, but don't you have to hold
this low for doing any seeking? Or do the bits come out automatically,
in a constant stream, looping over and over? I'd assume that if it did
spit bits out constantly, that this is where the index signal would
come in handy, but again, I'm not even sure 3.5" disks can do that.

I also can't seem to find any definitive reference for the actual
signals needed for each pin, such as what signal to use for density
select to force high-density disks, or what signal means which
direction, etc. I found a reference at one point, but it wasn't
complete, and considering the signals are active-low apparently, I had
no idea if that person took that into consideration or what.

What I thought would be something relatively simple has ended up a bit
trickier than I thought, unless I'm just overlooking something simple.
A good reference would probably help wonders, but it seems I only
manage to find a lot of useless pinouts.

Anyone with any insight on working with floppy drives would be
appreciated!

 

[Adrian Jansen]

What I thought would be something relatively simple has ended up a bit
trickier than I thought, unless I'm just overlooking something simple.
A good reference would probably help wonders, but it seems I only
manage to find a lot of useless pinouts.

Anyone with any insight on working with floppy drives would be
appreciated!

You needed to be around 20-30 years ago, when floppy drives were new,
and all the interface stuff was well known by hobbyists.
And no, I cant help with the details, all that info is long gone. But I
can tell you that reading bits off a disk is a *lot* harder than just
digital. There were several different encoding schemes, all involving
clock and data recovery from essentially analog signals.

--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

 

[Jim Thompson]

You needed to be around 20-30 years ago, when floppy drives were new,
and all the interface stuff was well known by hobbyists.
And no, I cant help with the details, all that info is long gone. But I
can tell you that reading bits off a disk is a *lot* harder than just
digital. There were several different encoding schemes, all involving
clock and data recovery from essentially analog signals.

Here's the floppy data extractor scheme I used 23 years ago on the
OmniComp/GenRad portable testers....

http://analog-innovations.com/SED/FloppyDataExtractor.pdf

...Jim Thompson

 

[Luhan]

You needed to be around 20-30 years ago, when floppy drives were new,
and all the interface stuff was well known by hobbyists.
And no, I cant help with the details, all that info is long gone. But I
can tell you that reading bits off a disk is a *lot* harder than just
digital. There were several different encoding schemes, all involving
clock and data recovery from essentially analog signals.

--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

I used to work for PerSci designing testers for floppy drives. Those
direction lines on your chart are ass-backwards.

On older style drives, the data comming out is digital with a recovered
clock signal. You still have to detect the trick soft-header info with
missing clock bits. If the drive is IDE, you get the actual data.
Look up specs on the IDE interface, some compact flash memory cards
also use this. You have a 'fighting chance' with a parallel port (or
2).

Luhan

 

[Luhan]

Here's the floppy data extractor scheme I used 23 years ago on the
OmniComp/GenRad portable testers....

http://analog-innovations.com/SED/FloppyDataExtractor.pdf

...Jim Thompson

Ye olde Shift-Register-Flywheel data recovery system.

I've used similar schemes for other synchronous data streams.

Luhan

 

[Jim Thompson]

Ye olde Shift-Register-Flywheel data recovery system.

I've used similar schemes for other synchronous data streams.

Luhan

Yep... a true PJL (phase-jerked loop

...Jim Thompson

 

[[email protected]]

Hiya folks! Due to my constant need to do somewhat useless things just
to see if I can, I decided I want to better learn the workings of a
floppy drive by making a parallel port interface for one. I might also
implement something like this in a homebuilt computer design I've
played around with.

First of all, there's a couple things I'm unsure about on the
connector, so to the pinout!

http://pinouts.ru/Storage/InternalDisk_pinout.shtml (Modern floppies
would use the top pinout table, correct?)

I think there's an error in the signal direction for DSKCHG. I would
assume you read this pin, yet they have it indicated that you write to
it, which makes no sense. The other thing I'm curious about is what
the INDEX signal is for. I guess this might have been used for 5.25"
disks which had that little hole in'em, and I don't even entirely
understand what it'd use that for, but this seems to be a useless
signal for 3.5" if this is the case, since they seem to be lacking such
a hole as far as I can tell.

Now for the meat of the matter. I thought I had the general idea of
how the drive worked down, up until I started writing this post, then I
realized I don't understand a lot more than I realized. I intially
thought it went something like: enable drive select for the drive in
question, enable the motor, set direction, step to track you want.. but
then I realized, how does one actually READ the disk? I mean, I can
step to the track I want, but how do I read off the bits of that track?
I don't see any signals on the connector which could indicate anything
I need to clock. The Drive Select, perhaps, but don't you have to hold
this low for doing any seeking? Or do the bits come out automatically,
in a constant stream, looping over and over? I'd assume that if it did
spit bits out constantly, that this is where the index signal would
come in handy, but again, I'm not even sure 3.5" disks can do that.

I also can't seem to find any definitive reference for the actual
signals needed for each pin, such as what signal to use for density
select to force high-density disks, or what signal means which
direction, etc. I found a reference at one point, but it wasn't
complete, and considering the signals are active-low apparently, I had
no idea if that person took that into consideration or what.

What I thought would be something relatively simple has ended up a bit
trickier than I thought, unless I'm just overlooking something simple.
A good reference would probably help wonders, but it seems I only
manage to find a lot of useless pinouts.

Anyone with any insight on working with floppy drives would be
appreciated!

You sound like a fun guy. Like others have said, this is a lot harder
than it looks. Perhaps you can go visit some of the newsgroups
dedicated to old home computers, like comp.sys.cbm. There is a wealth
of expertise on these kinds of things.

You might want to download the service manual for the Commodore 1581
floppy drive. This was a 3.5 inch external drive with its own CPU. (The
Commodore peripherals were daisy chained on a serial bus and were
intelligent). This drive, unlike Commodore's earlier 5.25 inch drives,
uses a more or less standard PC-style mechanism, so you can at least
learn a bit about the 3.5 mechs.

 

[Robert Baer]

Hiya folks! Due to my constant need to do somewhat useless things just
to see if I can, I decided I want to better learn the workings of a
floppy drive by making a parallel port interface for one. I might also
implement something like this in a homebuilt computer design I've
played around with.

First of all, there's a couple things I'm unsure about on the
connector, so to the pinout!

http://pinouts.ru/Storage/InternalDisk_pinout.shtml (Modern floppies
would use the top pinout table, correct?)

I think there's an error in the signal direction for DSKCHG. I would
assume you read this pin, yet they have it indicated that you write to
it, which makes no sense. The other thing I'm curious about is what
the INDEX signal is for. I guess this might have been used for 5.25"
disks which had that little hole in'em, and I don't even entirely
understand what it'd use that for, but this seems to be a useless
signal for 3.5" if this is the case, since they seem to be lacking such
a hole as far as I can tell.

Now for the meat of the matter. I thought I had the general idea of
how the drive worked down, up until I started writing this post, then I
realized I don't understand a lot more than I realized. I intially
thought it went something like: enable drive select for the drive in
question, enable the motor, set direction, step to track you want.. but
then I realized, how does one actually READ the disk? I mean, I can
step to the track I want, but how do I read off the bits of that track?
I don't see any signals on the connector which could indicate anything
I need to clock. The Drive Select, perhaps, but don't you have to hold
this low for doing any seeking? Or do the bits come out automatically,
in a constant stream, looping over and over? I'd assume that if it did
spit bits out constantly, that this is where the index signal would
come in handy, but again, I'm not even sure 3.5" disks can do that.

I also can't seem to find any definitive reference for the actual
signals needed for each pin, such as what signal to use for density
select to force high-density disks, or what signal means which
direction, etc. I found a reference at one point, but it wasn't
complete, and considering the signals are active-low apparently, I had
no idea if that person took that into consideration or what.

What I thought would be something relatively simple has ended up a bit
trickier than I thought, unless I'm just overlooking something simple.
A good reference would probably help wonders, but it seems I only
manage to find a lot of useless pinouts.

Anyone with any insight on working with floppy drives would be
appreciated!

1) The original IBM spec did not define or use pin 2 or pin 34.
2) Pin 2 for density i would think would exist on the 1.44Mbyte 3.25
drives to *sense* if the floppy was 720K or 1.44Mbytes. There never
would be a control to "tell" the drive what density it "should use"., as
density is driven by the FDC which is in/on the motherboard (depending
286, 386, 486, etc). The same would hold for the older dual-density
5.25 inch drives (360K / 1.2Mbyte).
3) Pin 34 is something that seems to be added that was never needed, as
the index hole would be sensed to indicate the presence of a floppy. If
present, it would be *read* as one cannot "tell" the drive that there is
a floppy in it with no regard to reality.
4) The INDEX remains used as that is (in a sense) how the FDC is
"triggered" to start reading data on a track. Look at the metal disk on
the bottom of a 1.44Mbyte floppy. That slot is used to drive it around
and the driver has an aligned "index" indicator.
5) Look for a DATA line...there are two: one for read and one for write.

 

[Robert Baer]

Here's the floppy data extractor scheme I used 23 years ago on the
OmniComp/GenRad portable testers....

http://analog-innovations.com/SED/FloppyDataExtractor.pdf

...Jim Thompson

Gee, you could read darn near anything...

 

[Michael Black]

Hiya folks! Due to my constant need to do somewhat useless things just
to see if I can, I decided I want to better learn the workings of a
floppy drive by making a parallel port interface for one. I might also
implement something like this in a homebuilt computer design I've
played around with.

First of all, there's a couple things I'm unsure about on the
connector, so to the pinout!

http://pinouts.ru/Storage/InternalDisk_pinout.shtml (Modern floppies
would use the top pinout table, correct?)

I think there's an error in the signal direction for DSKCHG. I would
assume you read this pin, yet they have it indicated that you write to
it, which makes no sense. The other thing I'm curious about is what
the INDEX signal is for. I guess this might have been used for 5.25"
disks which had that little hole in'em, and I don't even entirely
understand what it'd use that for, but this seems to be a useless
signal for 3.5" if this is the case, since they seem to be lacking such
a hole as far as I can tell.

Now for the meat of the matter. I thought I had the general idea of
how the drive worked down, up until I started writing this post, then I
realized I don't understand a lot more than I realized. I intially
thought it went something like: enable drive select for the drive in
question, enable the motor, set direction, step to track you want.. but
then I realized, how does one actually READ the disk? I mean, I can
step to the track I want, but how do I read off the bits of that track?
I don't see any signals on the connector which could indicate anything
I need to clock. The Drive Select, perhaps, but don't you have to hold
this low for doing any seeking? Or do the bits come out automatically,
in a constant stream, looping over and over? I'd assume that if it did
spit bits out constantly, that this is where the index signal would
come in handy, but again, I'm not even sure 3.5" disks can do that.

When the drives were cooked up, you basically would be doing things
the way you describe. Because there were no fancy ICs to take care
of it. All you need to do is look in Byte circa 1977, and you may
find circuits to do what you want (I say may because it was right on
the cusp, and if floppy drives became "cheap enough" too late, the
process would have been sidestepped in favor of a more integrated
IC solution. But I think Byte did have at least one article that
amounted to a floppy drive from ttl parts.

Ohio Scientific used a USART for their drive interface, though
that's all I remember. Note the "S", because they were using
the synchronous mode. The USART collected the bits into bytes.

But fairly soon, ICs came along that did it all in one package, or
almost in one package. Instead of using the CPU to control the control
pins on the drive, they'd be connected to the floppy controller IC,
which had a certain level of "smartness" to it. Th IC would collect
the bits coming off the Floppy drive, assemble them into bytes,
and then collect a full sector. It was so much better that once
they existed nobody went back to doing it any other way.

Of course, Apple Computer did do it differently. Because in 1977
when they needed a floppy drive as an accessory, it did take a full
board of ICs to do the deed. Steve Wozniak decided that if he stripped
down the circuitry in the floppy disk drive, making the interface more
raw, he could do a far simpler interface for the Apple II. Hence they
had to have drives especially made (there is less on the controller
boards than on the average Floppy drive of the time), but the interface
board is simple, using instead the Apple's CPU to do most of the work.

Michael

 

[Michael A. Terrell]

When the drives were cooked up, you basically would be doing things
the way you describe. Because there were no fancy ICs to take care
of it. All you need to do is look in Byte circa 1977, and you may
find circuits to do what you want (I say may because it was right on
the cusp, and if floppy drives became "cheap enough" too late, the
process would have been sidestepped in favor of a more integrated
IC solution. But I think Byte did have at least one article that
amounted to a floppy drive from ttl parts.

Ohio Scientific used a USART for their drive interface, though
that's all I remember. Note the "S", because they were using
the synchronous mode. The USART collected the bits into bytes.

But fairly soon, ICs came along that did it all in one package, or
almost in one package. Instead of using the CPU to control the control
pins on the drive, they'd be connected to the floppy controller IC,
which had a certain level of "smartness" to it. Th IC would collect
the bits coming off the Floppy drive, assemble them into bytes,
and then collect a full sector. It was so much better that once
they existed nobody went back to doing it any other way.

Of course, Apple Computer did do it differently. Because in 1977
when they needed a floppy drive as an accessory, it did take a full
board of ICs to do the deed. Steve Wozniak decided that if he stripped
down the circuitry in the floppy disk drive, making the interface more
raw, he could do a far simpler interface for the Apple II. Hence they
had to have drives especially made (there is less on the controller
boards than on the average Floppy drive of the time), but the interface
board is simple, using instead the Apple's CPU to do most of the work.

Michael

Not to mention losing quite a bit of storage capacity due to the
simplified interface.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

 

[FyberOptic]

Looks like I ended up with more responses than I figured for such a
short time, so I'll condense my reply to one post before I get behind.

I went and found the service manual to the Commodore 1581 and skimmed
through it, which is starting to reinforce the idea that I'm probably
going to need a floppy controller IC. In the case of the 1581, which
runs off its own 6502 cpu, it uses the WD1770 controller. Since I own
an old dead Atari 810 floppy drive (whichs runs/ran from a 6507), I dug
up some schematics for it as well, and found it uses a WD1771
controller. Despite having not looked at the datasheets yet, I would
assume these are nearly identical.

In the case of the Apple II though, I had always heard how Woz
implemented such a simple controller based more around the main cpu,
which is what prompted me to think I could use something like the
parallel port in the first place, since it gave me the false impression
that it was easy to work with a floppy drive. So much does one learn
in a day's time which proves otherwise!

In things I've found since my initial post, and things written here, I
have a somewhat better understanding of how it's done, at least.
Though even if I did manage to put something together to read bits
accurately from the drive, I still come across the problem of reading
whole sectors. It'd be kind of pointless to have an interface which
was incapable of reading any floppies I wrote elsewhere, after all.
While from the programmer's standpoint we always see the sectors as 512
bytes (as far as PC floppy disks go), I'm sure there's probably some
extra bytes for each sector for error checking, and I have yet to find
any reference for what the structure actually is.

So again, it looks like doing all of this "manually" would require way
more support circuitry than I'd have room for on a breadboard. Even
using an IC might end up taking a bunch of space. But a quick glance
through the WD FD1771 datasheet says it can handle 512 byte sectors, so
I would assume this IC might be okay to read PC floppy disks, though
I'm unsure how compatible it is with whichever was actually used in
PCs.

The reason I mention using the 1771 is because I have that one
available in the 810 disk drive as mentioned above, and unless by some
small chance I got the drive itself going again, I'd be more likely to
just remove the chip (and possibly some other components) for my own
use, assuming it's not burnt out.

 

[[email protected]]

it, which makes no sense. The other thing I'm curious about is what
the INDEX signal is for. I guess this might have been used for 5.25"

You saw a lot of interesting responses there, but I'm not sure you're
started on your project yet

First, look at the "flywheel" underneath the drive. You'll see a tiny
magnet glued to it at one point. This activates a Hall effect sensor
somewhere on the board to generate the index pulse. Not all recording
systems required the index signal; the Amiga, for instance, records its
tracks at any old location relative to the index mark. The floppy
controller reads the track into a RAM buffer that's bigger than the
actual data size; software on the host computer located the actual
start of the track and removed sync information.

You might find it instructive to put a 2-channel scope on the drive;
hardwire the drive so it is in read mode, with the hub motor running.
Put one channel on index, one channel on data out; trigger on index
pulse. Observe.

If you want to talk to a floppy drive to read and write bits from
standard PC-format floppies, the _easiest_ thing to do is to acquire an
old "super I/O card" (FDC/IDE/2S/2P/1G typically) and use the floppy
controller on that.

If you just want to use a floppy disk as [proprietary] storage,
non-interchangeable with any other system, I suggest you look at the
15_4_1, because the GCR format it used is a lot simpler to work with
(to my brain, anyway).

 

[Donald]

The reason I mention using the 1771 is because I have that one
available in the 810 disk drive as mentioned above, and unless by some

In its day there were two controller families being used.

Intel created one version (forget the number) and the WD family like the
1771 and 1793(double density).

The Intel version is the one used in PCs.

This chip is like the intel version and is still available:

http://www.smsc.com/main/catalog/fdc37c78.html

 

[J.A. Legris]

Looks like I ended up with more responses than I figured for such a
short time, so I'll condense my reply to one post before I get behind.

I went and found the service manual to the Commodore 1581 and skimmed
through it, which is starting to reinforce the idea that I'm probably
going to need a floppy controller IC. In the case of the 1581, which
runs off its own 6502 cpu, it uses the WD1770 controller. Since I own
an old dead Atari 810 floppy drive (whichs runs/ran from a 6507), I dug
up some schematics for it as well, and found it uses a WD1771
controller. Despite having not looked at the datasheets yet, I would
assume these are nearly identical.

In the case of the Apple II though, I had always heard how Woz
implemented such a simple controller based more around the main cpu,
which is what prompted me to think I could use something like the
parallel port in the first place, since it gave me the false impression
that it was easy to work with a floppy drive. So much does one learn
in a day's time which proves otherwise!

In things I've found since my initial post, and things written here, I
have a somewhat better understanding of how it's done, at least.
Though even if I did manage to put something together to read bits
accurately from the drive, I still come across the problem of reading
whole sectors. It'd be kind of pointless to have an interface which
was incapable of reading any floppies I wrote elsewhere, after all.
While from the programmer's standpoint we always see the sectors as 512
bytes (as far as PC floppy disks go), I'm sure there's probably some
extra bytes for each sector for error checking, and I have yet to find
any reference for what the structure actually is.

So again, it looks like doing all of this "manually" would require way
more support circuitry than I'd have room for on a breadboard. Even
using an IC might end up taking a bunch of space. But a quick glance
through the WD FD1771 datasheet says it can handle 512 byte sectors, so
I would assume this IC might be okay to read PC floppy disks, though
I'm unsure how compatible it is with whichever was actually used in
PCs.

The reason I mention using the 1771 is because I have that one
available in the 810 disk drive as mentioned above, and unless by some
small chance I got the drive itself going again, I'd be more likely to
just remove the chip (and possibly some other components) for my own
use, assuming it's not burnt out.

This is all an interesting challenge, but really, why don't you devote
your effort to something a little more useful - something that might
even provide you with a marketable skillset? For example, learn about
the USB bus and then how to get data in and out of a USB flash drive.

 

[Jim Thompson]

Gee, you could read darn near anything...

Yep. But I had trouble getting it by the digital guru, because he
didn't seem capable of understanding it. But management came down to
my lab and watched as I swung a PSP tester back and forth as it
continued to read without skipping a beat. Then I drug my thumb on
the motor to slow it down, it kept reading. They signed off on it ;-)

...Jim Thompson

 

[FyberOptic]

Back again! Thanks so far for the responses, as I'm slowly but surely
wrapping my head around things. But since it's obviously a complicated
matter, I'm back with some complicated questions.

I've found that apparently NRZI is used at the lowest of lowest levels,
where apparently a binary "1" is indicated by a change in flux on the
media, and a "0" is a lack of such a change, since the drive is
apparently incapable of determining the actual "polarity" of the flux
on the disk, only the changes in it, from what I understand. I did
read in one place however that it was the opposite (0 = flux change, 1
= none), but like with most of this stuff, I can't seem to find any
"official" documents to say otherwise. So for the time being, I'll
assume "1" is flux change.

I keep reading tidbits that this method can't be used directly,
possibly for a couple reasons. First, there's something about it
messing up the "clock". What exactly can the data bits clock, and how
can they clock it reliably, since unless your data was a repeating set
of identical/similar bytes, the clock signal would fluctuate too
randomly, wouldn't it? The second reason you supposedly can't use it
directly is due to something about how you can't have too many magnetic
fluxes too close together; I guess this would mean you couldn't have a
bunch of "1" one after the other. This would create too strong a flux
in one location? Though if so, what would the consequence be?

The solution(?) to the problem(s) was using encoding on top of that,
and in the case of PC floppy disks, this is MFM. A "1" is encoded as
"01", and a zero is encoded depending on whether it followed a "1"; if
so, it's "00", and if it followed a "0", it's "10". The byte
"10100001" should end up being "0100010010101001", which apparently
ends up taking twice as many bits as the original byte. Again, I can't
seem to see any means of using the bit stream as a clock from something
like that. It would also seem that if you're using twice as many bits
per byte, that if a disk were rated 2mb, wouldn't that mean you only
end up with 1mb, or am I missing something?

Then on top of that, you have the track/sector structure, which uses
some headers and sync marks and CRC bits and such. What I don't
understand in this aspect, is whether these header bits (such as the
sync mark) are encoded as MFM, or if these bytes are directly encoded
to the drive. The sync mark supposedly breaks the MFM rules somehow,
for some reason, but I just don't understand why or what it's for yet.

Hopefully I at least have a decent understanding of the stuff mentioned
above, but as usual, I'm welcome to correction and any insight on the
issues anyone can offer. Thanks again!

 

[Mark Zenier]

Back again! Thanks so far for the responses, as I'm slowly but surely
wrapping my head around things. But since it's obviously a complicated
matter, I'm back with some complicated questions.

I've found that apparently NRZI is used at the lowest of lowest levels,
where apparently a binary "1" is indicated by a change in flux on the
media, and a "0" is a lack of such a change, since the drive is
apparently incapable of determining the actual "polarity" of the flux
on the disk, only the changes in it, from what I understand. I did
read in one place however that it was the opposite (0 = flux change, 1
= none), but like with most of this stuff, I can't seem to find any
"official" documents to say otherwise. So for the time being, I'll
assume "1" is flux change.

On the interface, It's not "1" or "0", rather, the signals used on
the data in and out lines are short pulses. For the input line to
the drive, these are generated in the computer's floppy controller IC.
(This feeds the clock input of a T flip flop on the drive (or the LSI
chip equivalent) to generate the acutual write current in the head).
For the output from the drive, the analog electronics on the drive
outputs a short pulse from a monostable for every flux transition,
independent of the direction of that change.

I keep reading tidbits that this method can't be used directly,
possibly for a couple reasons. First, there's something about it
messing up the "clock". What exactly can the data bits clock, and how
can they clock it reliably, since unless your data was a repeating set
of identical/similar bytes, the clock signal would fluctuate too
randomly, wouldn't it? The second reason you supposedly can't use it
directly is due to something about how you can't have too many magnetic
fluxes too close together; I guess this would mean you couldn't have a
bunch of "1" one after the other. This would create too strong a flux
in one location? Though if so, what would the consequence be?

The solution(?) to the problem(s) was using encoding on top of that,
and in the case of PC floppy disks, this is MFM. A "1" is encoded as
"01", and a zero is encoded depending on whether it followed a "1"; if
so, it's "00", and if it followed a "0", it's "10". The byte
"10100001" should end up being "0100010010101001", which apparently
ends up taking twice as many bits as the original byte. Again, I can't
seem to see any means of using the bit stream as a clock from something
like that. It would also seem that if you're using twice as many bits
per byte, that if a disk were rated 2mb, wouldn't that mean you only
end up with 1mb, or am I missing something?

Then on top of that, you have the track/sector structure, which uses
some headers and sync marks and CRC bits and such. What I don't
understand in this aspect, is whether these header bits (such as the
sync mark) are encoded as MFM, or if these bytes are directly encoded
to the drive. The sync mark supposedly breaks the MFM rules somehow,
for some reason, but I just don't understand why or what it's for yet.

Hopefully I at least have a decent understanding of the stuff mentioned
above, but as usual, I'm welcome to correction and any insight on the
issues anyone can offer. Thanks again!

Go back to an archive of this newsgroup (google) for the April 29, (2006)
and read the thead started by Rene Tschaggelar about the floppy interface.
I posted the numbers of several ISO standards that describe the floppy
formatting. Also in my FTP directory are some of the datasheets I
mentioned.

<ftp://ftp.eskimo.com/u/m/mzenier/>

Look for the stuff added there in May, three files, I think.

Mark Zenier [email protected]
Googleproofaddress(account:mzenier provider:eskimo domain:com)

 

[joseph2k]

I used to work for PerSci designing testers for floppy drives. Those
direction lines on your chart are ass-backwards.

On older style drives, the data comming out is digital with a recovered
clock signal. You still have to detect the trick soft-header info with
missing clock bits. If the drive is IDE, you get the actual data.
Look up specs on the IDE interface, some compact flash memory cards
also use this. You have a 'fighting chance' with a parallel port (or
2).

Luhan

Floppy interface never did go IDE, not complicated enough.

 

[joseph2k]

Not to mention losing quite a bit of storage capacity due to the
simplified interface.

Actually when 320Kb and 360Kb were standard Apple has 400Kb. Of course by
then they were using FPGA tech in the FDD and FDC.