Re: [M100] mComm 1.5

[John R. Hogerhuis]

On Monday, October 17, 2016, Kurt McCullum  wrote:

> 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.
>
> Kurt
>
>
>
Well android is Linux so that figures.

A serial port is byte by byte transfer. But unix treats port as a buffered
stream where data is read/written in chunks. So I suspect the low level
receive buffering and the xoff is not processed soon enough to stop
transmission before the m100's 64 byte buffer fills up.

Maybe if the high water mark were tunable to a lower value or the rx buffer
was bigger.

Or serious surgery on the Linux serial port driver :-).

I think your approach of making small writes or per char delays is probably
the only way to go with Linux short of the hardware flow control I did in
HTERM. Which of course doesn't do anything for BASIC or TEXT serial I/O.

I had to do something similar in TBACK with per character delays.

-- John.

Re: [M100] mComm 1.5

[Daryl Tester]

On Mon, 17 Oct 2016 15:28:45 -0700, John R. Hogerhuis wrote:


Well android is Linux so that figures.


The problem with the Linux driver is that it follows the standard Unix
driver (which is not typical for Linux, but here we are).  Software 
flow

control schedules a software interrupt, which can have considerable
latency before it is processed (typically 100HZ?).  Hardware flow 
control

is handled by the UART (or UART like device), so it gets processed
immediately, which is why it's so much more effective.


Or serious surgery on the Linux serial port driver :-).


I had this issue when doing 9 bit serial I/O (needed for comms with
certain equipment) on FreeBSD.  The 9 bit hack for traditional UARTs is
done by manipulating parity generation with each byte write to get the
desired state for the 9th bit, but because parity generation was
"scheduled" in the top half of the drivers the configuration changes
were being delivered in bursts, rather than with each character sent.
I ended up having to hack the driver to get it to do what I want.

Cheers.

--
Regards,
  Daryl Tester
  Handcrafted Computers Pty. Ltd.

Re: [M100] TRS-80 Model 102 Newbie...

[Steve Batson]

Is there any known issues with this list? Some of my messages are getting 
through and therefore sent to me as well as the group. Some I’m not getting 
back or seeing responses even though I can see my messages showing up in the 
List Archive on the site.

> On Oct 12, 2016, at 11:17 PM, James Zeun  wrote:
> 
> The more people the merrier. I'm not a developer but more of a general user. 
> Combined with mcomm. My M100 is a great machine for writing my blogs. And the 
> odd game isn't bad either.
> 
> James
> 
> 
> On 13 Oct 2016 12:14 a.m., "Steve Batson"  > wrote:
> Thanks for the welcome everyone. I’ll post some info about what I’m doing 
> with it so far and some questions soon.
> 
> Steve
> 

Re: [M100] mComm 1.5

[Daryl Tester]

On Mon, 17 Oct 2016 17:11:28 -0700, John R. Hogerhuis wrote:


Interesting.  Might have a use for that, I do some work with vending
machines. The MDB bus used for communication with payment device has 
9 bit

data.


Yeah, that looks like the same protocol (not identified as such with 
the
kit I was working with) - 9th bit set on address, reset on the data 
bytes.

For an uncommon protocol, it pops up quite a lot.

--
Regards,
  Daryl Tester
  Handcrafted Computers Pty. Ltd.

Re: [M100] mComm 1.5

[Mike Stein]

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.

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


  Kurt




  On Monday, October 17, 2016 2:16 PM, Mike Stein  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.

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

Re: [M100] mComm 1.5

[Kurt McCullum]

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


 

On Monday, October 17, 2016 11:36 AM, John R. Hogerhuis  
wrote:
 

 

On Mon, Oct 17, 2016 at 7:14 AM, Kurt McCullum  wrote:

Even though the buffer is 256 bytes in size, TELCOM sends the XON/XOFF commands 
when the buffer is only slightly full, so I have had to block the sending of 
the data in small packets and check for XOFF.



The serial receive buffer is 64 bytes.
-- John. 

   

Re: [M100] mComm 1.5

[Mike Stein]

AFAIK 64 is the global limit for all COM receives; XOFF is sent at 40 
characters which is easily overrun, especially with a long turn-around time and 
receiving a packet.

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


  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.


  Kurt








  On Monday, October 17, 2016 11:36 AM, John R. Hogerhuis  
wrote:








  On Mon, Oct 17, 2016 at 7:14 AM, Kurt McCullum  wrote:

Even though the buffer is 256 bytes in size, TELCOM sends the XON/XOFF 
commands when the buffer is only slightly full, so I have had to block the 
sending of the data in small packets and check for XOFF.






  The serial receive buffer is 64 bytes.


  -- John. 

Re: [M100] mComm 1.5

[Mike Stein]

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