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!daveron@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!pedz