Dec 262017
Check for line noise between BBS and remote system. Requires this program to be run on both the host and the remote machine. ASM source included.
File NOISECHK.ZIP from The Programmer’s Corner in
Category BBS Files
Check for line noise between BBS and remote system. Requires this program to be run on both the host and the remote machine. ASM source included.
File Name File Size Zip Size Zip Type
NOISE.ASM 33950 9927 deflated
NOISE.BAT 52 52 stored
NOISE.COM 3574 1971 deflated
NOISE.DOC 8512 2795 deflated
NOISE.OBJ 3607 2651 deflated
NOISE.XYW 6803 2667 deflated

Download File NOISECHK.ZIP Here

Contents of the NOISE.DOC file

Serial Communications
Diagnostic Program
Created 11-DEC-1988
Richard B. Johnson
PROGRAM EXCHANGE (303) 440-0786

This program is meant to be executed as a "live program"
from a BBS system and as an "external protocol" from a
remote-user's communications program. It will display in-
formation concerning the quality of the transmission channel
existing between the remote user and the BBS system. It may
be helpful in obtaining better quality service from the
telephone company.

Now to install this program.
If you are a BBS system operator, you create a batch file
containing the following information:

REM * Noise Program Batch file *
| | | | | |__ optional
| | | | |________ Execute mirror mode
| | | |____________________ COM port (1-4)
| | |___________________________ Program name
| |_________________________________ Path to program
|_______________________________________ Drive name

You then define this as a "live program" (DOOR) in your BBS
system software configuration.

If you are a remote-user, using a communications program
like TELIX or PCPLUS, you create a batch file containing the
following information:

REM * Noise Program Batch file *
| | | | |
| | | | |__________ Optional
| | | |________________ COM port (1-4)
| | |_______________________ Program name
| |_____________________________ Path to program
|___________________________________ Drive name

You then define this batch file as an "external protocol"
DOWNLOAD utility. In TELIX, you use ALT-O to get to the cor-
rect menu. You can use "NOISE" as the protocol name. Tell
TELIX that you do NOT wish to be prompted for a file name.

How to use this program.

- 1 -

Find a BBS system that has this line-noise live program
"door" installed. Execute the live program from your com-
munications program just as though you were going to execute
any other live-program. When the BBS system advises that you
execute your local NOISE.COM program, just hit the "down-
load" key (PgDn for TELIX) and select "NOISE". The program
should begin execution and keep a running tabulation of the
amount of data sent and received, the number of bad bytes
and the percentage error-rate.

When you wish to exit the program, just hit control-break,
escape, or control-C. Control-break and escape are "cleaner"
because they don't mess up your screen with a "^C" echo and
cause the screen to be overwritten.

You can also execute this program from the DOS command line.
If you were executing a communications program, you could
"shell" to DOS and execute the same command-line that you
used within the batch file. If your program exists within
the current path, you need not type the path and drive on
the command line. If the communications adapter port in use
in COM1, you need not enter anything on the command line. In
this case, "NOISE", entered at the DOS prompt or from the
batch file, is sufficient. In most cases, you will never
have to set the baud-rate with the "SPEED" command. When the
"SPEED" command is not found, NOISE just leaves the baud-
rate alone. It remains set to whatever it was when the com-
munications program was executing, which certainly should be
the correct baud-rate.

Other usage:
NOISE has two modes of operation. The default mode is to
send a string of bytes to a remote location and record any
errors in the string being echoed back. The other mode, the
"mirror" mode, simply echoes any characters received. It
functions as though you put a connection between pins 2 and
3 of a RS-232C connector to immediately echo any bytes re-
ceived on the RX line back to the TX line. The only differ-
ence between NOISE in the "mirror" mode and a piece of wire
is that if NOISE receives a ^C, it aborts. You can see from
this that NOISE can be very useful in debugging local RS-
232C connections as well as monitoring line-noise.

NOISE.ARC contains the complete source-code and documenta-
tion. The source code shows how to operate the UARTs used in
IBM-compatible computers in interrupt-mode. Interrupt-mode
operation is necessary if you intend to use these UARTs at
speeds much in excess of 2400 baud for communications. In
particular, the code shows how to:

(1) Set up the required interrupt vectors.
(2) Set up the UART

- 2 -

(3) Set up the interrupt controller.
(4) Operate both transmit and receive in interrupt-mode.
(5) Trap ^C and control-break so vectors may be restored.
(6) Restore interrupt vectors before program exit.
(7) Restore interrupt-controller mask program before exit.
(8) Restore saved UART parameters before program exit.

Restoring the machine-state before the program exits is very
important. The major failing of many, otherwise excellent,
home-made communications programs has been that the program
may exit without restoring the machine state. The next time
a program is executed, the system will crash if the machine
state has not been correctly restored.

If you use these routines for a tutorial, remember that it
is seldom necessary to operate the UART in interrupt-mode
for transmit, only for receive. Operation of the UART in
interrupt-mode during transmit will accomplish nothing use-
ful in a communications program since the program must wait
until the host receives the characters, processes them, and
sends back a response, before the interactive user sends
more characters. Operation in interrupt-mode for receive is
important so that no incoming characters are ever lost even
if the user is typing at the keyboard, reading from a file,

How the program works.
The program sends a string of all the ANSI characters (with
^C missing) to the remote computer. The remote computer
simply echoes these characters back.

The program then compares the characters sent with those
received. If they are the same, the block-number and byte-
count is updated on the screen and the cycle continues. If a
byte is missing or garbled, the program records this fact,
calculates a running error-rate, and then continues. The
process continues until aborted by the user or until the
modem carrier fails.

If the user aborts, a string of ^C characters are sent to
the remote computer to cause the remote program to abort
also. In case of an abort for any reason, the machine-state
is restored before the program terminates.

This program is supplied "as-is" with no warranty whatso-
ever. The complete source-code is provided so the users may
determine for themselves if the program may serve a useful

- finis -

- 3 -

 December 26, 2017  Add comments

Leave a Reply