Introduction
There are a number of ways that the serial port can be used. Modems,
 bar code readers, and many other devices deliver data over this port or
 are regulated by it. Although standards do exist, in the final
 analysis, the type of communication is different every time.
The functions in this chapter offer possibilities for data transmission
 and allow you to influence control signals. These functions do not
 support any particular protocol or any specific instrument. For a few
 expanded applications, like the XMODEM protocol, you should find
 sufficient information in the example programs for Clipper Tools.
Port Parameters
All the parameters for the port, like baud rate, parity, file length,
 and stop bits, are fully adjustable. It is possible to change the
 settings for a port without closing it. In this way the transmission
 speed can be changed without losing the contents of the buffer or
 terminating an existing connection (DTR-signal).
Data Transmission
Using Clipper Tools, you can use up to four serial ports
 simultaneously. You can create a sending and a receiving buffer of up
 to 64kB in size. The characters for the background transmission mode
 are placed in the sending buffer, while characters received through the
 port are stored using an interrupt handler. You can determine the
 number of characters in the receive buffer from your Clipper program,
 and as many of the available characters as you like can be read.
 Additional special control functions exist for the sending buffer that
 give the governing program full control. It is also possible to engage
 a software or hardware handshake that is performed completely in the
 background.
Handshake
As previously mentioned, Clipper Tools functions support both a
 hardware and software handshake. As soon as the receiving buffer
 threatens to overflow by at least one page, a special handshake
 character is transmitted that tells the other side that no further data
 should be transmitted. Whether you implement the hardware or software
 handshake depends upon the type of data transmission. Hardware
 handshakes use physical port controls. These port controls are usually
 RTS and CTS, so within the scope of Clipper Tools functions, these
 control ports cannot be used for modem transmission. Modems are
 generally not able to reproduce port controls directly over the
 transmission route (i.e. telephone connection). A software handshake
 must be implemented in such cases.
A software handshake uses characters from the ASCII character set to
 control the data flow. The ASCII character set is a standard which
 defines the XOFF (stop data, transmission off) as CHR(19) and the XON
 (continue transmission, transmission on) as CHR(17). (You will
 recognize the similarity to your keyboard since CHR(19) corresponds to
 Ctrl-S, and CHR(17) corresponds to Ctrl-Q).
If one of the handshake processes is implemented, the software must test
 both sides to see if the receiving buffer has been filled. The software
 then either deactivates the CTS controls or sends an XOFF character. By
 contrast, when sending data you must constantly test to see if the RTS
 input from the remote station has been deactivated or if an XOFF
 character has been received. In both cases transmission must stop
 immediately.
Since you can never be sure if the remote stations stop immediately
 after receiving an XOFF character, the internal handshake becomes active
 when the buffer is 75% full. If the remote stations ignore the
 handshake, the 75% limit is probably insufficient at a set buffer size
 of 100 byte (which equals a 25 byte reserve).
The techniques described here for the handshake are managed completely
 by the Clipper Tools routines. They do not concern themselves with
 the interface cards or the Universal Asynchronous Receiver Transmitters
 (UARTS). It is sufficient to activate the selected method, which allows
 your program to regulate the status of the sending and receiving buffers
 on an ongoing basis.
Protocols
As previously mentioned, remote data transmission is, as a rule,
 implemented only through a software handshake. A significant
 disadvantage to this method is that the characters used for flow
 control, CHR (19) and CHR(17) can no longer appear in the original data.
 Because these characters appear in binary files, remote data
 transmission is not possible -- transmission protocols must be used.
 You find XMODEM routines written in Clipper in the example programs.
 Using the Clipper Tools port functions and this example as a basis,
 other protocols can be developed fairly simply.
Firm protocols are not provided within Clipper Tools because their
 realization in Clipper code presents no real advantage. It is more
 important that you have the ability to create your own protocols so that
 you are not locked into whatever protocol is within Clipper Tools.
Control Signals
You can set or query all important port connector control signals, like
 CD (carrier detect), DTR (data terminal ready), etc.. To simplify your
 programming, there is a separate function for each signal. For all
 other status and control information, which is seldom required in serial
 communications, you can read or describe the corresponding UARTS
 register of the port directly.
Direct Hardware Access
All Clipper Tools port functions directly address the hardware.
 Working over BIOS or even DOS calls would be impractical or even
 impossible. We therefore presuppose 100% hardware compatibility with
 the established IBM personal computer industry standard.
In order to guarantee that everything is functioning properly, both
 ports must be equipped with either UART 8250 or the compatible 16450.
 When you use the 8250, interrupt controlled transmission is only
 possible up to 2400 baud. Technical details regarding the ports and the
 UART registers can be found in the corresponding technical instructions,
 like the IBM Technical Reference Manuals.
I/O Addresses and Interrupt Requests
Clipper Tools assumes the following basic settings for the four
 ports:
Table 1: Standard Port Settings
 ------------------------------------------------------------------------
 Port I/O Address IRQ
 ------------------------------------------------------------------------
 COM1: 3F8H 4
 COM2: 2F8H 3
 COM3: 3E8H 4 - Not specifically defined
 COM4: 2E8H 3 - Not specifically defined
 ------------------------------------------------------------------------
In contrast to COM1 and COM2, the I/O addresses and IRQs for other ports
 are often different. If you want to use hardware that is not entirely
 compatible, Clipper Tools has additional functions that you can use:
 COM_SETIO() and COM_SETIRQ(). When you use these functions, the I/O and
 IRQ settings for the port routines can be changed to the selected
 values. However, please notice that incorrect settings can have a wide
 range of consequences when they come in conflict with other hardware.
 These consequences include data loss or damage to hardware.
The correct settings for your hardware can be found at any given time in
 its accompanying documentation.
Possible Hardware Conflicts
Clipper Tools recognizes the four addresses mentioned above for the
 ports COM1 to COM4. The COM_NUM() function uses these addresses to
 determine the number of available ports. For example, if the PC has a
 built-in ArcNet adapter, you can have a conflict between the I/O
 addresses. The Clipper Tools routine addresses 02EAh, which is
 defined totally differently for the ArcNet adapter than for a serial
 interface. In this case an existing network connection would probably
 be disconnected. The COM_SETIO() function can provide assistance by
 designating the second parameter as 0:
COM_SETIO(<port>,0)
The corresponding standard address within the internal address table is
 deleted and access to other hardware is avoided. However, this is only
 possible if the COM_NUM() function has not previously been called within
 the program. (In this case the interface would have already been marked
 "in use.")
Important Notes
As the table of default settings indicates, it is possible for multiple
 ports to use the same IRQ -- a procedure known as interrupt sharing.
While Clipper Tools functions support these procedures, standard port
 hardware usually does not. Specialized multiple port cards are
 available from different manufacturers for this purpose.
Generally we cannot guarantee that interrupt sharing can be
 implemented.
Clipper Tools supports up to four ports, each with sending and
 receiving buffers of up to 64kB and speed of up to 19200 baud. This is
 not to say that all this could be used at the same time to its highest
 limit. Eight buffers at 64kB are not possible. The buffers must be in
 conventional memory because the buffers are handled by interrupt
 routines. The number of ports and the speed with which they can
 function correctly is dependent upon the computer being used.
Differences from BASIC
In contrast to other programming languages (like BASIC),
 COM_OPEN()/COM_INIT() do not influence control signals. If you want to
 address a modem over the serial port using Clipper, you must set DTR
 and any other signals yourself, using the corresponding Clipper Tools
 functions.

Note :

    This section of CTools  considered as obsolete and details skipped.