Psion Homepage Logo.

Comms Link Manual, Part 4

Psion bar.



This chapter assumes that you are familiar with the Organiser programming language (OPL). OPL is described in detail in the Organiser 2 Operating Manual.

When Comms Link is fitted to the Organiser, OPL programs may use the LPRINT command to transmit data and also a number of communications procedures. These procedures are called in exactly the same way that you would call your own procedures and are loaded from the Comms Link device. You should avoid giving any of your own procedures the same name as any of the procedures described here.

In addition to the LPRINT command, the LSET, LINPUT$ and TRIG$ procedures may be used to communicate with any other device. They operate as follows:
LSET Set the communications parameters
LINPUT$ Receive a line of data
TRIG$ Transmit data then receive a line of data

Note that the user can abort the LPRINT, LINPUT$ and TRIG$ commands by pressing ON/CLEAR. This feature can be disabled by using the ESCAPE OFF command.

The remaining communications procedures are protocol based and may only be used when the Organiser is connected to a PC running the supplied communications program CL. If the Organiser is not connected to a PC which is running CL, the procedure will fail with a DEVICE READ ERR (error number 193) after a few seconds. Communication using protocol-based procedures is error checked and is generally more reliable than the non-protocol procedures.

Two procedures XTSEND and XTRECV allow OPL programs to exchange files (including binary files) with the PC. They are:
XTSEND Send a file to the PC
XTRECV Receive a file from the PC

You can directly access binary files, text files and "directory files" on the PC with a comprehensive set of file procedures. These are as follows:
XFOPEN Open a file
XFCLOSE Close the open file
XFGET$ Read data from the open file
XFPUT Write data to the open file
XFPOS Set the current file position
XFEOF Return end of file status

Only one file may be open at a time.

The following procedure names are used internally: XLCON

and you should also avoid these names.

If an error occurs in any of the Comms Link procedures an error is "raised" in the normal way. See, the "Error Handling" chapter in Organiser 2 Operating Manual for a description of OPL error handling facilities. If the OPL program does not trap errors, the program will terminate when an error occurs, displaying an error message which corresponds to the error number.

When using the protocol based procedures, the error can be generated by the software on the PC (the server) rather than the Organiser. For example, the server might fail with a DISK FULL error on the PC. When this is the case, the error number will have a value from 190 downwards and an error message will be displayed on the PC screen. There is no message text stored in the Organiser which is associated with such error number's and, although the OPL function ERR will correctly return the error number, ERR$ will always return "*** ERROR ***" rather than a specific error message.

You should always trap errors (using the TRAP and ONERR commands) when using the protocol-based procedures, otherwise you will not get an informative error message when the program terminates.


The LSET procedure is used to set the current value of the communications parameters without having to use the SETUP option in the COMMS menu. Parameters which are changed by LSET remain changed when the OPL program terminates. The syntax is:


where the procedure parameters correspond to the communications parameters which appear in the SETUP command under the COMMS menu.

The meaning of the parameters are described fully in the previous chapter "The COMMS Menu" in the section on the SETUP command. Except for the trailing % or $, the names of the procedure parameter names used here correspond to the parameter names used by the SETUP command.

Any procedure parameter may be set to -1 in which case the current value of that parameter is not changed by the call to LSET. For example, the line:

LSET:(-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 3, -1)

sets the TIMEOUT parameter to 3 seconds without affecting the current setting of any of the other SETUP parameters.

If there are trailing parameters which you do not wish to change, they may be omitted. The line:

LSET:(-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 3)

has the same effect as the previous example, and, as another example:


sets the Baud rate to 1200.

Omitting all the parameters to LSET is a special case and has the effect of restoring the complete set of communications parameters to their default values.

As in SETUP, the communications parameters may only take their value from a list of allowed values. The LSET parameters BAUD%, PARITY%, BITS%, STOP%, HAND%, ECHO%, and PROTOCOL% are specified in this way and the correctly ordered lists are:
Parameter Range Value List
BAUD% 50-9600 50, 75, 110, 150, 300, 600, 1200, 2400, 4800, 9600

For example, the line:


sets the communications parameters to 9600 Baud, even parity, 8 data bits and 1 stop bit.

The parameters WIDTH% and TIMEOUT% are set to zero to indicate NONE. WIDTH% should be an integer in the range 1 to 250 to specify the maximum line width and TIMEOUT% should be an integer in the range 1 to 255 to specify the transmission time out interval in seconds.

