Documentation for Send and Rcv Version 1.0
Copyright 1996, by Rob Meredith

Introduction

Send and Rcv are two commands that can be used to move files between two
computing devices through a serial port.  They are both MS-DOS utilities, and
must be used from the command line.  They are small and efficient, allowing
them to be used on older IBM compatibles, as well as those of today.  They
support a wide variety of serial communications options, making them perfect
for even the most demanding user.

Send and Rcv are most useful in situations where it is necessary to move data
between an MS-DOS machine and some other serial device, such as a personal
note-taking device like a Braille 'n Speak, a stand-alone reading machine, or
some other type of serial equipment.  While Send and Rcv can be used to move
files between two MS-DOS machines, there are better ways to do this.

Send and Rcv can do nothing for you if you don't understand a little about
serial communications.  See the file Article.txt for help with this subject if
you need it.

Copyrights and Obligations

This software is copyright (C) 1996 by Rob Meredith, and is available to the
public as freeware.  The author is not in any way responsible for any
consequences resulting out of the use of this software.  If you decide to use
the software, you will be doing so at your own risk.  I am also not obligated
to support the software in any way.

Although I am not obligated to support the software, it is possible that I may
be willing to do so as time permits.  if you have a problem or question
concerning Send or Rcv, you may reach me via e-mail at rmeredit@iglou.com.

Why are Send and Rcv Free?

Send and Rcv are quality software products, and may be useful to many.  But,
shareware doesn't work, and there is no market for DOS-based software anyway. I
have decided to make these programs available for no cost to those who find
them useful.  So, relax!  This is one set of programs you won't have to worry
about registering.

Requirements to Run

Send and Rcv require MS-DOS version 2.0 or later, and at least one
8250-compatible serial port.  They only require about 16K of free memory to
run.

Features

Send and Rcv pick up where DOS left off.  If you have ever tried to use DOS to
move files through the serial port, you have probably found just how inadequate
it is.  Following are some of the features supported:

>Use of serial ports 1 through 4
>Common baud rates from 300 through 115200 baud
>5 parity settings -- None, Even, Odd, Space, and Mark
>One or two stop bits
>Three different types of handshaking -- Xon/Xoff, RTS/CTS, and DTR/DSR, as
well as no handshaking
>Special treatment of linefeed characters
>Special treatment of the EOF (End Of File) character
>Data clicker
>Most common IRQ line settings (Rcv only)
>Support for 16550 FIFO (Rcv only)
>Use of an environment string for specifying option preferences
>Built in quick-help screen

The Send Command

To use Send, simply place it in a directory which is in your MS-DOS Path, or
switch to the disk/directory where it resides.  Then type Send followed by any
optional parameters and the name or names of files you want to send.  Each
parameter or filename should be separated from the word Send or an adjacent
parameter by a space.  Wildcards for filenames are not supported.  Files are
sent in the order they are specified on the command line.

Optional Parameters for Controlling Send

Send offers a wide variety of parameters to control how the files you want to
send are transmitted.  When typing parameters, the case of letters is not
important.  Parameters can be specified in any order.  Following is a list of
each parameter, what it controls, and its range.

/c:Com-port

The /c switch controls which communications port will be used.  Valid settings
are 1 through 4.  If you do not use /c, the lowest numbered serial port found
in your machine will be used.  This is usually com1.

/b:Baud Rate

Use the /b switch to specify which baud rate should be used.  Valid settings
are:
3, 12, 24, 48, 96, 192, 384, 576, 1152
Note: these are common baud rates divided by 100.

For example, to use 2400 baud, you would specify:
/b:24

If you do not use the /b switch, the default baud rate of 9600 will be used.

/7 -- 7 Data Bits or /8 -- 8 Data Bits

Use /7 if you want a word length of 7 data bits.  Use /8 for 8 data bits.  The
default is /8.

/p:Parity

The /p switch controls use of a parity bit.  You may use the following
settings:
/p:n -- No parity
/p:e -- Even parity
/p:o -- Odd parity
/p:s -- Space parity
/p:m -- Mark parity

If you do not use the /p switch, the default of No parity will be used.

/1 -- 1 Stop Bit or /2 -- 2 Stop Bits

Use /1 to allow timing for a single stop bit.  /2 will give you 2 stop bits.
The default is 1 stop bit.

/l -- Linefeed Suppression

Text files in MS-DOS use a linefeed after each carriage return character.
While most devices will accept this, it is often not needed, and just waists
time and memory.  If you want Send to strip all outgoing linefeed characters,
use /l.  The default is not to strip linefeeds.

/e -- Terminate on EOF

