Copyright (C) 1993-1995 Jonathan R Hudson.
This edition of the QTPI documentation is consistent with version 1.56 of QTPI.
Published by Jonathan R Hudson
PO Box 2272,
Ruwi 112,
Sultanate of Oman.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
These programs are free; this means that everyone is free to use them and free to redistribute them on a free basis. There are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of these programs that they might get from you.
The following precise conditions pertain to QTPI.
If you find QTPI useful you are encouraged to make a small donation to an animal welfare charity.
QTPI is a tele-communications program for SMS/QDOS compatible operating systems, these include SMS2, SMSQ, SMSQ/E and probably many other operating systems starting SMS. It will also run on the QDOS derived operating systems (QDOS, Minerva, ST/QL and Ami/QL) originally implemented on the Sinclair QL. QL/QDOS based systems may not be able to enjoy full QTPI functionality without additional hardware such as the (super)Hermes serial co-processor from TF Services and proposed extended graphics cards. Specific QL caveats are described in the appendices to this manual.
QTPI uses the "Pointer Interface" or "Extended Environment" (or even "Pointer Environment" (PE)). If this is not supplied as part of the system software for your computer, you will have to obtain the files ptr_gen, wman and hot_rext from a commercial source. QL/QDOS users who are members of the QUANTA user group can obtain a free version of the PE that may support QTPI functionality. QDOS users also require Toolkit II (TKII).
Two other, freely distributable, software products, the QJump "Config program", and the c68 "env_bin" environment variables extension are recommended. The Config program is (c) QJump and is placed in the public domain by Tony Tebby. Env_bin is a freely distributable c68 extension by Dave Nash, Dave Walker and Dave Woodman. These items are not subject to the QTPI license.
QTPI is an acronym for Quintessential Telecommunications, Pointer Interface, or perhaps Quintessential Telecommunications, Peculiarly Intuitive (or even quite terrible, pathetic implementation, but don't tell anyone I told you that).
It was a working name during program development that unfortunately stuck. The author continues to be deeply embarrassed, and is likely to remain so for the foreseeable future.
QTPI is distributed in three parts.
QTPInnnE.ZIP
QTPInnnD.ZIP
XPRnnn.ZIP
A "readme" file in each archive will describe the individual archive contents and any interdependencies.
QTPI scripting requires a Thing, "Client Server Manager" (CSM). QTPI v1.56 requires CSM v1.17.
Full distributions of large amounts of largely uncommented 'C' and assembler tend to be unpopular, particularly with BBS Sysops. The source to QTPI is not confidential; it is available in part or entirety, on request, from my BBS, see section The Dead Letter Drop. Please note that I foolishly embarked on QTPI before I had learned how to program the Pointer Interface; the code is thus obscure, unclear, uncommented and full of bugs.
QTPI may be configured using the QJUMP Config program. The following items are configurable.
Data File
Colour Scheme
High Speed
The example phone book is just that, an example, I accept no responsibility for the accuracy of the information therein.
QTPI uses four categories of files, you may choose to place them in four discrete directories or all in one place, or any such combination, the choice is yours.
QTPI
QTPI_dat
QBook_dat
XPR*_library
*_prefs
XPR stands for eXternal PRotocol. It is a method of providing file transfer protocols to a communications program in an open and extensible fashion. You can use the XPR libraries with any program that supports the XPR standard. If you wished to write, for example, a standalone ZMODEM server, or even a BBS (Bulletin Board System), you could use XPR to provide a file transfer capability. Documentation, source code and program examples on writing and using XPR compliant programs may be available from "The Dead Letter Drop BBS" (section The Dead Letter Drop). The following XPRs are currently available.
XMODEM
YMODEM
ZMODEM
SEALink
Kermit
ASCII
Each XPR library has a 'preferences' file associated with it. This file defines the settings used by an XPR library. If this file does not exist it will be created using default values. You can edit these values from within QTPI. See section XPR Preference Settings. These files are named *_Prefs where '*' represents the protocol name. The rules for locating these files are described in section XPR Prefs Path
The location of the files used by QTPI may be defined in a number of ways. The location of the default data file `QTPI_dat' can be changed by 'patching' the QTPI program using the QJump Config program, for more details, see section Config Options.
You can override this setting when you run the program by two methods.
setenv "QTPI_DATA=win1_comms_QTPIxmodem_dat"
ex QTPI;'-s win1_comms_OldModem_dat'
The data file is located as follows:
The phone book file is defined from within QTPI, from either the Files or Preferences menus, and is stored in the QTPI_DATA file.
The XPR Libraries are located as follows:
The XPR preference files are located by:
QTPI supports the environment variable QEM_BUFFER (sic) to define a serial buffer size. The serial buffer size is determined by:
Given reliable hardware (*Hermes, Atari, QXL with 16550 PC UART), then there is no reason to change this.
QTPI is a Pointer Environment program, this should mean that it should have a standard, intuitive user interface; I do not intend explaining how the PE works, it is explained in the Pointer Environment manual, available from the usual vendors (Jochen Merz Software).
This document also assumes that you have some knowledge of basic computer communications and thus may not explain every option in detail.
A great deal of basic communications information is available from the following sources.
You can invoke QTPI using EX and EW commands from the command line, or by exec'ing from a QPAC2 menu. You can also HOT_LOAD1 it from a hotkey. Some moderately cunning hotkey options are described in section HotKey Trickery
When QTPI starts up, you will see an 'About Box' giving the program version number and the Pointer Environment version number. Please quote these numbers if you need to report a problem.
QTPI displays both a pointer and a cursor in the main terminal window. The terminal window can only accept keyboard input when the cursor is in the window; this is a feature of the Window Manager.
You will see a number of icons on the left of the screen. The first three are the standard Pointer 'move', 'size' and 'sleep' icons.
QTPI initially uses a 512 x 256 pixel area, the move icon is therefore of no use on a basic system, but is functional on SMS and extended mode ST/QL systems.
The size icon permits resize in the vertical only; from approximately 21 lines (224 pixels) to your screen maximum-2, this gives 24 text line on a standard QL screen and 58 text lines on a 800x600 enhanced display. In order to easily achieve the 80x24 character cell screen for VT/ANSI applications, a DO on the resize button will force a 80x24 display, while a HIT (or CTRL-F3) will invoke the standard resize function.
The sleep icon will iconify QTPI. In this state, it continues to read incoming serial data, so log files are maintained and auto-XPR (ZMODEM) requests are honoured, however when you 'HIT' the icon (button), then the restored screen will be redrawn to the degree defined by the 'Connections' menu 'On Wake' item. See section On Wake. If QTPI receives an XPR ZMODEM request while it is iconified, then the full screen will be picked to the front and the transfer will proceed. If QTPI is configured to start XPRs iconified, then the pick happens when the transfer completes, so you could use QTPI as a background ZMODEM server. The pick and restore can be quite spectacular, particularly if you are working on another application at the time!
If you have the 'QPAC2' (or equivalent) button frame software, then the QTPI button is placed in the button frame, if you don't have this software, then you get a small button at the pointer position. You can move this button by HITting and dragging it. In both cases, DOing the button restores QTPI. QTPI uses the standard Pointer keys for 'move' and 'sleep', CTRL-F4 and CTRL-F1 respectively.
The other icons represent the Files Menu (F6), Modem Menu (F7), Preferences Menu (F8), Phone Book (F9), Transfer Icon (F10), "Handy Items" (CTRL-F6) and Exit (Shift-Enter).
The 'disk' icon invokes the FILES menu, the selection key is F6 (SHIFT-F1). The files menu offers the following options.
Capture All (C)
Capture Now (A)
Send Text (S)
Upload (U)
Download (D)
XPR Protocol (X)
XPR Prefs (P)
File Options (F)
Review Buffer (R)
Run Script (N)
The 'Capture All', 'Capture Now' and 'Send Text' options will prompt you for a file name.
The 'Upload' option will also prompt for a file name, or names. The selection for upload depends on the XPR Protocol chosen; some protocols (Kermit, SEALink, YMODEM and ZMODEM) allow 'batch' uploads (i.e. more than one file). For batch protocols, you may define multiple files, wildcarded file names and /or the name of a file listing the files you wish to transfer. This is described in the File Transfer section. See section Specifying Upload files.
The 'Download' option will request a file name for the non-batch (XMODEM & ASCII) transfers. For batch transfers, the name supplied by the host is used.
The 'XPR Protocol' will present you with a list of the XPR options installed on you system. Note the usage of the 'Libr Dir' setting to define the device and /or directory where the protocols are stored.
The 'XPR Preference' item will present you with a list of options for the current XPR transfer library. Each setting is described in the XPR Transfer chapter. See section XPR Preference Settings. The 'File Options' choice allows you to change a number of file and directory related items. If you select 'Save' or 'SaveAs' from the 'Commands' option in this section, QTPI saves all configurable information, not just the files related items. The following file options are available.
Phone Book
Send From
Receive To
Upload Dir
Download Dir
Libr Dir
HOT Keys
Default Log
Start with
Script Log
Start Script
Stop Script
User Menu
QTPI internally buffers the last 64 Kbytes of data received. This can be viewed by selecting the review buffer item from the 'Files' menu. This opens a separate window that can be moved, scrolled and resized. If you are fortunate enough to have SMS or Extended Mode 4 ST Emulator, you can move the review window clear of the QTPI window and thus view current and logged data at the same time. The data displayed in the review buffer is a snapshot of the QTPI internal buffer. It can be updated with the most recent contents of the internal buffer using the WAKE icon. Note that QTPI can only display incoming data if you either move the review window so it does not overlap the QTPI window or you pick the QTPI window to the top. You can use HOT_KEYS to toggle between QTPI and the review buffer, for example.
ert HOT_LOAD1(q,QTPI)
ert HOT_PICK('x','QTPI Review') : REMark Pick is not wake
ert HOT_WAKE('X','QTPI Review') : REMark Wake is not pick
When you PICK the review buffer, the window is brought to the front, if you WAKE the review buffer, then it is brought to the front, and reloaded from the latest data in QTPI's internal buffer. You can just define a single key toggle between QTPI and the review buffer. In the first case, ALT q will toggle between WAKEing QTPI and WAKEing the review buffer, once the review buffer has been initially invoked. Clever this HOT_KEY stuff.
The Review Window supports the following key / mouse actions.
ESC
CTRL-F2
CTRL-F3
CTRL F4
T
B
ALT DOWN
ENTER,DO
ALT UP
Space,HIT
Shift space
The Review buffer does not interpret control characters, these will displayed according to the facilities of your operating system. The review buffer does filter out carriage returns. If you want to see a captured session in full emulation, you must save the data to a file See section File Menu Options. Such capture files (see section Capture Options) may be 'played back' with QTPI in local mode , see section Access, using the 'Send Text' menu option. The results of XPR file transfers are also recorded in the review buffer. The Capture Options reflect the review buffer functionality
Capture All
Capture Now
QTPI supports scripting via a number of extensions available using the "Client Server Manager" (CSM) Thing. This is described in the document "QTPIScript_Man".
QTPI has always been HOT_KEY friendly (unlike some other comms programs). QTPI supports the concept of job specific hot keys. These are HOT_KEY definitions stored in a file that is loaded during QTPI start up. Such HOT_KEYS are only defined while QTPI is running. If there is a conflict with previous HOT_KEY definitions, the conflicting definitions are saved, and restored when QTPI exits. This of course, only works if you cleanly exit QTPI, if you RJOB it, then the QTPI specific keys are not removed and the conflicting ones are not restored. The QTPI specific HOT_KEYS just stuff characters into the keyboard queue. As SMS/QDOS is a multi-tasking system and HOT_KEYS are a system wide resource, then this obviously has system wide implications, however as comms programs tend to be used in an exclusive mode, you may not find this a problem. I was not convinced of the usefulness of this feature while I was developing it, now I would not be without ALT-U (upload), ALT-D (download), ALT-R (Review) etc. If you don't like it, you don't have to use it. The name of the hot key file is defined as in the 'Files Options' menu, see section File Menu Options. The default is `dev_QTPI-Keys_dat'. I happen to like `illegal' characters in such file names, change it if you don't. The QTPI-Keys file is an ASCII text file that can be edited with a standard text editor such as QD, QED or MicroEmacs. The format is:
#Define upload hotkey (ALT U)
U,\xeaU
# Define List phone book (ALT L)
L,\xf6\xf0L
Any attempt to use either hash or comma as a HOT_KEY will result at best in abject failure. You (probably) deserve any problems it creates. Hexadecimal equivalents for function keys are defined in your system manual.
If you have, for example,
ERT HOT_THING (r, RJob)
in your boot file, and
#Define Review hotkey (ALT R)
R,\xeaR
in the QTPI-Keys file, then :- Before running QTPI, "ALT R" and "ALT r" give the 'Rjob' thing. Run QTPI, "ALT R" gives the Review Buffer, "ALT r" gives the 'RJob' thing. Exit QTPI (cleanly), and both give 'Rjob' again. Almost impressed? You should be!
The MODEM menu is selected with F7 (SHIFT-F2). The menu offers the following options.
Dial (D)
Disconnect
Connect (C)
Answer (A)
Auto Answer (U)
Reset Line (R)
Version (V)
AT Strings (T)
The "AT Strings" item displays a window to enter or change modem command strings. Special, control characters may be included using an escape notation See section QTPI Escape Sequences.
The items and the defaults are:
Modem Init.
Pre Dial
Post Dial
Apres Dial
Disconnect
Connect
Answer
Auto Answer
Reset
Version
Get Carrier
Drop Carrier
Certain special characters can be defined using a 'C' like escape sequence notation. The escape character is the backslash. The following escape commands are provided. These may be used in AT modem command strings, or in QTPI HOTKEYS. Some sequences, such as the delays, are only applicable in modem control sequences,
\r
\n
\e
\\
\t
\b
\s
\f
\nnn
\xnn
\|
\~
\+
\u
The "question mark" icon invokes the PREFERENCES menu, the selection key is F8 (SHIFT- F3). You are presented with a menu with options of:
Connection (C)
Files (F)
Modem (M)
The 'Connection' option invokes a selection page for the general terminal preferences. The file and modem selections here are the same as are available from the 'Files'/'Preferences' and 'Modem'/'AT Strings' menus described earlier.
The pull down screen associated with this and other configuration related displays has three options displayed in the title bar.
Commands (F3)
Abort (Shift-Tab)
Quit (ESC)
The 'Commands F3' menu has the following options, some of which may be unavailable, depending on context.
Open (O)
Save (S)
Save As (A)
Defaults (D)
Init Modem (I)
The Connections window displays a window that allows you to change a number of connection options. These items may be text (you are invited to type a response), toggle (a number of preset items are available), or 'other' (where a menu or additional dialogue box will be presented).
Toggle fields (those having number of preset values), may be toggled forwards using ENTER/DO or backwards using HIT/SPACE. For example, if the 'Baud' field displays 9600, then ENTER/DO will change it to 19200 and SPACE/HIT will change it to 4800. This is more natural with a mouse than keyboard.
The terminal emulation, VT52, VT100/VT102, ANSIn (n=1 to 4). ANSI modes are described in section Emulation Modes.
The serial port, ser1 or ser2.
This item offers the standard SMS/QDOS parity settings. QTPI maintains the serial device with no parity and handles these parity settings internally. This means that Even Parity and CIS mode are exactly the same (indeed all binary file transfer protocols run as 8 bit, regardless of parity).
Parity is correctly asserted on transmit and, if set, masked out on receive (no check is done on receive parity).
The parity setting is not denoted as part if the serial device name, but between the device name and the emulation (e.g "ser2hr e VT100" for even parity) in the status line.
This defines the hardware flow control (or not).
This item controls the serial device's internal translation of EOL/EOF codes. This maybe better handled by the QTPI RX/TX EOL parameters.
The baud rate. QTPI will set the baud rate to the value specified here. If this is set to "None", then the baud rate pertaining before QTPI was invoked is used.
The received character(s) that represent "End of Line".
The characters that QTPI transmits when you press ENTER (or Sending a text file, when a LineFeed character is encountered).
The character that is sent when the DELETE key is pressed. Options are BackSpace (ASCII 8) or DEL (ASCII 127). QDOS/QBOX bulletin boards require DEL, boards hosted on Unix, a PC or Amiga may require BS.
The Wrap parameter has values On,Off,force. When you select VT100 or VT102, wrap is set to off (VT100 standard), unless you have wrap = force, in which case QTPI will autowrap long lines. If you use ANSI emulation with a PC based BBS, you will almost certainly require Wrap = On to view ANSI graphics correctly.
The selected file transfer protocol. When you DO or HIT this item, a menu will display the currently available file transfer protocol(s).
Controls if QTPI beeps on completion of XPR file transfers.
CSI. This controls the usage of the CSI character (ASCII 9b hex, 155 decimal). This character is the eight bit ANSI 'lead in' control character (the seven bit VT100 equivalent is 'ESC[' ). If this field is defined as Interpret, then CSI is used as a control character. If this field is defined as display, then CHR$(155) is displayed. This field is only effective with ANSI emulations. If CSI is defined as interpret, and your are using an ANSI emulation, then CSI is also transmitted as the lead in for arrow and function keys. This means you can use QTPI as an 8 bit ANSI terminal.
Unless you know you need this, leave it as 'display'.
This item defines the effect of the arrow keys. This may have values 'Move Pointer' or 'As Keys'. If this is set to 'Move Pointer', then these keys move the PE pointer and do not transmit codes to the host. You must use SHIFT-Arrow key to transmit arrow key codes to the host in this mode.
The 'Move Pointer' mode has an unfortunate side effect with ALT/HOT KEY strings (see section Caveat Non-Mousers).
I STRONGLY RECOMMEND THAT YOU USE THE DEFAULT 'As Keys' MODE.
If the mode is 'As Keys', then the arrow key codes are transmitted to the host and do not move the pointer. In this mode, you need a mouse to move the pointer IN THE TERMINAL WINDOW ONLY. The arrow keys will still move the pointer in all the other windows and menus. You can therefore use 'As Keys' mode without a mouse, you just have to select menus by FUNCTION key rather than with the pointer.
The usage of VT100 keypad emulation is controlled by this configuration item, VT Keypad, which takes values YES or NO. The keypresses used for VT100 keypad emulation are also so used for some non-English accented characters, particularly German. With VT Keypad = YES, you get the VT100 escape sequences, with VT Keypad = NO, you get the normal QDOS character. If you want to use VT100 keypad and German, you have a problem to which I currently have no solution.
The VT100 KeyPad emulation Keys are: VT Key Keypress PF1 F1 PF2 F2 PF3 F3 PF4 F4 Key Pad 0 CTRL 0 Key Pad 1 CTRL 1 Key Pad 2 CTRL 2 Key Pad 3 CTRL 3 Key Pad 4 CTRL 4 Key Pad 5 CTRL 5 Key Pad 6 CTRL 6 Key Pad 7 CTRL 7 Key Pad 8 CTRL 8 Key Pad 9 CTRL 9 Key Pad - CTRL - Key Pad , CTRL , Key Pad . CTRL . Key Pad ENTER CTRL /
This field was included at the request of a hardware developer. Do not use it.
The key used to cycle jobs. Some host operating systems use CONTROL-C, so you can change the SMS/QDOS key here. QTPI will restore your default value on exit.
Controls whether the QTPI uses the XON-XOFF protocol to pace the host.
Determines whether low ASCII (0-31) characters are Displayed or Interpreted.
This takes the legal QDOS baud values or None or Never. If a numeric value is displayed, then that baud rate will be re-instated on QTPI exit. If the field is set to "None", then the baud rate in force when QTPI was invoked is restored (or at least the value suggested from the system variable offset, sys_tmod). If "Never" is selected, then no change of baud rate is made.
This setting controls access to the serial line, taking values "On Line", "Local" or "Echo". In "Echo" mode, typed characters are both echoed to the screen and transmitted to the host. This may be useful for direct connections between two machines where the host does not provide echo.
Local Mode may be used for replaying captured data with the original emulation.
This parameter defines the number of lines that are scrolled when a NewLine is required in the bottom line of the display. Screen scrolling is a relatively expensive operation, so setting this to a value greater than 1 can be very effective in speeding up text display to the screen. The value used is a compromise between speed and readability. 0 (or 1) gives a smooth, slow display, 4 is a good working value, 16 is fast but jerky and difficult to read.
These two parameters control the redial of a BUSY phone number. To use this feature, you must either have a 'Hayes' compatible modem giving verbose (text) responses.
The "Dial Try" item defines the number of attempts QTPI will make to dial a number before it gets a connection.
The "Dial Wait" item defines the delay in seconds between dial attempts.
If either of these values is zero, then auto-redial is disabled.
This setting controls a inter-character delay when commands (such as dial) are sent to the modem, the units are 1/50 second, and the valid range is 0 (the default, i.e. no delay) to 32767 (over 10 minutes !!).
This setting was not only useful for QXL owners (prior to SMSQ 2.38) , but remains so for owners of older modems. I discovered by accident that while "Cmd Delay = 0" works fine with a ZyXEL 1496E+ model (a modern, quality model). I have to set "Cmd Delay = 12" (1/4 sec delay between characters) to get it to dial with an older, obsolete Amstrad SM2400 modem. In the case of the SM2400, QTPI otherwise sent the characters faster than the modem could cope in command mode.
Use of "CMD Delay" may enable use of QTPI with older modems that have previously refused to dial from the phone book or modem menu.
I recommend that if your modem has failed on dial with older versions, then you should start with "Cmd Delay = 25" and work down to a minimum safe value. If you do this dialing your own number, it costs you nothing.
This defines the memory used by QTPI to buffer serial input, it may be from 1280 bytes to the maximum your free memory permits. The value set on the 'Connection' page will only come into effect when you re-start the program (i.e. it is not dynamic). You may define it using the symbol 'k' for multiples of 1024 bytes (i.e. 16K and 16384 are equivalent). The default of 16K bytes should be sufficient for all applications. The value set here may be over-ridden by the environment variable "QEM_BUFFER" (sic).
This offers the choice of 'Full screen', 'Iconified' or Info-Icon'. QTPI can start XPR transfers with QTPI in a iconified (button) state, this allows the transfers to proceed faster (about 10%) as it does not display on- going statistics and lets you get on with something else. QTPI will be picked to the front of the screen when it finishes. The 'Icon' state just displays a button; 'Info-Icon' displays a button that is updated with number of bytes, errors and timeouts. This setting provides a compromise between speed and operator sanity.
Aka the "Casablanca" option, (so called because it uses a procedure called PlayItAgainSam()). This option instructs QTPI to replay (some of) the review buffer to the terminal screen after a WAKE. QTPI redraws the lesser of:
You can enable and disable this behaviour from the 'Connection' screen, using the 'On Wake' field options 'Redraw' or 'Clear').
At present QTPI adds information such as log open times and XPR information to the review buffer, if you SLEEP an XPR transfer then after the WAKE, as well as the saved terminal info, you see the transfer statistics. Note that if you have a complex ANSI screen, it may be bigger than 2K and not have ANY LFs in it, thus it would not be correctly redrawn, this is a feature.
In "Arrow Keys" = 'Move Pointer' mode, the PE removes spaces from 'HOT_KEY' or 'ALTKEY' strings before they are delivered to the program. This means that if you have defined a hotkey in 'Move Pointer' mode as, for example :
ert HOT_KEY ('a','spaced out man')
or ALTKEY 'a','spaced out man'
and press ALT-A on the main QTPI screen, you will get 'spacedoutman' without the spaces. If you pressed ALT-A in a text requester (the phone number one from the F7 menu for example), then you get the spaces. HOT & ALT Keys work normally (i.e with spaces) in "As Keys" arrow key mode. I STRONGLY RECOMMEND THAT YOU USE "As Keys".
This facility is only available with PE v1.23 and later. If you run a version of the PE less than 1.23, then the cursor keys always move the pointer. It is highly unlikely that QTPI will work with such old versions of the PE.
The next icon represents the PHONE BOOK menu, the selection key is F9 (SHIFT-F4). A menu is displayed listing all the phone book entries (with scroll bars if necessary). 'HIT'ting an entry will pull down a sub-menu allowing you to maintain that entry or the phone book. 'DO'ing an entry will dial the entry's phone number. The 'auto-redial' features are described in section Auto Dial Menu.
Dial (D)
Edit (E)
Zap (Z)
Add (A)
Open (O)
Save (S)
Save As (A)
List (L)
If no entry is selected, (i.e. you select 'Commands F3') then the D,E,Z options will be 'ghosted' and unavailable. You can only use the file options (Add through List).
The screen to edit and amend phone book entries has the following entries.
The name of the BBS or service.
The phone number of the BBS or service
A string that may be transmitted to the host as part of the logon sequence. This string will be transmitted automatically if the host sends an ENQ (ASCII 5) character. It may also be transmitted manually from the "Handy Items" menu.
If this string is defined, it is concatenated to the "Login" string.
A comment that may describes the host service. You can use this field for anything you like.
A string (that may contain QTPI escape sequences) that is used to initialise the modem. This may be used with old modems/services using 1200/75 bps where a special command has to be sent to the modem to change the baud rate.
The XPR Protocol (file transfer protocol) used by the service. If this is defined and different from the current XPR, then the new protocol will be loaded before the service is dialed.
These other fields will replace the preference values if different. If the baud rate in the phone book is set to "None", then it is not changed.
The size of the phone book is limited only by media, memory and common sense.
The next icon represents the TRANSFER icon, the selection key is F10 (SHIFT- F5). YOU MUST HAVE defined an XPR upload or download from the 'Files' menu before you select this item. The requirement to invoke transfers via the TRANSFER icon depends on the protocol selected. If you need to hit F10 (Shift-F5/Xfer Icon), a message is displayed in the status area. If the protocol supports batch transfers, then when you are downloading, selecting download from the 'Files' menu will start the download immediately. You only need to use the 'F10/Xfer Icon' to start a download when you have to define a download file name (i.e. using XMODEM, KERMIT (Host Server) or XPRASCII) Therefore, to download a file using a batch protocol, you should do:
The download then starts immediately. If you use ZMODEM, you don't even have to do this, starting the transfer on the host system will automatically start it in QTPI.
The next icons represents 'OTHER HANDY' items, the selection key is CONTROL-F6 (CONTROL-SHIFT-F1). These are items that are useful but have no where else to live.
Answerback (A)
Clear Terminal (C)
Output Toggle (O)
ReDial (R)
Def Log (D)
The next item is the User Menu. The icon may appear to resemble a right pointing arrow decked out in a fairly common menu title bar colour scheme. The selection key is Control-Shift-F3 (hex $f3).
This option invokes a 'user defined' menu that will run scripts. The File Menu option "User Menu" is the name of the user menu defition (UMD) file. Note that this entry is only read at startup, so to define a UMD, you must either do it in QTPI, exit and restart or add a line to QTPI_DAT before you start, for example:
User Menu=flp2_QTPIMenu_dat
The format of the UMD file is very simple. Any line starting with a hash (#) is a comment, and anything else is a data line. The first data line is the name of the menu, the rest are menu items. Menu Items are of the format.
item name | script file name | selection key
The vertical bar is a mandatory separator.
So for example, given some example scripts in, we could construct the above UMD file as:
# This is a QTPI UMD file # # The rather original title is Jonathan's Menu # And some wonderfully useful options are .... FS Upload | flp2_fsup_bas | U Send Text | flp2_sendtxt_bas|S Fax Send|flp2_fax_bas |X XPR ASCII | flp2_upasc_bas | A BBS Dial|flp2_dialer_bas|D # Selection key is not mandatory. White space around bars is optional too Config|flp2_config_bas # That's all for now folks .....
The next icon is the "END" item, the selection key is SHIFT-ENTER. This quits the QTPI program. You get a requester if you exit with uncommitted changes to the data file or phone book. The options are:
Save (S)
Don't Save (D)
Go Back (G,ESC)
Note: QTPI does not check the save file is writable. I assume that if you select 'Save' then you have ensured a writable disk is available.
If you use the 'repeat dial' feature (by defining the 'dial try' and 'dial wait' items in the 'Connection' menu, an additional icon will be displayed when dialing is in progress. The icon represents (to those of vivid imagination), a stop-watch. The number of tries and the timeout period are displayed below this icon. If the dial succeeds (the modem returns the "Get Carrier" string ('CONNECT'), then these items are removed. If you select the icon (with the pointer or by CONTROL-F7), a menu with the options of 'Online', 'Abort' or 'Quit' is displayed.
Online (O)
Abort (A)
Quit (ESC)
If you dial 'one shot', i.e. with 'Dial Try' set to zero, then the stop watch icon is displayed but no countdown or timer. The icon is removed when when a CONNECT is received or you use the CONTROL-F7 menu to cancel dialing, or a key is pressed.
The progress of the transfer is displayed in the XPR window, unless QTPI is iconified. In the (extremely) rare event of a QTPI/XPR transfer appearing to get stuck, hitting the QUIT item (or pressing ESCAPE) about six times, will abort any transfer. If the sender is still sending to you, typing a number of CONTROL-Xs should shut it up.
"In extremis" you could RJOB the protocol. To reload it, first set the protocol to "None", then to the desired protocol. The 'Files' section of QTPI has two entries, 'Upload Dir' and 'Download Dir'. These are just short cuts to prevent you having to enter a full path name in the respective Up/Down load file name requester. You just append your required file name. For example, if Upload Dir is 'ram2_' and you wanted to upload, using ZMODEM, all files in ram2_, then you would just have to append a star to the initial choice presented in the 'Upload' filename requester, giving 'ram2_*'. If this requester is initially blank, then you have not defined UpLoad or Download Dir. If the protocol supports batch downloads (i.e. Kermit, ZModem, YModem), then the Download Dir field is ignored, but a download directory may be defined in the 'XPR Preferences'. SEALink is a little strange, in that if a file name is given, then it is used. You should make sure DownLoad Dir is blank (and you have specified a Default receive path in section SEALink Prefs), if you want to use host supplied SEALink names.
Note that you can 'preload' the upload buffer name before you do an upload, even before you dial the BBS/Service if you want. Select upload from the files menu, specify the file names that you want to upload. QTPI will beep and give you the "F10/Xfer Icon message". Just ignore it for the time being.
Now connect to the service. If it supports ZMODEM, then just start the upload, (F10/Shift F5/Xfer Icon). If the service only offers a non-auto start protocol, then start the transfer on the host, hit F10/Shift-F5/Xfer Icon and off it goes. Couldn't be easier.
QTPI lets you specify upload file names as a list, using wildcards, or via a list file, or a combination thereof.
Upload: ram2_file_txt ram2_demo_up flp2_*_c @ram1_files_list The file "ram1_files_list" contains win1_demo_*_h win1_qtpi_xmodem_prefs
Note that:
-r win1_a*_c win1_b* -r win1_c*_c
win1_boot
win1_bas->
win1_boredom
XMODEM has the following settings.
Text Mode (Y,N,C)
CRC Mode (Y/N)
1K Blocks (Y,N)
YMODEM has the following settings.
Overwrite Mode (O,D)
CRC Mode (Y,N)
1K Blocks (Y,N)
Option-G (Y,N)
Download Dir
SEALink has the following settings.
Path translate (Y/N)
Batch Upload Delay
Macflow (U/D/A/N)
U
D
A
N
Default receive path
Kermit settings are different from the other protocol libraries in that they may be used to to send commands to a Kermit Host server. The options:
Kermit FINISH Kermit BYE
send the FINISH and BYE commands to the host Kermit. The Kermit CD option should allow you to tell a Kermit host server to change its default directory, I'm not sure that works correctly.
The Kermit Prefs are accessed via the "Kermit Options" item and has the following settings.
Convert Filename
Keep Incomplete
Host Server
Text File
Packet Length
Block Check
Timeout
Retry Limit
ZMODEM has the following settings
Text mode (Y,N,?,C)
Overwrite mode (Y,N,R,S)
Buffer size
Frame size
Error count
Auto-activate receiver (Y,N)
Delete after sending (Y,N)
Keep partial files (Y,N)
Send full directory path (Y,N)
Use received path (Y,N)
Default Receive path
ASCII transfer has the following settings
EOL Convert (Y/N)
Pad Blank Lines (Y/N)
Inter-char delay
Inter-line delay
QTPI offers VT52, VT100 and ANSI terminal emulations. VT52 is an old standard, named after a Digital Equipment Corporation (DEC) terminal of the same name. This emulation is essentially obsolete in commercial terms, DEC are warning that they may not support it in future versions of their operating systems. It is used by some on-line services, such as CompuServe, and due to its low processing overhead, may be used for scrolling services such as QBOX based BBS.
VT100 is a later DEC standard for terminals and is a subset of ANSI. It is widely supported on both DEC's proprietary operating systems and most manufacturer's flavours of Unix. It is also used by some on-line services such as Electronic Yellow Pages.
ANSI is an advance on VT100, and is the character based terminal mode used on IBM compatible PCs and the Amiga. It supports up to sixteen colours and a wide range of 'graphics' characters. QTPI offers an emulation that is in excess of VT102 level (i.e. it supports some VT220 sequences such as cursor on/off). The mode (VT100/VT102) defines the response QTPI gives to a "What are you ?" (DA) sequence from the host. The responses are "VT100 with AVO" or "VT102". The ANSI emulations (ANSI1 - ANSI4) define how QTPI handles ANSI colours. The ANSI standard specifies support for eight colours (plus bolds) (BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN and WHITE. In mode 4, the SMS/QDOS can only display BLACK, RED, GREEN and WHITE. If you select ANSI1 mode, the colours YELLOW, BLUE, CYAN and MAGENTA are simulated using stipple patterns to give a muddy yellow, pale grey, pale green and darker red. The downside is that if text is written over a stippled background (or text is written in a stippled colour), then it is difficult to read. The ANSI2 emulation just maps the missing colours to WHITE, BLACK, READ and GREEN, which means that BLUE on a BLACK background comes out as all BLACK, which is even less satisfactory. Many ANSI screens contain white text on green background, which may be difficult to read. ANSI1 and ANSI2 ignore ANSI bold. ANSI3 and ANSI4 support ANSI bold, emulating a sixteen colour ANSI display. Due the the hardware palette of SMS/QDOS (four colours), it is difficult to select sufficient stipple patterns that work under all circumstances. ANSI3 has an additional 8 stipple patterns, but these are frequently difficult to read when text is involved (text constructed from ANSI graphics especially). ANSI4 attempts to use a SMS/QDOS base colour (red, green, white, black) for ANSI bold when ever possible. I find ANSI4 is the most satisfactory compromise for the majority of ANSI screens.
The QJump Config program can be used to configure QTPI. You are presented with the following options:
Default QTPI_Dat> flp1_QTPI_dat
Colour Scheme > Four colour / monochrome
Xfer Mode > High Speed/Normal.
Screen Lines > 24
The monochrome mode provides a more usable mode on monochrome devices such as ST Stacy. The 'high speed' (sic) Xfer mode setting will give faster XPR file transfers IF your hardware handshake is 100% efficient. If the handshake is not up to the job you'll get timeout and checksum errors. High speed is the default.
The screen lines option will force QTPI to open at the specified size. The minimum value is 21, if the value exceeds your screen size, then the maximum size for the screen is used.
QTPI also recognises the following command line options
ex QTPI;'-h -m -s Startup_File -t Phone_Book'
-h Toggles 'high speed' mode.
-m Toggles 'mono' mode.
-s Startup_file Defines alternative startup file (QTPI_DAT)
-t Phone_book Defines alternative phone book (QBOOK_DAT)
If you find this program useful and think it does have some value, then I'd be grateful if you make a small donation to an animal welfare charity or to GreenPeace in appreciation. If you think the program worthless, or you can't afford it, hate animals or adore nuclear bombs, then don't bother, there is absolutely no obligation.
Daria for putting up with me and my ******** computers. Graham Goodwin for encouragement, advice, debugging and donating a legal copy of the QPTR Programmer's Kit. Wayne Weedon for maintaining the primary distribution channel for QTPI (4th Dimension BBS). Tony Firshman of TF Services for a "developer's copy" of Minerva 1.97. QTPI on a QL is enhanced by Minerva and Hermes. I am pleased recommend both of these products. Bob Weeks of 'Pointer Products' for advice on the PE. I trust the favour has been repayed :-). Dave Walker et al, Tony Tebby, c68 and libqptr. This program is written using c68 and the libqptr library. Without the efforts and generosity of those involved with the production of this software and making it freely available, QTPI would not exist.
Jonathan Hudson, PO Box 2272, Ruwi 112, Sultanate of Oman. Tel/Fax : +968-699407
I may be contacted via my BBS, 'The Dead Letter Drop' which is online every evenings from 18:00 GMT to 03:00 GMT on my normal phone number. All speeds to v.32bis (14400 bps) and ZyXEL 16800 & 19200 bps. Use:
ZMODEM protocol RX EOL = <CR/LF> TX EOL = <CR> Delete = BS (8) 8-N-1
The BBS runs within a voice mail system. It should automatically recognise fax and data calls. Should the system fail to recognise data or fax, these modes can be forced by pressing the following telephone keypad while the OGM is playing (or after the voice "tone").
0
5
QTPI (or any other serial input program) will not work correctly with the Sermouse product, regardless of the whether you have Hermes or standard 8049 serial port hardware. QDOS appears (on both my QLs (Minnie 1.80/Trump MkI/Hermes or JM/8049) at least) to take 'device independence' to bizarre lengths by reading serial input from either serial port at random rather than the specified one. For example, I can connect a serial data source to ser1, enter the command 'copy ser2,scr' and watch data transmitted via the cable in ser1 appear on screen, even though the copy command is via ser2. Try it and see. I expect it is possible to use a mouse on grown up hardware like an Atari emulator, or using a 'bus' mouse such as QIMI. Pity really, as I only got the Sermouse to develop this program. They don't tell you this is the ads, caveat emptor ! This is a QL/QDOS 'feature', not a SerMouse bug; don't let this stop you getting SerMouse if you want an easy way to connect a mouse for other 'no serial input' programs. This QL feature affects not only SerMouse and QTPI, but any other combination of QL programs that attempt simultaneous serial input on both ports. Neither I, nor, I suspect, Albin Hessler can do anything about this other than warn you. SerMouse is, otherwise, an excellent product. If you use SerMouse and want to run QTPI (or QeM, Terminal, etc etc), then kill off Sermouse first, otherwise serial I/O is very slow. You may also have to remove the mouse from the other port, otherwise if you accidentally jar the mouse, junk appears on the screen.
QTPI later than v1.45 requires v1.38 ptr_gen or later. QTPI displays the PE version number in its 'About Box' when loading.
If you own a PE product, your supplier may be able to supply you with the latest version of the Pointer Environment. If you purchase a new program that uses the PE, then the latest version of the PE may be supplied; the supplier will have entered into a license agreement with Tony Tebby to do this and will pay Mr. Tebby a remarkably modest license fee for this facility. Although Mr Tebby's fee is modest and my generosity is legion, QTPI is freeware and I cannot enter into such a licensing agreement; you, the user, must be responsible for legally acquiring a suitable version of the PE. If you are a member of QUANTA, PE v1.35 is available on the QUANTA library SPECIALS_0 disk, free of charge. This free version is only available to QUANTA members and may not be distributed to non-members. It is possible that QTPI will not work with this obsolete version of the PE.
The non-standard nomenclature and writing adopted for the QL serial ports has caused much confusion. The following rules may help.
The following settings should work for many applications.
Ser2 MODEM cable or Ser1 NULL Modem
QL Ser Pin QL Cable DB25 pin DB9 pin
Colour
1 GND Black 7 GND 5 GND
2 TXD White 2 TXD 3 TXD
3 RXD Green 3 RXD 2 RXD
4 DTR Blue 4 RTS 7 RTS
5 CTS Red 5 CTS 8 CTS
6 to 20 6 to 4
(connect DSR - DTR)
Ser1 Modem / Ser2 NULL Modem cable
QL Ser2 Pin QL Cable DB25 pin DB9 pin
Colour
1 GND Black 7 GND 5 GND
2 TXD White 3 RXD 2 RXD
3 RXD Green 2 TXD 3 TXD
4 DTR Blue 5 CTS 8 CTS
5 CTS Red 4 RTS 7 RTS
6 to 20 6 to 4
(connect DSR - DTR)
Note that QL 6 pin (PCC) plug has pin 6 next to the clip.
This manual is prepared using the GNU texinfo macro package
for the TeX typesetting system. This facilitates the production of
typeset (*.dvi or Postscript) documents (using TeX and dvips)
and indexed ASCII documents using texi2roff and groff. If
you have access to a TeX system or DVI viewer/printer or a
Postscript printer and would like the typeset files (.texinfo, .dvi or
.ps format), please fax me or leave a message on my BBS.
The typeset manual is designed to be printed double sided. The
Postscript file can be provided as two (odd/even) files, or two files
can be generated by dvips from the qtpi.dvi file.
The groff/troff file is also available and may be typeset with
grops. You will need the -me macro package.
The Postscript manual may be printed using the SMS/QDOS version of 'ghostscript'. This program is available via SMS/QDOS BBS systems, if your usual BBS does not carry it (it is quite large), then the sysop will be able to tell you where it may be found.