The remaining 6 parameters (REOL$, REOF$, RTRN$, TEOL$, TEOF$ and TTRN$) are a string of zero, one or two characters. A zero length string corresponds to the SETUP value NONE. A one or two character length string corresponds to the one or two characters of the corresponding SETUP parameter.

For example, the line:

LSET:(-1, -1, -1, -1, -1, -1, -1, -1, -1, "/"+CHR$(9), -1, -1, CHR$(9)+"/")

sets RTRN and TTRN such that "/" is converted to <TAB>on input and <TAB> is converted to "/" on output.


LPRINT is an OPL command which is built into the language. However, LPRINT will fail unless Comms Link is connected to the Organiser. LPRlNT has the same syntax as the PRINT command and operates in the same way except that output is transmitted to the connected device rather than to the display. Both PRINT and LPRINT are described in the Organiser 2 Operating Manual.

LPRINT data is subject to TTRN processing and, after TTRN processing, any occurences of <CR> and <SUB> are converted to TEOL and TEOF sequences respectively. Note that a trailing <CR> is added by the LPRINT command if the command does not end with a semicolon.

The LPRINT command uses the following SETUP parameters:



The LINPUT$ procedure is used to receive data from the communicating device. The use of the procedure is as follows:




where n% is an integer in the range 0 to 255. A special case of the command is when the value of n% is 0, when any received data in the input buffer is discarded. If n% is non-zero, LINPUT$ returns n% bits or, if an REOL or REOF is received, the characters up to and including the REOL or REOF. Typically, the n% will match the length allocated to the string variable data$ which is to take the received data.

The optional parameter t% specifies a timeout in seconds. If this parameter is omitted or has the value zero, LINPUT$ will wait indefinitely until an REOL or REOF sequence or n% characters are received. If t% is in the range 1 to 255, specifying a timeout interval in seconds, LINPUT$ returns with as many characters as it had received when the timeout timer expired. The timer expires when no character has been received for the specified time.

If you have the choice, it is safer to use a one character REOL and REOF. A two character REOL or REOF can be split over two LINPUT procedure calls if the first character of the happens to arrived as the last character allowed by the n% parameter.

The LlNPUT$ procedure uses the following SETUP parameters:



The TRIG$ procedure is similar to the LINPUT$ procedure except that a string is first transmitted before waiting for received data. The use of the procedure is as follows:

data$=TRIG$:(n%, a$)


data$=TRIG$:(n%, t%, a$)

The parameters n% and t% are as for LINPUT$, above.

The parameter a$ is the string to be transmitted before waiting for received data. The output string is subject to TTRN processing and any occurrences of <CR> and <SUB> are converted to TEOL and TEOF sequences respectively.

Using the TRIG$ procedure is equivalent to an LPRINT command followed by a call to LINPUT$ and is slightly faster.

The TRIG$ procedure uses the following SETUP parameters:



The file transfer procedures, XTSEND and XTRECV, are used to send a file to and receive a file from a PC which is running the supplied communications program CL.

The procedure to send a file, XTSEND, has the syntax:

XTSEND: (remote$, local$, type%)

and the procedure to receive a file, XTRECV, has the same syntax:

XTRECV:(remote$, local$, type%)

XTSEND sends the Organiser file with file name local$ and of type type% to the PC, giving it the pathname remote$. Any existing file on the PC of the same name is replaced.

XTRECV provides the converse operation to XTSEND and restores the PC file with file name remote$ to the Organiser, giving the created file the file name loca1$. Any existing file on the Organiser of the same name is replaced.

The organiser file name local$ includes the device name (A, B, C or D) in the same way as, for example, the OPL OPEN command.

The PC file name remote$ may either give the full pathname of the file or just the file name, in which case the current directory (when CL was run) will be used. Any "/" character in remote$ is translated to a "/" character by the server, allowing pathnames to be easily specified. If the file name does not contain a file name extension, an extension is generated from the type% parameter and added to the file name. The generated extensions are:
type% Extension
2 OB2
3 OB3
4 OB4
5 OB5

The parameter type% specifies the Organiser file type and should be one of the following:

0 - a data file
1 - a procedure file (source only)
2 - a diary file
3 - a procedure file
4 - a Comms link setup file
5 - a spreadsheet file

