Re: [M100] mComm 1.5

2016-10-17 Thread John R. Hogerhuis
On Monday, October 17, 2016, Daryl Tester < dt-m...@handcraftedcomputers.com.au> wrote: > > 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

Re: [M100] mComm 1.5

2016-10-17 Thread Kurt McCullum
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

Re: [M100] mComm 1.5

2016-10-17 Thread 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

Re: [M100] mComm 1.5

2016-10-17 Thread 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

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

2016-10-17 Thread 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

Re: [M100] mComm 1.5

2016-10-17 Thread 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

Re: [M100] mComm 1.5

2016-10-17 Thread 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,

Re: [M100] mComm 1.5

2016-10-17 Thread 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

Re: [M100] mComm 1.5

2016-10-17 Thread John R. Hogerhuis
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

Re: [M100] mComm 1.5

2016-10-17 Thread 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

Re: [M100] mComm 1.5

2016-10-17 Thread 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 -