[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