Wow; $192 for a 5.25" floppy disk drive

Jules Richardson julesrichardsonuk at
Fri Oct 20 14:56:33 CDT 2006

Doc Shipley wrote:
> cclist at wrote:
>> I *like*  the idea of ethernet myself.  Hardly anything, save for some 
>> very vintage gear that doesn't understand it.  I wonder if you could 
>> use one of the standard services, such as ftp, to nearly avoid having 
>> to write anything for the host system...
>   Hrrm.  TFTP would be a natural for this, at least if you limit the 
> host to Unix/Linux systems.  I have no idea how you'd fare for a TFTP 
> daemon in WinWorld.

Hmmm, I wouldn't think that the device being the client and the 'attached' 
computer being the server is a good idea; given that we'd likely want to 
support more than one OS, it opens up problems of file naming and the like 
(which aren't an issue the other way around, as it's the OS-specific bit of 
software running on the attached machine which prompts the user for a filename)

Some sort of server on the device *might* be an option depending on 
architecture and what tools are out there; HTTP and FTP protocols aren't 
rocket science.

Personally I'd like to treat this as though a single attached computer talks 
to a single 'remote floppy' device for the purpose of transferring a single 
disk image only at this stage - just to keep things as simple as possible and 
hopefully speed up development times. Later on there might be scope for having 
the device able to store more than one image at once or other fun things...

> 2) RS232/RS422 serial is getting harder to support, and will continue to 
> get worse.  USB is simply not an option for some of us.  Anyone with a 
> PDP-11 or a C64 can support an ethernet connection, and almost (?) 
> everything needed for implementation for both host and appliance is 
> already there.  Plus, the standards for ethernet transactions are not as 
> "widely interpreted" as those for USB or serial.

Yep. I am concerned that OS support for sending raw Ethernet packets from any 
kind of user-space app just isn't there in most modern OSes, though. I really 
think it'd have to be IP-based to make the 'client' software do-able (and to 
prevent problems with any intermediate network devices), even if that means 
more complexity at the device end.

> 3) It might be well to stipulate and design this as a tool for advanced 
> users only, at least to start.  I'd happily settle for something simple 
> and raw with 8 pages of install instructions.  As an example of what I 
> mean and why, if TFTP is used, having that set up by hand makes it more 
> likely that the user understands the security implications and will 
> handle that.

If the device is the 'server', what's to set up? Plug it in, give it an IP 
address (method to be determined), fire up the client software and talk to it.

> 4) Same concept concerning host platforms.  I vote for $FreeOS as the 
> initial supporting platform, but if DOS works better, so be it. 

I'm of the same mind there. I expect nearly everyone who will want this can 
easily rustle up a DOS / Unix / OSX / whatever system, but Windows is more 
problematic for some of us.

> 5) For anyone not a network geek, DHCP is a right pain to manage, as is 
> broadcast TFTP.  Again as a short-term implementation, how about 
> stipulating a dedicated interface, with the IP preprogrammed and 
> programmable?  If  can't leave it dedicated, I could set the host IP to 
> talk to the appliance and reprogram the appliance IP and TFTP target to 
> match my subnet.  That should actually reduce the amount of setup on the 
> host side.

That was the reason for my question about DHCP; I've almost exclusively used 
static IP addresses for anything I've ever set up (mainly because most of the 
time they've been servers), so my knowledge of DHCP is lacking.

I can't think of an easy way of doing that initial device configuration in an 
Ethernet world, though; DIP switches and the like requires a lot of them, but 
any other configuration seems to require some other form of interface to 'kick 
start' the initial config.

> 6) Git 'er dun. 

For sure...

I'd love for someone to Just Do This. Providing it's cheap I don't really mind 
how it's implemented either; I'd rather have something than nothing. What I 
don't want to do is pay 'too much' for something that doesn't do what's needed 
though, or is completely inflexible.

It's probably worth exploring ideas for a couple of weeks, though, just to 
see what comes of it. After that, hopefully someone can just get on with it :)

If you've ever wondered how you get triangles from a cow
You need buttermilk and cheese, and an equilateral chainsaw

More information about the cctech mailing list