pnelson@antares.UUCP (Phil Nelson) (02/08/89)
Well, I still think Marco writes a good Comm program, but I have found
a "feature" (not a bug exactly, but it sure bit like one). The problem has
to do with how you deal with the receipt of a stray x-off (control-s)
character. I found out (when I received a stray x-off) that your program
ceases output. Now I know that this is what it is supposed to do, and some
other programs do the same, but consider; if I never receive the x-on, I
can never send any data again. In fact, I could not even exit the program,
I had to re-boot the Amiga. Naturally, all this occurred at a very bad time,
so I simply went through my terminal program collection until I found one
that worked (well, to be fair, one that didn't have this feature), vt100.
I would like to take this opportunity to thank Dave Wecker and Tony Sumrall
for a very useful program. I also tried the Gizmoz Terminal, which had the
same feature.
I realize (after dragging out the datascope to discover the cause of the
problems I was having, I didn't know it at the time) that I can simply
disable the X-on - X-off, but I normally run with it enabled, for those
cases where I wish to upload files straight (without protocol). I can think
of three other ways to handle this;
1. Ignore the receipt of X-off when data is coming from the keyboard (I think
this is what vt100 does, it's also the way I did it when I wrote a comm
program once).
2. Timeout - MSKermit does something like this (I encountered the same
embedded X-Off at work, running MSKermit (also a very useful program,
for those of us who have to use ..shudder.. clones :-). MSKermit handled
the same situation by considering the matter for about 10 seconds after
I started typing, then, finally, sending the character. I wasn't really
pleased with this, but it did let me continue working.
3. Alert the user, and provide some means of override - I haven't seen this,
but it seems like a reasonable compromise for those who do not want to
ignore the X-off under any circumstances. As I see it, if the program is
not going to send my characters (it's normal function), it should tell
me, at least.
So, I am still using A-Talk III, except for this one problem it has served
very well, but I keep vt100 around for emergencies.
--
Phil Nelson at (but not speaking for) OnTyme:NSC.P/Nelson
Tymnet, McDonnell Douglas Network Systems Company Voice:408-922-7508
UUCP:{pyramid|ames}oliveb!tymix!pnelson LRV:Component Station
"ding ding..." -Santa Clara County Transit Company trolley car (AKA "LRV")msl5864%ritcv@cs.rit.edu (02/24/89)
In article <382@antares.UUCP> pnelson@antares.UUCP (Phil Nelson) writes: > > Well, I still think Marco writes a good Comm program, but I have found >a "feature" (not a bug exactly, but it sure bit like one). The problem has >to do with how you deal with the receipt of a stray x-off (control-s) >character. I found out (when I received a stray x-off) that your program >ceases output. What's wrong with that? >... Now I know that this is what it is supposed to do, and some >other programs do the same, but consider; if I never receive the x-on, I >can never send any data again. In fact, I could not even exit the program, Programs should have a "clear comm" type feature. That is why DEC put Clear Comm in their set-up menus. >I had to re-boot the Amiga. Naturally, all this occurred at a very bad time, >so I simply went through my terminal program collection until I found one >that worked (well, to be fair, one that didn't have this feature), vt100. Actually, VT100 disables flow control when sending characters. That sucks because it won't recognize xoff's while your typing. This happens a lot at high baud rates. VT100 will freeze and the machine must be rebooted. >I would like to take this opportunity to thank Dave Wecker and Tony Sumrall >for a very useful program. I also tried the Gizmoz Terminal, which had the >same feature. > > I realize (after dragging out the datascope to discover the cause of the >problems I was having, I didn't know it at the time) that I can simply >disable the X-on - X-off, but I normally run with it enabled, for those >cases where I wish to upload files straight (without protocol). I can think >of three other ways to handle this; > >1. Ignore the receipt of X-off when data is coming from the keyboard (I think > this is what vt100 does, it's also the way I did it when I wrote a comm > program once). > yech. Kludge. >2. Timeout - MSKermit does something like this (I encountered the same > embedded X-Off at work, running MSKermit (also a very useful program, > for those of us who have to use ..shudder.. clones :-). MSKermit handled > the same situation by considering the matter for about 10 seconds after > I started typing, then, finally, sending the character. I wasn't really > pleased with this, but it did let me continue working. > yech. Kludge. >3. Alert the user, and provide some means of override - I haven't seen this, > but it seems like a reasonable compromise for those who do not want to > ignore the X-off under any circumstances. As I see it, if the program is > not going to send my characters (it's normal function), it should tell > me, at least. > yech. Kludge. > >So, I am still using A-Talk III, except for this one problem it has served >very well, but I keep vt100 around for emergencies. >-- >Phil Nelson at (but not speaking for) OnTyme:NSC.P/Nelson >Tymnet, McDonnell Douglas Network Systems Company Voice:408-922-7508 >UUCP:{pyramid|ames}oliveb!tymix!pnelson LRV:Component Station >"ding ding..." -Santa Clara County Transit Company trolley car (AKA "LRV") I would do it this way: I would get on commodores back to have them fix all of the bugs in the serial driver. The applications program is never informed when an Xoff is sent or received. There is supposed to be a bit that shows the xoff/xon state, but it never changes. When that bit works, there are two approaches. One, if the input came from a human, throw the character away and beep the bell or blink the screen. Two, if the input is from another program or file xfer, send the unsent characters in the string back to the calling program and let the caller decide what to do. Meshugena 2.0 has the following communications menu: ----------------------------------- | Communications +---------------------+--------- | Stop Communications | | Start Comm (go) | | ------------------- | | ,/ Flow control on | | Flow control off | +---------------------+ Michael S. Leibow UUCP: rochester!ritcv!msl5864 BITNET: MSL5864@RITVAX
jms@antares.UUCP (Joe Smith) (02/26/89)
In article <952@cs.rit.edu: msl5864%ritcv@cs.rit.edu (Michael S. Leibow) writes: :In article <382@antares.UUCP: pnelson@antares.UUCP (Phil Nelson) writes: :: Well, I still think Marco writes a good Comm program, but I have found ::a "feature" (not a bug exactly, but it sure bit like one). The problem has ::to do with how you deal with the receipt of a stray x-off (control-s) ::character. I found out (when I received a stray x-off) that your program ::ceases output. : : What's wrong with that? The problem Phil mentions occurs when line noise looks like an XOFF and your keyboard goes dead for no apparent reason. At least the real VT100 terminal made it so you could do something about it. It would turn on the KEYBOARD LOCKED light so you could detect the problems, and you could cancel the "I saw an XOFF" flag by simply hitting the SETUP key twice. It sounds like A-Talk does not have a well documented equivalent of this function. -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"