Floppy Drive Interface

Aaron193

Hello

I am curious to know if it is possible to use a Propeller microcontroller to access an internal floppy drive. Does anyone know of any third-party adapters that a propeller microcontroller can use to control a floppy drive? (I'm trying to see if I can use a floppy disk, not external EEPROM to boot up a Propeller Microcontroller).

Mike Green

I'm sure it's possible, but not practical. There are floppy controllers that handle a lot of the details of decoding the data stream from the drive and managing the track stepping and one of these could also be interfaced to the Propeller.

You can't use anything other than a standard 32KB or larger EEPROM or a PC (over a serial port) to boot the Propeller. The boot loader in the ROM is specifically written for these two sources.

David B

I wrote a propeller program that reads sectors from a floppy, just to learn about how it's done, and it worked pretty well.
But I never got so far as actually traversing a filesystem on it.

David

Aaron193

So are there any third party adapters I can use to do this, or will I have to make my own PCB? Also, if I would have to make my own PCB, can someone include a pinout for a standard Floppy drive?

StefanL38

hello aaron,

a floppy has about 1,44MB storage capacity

why don't you use an SD-cardslot which you can get with much more capacity

there are already drivers for it for the propeller

SD-Cards are smaller and tougher than floppy-disks
and they are an up to date hardware to connect to PCs

or mounting an EEPROM onto a small PCB with an 10-pin double-row PCB-connector to have a tough mechanic solution to plug in/out different EEPROMs?

greetings

Stefan

QuattroRS4

Aaron,
You wanted the pinout for floppy drive www.interfacebus.com/PC_Floppy_Drive_PinOut.html

Why not look at the SD card routines out there ? Or are you deliberately going retro ?

Regards,
QuattroRS4

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

RobotWorkshop

Controlling the floppy drive directly would be messy as there are all sorts of issues that can some up. Write pre-comp setting, track to track access times, data rates (single, double, Hi-Density), etc. If you want larger storage for your project than the SD cards are the way to go. On the other hand if you want to do it as an experiment and to learn about floppy technology before it complete disappears then it can be fun and there are a couple ways to go about it....

You can search for details on existing floppy controllers. Most of the older systems used on of the Western Digital floppy controller chips (1771, etc). One site that came up is:

http://www.swtpc.com/mholley/DC_5/DC5_Index.htm

Another choice may be the 765 disk controller chip. The floppy controllers handle a lot of the nasty little details of controlling the drives and reading/writing the data.

Alternately you could try to control the drive directly but its a lot more work.

Good luck,

Robert

David B

There is no need for any special interface board to connect a floppy to the propeller, although one would certainly look better than a handwired connector.

I agree with everyone who says that the floppy isn't the best device for modern data storage. But on the other hand, it's an excellent project for getting some propeller coding experience and for learning low-level real-time bit detection, bit encoding, CRC calculation, propeller cog usage, stuff like that. And it's fun for retro enthusiasts to actually see the floppy run!

Here's my code. It reads and returns the contents of a floppy sector, by number. The example here returns the first sector of a FAT12-formatted floppy and verifies that the last four bytes contain the FAT boot sector signature "AA55". But it's customized for using the LCD display on my homemade breadboard, so while it may be useful as a reference for how to access floppy bits, it won't run as is on other propeller boards.

The raw floppy data bits arrive so fast that I decided to use two assembly cogs - one cog to detect the timing between the magnetic flux transition bits and generate the 16 bit MFM-encoded words, and another cog to read the words, detect sector sync patterns, translate the MFM into 8-bit data words, calculate header and data CRCs, search for the requested sector and copy the 512 bytes of extracted data back to the hub.

I was thinking that there is probably enough time in the bit detection cog to also do the CRC calculation as each individual bit is detected; that would be a nice enhancement, but I haven't gotten that far. I also haven't done any sector writing; that'll be an entire new phase of this project, if I ever get to it.

On my homemade propeller breadboard, I found myself experimenting with so many 5 volt devices that needed a few bits of both input and output that I made a "permanant" parallel port, wired like a PC parallel port and using the same 25 pin "D" connector. Voltage conversion from the propeller to the outputs is done by sending the propeller 3.3V signal through some 74HCT14s to emit 5V. Conversion from 5 to 3.3 is done by passing the incoming signal through more 74HCT14s, then into a 2.2K-3.3K voltage divider, where the propeller reads the divided voltage.

So with that parallel port in place, all the floppy needs is for 7 output pins and three input pins to be directly wired from a 25 pin "D" connector to a floppy cable connector. You can see the little perfboard adaptor in the picture. My code explains which floppy pins are needed, but you'll have to use the floppy cable pinout to locate them, with the usual hassle of translating from the floppy hardware pin configuration to the orientation of the pins at the far end of the cable connector.

Personally, I wouldn't bother using a floppy control chip. If you really want to go to that trouble, then why not use a FRAM or an SD card or something modern, faster, with more storage and probably more reliability. As I've shown, the propeller is able to read and decode the raw floppy bits. But everybody's different; someone else may want to use a controller chip, and I'm sure the learning experience would be helpful.

I'd already written FAT12 access routines for an MMC card and had written code that allows multiple files to be open at once for a WAVE player project. But I got to thinking that instead of just copying and embedding the FAt12 routines from the MMC to the floppy code, why not try to create general filesystem code that allows sharing of common routines?

I have this grand vision of a filesystem framework for the propeller. At the lowest level, You plug in device initialization and sector access code for whatever device(s) you're using, maybe a floppy, or an MMC or an SD card, or a hard drive. On the next level, you provide FAT12, or FAT16, or FAT32, or some other filesystem routines. On a level above that, you provide directory management routines that are common to all FAT filesystems. On the topmost level, you open files, read, write, append, delete, close, list directory contents, etc.

But it's really slow work...

David

Fred Hawkins

David,

Gee, that's a gorgeous board! Very clean and concise. Two general questions:
1) what drives the alphanumeric? Also, is the lcd serial?
2) what's the card that hangs off the right side?

