Amateur Radio Packet Door

                               Program Flow



This file is provided to assist those who may have a problem in setting up and using
ARPD on systems/equipment that is substantially different than that used by the author.
If ARPD doesn't work as expected, read this file carefully for information which may
clarify what ARPD is expecting and what it will do under normal circumstances. 



When ARPD is called it creates a structure of values and strings and initializes them to
default values. These defaults include the screen colors, TNC port protocol, speed, etc.
These values remain at their default settings unless modified by lines in the
CONFIG.TNC file. 

The next step is to set the CTRL-C handler. Normally a DOS program will abort when a
user presses CTRL-C. It is handled by the operating system in much the same way as a
hardware interrupt and the "handler" must know that the TNC is using it as a control.
The default handler will cause the CTRL-C key sequence to be passed along to the TNC
as an ASCII character $03. (The alternate action, set by the configuration file is to send a
'modem-break' signal to the TNC for approximately 3/4 of a second.) If for some reason
the CTRL-C handler cannot be installed, the program will error out and refuse to run at
all. 

ARPD then looks for the CONFIG.TNC file. If this or any of the support files are not
present in the current directory ARPD will exit with an error message. The information in
the configuration file is plugged into the structure and minimal error checking is done. 

The next step is to fetch the DORINFO1.DEF file from the path listed in the
CONFIG.TNC file. This BBS drop file will point to the modem serial port and
parameters, the users logon name, time left on the system, etc. A comm port number of 0
and a baud rate of 0 indicates a local session and the BBS serial port is ignored. 

ARPD then assumes control of the BBS serial port. This is an area where many system
operators get a little confused. The modem serial port, when ARPD is called is
ALREADY initialized. It is running at the proper speed, protocol, etc. There is, in fact, a
user ONLINE! We don't want to start from scratch so we do just a couple of things. First,
we store the present parameters of the serial port so we can put it back just as we found
it if we want to make changes during the operation of the program. 

The BBS serial port will probably be under the control of a FOSSIL driver which may be
TSR. Since a TSR program may be operational concurrently with ARPD we must insure
there is no conflict. To prevent the FOSSIL from attempting to respond to interrupts
generated by the UART we turn all interrupts OFF! All communications with the BBS
comm port in ARPD is done with DIRECT port reads/writes. The BBS modem port is
NOT interrupt driven. 

Output to the modem port is done at the convenience of the program and since TNC
output is buffered there is no chance of losing data outgoing to the port under normal
conditions. Input from the port is done at keyboard typing rates and the speed at which
the program runs on even the slowest of machines allows for several polls of the UART
between characters. 

FOSSIL drivers are nothing more than replacement INT14 interrupt handlers. They
replace the standard BIOS services that come with your computer. Operating systems of
all types are notoriously lacking in communications services and as a result FOSSIL's
were created to better handle the task and at the same time make it appear that BIOS is
doing the work. 

By turning off interrupt reporting from the UART we bypass the FOSSIL and gain the
speed and accuracy of direct port writes without the overhead of system calls. This is
done in much the same way that some programs use direct screen writes in preference to
DOS/BIOS services to paint the screen. The speed difference is significant. Output to the
users screen with direct port writes in ARPD is also noticeably faster. 

With no further delay, ARPD displays the opening title screen. Currently in ARPD there
is only one version of the title graphics. The ANSI version. This may cause some concern
for some of your users who do not have ANSI loaded. They will see a screen that is
almost totally unreadable. Future versions may include ASCII versions at the expense of
a larger .EXE file. 

While the user is carefully reading the opening screen, ARPD opens the USERS.TNC
file and searches for a match for the logon name found in the DORINFO1.DEF file. If no
match is found the program outputs the 'ACCESS DENIED' screen, resets the BBS port
to it's previous condition and exits back to the BBS operating system. 

When a user is found in USERS.TNC the information is stored in the structure and TNC
port initialization is begun. This process is done in steps to insure that no conflict will
arise regardless of the present status of the TNC. 

The first step is to check for the presence of the TNCB.USY file in the current working
directory. The presence of this file indicates to ARPD that the TNC is already in use
from the computer end. Either the SysOp is using a terminal program in another
multi-tasking window or another user is operating on another BBS node. Multi-line
BBS's MUST have this protection to prevent TNC port conflicts. 

