Re: Adding flow control to CC65 up2400 driver.

To be clear on the directions, then, it's the 8-bit client which is
receiving data, has got too much, or nearly too much, and would like to
tell the upstream host to stop sending?

I've seen that same situation using the BBC Micro's serial port and
connecting to a PC. The Acorn OS has a buffer threshold parameter, and I
found I needed to adjust it. That is, the BBC needs to maintain a lot of
space in the buffer, and as soon as it has less then 50 bytes it tells the
PC to stop sending. The reason is that the PC can take its time to respond
to the request to go quiet, and many more bytes may arrive.
http://beebwiki.mdfs.net/OSBYTE_%26CB

Others have seen the same, and set the free space to 100 bytes:
https://stardot.org./forums/viewtopic.php?p=58297#p58297
although I see they still report problems.

It's crucial to have the right cable connections, and a suitably
cooperative serial port behaviour on the PC.  It might even depend on the
responsiveness of the PC OS.

Ed


On 29 July 2018 at 16:45, Thom Cherryhomes <thom.cherryhomes@gmail.com>
wrote:

> Am barrelling through PLATOTerm, and I've found that checking the receive
> buffer in the main-line code and asserting flow control there doesn't seem
> to be 100% effective in dealing with what still looks like some buffer
> overrun.
>
> Given this code here:
> https://github.com/nanoflite/c64-up2400-cc65
>
> Would adding a buffer overflow check and asserting bit 1 of $DD01 to
> assert hardware flow control work? I'm asking because I know this code is
> _very_ timing sensitive, and I am not very familiar with the user port
> serial machinery.
>
>