Hi all,

once again, another fun question from me

Does anyone know of any good, clear, well documented / easy to follow references for interfacing with a floppy drive?

I'm thinking of a little project that I would like to store data from to be loaded on a PC, I can either do it via compact flash (which I have found some reference for) or floppy (which I haven't yet). I was thinking floppy since disks are cheap and easy to come by, plus it's easy to get ahold of a PC 3.5" drive, but my two main obsticles are - talking to the drive to get it to store data and figuring out the FAT file format so I can store my data as a txt file on the disk.

Oh - and to KC5TJA - any plans to get your general soon?

Definitely not my area of expertise. Though if I were to do something like this, I would try to consider some way to bit-bang the floppy interface; I really don't like the rigidity a dedicated FDC chip provides.

For example, if a critical disk failure occurs that prevents the disk from being read by an FDC chip, then it's still possible to use the bit-banged interface to find out precisely what is wrong, and try to recover what data you can. My former roommate has expressed a desire to connect a PC floppy drive to the computer's parallel port, so as to be able to recover data off of disks damaged by the local university's anti-theft system. I do not know the progress of this project.



FAT is a very simple filesystem. VFAT adds some complexities, though, I don't think you'll be needing to support that. This is one of the reasons why it's so universally supported. http://www.nondot.org/sabre/os/articles/FileSystems/ contains a wealth of information -- many documents are authored by Microsoft directly. I strongly advise making a local copy of these files, as important data like this has a nasty habit of disappearing on the net.



I would love to. But I have no time. I'm working 30 hours a week at In-N-Out at the moment, and when I'm not working there, I'm in school. Plus, the FCC still hasn't gotten my new address updated yet.

I'll see what I can do to hasten the process, as my license will be up for renewal in a couple of years anyway.

Thanks for the extra resource with regard to FAT/VFAT - always good to have more info

I may have to start with just compact flash, I'm having a real hard time locating good data on floppy drives, connectors, timing, etc.

I have tons of resources for compact flash access, and a good amount for IDE access.

ps - I just took and passed my general today

That's a pity. I'm sure that with time and effort, an Internet search will yield something of value.



Awesome! Congradulations! Now if only I could take the time to take the test...

BTW, what's your QTH?

