USB Universal Floppy Disk controller

Philip Pemberton philpem at
Mon Mar 14 17:31:37 CST 2005

In message <1110833470.10973.51.camel at weka.localdomain>
          Jules Richardson <julesrichardsonuk at> wrote:

> I forsee four goals to make it useful:
>   o  Cheap

CPLDs tend to cost between £10 and £20 each in 1-off, but you can stuff
nearly all of the logic into just one of them. You could even make the board
in-circuit reprogrammable if you wanted, but I'd be tempted to use an SRAM
FPGA instead of a CPLD if I did that, simply because most FPGAs have open
programming specs (it's something of a requirement - if you have to reload
the fusemap every time you powercycle the chip, you're not going to want to
drag the manufacturer's programmer around with you).

>   o  Simple to build by anyone with a few electronics skills.

Can you solder a 0.1" pitch PLCC socket? :)

>   o  Easy / quick connectivity

Parallel port then. I'd add "Portable across multiple platforms" which
basically means "parport or nothing". Every desktop and laptop machine I've
seen has had an IEEE-1284-compliant (or compliant to a reasonable degree)
parallel port.

> at it yet, but doubtless a bunch of us on this list could come up with
> something that'd cater for all tastes (plus the really low-level
> software would all be open source anyway!)

"Here's the CPLD sources, the schematic, and the interface spec. Go forth and
Have Fun."

> Personally I'm not a fan of a USB version though; I'd rather have
> parallel as pretty much any machine has a parallel port - USB limits me
> to newer PCs and Macs (plus software interfacing *might* be harder). 

Me neither - software interfacing for USB is a total pig, not to mention the
fact that you'll need some form of USB controller in the hardware.

> Priorities seem to me to be (highest first):
>   o  Reading disks

Easy - start when you get an index pulse, then stop when you get another
pulse. I'd be tempted to make the stop pulse lag a bit though, just to make
sure there's enough overlap to be reasonably sure that you've got all of the

>   o  Writing back a disk image

See above.

>   o  Decoding disk data on host machine

Synchronisation would be the hardest part of that. If you know where the bit
boundaries are, you can just scan through the data and replace the
flux-reversal sequences with binary bits.
If you wanted to read an Amiga floppy, you'd have to use some form of
circular buffer, find the sync marker, then move the data around in the
buffer before decoding it.

>   o  Modifying disk data on host machine, re-encoding back to floppy

Building an MFM image may actually be easier than decoding one :)

> Happily, that's probably order of complexity too, easiest first :) (I am
> coming at this from a preservation point of view, rather than being able
> to create disk images for use with emulators, say)

You could decode the images into whatever format you wanted. It's just a
question of software.

I've got some digital design knowledge and I've got four weeks spare starting
Friday - I might be able to look into designing something that would read
disks. There should be a spare 3.5" drive around here *somewhere*...

Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
philpem at              | ViewFinder, 10BaseT Ethernet, 2-slice,          | 48xCD, ARCINv6c IDE, SCSI
... Don't dispute death unless you've lived through it.

More information about the cctech mailing list