The EOF character, Control-Z, is often used in text files to mark the End Of
File.  Send can be instructed to stop sending a file after the first occurrence
of the EOF character has been transmitted.  The default is to send the entire
file, regardless of EOF characters.

/n -- Noise Control

It is often desirable to have Send make noise through the PC speaker to
indicate that data bytes are being transmitted.  This depends on your personal
preference, and the loudness of your particular PC speaker.  If /n is used, a
click will be made by the speaker when ever a byte is sent out the port.  These
clicks will be faster at higher baud rates, making anything from a clicking
sound, to a buzz, to a beep.  The default is not to make any noise at all.

/d -- Use DSR Handshaking

DSR handshaking is a type of hardware handshaking.  For this type of
handshaking to work, the device you are sending to must drop the DSR line to
pause data flow, and the serial cable in use must be wired properly to
communicate this information to the PC. The default is not to use DSR
handshaking.

/r -- Use CTS Handshaking

CTS handshaking is a type of hardware handshaking.  For this type of
handshaking to work, the device you are sending to must drop the CTS line to
pause data flow, and the serial cable in use must be wired properly to
communicate this information to the PC. The default is not to use CTS
handshaking.

/x -- Use Xon/Xoff Handshaking

Xon/Xoff handshaking is commonly referred to as software handshaking.  This is
a common kind of handshaking, because it is not dependant on the presents of
special hardware lines .  The default is to use Xon/Xoff handshaking.

/z -- Leave DTR and RTS lines On After Exit

The DTR and RTS lines are two output lines controlled by the PC.  When you
first boot your machine, these lines are turned off.  But, most devices
function better if they are on.  Use /z to leave them on after Send is through
with the serial port.  This is the default.

/? -- Quick Help

For a quick reference containing all of the available parameters for use with
Send, use /?.  When requesting quick help, all other parameters are ignored,
and no files can be sent.

Disabling a parameter

You probably noticed that some single-letter parameters are active by default.
For example, the parameter for controlling Xon/Xoff handshaking, /x, is active
by default.  If you need to disable a feature which is controlled by a
single-letter option, you may place a hyphen (-) immediately after the
parameter.  For example, if you wanted to disable Xon/Xoff handshaking, you
would use /x-.  If you wanted to leave DTR and RTS in their original state
after sending, you would use /z-.

Using an Environment Variable to Control Send

While Send incorporates reasonable defaults, most people will need to use
optional parameters to make it function in a way which best meets their needs.
To avoid having to constantly type optional parameters every time Send is used,
an environment variable can be defined before running Send which specifies
these values.  The name of the variable is SENDXCMD.  If the SENDXCMD
environment variable exists when Send is run, Send uses it to set its
parameters before checking the command line.  Therefore, you can override the
SENDXCMD environment variable by specifying the same parameter on the command
line with a different setting.

Let's consider an example.  Suppose you put the following line in your
Autoexec.bat file:
set sendxcmd=/c2 /b192 /l /n

After booting your computer, Send will automatically use Com2 with a baud rate
of 19200.  It will also strip outgoing linefeed characters, and click the
speaker after sending each byte.

Now, assuming that the SENDXCMD environment variable still contains the above
string, imagine that you want to run Send without clicking the speaker.  You
usually want the speaker noise, but this time you don't.  You would type:
Send /n- filename

The /n- would override the /n in the SENDXCMD environment variable, and no
noise would be made while sending.

In a similar way, if you wanted to use Com1 instead of Com2, you could type:
Send /c1 filename

Be careful!  Improper definitions in the SENDXCMD environment variable can
cause Send to fail.  For example, if you use /o in the variable, Send will
simply report that /o is an invalid option, and refuse to run.  Similarly, if
you use /c2 and you do not have a serial port defined as Com2 in your machine,
send will fail.  Also remember that no spaces should be typed between the
variable name, SENDXCMD, the equals sign (=), and the first parameter.

The Rcv Command

Rcv is the opposite of Send.  While Send sends a file out the serial port, Rcv
receives a file through the serial port.

To use Rcv, simply place it in a directory which is in your MS-DOS Path, or
switch to the disk/directory where it resides.  Then type Rcv followed by any
optional parameters and the name of the file to be received. The filename and
parameters should be separated from the word Rcv and each other by a space.
Only one file can be received at a time.  After all data has been received,
press Escape to exit Rcv.

Optional Parameters for Controlling Rcv

Rcv offers a wide variety of parameters to control how the file should be
receive.  When typing parameters, the case of letters is not important.
Parameters can be specified in any order.  Following is a list of each
parameter, what it controls, and its range.