Hole in the wall (errr, hmm, Hohenwald), TN (I'm KG4WFX).

I'm sure you could probably pass with ease, I noticed on QRZ that you're a Tech Plus, I'm assuming from the old licensing grouping (novice, tech, tech plus, etc.) - I doubt the current general is all that different from the old tech plus.

So far with regard to floppy, most of the info I can find is the pinouts of the interface...

http://www.cpmspectre.pwp.blueyonder.co ... cat3_5.htm

and a bit more detail....

http://ohlandl.kev009.com/floppy/Floppy_Pinouts.html

I'm just going to have to find the magic combination of words to get me the info I want.

If you don't mind dropping a few bucks on a book, then I'd recommend "The Indispensable PC Hardware Book" by Messmer, which includes a lot about PC hardware, at least the older stuff. It'll tell you all about the hardware and some about FAT12.

My personal experience with floppy disks is that they aren't reliable, so be careful!

Scott

> Does anyone know of any good, clear, well documented / easy to follow
> references for interfacing with a floppy drive?
>
> I can either do it via compact flash or floppy

Good,clear,and well documented are not usually found in the same sentance as floppy controller datasheets.

There are 3 that I'm aware of
8271 (used on the BBC Micro,obsolete in about 1981)
177X (used variously,includes 1770/1772/1773)
765 or 82077 (most common)
The last one there is the one from the original IBM PC era,so is by far the most common - however you'll find it hard to get it as a discrete part - it's long since been integrated into chipsets.
You may however find the SMSC 37C669 and relatives worth a look.

You software will need to be pretty well tailored,you get an IRQ at the end of every sector op which in practice means on a DD disc you must be in and out within about 40us - so NMI required.

All have their own little quirks,bugs,and general annoyances - I'd steer clear of floppies if at all possible,the reliability versus cost versus data storage density is pathetic.

So - opt for flash of some sort.I'd look at compact flash (being parallel) or MMC/SD flash cards (as these can be wiggled using high level commands in SPI mode).

The difference with flash cards are that FAT12 doesn't cut it anymore and you'll have to use FAT16 (or once you bust through the 2G barrier or want vaguely efficient cluster sizes) FAT32.
All are pretty easy,I did FAT12
http://www.sprow.co.uk/bbc/dosfs.htm
which was fun,
Sprow.

interfacing to floppy drive is hard task, and for 6502 based project it may be even harder...
you may use pc ready io card (i mean isa multi-io card) or use wd series fdc (wd1772 or wd2772 is okay) but! 720kb disk (DD) needs 8mhz clock for WD controller, HD (1440) disks needs that clock doubled (and WD works up to 8MHZ (well... at least according to specs, but it may work reliable with 16mhz - this is device dependand, and cannot be relied on)
you may also use lower clock speeds and get lower density disks - for pc side there is no problem - pc controller can read almost any data as lons as is in FM or MFM coding and uses index hole (3"5 disc also have index "hole") for marking begin of track
interfacing IDE is as simple as building address decoder and some circuit to put 16 bit data to IDE data port at one write (but you can easly skip that - at cost of loosing half of device capacity)
if you need some examples i would encourage you to familiarize yourself with atari 1050 disk drive design (wd2772 & 6507) and some IDE interfaces for 8 bit atari computers
FDC 765 mentioned here is not very suitable for homebuilt project, and SMC chips may be found on most of pc multi-io isa cards

Gotcha. I'm currently living in San Diego, CA.



It's very different. The test is the same old General exam it's always been, plus being augmented with the new safety rules that the FCC has.

I'm not sure I agree with this. I would qualify this with, "It might be able to read any FDC 765-compatible disk," but even there, the FDCs in the PCs today have specific bit rates that it operates at (125kbps, 250kbps, and 500kbps). If it's too slow or too fast, it might not read them.

Also, while it might be able to read them, it certainly wouldn't be able to write them, which limits its utility to archival storage.

I bring up this point because the Amiga and Commodore 1571 disk drives both could read/write using MFM, but they are not 765-compliant formats (though, both can be made to read/write PC-formatted disks; note also that the 1571 also supported GCR recording for non-CP/M formatted disks).

to extend your knowledge amiga/commodore computers/disk drives were quite stupid - they read, yest, thats true, but raw data - it was cpu task to decode data into sectors - you got only bucket of bits after read, and you had to decode it by hand
for diffrent clock rates i though of 1 2 or 4mhz so it would give out bitrate acceptable for 765 compilant fdc controller

For what it's worth, I used to work for Amiga, Inc. I can assure you I know *precisely* what I'm talking about with respect to the Amiga.



To extend your knowledge a bit, that is true that the controller read a bucket o' bits. But it was the blitter's job to actually perform the MFM decoding, thus incurring near-zero CPU overhead (and what overhead there was was already overshadowed by the I/O latency from reading any subsequent tracks anyway).

Also, the Commodore disk drives were complete computers in and of themselves (complete with the ability to load software into them and run them). Thus, no CPU overhead on the main computer's CPU. I personally prefer this solution over the FDC-approach anyway, since it's more flexible (obviously, as they could read PC and non-PC diskettes that way).

The Commodore 1581 disk drive, unfortunately, did have a 765-compatible FDC chip in it. I guess it was a least-cost solution for Commodore.



I didn't say anything about clock rates to the FDC chip itself. But I do know that the actual bit rate over the floppy disk cable (e.g., the cable that leads directly to the floppy disk drive itself) is 125kbps, 250kbps, or 500kbps.

didn't you say you don't have any experience in fdc?
i tell you to stop acting as a guru, and thats big diffrence :]
i cannot verify if its possible to do mfm decoding or gcr decoding with blitter, but its primary task ist graphics and this is simple dma controller with boolean operations capability

I've never played around with a 6502 computers hardwarewise, but i have used an apple II which uses a 6502. Coulden't you interface the same way the apple II did. Although they did use a cardslot, and used a small ribbion cable, the other problem is it used 5.25" disks. Not really fun, but there could be a way to modify the interface for it to use 3.25 disks.

No, not at all. I said it wasn't my area of expertise.



No, I'm being honest. I've always been primarily interested in digital and analog interfacing, particularly sound and video (which is why I might sound like a guru to you in those fields. I apologize if I do; it is not my intention to be condescending. Rather, I wish only to share my experience and to educate). Floppy disks is one thing I haven't personally been involved with too much, and certainly not at the level between the floppy drive itself and its controller. Still, I'm familiar with why they work, even if I've never actually picked up a soldering iron and built such an interface myself.

I'm also involved with operating system design and implementation.



The trackdisk.device driver uses the blitter to accomplish MFM encoding and decoding. It does this by storing all the even bits in one "bitplane" and all the odd bits in another, and running a few blits over the data. The result is an encoded or decoded image. This information is documented (briefly) in the Amiga ROM Kernel Reference Manuals and the Amiga Hardware Reference Manual.

This is why the PC's FDC cannot read Amiga-formatted disks. Even ignoring the differences in the floppy disk track layout (where the Amiga gets 880KB of useful data on the disk with 80 cylinders, the PC only gets 720KB), the fact that the Amiga writes out all odd-then-even bits is itself enough to cause the PC's FDC to go into epilleptic seizures.

(For the record, while I AM in total support of Amiga-style full-track-buffering, I am NOT in support of its splitting of odd and even MFM encoded bits. It destroys the whole purpose of MFM to begin with, which is to maintain a self-clocking data stream. The fact that the technique worked at all seems dangerous to me; and, at least, that half the disk is thus being wasted, and that they could easily have gotten 1760K on a single double-density disk. For example, to maintain synchronization, the AX.25 amateur radio protocol depends on "bit stuffing," which itself could also be used on floppy disks. This could easily result in 50% to 100% improvement in storage capacity while not losing sync. But, I digress.)

I'm pretty sure it's not really possible (or beneficial) to do GCR decoding with the blitter -- at least, not in any way that would be faster than just having the CPU do it itself.