[Coco] DriveWire

[Brett Gordon]

Both the DW server and the client are supposed to implement a
transaction reponse timeout of .25 sec.  This takes care of 99.9999%
of the sync problems.  There is a simple checksum that's also done on
disk transactions.  I rarely get any sort of CRC or timeout errors, or
command sync problem...even at the bitbanger's 230k.  Its so rare that
Aaron didn't do any error checking on the virtual serial ports...and I
rarely have problems with those**.   Just shut off the interrupts
during the entire length of a transaction, and don't dally between
sending your DW command, and the reception of the server's response,
and I bet you'll never loose a byte.  Checking for framing errors and
timeouts is a good thing, but not horribly dire if you're looking for
simplicity.

I think we have some Z80 code in Alan Cox's Fuzix project that
implement DW.  OK, I found some DW code for the TR80 series:
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform-trs80/drivewire.s
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/dev/devdw.c


** we need to hack a transactional timeout into the vport stuff... the
serial servlets will lock up and become dead if you shut your coco off
at the wrong time.  Disk transactions will still work fine, but a
restart of the DW server is needed to allow the Vport system to run
again.  Anyone good with Java ?

On Fri, Feb 19, 2016 at 9:45 AM, Mathew Boytim via Coco
<coco at maltedmedia.com> 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.
>
> As I mentioned, my driver is working and except for my own SW and HW bugs I haven't seen any errors or see it hang.  But now that it's working I'm starting to think about robustness.
>
> By HW bugs I mean in my external 16550 uart circuit.  The M1/3/4 rs232 is limited to 19,200 baud because of the baud rate generator so to exceed that I interfaced a 16550 uart which with the right xtal allows me to even go faster than 115,200.  The only xtal I could find in my parts drawer will let me go to 230,400 and that is working well, but I want to try 460,800 when I find a different xtal.
>
> Bitbanging like is done on the Coco is also possible but I will leave that exercise to someone else.
>
> Thanks,
>
> Matt
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco



-- 
Brett M. Gordon,
beretta42 at gmail.com