schwartz@swatsun.UUCP (05/27/87)
Hi gang,
This is a complaint, I guess. At Swarthmore we have lots of Adds
Viewpoint terminals. On these beasties the escape sequences to enter
standout mode, underline mode, normal mode, etc all take up one space
on the screen (gaak). The problem is that lots of programs that go
to lots of trouble to figure out what the termcap entries for these
things are never bother to check the width of the entries as printed.
So microEmacs (all versions that I know of, up to 3.8f), for example,
prints like this on a viewpoint:
n o s p a c e s
Don't even think about what happens when it tries to highlight the status
line. Similarly, the latest posting of rogue to comp.sources.games
blindly ignores the "sg" and "ug" termcap entries.
So look, please accord "sg" the respect it deserves, and use it in your code!
Not everyone is lucky enough to have a vt100 :-)
Oh, and speaking of rogue... the readme said it was not yet ported to
BSD, etc... I've been working on porting it to Pr1mos (I kid you not).
Pr1me's C compiler has it's own ideas of what is allowed and what's not:
variable length argument lists are death on wheels, probably for
architectural reasons. At any rate having all the OS dependent stuff
localised was a big win, and the porting went pretty smoothly.
The inspiration for this was that I hate walking into the lab and seeing
a room full of Suns busy playing hack :-)
--
# Scott Schwartz
# UUCP: ...{{seismo,ihnp4}!bpa, cbmvax!vu-vlsi, sun!liberty}!swatsun!schwartz
# AT&T: (215)-328-8610 /* lab phone */snoopy@doghouse.UUCP (05/28/87)
In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: > This is a complaint, I guess. At Swarthmore we have lots of Adds >Viewpoint terminals. On these beasties the escape sequences to enter >standout mode, underline mode, normal mode, etc all take up one space >on the screen (gaak). The problem is that lots of programs that go >to lots of trouble to figure out what the termcap entries for these >things are never bother to check the width of the entries as printed. >So microEmacs (all versions that I know of, up to 3.8f), for example, >prints like this on a viewpoint: > n o s p a c e s Am I missing something here, or should these termcap entries include a backspace to return the curser to where it belongs? Why screw up a bunch of code to get around brain-damaged hardware if it can be fixed in the termcap entry? Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
chris@mimsy.UUCP (Chris Torek) (05/29/87)
>In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott >Schwartz) writes: >>... At Swarthmore we have lots of Adds Viewpoint terminals. On >>these beasties the escape sequences to enter standout mode, underline >>mode, normal mode, etc all take up one space on the screen (gaak). (I do not recall this of the Viewpoint: It had one mode that could always be displayed; that mode could be any of inverse, blink, or underline, and perhaps one other. These may be different Viewpoints.) >>The problem is that lots of programs that go to lots of trouble >>to figure out what the termcap entries for these things are never >>bother to check the width of the entries as printed. In article <8601@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes: >Am I missing something here, or should these termcap entries include >a backspace to return the curser to where it belongs? Alas, this simply does not work. The way these terminals work is rather bizarre. The manufacturer decided to save one whole memory chip, using only seven bits per character. Since, however, better terminals provide inverse video, underline, blink, and bold, these terminals do too. But without extra bits, this information must come from elsewhere. It is inserted into the display by storing control characters in screen RAM. These are programmed to display as blanks, yet they are *not* blanks: They alter the state in the video generator such that all following characters are displayed in inverse video, or underlined, or whatever. These `marker' control characters that display as though they were blanks are referred to as `magic cookies'. Terminals that behave this way are said to have the `magic cookie glitch'. This is a horrid thing for a terminal to do, and there is now no justification for it: memory is cheap, and 2K by 8 bit display RAMs are available on a single chip. (Indeed, I suspect that by now, 2K by 11 or more bit dual ported RAMs with one of the ports internally interfaced to a video controller are available.) If you manage to position the cursor on top of one of these magic cookies, and write a real character, it replaces the magic cookie and the inverse video (or underlining or whatnot) on succeeding characters instantly vanishes. Whether it is possible to position the cursor on one of these cookies, and whether text will overwrite or simply skip the cookie, depends on the terminal firmware. >Why screw up a bunch of code to get around brain-damaged hardware >if it can be fixed in the termcap entry? Why keep a terminal that uses magic cookies, when real displays are cheap? :-) Actually, faced with such a terminal, I might just leave out the `so' and `se' termcap capabilities. We did this with the Datamedia 2500, whose only standout mode was `blink'.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
schwartz@swatsun.UUCP (05/29/87)
In article <8601@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: > In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: > > n o s p a c e s > Am I missing something here, or should these termcap entries include > a backspace to return the curser to where it belongs? > Why screw up a bunch of code to get around brain-damaged hardware > if it can be fixed in the termcap entry? Sorry for not being clear in the first place. The termcap entry we use entry is correct. It functions perfectly with lots of unix software: vi, gnuemacs, etc, etc, etc. The problem really is that the authors of microemacs and rogue (and probably other things too) IGNORE the relevent termcap fields. I know this because I looked at the source. In fact, someone once posted a patch for uEmacs 3.7 to handle just this problem. uEmacs 3.8 has been rewritten enough that the original fix cannot be naively applied with patch(l). > Snoopy -- # Scott Schwartz # ...{{seismo,ihnp4}!bpa,cbmvax!vu-vlsi,sun!liberty}!swatsun!schwartz
phil@amdcad.AMD.COM (Phil Ngai) (05/30/87)
Speaking of terminals, I note that PC clones with floppy only drives,
monitor, and DOS can be gotten in the $600 range, which is less than
we pay for DEC VT-220s. Are there any places which are buying PCs and
using them as simple terminals? How does it work out? Wouldn't you be
subject to the bozos who say "what a lousy computer you bought" when
it was only intended to be a terminal?
Why would you want a PC instead of a terminal? Well, in addition to
the fact that it can be cheaper (particularly if you want graphics)
the IBM monitor makes really nice characters and the IBM keyboard
feels VERY nice. I don't know how well the clones do in this area.
--
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.comwcs@ho95e.ATT.COM (Bill.Stewart) (05/31/87)
In article <8601@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes: >In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: > >> [Why does ADDS Viewpoint act braindamaged; describes magic cookie] >>So microEmacs (all versions that I know of, up to 3.8f), for example, >>prints like this on a viewpoint: >> n o s p a c e s >Am I missing something here, or should these termcap entries include >a backspace to return the curser to where it belongs? >Why screw up a bunch of code to get around brain-damaged hardware >if it can be fixed in the termcap entry? As other posters point out, termcap fixes aren't enough; magic cookies are serious braindamage. Apparently some manufacturer (?Rockwell) made a relatively low-cost chipset that was used by Televideo, ADDS, some WYSE terminals , etc. and all these terminals started calling themselves Televideo-compatible, as if it were a good thing. It may not be possible to fix MicroEMACS to use them, except by turning off the highlighting modes entirely. Most EMACS descendants share Richard Stallman's view that you shouldn't mung up your software to accomodate bad hardware decisions made by other people. (Control-S is the prime example.) I tend to disagree; software should be made flexible enough to work around most problems. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
rbl@nitrex.UUCP ( Dr. Robin Lake ) (06/01/87)
In article <16906@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: > >Speaking of terminals, I note that PC clones with floppy only drives, >monitor, and DOS can be gotten in the $600 range, which is less than >we pay for DEC VT-220s. Are there any places which are buying PCs and >using them as simple terminals? How does it work out? Wouldn't you be >subject to the bozos who say "what a lousy computer you bought" when >it was only intended to be a terminal? And a Macintosh with a couple of terminal emulation programs beats the cost of any ONE of them, nonetheless ALL of them. We could not get a decent hardcopy off a VT241 (colors all print in black on an LA50). A Mac with terminal emulation (White River's MAC240(TM)) mapped the colors to patterns and the job rolled on! Ditto for a variety of Tek 401X and other Tek emulations. And, of course, a variety of DEC emulations thrown in, too. Funny, the boss thinks it's great. After seeing what the Mac could do, he now even asks for project plans "using that Macintosh" (and MacProject). Disclaimer: Only the workers take the Mac seriously. This is definitely NOT an endorsement of any product, just a comment on what's goin' on. Rob Lake decvax!cwruecmp!nitrex!rbl
langdon@lll-lcc.aRpA (Bruce Langdon) (06/01/87)
In article <16906@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes: > > Speaking of terminals, I note that PC clones with floppy only drives, > monitor, and DOS can be gotten in the $600 range, which is less than > we pay for DEC VT-220s. Are there any places which are buying PCs and > using them as simple terminals? How does it work out? Atari 540 ST's with a monochrome monitor are as cheap and provide a lot better display quality, or else more lines/characters per line. The higher number of pixels also helps you for graphics when you emulate a Tektronix. The software to do this is cheap too. With our present budget shortages, some people here are doing just this. If you don't need perfect VT-xxx and IBM compatibility, buy cheap. Save your money for Suns and MicroVax II's ---real PC's!!! -at rapidly dropping prices. > the IBM monitor makes really nice characters ?? you must be talking about the monochrome board that doesn't support graphics. ---------------------------------------------------------------------- Bruce Langdon L-472 langdon@lll-lcc.ARPA Physics Department 339650%d@nmfecc.ARPA Lawrence Livermore National Laboratory Livermore, CA 94550 (415) 422-5444 UUCP: ..{ihnp4,qantel,ucdavis,pyramid,styx,topaz}!lll-lcc!langdon ..{gymble,ll-xn,seismo}!lll-crg!lll-lcc!langdon
jfh@killer.UUCP (06/01/87)
In article <8601@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: > In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: > > > This is a complaint, I guess. At Swarthmore we have lots of Adds > >Viewpoint terminals. On these beasties the escape sequences to enter > >standout mode, underline mode, normal mode, etc all take up one space > >on the screen (gaak). The problem is that lots of programs that go > >to lots of trouble to figure out what the termcap entries for these > >things are never bother to check the width of the entries as printed. > >So microEmacs (all versions that I know of, up to 3.8f), for example, > >prints like this on a viewpoint: > > > n o s p a c e s > > Am I missing something here, or should these termcap entries include > a backspace to return the curser to where it belongs? > > Why screw up a bunch of code to get around brain-damaged hardware > if it can be fixed in the termcap entry? > > Snoopy > tektronix!doghouse.gwd!snoopy > snoopy@doghouse.gwd.tek.com I don't know if the ADDS Viewpoint has a setup option for visible and invisible attributes, but the problem seems to be caused by the spaces that the attributes take up, SG and UG give the number of spaces each attribute takes. ERASING OR OVERWRITING THE SPACE MAY MAKE THE ATTRIBUTE GO AWAY!!! You may want to make certain your termcap entry has both of the widths given. If memory serves correctly, SG is for standout mode and UG is for underline mode. You didn't say if you checked your termcap (including termcap entries in postings needs to become a standard practice with termcap questions.) Double check it and repost with the termcap if your problem still exists. I can't believe anyone wrote that kind of brain-damage :-) code ... ( Snoopy - back to the dog house for you :-) - John. Disclaimer - No disclaimer. Whatcha gonna do, sue me?
catone@dsl.cis.upenn.edu (Tony Catone) (06/11/87)
In article <16906@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: > >Speaking of terminals, I note that PC clones with floppy only drives, >monitor, and DOS can be gotten in the $600 range, which is less than >we pay for DEC VT-220s. Are there any places which are buying PCs and >using them as simple terminals? How does it work out? The problem we have with this is that our users fall in love with the VT100 keyboard for editors like EDT and TPU, and then complain about the incomplete VT100 emulation PC's provide. In reality, most times it turns out the emulators (PC/Intercom, MS-Kermit, CrossTalk) are very complete (with the notable exception of 132 column mode), but are limited by the fact that the PC keyboard does not physically have as many keys as the VT100 layout. Unix users of emacs and vi are not usually as unhappy, since those editors do not rely as much on function keys etc. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
jdia@osiris.UUCP (06/12/87)
In article <1335@super.upenn.edu.upenn.edu>, catone@dsl.cis.upenn.edu (Tony Catone) writes: > > The problem we have with this is that our users fall in love with > the VT100 keyboard for editors like EDT and TPU, and then complain > about the incomplete VT100 emulation PC's provide. In reality, most > times it turns out the emulators (PC/Intercom, MS-Kermit, CrossTalk) > are very complete (with the notable exception of 132 column mode), but > are limited by the fact that the PC keyboard does not physically have > as many keys as the VT100 layout. Unix users of emacs and vi are > not usually as unhappy, since those editors do not rely as much on > function keys etc. A worse problem exists for those of us who access machines through Bridge boxes, multiplexers, and some types of switches. First of all, most of these filter out some control characters, to use them for their own weird purposes, or handshaking. More than half of these that I have encountered do not pass ^S and ^Q (xoff and xon) as they are sent. This recks havok with editing in EMACS, which usually has ^S bound to search-forward and ^Q bound to quote-character. To top it off, ^X^S is SAVE-FILE!!!! Try working in an editor where you can't even save a file!!! There are usually ugly kludges around these problems. These usually consist of binding other keys to these functions. This is especially difficult in emacs because there are functions already bound to most of the keys and key-combinations. Why can't multiplexers/bridgeboxes pass these AS THEY ARE RECEIVED??? It shows a lack of thought on the part of someone, I'm not quite sure who. There has got to be a better way of doing this handshaking! Or, there has to be a version of emacs that makes more use of individual terminals' program function keys, and less use of control chars. esc-codes are ok, but the control codes can really mess things up. 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? The "IDEAL" solution to this problem would be to make emacs understand pf-keys better. Microemacs is easily kludged to do this. Isn't it about time this happened? I won't even mention that most emacs'es don't understand the cursor keys which exist on all but the most archaic terminals (and Macintoshes). :-) That's Enough... Spidey! -- A message from Spidey, and the Spidey Team. ------>>>> \_\ /_/ ____________________________________________________________ _[*]_ \ Reachable via UUCP: ...decvax!decuac!aplcen!osiris!jdia / / / \ \ / ...allegra!mimsy!aplcen!osiris!jdia \
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/87)
Railing against the use of DC3 and DC1 for flow control by some terminals is pointless -- they need to throttle incoming data, especially at high bit rates and when performing complex actions such as line insertion, and the DC3/DC1 method was chosen as the best way to do this, given that most modems don't correctly handle control-line (out of band) flow control. If your terminal requires support for DC3/DC1 flow control, you should so inform the UNIX terminal handler, which will make sure the DC3/DC1 characters are not seen by the application. You should also have the "xo" Boolean capability set in the termcap entry. If in spite of this, your copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them as user command keystrokes, then your EMACS is in need of repair. The version I often use does not have this problem. (You should also get out of the habit of using any key bindings containing ^S or ^Q. That was a really stupid set of defaults in the first place.)
u3369429@murdu.UUCP (06/15/87)
I don't know why this discussion is in comp.sources.d, but where is a better place? In article <1335@super.upenn.edu.upenn.edu> catone@dsl.cis.upenn.edu.UUCP (Tony Catone) writes: >The problem we have with this is that our users fall in love with >the VT100 keyboard for editors like EDT and TPU, and then complain >about the incomplete VT100 emulation PC's provide. In reality, most >times it turns out the emulators (PC/Intercom, MS-Kermit, CrossTalk) >are very complete (with the notable exception of 132 column mode), but >are limited by the fact that the PC keyboard does not physically have >as many keys as the VT100 layout. Apart from speed considerations (as somebody pointed out, even the VT100 is pretty limited), would somebody care to name a hardware/software combination which completely emulates a VT100? Including 132 columns, smooth scroll, double height/width, alternate character sets like Dec Special Graphics, Display Control Font ? (Not to mention the VT100's VT52-compatibility, but now I'm going too far.) The only ones I'm aware of are a handful of VT100 (or rather VT200) terminal clones, no micros.
tech@auvax.UUCP (06/16/87)
In article <1166@osiris.UUCP>, jdia@osiris.UUCP (Josh Diamond) writes: > In article <1335@super.upenn.edu.upenn.edu>, catone@dsl.cis.upenn.edu (Tony Catone) writes: > > > > The problem we have with this is that our users fall in love with > > the VT100 keyboard for editors like EDT and TPU, and then complain ... > The "IDEAL" solution to this problem would be to make emacs > understand pf-keys better. Microemacs is easily kludged to do this. > Isn't it about time this happened? The problem for me is that to use function keys I have to take my hands off the keyboard and reach for the function keys. Worse, I have to take my eyes off the screen and look at my hands. On VMS I use the TPU based LSEDIT where I have mapped the more used function keys to emacs like control chars. I have to conclude that Function Key editors were not invented by typists. ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada ..........**** ihnp4!alberta!auvax
aad+@andrew.cmu.edu.UUCP (06/16/87)
Don't flame mindlessly agains GIGI's when you don't seem to understand them. You can't seriously believe that the logic is written in basic, can you? The gigi buffer fills at 9600 baud when you send it a bunch of short lines in a row. You can set the flow control via setup. If it bothers you that much rebind ^s.
guy@gorodish.UUCP (06/16/87)
> I have to conclude that Function Key editors were not invented by typists.
I have to conclude that this is a flame based on personal anecdotal
evidence. There are benefits to function keys (for one thing, you
don't have to hit a shift key - I, for one, find I occasionally get
^X-^N when I want ^X-n) and there are benefits to control keys (you
don't have to move your hands from the main keyboard).
However, it is possible to work with a program that uses control keys
(most of the time I don't end up getting ^X-^N when I want ^X-n) and
it is possible to work with a program that uses function keys (when
useing such an editor my hands learned where the function keys were,
and I could go there and back very quickly without looking).
I have yet to see any objective evidence to indicate either that function
keys are clearly superior to control keys or that control keys are
clearly superior to function keys. It would be interesting to see
experimental (as opposed to anecdotal) evidence either way.
You can say that you work better with control keys, or that you work better
with function keys, but not that "control keys are better" or
"function keys are better".
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.comjdia@osiris.UUCP (06/17/87)
In article <IUpNpZy00Uo58EI091@andrew.cmu.edu>, aad+@andrew.cmu.edu (Anthony A. Datri) writes: > Don't flame mindlessly agains GIGI's when you don't seem to understand them. > You can't seriously believe that the logic is written in basic, can you? How come one time when someone entered something weird into the setup, the screen changed and we were in basic, with a message that went something like "subscript out of range in line XXX"? Moreover, there have been several communication packages for the IBM-PC that are written in BASIC. Interpretive. For insance: The IBM Asynchronous Communications Package which they released when the PC first arrived on the scene, way back when. Besides, the GiGi keyboard is really poorly made. (Then again, so is the "real DEC" vt100 keyboard :-). Josh / Spidey! -- DON'T PANIC!!! \_\ /_/ Yes, it is _[*]_ supposed to A message from Spidey, and the Spidey Team. ------>>>> / / \ \ look like a Reachable via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia spider!
jmg@mdbs.UUCP (John Murray Gamble) (06/17/87)
In article <189@auvax.UUCP> tech@auvax.UUCP (Richard Loken) writes: > >The problem for me is that to use function keys I have to take my hands off >the keyboard and reach for the function keys. Worse, I have to take my >eyes off the screen and look at my hands. > >On VMS I use the TPU based LSEDIT where I have mapped the more used function >keys to emacs like control chars. > >I have to conclude that Function Key editors were not invented by typists. > > ********* 73 > ********** Richard Loken VE6BSV > . **** > .. **** Athabasca University > .... **** Athabasca, Alberta Canada >..........**** ihnp4!alberta!auvax Actually, i conclude just the opposite. *Editing* is different from *typing*. The operations involved in editing (moving or deleting lines, words, or characters, searching/replacing) have very little to do with actual creative typing. When i am typing, my fingers stay on the main keyboard for long periods of time, and when i am editing my left hand rests while my right hand works the keypad. I never had to look at my hand, anymore than i look at the keyboard for typing. This is one of the reasons i miss EDT. When doing actual editing, all the keys i need to use are beneath *one* hand, which does not need to move while i am editing. No silly control key to hit (an operation invented to destroy the pinkie finger on the left hand) while simultaneously hunting for the key to be control-ed. Thank god EMACS-style editors allow key rebindings, or my fingers would be useless. For those wondering what the fuss about EDT is, a short, incomplete description of it would be to call it the RISC equivalent of editors. Very few commands in screen mode, but they are very powerful. It is analagous to driving a car, in that the same operations work in forward and reverse, with the directions toggled by a key(pad)stroke. It was a definite change from vi and took a lot of getting used to, but it ruined vi for me. EMACS (any flavor) is now my editor of choice. ---------------------------------------------------------------------------- John M. Gamble | Lo! thy dread Empire COBOL is restored; 2550 Yeager Rd. #15-2 | Light dies before thy uncreating word: West Lafayette, IN 47906 | Thy hand, great Anarch, lets the curtain fall, -------------------------| And Universal Darkness buries all. (313) 497-9501 | ihnp4!pur-ee!mdbs!jmg | from "The Dunciad", sort of, by Alexander Pope ----------------------------------------------------------------------------
tech@auvax.UUCP (06/17/87)
In article <21251@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > I have to conclude that Function Key editors were not invented by typists. > > I have to conclude that this is a flame based on personal anecdotal > evidence. There are benefits to function keys (for one thing, you Some little nits can't tell a flame from a reasonably restrained comment. I said that this was my opinion and did not imply that control keys are better but suggested that two or three people out of 100,000 might prefer them. I will explain flames so that you can use the term correctly in the future. THIS IS A FLAME. YOU ******* IDIOT!!! ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada ..........**** ihnp4!alberta!auvax
smvorkoetter@watmum.UUCP (06/18/87)
In article <1264@murdu.OZ> u3369429@murdu.oz.au (Michael Bednarek) writes: >Apart from speed considerations (as somebody pointed out, even the >VT100 is pretty limited), would somebody care to name a hardware/software >combination which completely emulates a VT100? Including 132 columns, >smooth scroll, double height/width, alternate character sets like >Dec Special Graphics, Display Control Font ? >(Not to mention the VT100's VT52-compatibility, but now I'm going too far.) The package "Terminal Emulator and File Transfer 2.40a" on an IBM PC emulates double height/width (does double spacing on the screen, but the characters all come out in the right place), alternate character sets (UK,GRAPHICS,US), display control font (part of the graphics set, just as on a VT100. Uses representative symbols from the IBM PC character set.) It also does VT52 emulation, and can be put into VT52 mode from VT100 (or VT102) mode by the host, just like a real VT100, and when told to go back, will return to VT100 (or VT102) mode, just like a real VT100. Also manages 19200 baud on an AT, or 9600 on a PC.
vallury@dartvax.UUCP (RustCat) (06/23/87)
In article <1335@super.upenn.edu.upenn.edu> catone@dsl.cis.upenn.edu.UUCP (Tony Catone) writes: >In article <16906@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: >The problem we have with this is that our users fall in love with >the VT100 keyboard for editors like EDT and TPU, and then complain >about the incomplete VT100 emulation PC's provide. In reality, most >times it turns out the emulators (PC/Intercom, MS-Kermit, CrossTalk) >are very complete (with the notable exception of 132 column mode), but >are limited by the fact that the PC keyboard does not physically have >as many keys as the VT100 layout. Unix users of emacs and vi are >not usually as unhappy, since those editors do not rely as much on >function keys etc. > As far as the VMS and the terminal emulation thereof on a PC is concerned, it shouldn't take too long to write up a little TPU initialization file rebinding keys to perform whatever editing functions you want. Just look at the EDTSECINI file in your VMS system to see how this is done. The key defining function in VAXTPU will do most anything for you. Enjoy. "We cut down some trees and we trailed our ideals through the forest glade" Vallury
stevesu@copper.TEK.COM (Steve Summit) (06/25/87)
I've been meaning to mention this ever since the termcap
discussion started. (The original complaint was about software
that did not acknowledge sg.)
The reason that so few programs handle terminal dependencies
correctly is that it is a very hard problem, and termcap is not a
particularly good solution. Furthermore, it is essentially
undocumented. termcap(5) gives you a sketchy outline, which
might help if you are trying to write a new termcap entry for a
new terminal, but if you are trying to write a new _p_r_o_g_r_a_m which
is supposed to deal correctly with all 2,574 termcap entries
already in there, forget it.
termcap should really be called vicap (or maybe cursescap).
termcap and vi are married to each other; curses may get it
mostly right, but for any other software package (including
more, which is probably #3), all bets are off.
Steve Summit
stevesu@copper.tek.com