Dec 092017
 
Examples of RS232 device drivers with ASM source code.
File RS232DVR.ZIP from The Programmer’s Corner in
Category Assembly Language
Examples of RS232 device drivers with ASM source code.
File Name File Size Zip Size Zip Type
AUXDVR.SYS 2899 1254 deflated
IBMRS232.ASM 27952 5096 deflated
RS232.ASM 12369 2970 deflated
RS232.COM 1775 936 deflated
RS232.DOC 9826 3240 deflated
RS232.INC 18155 3960 deflated
TPCREAD.ME 199 165 deflated

Download File RS232DVR.ZIP Here

Contents of the RS232.DOC file


RS232 Communications Driver

Original Author: Greg Haley, Texas Instruments

Version 3.00 by
Joe McDaniel
Fein-Marquart Associates, Inc.
7215 York Road
Baltimore, MD 21212
(301) 821-5980

History:
The original work on this package was done by Greg Haley
of Texas Instruments. The system I took and modified had severe problems
in that it could support input, but output didn't work. Also it did
not support interrupt driven output, only input. The original version
also had support for (I assume) debugging aids which allowed for echoing
of characters received and transmitted and for direct keyboard input.
None of these features is currently present - I felt they were of no
value and just kludged up the code. Xon/Xoff now works. RS232.COM now reports
on the status of the control lines. I eliminated the TI specific stuff as I had
no way to test it. Also, the original distribution had a terminal emulator
that took advantage of the echoing features - it is now gone, too. I fixed
the 19,200 baud stuff so it will work.

Introduction

The purpose of this package is to provide RS232 communications support
in device driver form for the IBM PC. All machine dependent code is confined
to the device drivers. The device drivers in this package use the
MS-DOS I/O control channel to configure the driver and to check or change the
modem RS232 signals. Some of the features of the drivers used here that make
them useful for communications are:

o Interrupt driven communications
o Optional flow control
o Access to the modem signals
o Ability to change communication settings without disconnecting
o Ability to force a disconnect by dropping RTS and DTR
o 110 - 19200 baud rates
o EVEN, ODD, or no parity using 7 or 8 data bits
o Device driver is configured using standard MS-DOS function calls
o Access the number of characters in the receive queue
o Ability to purge the receive queue

These drivers support all the major needs of any communications program,
and are a substantial improvement over most of the default device drivers
that come standard with each MS-DOS computer.

Using these drivers, any language that can write to the device "AUX" can
now do interrupt driven RS232 I/O. If the language is not capable of issuing
the MS-DOS functions call 44 hex (I/O control) to configure the driver, the
assembly program RS232 is provided to set up the port, baud rate, parity,
etc. for the device driver. The source code for this program is provided as
an example of using the MS-DOS I/O control function call.

Here's a list of the files in this package with a brief description of each
file:
IBMRS232.ASM Source for IBM PC machine dependent code
RS232.ASM Source for RS232 configuration program
RS232.DOC Documentation for this package
RS232.INC Source for general device driver routines

Assembling the routines

Edit IBMRS232.ASM ans RS232.ASM to set the name of the device being created.
It is currently set to AUX. Assemble as follows:
masm ibmrs232;
masm rs232;

Link:
link ibmrs232;
exe2bin ibmrs232.exe auxdvr.sys
link rs232;
exe2bin rs232.exe rs232.com

Installing the Device Driver

Installing the device driver of your choice is done by editing your
CONFIG.SYS file and putting a copy of the driver in your root directory.
As an example, to install the IBM driver on drive C:, first copy the file
AUXDVR.SYS to someplace where you can access it during boot such as
C:\AUXDVR.SYS. Next, add the following statement to your CONFIG.SYS file:

DEVICE = AUXDVR.SYS

The next time you reboot, the driver will be installed and will take the
device name "AUX". The driver will not respond until you configure it by
writing the Device Configuration Word (DCW) to the I/O control channel.
This is accomplished using the MS-DOS function call 44h (hex) and is covered
in the next section.

Using the I/O Control Function Call