/c:Com-port

The /c switch controls which communications port will be used.  Valid settings
are 1 through 4.  If you do not use /c, the lowest numbered serial port found
in your machine will be used.  This is usually com1.

/b:Baud Rate

Use the /b switch to specify which baud rate should be used.  Valid settings
are:
3, 12, 24, 48, 96, 192, 384, 576, 1152
Note: these are common baud rates divided by 100.

For example, to use 2400 baud, you would specify:
/b:24

If you do not use the /b switch, the default baud rate of 9600 will be used.

/7 -- 7 Data Bits or /8 -- 8 Data Bits

Use /7 if you want a word length of 7 data bits.  Use /8 for 8 data bits.  The
default is /8.

/p:Parity

The /p switch controls use of a parity bit.  You may use the following
settings:
/p:n -- No parity
/p:e -- Even parity
/p:o -- Odd parity
/p:s -- Space parity
/p:m -- Mark parity

If you do not use the /p switch, the default of No parity will be used.

/1 -- 1 Stop Bit or /2 -- 2 Stop Bits

Use /1 to allow timing for a single stop bit.  /2 will give you 2 stop bits.
The default is 1 stop bit.  This option only matters when Rcv is performing
Xon/Xoff handshaking, and will most likely never need to be used.

/i:IRQ line

Rcv uses serial interrupts when receiving data.  Therefore, it requires the use
of an IRQ (interrupt request) line.  The line which must be used is the one
which the serial port is configured to use.  Normally, com1 uses IRQ 4, com2
uses IRQ 3, com3 uses IRQ 4, and com4 uses IRQ 3.  If for some reason you need
to use a different IRQ setting, the /i switch lets you do this.  Valid settings
are 2, 3, 4, 5, or 7.  The default is to use the IRQ normally used by the port
selected.  In most cases, you shouldn't have to worry about this parameter.

/a -- Append to Existing File

It is possible to add (append) new data to the end of an existing file.
Normally, Rcv will create a new file, or overwrite an old one.  If /a is used,
Rcv will always append to an existing file, or create a new one if none exists.
The default is not to append.

/y -- Overwrite Existing File

If you try to receive data to a file that already exists and you are not using
/a, Rcv will ask you if you want to replace the file, append to it, or cancel.
This is done with the question:
Replace existing file (Yes/No/Append)?

If you press Y, Rcv will overwrite the file with the new data.  If you press N,
Rcv will terminate without receiving anything.  If you press A, Rcv will append
to the file, as if /a had been used.

The /y option  instructs Rcv to automatically overwrite an existing file
without asking. Note that if /a is used, /y is ignored.

/l -- Add Linefeed to Return

The /l switch should be used in situations where you are receiving a text file
which does not contain linefeeds after carriage returns.  If /l is used, a
linefeed will automatically be inserted after each return.  The default is not
to add linefeeds.

/e -- Exit on EOF

The EOF character, Control-Z, is often used in text files to mark the End Of
File.  Rcv can be instructed to stop receiving after the EOF character has been
received.  The default is not to exit on the EOF character.

/f -- 16550 FIFO Control

If your machine has the newer 16550 serial chip, Rcv can be instructed to
either ignore this fact, force the chip's internal buffer off, or force the
chip's internal buffer on.  To ignore the 16550, use /f-.  This is the default.
To disable the input buffer, use /fn.  To enable the input buffer, use /fy.
When the buffer is enabled, the chip will interrupt the machine once for every
14 characters received, saving interrupt processing time, and minimizing the
chance of character loss.  Note that if you don't have a 16550 chip and you use
/fy or /fn, Rcv will report that the serial chip in use is not 16550
compatible, and continue normally.

/n -- Noise Control

It is often desirable to have Rcv make noise through the PC speaker to
indicate that data bytes are being received.  This depends on your personal
preference, and the loudness of your particular PC speaker.  If /n is used, a
click will be made by the speaker each time a serial interrupt occurs.  These
clicks will be faster at higher baud rates, making anything from a clicking
sound, to a buzz, to a beep.  The default is not to make any noise at all.

/d -- Use DTR Handshaking

DTR handshaking is a type of hardware handshaking.  For this type of
handshaking to work, the device you are receiving from must stop sending data
when the DTR line is dropped, and the serial cable in use must be wired
properly to communicate this information to the device. The default is not to
use DTR handshaking.

/r -- Use RTS Handshaking

RTS handshaking is a type of hardware handshaking.  For this type of
handshaking to work, the device you are receiving from must stop sending data
when the RTS line is dropped, and the serial cable in use must be wired
properly to communicate this information to the device. The default is not to
use RTS handshaking.

