When I used the M100 on the 'net I set the bridge to send  1 byte packets to 
the M100, although a larger number like 8 would probably have worked as well 
since there are 24 bytes available.

  ----- Original Message ----- 
  From: Kurt McCullum 
  To: Model 100 Discussion 
  Sent: Monday, October 17, 2016 6:12 PM
  Subject: Re: [M100] mComm 1.5

  The only time I've seen it go over 64 was when stepping through the T-Word 
code and watching the buffer byte while sending a track (128 bytes + header) 
from sardine.But I may have been watching the wrong byte in memory.

  As far as the 64 byte limit, I had a heck of a time getting that to work 
properly with the Android device. With Windows, the XON/XOFF works pretty well. 
I ended up sending 8 byte chunks and then checking for a flow control byte. A 
pain, but I think I have the timing right.


  On Monday, October 17, 2016 2:16 PM, Mike Stein <mhs.st...@gmail.com> wrote:

  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.

    ----- 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> 

      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.

Reply via email to