All I/O control to the device driver is done in one or two byte forms.
The two byte form is used to set up the communications paramenters. The
single byte form is used to select all other options such as checking the
modem signals. We'll cover the single byte form first. Reading one byte
from the I/O control channel causes the driver return the current modem
signals and I/O configuration. (See function 44h, AL=2 in your MS-DOS manual)
The modem signals and options are encoded as follows:

Bit number
+-------------------------------+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|-------------------------------|
| | | | RI|SCF|DSR|CTS|DCD|
+-------------------------------+

Bit Description
4 0 = RI (Ring Indicator) is down.
1 = RI (Ring Indicator) is up.


3 0 = SCF (High speed line) is down.
1 = SCF (High speed line) is up.
* The signal SCF is not supported by the IBM PC.
For the IBM PC, this signal will always be down (0).

2 0 = DSR (Data Set Ready) is down.
1 = DSR (Data Set Ready) is up.

1 0 = CTS (Clear to Send) is down.
1 = CTS (Clear to Send) is up.

0 0 = DCD (Data Carrier Detect) is down.
1 = DCD (Data Carrier Detect) is up.


Writing a single byte to the I/O control channel (function 44h, AL=3)
is used to set the driver options, flush the receive buffer, and disconnect
(by dropping RTS and DTR). Below is a chart showing the various values for
the byte code and the action taken:

Bit number
+-------------------------------+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|-------------------------------|
| | | | | |LEN|FIB|DTR|
+-------------------------------+

Name Bit Description
LEN 2 0 = Output DCW on 2 byte I/O channel reads. (Default)
1 = Output receive queue length on 2 byte I/O channel reads.
* Note that this field need only be set once. The current
state is used until LEN is changed again.

FIB 1 0 = Don't flush receive buffer
1 = Flush receive buffer

DTR 0 0 = Disconnect (drop DTR and RTS) and reset driver.
1 = DTR and RTS up.

N.B.: The read byte and write byte have no relation to each other! If you
read, do not write the read value. Set your own parameters!


The two byte form of I/O control can be used to read or write the
communications settings. Writing a 2 byte value to the control channel
will set the Device Configuration Word (DCW). Reading 2 bytes from the
control channel will do one of two things depending on the state of the
LEN bit. (The LEN bit is set by the user in the single byte control channel
write.) If LEN = 0, the DCW will be read. If LEN = 1, the receive buffer
length is read. The default mode is LEN = 0, read the DCW. Below is a bit
map showing the various fields within the Device Control Word:

+-------------------------------+-------------------------------+
| Upper Byte | Lower Byte |
+-------------------------------+-------------------------------+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------+-------------------------------+
| 1 | 2 | 0 | 3 | 3 | 0 | 4 | 4 | 5 | 5 | 5 | 5 | 6 | 7 | 8 | 8 |
+-------------------------------+-------------------------------+
| Bit Codes |
+-------------------------------+-------------------------------+

Bit Code Description

2 Number of data bits
0 = 7 data bits
1 = 8 data bits

3 Port Number
00 = Port 1
01 = Port 2
10 = Port 3
11 = Port 4

4 Flow Control
00 = none
01 = SCF (NONE for IBM PC)
10 = DSR
11 = XON-XOFF

5 Baud Rate
0000 = 110
0001 = 150
0010 = 300
0011 = 600
0100 = 1200
0101 = 2400
0110 = 4800
0111 = 9600
1000 = 19200

6 Number of Stop Bits
0 = 1
1 = 2

8 Parity
00 = none
01 = ODD
10 = none
11 = EVEN

Writing a New Driver

Additional RS232 drivers may be written for other MS-DOS (2.xx and greater)
machines by changing the machine dependent portion of the driver. The two
driver provided has machine dependent code in IBMRS232.ASM. The file RS232.INC
is an include file and provides the general device driver functions. Any general
changes to the driver should be made here. To make a new driver, only the
machine dependent portion needs to be written, and any new driver should also
use the INCLUDE directive to add the code from RS232.INC. Following this form
will make maintaining the various drivers much easier.



 December 9, 2017  Add comments

Leave a Reply