Interfacing to a FOSSIL Communications Driver



June 01, 1995
URL:http://www.drdobbs.com/interfacing-to-a-fossil-communications-d/184403026

June 1995/Interfacing to a FOSSIL Communications Driver

Jim Lawless is a programmer specializing in C development for Windows for a financial institution. He teaches C & Visual BASIC programming at a local college. He can be reached at [email protected] or 2414 4th Ave., Council Bluffs, IA 51501.

Introduction

The number of people who utilize online services and electronic bulletin-board systems grows each year. Despite public interest in telecommunication, accessing a modem from an MS-DOS application has been a somewhat arcane science.

MS-DOS provides extremely minimal support for access to the RS-232 communication ports. In fact, MS-DOS relies heavily on the hardware Basic Input/Output Subsystem (BIOS) to handle all of the dirty work related to utilization of a modem as an I/O device. The major problem with utilization of BIOS communication routines is that characters that are sent and received are not buffered. An application must poll the ports frequently to avoid losing data.

Although the BIOS does not readily support lossless RS-232 I/O, the Universal Asynchronous Receiver/Transmitter (UART) chip found in every IBM PC/XT/AT or compatible computer does provide for an interrupt-driven method of accessing the communication ports. The UART can be programmed to generate an interrupt upon reception of data. It can also generate an interrupt when its transmit register becomes empty.

Meeting the Challenge

For an application to properly utilize interrupt-driven serial functions, it must perform the following tasks:

1. The application must provide interrupt-processing routines.

2. The application must determine which interrupt is associated with a given communication port. Some RS-232 cards allow non-standard interrupts to be paired with existing communication ports.

3. The application must manipulate the Programmable Interrupt Controller (PIC) chip registers so that it allows interrupts from the UART.

4. The application must manipulate the appropriate UART control registers so that RS-232 I/O finally occurs.

This sounds like quite a bit of complexity just to send and receive data, doesn't it? While communications libraries began to appear to minimize the work involved in writing a telecommunications application, a somewhat more flexible methodology became available in 1987.

Programmers involved in software related to the Fido electronic message network system (particularly with the SEADog mailer, the Opus electronic bulletin-board system, and general Fido driver) found themselves dealing with problems with what were then referred to as "clone" machines. This was at a time when clone machines were still suffering from hardware compatibility problems.

One of the most important problems that they encountered pertained to inconsistencies found in certain UART chips. The obvious answer to the compatibility problem was to isolate the program code to handle the inconsistencies into a single driver with a standard interface. This interface/driver became known as the Fido-Opus-SEADog Standard Interface Layer (FOSSIL).

FOSSIL's interface is an extension of the BIOS interrupt Ox14 interface. FOSSIL incorporates buffered input and output as well as providing functions for video and keyboard I/O. A FOSSIL driver is usually implemented either as an MS-DOS device driver or as a Terminate-but-Stay-Resident (TSR) program.

Utilization of a FOSSIL driver has many advantages, one of which is that just about any programming language can readily access FOSSIL functions through the INT 0x14 interface. This can include some macro scripting languages found with applications such as word processors and spreadsheet programs.

