Date   : Sat, 04 Oct 2003 10:02:44 -0700
From   : Angus Duggan <angus.duggan@...>
Subject: Re: XFER v4 problem

This is a resend; I had the wrong email address registered, so my mail to the
list didn't get out. I don't think so, anyway, apologies if you've seen this
before.

Bob Devries writes:
>> OK, just tried version 4 of XFER on my laptop ('486 running Win95), and it
>> works fine there.
>
>OOps, that was premature. V4 still has problems with files >4096 bytes long.

Sorry, I've not being tracking this particularly closely. Is this sending to
or reading from the BBC?

There is a 4096 byte buffer used for sending to the Beeb. I do remember
having some problems getting the Win32 serial port settings correct; I tended
to use it on Linux most of the time. There is a comment in xfer.c that says:

    /* The send loop is revolting. I don't like using sleep(), but it seems
       unavoidable; after the BBC has got a buffer full, it saves to disc.
       While it is saving, and NMI is claimed, it cannot alter the CTS line
       fast enough to prevent buffer overruns (even experimenting with FX 203
       doesn't help. We get around this by matching buffer sizes exactly, and
       putting in a delay after sending each buffer which should be long
       enough to write the buffer to disc. We also send the buffer in small
       chunks and allow the output to drain between writes. */

If the problem is in sending to disc, this could be the problem, especially
if your disc on the BBC end is slow. There is a 1 second sleep per 0.5Kb
sent. This may not be enough, and it may be possible for the sleep to happen
at the wrong time (thus missing CTS line changes). I've always preferred
hardware handshake using CTS/RTS when making up serial cables.

I have been meaning to think about making the protocol more robust by
introducing block confirmations, block CRC checking and re-sends, but haven't
yet put the effort into working out a design that is robust from both ends.

a.