File types 0 and 1 produce text files on the PC which can be manipulated directly on the PC. For example, you can edit a procedure file on the PC using your normal editor or word processor. Using XTSEND and XTRECV with file types 0 and 1 form the same functions as TRANSMIT and RECEIVE in the COMMS menu (as described in the previous chapter). In TRANSMIT and RECEIVE, the choice between FILE or PROCEDURE corresponds to file types 0 and 1 respectively.

File types 2 to 5 inclusive produce binary files on the IBM PC. These files are not directly usable on the PC except by the XTRECV procedure when restoring files to the Organiser.

File types 1 and 3 both deal with procedure files (which are binary files) on the Organiser. When using TRANSMIT or XTSEND with type% set to 1 the procedure source (i.e. the plain text version) is extracted from the binary procedure file to create an editable text file on the PC. When using RECEIVE or XTRECV with type% set to 1, the text file is converted to a binary procedure file on the Organiser which contains only the source (so you have to translate the procedure before you can call it). Transfers with type% set to 3, however, correspond to simply copying a binary file from one machine to another where the procedure file may contain the source only, the source plus the translated source or just the translated source.

Transfers using file type 3 can be used to save translated procedures on the IBM PC which can later be restored and called in the normal way, effectively providing a means of loading and running OPL programs which are stored on the IBM PC.

The XTSEND and XTRECV procedures use the following SETUP parameters:


Note that XON/XOFF handshaking is disabled regardless of the value of HAND. TTRN is only used by XTSEND and only when type% is 0. RTRN is only used by XTRECV, and only when type% is 0.

Apart from the normal Organiser errors, the following server errors may raised by XTRECV or XTSEND:


The file access procedures provide access to one file at a time on an attached PC running the supplied communications program CL.


The XFOPEN procedure is used to open a tile on the PC. The syntax is:

XFOPEN:(remote$, amode%, ftype%)

where remote$ is the pathname of the file on the PC, amode% specifies the file access mode, and ftype% specifies the remote file type.

Only one file may be open at a time. XFCLOSE must be used before another file may be opened using XFOPEN or before a file can be transferred using XTRECV or XTSEND (the procedure will fail with error number 199, FILE IN USE, if a remote file is already open).

The PC file name remote$ may either give the full path name of the file or lust the file name, in which case the current directory (when CL was run) will be used. Any "/" character in remote$ is translated to a "\" character by the server, allowing pathnames to be easily specified.

The file type is specified by the parameter ftype% which is one of:

1 - TEXT

Binary files are random access files which consist of a byte stream and have no record structure.

Text files are variable length record sequential tiles where each record normally contains characters with ASCII codes greater than 31 (although this is not enforced). The maximum record length (excluding any record terminator) is 254 bytes - the maximum string length in OPL. On the PC each record is terminated by <CR>,<LF>.

Directory files behave like sequential files which may only be read. The path name remote$ specifies a normal PCDOS directory search string. When a directory 'file' has been opened, the records made available to XFGET$ each contain the name of one file found in the path and directory given in remote$. When the last record has been accessed and EOF is returned, the file is automatically closed.

A file may be opened in one of five access modes, as specified by the parameter amode%:

0 - READ

When amode% is READ, the remote file is opened for reading only and XFOPEN will only fail if the file cannot be found.

When amode% is CREATE/REPLACE, a new file is created for writing and, if the file is a binary file (i.e. a random access file) reading. Any existing file of the same name is deleted.

When amode% is REPLACE, XFOPEN behaves as for CREATE/REPLACE except that it will fail if the file does not already exist.

When the amode% is CREATE, XFOPEN behaves as for CREATE/REPLACE except that it will fail is the file already exists.

When amode% is UPDATE, the file is opened for writing and, if the file is a binary file (i.e. a random access file), reading. XFOPEN will fail if the file does not already exist.

When ftype% is DIRECTORY, XFOPEN will fail unless amode% is READ. When ftype% is either BINARY or TEXT, any of the above values of amode% are valid. Setting amode% to UPDATE has a different meaning depending on whether ftype% is BINARY or TEXT.

When amode% is UPDATE and ftype% is TEXT, the file is positioned initially at the end of the file, allowing records to be appended to the file. When ftype% is BINARY, the file is positioned initially at the beginning of the file end you may read and write to the file.

Apart from the normal Organiser errors, the following server errors may be raised by XFOPEN:


Closes the open file and returns when the file has been closed. XFCLOSE has no parameters XFCLOSE is harmless and reports no error if there is no open file.


