rAvbB1]2G2-{eN s[UGK ]?$\` pJmUGK&0e?,z--p7kUI5TI>^v8U^ There has been a lot of talk in the INFO-300 discussion concerning making CRTSTY smarter about clearing to the end of a line. One thing that bothered me was that people seem to think that this is easy to do. It is not. The clear to end of line (CLEOL) operation is so fundamental that ITS quite naturally (and correctly) assumes that every terminal is so capable. Because of this, many programs make liberal use of CLEOL; this makes their life simpler and their operation correct on display terminals which can overstrike. To get an idea of how fundamental CLEOL is, note that the outputting of a CR-LF by a program is interpreted by ITS as an implicit request to do a CLEOL. CRTSTY is a program which takes requests from ITS and translates them into things specific terminals can understand. It tries to do this as optimally as possible, but it still has to perform the operation it has been told to do. Thus when ITS directs CRTSTY to CLEOL, CRTSTY has no choice in the matter, though it will do the CLEOL operation as optimally as possible. For example, if the line only contains text in the middle, CRTSTY will cursor position to the beginning, output just enough spaces to clear the stuff and then cursor position back. To implement a better CLEOL CRTSTY would have to put off doing the CLEOL that ITS has told it to do until some later time, hoping that by so doing it will avoid clearing a line and then immediately filling it. The whole concept of putting off operations until a later time would require quite a few changes in the structure of the program. To make those changes would require quite a bit of KLH's or my time. However, we've worked out algorithms to do these things, just to see if its really possible to do them at the low level at which CRTSTY operates (the alternative would be to do them in the higher level user programs which generate the CLEOL requests in the first place). Our motivation for actually implementing these algorithms is slight as none of us have a CLEOL-less terminal (and if I did I would get out my soldering iron and fix it). It looks like we may implement them anyway, but don't count on it.  ---- DM2500 doc ---- The DM2500's main misfeature is the way it hacks "Roll mode" and automatic newline. Automatic newline is a feature whereby, if a move forward command (^\) or character is sent and the cursor is in the last column of a line, an automatic CR-LF is done (henceforth known as "auto-nl"). There are two interdependencies to watch for: [1] a CR (which does a newline) will not function immediately after an auto-nl! [2] a LF (move down) will not function immediately after an auto-nl OR a CR! Now, what happens when one of auto-nl, CR, or LF is done on the bottom line of the screen? That depends on whether or not the terminal is in Roll mode: a) NOT in Roll mode: Auto-nl or CR moves cursor to beginning of top line (home position), LF likewise wraps to top line but stays in the same column. b) IN Roll mode: screen scrolls upwards; top line is lost, and cursor either moves to beginning of new line (auto-nl, CR) or stays where it is (LF). Roll mode can be set and cleared either locally or remotely. DM2500 Control Codes: ====== ======= ===== ^Z = Up-line (if in first row, doesn't move) ^J = Down-Line (if in last row, goes to first row; but if Roll mode is on, screen scrolls up instead. LF will not function immediately after a CR or auto-NL) ^\ = Forward (if in last col, does an auto-NL with resulting side effects) ^H = Backspace (if in first col, doesn't move) ^I = Tab (this is used to move to next "variable field". no tab stops.) ^M = Newline (Not CR! Moves to beg of next line (see misfeature description)) ^B = Home ^L = Cursor positioning. Followed by X, Y coordinates (column, line) of the form #140, i.e. XOR the value with 140. ^W = Erase to End-of-line ^_ = Erase Screen - clears all "variable"-field data. If no protected fields are used, this is equivalent to Master Clear (but slower). On some DM's, this code is strapped to mean Clear-to-EOS, but not all. ^^ = Master clear - zap entire memory and home cursor. ^N = Blink On - all chars after this one will blink ^O = Form On - all chars after this will be in a "protected field". ^] = Roll On - turn on Roll mode. ^P = Insert/Delete On - see below. ^X = CAN - turn off all of Blink, Form, Roll, and I/D. Insert/Delete Codes: ============= ===== ^P = Enter Insert/Delete Mode ^\ = Insert Character - create a space at current cursor position, moving following chars on the line one space to the right. chars moved out of the last column are lost. Cursor remains where it is, i.e. now pointing at the space. ^H = Delete Character - delete char at cursor position, moving following chars left by one. a space is shifted into the last column. Cursor does not move, i.e. now points at the char previously just to the right of the deceased char. ^J = Insert Line - insert line at cursor position, by moving current line and all succeeding lines down by one, creating a fresh, cmpletely blank line. The line shifted out at the bottom is lost. Cursor does not move, i.e. is now sitting in the blank line at same column position. ^Z = Delete Line - delete line at cursor position. All following lines move up by one, and a blank line is shifted in at the bottom of the screen. Cursor does not move. ^X = CAN - leave I/D mode (as well as any other) Some words about padding: A normal DM2500 only requires padding for the following: 1) Erase (^_, not ^^) - at 9600 baud, this code should be sent twice in succession; otherwise just once is sufficient. This is sort of a pseudo-pad. 2) Insert Char - At 9600 baud, one rubout should be sent after each ^\. At lower speeds none are needed. 3) Delete Char - At 9600 baud, one rubout should be sent after each ^H. At lower speeds none are needed. 4) Delete Line - At 9600 baud, one rubout after each ^Z. At lower speeds, none needed. 5) Insert Line - the slowest. Here is an empirical table of # rubouts needed after each ^J: Speed # pads 9600 15 4800 7 2400 3 1200 1 6) Tab - If you really want to use this, you should get a Datamedia Technical Manual and learn about the protected vs. variable field hackery. NOTE: on some older model DM2500's, Insert Line needs one more rubout than those given in the table (possibly two), and Insert Char is unreliable in the first 11 or so lines of the screen if running at 9600 baud, no matter how many pads are given. This is a design flaw with respect to the memory board that was corrected on later DM's by redesigning it to halve the access time for I/D mode. FURTHER NOTE: on these losing DM2500's a frob that lets you win with Insert Char is to send a Space (40) instead of a FS (^\). This shifts the line properly, but has the side effect of moving the cursor and can leave garbage in the position spaced over, so after leaving I/D mode one must backspace over and write spaces or something there. The number of rubouts needed for Insert Line is really dependant on the current line position, here is a formula that seems to work: ((30.-VPOS)*OSPEED-2400.)/14400. KLH@MIT-AI 01/18/78 20:51:08 SAM@MIT-ML 01/18/78 20:47:10 Re: T.D.L. Video Display Board To: KLH at MIT-ML, MGW at MIT-ML, RTS at MIT-ML, DEVON at MIT-ML CC: SAM at MIT-ML Hi, I have just returned from a trek to the Computer Mart,where I saw demonstration of the T.D.L. Video Display Board.It is 25 lines of 80 characters and puts up a nice display.TDL supplies a software driver that emulates an ADM-3A Dummie Terminal.The board itself comes factory A+T with a combat (ARMY) green solder mask.They recommend that you use it with a converted Hitachi TV(Suggest Pickles+Trout mod. Kit.)The board itself performs well and puts up a clear-well focused display.The board I saw however did show signs of flicker,but this is present in almost all hobbyist displays and as such must be put up with. Sam  KLH@MIT-AI 01/14/78 07:01:05 CBF@MIT-MC 01/14/78 03:23:48 To: ELLEN at MIT-MC, KLH at MIT-AI CC: CBF at MIT-MC TTY 43: Printing terminal, 30 cps, would look to the system exactly like an LA36 (ie. no padding needed for CR, no hardware tabs). Prints 132 columns by 54 lines horizontally on 8.5x11" paper. Looks like a cute plastic toy. Uses 9x7 dot matrix, descenders included. Character set fairly readable, ribbon changes very easy. Alas for the quoted prices, they are only for certified OEMs (whatever that is), however there are no quantity discount. Table is roughly as follows reconstructed poorly from memory: Discount INTERFACE None Educational OEM TTL $1200 $1000 $ 840 EIA $1350 $1200 $1080 PSK (modem) $1550 $1350 $1100 These numbers are plus or minus 10%, but should give you some idea. Someone in the Math Dept ordered one for himself through the dept and paid the educational price. I don't know what happens if you simply send in an order with the OEM price. He managed to get quick delivery through a dealer, but in general these things are difficult to get a hold of, as AT&T absorbs some large percentage of the production. No real options (like tabs or form feed) are available, program settable margins are standard, as is a remotely controllable loopback capability for testing. The PSK version basically has a standard 103 type modem built in, and that is the only interface. Ie. if you elect for that, you cannot hardwire it if you cared to. The PSK version has 2 modular type phone jacks on the back, one to plug your phone line into, the other to plug your phone into. Once you dial up, you can hang the phone up or not as you care, its disconnected on reciept of carrier. There is an auto-answer switch on the terminal, also a 110 baud setting, but amazingly enough (considering TWX applications) no optional or standard answerback. I understand though, that an ASR version of some sort is in the works. (Probably with some sort of internal memory, perhaps like the TI bubbles). The keyboard is fairly good, has about the same feel as a TTY40, ie. an exaggerated feedback (in my opinion), but one can probably easily get used to it and achieve good speeds. As I mentioned the thing sort of looks like a plastic toy and sits on a desktop. The 132 character width and use of cheap paper certainly make it preferable to a TI, and its almost as quiet. Its just slightly oversized to be easily portable, not to mention not being available with a suitable carrying case, though presumably that could be remedied. If you carry your own modular cable around for the PSK version, you could certainly attach to any convenient modular phone. You must use the special 8.5x11" paper with prforated tear off edges though, since the platen is fixed sized. If I decided I needed to buy my own printing terminal tomorrow, this would probably be it.  KLH@MIT-AI 11/15/77 16:27:55 Date: 14 NOV 1977 1526-EST From: CBF at MIT-MC (Charles Frankston) Subject: MiniBee To: MSS at MIT-MC CC: ELLEN at MIT-MC, MOON at MIT-MC, KLH at MIT-AI, CBF at MIT-AI There are, I believe 4 levels of Mini-bee, labelled something like 1 through 4. I am sure the lowest (I believe that is 4), will not work as :TCTYP MINIBE, and possibly 2 & 3 don't either. If you have the highest level of Mini-Bee and have problems anyway, I think it may be because the Mini-Bee only has 24 lines on a screen & the system thinks it has 25. You can try fixing this by doing a :TCTYP MINIBEE,PAGE 25. the decimal point at the end is important. The Mini-Bee 4 can probably be used as a display by going through CRTSTY. I beliebe :CRTSTY MB4 will do this, however, it will on the average, take a full minute to transmit a screenful at 300 baud.  CFFK@MIT-AI 11/01/77 21:23:40 Re: lost keys on ADM2 To: (BUG CRTSTY) at MIT-AI, JLK at MIT-MC Well I found them. ^_=new line and ^^=home!  CFFK@MIT-MC 11/01/77 17:03:12 To: JLK at MIT-MC, (BUG CRTSTY) at MIT-MC I can't find ^_ or ^^ on the ADM2 keyboard. Does anyone know where they might be?  CBF@MIT-MC 09/30/77 15:58:34 Re: Micro-Term Act IV To: RJF at MIT-MC, KLH at MIT-AI CC: KLH at MIT-MC, ELL at MIT-MC, ELLEN at MIT-MC, MOON at MIT-MC CC: JM at MIT-MC, CBF at MIT-MC Ok, I called them and asked them to send me a manual. Apparently line/character insert/delete is not available via control code from the computer because the terminal cannot do them at 19.2Kilobaud. However it does have the standard set of cursor positioning and Clear to End of Line and Clear to End of Screen. Their codes for this are apparently their own selection, however they said for a one time charge of $50 they would make a ROM for any codes we wished. Also for that same charge they would put insert/delete character/line codes in the ROM, although they would need apx. 2 milliseconds/line or 20usec/character of padding. They have none in any computer store in the Boston area, they claimed a computer store in NY carries it, but they said "it was not a good one" (the computer store presumably). Perhaps you CA people might check your local computer store to see one. While the CA people are sampling terminals, the Computermania show out here had a 48 line by 80 character terminal for $1300 assembled and $1100 kit. I did not get to see it, but the people who did claimed it looked good. They are Video Terminal Technologies in Sunnyvale. Claims to have all the standard VT-52 like features again, but no claim of insert/delete line or anything. On the whole, for a home terminal, I would take line insertion/deletion over 48 lines, because that is more useful at 300 baud. But another cute thing about this terminal, is it has optional bit raster display. The 256*256 version cost $600, I didn't get a price on the 512x512 version.  KLH@MIT-AI 10/06/77 19:05:35 To: CBF at MIT-AI, (FILE [ksc;crtsty notes]) at MIT-MC Well, had a chance to look over a VT-4800 today. Basically my feeling is that the lack of char/line ins/del is quite deadly to any hopes of using it, particularly with 48 lines. It seemed clear that these functions don't exist at all. The salesman said that one customer was doing that by adding an 8080 or something; it does have a 800 Khz parallel input port with whch I assume you can hook up your favorite controller. Serial I/O is limited to 9600 baud. It's not clear why 19200 isn't supported, since he claims no pads are required even at the 800 Khz rate. Anyway, the model he brought was fixed at 4800 because the baud selector switch hadn't been wired up yet, and even then there seemed to e some problem with its timing, since 4800 from the IO-11 didn't work very well; lots of garbage on the screen. Perhaps the clock got out of adjustment or smething (crystal, 0.5% error). So we were limited mostly to local-mode stuff. Other things: It has video invert and lowercase but both ma be options; not sure. (by invert I mean single chars - but no blinking, etc). It has no CLEOF. Cursor addressing is 4 bytes; all control functions are strappable to any control character (except ^G,^M,^J fixed). It doesn't use escape sequence. ie mos stuff directly in hardware. although it has M6800 processor, I guess it doesn't do much. If you woner about the 4-byte addressing, well it has set-X and set-Y functions which take next byte as value. Other functions set video normal/inverse, cursor left and right, up and down (scroll both ays), home, clear, cleol, total-reset. It has provision for "pages" with functions to jump to page 0, show next page, previous page. Needs 4K memory per page, up to 16K. The keybaord is pretty good. N-key rollover, good feel, auto-repeat, lots of blank keys for progammed use. It is possible to get a metizer set up for the 8th bit; it seemed as if using CTRL and SHIFT together might be a pssible way of doing it, although I'm not sure I and salesman understood the other perfectly. The display is bit mapped and graphics hardware is supposed to be available, 2-plane so no interference with characters. These by the way are 5x7 which is how they fit 48 lines in, as oppoed to 7x9 etc; the monitor is conventional. Graphics will ave hardware vectors, 256x256 resolution. There are altogether too many jumpered options which would be nicer to have as switches such as oe finds on the ADM-3A. eg parity handling. But I suppose once you put your soldering iron away there won't be much need to change. Costs: 1195/kit to individual. they may not sell kits in future though. in groups of 5, $995 fully assembled and $895 kit. Over 25, he didn't know; something lower. No educational institution discounts. 2 boards, one for main stuff and the other is part of the kbd. Not really impressive I would say; 48 lines and decent keyboard are about the only things it has going for it over other terminals. Now if it had line ins/del I would perk up. The fellow is going to call back later with some more info on that and if we are still interested we may be able to borrow one (with proper baud rate) overnight for an online tryout.  CBF@MIT-MC 09/16/77 16:11:51 Re: ADM-3A To: ELL at MIT-MC CC: (BUG CRTSTY) at MIT-MC, RJF at MIT-MC As far as a fix for the terminal goes, Moon put Clear to End of Line in his when he built it. He also used all the Datamedia 2500 control codes (except of course it doesn't support line or character insertion deletion, or Clear to End of Screen which he claims is rarely sent by ITS), he also removed the keyboard locking and unlocking feature and put used the bell to make a clicker for the keyboard (sort of lock a less sharp VT-52 style clicker). Anyway, the important feature is obviously Clear to End of Line, which would make the terminal supportiable. Also, unless I am completely misunderstanding things, if you want the terminal to scroll, run it :TCTYP GLASS, and not through CRTSTY, it will be about 40 times as fast that way.  CBF@MIT-MC 08/17/77 22:54:57 Re: HP2645A padding. To: (BUG CRTSTY) at MIT-MC I think there is an interpretation of the documentation which indicates we can get away without padding even at 9600 baud. One has to remember that there is an 80 character buffer for the Ack/Nak stuff. Thus using the following table: Function Milliseconds Vanilla Character 0.7 Cursor Up/Down/Left/Right 1.4 Line Feed 1.4 Insert Character 4.5 Delete Character 7.0 Insert Char w/wrap 12.0 Delete Character w/wrap 19.0 Forms Mode On 12.0 Forms Mode: Home 8.0 Tab 8.0 Back Tab 10.0 EOL (40 chars) 10.0 Given then that each normal character can buy you a little over .3 milliseconds to apply toward the slower functions, it is doubtful any normal ITS output will have a problem, especially since we won't run it in forms mode.  CBF@MIT-MC 08/17/77 22:56:37 Re: HP2645A padding table To: (BUG CRTSTY) at MIT-MC addendum: Being the usual HP, the times in the table are not exact, but an average. This is the detailed reference manual I got them from not the usual manual. I suppose HP feels the user would be overlwhelmed if he actually got some exact timing formulas. < KLH, DISPLAYS.NLS.1, >, 13-Jun-77 02:21 KLH ;;;; 1 Intro - for people with (or thinking of getting) new displays 1A This document is meant for people who have, or intend to obtain, a CRT display terminal and wish to use it effectively with ITS. Although it includes the "normal" terminals which ITS understands internally, the emphasis is on how to properly use odd, exotic, or misdesigned terminals, and what types/brands/models will work best in the ITS environment. 2 ITS display philosophy 2A ITS provides excellent display terminal support (vastly better than any other PDP-10 system) both in terms of quality and generality; not only are many programs written for display use, but the same program is usable on almost ANY display. This is due to the concept of a "virtual display"; 2B ITS tries to make each terminal resemble, as closely as possible, a "virtual display" which programs can manipulate using standard commands. These commands are called "^P-codes" because when an output channel to the TTY is enabled for display mode, display commands are prefixed with ^P. (For example, ^P K is the command to erase a single character. See E.3 of .INFO.;ITS TTY for a complete listing of ^P-codes) Thus, while the dimensions of this virtual display can change, and some features may not be available in reality, the program never needs to concern itself with how a command is implemented. When necessary, the program can simply ask ITS for the screen dimensions and a set of "option" bits which indicate whether or not a specific ^P-code command can actually be given. 3 What kind of terminal will work? 3A Any kind. But the extent of their usefulness on ITS will depend on how closely they approach the "ideal" full-capability virtual terminal. For editing text, anything less than a standard display would be very backward; more than that would be nice but is not essential. 3B The standard display must have: 3B1 [1] CURSOR CONTROL 3B1A Move the cursor anywhere on the screen 3B2 [2] SELECTIVE ERASE 3B2A Erase any single character without disturbing the rest 3C The "option bits" define some progressively more primitive subsets of the full ITS virtual display capabilities. 3D These subsets are, roughly: 3D1 1) Printing terminal 3D2 2) Storage-tube - no selective erase. 3D3 3) Glass TTY - no upwards cursor control 3D4 4) Standard display - cursor control, selective erase. 3D5 5) Full ITS display with line/char insert/delete and highlight mode. 3E While most programs check these bits before doing anything funny, ITS will in most cases do something reasonable upon seeing a command that is not in fact possible; for example, if a ^PC (clear screen) is given, and the terminal is unable to do this, ITS sends a CRLF instead. 4 All TTY's are created equal - but some are more equal than others. 5 "Crippled" displays (without above) 5A Glass TTY's - clear, backspace/erase, no upwards positioning. 5B Storage-tube scopes - clear but no erase, positioning? 6 Idealized ITS display - software codes 7 Problems in practice 8 CRTSTY as partial solution 8A Theory 8B Terminals understood 8C Switches