maboytim at yahoo.com
Fri Feb 19 10:56:20 EST 2016
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.
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:
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.
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:
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
Coco mailing list
Coco at maltedmedia.com
More information about the Coco