XFEOF returns zero (false) if a file is open and -1.0 (true) if a file is closed. When an end of file is reached by a call to XFGET$, described below, the file is closed and XFEOF will return true.


The XFGET$ procedure reads data from the current position in the file and returns the data as a string. The syntax is:


where the returned string is required to be of length len% or less. The parameter len% may be between 0 and 255 inclusive.

If the file is a binary file (ftype% was 0 in XFOPEN), XFGET$ reads len% bytes from the file and advances the file position by len% bytes. Unless the end of file is reached, the returned string is of length len%.

When an end of file is encountered, less than len% bytes may be read and a string which is shorter than len% will be returned. The file is then closed and the XFEOF procedure will return -1.0 (true).

If the file is a text file or a directory file (i.e. ftype% was 1 or 2 in XFOPEN), XFGET$ reads a record from the file and positions to the next record. The returned record data does not include the <CR><LF> record terminator. If XFGET$ is called after the last record has been read, a zero length string is returned, the file is closed and XFEOF will return -1.0 (true). Apart from the normal Organiser errors, the following server errors may be raised by XFGET$:


The XFPUT procedure writes data to the current position in the open file on the PC. The syntax is:


XFPUT will fail if the file is open for reading only (i.e., amode% was 0 in XFOPEN).

If the file is a text file (ftype% was 1 in XFOPEN), a new record is appended to the file.

The file position is set to the end of the data written by XFPUT.


XFPOS sets the current file position on binary files and returns the new position. XFPOS will fail if ftype% was not 0 in XFOPEN. The syntax is:

newpos=XFPOS:(mode%, pos)

The new position is specified by the parameters mode% and pos. Depending on whether mode% is 0, 1 or 2, the parameter pos is interpreted as follows:

0 - relative to the start of the file
1 - relative to the current position
2 - relative to the end of file

For example. when mode% is 1 and pos is 0, XFPOS returns the current position, leaving it unchanged.

The remote file access procedures use the following SETUP parameters:


Note that XON/XOFF handshaking is disabled regardless of the value of HAND.



The names of the ASCII characters numbered 0 to 32 are shown below. For the printable ASCII character set, see appendix A of the Organiser 2 Operating Manual.
0 NUL 16 DLE
1 SOH 17 DC1 (XON)
2 STX 18 DC2
3 ETX 19 DC3 (XOFF)
4 EOT 20 DC4
5 ENQ 21 NAK
6 ACK 22 SYN
7 BEL 23 ETB
8 BS 24 CAN
9 HT 25 EM
10 LF 26 SUB
11 VT 27 ESC
12 FF 28 FS
13 CR 29 GS
14 SO 30 RS
15 SI 31 US



This appendix describes the hardware interface which is presented by the Comms Link cable and contains technical information which may be required for advanced communications applications or for building your own adaptor.


The RS232 standard is based on an assumption that communicating devices do so via a pair of modems as in figure B.1.

Figure B.1 Connecting via Modems

In the standard, the more general terms DTE (Data Terminal Equipment) for computers and printers and DCE (Data Circuit Terminating Equipment) for modems are used.

If the DCE and DTE have standard RS232 sockets, the DTE will have a 25 pin D-type male connector and the DCE will have the corresponding female connector. The RS232 cable between the two is a regular "straight through" connector which is male at one end and female at the other. In fact, you only need a cable at all because the connectors are usually mounted on the chassis of the equipment and cannot be physically brought together.

Modems are used to transfer data over long distances using low grade wires which were designed for transferring speech rather than data. In practice, the RS232 standard is often used over short distances where there is no need for a pair of modems and the computers (or DTEs) are connected "back to back" as in figure B.2.

Figure B.2 Direct Connection

In figure B.2, the cable between the computers (or DTEs) is not a simple "straight through" cable, as exists between the DCE (modem) and DTE (computer) in figure B.1. The cable in figure B.2 replaces the pair of modems and is called a "null modem cable". A standard null modem cable is female at both ends and is wired specially to simulate the effect of a modem link.

Although the Organiser is a DTE, the majority of Comms Link users will not be using a modem, so a null modem cable is "built in" such that the Comms Link cable will plug directly into most computers without requiring additional leads or adaptors. To the DTE (e.g. computer), the Organiser 25 pin D-type female connector emulates a DCE (modem) interface.

