Re: Adding flow control to CC65 up2400 driver.

On Sonntag, 29. Juli 2018 17:42:56 CEST Ed Spittles wrote:
> Oops, I'm in too deep to help there - hopefully I've helped to clarify the
> situation. My guess would be yes, the NMI service routine is a good place
> to act early in checking buffer space and turning off the sender, but yes,
> it's very critical code and you'd need to find the right place to do that
> work, and that might be difficult.

Usually you should set the handshake when you receive the byte and find too 
little space left, i.e. in the IRQ/NMI. After all this is the place where it 
fills up.

To make it faster, you only need to _stop_ the PC sending in the NMI. Make the 
PC start again you can do in the normal routine that reads from the buffer. 
Reading from the buffer is the only place where you free some space in the 
buffer, and can thus decide to let the PC send again. 

(Note: make sure your code does not have any race condition, like setting the 
handshake line from NMI and at the same time resetting from IRQ, as this could 
lead to bad results. Usually only change the handshake line when 
freespace(buffer) < LOWWATER in the NMI, and when freespace(buffer) > 
HIGHWATER in the read routine, where LOWWATER < HIGHWATER.)

Hope this helps (sorry it's late here)

André



> 
> Ed
> 
> 
> On 29 July 2018 at 17:06, Thom Cherryhomes <thom.cherryhomes@gmail.com>
> 
> wrote:
> > Yes, I am currently doing this in the main-line code, checking the size of
> > the ring buffer, and if it passes a given threshold, it asserts bit 1 of
> > $DD01, continues to process the now draining buffer, and toggles the line
> > when it's ready for more data...
> > 
> > This has worked, up until yesterday, when it's now clear that I am
> > spending too much time plotting text (that's a whole other matter), and I
> > am trying to get back that reliability while I try to either find help to
> > get the text routines fixed, OR ultimately work them out myself...but now
> > I
> > am wondering if moving the buffer check and the handshaking into the NMI
> > handler for the bit banging serial driver will give me the temporary
> > stability I need to make this work?
> > 
> > -Thom
> > 
> > On Sun, Jul 29, 2018 at 11:00 AM Ed Spittles <ed.spittles@gmail.com>
> > 
> > wrote:
> >> 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.