If you have a schematic or block diagram, please share!

Fred

tekochip

I opted for the uAlfat for my project, which·allows you to use USB thumb drives, or SD cards.

http://www.ghielectronics.com/details.php?id=1&sid=3

The uALFAT has an RS232, I2C and SPI interface, so you can use whatever works best in your application.· I opted for the I2C for a bunch of reasons, and even still it's fast enough·to stream compressed audio out of the thumb drive.· Since the uALFAT already contains all of the low level communication and FAT, you only need to send text commands to it to open/read/write/close files.· This leaves more room for your propeller application.

David B

Thanks for the compliment, Fred. I've never had my board called gorgeous before.

I really don't have a schematic because every time somebody writes up about some cool new device, like an audio DAC, or sigma delta ADCs, I rip out the least-recently-used circuit and build in the new circuit. The board is just a conventional propeller with power supply and serial programming circuit and eeprom, with -

sigma-delta ADC (thats the board hanging directly off a couple of bent-up propeller pins)
stereo DAC driving a mini phono jack
SD/MMC card socket
Seetron LCD display up on the raised support (serial, probably much like the Parallax serial LCD displays)
seven-segment LED for simple number display as well as 7 general purpose indicator LEDs
9-pin "D" connector so my Garmin GPS can feed in its 1PPS timing signal
and the two 25-pin parallel ports, one of which is currently running the floppy.

Fred Hawkins

"rip out the least-recently-used circuit" ... my guess it that the flip side is wire-wrapped, but maybe you do something else?

My reason for asking about schematic or block diagram is that your prop's pin allocations are impossible to see on that board.

David B

Yes, you're right, it is wire-wrapped on the back side. It's kind of a rats nest in appearance so even a photo of the backside probably wouldn't help much.

But I think I can answer your question. Look at the file "utilities.spin" in the attached code. In the comment area at the top of that file there is a full listing of the most current pin assignments, sometimes also with notes about how the pin connects and how it's used. As is typical with code documentation, I don't always update this description after changing pins around, but I think in this case it is pretty much correct.

The board pin assignments are pretty random. At first I organized all the pins for one device together, but as the board grew and evolved over time, I've had to sometimes use whatever pins are available to drive some new device.

David

Fred Hawkins

doh! Slaps head with spin file