The foremost advantage of utilizing a FOSSIL driver is that applications can more readily tolerate changes and advances in communication hardware. For instance, many workplaces now tie PCs together via Local-Area Networks (LAN's). A FOSSIL driver can be constructed which routes modem I/O from a client PC to a communications-server PC. A terminal program dependent on the FOSSIL interface would not even be able to determine that the modem is actually connected to a separate PC! And newer UART features such as built-in buffering can be automatically identified and activated when the FOSSIL driver initializes.

The primary disadvantage you'll encounter when using a FOSSIL driver will most likely be distribution costs. If you distribute a FOSSIL-based application, you may have to pay a royalty if you plan on distributing the driver as well. While this could be a concern, most distributed FOSSIL-based software simply states that it requires a FOSSIL driver to run (allowing the customers to choose the driver that best suits their needs). See the sidebar for a list of FOSSIL driver products.

FOSSIL Functions

Table 1 shows the FOSSIL functions, which are selected by setting the contents of AX (the main 80x86 accumulator register) prior to caling INT 0x14. The contents of AH correspond to the FOSSIL function number called. FOSSIL function 0 accepts values that differ slightly from its BIOS counterpart for initialization of the port baud-rate. Rather than providing support for 110 and 150 bit-per-second speeds, the codes for these two speeds now represent 19,200 and 38,400 bits-per-second, respectively.

FOSSIL functions 0x18 and 0x19 provide a means for an entire block of data to be received or transmitted. While this appears to be something that can be easily implemented by a simple loop, modems exist that allow high-speed DMA (Direct Memory Access) transfers of data. If a FOSSIL driver were constructed to handle these modems and their serial I/O controller chip, utilization of the block-oriented functions would make the actual existence of DMA movement an abstract concept. If DMA transfer capability is not present for the modem/driver combination, transfer duration will be no worse than that of a simple loop utilizing single-character I/O functions.

While FOSSIL provides functions to read the keyboard, get/set cursor position, and display characters to the console, I've chosen to use standard I/O functions from the C library to handle these tasks.

Many of the functions in the miscellaneous section are provided to make construction of electronic bulletin board systems and add-ons for BBSs easier to implement. One such function is the "watchdog" function, which will reboot the PC when a carrier signal is no longer detected. This eliminates the need for complex polling during idle-for-user-input operations. If a user hangs up while the system is waiting for input, the PC is simply rebooted. Finally, timer management functions allow the user to implement timer-interrupt functions by allowing the FOSSIL driver to install and remove timer handlers.

A Simple Example

I've provided a short, bare-bones terminal program (FTERM.C, shown in Listing 1) which utilizes a FOSSIL driver solely for its serial I/O capabilities. FTERM initializes port 1 for a 9,600 baud rate. Port parameters are set to an eight-bit word length, one stop bit, and no parity. I purposely built FTERM with a minimal (i.e., non-existent) user interface to show the simplicity of implementing a FOSSIL-based terminal program.

As demonstrated in FTERM, all of the hard work is now handled by FOSSIL. Using FOSSIL, the modem becomes the simple I/O device that we wanted in the first place!

June 1995/Interfacing to a FOSSIL Communications Driver/Listing 1

Listing 1 Bare-bones FOSSIL program

// Bare bones FOSSIL terminal program.
// Compiled with Microsoft VC++ 1.0, but should
// port to other compilers.

#include <stdio.h>
#include <dos.h>
#include <conio.h>

typedef unsigned char BYTE;
typedef unsigned int WORD;

// Extended key code for
// Alt-X
#define ALT_X (0x2d)
#define SER_DAT_READY (0x100)

int def_port=0;

// Generalized FOSSIL function
//          AH   AL   DX
WORD fossil(BYTE,BYTE,WORD);

// Specific FOSSIL functions actually implemented
// as macros
#define fos_setparms(p,x) fossil(0,x,p)
#define fos_putc(p,c)     fossil(1,c,p)
#define fos_getc(p)       fossil(2,0,p)
#define fos_status(p)     fossil(3,0,p)
#define fos_init(p)       fossil(4,0,p)
#define fos_uninit(p)     fossil(5,0,p)
#define fos_setDTR(p,f)   fossil(6,f,p)

main(int argc,char **argv)
{
   int c;
   
   if(fos_init(def_port)!=0x1954) {
      fprintf(stderr,
         "\nFOSSIL driver not present!\n");
      exit(1);
   }
   
   // Set Parms 9600,N,8,1
   fos_setparms(def_port,0xe3);
   
   // Main Terminal Loop
   while(1) {
      if(kbhit()) {
         c=getch();
         if(!c) {
            if(getch()==ALT_X)
               break;
         }
         else
            fos_putc(def_port,(BYTE)c);
      }
      
      // See if a character is waiting to be read
      // If so, display it.
      if((fos_status(def_port)&SER_DAT_READY)!=0) {
         fputc(fos_getc(def_port),stdout);
      }
   }
   // Lower DTR
   fos_setDTR(def_port,0);
   // Uninitialize Driver
   fos_uninit(def_port);
   exit(0);
}

// Use older interrupt interface rather than
// inline assembly.
WORD fossil (BYTE ahreg, BYTE alreg, WORD dxreg)
{
   
   union REGS r;
   r.h.ah=ahreg;
   r.h.al=alreg;
   r.x.dx=dxreg;
   int86(0x14,&r,&r);
   return(r.x.ax);
}

// End of File

June 1995/Interfacing to a FOSSIL Communications Driver/sidebar

Supplemental Information

The following are FOSSIL driver products:

X00

Available in X00150.ZIP in the CompuServe IBM Bulletin Board System Forum (GO IBMBBS) Library 2.

The newest version of this driver is in an archive labeled X00202R8 (the extension will depend on the archiver used). Look for this on electronic bulletin-board systems.

In addition to the FOSSIL driver, this package contains application-programming interfaces for C, Pascal, and BASIC.

Additionally, it contains a full chart of FOSSIL functions and a development history.

BNU

Available in BNU170.ZIP in the CompuServe IBM Bulletin Board System Forum (GO IBMBBS) Library 2. Newer versions are likely to be available on electronic bulletin-board systems.

COMM-DRV/DOS

Wille's Computer Software Company, 2470 S. Dairy Ashford Suite 188, Houston, TX 77077. Phone: 800-966-4832.

Other sources of FOSSIL information and FOSSIL-related products:

Serial Communications: A C++ Developer's Guide, by Mark Nelson, M&T Books. In addition to detailed information pertaining to programming the PC's serial interface, it contains information and sample code pertaining to the FOSSIL specification.

FOSSIL.DOC, by Vincent E. Perriello. This is a text file describing the evolution FOSSIL. It is available on electronic bulletin-board systems.

FDSZ (DSZ for FOSSIL prototype), Omen Technology, P.O. Box 4681, Portland OR 97208. Phone +1-503-621-3406. This program is the FOSSIL version of the popular external file-transfer protocol driver which includes Zmodem support.

OpenDoors Library, by Brian Pirie, Apt. 1416, 2201 Riverside Dr., Ottawa, Ontario K1H 8K9. Available in ODOORS.ZIP in the CompuServe IBM Bulletin Board System Forum (GO IBMBBS) Library 3. This shareware library is a C/C++ library for creating external "door" programs for electronic bulletin-board systems. The function library provides for automatic FOSSIL support.

June 1995/Interfacing to a FOSSIL Communications Driver/Table 1

Table 1 FOSSIL function table

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.