[Coco] Driverwire server

[Boisy Pitre]

On Mar 11, 2009, at 2:39 PM, Roger Taylor wrote:

> 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,

This is a good approach.  Some time back, I tested a similar scheme  
(not under NitrOS-9) and had acceptable results.

In NitrOS-9, though,  it gets a little touchy, depending on how fast  
the server can respond to the client CoCo's query.  Under NitrOS-9, an  
SCF driver could be written which would hook into the F$VIRQ (virtual  
interrupt) vector.  This is called by Clock at a rate of 60 times per  
second; for the bitbanger, the response back from the server would  
have to be quick, because the driver could not afford to wait very  
long in its IRQ routine for a timeout condition.

It's an interesting problem, but with the right protocol and a little  
testing, it could probably be pulled off under NitrOS-9 without being  
detrimental to the responsiveness of the operating system.

Boisy