jhs@MITRE-BEDFORD.ARPA (03/29/88)
Harlan Wolper asks: > Does anyone know if there is any software available > for the 8-bit Atari to emulate a VT100 type terminal? > Or any other type of standard terminals for that > matter? If so, where can these be obtained? As long-term readers of these postings are well aware, there are several. The two most popular, so far as I know, are kermit65 and OmniCom. kermit65 is Public Domain, and includes not only true 80-column vt100 emulation but plain 40-column Atari emulation and an 80-column "scrolling" mode that displays only half of the 80-column screen at one time. This program does kermit file transfer but does not currently support key macro definitions or keypad emulation. The other game in town is OmniCom, which is a "shareware" product, i.e., you are asked to send in $10 for an "official" disk and documentation if you decide to continue using the program after seeing what it does. I've been using OmniCom for over a year now and find it the best solution for my needs, because it DOES support keypad emulation and key macro definition, and because it has xmodem and plain ASCII capture and "Print Screen" functions, all of which I find extremely useful. With OmniCom, the only significant difference between logging in from my 800XL at home and the "real" vt103 at work is the 1200 baud line speed. And of course the ability to store and retrieve files and do local processing on the 800XL. With either of these programs, you should use a monochrome monitor if at all possible, because 80-column emulation on an 8-bit Atari pushes the graphics resolution to the limit. Next best would be a composite monitor that has a separate chroma input, or an RGB monitor with an external NTSC decoder (or just drive the Green input with the Atari luminance signal). Finally, if you HAVE to, you can use some monochrome TV sets with acceptable results. If you have the capability of downloading a file to your Atari, I can e-mail you a copy of either emulator in uuencoded form. If you need a disk, you might as well mail in your $10 to C. David Young, 421 Hanbee, Richardson TX 75080. -John Sangster / jhs@mitre-bedford.arpa
swklassen@trillium.waterloo.edu (Steven W. Klassen) (03/30/88)
In article <8803290303.AA02847@mitre-bedford.ARPA> jhs@MITRE-BEDFORD.ARPA writes: >This program [kermit65] does >kermit file transfer but does not currently support key macro definitions >or keypad emulation. > Forgive me if I'm wrong but doesn't the latest version of kermit65 (the version just posted awhile ago) support keypad emulation? Steven Klassen Computer Science Major University of Waterloo
cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (03/31/88)
In article <8803290303.AA02847@mitre-bedford.ARPA>, jhs@MITRE-BEDFORD.ARPA writes: > Harlan Wolper asks: > > Does anyone know if there is any software available > > for the 8-bit Atari to emulate a VT100 type terminal? [line-eater tells me to delete more... so I am... ] > The two most popular, so far as I know, are kermit65 and OmniCom. kermit65 > is Public Domain, and ... [ excess verbiage (sic) deleted... ] > This program does > kermit file transfer but does not currently support key macro definitions > or keypad emulation. ^^^^^^^^^^^^^^^^^^^ John, you're mistaken. Kermit65 DOES support a VERY GOOD keypad emulation. The mapping of functions to keycaps (all SHIFT-CONTROL combinations) is quite logical and consistent, and I am able to use it just as fast as a "real" VT100- and I'm a FAST typist. > The other game in town is OmniCom, which is a "shareware" product... [ more verbiage deleted for vnews' sake] > I've been using OmniCom for over a year now and find it the best solution > for my needs, because it DOES support keypad emulation and key macro > definition, and because it has xmodem and plain ASCII capture and "Print > Screen" functions, all of which I find extremely useful. With OmniCom, the I second the motion that having all the different file-transfer protocols in one program is a great thing! It's quite a pain to log onto a BBS or whatever with Kermit (my fave 'terminal emulator') and then have to switch to 850 Ex- press! to perform an XMODEM transfer! However, I found that OmniCom's PRINT SCREEN function (an option that can be turned ON or OFF to "print all incoming data," as I distinctly remember it) was unsatisfactory, because it wasn't able to do anything effective with the escape sequences typically sent to a VT100 for screen and cursor control. Even "stripping out" the escape sequences would be better than PRINTING them, but not even THAT is done. I found it completely impossible to print a data- base form-entry screen, once screen-painting was completed. Did I miss a feature that lets you print an image of an EXISTING DISPLAY? [ more deletions for the sake of the line counter ] > With either of these programs, you should use a monochrome monitor if at all > possible, because 80-column emulation on an 8-bit Atari pushes the graphics > resolution to the limit. Next best would be a composite monitor that has a > separate chroma input, or an RGB monitor with an external NTSC decoder > (or just drive the Green input with the Atari luminance signal). Finally, if > you HAVE to, you can use some monochrome TV sets with acceptable results. I've gotten readable 80-column results on a standard color TV; you have to turn the contrast way DOWN, and the brightness way UP, though. [ John Sangster's closing comments deleted; sorry John, the line-counter made me do it! ] Chris Chiesa -- UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP
njd@ihlpm.ATT.COM (DiMasi) (04/01/88)
> .... > However, I found that OmniCom's PRINT SCREEN function (an option that can be > turned ON or OFF to "print all incoming data," as I distinctly remember it) > was unsatisfactory, because it wasn't able to do anything effective with the > escape sequences typically sent to a VT100 for screen and cursor control. > Even "stripping out" the escape sequences would be better than PRINTING them, > but not even THAT is done. I found it completely impossible to print a data- > base form-entry screen, once screen-painting was completed. Did I miss a > feature that lets you print an image of an EXISTING DISPLAY? > .... I think you have the Capture and Print-screen features mixed up. Print screen (I forget the key combination! I think it's [SELECT][OPTION]) dumps, to the P: device, whatever is on the screen. Capture mode puts a copy of all incoming characters (or at least most of them) to a user-specified device. Print screen works fine for me, but not Capture. I think I'm on to a BIG clue, though - when I tried capture to a D: file instead of to P:, many of the characters were inverse video when I looked at the file. Hmm, 8th bit flipping around, eh? Parity? I have to make parity=none to get xmodem (binary files) to work, so I wonder what's going on. Nick DiMasi Uni'q Digital Technologies (Fox Valley Software subsidiary; ^ working as a contractor at AT&T Bell Labs in Naperville, IL) ( | this is an accent mark, supposed to replace the dot over the 'i')