Unfortunately, early versions of ARPD had a bug which allowed this file to remain under
some conditions and would cause ARPD to deny access until the file was removed. Many
SysOps using the early versions have taken steps to insure that this file is not present at
any time. These steps are no longer necessary and should be removed to allow ARPD to
manage this file. 

If the TNCB.USY file is found the user is shown the 'TNC not available' screen and the
program exits to the BBS. If it is not found ARPD then checks for the presence of the
TNCNODE.TNC file. If it is found a DOS copy command is used to create TNCB.USY in
the current working directory. This is done exactly as from the command line: 

COPY TNCNODE.TNC TNCB.USY 

Because this and other operations in ARPD require DOS services it is important that the
BBS software shells to a new instance of COMMAND.COM when the door is called. 

If TNCNODE.TNC is not present, TNCB.USY will not be created. This is the proper way
to prevent TNCB.USY from denying access under any circumstances. Just remove
TNCNODE.TNC from the ARPD directory. 

Once TNCB.USY is in place, it is safe to begin the TNC serial port initialization process.
The information in the CONFIG.TNC file points to the TNC port and tells ARPD the
speed, protocol and interrupt to use. All of this information MUST be correct for your
system. Changing the lines in CONFIG.TNC will not change your hardware. The
information in CONFIG.TNC is not used to configure your system, it is telling ARPD
how your system is already configured. 

Port addresses and interrupts are hardware settings. You must list a serial port that is
actually connected to your TNC and an interrupt that is not used for any other device in
the system while ARPD is in use. On a multi-tasking system with all or most of the
interrupts in use by sound, CD-ROM, printer, etc., you may have a hard time coming up
with a free interrupt. Under these circumstances you may decide to use the printer
interrupt. You normally have control of printer operations and may use it when ARPD is
not running on the system. 



Keep in mind that the TNC is on a separate serial port from the BBS. The BBS operating
system knows nothing of what is happening while it is shelled out. No FOSSIL driver is
(or should be) in place for the TNC port. ARPD has nothing to do with the BBS software
or the requirements it has for normal operation. It is a completely stand-alone program
which simply uses the open phone line as an additional I/O device. 



TNC port initialization begins with storing the current interrupt handler address and the
values in each of the UART registers so the system will be returned to original condition
when ARPD exits. New values are then loaded into the UART registers which reflect the
parameters set in CONFIG.TNC. The address of the new interrupt handler is supplied to
the system and the computer is connected to the TNC. 

With the computer now connected we can determine the status of the TNC. The first
thing we want to check is the DSR (Data Set Ready) line. If the power to the TNC is
turned on the DSR line should be TRUE. If DSR is not TRUE the user is shown the same
'TNC not available' screen that appears when TNCB.USY file is in place. 

Since the TNC can be connected from either the computer side or the radio side we must
also check the condition of the DCD (Data Carrier Detect) line. DCD indicates that a
station has connected to the TNC on the radio port side. Normal TNC conditioning done
by ARPD will cause this connection to be broken, leaving the connected station to retry
out. Since the connection made to the TNC from the radio side before ARPD loads is
made under the call sign of the SysOp, users are not allowed to interrupt this external
use. 

In either of the above conditions, the user is shown a 'sorry' screen, the TNC and BBS
ports are restored to original condition and the program exits to the BBS. In either case
reporting of the true TNC status is mandatory. TNC hardware and software settings
must be such that these two lines reflect actual conditions. Both lines may be
configurable with either hardware or software settings on your TNC. Please read the
manual carefully and take the steps necessary to insure proper reporting. 

ARPD now asserts DTR (Data Terminal Ready) to inform the TNC it is connected and
ready to receive data. 

Assuming proper settings for protocol and handshaking between the serial port and the
TNC, ARPD is now ready to condition the TNC for this session. Like most assumptions,
this one may or may not be valid. One of the greatest sticking points in the proper
operation of ARPD is proper protocol and handshaking parameters. 



