ah, ok. The Keyboard buffer is a convenient free-to-use memory buffer. That's where a number of programs build commands and ready data from TPDD.
It's just a buffer location, like ALTLCD. Yah, it would be possible to write to a larger buffer, and thereby enable large packets. On Mon, Apr 20, 2020 at 4:42 PM John R. Hogerhuis <[email protected]> wrote: > > > On Mon, Apr 20, 2020 at 1:24 PM Stephen Adolph <[email protected]> > wrote: > >> Interesting, but I think in my case I need to rely on small packets. >> This is because there is no time to bit-bang an interface and ALSO manage >> a circular buffer, and then move to memory. >> > > For TPPD, the request/response nature is the main flow control. You don't > request another packet until you're done handling the current one, so you > can't get overrun. > > Doesn't seem like packet size should matter. > > You are bitbanging at a fast rate. Basically either you can keep up or you > can't. SInce it's working, you're keeping up. > > How big the packets should be is more a function of how much space you > want to reserve for a receive buffer. > > >> I'm thinking to just read in data and directly place it into the Keyboard >> buffer. Once the packet is read - pause and process the Rx data. Ready >> to send another command then. >> >> > You lost me on the keyboard stuff. I'm missing part of the picture. Is it > necessary to be doing keyboard/video I/O during file transfer? > > It would be cool to do so of course. > > -- John. >
