Re: Floppy Disk Interfacing
- From: Nobody <nobody@xxxxxxxxxxx>
- Date: Fri, 29 May 2009 05:03:22 +0100
On Thu, 28 May 2009 16:58:18 -0700, FyberOptic wrote:
At 1us per MFM encoding bit, you'd need a clock capable of 1mhz to
read the bits fast enough, right? But even so, I have a feeling that
there would be sync problems, and have heard that a PLL is required
for reading disks like this. PLLs are still a bit out of my league at
the moment, but I always learn such things as I go along, so I might
could figure it out if push comes to shove. If you had a PLL, I
assume the clock would need to be much higher to be able to match up
with the data rate from the floppy.
The 177x used a fixed 8MHz clock; this supported 360k/720k formats, so
125/250 kbps.
I thought that an alternative might be some kind of a software-based
PLL, if you had a microcontroller running fast enough in comparison.
The use of MFM means that the clock doesn't need to be particularly
accurate, as you can't have more than 3 MFM bits (half data bits) without
a transition. It just needs to be accurate enough to distinguish 1001 from
10001. For 720k, with an 8MHz base clock, each half bit would last 16
clocks, so you would reset the counter on each transition and sample at
t=8, t=24, and t=40. This leaves a large tolerance for inaccuracies in
clock frequency and rotational speed.
What about writing to disks, though? I mean if you're reading from
them, you usually have all the sync bits to help you align your clock
with the PLL. But how would you align it with the disk rotation speed
if the disk was totally blank, with nothing like that to sync by? Would
the sync of the PLL also be tied in with the passing of the index hole
of the disk?
You read the sector headers to synchronise the clock, then start writing
at the end of the header.
This is why you have to format the disk before you can write to it, and
why there are gaps either side of the header and data, and why there's a
big gap at the end of each track (the recommended 16-sector formats have
two whole sectors' worth of padding at the end of each track, to allow for
being unable to sync the clock during formatting).
What is the actual physical procedure of reading and writing to a
floppy? I'm assuming that as long as the disk is in the drive and the
motor is spinning, that the data line is constantly spitting out bits.
What about writing? Do you pull the /wgate (?) signal to 0v, and then
immediately start spewing encoded bits into the write pin? And by
spewing bits, I mean toggling the pin high and low, since as far as I
understand, it doesn't matter if it's physically high or low at any
particular moment, it's the transition between the two that counts when
reading/writing the floppy.
Read the WD-177x data sheet. It doesn't cover high density (1.44MB), but
the concepts remain the same.
Are there any delay times you'd have to take into consideration, in
regards to like how soon you triggered to write and the time you started
sending out the data? Seems like it would be very hard to write into an
individual track at a particular spot during a random write, considering
how fast the disk is spinning and how close the bits are.
There are "write splice" gaps between the end of the header and the start
of the data, and the end of the data and the start of the next header. The
header and data both begin and end with markers to allow the alignment to
be correctly detected in spite of the timing differences which occur when
switching from reading the header to writing the data.
I also understand that you can't put too many bit transitions on the
disk too close to one another, or they would create too large of a
magnetic field in one area. Hence the need for encoding, such as with
MFM. If you did this to every track on the whole disk though, would the
magnetic field be noticeable? Like if you held a piece of metal near
it?
It's not a question of absolute field strength, but how close opposing
fields can be. This is partly a property of the magnetic coating, and
partly a property of the size of the read-write head.
I'm also curious if anyone knows where there are any technical documents
on floppy disks/drives, PC floppy disk layout (the gaps and header and
sync and all that), MFM encoding, etc. I'm having a hard time finding
such things.
MFM encoding:
http://en.wikipedia.org/wiki/Modified_Frequency_Modulation
GCR (used on classic Macs):
http://en.wikipedia.org/wiki/Group_Code_Recording
FDC (floppy disc controller) chips such as the 8271 and 177x have data
sheets:
http://www.datasheetarchive.com/pdf-datasheets/Datasheets-115/DSAP002129.pdf
http://www-uxsup.csx.cam.ac.uk/~bjh21/BBCdata/8271DataSheet.pdf
The source code for emulators often contains useful knowledge about
the corresponding platform's disk format(s).
My reasons for messing with floppies ranges from simply learning, to
using them for a fun way of storage in microcontroller projects, to
being able to read in other older floppy disks for computers of which
the drives have long since failed (like my Atari 800 drive). I just
find tinkering with this kind of stuff to be more fun in many respects
than Flash memory and SD cards. Probably because I grew up messing with
it all.
If you want to recover old disks, just sample the raw bitstream from the
drive's data-out pin and decode it in software on a PC. This will let you
read disks from the Amiga (which used a normal PC-type drive but did most
of the encoding and decoding in software) and classic Macintoshes (which
used a variable-speed drive).
.
- Follow-Ups:
- Re: Floppy Disk Interfacing
- From: FyberOptic
- Re: Floppy Disk Interfacing
- References:
- Floppy Disk Interfacing
- From: FyberOptic
- Floppy Disk Interfacing
- Prev by Date: Re: What's the hi-side current sense chip du jour?
- Next by Date: Re: My Vintage Dream PC
- Previous by thread: Floppy Disk Interfacing
- Next by thread: Re: Floppy Disk Interfacing
- Index(es):
Relevant Pages
|
