ordy@cwruecmp.UUCP (Greg Ordy) (01/27/84)
We are looking to get a couple of VT100 compatible terminals so that we can use the cursor based VMS editor, as well as several other VMS programs. These terminals require the following characteristics: *) Low Cost *) are truly compatible (no little quirks) *) work with vi and emacs under Unix (full 9600 baud) *) no brain damage (i.e. 'magic cookies') Things such as green screen and detached keyboard do not matter at all. Fancy graphics does not matter either. I would like to get any opinions on what to purchase. Please mail me any information. The one terminal that looks good on paper is the Televideo 970, which can be obtained for $910. I am a bit scared of Televideo, however, as some of their other terminals (920) have the 'magic cookie' problem, as well as other brain damage. Thanks, Greg Ordy Usenet: decvax!cwruecmp!ordy CSnet: ordy@case
dan@rna.UUCP (02/02/84)
Why not VT-220's ? They are less than $1000, VT-100 compatible, although I hear they're not really VT52 compatible. Besides any DEC/VMS software you're using is likely to have to work on VT220's. Cheers, Dan Ts'o ...cmcl2!rna!dan
guy@rlgvax.UUCP (Guy Harris) (02/04/84)
> We are looking to get a couple of VT100 compatible terminals... > These terminals require the following characteristics: . . . *) no brain damage (i.e. 'magic cookies') The ANSI X3.64 standard, which the VT100 adheres to, in effect says that magic cookies do not exist; any terminal with magic cookies can't be X3.64 compatible. (Furthermore, they can't even put the magic cookie in the display memory and not show it on the screen; they *must* implement the screen image so that it appears to the program talking to the terminal as if each screen position had a character and an attribute set, and that any character put on the screen gets the "current" attributes which are set by the SGR sequence.) As such, if the TeleVideo 970 has magic cookies, it's blatantly not VT100 compatible and not even X3.64 compatible, and they would probably not sell any after they were found out. I suspect you're safe if they claim VT100 compatiblility - however, the C. Itoh CIT-101 has a non-VT100 compatible printer port, which they had *no excuse* doing since there is a spec for an auxiliary output port in X3.64. First Datamedia used it, *then* DEC put a printer port on the VT100 - but both implementations were compatible because they were both based on X3.64. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
john@genrad.UUCP (John Nelson) (02/04/84)
Why not VT220's? I'll tell you why not! THEY FORGOT THE DAMN ESCAPE KEY! You have the choice of using control-3 or control-[ (or F11 in vt100 emulation mode) They have made the stupid thing inherently unusable with vi (and other programs, no doubt!)
gregs@uo-vax1.UUCP (02/14/84)
What is the 'magic cookie' problem? ------ Greg Stewart University of Oregon hplabs!hp-pcd!uoregon!uo-vax1!gregs
mab@bnl.UUCP (Michael A. Bloom) (02/15/84)
Watch out! I've seen a number of so-called VT100 compatibles which are near useless with EMACS. A common firmware shortcut seems to be for the terminal to behave as though you pressed the SCROLL key when you have in fact pressed C-S. This is extremely frustrating to someone who likes making use of C-S and C-X C-S. The real VT100 does not present this problem. -- Michael A. Bloom ..!bnl!mab or mcb@mit-mc.arpa or mab@bnl
fair@dual.UUCP (Erik E. Fair) (02/16/84)
A magic cookie is a piece of braindamage. It is when a cursor attribute
(like `cause this set of characters to blink') takes up a space on
the screen. The TeleVideo 950 suffers from this and so do all the
fool terminals trying to emulate it. Fortunately, the smarter manufacturers
are adding an option to remove the magic cookies.
So from now on, use magic mushrooms...
Erik E. Fair
dual!fair@BERKELEY.ARPA
{ucbvax,ihnp4,cbosgd,amd70,zehntel,fortune,unisoft,onyx,its}!dual!fair
Dual Systems Corporation, Berkeley, Californiarpw3@fortune.UUCP (02/16/84)
#R:dual:-28300:fortune:5200002:000:1416
fortune!rpw3 Feb 16 00:32:00 1984
To be fair, getting rid of "magic cookies" (we call them attribute
character positions) is not free. You have to double the size of your
video RAM, since every character now has to have a full set of attribute
bits (instead of inheriting them from the nearest attribute position to
the left of it).
For the cheapest terminals, this used to make sense, since RAM was very
expensive. These days, you're talking about another 2-3 bucks for an
80 x 25 terminal (maybe $6-10 retail?). Chickenfeed. Besides, the logic
gets a little simpler with the added RAM, so the cost difference is much
closer to zero (that's why WE have attribute-per-char, at least).
The biggest gain is being able to underline (or reverse video or boldface)
within a word, which makes it possible for editors to show you on the screen
the area about to be affected by a change without breaking words at the
beginning or end of the area.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065
p.s. There goes another word that used to have a "precise" meaning,
namely, "cookie". A cookie used to be (still is around here) a token,
a handle, a file descripter, an index, something you gave back to a
caller that he/she could later use to touch a resource, a ticket.
"Cookie" did NOT mean "an ugly hack". (C.f. "hacking" vs. crime)z005@dalcs.UUCP (Neil Erskine) (02/17/84)
While on the subject of the VT100 (essentially ANSI standard) terminals, and brain damage, does anyone out there understand why the decision was made to allow individual setting of the attribute bits through the Select Graphic Renditon sequence (ESC [ Ps;...;Ps m), and did not make a provision for individually clearing them? The only way to clear an individual attribute is to clear all of them and reset those that are still desired. This might be fine for DEC type software, where generally every- one knows what is going on everywhere, but in an environment that runs through termcap, with fields for turn on attribute, turn off attribute, it is not possible to accomplish some things. The specific case that annoyed me was the my inability to cause sysline to output entirely in half intensity by placing an "enter half intensity" in the goto status line sequence, and "exit half intensity" in the leave status line sequence. The time appears in half intensity, but when it leaves a blank space to separate fields, the half intensity bit is lost. A logical magic mushroom! Is anyone out there familiar with the committee that arrived at this standard, and if so what went wrong!