Wow; $192 for a 5.25" floppy disk drive
ray at arachelian.com
Sat Oct 21 05:54:39 CDT 2006
Philip Pemberton wrote:
> You send a packet to the broadcast address.
> Say your client is 10.0.0.1, and the target device is 10.0.0.2, and
> the subnet mask is 255.0.0.0. That means your broadcast address is
> 10.255.255.255. Sending a packet to the broadcast address means any
> device on that subnet will receive the packet. So the target listens
> on whatever port it's using, the source machine sends out a broadcast,
> and the target responds by sending a unicast packet (e.g. 10.0.0.2 to
> 10.0.0.1) back to the source to advertise its presence.
> As far as protocols go, UDP is nice and simple, but doesn't offer any
> form of guarantee that a sent packet will arrive, so you'd probably
> need to hack together some form of
> send/acknowledge/repeat-if-scrambled/repeat type system.
Keep it simple and open. Use protocols and code that already exist.
HTTP, FTP, Samba and NFS servers come to mind. Use Linux or some sort
of BSD. All the code is already built in. And yes, you can use DHCP
with those. Reuse some older PC like a P2. Otherwise, you'll spend
lots of time engineering the hardware AND the software. It'll be
difficult enough just to write the software to get it to do the core
task of imaging the disks in the first place. Don't make it more
complex than it has to be.
Don't be afraid of requiring a generic VGA monitor and a normal USB/AT
keyboard for configuration. It greatly simplifies things to have them,
and everyone has them already or they wouldn't be trying to image
floppies in the first place.
If you go with a custom black box design that lacks them, you'll wind up
re-engineering lots and lots of kludges just to hide the fact that this
is a computer. Treat it like a normal computer and slap some easy to
use UI on top of it. Hell, use Firefox and a web server to drive the
software. There are lots of wonderful tiny Linux distros that are well
suited for this sort of thing.
Keeping it as simple as possible and using what's already out there will
save lots of time, effort, and headaches. If you try to invent your own
protocols, you'll be working on the other stuff for half a year and
still not be able to build something that's as robust and as flexible as
reusing existing OS code.
More information about the cctech