[Coco] DriveWire

[Bill Pierce]

Tormod, to correct a misperception, The becker port runs at the same speed on emulators regardless of overclocking speed.
The Becker port uses TCP which is handled by the PC, not the emulated machine. The data packet is ALWAYS sent at the fastest possible speed the PC itself can handle regardless of the speed of the emulation. The TCP transfer is an "outside" process and not actually part of the emulation.
I have done tests with two instances of VCC running side by side, one at normal speed, one at 89mhz. Disk transfers run at the same speed and vport data does the same. There was no noticable difference.
One thing I did notice, with Vcc w/becker running side by side to a real Coco3 with dw4, the real Coco disk & vport transfers were faster than Vcc even though Vcc was at 89mhz. An example is my MShell software. It can read dirs & files from the PC to NitrOS9. On a real Coco3, the dir listings amd file transfers (using vport) are faster than Vcc at 89mhz. Vcc actually seems to "slow down" at higher overclock speeds when doing such transfers.
I mentioned this to Aaron once and he said it was probably due to the bottlenecks at both ends (client & server) of handling TCP data and buffering it to the serial emulation.

 

 


Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

 

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com


 

 

-----Original Message-----
From: Tormod Volden <lists.tormod at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, Feb 19, 2016 10:36 am
Subject: Re: [Coco] DriveWire

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 mostclients use it. Aaron's DW4 server doesn't honour it in all cases, sosometimes (if the client sends rubbish) it gets stuck in the wrongstate and you eventually end up with a "millipede" message in the logand a restart is needed.The DriveWire low-level drivers used in HDB-DOS and FUZIX (and prettymuch identical in NitrOS-9) are here:https://sourceforge.net/p/toolshed/code/ci/default/tree/hdbdos/dwread.asmhttps://sourceforge.net/p/toolshed/code/ci/default/tree/hdbdos/dwwrite.asmNote the Becker routines don't use a timeout by default because manypeople use them on overclocked emulators.In my experience (at 57600 baud and bit-banging) the whole thing worksvery reliably. Only when I experiment with buggy client drivers I endup with the DW4 "millipede" sometimes.Tormod-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco