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.
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.
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.
"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
"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.
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.
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.
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.
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:
"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.
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.
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...
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.