[Coco] Driverwire server

[Roger Taylor]

At 05:14 AM 3/11/2009, you wrote:
would be no expectation for multi-tasking in that environment, and the
>server CoCo could spend all its time waiting for the client CoCo to
>send requests.


>I'm not trying to discourage you from writing something, just be aware
>that this would be an issue that you would have to find some way to
>work around.


Boisy, the problem is solved for one CoCo that wants to run stuff 
while monitoring the bitbanger port.

The "listening" CoCo sends a constant beat of packets to the server 
as fast as it needs to, 60 times a second, 30 times, 10, 5, 1, 
etc.  Doesn't matter that much.  It can be timed by interrupt, or 
sent periodically at certain points in in the running code.

The packet?  The smallest possible:


Tell the server to send 512 bytes from it's Transmit Buffer:
$F200

$F meaning, Send Me Some Data, and $200 meaning the block size

Or better yet.... if the packets are to be 256 bytes or less:

$F8    where $8 really means $80 for the block size

Only one packet size scheme should be adopted, ofcourse.

The client CoCo should immediately be in bit sync to expect the 
return packet.  The server always send a block back.

The server sends whatever is in it's Transmit Buffer (not to exceed 
the Expected # of bytes), followed by filler data for any remaining 
bytes if under the expected # in the stream.

Think about the scheme before commenting.  I've already done this 
under Disk BASIC using IRQ and the timer interrupts.  The flashing 
cursor just keeps on flashing like nothing's going on in the background.

The client just appends the data to a circular buffer as usual and 
the mainline code reads from the buffer at it's own speed.

You can balance the protocol by tweaking the rate at which the CoCo 
contacts the server, the # of bytes to transfer in a block

-- 
Roger Taylor

http://www.wordofthedayonline.com