Cterm: ------ Cterm is a vt100 emulator written entirely in Turbo C. It is currently equipped to run on the TI Professional or the IBM PC/AT (monochrome). Making cterm: E:> mkdir cterm (it's best to put cterm code in a directory by itself or at least make sure that there are no other .c or .obj files in the directory. If that's not convenient, then the makefile will need overhauling) E:> <edit the -L and -I path(s) in turboc.cfg> E:> <edit makefile to select target machine (ie. SYS= TI? PC?) > < if SYS=PC then select a video adapter (ie. VID= CGA? HGC?...) > (If you're using Turbo C 2.0 then read Install.TC2) E:> make all Make version ... etc, etc. Turbo C ... etc, etc. E:> cterm (that *should* be all that's needed to get it running, but you never know :-) Quitting cterm: *** To quit cterm *** use <SHIFT>-BRK/PAUS (on the PC use Ctrl-Break/ScrllLck) If <SHIFT>-BRK/PAUS doesn't work, cterm probably hung itself (sorry about that). Some random notes: ================== "F1" is the SETUP key (ie. you use it to move to and from the setup screens). The setup screens are the same as a VT100's but with added features. As usual, hitting '5' will cycle you through the 3 setup screens. The left/right arrow keys, space bar, tab, backspace or return key can be used to move back and forth once you're in a setup screen. Read "Setups" for more details on the interactive setups. Read "Keyboard" for details about the functions keys and the keypad map. Read "Graphics" for a summary of the home-brew graphics escape sequences. Look in the demo directory for some host-based programs which will demonstrate some possible uses of the home-brew graphics commands. Source files: ------------- main.c - misc startup and system-related routines cterm.c - the main loop (the "guts" of the terminal). esc.c - the escape sequence interpreters (the "guts" of vt100-ness). This was part of cterm.c but became large enough to rate its own file. A majority of the mode flags (m_...) are declared and used here. misc.c - misc vt100 keycodes and strings (this also used to be in cterm.c) setup.c - handles the interactive setup screens. defs.c - routines to read/write startup definitions from/to cterm.ini. cterm.ini - default startup values (layout is similar to the setups). xample.ini - a sample cterm.ini file with comments. gfx.c - parse & execute graphics commands punted from esc.c gfx_m.c - some less simple graphics routines extracted from MGR. text.c - raw text transfer routines (send or capture)(kinda kludgey) printer.c - dummy printer handling routines. cterm.h - #defines used almost everywhere ti.h - TI Pro-specific #defines pc.h - IBM PC-specific #defines kermit.c - ancient C-kermit from usenet (version 1, I think) xmodem.c - version 1.0 UNIX-CP/M xmodem from usenet. types.h - imitation <types.h> file to satisfy xmodem.c and kermit.c (Turbo C 1.0 didn't have a standard types.h) ports.ti - serial IO handling done here. Uses TurboC's inport/outport functions to work "directly" with the TI Pro's Z8530 or the PC's INS8250A serial communications chip. Input is interrupt-driven and buffered using TurboC's special interrupt function-type. Buffer overflow checking is optional. Output is sent ASAP. keybrd.ti - TI keyboard reading, mapping and interrupt handling. screen.ti - TI screen handling (lots of int86() calls :-). ports.pc - PC serial IO handling. This is an almost direct translation of Qkermit's Turbo Pascal code. keybrd.pc - PC keyboard handling (direct handling or via BIOS) screen.pc - PC screen handling (some scribbling directly on video memory) Some supported vt102 features: ------------------------------ - local mode (for testing without having to connect to anything) - echoing (for half duplex connections) - screen saver (blanks screen after approx 15 mins. of inactivity) - transparency mode (show invisible characters (eg. ascii 7 shows up as "^G", linefeed becomes "^J", ascii 18 becomes "^R", etc.)). - load or save setups from a file (default is \cterm.ini or, with DOS >= 3.0, cterm.ini is in the same directory as cterm.exe). Some unsupported vt102 features: -------------------------------- reverse background, 132 columns, double-wide or double-height letters, printer "flow-through" For other unsupported features see the comments in 'xample.ini'. Or try toggling the related bit in the appropriate setup screen ... if the bit won't change then it's not supported (ie. it's "hardwired"). Some added features: -------------------- - primitive ANSI-like graphics support - shell escapes via '!' - primitive kermit, xmodem or raw text transfers - Meta-codes via the ALT key - save screen text to file Background: ----------- Cterm is a Frankenstein-type program ... ie. it's made up with chunks of code from here, other bits from there and some original code to fill in the gaps. Fortunately Turbo C provided all the facilities to put it together without having to resort to using (ie. learning to use) an assembler. Operational overview: --------------------- On startup, cterm attempts to locate and read a file called cterm.ini which contains the user's preferred startup parameters (cterm will try a number of pathnames before defaulting to the compiled-in values). With DOS 3.0 or greater, cterm will first check to see if cterm.ini is located in the directory containing the cterm.exe being executed. If an init file still hasn't been located, it then tries a standard default pathname (see #define FINIT) before it gives up and continues with just the default parameter values. The "devices" (ie. the operating modes and the function pointers for keyboard, comm ports and screen) are then initialized and the main loop begins. The main loop continually polls the keyboard and the comm buffer. If there is key data, the key buffer will be emptied. If there is comm data only one byte will be processed so that the keyboard can be polled again thus preventing a situation where user-generated keystrokes might be ignored. Regular ASCII user-keys are sent out as quickly as possible while function keys and special keycodes are processed primarily through lookup tables. Incoming comm data is buffered until it can be processed by the main loop. Buffer overflow checking is optional. XON/XOFF is used for flow control. Incoming ASCII data is either "burped" or processed via one of the escape sequence handlers (ie. ansi() or vt52()). Since the graphics sequences are meant to be ANSI-like, they are only recognized when cterm is in ANSI mode. A lot of features depend on interrupts and their service routines. The comm ports are initialized so that each incoming byte causes an interrupt which is serviced by port_isr() which in turn buffers the new byte. The keyboard ISRs are used to flag new keys and handle special keys (on the TI, mostly). The timer ISR is used to handle timeouts for kermit, xmodem and screen saving. When cterm shuts down, it replaces all its own ISRs with the ones it found on startup to prevent any problems when the user is returned to DOS. Caveat: ------ Cterm's transition points are not very "clean" (ie. startup, shutdown, moving to/from setups, and on PCs, moving to/from graphics mode). They could benefit from some standardization but since features are still being modified and since transition code is usually tougher to deal with these points are the last to get any attention. :-) Credits: -------- The content of esc.c was inspired by Qkermit which was written in Turbo Pascal by Victor Lee at Queen's University in Kingston, Ont. The Z8530 serial port init tables and serial port interface methods came in large part from MSXTIP.ASM by Dan Smith and Joe Smith at the Colorado School of Mines. Both Qkermit and MSXTIP.ASM were obtained from the KERMSRV@CUVMA.bitnet server. A couple of the more involved graphics drawing functions were copied out of src/graph_subs.c from BellCore's MGR by Stephen Uhler which had been posted to the comp.sources.unix newsgroup. Antique versions of kermit.c and xmodem.c, obtained from net.sources and mod.sources, respectively, were used mainly because they were small (ie. 1 file each) and simple which made it relatively easy to "plug" them into the existing cterm code. The Zilog Z8530 product specification helped to expand on the serial port information obtained by studying MSXTIP.ASM. The TI Pro Technical Reference Manual pretty well covered everything else as did the original IBM PC Technical Reference Manual and the _Programmer's guide to the IBM PC_ by Peter Norton. The vttest program by Per Lindberg was used for testing and adjustments. Turbo C 1.0 and 2.0 are, of course, products of Borland International, Inc. Thanks to Ed Ferguson <ferguson@m2.csc.ti.com> for objectively testing cterm's alpha version (0.8) and its numerous followups, for suggesting and testing the "ALT as Meta" feature, and for providing valuable hints and directions. Thanks to Jim Hayes for writing and distributing DCOM 3.3. Without it my Apple //e would have just been another lump on my desk at home. DCOM has nothing to do with cterm but I just thought I should mention it. The TI Professional Computer on which this all began used to be a product of Texas Instruments. And a very capable one, too. It's much better than an IBM PC and even with its 8088 it can give PC/ATs a run for the money. It's a shame TI didn't or couldn't give it the marketing it needed to make it a truly viable alternative to the PC. The Lanpar XT-100 PLUS that I used as a reference vt100 was manufactured by Lanpar Ltd. of Markham, Ontario. The xt100+ is no longer in production but there are still hundreds of them being used around here. They were (and still are) solid vt102 clones. Lanpar also made a solid vt220 clone called the Vision II. Just a while ago Lanpar was placed in receivership. "So it goes." And finally ... --------------- Cterm is Copyright (c) 1989 by the University of Toronto. All rights reserved. Anyone may use or copy this software, except that it may not be sold for profit, that this copyright notice remain intact, and that credit is given where it is due. The University of Toronto and the author make no warranty and accept no liability for this program. Some of the software used to make up Cterm is public domain or was extracted from other software. The files containing such software bear no copyright if none existed or retain the original author's copyright notice. ---- If there are any problems or if something hasn't been covered, please don't hesitate to contact me. Paul Kern (416) 978-6946 pkern@utgpu.uucp pkern@gpu.utcs.toronto.edu pkern@gpu.utcs.utoronto.ca ..!uunet!utai!utgpu!pkern ..!attcan!utzoo!utgpu!pkern