Emulating a DCE works when the DTE conforms strictly to the RS232 standard. This is true of most computers and some printers. For example, the IBM PC/XT and most compatibles conform to the standard and the Comms Link connector will plug directly into these computers. However, some computers and many printers do not conform and, for example, both the IBM AT and Apple Macintosh use non-standard 9 pin connectors. Other DTE's, particularly printers, may use a standard 25 pin connector but with a non-standard gender (female rather than male).

When the device you are trying to connect to does not present a 25 pin male DTE interface, either because it is a non-standard DTE or a DCE, you need an adaptor.


Although there are 25 pins on the D-type socket, only eight are connected through to the Organiser. Because the built-in null modem cable swaps the active lines, it is easy to get confused about the names of the lines, depending on whether you take the view of the Organiser or the attached DTE. Figure B.3 shows the pin assignments on the Comms Link socket, the signal names from both points of view and the direction of signal flow for each pin.
FG 1   FG
SG 7   SG
RD 2 <- TD
TD 3 -> RD
CTS 4 <- RTS
RTS 5 -> CTS
DSR 20 <- DTR
DTR 6 -> DSR

Figure B.3 Comms Link cable pin assignments

FG and SG stand for Frame Ground (earth) and Signal Ground (common return) respectively.

TD and RD stand for Transmitted Data and Received Data and carry the data signals.

RTS and CTS stand for Request To Send and Clear To Send and are the control lines which support RTS/CTS handshaking.

DSR and DTR stand for Data Terminal Ready and Data Set Ready. Although the Organiser can read pin 20, it cannot drive pin 6. However, pin 6 is connected to pin 20 via the Organiser so that if the DTE drives pin 20, it will see an asserted pin 6.

Pin 20 on the Organiser is also connected in a way which has the same effect as the ON/CLEAR key. The Organiser can be switched on by asserting pin 20 an it will not switch off while pin 20 is held high. The main application of this feature is when the Organiser is connected to an auto-answer modem which is waiting to be dialled. Connecting an Organiser to a modem is discussed in the following section.


An adaptor consists of two connectors which are wired back to back. One of the connectors is a 25 pin D-type male connector which plugs into the female connector on the Comms Link cable while the other end of the adaptor plugs into your computer, printer or modem. The wiring between the connectors may swap some lines (in the case of a modem adaptor), exclude unnecessary connections and correct for any non-standard pin assignments.

Connecting To A Printer

Many printers present a DTE female connector (rather than the standard male connector) and a gender changer will often suffice. However, some printers also require DCD (Data Carrier Detect) to be asserted and a printer adaptor may accomplish this by connecting pin 8 to pin 5. The printer adaptor supplied by Psion is reversible and is based on figure B.6.
1---1 (FG)
2<--2 (ID)
3-->3 (RD)
4<--4 (RTS)
8,5-->5,8 (CTS+DCD)
6-->6 (DSR)
7---7 (SG)
20<--20 (DTR)

Figure B.6 Printer Adaptor

Connecting To A Modem

To connect the Comms Link interface to a modem (or to another Organiser), you need to swap the three pairs of signal lines (TD and RD. RTS and CTS, DSR and DTR) back from a DCE interface to a DTE interface.

If you wish to originate (i.e. dial from the Organiser), the link on the Organiser between DTR and DSR will stop the modem from working. If DTR and DSR pins are not connected on the modem, the modem circuitry will usually pull DTR to a state which will allow the modem to work. For simple modem use, it is advisable that pins 6 and 20 are not connected, and Psion supplies a modem adaptor which is based on figure B.7.
1---1 (FG)
2<--3 (RD)
3-->2 (TD)
4<--5 (RTS)
6    20 (DTR)
7---7 (SG)
20    6 (DSR)

Figure B.7 Modem Adaptor

If you wish to connect the Organiser to an auto-answer modem in such a way that it can wait in an "off" state (where it uses very little power) and be woken up when the modem answers a call, you should connect DSR (pin 6 on the modem to pin 20 on the Organiser). In this case, the adaptor will not be reversible and you should label the ends appropriately. Use the OPL command OFF to switch off the Organiser and pause until DSR is asserted by the modem when it answers a call.


Because the Comms Link cable contains the software on ROM and because of power conserving features of the Organiser, the operation of the RS232 port is more complex than for other computers.

In this section, the RS232 lines are described from the Organiser point of view and you should read the left hand column of figure B.3 when converting the pin names into pin numbers.

The RS232 port can be in one of three states, OFF, POWERED and SELECTED.

