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. 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. >>> >>> >>Received on 2018-07-29 19:01:33
Archive generated by hypermail 2.2.0.