wagner@uw-june (Dave Wagner) (01/29/86)
Recently some people have remarked about an annoying feature of Wyse
terminals: namely, that the escape sequences for starting and
stopping display enhancements leave an extra space on the screen.
Why can't this be worked around by simply appending a backspace to
the TERMCAP entries for se, so, ue, and uo? I hope this works, because
I just bought a Wyse 30! (I don't have my modem yet; I'll try it first
chance I get and post the results - unless someone else does it first.)
Dave Wagner
University of Washington Comp Sci Department
wagner@washington.arpa
{ihnp4,decvax,ucbvax}!uw-beaver!wagner
"Many people would rather die than think;
in fact, most do."
- Bertrand Russellfreak@nsc.UUCP (Curt Mayer) (01/31/86)
In article <312@uw-june> wagner@uw-june (Dave Wagner) writes: >Recently some people have remarked about an annoying feature of Wyse >terminals: namely, that the escape sequences for starting and >stopping display enhancements leave an extra space on the screen. >Why can't this be worked around by simply appending a backspace to >the TERMCAP entries for se, so, ue, and uo? the way the wyse and televideo terminals work is that the magic cookie is a marker. if you wipe out the marker, you lose the attribute. one way this really shows up is if you have a begin reverse marker on line 3 and an end marker on line 7. now scroll the screen 3 lines, and all of a sudden, the 4 lines which were in reverse video return to normal video. ugly. curt
ccrdave@ucdavis.UUCP (Lord Kahless @ Imperial Propoganda) (02/01/86)
> Recently some people have remarked about an annoying feature of Wyse > terminals: namely, that the escape sequences for starting and > stopping display enhancements leave an extra space on the screen. > Why can't this be worked around by simply appending a backspace to > the TERMCAP entries for se, so, ue, and uo? > wagner@washington.arpa > {ihnp4,decvax,ucbvax}!uw-beaver!wagner Believe me, it doesn't work, at least not on a 75. I tried using backspace. I tried using ^[D to move the cusor to the left. I tried everything. The screen would freak out horribly. I also tried to get around this on the Televideo mode of a Wyse 50, but couldn't find a solution there either. It's a stupid feature. Magic cookies should have died along with Beehive International. {dual,lll-crg,ucbvax}!ucdavis!vega!ccrdave +-----------------------------------------------------------+ | "I've seen things you people wouldn't believe. | | Attack ships on fire off the shoulder of Orion. I watched | | C-Beams glitter in the dark near the Tannhauser Gate. All | | those moments will be lost in time, like tears in rain. | | Time to die." -- Roy Baty, Nexus6, N6MAA10816, Combat | +-----------------------------------------------------------+
jc@sdcsvax.UUCP (John Cornelius) (02/03/86)
The reason terminals have magic cookies is because the internal character size is insufficient to hold data about video attributes. Terminals without magic cookies typically have 4 or 5 extra bits in the internal character representation. Each bit indicates the state of 1 video attribute for that character only. Terminals with magic cookies may have 1 bit which indicates that the current character sets video attributes and the character contents itself gives the video attributes. Video attributes remain effective until another such character is encountered. Since there is a 1:1 mapping of data bytes (in memory) to screen position the effect of a backspace following a set attribute command is often described by the manufacturer as unknown. Magic cookies allow the manufacturer to hype a large number of video attributes and make his terminal look glitzy while keeping the terminal cheap to design and manufacture. The manufacturing cost savings are enormous, about $10.00, when compared to the total manufacturing cost of the terminal, about $140.00 to $200 for most ascii terminals. A true VT-200 emulating ANSII terminal (no magic cookie) costs $180.00 POE West Coast to bring to market. An ADM-3 look alike costs about $140.00 to bring to market under the same conditions. The $40.00 difference means about $120.00 by the time it gets to the end user. John Cornelius Western Scientific
chris@umcp-cs.UUCP (Chris Torek) (02/04/86)
In article <1374@sdcsvax.UUCP> jc@sdcsvax.UUCP writes: > ... Terminals with magic cookies may have 1 bit which indicates > that the current character sets video attributes and the character > contents itself gives the video attributes. I suspect that in most, there is no extra bit, and they use control codes; but the idea is the same. > Video attributes remain effective until another such character is > encountered. But not in all; in some, `end of line' resets the attributes (as does `end of screen' in all). This makes dealing with such attributes even more difficult than it might have been. There are a number of embedded attribute terminals that do not use up screen space for the attributes. I believe the HP 26xx series is an example (though I am uncertain that these are truly embedded attribute machines). The 262x and 264x series are rather successful; most can even keep up with 9600 baud for most purposes. Somewhat less successful is (was?) the Tektronix 4025. This machine has something called a `display tracker', which interprets `commands' for each `line'. A line starts with a cursor position code. If the code is zero (or was it > 80?), the line has no cursor; otherwise there is a cursor in the corresponding column. After that come characters and/or commands. Commands include end-of-line, jump, `nop', and `antinop'. The last three are used to implement blinking attributes: Nops are ignored on `even' frames and act as `skip next three bytes' instructions on `odd' frames; antinops do the same but for odd and even frames respectively. A jump instruction is followed by a 16 bit address from which the next set of commands is to be taken. The screen draws `even' frames for half a second, then `odd' frames for another half second, then back to even. To make characters that blink between inverse video and normal video, you embed a nop followed by a jump followed by the text. The jump directs the tracker to a `switch to inverse' command followed by another jump back to the text. All this is fine in theory. The problem is that the tracker is time constrained. It must put characters onto the screen at the screen draw rate. If you insert too many jumps, it falls behind and `gets lost' until the next end-of-line command. Putting up a large number of attributes on one line makes that line `break', usually becoming two lines (with a cursor in an odd place on the second line). Worse, if the jumps are behind a nop or antinop, the screen `bounces' every half second. This looks quite odd, to say the least. I strongly suspect that had the 4025 used 16 bits for each character, the firmware would have been less buggy too. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
mdf@osu-eddie.UUCP (Mark D. Freeman) (02/07/86)
Summary: >In article <1374@sdcsvax.UUCP> jc@sdcsvax.UUCP writes: > Video attributes remain effective until another such character is > encountered. I had to make a program of mine work on a Televideo 950, so anytime I sent some text to the screen I figured out the length of the string to be printed, then figured out where the last character would appear when it was sent to the screen. Then I sent it this way: Position cursor to column after where text ends, print <end-attribute>. Position cursor to column before where text stars, print <begin-attribute>. Print text. This was the only way to keep the whole screen from changing to underlined text while I printed one underlined word near the top of the screen. As soon as the <begin-underline> got to the screen, everything until the next <end-attribute>, or the end of the screen if there aren't any, changes to underline. Then the text prints, then the <end-attribute> is sent, and everything after the <end- attribute> that changed to underlining (as a result of the magic cookies), changes back. So the net effect is that major portions of the screen FLASH underlines, inverse, and other things while you are doing screen updates. Very ugly. My way of doing things solved the problem, but it involved rewriting all my screen output code. -- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mark D. Freeman Guest account at The Ohio State University StrongPoint Systems, Inc. mdf@osu-eddie.UUCP 209 Olentangy Street Mdf@Ohio-State.CSNET Columbus, OH 43202-2340 Mdf%Ohio-State@CSNET-RELAY.ARPA !cbosgd!osu-eddie!mdf I disclaim even my very existance. Acceptance without proof is the fundamental characteristic of Western religion, Rejection without proof is the fundamental characteristic of Western science. -- Gary Zukav from "The Dancing Wu Li Masters" <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>