The OFF State

In the OFF state, no voltage is applied to any of the pins of Comms Link connector and the signals seen by the connected device will depend upon the hardware design of that device.

The RS232 port is OFF when no power is supplied to the top port. Actually, the Organiser architecture is such that power is either supplied to all three ports or to none of them.

Normally, in the interests of power conservation, the Organiser switches oft the ports whenever the software is waiting for a key press. In Comms Link terminal emulation, however, this effect is disabled.

When the Organiser is switched off, the ports are also off. The Organiser is switched off when the top-level menu OFF command is used, when the Organiser has automatically switched itself off after being left for five minutes without a key press (except in terminal emulation), or when the OPL command OFF is used.


The RS232 port is in the POWERED state when power is supplied to the ports and the RS232 hardware is not selected.

In the POWERED state, the Organiser is unable to send or receive data, to set the state of RTS, or to read CTS or DTR. However, the hardware drives TD and RTS to the MARK state such that the communicating device will see no data and, provided that it is using RTS/CTS handshaking, it will not send any data to the Organiser. If XON/XOFF handshaking is enabled, the Comms Link software sends an XOFF followed by a delay (to give the communicating device a chance to respond to the XOFF) before entering into the POWERED state from the SELECTED state.

The RS232 port is in the POWERED state when a datapack is being accessed or when the Comms Link ROM is being accessed. For example, a procedure call to any of the extensions to OPL supplied by the Comms Link will put the RS232 port into a POWERED state.


The RS232 port is in the SELECTED state when power is supplied to the ports and the RS232 hardware is selected.

In the SELECTED state, the Organiser is able to send and receive data, drive RTS, and read CTS and DTR. Received data is stored in a receive buffer by an interrupt routine.

When the RS232 port is in the SELECTED state, RTS is output in the SPACE state and is only temporarily output in the MARK state when RTS/CTS handshaking is enabled and the receive buffer is nearly full. Also, when RTS/CTS handshaking is enabled, transmission is paused when CTS is in the MARK state (otherwise CTS is ignored). When CTS is not connected on the Organiser, it floats to the MARK state and RTS/CTS handshaking should not be enabled when CTS is not connected.

The RS232 port is in the SELECTED state during terminal emulation and when data is input or output to the RS232 port. It normally remains in the SELECTED state until something happens to move it to the POWERED state (e.g. a datapack access) or to the OFF state (e.g. waiting for a key press).


Ascii codes, 2
Auto-answer modem

Backing up Comms Link disk
Binary files

  menu, 2
Comms Link
Comms Link hardware
Connector wiring

Data files, 2
  backing up
DTR handshaking, 2, 3

Electronic mail

Fitting Comms Link

Gender changer, 2, 3

Handshaking, 2, 3

Line length

Modem, 2, 3

Null modem

Pin assignments
  line length, 2
  setting up
Printer adaptor, 151
  capture buffer
  data files
  from OPL
  MAIN file
  procedure files
Procedure files, 2
  NONE, 2, 3, 4, 5
  PSION, 2, 3, 4
  XMODEM, 2, 3, 4, 5
protocol, 2, 3

Receive end of file (REOF), 2
Receive end of line (REOL), 2
Receive translate (RTRN), 2
Receiving files, 2, 3
Removing Comms Link
RS232 OFF state
RS232 POWERED state
RS232 SELECTED state
RTS/CTS handshaking, 3

Saving a SETUP
Screen scrolling
Sending files, 2, 3
  BAUD, 2, 3
  BITS, 2, 3
  changing parameters
  default values
  editing parameters
  HAND, 2, 3
  parameters, 2
  PARITY, 2, 3
  PROTOCOL, 2, 3, 2
  REOF, 2
  REOL, 2
  RTRN, 2
  STOP, 2, 2
  TEOF, 2, 3
  TEOL, 2, 3
  TTRN, 2, 3
  valid parameters
  WIDTH, 2

Terminal emulation
Transmit end of file (TEOF), 2, 3
Transmit end of line (TEOL), 2, 3
Transmit translate (TTRN), 2, 2
Transmitting files, 2, 3

XMODEM protocol, 3
XON/XOFF handshaking, 2, 3

Organiser bar.

These pages should be viewed using Netscape 4.03 or Microsoft Internet Explorer 3.02 at 800x600 pixels.
Left arrow Comms Manual Chp. 6 ~ Homepage ~ Developer Manual Right arrow