[Coco] Coco to PC cable

Boisy Pitre boisy at tee-boy.com
Tue Mar 10 15:31:10 EDT 2009


> No flames here.  I'm always open for a peaceful group talk.
>
> I'm not sure I understand how any kind of "integration" of DriveWire  
> and CoCoNet (or their underlying protocols) could yield two systems  
> that don't eventually become identical.  Right now, they're not the  
> same by any means.  It seems that eventually the now-open DriveWire  
> would become CoCoNet, and CoCoNet would become DriveWire.  If this  
> happens, any competition at all would be in the EPROMs and/or the  
> paks they ride in, and software that uses the internet abilities of  
> either progressing network system.  I don't think the name DriveWire  
> will always describe what it does.  I think the name CoCoNet fully  
> describes where I'm taking the system.  These are some of the key  
> points that come to mind when I compare the two systems and where  
> they would otherwise be going.
>
> Here's a summary of what CoCoNet currently does:  As well as the  
> server, the *CoCo* can mount virtual disks from the web or remote  
> PC.  CoCoNet can request web pages and files and have them returned  
> on a mounted virtual disk.  These requests can append URL  
> parameters, making some serious things possible from the CoCo, like  
> live chat, multi-player games, etc. without adding any additional  
> protocol support.  Oh, and mounting virtual ROM Paks,... done in the  
> bitbanger version, not added to the 6551 version yet.

I don't have the benefit of seeing your CoCoNet protocol since you  
have not published it, so I cannot fully compare products here, but  
from your description, it is fair to assume that your product is a  
superset of DriveWire.

Even so, you could still adopt the DriveWire 3 protocol for disk  
storage and printing to remain compatible with the existing user base,  
and have your advanced features (web page saving, etc) outside of the  
DriveWire protocol altogether.

Adopting the protocol in CoCoNet would be a win-win for you and for  
the CoCo community.

For you, it would expand the use of your product immediately to Linux  
and Mac OS X for the disk functionality.   Do you plan on having  
NitrOS-9 support for CoCoNet?  Instead of writing your own drivers,  
you could adopt the DriveWire 3 protocol and not have to spend any  
time writing drivers.  It would just "work" under NitrOS-9.  And if  
you chose to publish your protocol, then NitrOS-9 could be made to  
adapt to any extra features that you would bring in your protocol.

For the CoCo community it would provide the following benefits:

1. HDB-DOS for DriveWire 3 users could talk to a CoCoNet server (you  
didn't indicate if the server software would be free or not, so this  
may not be an issue)
2. CoCoNet ROM users could talk to any DriveWire 3 server under Linux,  
Windows or Mac OS X for disk image support (DriveWire 3 servers are  
freely available for download)
3. NitrOS-9 users could boot from a NitrOS-9 disk mounted on your  
CoCoNet server

To enumerate the downsides of having two separate systems and  
protocols for disk storage:

1. CoCoNet customers could not use DriveWire 3 WinServer, MacServer or  
LinServer servers.
2. HDB-DOS for DriveWire customers could not use the CoCoNet server
3. Customers would be forced to choose between two products that have  
similar functionality; those who don't require web pages to be loaded  
onto their CoCo, or need NitrOS-9 support, would use HDB-DOS for  
DriveWire.  Those who would desire the web page and ROM pak features  
you offer would have to choose you product.
4. You would have to write NitrOS-9 drivers (assuming you wanted to  
support NitrOS-9, that is)

This is all, of course, your decision.  For me, there is no benefit or  
detriment to you choosing to adopt the DriveWire 3 protocol. Besides  
the benefits that I laid out above (additional server platform  
support, instant NitrOS-9 compatibility), the CoCo community would be  
the real winner here, and that's really what it's all about, right?

Is there anyone else here who would see the benefit of Roger adopting  
the DriveWire 3 protocol for disk storage in his CoCoNet product if it  
meant greater interoperability, greater choice and greater flexibility?

Boisy









More information about the Coco mailing list