Using a PIC as a floppy disk controller

Anyone have a thought on using a PIC as a floppy disk controller? Does it seem feasible? For 8 bit computer collectors it is getting hard to find parts these days. It would be great if we could come up with a controller which could use a standard 3.5" 1.44 Mb floppy, and also some of the older

5.25" floppy drives. That way we could transfer software back and forth.
Reply to
Homer J Simpson
Loading thread data ...

Don't knoe, last time I used microsoft backup utility to retorea backupvit said it wass not compstiblre with itself.

DNA

Reply to
Genome

I hate to think why anyone would want to !

Graham

Reply to
Eeyore

The raw data rate off the floppy drive is something like 1Mbps, which is a little much for a PIC. On the other hand, the PIC-compatible Ubicom microcontrollers could probably handle it. The code to read a sector would have to be tight & efficient, but should be quite doable.

Your main problem, I expect, will be finding enough program & data space to implement the file system. For FAT16, you might just manage to get it into a

4kB program/256 byte data part, but for FAT32 I think you'd be out of luck.

Personally I'd be tempted to do it with something like a small CPLD (or perhaps the simplest of the Ubicom CPUs) along with something like an Atmel AVR -- tons of memory, no problem whatsoever getting all of FAT32 in there. These days 32 bit CPUs are cheap enough that you might head that way as well to make porting the C code a little easier... the Alfat guys did this with their "FAT file system IC"

formatting link
.

Years ago Sparcom built a floppy drive for the HP-48 calacultor, making the device appear as a "terminal" (if you will) that spoke the Kermit filte transfer protocol to move files around. I believe it was effectively a really stripped-down PC in a box... 8086 or similar, NEC 765-compatible controller, etc.

---Joel

Reply to
Joel Kolstad

Interesting. I am only going to use this on floppies - IIRC even the 1.44 Mb drives only run 500Kbps so perhaps a PIC will work. I figure that the PIC will have to assemble the serial bits into bytes and deal with the inter sector gaps and reading the DAM and track / sector numbers.

I do recall that the Woz built his controller out of TTL, though in an ingenious way. Still his clock rate was way below a PIC chips' abilities.

Reply to
Homer J Simpson

"Eeyore" wrote in message news: snipped-for-privacy@REMOVETHIS.hotmail.com...

Can't buy the drives. Can't buy the floppies. Can't even buy the damned envelopes or labels!

Reply to
Homer J Simpson

"Homer J Simpson" schreef in bericht news:REnNg.3636$bf5.3245@edtnps90...

Why? There are still plenty of 3.5inch drives around and I bet you can find a working 5.25incher too if you look hard enough. Why go through all the trouble of getting such a device to work?

But from a purely technical standpoint, I see no insurmountable hurdles.

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Guy Fawkes

"Homer J Simpson" schreef in bericht news:REnNg.3636$bf5.3245@edtnps90...

The old PC floppy controller contained a WD92C32 or similar dataseparator and a NEC765 or similar floppy controller. Although both functions can be done in software I doubt a PIC to be fast enough.

petrus bitbyter

Reply to
petrus bitbyter

That's pretty much what I was suggesting with the "small CPLD" approach. You can get, e.g., 64 macrocell CPLDs that aren't much bigger than the size of your little fingernail, and stuff as much logic into them as a couple dozen discrete "jellybean" logic ICs ( Granted, Joerg might be able to do it more cheaply using jellybean logic... :-) ). The "fast" part is sampling at a MHz or so to find the clock and data bits, synchronizing to them, and then bundling up the data into, e.g., an 8 bit latched output that a PIC could read.

Back around 2003 I provided a modicum of assistance getting the Commodore One

formatting link
floppy interface going. She was using large Altera FPGAs, and the floppy interface did end up as some pretty small "fast" logic cells with the 6502 core having all the file system smarts. Hence if you're up for doing a larger FPGA design, there are free microcontroller cores on, e.g., freecores.org -- I believe some are even PIC compatible.

---Joel

Reply to
Joel Kolstad

... eBay?

Reply to
mrdarrett

Here's one:

formatting link

When all is said and done, though, when you add the shipping cost on a couple of these, the DIY approach might be a good one...

Try also the local thrift stores. I'm sure they'll have a bunch of '486s (or older) that no one wants anymore, that has floppy drives...

Regards,

Michael

Reply to
mrdarrett

Wasn't the goal of the OP to build a controller ??

There seems to be some hand waving to how best construct such a device.

I am sure the controller will need to handle IBM HD format, other wise whats the point.

The WOZ controller did not even read/write the 160KB floppies from the early IBM PC.

Anyone who is serious about building such a device, please be aware the the data separator in the problem. Moving stepper motors in not moving data bits.

As others have mentioned, the data stream is 1 MHz. Some processors may be able to handle this, but hardware is the only way to go here.

This is what I have used :

formatting link

So, unless the OP wants to play with an ancient floppy drive that is not compatible with a PC, yes you can write your own format on the media. It just won't be compatible with anything.

Good Luck

donald

Reply to
Donald

it

would

to

into a

luck.

Atmel

there.

well

formatting link
egory_Code=FF).

days.

a

the

really

controller,

You can clock the data into a shift register at say 8 times the expected bit rate, and then clock that into an external memory if necessary, you can then process it at liesure, decoding the pulse positions is easy.

If the file system code doesnt fit into a pic you could just transfer the raw data to a pc and do it there, the file system isnt part of a controller anyway.

Colin =^.^=

Reply to
colin

Don't know what your requirements are, but did you have a look at JDR or Jameco?

eric

Reply to
Eric

I'm hanging onto the 2 5 1/4 drives I have

Graham

Reply to
Eeyore

What about either using or duplicaing the function of a WD 1771 floppy controller. I used these in several home computer designs back in the early '80s. For info check:

formatting link

20Sheet.pdf
Reply to
Smaug Ichorfang

"Smaug Ichorfang" schreef in bericht news:Xns983CBC48B2F5Agoblineater@207.115.17.102...

This chip provides the same functionality the NEC765 does. A quick look shows me that it has its own dataseparator but it can handle external separated data as well. I missed the capability of supporting MFM which is essential for handling DOS formatted disks.

petrus bitbyter

Reply to
petrus bitbyter

kbps use

2000 Tape streamers 1000 2.88M disc 500 1.44M disc, 1.2M disc 250 720K disc

Ie you will most likely only see below 250 kbps bitrate. And you can proberbly use a onchip timer to get accurate length between pulses. And write those to memory.

Then decode pulses without timeing constraints.

You will likely see FM, MFM, or GCR formats.

Reply to
pbdelete

Thanks for the info.

The older drives used the WD FDCs and were very simple, either FM or MFM. IIRC only the Apple used GCR.

Reply to
Homer J Simpson

I believe the Commodore disk drives did as well.

In the Commodore 64-compatible drives (e.g., the 1541) they used the (6502, surprise surprise!) CPU to perform the GCR encoding and decoding and -- similar to the Apple II -- some handful of TTL logic to pull the raw data off the disk (as sopposed to using an actual disk controller IC). It always seemed ironic to me that they were clearly up for a bit of a challenge there, but they used a serial interface back to the C64 that was something like

2.5kbps -- slower than modems! (OK, ok, I never had better than a 2400bps modem on a C-64, but still...)

Of course this gave rise to the very well represented "fast loader" software market...

Reply to
Joel Kolstad

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.