KM_Term - A Terminal Program for the Atari ST ============================================= (c)K Millican 1992 20 St Johns Road Belton GREAT YARMOUTH Norfolk NR31 9NS ======================= v1.81 - 21 January 1992 ======================= NB: New features over 1.63 are highlighted in the text or mentioned separately in section 13. 1.0 Introduction 1.1 KM_Term is a VT52, VT100, & ANSI terminal emulator for the Atari ST range of microcomputers. 1.2 It was coded in Hisoft Power BASIC with a splash of assembly language here and there. 1.3 KM_Term will operate in Hires 640 x 400 or Medium res 640 x 200 screen modes; it has been tested on TOS 1.2, 1.4, and 1.6 (STE) and should operate happily on systems with as little as 512KB of memory. 1.4 This software has a number of features of which probably none can be described as unique, but which together make a powerful and complete system that can be easily customised for your particular needs. 1.5 Conventions Used 1.5.1 Because registered users receive a copy of the source code I may refer to some functions by their source-code names; this may be useful if you ever wish to tinker with the source code or are unsure why something doesn't quite function the way you expect. When I enclose a name in {curly brackets} I am referring to a FN, a named SUB or a GOSUB label. 1.5.2 User keypress combinations are highlighted e.g. 1.5.3 Named single characters or ASCII codes are enclosed in square brackets e.g. [CR] means a carriage return code and is identical to [dec13] or [hex0D] 2.0 History 2.1 I started using comms for BBS work in the beginning of 1992. My first dabbles with going on-line were conducted using VANTERM, UNITERM and after a while DTERM and finally FzDz. 2.2 I found problems with all the above, despite the fact that in many ways they are fine pieces of software that have obviously been carefully coded. I won't mention the problems (sometimes bugs) I had with these programs in detail with the exception of FzDz, because in a way this program is the reason I began writing KM_Term :- 2.3 Having tussled with many comms programs, I discovered the demo version of FzDz on a magazine cover disk. At first sight it seemed to be the ultimate answer to my needs, but after a while I began to realise that I would never be totally happy working with it. 2.4 I identified with the authors comments that `he wrote FzDz because the best just wasn't good enough'. I saw the tremendous effort that had been expended on the software, and thought it could have every feature that I could possibly want, but still there was something missing. Maybe I would have stuck with it if I had been a colour user instead of the owner of an SM124 (I'm sure that despite what the author said, he would have eventually got round to improving the mono display), ... but no, in the end I doubt it. 2.5 The problem wasn't the software; it was me:- I just didn't feel comfortable with the work style that the author envisaged, or the obscure text editor; however good it was, it just couldn't compete with Tempus 2 (my favourite) for speed, power and ease of use. There was also just too much going on in the various control panels etc. True, the author had thought of just about everything you could ever need, but in providing everything, much of the simple elegance of lesser programs such as DTerm had been lost. 2.6 I've come to the conclusion that the reason I couldn't get on with `the best' is not really because on any particular failing on the part of FzDz but because using comms software is a more personal activity than many others on my ST. It's a bit like organising folders on a disk really - everyone comes up with a way that suits them best. 2.7 So if the system I've come up with doesn't suit you in the way it suits me then I'm sorry but I'm not all that surprised; eventually you will find something that you are most comfortable with. It's partly because of this that I'm not disabling some of the better features until people have registered.; I want you to feel at least comfortable with KM_Term before you feel obliged to register (but of course it's only natural that I wish my registered users to receive the benefits of the latest revisions first). 2.8 It's also because of this recognition of the personal nature of using comms software that I have taken the unusual step of releasing the source code to registered users. If there is something that doesn't quite function the way you want it to you can change it if you have either Power or Hisoft BASIC. However I don't want to see vast numbers of KM_Term look-alikes floating around the PD libraries or BBS systems so I'll make this agreement with you :- You can alter the source code and re-compile the program for your own requirements provided that you do not release it in any form without my agreement in writing. If you feel your modifications are valuable to other users then I will give you a release version number that is unique and a format for adding to the documentation that makes it clear that the major part of the source code belongs to me. If anyone registers your release version with me I will forward an agreed percentage to you. However if I feel anyone is infringing my rights on my work by marketing KM_Term in any way I will take legal action to protect those rights (in summary: you treat me fairly and I'll do the same for you !) 3.0 Features 3.1 KM_Term has many special features too numerous to list here, but it is useful to provide an outline of the specification :- * Full VT52 emulation (as provided by the built-in Atari routines). * Partial VT100/ANSI terminal emulation. Any unrecognised codes don't mess up the display; they are just displayed in the top left corner of the screen. * Operates in Medium or High resolution. * Simple-to-use autologon sequence that is `recorded' whilst using KM_Term (or can be edited with a standard text editor) * Logs calls and charges on British Telecom b,b1,a, & L call rates. * Logs calls and charges on Mercury zones 1,2,3, & 4 (I've called them m1,m2,m3,& m4) * On-screen help including call duration and charge. * Supports XYZ.TTP external file transfer protocol (this should be registered separately; it is not part of KM_Term). * Supports JEKYLL.TTP external file transfer protocol (this should be registered separately; it is not part of KM_Term). * Supports direct access to your favourite text editor; Tempus is recommended but many other editors can be used according to your preference. * Loads IBM style fonts at startup. In mono, up to three can be loaded to provide VT100/ANSI style changes (colour changes are effected on colour monitors). Suitable fonts are included. * 8 Macro keys. * 10 quick autodial slots. * 10 configurable program slots mainly used for running other external file transfer protocols, QWK mail editors, or other comms utilities from within KM_Term. * Access to GEM accessories [New for v 1.8#] * Fully sizeable capture buffer that ignores escape and ANSI sequences so that the buffer can be loaded directly into your text editor. * Easy access to Mercury - autodial slots contain the information required to determine whether call is made via BT or Mercury and costed accordingly. * Upload an ASCII text file directly into a BBS line editor. * Will operate as a mini-BBS system when someone else calls your system (and the modem is set up for auto-answer). 4.0 The Terminal Display 4.1 When you start KM_Term, you are greeted with a blank screen and flashing cursor. Once you've recovered from this mind-blowing experience (!) carry on... 4.2 Pressing displays a menu showing the available key combinations that control KM_Term from the terminal - {GOSUB hlptxt}. Some of these functions can also be activated from the control panel. 4.2.1 The current RS232 settings, capture buffer status, and, - if you have started a call - the duration and charge will also be displayed here. 4.2.2 The terminal screen colours can be edited by pressing the appropriate colour key (1-3 or b) if you are in medium res. 4.2.3 Pressing a mouse button or a key on the keyboard will return you to the terminal. In theory any key can be used, but during a call the shift keys work much better (and there's no risk of the keyboard repeat entering unwanted characters down the line). 4.3 Pressing the and holding it displays the mouse pointer. Releasing it then positions the VT52 cursor at the mouse pointer position. 4.4 Pressing the calls up the main control panel - {GOSUB gembit}. 4.5 A full 25 line display is used by KM_Term. However there are many times when the program needs to advise you of what it is doing because changes are not readily apparent otherwise. 4.5.1 A subroutine is used for this information line - {SUB showmod}. If the BBS display overwrites this line it will not be restored until a new routine is used that displays information. 4.5.2 This has the benefit of a full-size display with the very minor cost that the top line of the display could be lost when some functions are used. In practice I have never found this to be a limitation since nothing useful on screen menus ever starts on the top line. 4.6 Most functions can be selected by an combination from the terminal screen - {GOSUB keyin}. The options are listed below :- Sends the escape command string (Hayes +++) twice and then the hangup modem string to the modem and logs the call. Manual modem users should define both (C)ommand & (H)angup as empty strings and use this after terminating a call to ensure that it is logged. Automatic (Hayes) modem users need only use this call where a BBS appears to crash without disconnecting. By default this string is `ATH0' but other methods exist to terminate the call if desired - {GOSUB hangup}. [v1.73 : The exact sequence has been changed slightly to tidy up the screen display - only one escape sequence is sent with a slightly different interval - seems to work even better though] Calls the external file transfer protocol (by default XYZ.TTP) to download a file - {GOSUB transfer}. The last-used settings are displayed in alert boxes as the defaults but these can be changed either by using the alert boxes or by altering the presets on the control panel. Calls the external file transfer protocol as above but allows the user to select a file for upload - {GOSUB transfer}. Calls the external file transfer protocol as above but asks the user whether they require upload or download (only included for compatibility with some other terminal programs) - {GOSUB transfer}. Calls an external file transfer protocol that doesn't require parameters - {GOSUB jekyll}. This is set up by default (and originally intended) for use with JEKYLL.TTP. Jekyll is the ultimate file transfer protocol for ST users since it allows simultaneous upload & download at ZModem speeds, and allows you to chat to the BBS sysop all at the same time. You can even access the BBS directories directly and the other end can request files from your drive as well (if host mode is switched on). Allows the user to select an ASCII text file for upload into a BBS line editor - {GOSUB ascii}. It's up to the user to ensure that the line lengths are correct but the utility will strip any linefeed codes out and send a space character ([dec32]) followed by [CR] for any empty lines. This will work well with just about any BBS line or ANSI editor - even at slow speeds. Displays the standard fileselector to allow the user to save the current capture buffer to disk - {GOSUB savebuf}. Unlike many terminal programs, KM_Term strips out any VT52 or ANSI escape codes to allow the file to be directly loaded into a text editor. The capture buffer is cleared after saving. Changes the Baud rate - {GOSUB baud}. Changes the RS232 Handshake protocol to NONE, XON/XOFF or RTS/CTS - {GOSUB handshake}. There are no special RS232 routines in KM_Term so you may need a software patch to use RTS/CTS with high speed modems. Runs the user-defined text editor - {GOSUB editor}. This is different from selecting the editor from the control panel in that it passes the name of the last-saved capture buffer as parameters to the text editor. If the text editor handles parameters properly (most do), then the editor will be loaded complete with the last-saved capture buffer ready for editing. Toggles the capture buffer ON or OFF. I don't really know why anyone would want to run without a capture buffer switched ON, but this is included for the odd time when you think this might be necessary (users of machines tight on memory with small capture buffers maybe). NB. Turning the capture buffer OFF prevents normal functioning of the automatic call-logging and autologon facilities, because both functions check the status of the last 10 characters in the buffer every 0.2 seconds. Toggles standard VT52 wrap ON or wrap OFF. Displays the fileselector and allows the user to select a program to run from within KM_Term - {GOSUB prgrn}. Displays the fileselector and allows the user to run a previously- recorded autologon file - {GOSUB start_autologon}. The default directory for this, is a folder called `\LOGON\' which should be in the same folder as KM_Term was run from. [NEW feature for 1.70 onwards] Sends the next character you type and then goes into raw ASCII capture mode - no screen display but will capture anything coming down the RS232 port at high speed even without RTS/CTS in most cases. I use this for capturing crude output from some laboratory equipment at high speed or capturing VT52 or ANSI codes for testing. returns you to standard mode. [New feature for 1.80 onwards] Allows access to GEM accessories - at present you must close these down before returning to the terminal. These are the macro keys which can hold any text strings you normally use frequently (e.g. your name, password(s), `Hello', or even certain modem setup strings). I've only included 8 because I can only remember about 4 ! If anyone thinks this is particularly stingy and can remember more than 8 then let me know and I'll add some more ! This key is a leftover from early development on a 1200/75 modem - {SUB sortit}. Under certain obscure conditions I found out the RS232 buffers can get confused when V23EMU.TOS has been used to provide a split baud rate on the ST. The problem occurs when you've been using V23 (1200/75) and then switch back to V21 (300/300); some characters are not returned from the BBS but they stay in the buffer so that as you press e.g. the key the lost characters appear (ie. you're not sending the correct characters to the BBS). The key resets the buffers to provide (probably temporary) relief from this. Displays the status of the RS232 input & output buffers - {GOSUB bufferstat}. Used to effect foreground & background colours temporarily in medium res - {GOSUB vt52col}. In mono 1-3 temporarily set the screen fonts, 4 & 5 set inverse & normal text, and 6 inverts the screen (pallette change) to white-on-black or vice versa - {GOSUB vt52mono}. This last setting is important because it is permanent, i.e. it can be saved using the `SAVE CONFIG' option. Initiates the `RECORD AUTOLOGON' sequence - {GOSUB record}. The fileselector is displayed so that the autologon file can be named. From this point onwards, all characters passed to the BBS are recorded in the file. Ends the `RECORD AUTOLOGON' sequence - {GOSUB record}. Records (Registers) the last ten characters from the BBS in the currently recorded autologon sequence file - {GOSUB record}. is normally pressed by the user at each point where the BBS pauses to wait for an input from the user. Inserts the active RS232 settings in the currently recorded autologon sequence file. This is normally pressed immediately after initiating the record sequence prior to autodialling when it is desired to use specific RS232 settings on playback. Toggles `HOST' mode on or off. Leaves the terminal (via alert box confirmation). 5.0 The Control Panel 5.1 The control panel is toggled with the - {GOSUB gembit}. This panel allows the user to set the RS232 settings, default upload/download options, and use some of the menu utilities that may or may not be available directly from the terminal screen. 5.2 All selections are made with the - {GOSUB decode}. Some features will return you to the terminal after selection, whilst others will not. You can return to the terminal at any time by pressing the or clicking on the close box at the top left of the control panel screen. 5.3 Most of the features are self-explanatory but some require a little more discussion as follows :- 5.4 The Autodialler (AUTODIAL) 5.4.1 There are ten user-definable autodial slots - {GOSUB autodial}. Users might be wondering why I've only included ten; well once you start to use the autologon facility, you'll probably only use this when recording an autologon sequence or as a quickdial facility. 5.4.2 To dial a number, just click on a highlighted number with the . 5.4.3 To define a number, press the number (0-9) on the main keyboard and edit it {FNedit$} using the following format :- ############# : ************************** @$$ where; ############# is the BT telephone number. ************** is the name of the BBS $$ is the call rate (a,b,b1,L,m1,m2,m3, or m4) The number of characters is not significant; everything up to the colon (:) is the number that is dialed and everything after is the BBS identification. (I also tend to put the BBS Fidonet number in here as a reminder). The call rate indicator must be the last thing on the line however, and this is essential for correct call logging. NB: YOU MUST CARRY OUT THIS OPERATION EVEN IF YOU ARE USING A MANUAL MODEM (AND YOU WISH KM_TERM TO LOG CALLS AND CHARGES) 5.4.4 There are also a couple of other variables that can be altered from this menu by pressing the character in brackets :- (P)refix Is the dial prefix sent to the modem before the number (For Hayes-compatibles `ATDP' for pulse or `ATDT' for tone). (C)ommand Is the sequence to be sent to the modem to select command mode (Hayes : `+++'). This is sent twice with a slight pause as per the Hayes standard but this should also work with non-Hayes modems. (H)angup Is the sequence to be sent after the command mode select in order to hangup the modem (Hayes : `ATH0'). (M)ercury Is the sequence sent after the prefix and before the BT telephone number if the autodial number contains the string :- `@m'. For Hayes-compatibles this is normally `131,,,ATDT##########' where `##########' is your Mercury access (PIN) code. The commas are a signal to your modem to pause for two seconds. According to Mercury you should dial 131 followed by a pause of five seconds followed by your PIN number, so you may find you can reduce this to two or maybe even one two-second delay. You should also ensure that you (or your other software) hasn't tampered with the time delay attributed to a comma. You will notice that once entered this number does not reappear on the display next time you select autodial. This is to ensure a measure of security but note that your PIN number will be saved in the KM_TERM.CFG configuration file. If you wish, you may of course save your Mercury number in the modem memory and use this variable to call on that particular memory instead. (D)ial Delay Is the number of seconds after initiating the autodial before KM_Term starts counting the call duration. You may wonder why I didn't relate the call start to the CONNECT **** signal sent back from the modem rather than the selection of the autodial number; well I found that the time taken to CONNECT to a BBS varies more than the time taken to dial and the BBS modem to answer the call - typically around 15-20 seconds. This is the best compromise to avoid overestimation or underestimation of the call duration (Nearly all BBS systems grossly underestimate the BT/Mercury call duration since they measure the connection time from the modem connection or logon completion). If you are using KM_Term with a manual modem you should set the delay to zero. [New for 1.80 onwards] if you specify a negative dial delay then KM_Term will not log the call when it receives a NO CARRIER message unless it has already received a CONNECT message. The value must be set to the typical time taken to CONNECT after the remote modem has answered the phone. This should help avoid logging phantom calls if your modem doesn't provide the BUSY message! (Some people may prefer this system anyway if their average answer-->CONNECT time is fairly constant). A good value for negative dialdelay is about -6. 5.4.5 You will have noticed by now that a BT (and/or Mercury) call area/charge list is useful. I wonder how many people never give any thought to whether a long distance call is charged at b or b1 rate on BT or m1/m2 on Mercury. It's well worth setting these correctly but as a guide :- most BT long distance calls are made @b (except calls to London which are invariably b1) and Mercury calls are normally @m1 unless the call is to a smaller town (@m2). There's quite a difference between BT b & b1 rates but less with Mercury m1 & m2. 5.4.6 You can exit back to the terminal by pressing the . 5.5 The Macro Key Editor (FUNCTION KEYS) - {GOSUB editfns} 5.5.1 To edit a macro key string, press the function key that you wish to edit and then edit the field using the key and new characters. Finally end the edit by pressing the key. 5.5.2 To use a macro key, just press the appropriate function key from the terminal screen. 5.6 The Automatic Program Run Slots (RUN PROGRAM) 5.6.1 When you select the `RUN PROGRAM' button from the control panel, you are presented with a number of slots that are used to describe up to ten external programs that you might wish to run from within KM_Term - {GOSUB autoruns}. You can also select and run a program that you don't wish to save into a slot. 5.6.2 Clicking on a highlighted slot with the will run the appropriate program associated with that slot. Any text in the description that follows a colon (:) will be passed to the program as a command line. 5.6.3 To edit a slot :- type the number of the slot on the main keyboard and edit it in a similar manner to the autodial slots or macro keys. 5.6.4 The descriptions and program (pathname+filename)s are saved when you use the `SAVE CONFIG' option from the control panel - {GOSUB saveconfig}. 5.6.5 This is one of the more powerful facilities of KM_Term. This allows access to all manner of useful utilities that can enhance your work session. A typical setup would include access to all your archiving software, additional external transfer protocols, text file viewers (perhaps with parameters for the call-log file or KM_Term documentation), and any software patches that you don't wish to run from an AUTO folder. 6.0 Program Configuration & the KM_TERM.CFG File 6.1 KM_Term is supplied and will run without its configuration file (KM_TERM.CFG). However it is intended that in normal use it will have access to one, so the first thing you should do on your initial session with KM_Term is set your favourite transfer protocol (Probably Zmodem or Ymodem), baud rate, and RS232 protocols (usually 8 bit, 1 stop, no handshake, full duplex for most BBS systems) and then use the `SAVE CONFIG' option from the control panel. 6.2 Most of the parameters in this file can be changed from within KM_Term but there are a few that can only be changed with a text editor directly. 6.3 This config file system is incredibly robust; The KM_Term defaults are all loaded from within the main program and then overwritten if the KM_TERM.CFG file happens to have that particular variable. This means that you can change any variable back to the default merely by deleting the line from within this file and re-running KM_TERM.PRG. 6.4 All lines in the config file start `##>' where ## is the variable identifier. Any other lines are ignored. 6.5 A typical file is shown below with REMarks (an asterisk [*] means that this variable can only be changed with a text editor) :- REM The function keys (macros) F1>Kevin Millican F2>Password F3>Hello F4>This is Kevin signing off now - thanks for chatting ...F8> REM The Autodial Strings D0>081 447 8244: Crystal Tower 2:440/25 @b1 D1>0225 840060 : Bath BBS @b D2>0603 507216 : StarNet 2:254/405 @a ...D9> REM The Autorun Program Descriptions A0> A1> A2>Archiving Shell ...A9> REM The Autorun Pathnames R0> R1> R2>E:\ARCS\ARCSHELL.PRG ...R9> REM The Parameters BU>-1 REM capture buffer ON (0=OFF) BS> 100000 REM buffer size in bytes BA> 4 REM baud rate (ST internal baud rate code numbers) HA> 0 REM handshake * ED>TEMPUS2.PRG REM pathname for text editor * XY>D:\XYZ\XYZ.TTP REM pathname for xyz.ttp * UP>D:\UPLOAD\ REM uploads path * DN>D:\DOWNLOAD\ REM downloads path * JE>D:\JEKYLL\JEKYLL.TTP REM pathname for Jekyll or other protocol PA>N REM parity SB>1 REM number of stop bits WD>8 REM word length (8 or 7 bits) DU>-1 REM full duplex (0=half) V2> 0 REM 1200 when set to 1200 (-1=1200/75) PR>z REM default xyz protocol (x,x1K,y,z) PF>ATDP REM dial prefix HU>ATH0 REM hangup string CO>+++ REM command mode string * C1>&h0 REM panel colour * C2>&h447 REM ditto * C3>&h115 REM ditto * C4>&h777 REM ditto C5> REM terminal colours ...C8> REM ditto BW>W REM black on white mode (B=inverse) * HF>HI_RES.FNT REM hires font1 (2 & 3 are fixed as HIRES2.FNT and HIRES3.FNT) * MF>MED_RES.FNT REM medium res screen font * LG>-1 REM call logging ON (0=OFF) * UN> 4.935 REM BT unit charge (incl. VAT) DD> 15 REM dial delay for call timing * M1>p12.46 s9.61 e4.25 REM Mercury rates @m1 (pence/min incl VAT) * M2>p12.93 s9.81 e4.64 REM ditto @m2 * M3>p11.40 s8.70 e2.88 REM ditto @m3 * M4>p11.63 s8.75 e2.94 REM ditto @m4 MY>131,,,ATDT ########## REM Mercury access number * T1>e220 s80 p57.5 REM time allowed on BT per unit @L (economy, standard, & peak) * T2>e80.8 s36.15 p27 REM ditto @a * T3>e37.95 s25.6 p19.2 REM ditto @b * T4>e50.35 s32 p23.95 REM ditto @b1 * RD>5 REM number of redials [New for 1.81] * IN> REM init string for modem on startup * TE> REM termination string for modem on exit 6.6 The 1200 & 1200/75 baud rates require a bit more explanation as follows:- 6.6.1 KM_Term does not directly support V23 (1200/75); to use it with this speed you will need to run a public domain program called V23EMU.TOS which patches the operating system. The reason why there is a V2> option in the KM_TERM.CFG file and a 1200/75 button on the control panel is to tell KM_Term to allow a bit longer for the return of characters when input at the keyboard. 6.6.2 The documentation of V23EMU.TOS indicates that this shouldn't be necessary, but then goes on to tell you not to type too fast ! In practice this can be a problem and hence the alternative selection. 6.6.3 The best place to run V23EMU.TOS is from a `RUN PROGRAM' autorun slot so that it's always there when you need it. 6.6.4 When I was using V23, I found that there were problems when I'd been using V23 and then switched to V21 (300/300) - particularly with xyz.ttp. I found it desirable to reboot before using it at 300/300 but I don't know whether this is peculiar to my system (TOS 1.4) or modem. Suffice to say the problem occurred with all terminal programs I tried with V23EMU.TOS. 6.7 The upload & download paths are designed to work with all xyz-style protocols even if they don't accept path parameters; when xyz.ttp is run it is run as a path-specific program and the default path is reset to that defined by UP> or DN>. It is therefore important to specify a path for XYZ.TTP. This is a significant change from versions 1.1 and 1.3 which expected XYZ.TTP to be in the same directory as KM_TERM.PRG and downloads to be directed to this area. 6.8 To get the most out of KM_Term it is important to give careful consideration to the location of utilities and data files. A typical directory structure is shown below :- \KM_TERM\컴컴컴컴컴컴컴컴컴컴컫컴�\UPLOAD\ � � � � � � � � KM_TERM.PRG � KM_TERM.CFG 쳐컴\DOWNLOAD\ TEMPUS.PRG (or other � � text editor) � � XYZ.TTP � � 쳐컴\JEKYLL\ � � � � � JEKYLL.TTP � <+ all JEKYLL system files> � 쳐컴\LOGON\ � � � � � � 읕컴\ARCS\ � � Apart from the requirement to have a `\LOGON\' directory within the same directory as KM_TERM.PRG, the above diagram is only a suggestion; there are many other different arrangements that are as good (e.g. you may find it advantageous to have a separate directory for your text editor, protocols such as XYZ.TTP or other utilities). 7.0 VT100/ANSI Emulation 7.1 There is a lot of confusion as to what ANSI emulation actually means; I've used terminal programs that claim to be ANSI-compatible because they load an IBM font ! 7.2 VT100 & ANSI codes from a BBS are [ESC] sequences followed by an open square bracket, followed by one or more numerical parameters, followed by a letter to indicate the type of action required. 7.3 If you log on to a BBS that runs ANSI codes with a VT52 or ASCII terminal emulator you will find that the menus are covered in little sequences such as [33m, [0m, [K etc. KM_Term intercepts all of these codes and converts most of them to the equivalent VT52 sequence. Any that aren't specifically recognised are displayed in the top left corner of the terminal display - {SUB showmod}. 7.4 In medium res, colour attribute codes are converted to select one of the four VT52 colours displayed by the ST. In mono the same codes select one of the three fonts loaded and reverse or normal text. It's a little bit arbitrary but the effect looks good. 7.5 You might wonder why I haven't aimed at a full ANSI emulation. The reason for this is that (a.) the ST is not capable of displaying more than 4 colours per scan line in medium res anyway (without sacrificing a great deal of it's speed), and (b.) the overall effect is not worth the massive increase in program size that would be required - it looks quite pretty enough already. In addition, I wanted KM_Term to run on any BBS with minimum specific configuration. To fully implement ANSI would necessitate switching off VT52 ie. have an ANSI or VT52 button. The aim of the partial VT100/ANSI emulations is to maximise the display quality and minimise the hassle & program size. In future releases I will tinker with the emulation but I doubt if KM_Term will ever emulate ANSI as completely as some dedicated ANSI terminal programs. 7.6 You will find that nearly all ANSI menus look fine and many ANSI animations work correctly. ANSI editors work up to a point but don't allow you to move up or down with the cursor keys (they do work with combinations however). I would improve this last feature if it weren't for the fact that it's still quicker to edit files using your favourite editor and upload the text using the command into the BBS editor. If anyone finds that the level of emulation is not sufficient for their needs then let me know and I will improve this area more rapidly. However if your motivation is merely that you want to be able to run all ANSI animations, then just keep taking the tablets - sooner or later you'll realise how pointless these really are ! 7.7 You may notice that some BBSs pause with an `ANSI:6n' code highlighted by {SUB showmod} in the top left of the screen. This is a request for the cursor location. I don't know a legal way to find out the position of the ST's VT52 cursor (which IS different to the standard output cursor); if someone does, then please let me know and I will make KM_Term respond to this request in a later version. 8.0 Some Comments on the Program Design 8.1 Many terminal programs make claims to use their `own RS232 routines'. At first sight this appears to be an attractive improvement but I will always stay clear of this approach in the development of KM_Term. In order to make KM_Term as compatible as possible with all ST variants, I have left it up to the user to make use of any software patches necessary to make their RS232 port function as desired. If I were to attempt e.g. RTS/CTS correction from within KM_Term this would be difficult to ensure that it worked on all systems (past & future). You only have to look at the number of serial port patch programs available for the different TOS versions to realise that this is true ! Similarly, if your serial port requires a software patch to perform the way you wish with KM_Term then you will invariably need this patch to remain operative with other utilities or file protocols such as XYZ. TTP. 8.2 It is my intention that KM_Term will never grow to be a monstrous memory-hungry program that `requires 1MB minimum' - if you have extra memory then it should be available to you for extra utilities, RAM disks, JEKYLL etc. I intend to keep the clean screen approach and hide much of the programs power beneath the surface, rather than advertising it by having masses of complex dialogue boxes, option screens, buttons etc. Much of the inspiration behind KM_Term was the excellent DTerm program which is still a favourite amongst some comms users, despite the availability of the technically-advanced FzDz. 8.3 KM_Term is unlikely to have built-in file transfer protocols; you would have to go some way to improve on JEKYLL.TTP or XYZ.TTP . KM_Term is more than just a terminal program - it is intended to be a shell for linking your text editor, file transfer protocols, QWK mailers, Archivers, & other comms utilities together into a coherent system. If you don't use it in this way then you will miss out on the power behind the program. 9.0 New to Comms ? 9.1 If you are a relative newcomer to communications then I have prepared a few tips to ease you in:- 9.2 Setups : Very few BBS systems require RS232 settings that differ from the following; Full Duplex (The BBS will send characters back to you when necessary so that you can see what you are typing - half duplex is normally only required for person-to-person communications) 8 Bit Words (Some BBS systems recommend 7 bits but these normally highlight this when you connect.) 1 Stop Bit No Parity No Handshaking (If you are using 300-2400 baud) RTS/CTS (If you are using high speed modems or error correction such as MNP#. To use this handshaking it will be necessary to use a patch program with most versions of TOS) The baud rate should normally be the fastest supported by your modem. If you are using a V21/V23 modem then use 300/300 (V21) if you are going to upload anything or 1200/75 (V23) if you are downloading or looking around a BBS. NB: Don't forget that you still need to use V23EMU.TOS if you wish to use KM_Term with V23 (1200/75) speeds. 9.3 Read and answer your mail off-line. However fast (or slow) your modem is , your activity on a BBS is what takes up most of the time (read 쐺쐓 !). When you feel competent, then install and use a QWK-mailer as much as you can. To begin with, however, read your mail on-line and then type after logging off from a BBS to save the capture buffer. Then type to edit replies to any read mail and save these with new filenames that allow you to locate them easily next time you logon to that BBS. Next time you logon go to the `write message' facility (or whatever it is called) start a message - eg. `Reply to message...' - then use the command to upload the text file directly into the line editor of the BBS and save it using the appropriate BBS command. When uploading text directly into a line editor you should allow KM_Term to strip the linefeeds. One other point ... when you edit a reply it is best to set the maximum line length to 70 or less to ensure that each line fits into the BBS editor. Also bear in mind that many BBS line editors have a maximum number of lines that you can use. 10.0 License Conditions & Disclaimer 10.1 KM_Term is shareware; you are free to copy the program to your friends, PD libraries, BBS systems provided that you include all the original documentation and do not tamper with it in any way. This does not include the source code which is only available to registered users. It does not include any beta-test versions that I have given you to try out either (I don't wish undebugged versions to be widely available for obvious reasons). 10.2 You may use KM_Term for 1 calendar month to evaluate it's functions and whether it meets your requirements. After this time you must register if you wish to continue using the program. There are two levels of registration :- 1. For 5 pounds Sterling, you buy a license to use any shareware version of the program without further payment. I will also offer answers to queries via the KM_Term support message area (currently at StarNet BBS - 0603 507216 or, System ST - 0533 413443). 2. For 10 pounds Sterling you buy the same licence as in level 1 above, but in return I will send you a disk with the latest version (and any beta-test variants) plus the source code, a few other PD/shareware comms programs with their original docs., and a printed manual for the latest version. Updated versions, ie. new release versions which become available, will be available from myself for 2 pounds Sterling (to cover the cost of the disk + postage) or through normal BBS/PD channels. The upgrade manual will be supplied in Write-On/That's Write format (and ASCII format on the disk) as a `changes to version....' file. 10.3 You can alter the source code and re-compile the program for your own requirements provided that you do not release it in any form without my agreement in writing. If you feel your modifications are valuable to other users, then I will give you a release version number that is unique and a format for adding to the documentation that makes it clear that the major part of the source code belongs to me. If anyone registers your release version with me then I will forward an agreed percentage to you. 10.4 KM_Term is supplied without warranty; any loss of data, damage to equipment, or any losses whatsoever attributable in whole or part to KM_Term are your responsibility. By using KM_Term, you are agreeing to these conditions of use. 11.0 More About Recording & Using Autologon Sequences 11.1 A step-by-step guide to recording a sequence:- a. Set the RS232 parameters to the required settings for the BBS you wish to call. b. Press . c. Enter the desired filename for the sequence in the fileselector and press or the . d. If you always wish to use the currently active RS232 settings with that BBS then press to register them in the autologon file. e. Pull up the control panel and go into the autodialler. f. Click on the appropriate BBS number with the to autodial it. g. Once you have connected, repeat the following steps until you have reached the position where you want to complete the sequence. g1. Every time the BBS pauses and waits for some kind of response from you, wait a minimum of 0.2 seconds and then press . This registers the BBS text that KM_Term will wait for before continuing the sequence. g2. Then enter the required response, (followed by where necessary). h. When you have reached the final point in the desired sequence then press to close the autologon sequence file. 11.2 It is important to note that any time XYZ.TTP is used during recording, the transfer parameters are also recorded. This makes it possible to set up autologon files that logon, go to the required BBS menu, download or upload mail using XYZ.TTP, and logoff without user intervention. 11.3 When playing back a sequence using , the user can still type in responses where desired. This means that if you get an unexpected request from the BBS, you can still respond on the keyboard. Once you get to the point expected by the autologon sequence, KM_Term will continue with the sequence as usual. You can cancel the sequence at any time by pressing . 11.4 Autologon sequences can be edited if desired using a text editor provided that the editor allows special characters such as [CR] and [ESC] to be seen on screen. The format is very simple; `SE>' precedes any characters sent by the terminal and `RE>' signifies any BBS characters to wait for (string must be 1 to 10 characters long). All [CR] codes must have their own `SE>' command. 12.0 HOST mode (the KM_Term mini BBS system) 12.1 If you are using a Hayes-compatible modem which is set to auto-answer (register S0>0) and verbose messages are active (i.e. you get `CONNECT ####' messages) then KM_Term will enter HOST mode when a `CONNECT' message is received. Actually KM_Term looks for the string `NECT' in the last ten characters of the capture buffer. This mode can also be enabled & disabled by pressing the key at any time. 12.2 In HOST mode, KM_Term will echo back any received characters to the remote modem (i.e. like a message editor in a BBS) and operate in half-duplex mode at the local modem (i.e. you will be able to see what you are typing even though the remote modem is not echoing your characters back to you). 12.3 HOST mode allows simple connection between two terminal users without manually selecting any different settings to those used to call BBS systems etc. The two terminals are continually in `CHAT' mode but it is not a split screen so care has to be taken not to type at the same time. A good practice to follow is to press a double [CR] when you have finished typing so that the person at the other end knows that you have finished. 12.4 The capture buffer will record anything typed by the remote modem, so the other user can simply type or ASCII-send any messages they want to you (and vice-versa). 12.5 If the remote user types `*MENU' a file MENU.TXT will be sent to them. This file contains a description of the HOST mode commands that they can use and it can be customised to the users preference. 12.6 Similarly if they type `*READ' followed by a [CR] a file READLIST.TXT is sent. 12.7 If they type `*READ#' where `#' is a number 0-9, a file #.TXT will be sent. 12.8 Using these simple ASCII files (which should be located in the same directory as KM_TERM.PRG) you can set up a bulletin menu (READLIST.TXT) with up to ten messages (1.TXT, 2.TXT, etc.). 12.9 By typing `*JEK' the other modem user can call up your JEKYLL connection, this will allow easier chat and also two-way file transfers depending on your Jekyll configuration. 12.10 The remote modem user can finish the connection by typing `*BYE' to logoff gracefully. 12.11 I wrote this function to enable me to leave KM_Term unattended but allow friends to connect and upload messages & files and read messages or download files from me, even when I'm not around. This offers a kind of miniBBS facility without the considerable hassle of setting up a full BBS system. 13.0 OTHER NEW FEATURES IN v1.81 :- 13.1 Had some comments back from a registered user regarding loss of some screen characters at 9600 baud. If you are using KM_Term at speeds in excess of 2400 baud it is wise to use a serial RTS/CTS patch program and RTS/CTS flow control switched ON. Nevertheless in the interests of continually upgrading KM_Term, I have tweaked the RS232 input routines to dramatically increase the screen handling at high speed, particularly when receiving standard ASCII or VT52 menu data. 13.2 The screen display will now nearly keep up with 9600 baud (970cps) input RS232 ASCII data without ANY handshaking, provided that a screen accelerator such as QuickST is used. It's still a good idea to use proper RTS/CTS handshaking at high speed however, particularly if you are viewing complex ANSI screens at 9600 baud or higher. With QuickST3 installed, KM_Term now handles 19200 baud ASCII/VT52 incoming text faster than any other ST terminal program that I know of (with the same screen accelerator installed obviously). 13.3 I also observed some minor improvement by increasing the RS232 buffer size. Many terminal programs seem to make up for slow screen handling by having a larger buffer; If anyone is interested I will incorporate this as a feature in a later version. 13.4 When exiting the program using the key, you are given the option of saving the capture buffer in case you forget. 13.5 The capture buffer overflow recognition has been improved. 13.6 Mercury & BT call logs are now saved separately, and the information displayed after a call is increased accordingly. 13.7 KM_Term 1.73 now automatically recognises when a zmodem transfer is initiated and calls XYZ.TTP with the '-d -z' parameters to download a file. If you have included a zmodem download in an autologon file it will be necessary to remove it otherwise XYZ.TTP may be called twice. All other protocols are unaffected. 13.8 The 0.5 second delay that KM_Term uses to detect the last 10 characters in the capture buffer has been reduced to 0.2 seconds. This speeds up autologons slightly but more importantly it allows KM_Term to detect zmodem start sequences. 13.9 The program error handling has been improved significantly. 13.10 If you hold down the shift key or control key when positioning the cursor using the left mouse button then the new coordinates are sent to the remote modem in VT52 or ANSI format respectively. 13.11 KM_Term now responds to the ANSI request for the cursor position. For this to work I've had to peek the memory for the ST's VT52 coordinates but the program searches for these memory positions at startup so it should work with all TOS versions - let me know if you get any messages to the contrary. 13.12 KM_Term now has auto-redial. 13.13 KM_Term now has access to GEM accessories. 13.14 The terminal can now send an initialise string on startup and a termination string on exit. Put the strings after the commands IN> and TE> respectively in the KM_TERM.CFG file. END OF FILE ---------------------------------------------------------------------