nathan@mit-eddie.UUCP (06/15/87)
In article <1166@osiris.UUCP> jdia@osiris.UUCP (Josh Diamond) writes: >Worst problem ever seen: > At an unnamed computer center there are several microterm terminals >(vt100/vt220 compatible), and several DEC-GiGi's. Obviously everyone >prefers to use the microterms. So one day I go there to do some work, >and I discover that all of the microterms are in use. So I go to a >gigi. I start up emacs, and discover that every time the screen is >rewritten, emacs decides it wants to search! Why? because the GiGi's are >so inept that they can't really hand 9600 baud (after all, their >terminal logic is written in inerpretive basic!!). So, they tell unix >to stop sending data so they can catch up, using ^S/^Q. But emacs >interprets this as a search. &%$%*^$*&)^^%&-up eh? I've had very similar problems repeatedly when using an h19 (in h19 mode). When ever certain screens were displayed, emacs would begin to start searching for what seemed like random strings of control characters and beeping repeatedly. I would often have to hit ^G 4 or 5 times before it would stop. And of course the screen was not drawn properly, so I have to redraw it...and often the same thing would happen again. I had decided that the problem might be that the h19 couldn't really handle 9600 baud (as described above for the gigi), since it would explain most of the behavior I experienced, but it seemed a little too far fetched. Since I thought h19's are/were fairly widely used, and regarded along with others like vt100's as a standard terminal type, I would expect it not to have such problems. Does anybody know whether this is indeed true of h19's? -- Nathan Glasser nathan@mit-eddie.uucp (usenet) fnord nathan@xx.lcs.mit.edu (arpa) "A tribble is the only love that money can buy."
rwa@auvax.UUCP (Ross Alexander) (06/16/87)
In article <6090@eddie.MIT.EDU>, nathan@eddie.MIT.EDU (Nathan Glasser) writes: > I had decided that the problem might be that the h19 couldn't really > handle 9600 baud (as described above for the gigi), since it would > explain most of the behavior I experienced, but it seemed a little too > far fetched. Since I thought h19's are/were fairly widely used, and > regarded along with others like vt100's as a standard terminal type, I > would expect it not to have such problems. > > Does anybody know whether this is indeed true of h19's? yes, it is indeed true. the h19 firmware is, to put it tersely, sh*t. OK, that's a little strong - apologies to JGL (or whoever; I don't have my source listings handy :-). But the truth is that the ROM's are clunky, to say the least. They treat the z80 as though it was an 8080, for a start. there are two fixes. one is hardware; it is relatively simple to speed up the clock on the z80 to 3 MHz and thereby pick up some speed. i never had any trouble with this on my h19 (part of my h89, actually). the other is to chuck the stock ROM's and replace them with something a little closer to good code. i borrowed a ROM from someone once that sped things up quite a bit and also did pretty fair vt100 emulation (sans 132 column, of course) but i can't remember the vendors name. i will dig around a bit at home and see what i can come up with. btw, heath/zenith will sell you a listing of the ROM. it is well commented and very complete (i know 'cause i typed it in and assembled it, and then hacked it up for my own use). ...!ihnp4!alberta!auvax!rwa Ross Alexander, Athabasca University
dave@astra.necisa.oz (Dave Horsfall) (06/24/87)
It occurs to me that if EMACS uses ^S (a character universally accepted
to mean STOP SENDING ME CHARACTERS!) as a command, then perhaps EMACS
is just ever so slightly brain damaged. Why shouldn't the terminal
(or the user for that matter) send ^S if it wants to? What do you
think the NO-SCROLL key does?
Yes - I have heard of hardware handshaking. I've also seen far too
many combinations of pins for my liking. Besides, hardware handshake
over a modem line is not the best.
Why did EMACS choose to redefine ^S anyway?
--
Dave Horsfall (VK2KFU) TEL: +61 2 438-3544 FAX: +61 2 439-7036
NEC Information Systems Aust. ACS: dave@astra.necisa.oz (also CSNET)
3rd Floor, 99 Nicholson St ARPA: dave%astra.necisa.oz@seismo.css.gov
St. Leonards NSW 2064 UUCP: {enea,hplabs,mcvax,prlb2,seismo,ukc}!\
AUSTRALIA munnari!astra.necisa.oz!daveKarl.Kleinpaste@cbstr1.att.com (06/26/87)
Posting-Front-End: GNU Emacs 18.47.3 of Sat Jun 20 1987 on cbstr1 (usg-unix-v)
dave@astra.necisa.oz writes:
It occurs to me that if EMACS uses ^S (a character universally accepted
to mean STOP SENDING ME CHARACTERS!) as a command, then perhaps EMACS
is just ever so slightly brain damaged. Why shouldn't the terminal
(or the user for that matter) send ^S if it wants to? What do you
think the NO-SCROLL key does?
[a] ^S is *not* universally accepted as a stop-send command. I never
use it as such. Many people I know avoid it completely. My stty
options disable it entirely. I use terminals on which I can stop
output by other means (notably, mouse-menu commands), or I pipe
massive amounts of output through a suitable pager (more or pg).
[b] The set of terminals with a no-scroll key is not all that large.
The one vt102 I use regularly is set so that the no-scroll key is a
no-op.
[c] The terminal shouldn't send ^S/^Q as flow control because there's
positively no reason for designing a terminal incapable of keeping up
at high baud rates.
Why did EMACS choose to redefine ^S anyway?
It is arguable that Emacs didn't choose to "redefine" it, but rather
that the conventions regarding ^S-as-search and ^S-as-stop developed
at similar times in different places.
Karlron@topaz.rutgers.edu (Ron Natalie) (06/27/87)
It was never an issue before VT100's came out. EMACS predates this by quite a bit. XON and XOFF were easily ignored as signals except when you were doing interesting things like downloads which you didn't use EMACS for. I'm always amazed. I always figured NUL was a bigger problem. Some terminals/systems just don't send or pass NUL, or it means something atrocious like END-OF-FILE. -Ron
ken@argus.UUCP (Kenneth Ng) (06/30/87)
In article <12964@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > I always figured NUL was a bigger problem. > Some terminals/systems just don't send or pass NUL, or it means something > atrocious like END-OF-FILE. On some systems the 'DEL' character is even more of a problem. Some of the older computer systems send 'DEL' characters to compensate for the slow teletype style printers used as terminals. The original meaning of DEL dates back to the teletype baudat days when it meant: 'ignore this character'. Unfortunately some VT100 styled machines took it to mean 'delete character'. ... This signature was put in in a way to bypass the ... bogus artificial line limit on the .signature file. ... Also, by its length it adds fodder to help avoid having ... my followups being bounced due to the restriction on ... followup articles. Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ken@bellcore.uucp *** bitnet(prefered) ken@orion.bitnet > > -Ron
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/30/87)
In article <931@argus.UUCP> ken@argus.UUCP (Kenneth Ng) writes (re. DEL character): >Unfortunately some VT100 styled machines >took it to mean 'delete character'. ? The DEC VT100 ignores received ASCI DEL characters. I take this opportunity to point out that it is INCORRECT to transmit padding characters to a terminal if the termcap/terminfo entry does not indicate that padding is needed and supported. In particular an ASCII NUL character is not always ignored by all terminals (I have mine set up to display it, so I can spot bugs in programs that output erroneous characters).
ken@argus.UUCP (Kenneth Ng) (07/01/87)
In article <6042@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <931@argus.UUCP> ken@argus.UUCP (Kenneth Ng) writes (re. DEL character): > >Unfortunately some VT100 styled machines > >took it to mean 'delete character'. > ? The DEC VT100 ignores received ASCI DEL characters. > I take this opportunity to point out that it is INCORRECT to transmit padding > characters to a terminal if the termcap/terminfo entry does not indicate that > padding is needed and supported. Interesting, so when you type the 'DEL' key on a VT100 the computer translates it into a sequence of characters to delete the previous key? The example I took was from two rather old computer systems (EIES and a Univac 90/80) that did not understand the concept of something similar to a termcap system, they were designed for TTY43 style machines. Univac in particular had *NO* known way to turn off the DEL padding characters unless you went to a special write mode which could write out several lines at a time. But even that transmitted DEL characters when the record was complete. I agree that it is incorrect to send any characters that are not indicated to be needed, but people should be aware of problems of some of the older systems. Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ken@bellcore.uucp *** bitnet(prefered) ken@orioal f> <2<
pedz@bobkat.UUCP (Pedz Thing) (07/01/87)
One problem that no one has pointed out is that the EIA-232-D
definition does not have any hardware flow control defined. The use
of request-to-send, clear-to-send for flow control from the computer
to the modem is mentioned although using for this puspose would not
violate the standard. The flow control from the modem to the computer
is not specified at all. Not to mention that flow control from one
computer to another (like a terminal) is totally out of the scope of
the specification.
There are customary ways to do hardware flow control although DEC has
a great tendency to ignore this. In fact, all of DEC's equipment is
completely backwards and frequently does not have any capability to do
hardware flow control at all. I guess that is to be expected.
--
Cute signature line employing many literary allusions and puns.
Standard disclaimer concerning my mental incompetance.
Perry Smith a.k.a. (Pedz Thing)
pedz@bobkat or {ti-csl,infotel}!pollux!bobkat!pedzjr@LF-SERVER-2.BBN.COM (John Robinson) (07/06/87)
>> One problem that no one has pointed out is that the EIA-232-D >> definition does not have any hardware flow control defined. I don't know about 232D (which is less than a year), but 232C does talk about half-duplex operation, as I remember. Here it is mandatory to watch the request-to-send/clear-to-send protocol, so that the two modems can coordinate their sending and receiving. The modems, for their part, have to turn their carriers on and off in response to what the computers/terminals do. Hardware flow-control can be based loosely on this model (Await CTS when you want to send; don't assert DTR [or else RTS] when you don't want to receive). Most UART chips can be wired so that they won't send unless they see CTS, providing the send direction automatically. When it works, hardware flow control is nice. It is faster (the terminal has to do some work to throw away all that padding - in fact, the VT101 works so hard that NO amount of padding is enough at 9600 baud) and it is not affected by termianl modes - it just keeps going even in raw mode. However, because they associate the control leads with half-duplex, most modems can't pass their value transparently to the other end, so hardware flow-control won't work over modems. I wonder if anyone has ever made an intensely interactive application like emacs work over a half-duplex line! /jr jr@bbn.com or jr@bbnccv.uucp Without life, there wouldn't be chemical companies.
dplatt@teknowledge-vaxc.ARPA (Dave Platt) (07/06/87)
Posting-Front-End: GNU Emacs 18.41.3 of Tue Apr 7 1987 on teknowledge-vaxc (berkeley-unix) In article ucbvax.8707061522.AA07395, John Robinson wrote: > Hardware flow-control can be based > loosely on this model (Await CTS when you want to send; don't assert > DTR [or else RTS] when you don't want to receive). Urrch! It's probably not a good idea to use DTR for flow-control purposes. Most terminals assert DTR to indicate "I'm powered up and alive"; similarly, most modems look at DTR to see whether the terminal is alive. The standard option-set (or jumper strapping) installed in most asynchronous modems on the market today will cause a modem to drop its transmit carrier and go on-hook (hang up) if DTR is deasserted for more than a very short amount of time (milliseconds, in some cases). Similarly, terminals connected to a host over a hardwired line often wire the DTR signal through to the host as a "terminal is alive" feature (it's connected to the host's Carrier Detect input pin), so that if a terminal is switched off or unplugged the connection will be "hung up". This is an excellent security feature, as it ensures that a timesharing/TP session will be terminated if its controlling terminal is powered off. It's unfortunate, but the standard asynchronous version of RS-232, and the 103/212/V.22 asynchronous modem protocols don't provide a standard end-to-end out-of-band flow control mechanism. The existing send/don't-send mechanism (RTS/CTS) operates only between a DTE (terminal) and its corresponding DCE (modem); there's no way for the equipment at the other end of the conversation to control it. I have seen some systems that have extended (or subverted) the RS-232 interface to provide additional flow-control capability, typically by using one of the optional RS-232 pins (e.g. external clock input / handshake) for a different purpose. These extensions work only on hardwired terminal-to-host connections; if you introduce a full-duplex modem protocol between the host and the terminal, the additional signals aren't carried through. A real solution to this problem would probably require a slight extension to RS-232. It would probably require two additional pin assignments: one output pin to say "please stop sending", and one input pin to receive the "stop sending" signal from the person at the other end of the wire. Extensions to the modem protocols would also be required... perhaps a pair of frequencies at the lower end of the voiceband could be assigned (in the 103/113/212 families). I really doubt that this set of extensions will occur.
jr@LF-SERVER-2.BBN.COM.UUCP (07/07/87)
>> Urrch! It's probably not a good idea to use DTR for flow-control >> purposes. Most terminals assert DTR to indicate "I'm powered up and >> alive"; similarly, most modems look at DTR to see whether the >> terminal is alive. Oh I know that. But terminals that do hardware flow-control at all have to use some signals (and avoid modems!). I think my message indicated that this is all no help over modems since they only interpret the control signals locally. >> It would probably require two additional pin >> assignments: one output pin to say "please stop sending", and one >> input pin to receive the "stop sending" signal from the person at the >> other end of the wire. This is all well and good, but now you have to worry about the delay imposed by the modem link. It may use a satellite hop or a slow microwave repeater. The "out-of-band" signal may have a very low baud rate. Most terminals only have a few characters of buffer left when they say stop. >> I really doubt that this set of extensions will occur. Agreed. Better to use a real communications protocol based on packets, like say X.25. Or even Kermit. Not likely to appear in a termial near you soon, but at least PCs generally can all do this sort of thing now. /jr
daveb@geac.UUCP (Dave Brown) (07/09/87)
In article <8707071528.AA02320@ucbvax.Berkeley.EDU> jr@LF-SERVER-2.BBN.COM (John Robinson) writes: >Agreed. Better to use a real communications protocol based on >packets, like say X.25. Or even Kermit. Not likely to appear in a >terminal near you soon, but at least PCs generally can all do this sort >of thing now. /jr They may not be appearing in terminals, but X.PC and MNP are certainly appearing in *modems*: I have two friends who make their living writing packet protocols that run in about 2.5 sq in of board space inside several modems. And TYMNET has a X.PC to X.25 gateway facility (down thar in the excited states (:-)), so one can Emac away happily 1200 miles from one's host with minimal flow-control and delay problems. [cf my earlier rant about negotiated echo on x.25] -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
ron@topaz.rutgers.edu (Ron Natalie) (07/21/87)
A quick summary of RS-232C
The world is divided into DTE and DCE. DTE is data terminal equipment,
sometimes referred to as the business machine. This includes what we
refer to as terminals as well as the computers. DTE's SHOULD have male
DB-25's on them. DCE is the communications network end. Modems fall into
this category. DCE should correspondingly have the female DB-25 connector.
Here are the popular signals. Note the letters DCE or DTE indicate whether
the signal is sourced from the communications equipment or terminal equipment
respectively:
DSR (Data Set Ready)-DCE- I am up and running and ready to place/receive
calls. Should remain on whenever the DCE is on and happy.
DTR (Data Terminal Ready) -DTE- I am ready to receive calls. While many
people use this to indicate that they are ready and assert it all the time
when they are up (which is legal), a terminal is allowed to wait until
the RI line comes up before raising DTR. Once raised, it should never
be lowered unless you wish to sever the connection.
RI (Ring Indicator) -DCE- The phone is ringing, there is a call pending...
CD (Carrier Detect), also refered to as RLSD (Recieve Line Signal Detect?)
-DCE-
I have detected a valid signal from the remote modem.
RTS (Request to Send) -DTE- Generally ignored in the full-duplex world,
but this is asserted when the terminal wants to send data to the DCE.
In the half-duplex or multi-drop environment, the DCE must prepare
itself to send the data.
CTS (Clear to Send) -DCE- Answer to RTS. Terminal may send it's data
now.
and just for completeness
TD (Transmit Data) -DTE- Data from terminal TO DCE
RD (Recieve Data) -DCE- Data to DTE from DCE
Note, that RS-232C has NO FLOW CONTROL. Let me say this again. THERE IS NO
FLOW CONTROL. RS-232C describes the interconnection of a terminal with a
modem. Some signals like TRANSMIT and RECEIVE DATA are passed through to the
other side. Other signals may be affected by actions on the other side, but
they are indications from the modem to the terminal specifically. RTS and
CTS are properties of the transmission of DATA to the MODEM, these signals
go no farther than the modem. The same for DTR, DSR, CD, and RI. If you
are using RS-232, flow control needs to be done in the data stream.
-Ronrbj@ICST-CMR.ARPA (Root Boy Jim) (07/23/87)
? A quick summary of RS-232C And a good one at that. Now allow me to dream a bit... First, I believe that all pieces of equipment should have female plugs and that all cables should have male plugs. The rationale is that if the pins break, you can replace the cable easier than the equipment. Second, I would like to see a universal reversible plug. The thing would have an odd number of pins. Ground would be in the center, all the control (outbound) pins would be on the left side, and all the status (inbound) pins would be on the right side. Actually, they wouldn't be pins (because then there would have to be holes), but nore like overlapping fingers. To make a null modem cable, one would mere put a half twist in the cable before connecting it. The cable might look like: ------------------------------------- GREEN | TD RTS DTR XON GND XIN DSR CTS RD | RED ------------------------------------- The connectors and jacks would be colored (or marked) on each side so that even an idiot could connect them correctly. Several problems remain. First, I may have to give up a universal connector, as topology may not support reversibility. The latter is more important. Second, I left out RI and CD. What are their corrresponding signals (or rather, what would they be if they existed)? Are they really necessary for full duplex? The two extra signals XON and XIN are for flow control. The former I don't know how one modem would tell another modem to assert it's XON when it sees XIN, but that's a hardware detail. They may not even be necessary if RTS and CTS were handled this way. Lastly, it'll never get done. All we need is another standard. Right! ? Note, that RS-232C has NO FLOW CONTROL. Let me say this again. THERE IS NO ? FLOW CONTROL. RS-232C describes the interconnection of a terminal with a ? modem. Some signals like TRANSMIT and RECEIVE DATA are passed through to the ? other side. Other signals may be affected by actions on the other side, but ? they are indications from the modem to the terminal specifically. RTS and ? CTS are properties of the transmission of DATA to the MODEM, these signals ? go no farther than the modem. The same for DTR, DSR, CD, and RI. If you ? are using RS-232, flow control needs to be done in the data stream. Of course, if you use a null modem cable, you can do hardware flow control. And of course, you can also use the wrong signals as we already know. ? -Ron ? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 .. are the STEWED PRUNES still in the HAIR DRYER?
drw@cullvax.UUCP (Dale Worley) (07/24/87)
ron@topaz.rutgers.edu (Ron Natalie) writes: > A quick summary of RS-232C > > The world is divided into DTE and DCE. DTE is data terminal equipment, > sometimes referred to as the business machine. This includes what we > refer to as terminals as well as the computers. DTE's SHOULD have male > DB-25's on them. DCE is the communications network end. Modems fall into > this category. DCE should correspondingly have the female DB-25 connector. Also, beware of male vs. female DB-25 connectors. I was once confused reading a supply catalog until I figured out that a genuing "male" DB-25 *does* *not* have pins in it! The one with pins is "female". Apparently, it's not the gender of the little pins that counts, but rather the gender of the outermost metal shell around the insulator that separates all the bins/sockets. On a "male", the outermost metal shell is recessed relative to the insulator. Or am I totally confused? Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw From the Temple of St. Cathode of Vidicon:
goldfain@osiris.cso.uiuc.edu (07/28/87)
Dale:
I think you have that wrong. The ones with pins coming out are called
male DB-25s around here, even though the pins do not extend out beyond the
outer shielding.