C. Sullivan wrote:
Chuck:
It sounds like what you are looking for would be a microcontroller, some
Flash memory (or possibly a CF/SD/MMC/whatever slot), with a couple of
common floppy drive connectors (card-edge [5 1/4], card-edge [8"], and
the modern pin-style [for 3 1/2"]).
Basing it around the size of a stock 3.5" floppy drive, with the same mounting
points, might be nice. Card slot / LCD / whatever at the front, stock power
and pin connector at the back. Convenient mounting for systems with 3.5"
drives, or with 5.25" via a bracket (I bet lots of us have one of those
brackets tidied away).
8" is left as a bit more of an engineering exercise for the reader :-)
so you could take (as an example) a CP/M or Apple ][
disk image directly
from the Internet, drop it on a CF card, and plug it in to the computer
in question and boot from it. Heck, while we're at it, add a mp3
decoder chip, so we can put cassette images on it. *chuckle*
Bah, give it a wireless card and it can get its own darn images from the
Internet! ;-)
To be honest, I'd like it if the device did have a direct-link capability to
the outside world (whether it be RS232, USB, Ethernet, parallel, SCSI, or
whatever). But I'm not *that* bothered if it doesn't; it's not that difficult
to sneakernet a CF card back and forth between the device and a modern system
(except that I blew my card reader up a couple of months back :)
IMHO: I think that having the device aware of sector, let alone filesystem,
structure is a mistake though - it just adds complexity, increases firmware
size, and can never hope to support all the systems out there anyway. Better
to make the device good at its primary job - emulating a standard floppy drive
- and leave support for more complex things to tools that can exist on a more
modern machine as and when people feel like writing them.
I don't know enough about how floppy interfaces
work, but I know enough
about microcontrollers to see this as being a "not too difficult"
project from the hardware side. Coding it might be difficult, getting
all the timings right.. but it certainly does not strike me as
"impossible".
Timings shouldn't be too tricky I would have thought. Once you know the data
rate and RPM then you know how often to sample the data stream (on floppy
write) or output the current bit (on floppy read). There aren't many more
parameters; you'd have to simulate step rate and motor on/off delays but
that's about it (sensible defaults would probably work in a lot of cases as
they can be a lot faster than a real drive - making them slow enough so as not
to cause problems is likely the issue)
If I knew anything about PIC design* I'd get to doing some messing around with
it right now... :-)
* assuming that a PIC is fast enough; it'll have to read/write to the floppy
interface side at several times the floppy data transfer rate, so several MHz
- then there are program overheads on top of that... (you could almost do a
DMA approach to/from buffer memory actually and have the CPU relatively slow...)
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath