QTPI

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.

QTPI Copying Conditions

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.

  1. QTPI is copyright (c) Jonathan Hudson. All rights reserved.
  2. NO WARRANTY. Every effort has been made to ensure that the programs described operate correctly. No guarantee of any kind is given that the program(s) described in this document are reliable. You use this material at your own risk.
  3. QTPI may be distributed in user group or public domain libraries, and posted on public access BBS provided:
    1. You may not profit by distributing QTPI. You may only charge for your time, media and postage costs. Any charges, excluding postage, shall not exceed US$6.00.
    2. You may not claim ownership of, or any rights to, the software.
    3. You may not place any restriction on the further distribution of the software.
  4. All QTPI archives must be distributed complete and unaltered.

If you find QTPI useful you are encouraged to make a small donation to an animal welfare charity.

Overview of QTPI

System Requirements

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.

What a stupid name

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.

Distributed files

QTPI is distributed in three parts.

QTPInnnE.ZIP
The QTPI program (nnn represents the version number).
QTPInnnD.ZIP
The QTPI documentation and support files.
XPRnnn.ZIP
The XPR file transfer libraries (nnn represents the version number).

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.

Source code

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.

Config Items

QTPI may be configured using the QJUMP Config program. The following items are configurable.

Data File
The default data file is `flp1_QTPI_dat'. This file contains all the configuration information for QTPI. You can change this name to suit your particular setup. QTPI does not use data defaults when locating the data file, you must specify the full path.
Colour Scheme
Monochrome or four colour
High Speed
(sic). This setting may improve data rates during file transfer on some hardware options.

Example Phone Book

The example phone book is just that, an example, I accept no responsibility for the accuracy of the information therein.

Installation

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
The program.
QTPI_dat
QBook_dat
QTPI data files (Program configuration and phone book)
XPR*_library
The XPR file transfer libraries (* represents a protocol, see section XPR Overview).
*_prefs
XPR 'preference' files, created and maintained by the XPR library to store your preferred parameters.

QTPI XPR Libraries

XPR Overview

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
The original file transfer protocol. It is widely supported on most hardware platforms. It is slow and does not support batch transfers. It is supported on most BBS. It offers a numbers of options, for example 128 byte blocks or 1K blocks and either checksum or CRC error checking. Use 1K blocks and CRC where possible.
YMODEM
As XMODEM, but with added batch capabilities. Offers a 'G' option that is faster at the cost of reduced error checking.
ZMODEM
A modern and sophisticated protocol that supports batch operations, automatic initiation of transfers, sliding windows and automatically variable block size depending on line condition. It is widely available on most platforms, but unfortunately not yet on many SMS/QDOS based BBS. If you use a PC based BBS (4th Dimension (still ?) for example), or a PBOX BBS (Nene Valley), use ZMODEM, it'll save your phone bill and nerves. ZMODEM is currently the default protocol on 'The Dead Letter Drop', the QTPI support BBS. ZMODEM can be auto-activated (i.e. respond to remote file transfer requests, both for send and receive.
SEALink
A sliding window protocol with batch capabilities. It is limited by its small (128 byte) block size. The protocol suffers from a number of design features that can result in handshake problems if even a single protocol character is lost or corrupt. Recent versions of XPR-SEALink (QTPI) and QBOX BBS (1.19m or later) contain debugged SEALinks that may work well. SEALink is the only batch protocol (at the time of writing) supported by the SMS/QDOS 'QBOX' BBS program
Kermit
A rather old fashioned batch protocol with good error detection and correction at the expense of speed. It will usually cope with very poor lines. Widely supported on mainframe computers and in academia. The XPR implementation supports 1K blocks and level 3 (CRC) error checking and will (allegedly, (actually after v3.2)) communicate with Kermit servers.
ASCII
Not a protocol at all ! It has no error checking capability. It offers translation between end of file format and can add a space to otherwise blank lines, which may be useful when using BBS mail editors.

XPR Preferences

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

QTPI Paths

QTPI_DAT

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.

  1. Define the environment variable QTPI_DATA. For example

    setenv "QTPI_DATA=win1_comms_QTPIxmodem_dat"

    You must have loaded (respr/lrespr etc) the `env_bin' extension for this.
  2. Invoke the program with the '-s' command option, for example,

    ex QTPI;'-s win1_comms_OldModem_dat'

    The space between the -s and the file name is optional.

The data file is located as follows:

  1. If a command option '-s' is given, use that.
  2. Else, if the environment variable is defined, use that.
  3. Otherwise, use the internal (Config) value.

The phone book file is defined from within QTPI, from either the Files or Preferences menus, and is stored in the QTPI_DATA file.

XPR Library Path

The XPR Libraries are located as follows:

  1. If the environment variable XPR_PATH is defined, use that.
  2. Else, if the 'libr dir' field from the 'Connection' menu is defined, use that.

XPR Prefs Path

The XPR preference files are located by:

  1. If the environment variable XPR_PREFS is defined, then use that.
  2. Else, if the 'Libr Dir' field from the 'Connection' menu is defined, use that.

QTPI supports the environment variable QEM_BUFFER (sic) to define a serial buffer size. The serial buffer size is determined by:

  1. If the environment variable QEM_BUFFER translates to a valid value,then use it.
  2. Else, If the Ser Buffer field is defined in the 'Connection' menu, then use that.
  3. Otherwise, use the default of 16K bytes.

Given reliable hardware (*Hermes, Atari, QXL with 16550 PC UART), then there is no reason to change this.

Getting Started

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.

  1. The QeM manual, QeM was a non-Pointer precursor to QTPI, so QTPI is a natural progression from QeM. This document is available from "The Dead Letter Drop BBS" and maybe others. It is tediously detailed (the document, not TDLD BBS).
  2. The LFAX manual (Lester Wareham) contains much useful material on connecting a modem to your system and solving modem problems, even if you're not using Class 1 fax.
  3. The Quill format doc file distributed with the version of QualSoft Terminal supplied with the QUANTA QConnect offer has some useful general advice on QL Comms.
  4. Well known SMS/QDOS comms luminaries such as Tony Firshman, Graham Goodwin and Wayne Weedon (and many others(1)) are extremely knowledgeable on these programs (and QL Comms in general). They are an excellent source of advice, you will find them (any many others) friendly, welcoming and helpful. Your local QUANTA sub- group or SMS/QDOS BBS Sysop may also be able to help. If you have any comms program running, my support BBS is described at the end of this document, see section The Dead Letter Drop.
  5. In extremis, you could ask me ! The most reliable way to contact me is by e-mail/file transfer to my BBS. Or by fax (see number at end of this document), phone, or even letter. Please do not expect me to (voice) phone you back. If you want a machine readable reply (e.g. the latest version of the program(s)) then please do not send me blank disks or IRCs, I would prefer US dollars (wouldn't we all ?). I can supply the latest software (QTPI, XPR libraries, QeM, ATP Off Line reader, QFAX etc) on the basis of US $4.00 per disk (i.e. this includes the cost of the disk plus postage), work on two software packages per disk. This just covers my costs, I don't actually make anything on this, but it's cheaper than you sending me blank disks; I cannot provide a free, air-mail, update service; I run a BBS for that. In my experience it's quite safe sending small denominations of cash wrapped up in a letter. Daria (my wife) really doesn't fancy trying to explain IRCs to the local Post Office. Postage from Oman is quite expensive, but at least the stamps are pretty. If you phone or fax, please note Oman is four hours ahead of GMT, it may be convenient for you to phone at 23:00 GMT, but not for me; you'll get an automatic data/fax/voice switching and answering service.

Using QTPI

Invoking QTPI

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.

QTPI Icons

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.

** Cannot display QTPI1.GIF **

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).

Files Menu

File Menu Options

The 'disk' icon invokes the FILES menu, the selection key is F6 (SHIFT-F1). The files menu offers the following options.

Capture All (C)
Captures incoming serial data to a file. Any currently buffered serial data is also stored.
Capture Now (A)
Captures incoming serial data to a file. Any currently buffered serial data is ignored.
Send Text (S)
Transmits a text file.
Upload (U)
Uploads (sends) file(s) using the currently defined XPR protocol.
Download (D)
Downloads (receives) file(s) using the currently defined XPR protocol.
XPR Protocol (X)
Displays a menu listing the available XPRs. You may load a new protocol from this menu.
XPR Prefs (P)
Invokes the current XPR preferences edit screen.
File Options (F)
Displays a menu listing default files and directories used by QTPI.
Review Buffer (R)
Displays the contents of the Review Buffer.
Run Script (N)
Runs (interprets or executes) a script file. See QTPIScript_Man for further details of the QTPI scripting language and facilities.

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
The location of the QTPI phone book `QBOOK_DAT'
Send From
The default directory for ASCII send files
Receive To
The default directory for ASCII capture
Upload Dir
The default directory for XPR upload
Download Dir
The default directory for XPR download
Libr Dir
The default location for XPR libraries
HOT Keys
The file describing QTPI specific HOT KEYS
Default Log
The default log (capture) file
Start with
Either 'Log open' or 'Log Closed'. Only valid if a default log file name is defined. If the setting 'Log Open' is used, then a capture log is open as soon as you invoke QTPI.
Script Log
The default output file for scripts invoked by QTPI.
Start Script
The name of a script file to be interpreted (or executed) when QTPI is invoked.
Stop Script
The name of a script file to be interpreted (or executed) when QTPI is exited.
User Menu
The name of a file defining the current "User Menu". The format of this file is described in section User Menu Item.

Review Buffer and Capture Options

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
Exit, close review window
CTRL-F2
Refresh, loads the latest data from QTPI's buffer.
CTRL-F3
Resize according to usual PE rules
CTRL F4
Move window
T
Top of buffer
B
Bottom of buffer
ALT DOWN
Page down
ENTER,DO
ALT UP
Page Up
Space,HIT
Line down
Shift space
Line up

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 Options

Capture All
Stores all data currently in the review buffer and subsequent data to the specified log file.
Capture Now
Stores all subsequent data in the log file .The 'Default Log' from the 'Miscellaneous' ('Handy') menu is a Capture Now' log.

Scripting

QTPI supports scripting via a number of extensions available using the "Client Server Manager" (CSM) Thing. This is described in the document "QTPIScript_Man".

HotKey Trickery

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:

  1. Any blank lines are ignored.
  2. Lines starting with a hash (#) are comments.
  3. The HOT_KEYS are defined as KEY,STRING.

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!

Modem Menu

Modem Menu Options

The MODEM menu is selected with F7 (SHIFT-F2). The menu offers the following options.

Dial (D)
Presents a text requester for a phone number to dial.
Disconnect
Sends the disconnect command to the modem.
Connect (C)
Sends the connect command to the modem.
Answer (A)
Sends the answer command to the modem.
Auto Answer (U)
Sends the auto-answer command to the modem.
Reset Line (R)
Sends an initialise command to the modem, resets some internal parameters.
Version (V)
Sends the inquire command to the modem. Displays an about box. Click on 'OK' or enter ESCape to continue.
AT Strings (T)
Defines modem commands for 'Hayes' compatible modems.

Modem Commands

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.
This command is sent before dialing and when the "Reset Line" or "Init Modem" commands are used. The defaults is "ATZ\r".
Pre Dial
The dial command. This is sent immediately before the phone number. The default is "ATD".
Post Dial
Sent after the phone number. The default is '\r' (carriage return).
Apres Dial
A string that may be sent between the "Pre Dial" string and the actual phone number. This may be used to invoke extra telecomms services, such as Mercury cost call back.
Disconnect
A command to disconnect the modem ("drop the line"). Should only be used 'in extremis', as failing to log off correctly will annoy BBS sysops. The default is "+++\|\~ATH0\r".
Connect
A command to seize the line. Default is "ATH1".
Answer
Command to get the modem to answer the phone. The default is "ATA".
Auto Answer
Command to get the modem to automatically answer the phone. The value after the "=" is the number of rings before the modem answers. The default is "ATS0=2".
Reset
Command to reset the modem. Default is "+++\|\~ATZ\r".
Version
Command to return version and status information from the modem. The default is "ATI0I1I2I3\r".
Get Carrier
A string returned by the modem when a carrier is detected ('a connect', 'going on line'). The default is "CONNECT". Supra modems return "CARRIER" before a CONNECT message. QTPI will start the call timer when it recognises the Get Carrier string.
Drop Carrier
A string returned by the modem when a carrier is lost ('a disconnect', 'dropping the line'). The default is "NO CARRIER". QTPI will stop the call timer when it recognises the Drop Carrier string.

QTPI Escape Sequences

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
Carriage return (ASCII 13)
\n
Line feed (ASCII 10)
\e
Current line terminator (as configured by the TX EOL Code field)
\\
The backslash character (ASCII 92)
\t
Tab character (ASCII 9)
\b
Backspace character (ASCII 8)
\s
Space character (ASCII 32)
\f
Formfeed character (ASCII 12)
\nnn
nnn is an Octal (base 8) number, inserts the ASCII value nnn into the text string. The text \033 would insert the ESCape character into the output string.
\xnn
nn is a sedecimal (hexadecimal, base 16) number. \x1b would insert the ESCape character.
\|
One second delay before next character.
\~
0.1 second delay before next character.
\+
10 second delay before next character.
\u
Sends the current phone book "login" string.

Preferences Menu

Preference Menu Options

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)
Displays an edit page for general, configurable items.
Files (F)
Displays file preferences edit page.
Modem (M)
Displays modem 'AT' edit page.

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.

Prefs Sub Menu

The pull down screen associated with this and other configuration related displays has three options displayed in the title bar.

Commands (F3)
Pulls down a command sub-menu, described below.
Abort (Shift-Tab)
Returns from the menu and restores (where possible), changed values to the previous value.
Quit (ESC)
Returns from the menu and uses all edited (new) values.

Prefs Sub Menu - Options

The 'Commands F3' menu has the following options, some of which may be unavailable, depending on context.

Open (O)
Opens and reads a data file. The setup described by the file will become the current setup.
Save (S)
Saves data to the current data file.
Save As (A)
Saves data to a user-defined file.
Defaults (D)
Returns values to default values.
Init Modem (I)
Initialises the serial line and modem.

Connection Options

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.

Emulation

The terminal emulation, VT52, VT100/VT102, ANSIn (n=1 to 4). ANSI modes are described in section Emulation Modes.

Port

The serial port, ser1 or ser2.

Parity

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.

Flow

This defines the hardware flow control (or not).

Translate

This item controls the serial device's internal translation of EOL/EOF codes. This maybe better handled by the QTPI RX/TX EOL parameters.

Baud

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.

RX EOL

The received character(s) that represent "End of Line".

TX EOL

The characters that QTPI transmits when you press ENTER (or Sending a text file, when a LineFeed character is encountered).

Del Char

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.

VT Wrap

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.

XPR Protocol

The selected file transfer protocol. When you DO or HIT this item, a menu will display the currently available file transfer protocol(s).

Beep

Controls if QTPI beeps on completion of XPR file transfers.

CSI

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'.

Arrow Keys

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.

VT Keypad

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 /

Comm Dev

This field was included at the request of a hardware developer. Do not use it.

Job Swap

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.

Xon/Xoff

Controls whether the QTPI uses the XON-XOFF protocol to pace the host.

Controls

Determines whether low ASCII (0-31) characters are Displayed or Interpreted.

Exit Baud

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.

Access

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.

Scroll

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.

Dial Try and Wait

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.

Cmd Delay

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.

Ser Buffer

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).

Start XPR

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.

On Wake

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:

  1. last 24 screen lines (delimited by LF)
  2. From last form feed (Home/Clear screen)
  3. last 2K in review buffer (or all if less)

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.

Caveat Non-Mousers

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.

Phone Book Menu

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)
Dial the selected entry
Edit (E)
Edit the selected entry
Zap (Z)
Delete the selected entry
Add (A)
Add a new entry
Open (O)
Open and read a new phone book file
Save (S)
Save phone book to the currently defined phone book file.
Save As (A)
Save phone book to user-defined file.
List (L)
List phone book contents to user-defined file or device.

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).

Edit phone entry

The screen to edit and amend phone book entries has the following entries.

Name

The name of the BBS or service.

Phone Number

The phone number of the BBS or service

Login

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.

Login++

If this string is defined, it is concatenated to the "Login" string.

Comment

A comment that may describes the host service. You can use this field for anything you like.

Modem Ini

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.

XPR Protocols

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.

Miscellaneous phone book fields

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.

Transfer Menu

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:

  1. Start the download on the remote system (BBS).
  2. Hit F7,D (or have it on a hotkey).

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.

Miscellaneous Icons

The Handy Items

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)
Returns the last used Answerback (the contents of a phone book login and login++ fields).
Clear Terminal (C)
Clears the terminal screen.
Output Toggle (O)
This item controls whether QTPI displays received text on the screen. This is not as ludicrous as it at first sounds ! If output is set OFF, then an indicator appears in the extreme left of the status bar. This is green when data is being received, and red when it is not. In monochrome, the indicator is white in the quiet state, black when receiving, in both modes it is in contrast to the menu bar. Such data is still logged and stored in the review buffer, and ZMODEM auto-receive will still work.
ReDial (R)
Redials the last selected phone number.
Def Log (D)
Toggles the state of the default log file. You must have defined a default log file.

User Menu Item

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 .....

End Item

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)
Save data and exit program.
Don't Save (D)
Exit, don't save data.
Go Back (G,ESC)
Abandon the exit (i.e. go back to the terminal screen).

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.

Auto Dial Menu

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)
Cancels the redial sequence and places QTPI in its internal 'connected' state.
Abort (A)
Just cancels the redial sequence.
Quit (ESC)
Sends the modem the disconnect string before canceling the redial sequence.

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.

XPR Details

XPR Hints

General XPR Hints

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.

Preloading Upload 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.

Specifying Upload files

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:

  1. A list file may not contain references to another list (@) file.
  2. Non-batch protocols (XMODEM, ASCII) will only send the first file if more than one is given or a wild card is specified.
  3. QTPI defaults to non-recurse into hard directories, but will recurse if the name is preceded by "-r ". The "-r " applies only to the next entry,so

    -r win1_a*_c win1_b* -r win1_c*_c

    would recurse into any hard sub-directory starting 'a' or 'c' and find (at any depth) _c files, while only root directory files starting with 'b' would be selected (and if there are hard sub-directories, these are ignored), so if you had.

    win1_boot
    win1_bas->
    win1_boredom

    Then 2 files would be returned from the middle wild card. The number of files returned from a wild card search in now limited only by memory. You are notified of the number of files found.

XPR Preference Settings

XMODEM Prefs

XMODEM has the following settings.

Text Mode (Y,N,C)
Y = yes, N = No, C = Computer's best guess. This defines whether XMODEM attempts to translate EOL codes between the LF used on SMS/QDOS, Unix, Amiga etc to the CR/LF of the PC. You should have this set to NO. The overhead of doing the translation is quite high.
CRC Mode (Y/N)
XMODEM can use CRC or Checksum error checking. If the host supports CRC, you should have this set to YES.
1K Blocks (Y,N)
XMODEM can transfer data in 128 byte or 1K (1024 byte) blocks. Set this to YES to use 1K blocks where possible.

YMODEM Prefs

YMODEM has the following settings.

Overwrite Mode (O,D)
Receive overwrite setting. If "O", then duplicate file names cause the old file to be overwritten, "D" causes the new file to have "_dup" appended to the name (and "_dupN" N=2-9999) if still a clash.
CRC Mode (Y,N)
As XMODEM
1K Blocks (Y,N)
As XMODEM
Option-G (Y,N)
An faster version (no ACK messages after each block), for use only with error-correcting modems (or clean connections).
Download Dir
The directory where downloads are stored. Use a ram or hard disk for speed and reliability. The file name is supplied by the host.

SEALink Prefs

SEALink has the following settings.

Path translate (Y/N)
Translates SMS/QDOS path names to and from Amiga/PC/Unix conventions. Not necessary if you only communicate with SMS/QDOS systems. Best left set.
Batch Upload Delay
A delay (in seconds) between files in a batch upload. A setting of 1 or 2 will give a slow host a chance to flush file buffers before the next file negotiation.
Macflow (U/D/A/N)
SEALink can use a form of XON-XOFF protocol, mainly to prevent an uploader from transmitting while the host is writing to disk. XPR SEALink has the following settings.
U
Honours Macflow when uploading.
D
Honours Macflow when downloading.
A
Honours Macflow uploading and downloading.
N
Does not use Macflow. This is the default setting.
Various problems with Macflow have been reported with the QBOX BBS where the file size exceeds the SEALink buffer. This is why the default setting (XPR-SEALINK 3.49+) is N. QTPI <-> QTPI SEALink and QTPI to TDLD BBS will work correctly with MACLFOW=A at both ends.
Default receive path
The directory where downloads are stored. Use a ram or hard disk for speed and reliability. The file name is supplied by the host.

Kermit Prefs

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
If "Yes", converts between SMS/QDOS and Amiga/PC/Unix formats.
Keep Incomplete
If "Yes", then the partial files resulting from incomplete file transfers are not deleted.
Host Server
Specifies if the remote computer is running interactive Kermit or as a "Host Server". Host server up and down load commands now work.
Text File
If Yes, carriage-return/line-feed pairs in the incoming packets are converted to a single line-feed before writing the packet to a file, and the opposite conversion is made when a file is sent to a remote system.
Packet Length
The Long Packets extension to Kermit is supported. Setting a packet length larger than 94 (the default) enters long packet mode automatically. If you use long packets, it is strongly recommended that you use block check 2 or 3 (see below) if the host Kermit supports them. The current limit is 1024 for XPR Kermit; the default value is 94, the longest standard Kermit packet.
Block Check
This can have the value of 1, 2, or 3, and chooses successively more stringent types of error checking on the incoming data: 6-bit checksum, 12-bit checksum, and 16-bit CRC, respectively.
Timeout
The length of time (seconds) XPR Kermit will wait for a packet before assuming it isn't coming. Default 5 seconds.
Retry Limit
The number of times XPR Kermit will attempt to send or receive the next packet of data before quitting. Notice that if the remote end simply stops sending, a length of time equal to the retry limit times the timeout will elapse before XPR Kermit actually exits. Default 10 retries.

ZMODEM Prefs

ZMODEM has the following settings

Text mode (Y,N,?,C)
Y = Text Yes; if receiving, translate CR/LF pairs or solo CR chars to normal QL LF chars. Ignore data past ^Z. If sending, suggests to receiver that they should receive this file in text mode. N = Text No; receive file verbatim, without changes. If sending, suggest to receiver that they receive this file verbatim, without translations. ? = Text status unknown; if receiving, use sender's suggestion as to whether to do EOL translations or not. If sending, tell receiver to use default mode, as we don't know either. C = Text mode set by Comms program; the library asks the comms program whether or not to use Text mode for each file. ZMODEM gets the mode from the text/binary flag in the file directory entry, so it may not always be right. Normally, set Text Mode = N.
Overwrite mode (Y,N,R,S)
Y = Overwrite Yes; if about to receive file with same name as one which already exists, delete the old file and receive the new file in its place. N = Overwrite No; if about to receive file with same name as one which already exists, append "_dup" onto the name of the new file to keep them separate. R = Overwrite Resume; if about to receive file with same name as one which already exists, resume receiving file data from the current end of the existing file. S = Overwrite Skip; if (etc.), tell sender never mind, skip this file, we don't want it. Batch transfers will move on to the next file in the set, if any.
Buffer size
Just leave at 16 Kb.
Frame size
Although normally avoided, ZModem has the ability to require an ACK to be sent from the receiver to the sender every X-many data bytes. Normally you don't want to use this feature, because not waiting for ACKs is part of how ZModem works so fast. However, this feature can be very useful in conjunction with file I/O buffering on slow devices (namely those floppy drives). This value should be set to 0 to disable ACKs (normal mode), or set it to the actual number of data bytes allowed between ACKs. If you have problems with hardware handshake or disk I/O, a value less than say 15360 (15Kb) may help.
Error count
This allows you to set the number of sequential errors which will be required to convince ZModem to abort the transfer. The normal value is 10, meaning that 10 errors must happen in a row with no valid data being transferred in order to cause an abort. This setting is provided for those using XPRZMODEM with a BBS, who may wish to use a relaxed setting, or those with really lousy phone lines who are desperate and patient enough to want the transfer to continue in spite of horrible performance.
Auto-activate receiver (Y,N)
Yes; if the comms program supports the ability, the ZMODEM will automatically go into receive mode when the start of a ZModem download is detected. QTPI supports this mode. No; don't try to automatically start downloading, make the user activate it.
Delete after sending (Y,N)
Yes; delete each file after it has been successfully sent. At your own risk. No; don't delete files after sending them.
Keep partial files (Y,N)
Yes; keep the fragment of a file received so far if file reception is aborted. This allows you to use the Overwrite Resume option above to pick up where you left off on your next attempt. No; delete any partially-received file after an aborted transfer.
Send full directory path (Y,N)
Yes; send full filenames including directory path to receiver. No; send only simple filenames, not including directory path.
Use received path (Y,N)
Yes; use full filename exactly as received, instead of using the Default Receive path option. No; ignore received directory path (if any), use Default Receive path option path instead. Leave this option at N if you value your sanity. (OK now HW ?).
Default Receive path
Path to use for received files. Stores all received files in directory "x" if "Use received path" is "N". Ignored if "Use received path" = "Y". "x" can be any valid device or directory, with a trailing "_".

ASCII Prefs

ASCII transfer has the following settings

EOL Convert (Y/N)
Conversion of LF to and from CR/LF.
Pad Blank Lines (Y/N)
If set (Y), any blank lines will have a leading space inserted. This may be useful with mail editors that take a blank line as end of message.
Inter-char delay
Inter-line delay
Delays (in 1/50 seconds) between characters and lines respectively.

Emulation Modes

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.

Config Options

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)

Miscellaneous

CharityWare

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.

Acknowledgments

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.

The author

QTPI was written by:

Jonathan Hudson,
PO Box 2272,
Ruwi 112,
Sultanate of Oman.

Tel/Fax : +968-699407

The Dead Letter Drop

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
Force data connect.
5
Force fax connect.

Using a serial mouse

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.

The Generation Game

QTPI later than v1.45 requires v1.38 ptr_gen or later. QTPI displays the PE version number in its 'About Box' when loading.

Upgrading PE

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.

QL Serial wiring

The non-standard nomenclature and writing adopted for the QL serial ports has caused much confusion. The following rules may help.

  1. Terminals, computers and printers (and QL ser2) are wired as DTE (Data Terminal Equipment).
  2. Modems (and ser1) are wired as DCE (Data Communications Equipment).
  3. The QL DTR signal is not DTR; it is RTS.
  4. Hardware handshake (usually) involves RTS and CTS; the DTR and DSR signals merely indicate that a device is online (not that it is necessarily ready to receive data).
  5. When wiring a DTE to a DCE, the cable should be connected "straight through", i.e. TXD - TXD, RXD - RXD, RTS - RTS, CTS - CTS etc.
  6. The QL cannot supply or detect DSR or DTR (see item 3 above), so connect DSR and DTR together in the plug.
  7. If your device is DCE (i.e. a modem), you can use it on ser2 with a straight through cable.
  8. If the device is a DTE (i.e. a printer), the you can use it on ser1 with a straight through cable.
  9. If you want to make a direct connection to another computer then you can connect a DTE to DCE (i.e. ser2 to ser1, PC/Amiga to ser1) with a straight cable, or DTE to DTE (ser2 to ser2 (or even ser1 to ser1), or PC/Amiga to ser2) with a cross-over cable.

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.

About this manual

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.

Index

4

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

u

v

w

x

y

z