/x -- Use Xon/Xoff Handshaking

Xon/Xoff handshaking is commonly referred to as software handshaking.  This is
a common kind of handshaking, because it is not dependant on the presents of
special hardware lines.  The default is to use Xon/Xoff handshaking.

/w -- Handshake During Writes

Normally, Rcv will not attempt to handshake when writing data to
disk, allowing handshaking only to be controlled by the amount of data in the
input buffer. There are times, however, when it is helpful to handshake when
writing to disk. This is necessary when the disk device driver disables
interrupts for a relatively long period of time.  If you find you are losing
data when receiving, try /w.  Note: most RAM-disk drivers disable interrupts
for a period of time.

/q -- Don't Report Serial Errors

When Rcv terminates, all serial errors, if any were detected, are reported.
These include overrun errors, parity errors, and framing errors.  If for some
reason you do not want these errors to be reported, use /q.

/z -- Leave DTR and RTS lines On After Exit

The DTR and RTS lines are two output lines controlled by the PC.  When you
first boot your machine, these lines are turned off.  But, most devices
function better if they are on.  Use /z to leave them on after Rcv is through
with the serial port.  This is the default.

/? -- Quick Help

For a quick reference containing all of the available parameters for use with
Rcv, use /?.  When requesting quick help, all other parameters are ignored, and
no files can be received.

Disabling a parameter

You probably noticed that some single-letter parameters are active by default.
For example, the parameter for controlling Xon/Xoff handshaking, /x, is active
by default.  If you need to disable a feature which is controlled by a
single-letter option, you may place a hyphen (-) immediately after the
parameter.  For example, if you wanted to disable Xon/Xoff handshaking, you
would use /x-.  If you wanted to leave DTR and RTS in their original state
after receiving, you would use /z-.

Using an Environment Variable to Control Rcv

While Rcv incorporates reasonable defaults, most people will need to use
optional parameters to make it function in a way which best meets their needs.
To avoid having to constantly type optional parameters every time Rcv is used,
an environment variable can be defined before running Rcv which specifies these
values.  The name of the variable is RCVXCMD.  If the RCVXCMD environment
variable exists when Rcv is run, Rcv uses it to set its parameters before
checking the command line.  Therefore, you can override the RCVXCMD environment
variable by specifying the same parameter on the command line with a different
setting.  Refer to the example given with the Send command to see how to use
this variable.

Be careful!  Improper definitions in the RCVXCMD environment variable can cause
Rcv to fail.  For example, if you use /o which is an invalid parameter in the
variable, Rcv will simply report that /o is an invalid option, and refuse to
run. Similarly, if you use /c2 and you do not have a serial port defined as
Com2 in your machine, Rcv will fail.  Also remember that no spaces should be
typed between the variable name, RCVXCMD, the equals sign (=), and the first
parameter.

Notes on Optional Parameters

While all examples for Send and Rcv in this manual use the slash character (/)
when specifying optional parameters, the hyphen (-) may also be used.  For
example, -b192 is the same as /b192.

All colons after the first letter of optional parameters are ignored.  For
example, /b:96 and /b96 are the same.  Likewise, /p:e and /pe are the same.

A Bit of Technical Info

Send and Rcv do not use any error correction, and use little error detection.
So, you must be careful when using them if you are concerned about data
integrity.  In short, your objective should be to get the most throughput with
no errors.

When using Send, there is not any concern on the PC end, since sending data is
not a time-sensitive operation.  Send simply sends what it is instructed to, as
fast as it possibly can, according to the parameters specified.  It is the
device which is receiving from Send which must be able to keep up with data
flow.

When using Rcv, however, Rcv must be able to keep up with incoming data.  This
will be governed mainly by the speed of your microprocessor, the tolerance of
your serial chip, and the number of TSR (Terminate and Stay Resident) programs
you are using.  In older machines, a baud rate of 9600 is probably the maximum
which should be used.  But, newer machines can go much faster, perhaps as
fast as 19,200 or 38,400.  Note that Rcv can use a maximum baud rate of
115,200, but high rates should be used with extreme caution.

If you choose to use a baud rate above 9600, you may want to carefully examine
your received data to be sure it is what it should be. Rcv will detect parity,
framing and overrun errors, but this is not 100 percent reliable.  If you do
not get one of these errors when exiting Rcv, however, there is a pretty good
chance your data was received correctly.  Also, if you are not adding linefeeds
with /l, you may want to check the file size after receiving to be sure it
matches the size of the file sent from the other device.  One way to check the
received file size is with the DIR command.


