[Coco] Stand-alone DriveWire devices.

[Boisy G. Pitre]

> Although you could probably slow down the communication, right?

That could be done by recoding the timing loops, but that would (1) 
potentially increase code size, since slower speed means more delay, 
and (2) would drop performance of DriveWire.  The 57600 (38400 for the 
CoCo 1/2) bps timing code was meticulously tweaked to get just the 
right amount of time out of the CoCo.

Now you *could* set up a CoCo 3 as a DriveWire server *IF* it was 
dedicated to that task ONLY.  In other words, the server CoCo 3 would 
spend all of its time watching for an incoming bit on the bit banger 
(from the other CoCo 3 which is a DriveWire client).  The server CoCo 3 
would receive the command, process it, then respond.  However, you can 
forget doing this under NitrOS-9, unless you're willing to live with 
your system being non responsive for most of the time.  Under Disk 
BASIC, this model could work, but again, the server CoCo would need to 
spend all of its time waiting for a command.

So although you could master/slave two CoCo 3's together through their 
respective serial ports, but that's a bit beyond the scope of what 
DriveWire is trying to do.  DriveWire's sole purpose in life is to give 
the CoCo an alternative to a hard drive system, and that means 
depending upon something faster and more advanced than the CoCo to act 
a server.

> Would they share the same disks? If so, how would you handle file 
> access?
> Such as, if two CoCos are accessing the same drive image for writing,
> would the server have any access locking? And if so, would it be file
> based, or drive based?

In the scenario that I envision, you would want to have each server 
serving separate disk images to separate CoCos.   Doing what you 
suggest would require record locking on a sector basis between two 
different instances of DriveWire Server.

Boisy