USB Universal Floppy Disk controller

[Jules Richardson]

On Mon, 2005-03-14 at 11:55 -0800, Dwight K. Elvey wrote:
> >From: "woodelf" <bfranchuk at jetnet.ab.ca>
> >Look what you are doing is building a generic floppy disk controler.
> >The only high speed device what you use to sync the  data/clock pulses
> >to the system cpu clock. The rest is software.  I'd sooner use a CPLD
> >designed for generic bit sampling but a PIC would also work with
> >a digital data/clock seperator. Now would getting the people who do
> >cat-weasel create a USB version be a better goal?
> >Ben alias woodelf
> >PS. What about hard-sectored floppy disks, that too may  need reading
> >too?
> 
> Hi
>  I think you are missing what I am saying. The SPI is just
> a shift register that takes an external clock. It can be programmed
> to automatically DMA transfer into memory. It is the perfect zero
> additional logic circuit to use. You don't need to build a
> data/clock separator or anything. Just sample the data.
> One could even make the output SPI provide write data. These
> chips are designed to load their programs from a single
> flash or EPROM so the entire hardware requirement is almost
> nothing.
>  I see others on comp.os.cpm talk about using a 50MHz variant
> of a Z80. I think most miss the point. These DSP's are 30 MIPS+
> not just 50 MHz clocks. They have enormous capabilities in
> a relatively small package. It was like they were designed for
> this project. You don't need to create a CPLD since the hardware
> part is already done for you.

What about cost? (irrespective of how the device physically connects to
the host machine)

I forsee four goals to make it useful:

  o  Cheap
  o  Simple to build by anyone with a few electronics skills.
  o  Open 'source' (all schematics etc. available)
  o  Easy / quick connectivity

Catweasel seems to lose out on 1, 3, and 4 - and 2 isn't relevant in its
case. Can't comment on how nice its software API is as I haven't looked
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!)

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). 

Priorities seem to me to be (highest first):

  o  Reading disks
  o  Writing back a disk image
  o  Decoding disk data on host machine
  o  Modifying disk data on host machine, re-encoding back to floppy

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)

cheers

Jules