One of the most overlooked of the parameter settings for ARPD is protocol. Many
TNC's default to 7E1. The setting desired by most operators is 8N1. Many people set
the 8N1 in the CONFIG.TNC and assume the job is done. Not so. The proper settings
must be made in the TNC parameters held in BBRAM must also be set. Remember,
CONFIG.TNC is NOT configuring your system or your TNC. CONFIG.TNC tells ARPD
HOW YOUR SYSTEM AND TNC ARE CONFIGURED! 



Both ARPD and the TNC will normally allow for operation with either hardware or
software flow control. While either will work, both the TNC and ARPD must agree on
which to use. To change from the default of hardware handshaking to software
handshaking in ARPD it is only necessary to add XFLOW to the CONFIG.TNC file.
There may be several settings in the TNC necessary to change the default software
handshaking to hardware handshaking. Please note the difference in defaults. ARPD
defaults to hardware handshaking while most TNC's default to software. 

It is beyond the scope of this text to discuss serial data transfer completely. It is only
necessary to say that software handshaking relies on the TNC to send a device control
character (XOFF) when it can no longer accept data. When its buffer is cleared and it is
once again ready to receive, it sends another device control character (XON) to restart
the data stream. 

Hardware handshaking allows the data to flow as long as the CTS (Clear To Send) line
from the TNC is TRUE. If the CTS becomes FALSE data flow is inhibited. 

Either way it is done this flow control prevents the terminal from over-writting the TNC.
There is no flow control enabled to prevent the TNC from overrunning the computer. 

As the input from the TNC is interrupt driven and characters are buffered as they are
received in a 512 byte circular buffer there is little cause for concern. 

The RS-232 standard seems to have been taken as a suggestion rather than a command
by many serial device manufacturers. TNC manufacturers are no different. They
sometimes play fast and loose with the requirements for proper flow control. It is difficult,
therefore, to make one size fit all. 

Many 'fixes' have been placed in the ARPD code to allow for some of the variations
encountered with some makes/models of TNC. The following are a few rules which
ARPD lives by: 

If XFLOW is found in the CONFIG.TNC file, ARPD will not send to the TNC after
receiving an XOFF character. It will continue to receive and display data received from
the TNC while in this condition. The only way to restart flow from the computer to the
TNC is for ARPD to receive the XON character from the TNC. This means that the
XON/XOFF characters you have set in BBRAM in the TNC must be the STANDARD
values and you may NOT use one character for both in an attempt to toggle the state
with one value. 

In ARPD hardware handshaking the default is HALF DUPLEX. This means that ARPD
will assert the RTS (Request To Send) line before checking the state of the CTS (Clear
To Send) line. ARPD may be made to operate in the FULL DUPLEX mode by adding the
line RTSHIGH to CONFIG.TNC. In this state, the RTS line is held HIGH at all times.
The CTS line is still checked before sending data however. Normally your manual will
say little on the subject except for the FULLDUP command. THIS IS NOT THE SAME
THING! Simply try it both ways on your TNC to see which works. 

ARPD has been in release for over a year. In that time many changes have been made.
Some were done for ease in working with the code for me. Others were made at the
suggestion of users and the program is a better one for this input. 

Also over that period of time many reports of problems have been received. With one
exception, these problems have been the result of hardware configuration or hardware
failure. The most common problem reported to the author has been a condition which
would allow the user to control the TNC and even connect with other stations but no
characters were output to the remote or local screen in the door. 



This condition, in EVERY case, was caused by the serial port interrupt either improperly
configured or not working at all. Many people don't understand that the interrupt setting
requires a jumper or switch be set to the correct value on the serial card itself. Changing
the line in the CONFIG.TNC file WILL NOT SET THIS JUMPER! But the line in the
CONFIG.TNC file MUST AGREE WITH THIS JUMPER! If you are having a problem
similar to the one described above, this is the problem. 



Reports of ARPD not working in other operating systems have been received but the
author has no way of compiling for these systems and, frankly, little interest in them. This
is FREE software. It was written for MY system to please me. It is not intended to make
money, it is simply meant to allow other hams to have access to packet radio. If you find
it of value and use it, you're welcome to it. If it doesn't work for you, there are others out
there that may. Find the one that works for you. I make the same amount either way. 

                                    -73-
                               Dave W4KGU