Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.info-terms Subject: Re: Wyse "magic cookies" Message-ID: <3039@umcp-cs.UUCP> Date: Tue, 4-Feb-86 15:19:26 EST Article-I.D.: umcp-cs.3039 Posted: Tue Feb 4 15:19:26 1986 Date-Received: Thu, 6-Feb-86 05:21:41 EST References: <312@uw-june> <120@ucdavis.UUCP> <1374@sdcsvax.UUCP> Distribution: net Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 56 Keywords: Cheap glitz 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