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:00:04
Archive generated by hypermail 2.2.0.