Wow; $192 for a 5.25" floppy disk drive

Doc Shipley doc at
Fri Oct 20 13:52:31 CDT 2006

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.

   Normally TFTP services are read-only or allow only modification to 
existing files, but the daemon can be told to allow file creation.  The 
client code - appliance end - is necessarily tiny, it's lightweight, and 
most current clients and daemons support RFC1783 negotiation for 
large-file transfers.  The appliance could then boot from the host, too, 
but that seems like overkill to me.

   I have a couple of thoughts to offer about this basic concept.

1) I like the idea of using something like ARM processors  With 
everything built into the chip, you'd not only get a much smaller 
component count, but it seems to me that most of the layout and basic 
code would likely be already out there.  All that spells a lower 
long-run cost in general, and more universal accessibility.

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.

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.

4) Same concept concerning host platforms.  I vote for $FreeOS as the 
initial supporting platform, but if DOS works better, so be it.  Get it 
out the door and running, and somebody else will write support for the 
other platforms.

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.

6) Git 'er dun.  I'd like to point at The Great Universal Archive Format 
Project of a couple of years ago.  Trying to anticipate and solve every 
possible permutation killed that deader than hell.  Design in some room 
to grow, cover the basic common disk formats, and expect v1.0 to suck.

   I don't have any design skills to offer, but I'd throw some dollars 
in the pot and such free time as I have for testing.  This is a tool 
that I'd very much like to have.


More information about the cctalk mailing list