Looks like John beat me to it ;-)
Steve played with expanding the buffer a long time ago while we were playing
with the M100-on-the-Internet but never got it working 100% reliably, so we
ended up handling XON/XOFF in the bridge hard/software instead which could
respond instantly.
m
----- Original Message -----
From: John R. Hogerhuis
To: Model 100 Discussion
Sent: Monday, October 17, 2016 5:05 PM
Subject: Re: [M100] mComm 1.5
On Mon, Oct 17, 2016 at 1:11 PM, Kurt McCullum <kurt.mccul...@att.net> wrote:
John, Thanks for info. Is that a TELCOM limit? The reason I ask is because
when running virtual T with TS-DOS, I notice that the buffer can go to 255. Or
at least the byte which holds the buffer size.
In my experience I've found that all 8-bit bytes go to 2^8 - 1 = 255
Just teasing :-) It could but it should never in practice have a value > 64.
Have you observed a higher value than 64?
It's not a limitation of TELCOM per se, it's a limitation of the receive
interrupt handler logic and the size of the circular queue-on-array reserved
for receiving bytes. The same receive handler is used for TELCOM and BASIC
access to the serial port.
See http://www.club100.org/ftp/m100-hiddenpowers-3.pdf
Page 186
It shows a receive buffer of 64 bytes. If it went beyond the bounds,
unmasked, I would expect it to corrupt other data structures.
The high-water mark for the buffer is 40 (the point at which the receive
handler sends XOFF), which probably makes more sense in the context of a 64
byte buffer than a 255 byte buffer :-)
-- John.
