[Coco] DriveWire

[Mathew Boytim]

Thanks for the replies.  So are you saying that after 0.25 sec the server will return to the "waiting for command state" so if the client ever gets stuck for 0.25 sec waiting for any byte from the server it should go to a state where the next transfer with the server is to send a command?

Are most people using DW4 then?  I am currently using a version of DW3 hacked to get the bauds I need.

Thanks again,

Matt

--------------------------------------------
On Fri, 2/19/16, Tormod Volden <lists.tormod at gmail.com> wrote:

 Subject: Re: [Coco] DriveWire
 To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
 Date: Friday, February 19, 2016, 10:35 AM
 
 On Fri, Feb 19, 2016 at
 3:45 PM, Mathew Boytim wrote:
 > I'm
 working on a disk driver for the Models 1/3/4 to use DW -
 just disk at the moment.  The DW protocol itself does not
 seem very robust because the command values are not unique
 and can appear within data and there is no explicit means to
 achieve a positive sync with the server.  I think there
 could be some ways such as if an error or timeout occurs you
 could send 256 1-byte commands to the server which after 256
 of them you'd be guaranteed to be in sync.
 >
 > Currently my driver
 is working but I don't do any timeouts or error checking
 or error handling other than report DW errors up to the DOS
 - but if a character was ever lost then the driver and
 client would be hopelessly out of sync with no recovery
 other than to restart both.
 >
 > So I'm of course wondering what the
 Coco disk drivers do regarding timeouts and error
 checking/handling.  Can someone point me to some DW driver
 source as an example of the design intent or maybe just
 outline the error checking/handling?  Or maybe there is
 none and DW just assumes a fundamentally reliable connection
 as my driver does currently.
 
 Hi Matt,
 
 There
 is a timeout specified in the DriveWire protocol and most
 clients use it. Aaron's DW4 server
 doesn't honour it in all cases, so
 sometimes (if the client sends rubbish) it gets
 stuck in the wrong
 state and you eventually
 end up with a "millipede" message in the log
 and a restart is needed.
 
 The DriveWire low-level drivers used in HDB-DOS
 and FUZIX (and pretty
 much identical in
 NitrOS-9) are here:
 
 https://sourceforge.net/p/toolshed/code/ci/default/tree/hdbdos/dwread.asm
 https://sourceforge.net/p/toolshed/code/ci/default/tree/hdbdos/dwwrite.asm
 
 Note the Becker routines
 don't use a timeout by default because many
 people use them on overclocked emulators.
 
 In my experience (at 57600
 baud and bit-banging) the whole thing works
 very reliably. Only when I experiment with
 buggy client drivers I end
 up with the DW4
 "millipede" sometimes.
 
 Tormod
 
 -- 
 Coco mailing list
 Coco at maltedmedia.com
 https://pairlist5.pair.net/mailman/listinfo/coco