Re: [M100] mComm 1.5
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 <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. 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.
Re: [M100] mComm 1.5
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
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] mComm 1.5
On Monday, October 17, 2016, Kurt McCullumwrote: > 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
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.
Re: [M100] mComm 1.5
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 <jho...@pobox.com> wrote: On Mon, Oct 17, 2016 at 7:14 AM, Kurt McCullum <kurt.mccul...@att.net> 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
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. Hogerhuiswrote: 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
Cool! On Oct 14, 2016 5:32 PM, "Kurt McCullum"wrote: > Just a heads up to any who are interested. A new version of mComm for > Android devices is in the final testing stages. This version adds a virtual > modem. That means you can go to TELCOM and ‘Dial’ a telnet bbs with ATDT > URL:PORT. I just need to kick the tires a bit more, write up some > documentation, and then I’ll release it. > > > > Kurt >
[M100] mComm 1.5
Just a heads up to any who are interested. A new version of mComm for Android devices is in the final testing stages. This version adds a virtual modem. That means you can go to TELCOM and 'Dial' a telnet bbs with ATDT URL:PORT. I just need to kick the tires a bit more, write up some documentation, and then I'll release it. Kurt