RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 08/685,310, filed Jul. 22, 1996, U.S. Pat. No. 5,864,710 which claims priority to U.S. application Ser. No. 60/010,909, filed Jan. 31, 1996.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to modems used in personal computers, and more particularly to a modem wherein the controller and UART functions are performed by the host CPU using software organized as virtualized driver and modem modules, with the modules communicating via a virtualized UART interface.

2. Description of the Related Art

Most of today's personal computers include some form of modem functionality. High speed modem systems are typically incorporated onto an option card, and usually include a “data pump” for supporting the various protocols of modem communication, such as the V.22, V.22 bis, V.32, V.32 bis, and V.34 (28.8 Kbps) protocols recommended by the International Telegraph and Telephone Consultative Committee (CCITT). The data pump itself typically includes a DSP (digital signal processor) for performing modulation, demodulation and echo cancellation and a coder-decoder (CODEC) for performing analog to digital (A/D) and digital to analog (D/A) conversion. Analog signals from the phone line are digitized by the CODEC and then demodulated by the DSP to extract the original digital data sent by an external device. This procedure is reversed for data transmitted by the modem to the external device.

In prior modems, support logic to interface the modem to the computer system has typically included a microcontroller for establishing a communications link, controlling the sequence of events to originate or answer a call, and to transmit or receive digital data from the computer system through a universal asynchronous receiver transmitter (UART) across the I/O bus. The microcontroller also typically performs error correction procedures, such as those according to the V.42 protocol, as well as compression/decompression procedures, such as those according to the V.42 bis protocol recommended by the CCITT.

The UART was originally designed as an intelligent microchip for serial interfacing, typically serializing data presented over a bus (or serial transmission such as over an RS-232 communications link, and receiving such data, converting it to parallel form, and sending it over a bus. Access to a UART chip is typically gained through a personal computer system's I/O ports (typically COM1 and COM2). Typical representatives include the UART 8250 and 16450 chips by National Semiconductor Corporation.

The hardware portions of modem devices contributes substantially to the ultimate cost of such modems. Further, they contribute to the size of such modems. Any reduction in the component count of such modems is desirable because it results in lower costs.

Further, ease of upgradability and portability across different operating system platforms is important to modem makers in today's age of rapidly changing technology and quick obsolescence. Manufacturers are faced with the pressure of trying to recover the cost of hardware development in the face of shortened product lifecycles. Therefore, any reduction in such hardware development is similarly desirable.

SUMMARY OF THE INVENTION

In a modem according to the preferred embodiment, the UART and microcontroller functions are virtualized and implemented in software (the “modem module”) run on the host processor. The modem module interfaces with a second layer (the “virtual device driver layer”) that includes an operating system-specific virtual port driver that interacts with the operating system. This dichotomized architecture is advantageous in that the modem module software remains virtually unchanged when the modem is used in conjunction with different operating systems (OSs). Most operating systems already incorporate the ability to communicate with a UART. Hence, modifying only the virtual device driver layer is much simpler and more cost effective than attempting to modify both layers.

Implementing portions of the modem hardware as software modules has additional advantages. By leveraging the capabilities of today's powerful microprocessors, high speed modem performance is actually improved over that of “standard” modems by eliminating bottlenecks associated with physical UARTs. Thus, a modem according to the present invention can be cheaper, faster, and easier to upgrade than traditional modem cards.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:

FIG. 1

is a simplified block diagram of a computer system with an optional modem card according to the present invention;

FIG. 2

is a block diagram showing traditional modem hardware in a PCMCIA card;

FIG. 3

is a block diagram of modem hardware according to the disclosed embodiment of the invention illustrating eliminated hardware portions;

FIG. 4

is a detailed block diagram of a modem card according to the present invention;

FIG. 5

is a block diagram depicting various software components in a Windows® 95 environment as used with a modem implemented according to the present invention;

FIG. 6

is a block diagram depicting various software components in a Windows® 3.1 environment as used with a modem implemented according to the present invention;

FIG. 7

is a block diagram showing the CPQFMW95.VXD and modem module interface in greater detail;

FIGS. 8A and 8B

are flowchart diagrams of the routines used by CPQFMVCD.386 to determine if a modem according to the present invention is installed in the computer system;

FIGS. 9A and 9B

are a flowchart illustration of a PPORTOPEN routine that performs the “virtualized” input and output operations to a virtual UART according to the invention;

FIG. 10

is a flowchart illustration of macro in-line code to be generated for “virtual” input and output operations;

FIG. 11

is a flowchart illustration of code called by the macros of

FIG. 10

;

FIGS. 12A and 12B

are a flowchart illustration of a SIM

450_

READ routine to be executed on calls to the virtual UART;

FIGS. 13A-13C

are a flowchart illustration of a SIM

450_

WRITE routine to be executed on calls to the virtual UART;

FIGS. 14A and 14B

are a flowchart illustration of a SIM

450_

EVALUATE_INTERRUPT routine that determines when interrupts should be provided by the virtual UART; and

FIG. 15

is a flowchart illustration of two routines used by modem controller code to send data to and receive data from the virtual UART according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to

FIG. 1

, a simplified block diagram of a computer system C is shown, including a modem card

30

. The computer system C incorporates a central processing unit (CPU) system

10

coupled to a host bus

16

. The host bus functions to interface the CPU system

10

to the rest of the computer system C, including a memory array otherwise referred to as the main memory

12

. The CPU system

10

may simply be a microprocessor, such as Intel Corporation's 486 or PENTIUM™ or a more complete CPU system including a microprocessor, a cache controller and other components. A video system

14

is also connected to the host bus

16

.

The host bus

16

is coupled to the I/O bus

20

through a bus controller

18

, which is preferably compatible with the Industry Standard Architecture (ISA) or the Extended Industry Standard Architecture (EISA) bus. The exact architecture of the I/O bus

20

is not critical to the invention.

Connected to the I/O bus

20

are various components conventionally located on the system board of the computer system C. These include the read only memory (ROM)

32

, which provides the BIOS and other system level instructions, and an 8042 keyboard controller

34

. A keyboard port

36

and an auxiliary or pointing device port

38

are connected to the 8042 keyboard controller

34

. A hard disk drive

24

is connected to the I/O bus

20

via an IDE controller

22

. The IDE controller

22

contains buffer control logic and generates chip selects for IDE drives during data reads and data writes to IDE devices.

Of interest in this description, a modem card

30

is connected to a Personal Computer Memory Card International Association (PCMCIA) interface

26

through a slot connector

28

. The PCMCIA interface

26

provides connectivity to the I/O bus

20

. Although originally intended as a memory expansion (standard 1.0) interface, PCMCIA specification 2.0 allows credit card-sized cards to be used for various I/O devices, such as fax modems, SCSI adapters or Global Positioning System (GPS) receivers with a PCMCIA interface. For sake of simplification, modem functions discussed hereinafter are assumed to include the capability to handle facsimile, data, and voice information, since the communication protocols for each are related.

The computer system of

FIG. 1

is exemplary, and numerous other computer system designs could be used. Further, the modem card

30

can be located directly on the I/O bus

20

or any other bus utilized by the computer system C, including the host bus

16

. The exact location of the modem is not critical to the invention.

Referring briefly to

FIG. 2

, a block diagram of traditional modem hardware is shown. A prior art modem is coupled to a phone line (not shown) through a data access arrangement (DAA)

54

, which electrically isolates the modem

30

from the phone line to control emissions of electromagnetic interference/radio frequency interference (EMI/RFI) as required by the Federal Communications Commission (FCC). The DAA

54

also typically isolates the received data from the transmitted analog signals, and develops a digital ring signal to inform the computer system to answer. The DAA

54

is preferably compatible with the public switched telephone network (PSTN) interface. The DAA

54

receives signals from the phone line through a telephone jack, such as an RJ11C used for standard telephones.

Traditional modems also include: a DSP

58

and support memory

64

, a microcontroller

40

requiring RAM

42

and ROM

44

, a physical UART

46

, and a peripheral interface device (PID)

48

. In such prior art modems, the microcontroller

40

would typically communicate with the CPU system

10

through the UART

46

. The CPU system

10

would send and receive data, using a separate UART, to the UART

46

, which would in turn provide the data to the microcontroller

40

, as well as send data from the microcontroller

40

to the CPU system

10

.

The microcontroller

40

, however, could not simply receive data from the CPU

10

and send it over the telephone line, nor could it simply receive data from the telephone line and send it to the CPU

10

. Instead, it would typically include the software necessary to implement a modem command set, such as the standard Hayes AT command set. The microcontroller

40

would include software for receiving ASCII commands according to the AT command set over the UART

46

, and performing various functions based on those commands. For example, the “ATH” command would cause the microcontroller

40

to “hang up” the DAA

54

, disconnecting the modem link. The other commands are well known according to the AT command set. Further, the microcontroller

40

would implement various error correction and data compression protocols. All of these functions are well known to those of ordinary skill in the art. When the software is in the communications mode rather than the command mode, of course, the microcontroller

40

would pass data to and from the UART

46

and to and from the DSP

58

. The DSP

58

would then convert that data into appropriate digitized signal levels, and pass that data on to a CODEC

56

(see FIG.

4

). To exit the data communications mode and into the command mode, the microcontroller

40

would preferably operate according to the AT command set, and respond to a sequence of three plus signs “+++” by by switching to the command mode, allowing the host PC to provide AT commands through the microcontroller

40

. One typical microcontroller used for the microcontroller

40

would be the Motorola MC68302 embedded controller.

Referring now to

FIG. 3

, a block diagram of modem hardware according to the disclosed embodiment of the invention is shown. Physical components that are implemented in software or no longer required are represented by dashed lines. As mentioned, prior art modem systems usually included a microcontroller

40

(

FIG. 2

) that provided data to the DSP

58

, and which also controls the DAA

54

, taking it on or off-hook as necessary. To establish a communication link, the microcontroller

40

directs the proper sequence of signals to either originate or answer a telephone call. In a modem according to the preferred embodiment, however, the various microcontroller

40

and UART

46

functions are implemented in a virtualized modem module

114

(FIGS.

5

and

6

). This software implementation results in substantial monetary savings and increased data rates. Further, the microcontroller

40

and the UART

46

are preferably implemented as a module independent from other operating system software, so that the virtualized versions of the microcontroller

40

and the UART

46

can be easily moved to other operating systems.

Proceeding now to

FIG. 4

, a modem card

30

according to the present invention is shown in greater detail. A PCMCIA host interface application specific integrated circuit (ASIC) PID

2

62

is used to connect the modem card

30

to the computer system C through the PCMCIA slot connector

28

. PID

2

62

is also connected to an EEPROM

64

, which contains the Card Information Structure (CIS) that is loaded into the PID

2

62

. In the preferred embodiment, the EEPROM

64

is manufactured by National Semiconductor Corporation. The PID

2

62

is further connected to an interface ASIC V32INFC2, which in turn provides an interface for a DSP chip

58

. The DSP

58

performs calculations to provide desired modem functions. In the preferred embodiment, the DSP

58

is a conventional DSP16A manufactured by AT&T Microelectronics.

The DSP

58

generally converts the digital data from the computer system C into a digitized analog waveform that provides to the CODEC

56

. The CODEC

56

then provides a true analog waveform to the DAA

54

. The DSP

58

also receives a digitized analog waveform from the CODEC

56

. The CODEC

56

receives a true analog waveform from the DAA

54

and converts that analog data into digital data for the computer system C. The DSP

58

also preferably performs echo cancellation to cancel signals echoed back to the modem

30

due to the transmitted signal.

The CODEC

56

is connected to the DSP

58

by four signals referred to as RXD, TXD, SYNC and CLK. The RXD and TXD signals are the receive and transmit digital signals, while the SYNC and CLK signals are conventional signals as utilized between a DSP

58

and a CODEC

56

. Together, the V32INFC2

60

, DSP

58

and CODEC

56

form what is commonly referred to as a “data pump”

50

. The data pump

50

is typically a modem data pump chip set supporting the various protocols of modem communication. In the preferred embodiment, the data pump

50

is a DSP16A-V32INFC2-LT V.32 bis plus FAX Data Pump Chip Set sold by AT&T Microelectronics.

The CODEC

56

receives an RXA or receive analog signal from the DAA

54

, and provides a TXA or transmit analog signal to the DAA

54

. The CODEC

56

digitizes analog data from the RXA signal for processing by the DSP

58

. Likewise, digital data TXD received from the DSP

58

is converted to analog format onto the TXA signal.

As mentioned, the DAA

54

serves to isolate the modem

30

from the telephone line to meet FCC or national regulations for the control of EMI/RFI interference. Data being received by the DAA

54

from an external device is filtered and provided in analog form to the CODEC

56

on the RXA signal. Similarly, data being transmitted by the modem

30

is provided from the CODEC

56

to the DAA

54

on the TXA signal, which is then asserted by the DAA

54

on the phone line. Data is preferably transferred serially between the DSP

58

and the CODEC

56

. Further details of exemplary DAA circuitry can be found in copending U.S. patent application Ser. No. 08/304,262, entitled “Modem Having Separate Modem Engine and Data Access Arrangement” and hereby incorporated by reference.

The DAA

54

is connected to a standard telephone line through an RJ-11 phone jack

52

. The phone jack

52

is provided to provide and receive certain telephone signals as known to those skilled in the art. Many different kinds of phone line or other transmission media are contemplated, so that the phone jack

52

and DAA

54

would be configured to be compatible with whatever phone line means or transmission media is being used. The present invention is not limited by any particular type of transmission media, phone jack or DAA, so that those shown are used merely for purposes of illustration.

A modem

30

according to the preferred embodiment is ideally able to identify itself according to the method described in the Plug and Play External COM Device Specification. In addition, to qualify for a Windows® 95 logo, the modem

30

must support at least 9600 bits per second (bps) V.32 with V.42/V.42 bis protocol for data modems; support the TIA-602 (Hayes®-compatible) AT command set, with extensions for flow control, V.42/V.42 bis; support fax capabilities of at least 9600 bps V.29 with class 1 (TIA-578 A); and support the 16450 A/16550 compatible UART interface. Windows® 95 does support the older 8250 UART chips.

Windows® 95 Background

At the core of Windows® 95 is a 32-bit protected-mode operating system called the virtual machine manager (VMM). The VMM provides services that manage memory, processes, interrupts, and exceptions such as general protection faults. The VMM works with virtual devices (VxDs) to allow the virtual devices to intercept interrupts and faults to control the access that an application has to hardware devices and installed software. Both the VMM and VxDs run in a single, 32-bit, flat model address space at privilege level 0 (also called ring 0). Code running in ring 0 can perform any task the processor is capable of handling, and it can manipulate any memory address in the computer system. Ring 1 has more privilege than ring 2, which in turn has more than ring 3. Windows® 95 uses only ring 0 and ring 3.

In Windows® 95, the VxDs are 32-bit protected mode modules that support the device-independent VMM by managing the computer's hardware devices and supporting software. VxDs support all hardware devices in a typical computer system C, including the direct memory access (DMA) devices, IDE controllers, serial ports, parallel ports, keyboards, and video card adapters. A VxD is required for any hardware device that has programmable operating modes or retains data over any period of time. In short, if the state of a hardware device can be changed by switching between multiple virtual machines or applications, the device usually must have a corresponding VxD.

Windows® 95 allows the user to install custom VxDs to support add-on hardware devices. It is also permissible for a VxD to support software, but no corresponding hardware device.

Modem Software

Referring now to

FIG. 5

, a block diagram is shown depicting various software components of a controllerless modem implemented Windows® 95 operating system in a according to the present invention. The modem software is organized as software layers interposed between the application that wants to use the modem and the modem itself. Windows® 95 is upwards compatible with both Windows® 3.x and DOS. In a modem according to the disclosed embodiment, therefore, Windows® 95 32-bit applications

100

, Windows® 3.x 16-bit applications

102

, and Windows® 95 DOS applications

104

are all supported. All of these applications run in ring 3, and each interfaces with the modem module

114

in a slightly different manner.

For 32-bit applications

100

, service requests are processed by VCOMM.386

108

, the virtual communications driver. VCOMM.386

108

provides protected-mode support for high-speed data ports, as well as conventional RS-232 serial ports (COM ports). VCOMM.386

108

manages all accesses to communications devices, and can support up to 128 serial ports.

VCOMM.386

108

is a standard module implemented in the Windows® 95 operating system, and remains unchanged according to the invention. Its various interface protocols are well known to those of ordinary skill in the art.

In the case of Windows® 3.x 16-bit applications

102

, a slightly different execution path is necessary because such applications are unable to use the Windows® 95 architecture. Communications software written for Windows® 3.x relies on being able to use the Win16 Comm API (not shown) to request services, and also expects to interface with the communications driver COMM.DRV

106

, another standard module in Windows® 95. COMM.DRV

106

provides a set of exported functions that an application calls to implement the Windows® communications API. In Windows® 95, COMM.DRV

106

is not tied to any specific communications hardware, and is not replaced as was done in previous versions of Windows®. COMM.DRV

106

accesses communications resources by communicating directly with VCOMM.386

108

as if it were a physical port.

For Windows® 3.x applications

102

and 32-bit applications

100

, VCOMM.386

108

interfaces with CPQFMW95.VXD

112

. CPQFMW95.VXD

112

is a virtual port driver that can call VCOMM.386

108

services directly, or can be used by VCOMM.386 to access communication ports. In Windows® 95, VCOMM.386 requires a virtual port device driver to communicate with the physical hardware. CPQFMW95.VXD

112

provides this virtual device driver. Instead of directly communicating with the UART, however, as described below CPQFMW95.VXD

112

instead communicates with a modem module

114

via a virtual UART represented by a darkened line. In the preferred embodiment, the virtual UART is contained within the modem module

114

. In prior art systems, UART chips are the hardware portion of the computer system's COM port that actually communicate between the CPU system

10

and any device attached to the COM port. As mentioned, a UART typically serializes and transmits parallel data inserting start, parity, and stop bits, and receives serial data that it converts to parallel data. A physical UART provides a variety of other options, including clock controls and configurable registers. Required UART functions are implemented in software in a modem according to the preferred embodiment. Details of the interface between CPQFMW95.VXD and modem module

114

are provided below in conjunction with

FIG. 7

, and its source code, written in assembly language, is provided in Appendix A.

The modem module

114

also contains the modem code that is typically programmed into a physical microcontroller. For reasons of compatibility with Windows® 3.x, the modem module

114

is separated into two parts, CPQFM19A.386

114

a

and CPQFM19B.386

114

b

, but could be unified in the Windows® 95 implementation. As mentioned above, the modem module

114

is not operating system dependent. A Data Terminal Equipment(DTE) portion of modem module

114

emulates a device located at the end of a transmission line which provides or receives data (i.e. computer, telephone, fax, etc.). Further, a Data Communication Equipment (DCE) portion of modem module

114

emulates a device for transmitting data, generally a modem. In the preferred embodiment, the serial data exchange interface between the DTE and DCE portions of module

114

follows the RS-232C standard of the EIA (Electronic Industries Association).

Referring briefly to Windows® 95 DOS applications

104

, data again follows a different path to the modem module

114

. Data first travels to CPQFMDB.VXD

110

, which is a port virtualization VxD that simulates communications hardware for applications running in a Windows® 95 DOS interface, or “DOS box.” This source code is found in Appendix B. After registering with VCOMM.386, CPQFMDB.VXD

110

is allowed to redirect data to the virtual port driver CPQFMW95.VXD

112

. The interface between CPQFMDB.VXD

110

and CPQFMW95.VXD

112

is shown in more detail in FIG.

7

.

The modem module

114

communicates to hardware (particularly the DSP

58

) on the modem card

30

through PCMCIA interface

26

and a PCMCIA slot connector

28

. For data transmissions, information sent to the DSP

58

by the modem module

114

includes carrier start and stop commands and the data to be sent. Modem AT commands known to those skilled in the art are used by the modem module to decide how to send data to the DSP

58

. After receiving the data, the DSP

58

generates the carrier signal and modulates data across the telephone line.

The software for implementing the modem module

114

is in general the same as the software used to program the microcontroller

40

in prior art systems. It could be written in a high level code, such as C, allowing portability between a variety of processors. Further, if the modem module

114

was originally written in C for the microcontroller

40

, it can simply be recompiled for use as the modem module

114

according to the invention.

Code for the microcontroller

40

is generally well known to the art. It is available from a number of sources, such as R. Scott & Associates. It is generally written in a high level language, so it can be used with a variety of microcontrollers

40

. Referring to the microcontroller

40

of

FIG. 2

, however, it must be understood that code used in the microcontroller

40

typically expects to communicate with a UART

46

as well as with a DSP

58

. According to the invention, the UART

46

is instead implemented as “virtual” code, included in Appendix C. Therefore, a “glue” interface is necessary for the microcontroller

40

, so that rather than communicating with a hardware UART

46

, it instead communicates with software routines to virtualize the UART

46

as well as the UART normally present within the computer system itself. These “glue” routines are also found in Appendix C. These routines are also used to communicate over the PCMCIA interface with the PCMCIA modem card

30

.

Hardware interrupts generated by the DSP

58

are communicated to the virtual port driver CPQFMW95.VXD

112

via an interrupt handler VPICD.386

116

. The VPICD.386

116

is a standard Microsoft VxD that is installed as soon as the system is booted. Port drivers must install such interrupt handlers if they are to perform input and output operations using queues.

A block diagram depicting various software components of a Windows® 3.1 modem implemented according to the present invention is shown in FIG.

6

. The modem software is organized as software layers interposed between the Windows® 3.1 and Windows® 3.1 DOS applications

102

and

104

and the installed modem card

30

.

In DOS applications

104

, reads and writes are trapped by the CPU system

10

in a port dependent manner and fault into CPQFMVCD.386

122

. The CPQFMVCD.386

122

is a lower level virtual communications driver (VxD) which handles both DOS and Windows® 3.1 applications. The CPQFMVCD.386

122

performs some of the same function as the port virtualization VxD CPQFMDB.VXD

110

(FIG.

5

), but in Windows® 3.1 typically further includes the software for actually communicating with the physical port. Windows® 95, as shown in

FIG. 5

, instead separates the virtual interfaces provided by VCOMM.386

108

and CPQFMDB.VDX

110

from the actual physical interface provided by CPQFMW95.VXD

112

together with the modem software

114

. Therefore, CPQFMVCD.386 is preferably modified to allow the datastream to be directed to a prior art modem or other serial port device. For DOS applications

104

that do not use the controllerless modem

30

, CPQFMVCD.386

122

acquires the datastream and buffers it through use of COMBUFF.386

124

(a standard Microsoft VxD).

For applications that require the controllerless modem

30

, the data is buffered through CPQFMW31.386

126

, which actually implements portions of the COMBUFF.386

124

code. CPQFMW31.386

126

is included as Appendix D. The data is then provided to the modem module

114

, and is subsequently sent to the modem hardware. All serial port data passes through the CPQFMVCD.386

122

, which has routine calls that enable it to communicate with CPQFMW31.386

126

registers. In the disclosed embodiment, CPQFMVCD.386

122

is a Microsoft VxD that has been modified slightly to recognize CPQFMW31.386

126

. Communication between CPQFMVCD.386

122

and CPQFMW31.386

126

is illustrated more fully by

FIGS. 8A and 8B

.

The modem module

114

, however, is identical in both the Windows® 3.1 implementation of FIG.

6

and the Windows® 95 implementation of FIG.

5

. That is, only the virtual device driver which communicates with a virtual UART within the modem module

114

changes. In Windows® 95, CPQFMW95.VXD

112

(Appendix A) is used to communicate with the virtual UART code of the modem module

114

. In the Windows® 3.1 version, the module CPQFMW31.386

126

assumes this role.

For Windows® 3.1 applications

102

, communications are handled by a Windows® protected-mode API SSComm.drv

120

. SSComm.drv

120

passes data to CPQFMVCD.386

122

through use of software hooks. Data then follows the same path as that as that used for DOS applications.

CPQFMCFG.EXE

130

is a hidden Windows® application that is started along with Windows® 3.1. CPQFMCFG.EXE

130

registers with Card Services

132

, which is a high level interface to Socket Services (a manufacturer dependent method of talking to PCMCIA cards). When a PCMCIA card

30

is inserted, Card Services

132

checks to see if the card is a controllerless modem card

30

according to the present invention. If so, a call is made to CPQFMW31.386

126

to let it know that a conforming card has been installed. CPQFMW31.386

126

then instructs CPQFMVCD.386

122

to direct subsequent modem data to the modem module

114

. QUEUES

134

is used to buffer data communicated between SSComm.drv

120

and CPQFMW31.386

126

.

Again, a virtualized UART is represented by the darkened line between CPQFMW31.386

126

and modem module

114

. The VPICD.386

116

, modem module

114

, and other system components perform essentially the same functions as those discussed in conjunction with FIG.

5

.

Referring now to

FIG. 7

, the CPQFMW95.VXD

112

and modem module

114

interface is shown in greater detail. As mentioned above, the interrupt handler VPICD.386

116

communicates hardware interrupts from the DSP

58

to the CPQFMW95.VXD

112

. Further, “virtual” interrupts from the virtual UARTs are ultimately passed through the interrupt handler VPICD.

386

116

. Illustrated is the case of receive data becoming present in the receive data register of the virtual UART in the modem module

114

coupled to the CPQFMW95.VXD. In that case, an “interrupt” causes a serial interrupt service routine in the CPQFMW95.VXD

112

to examine the interrupt source, found in another register of the same virtual UART of the modem module

114

. Based on that source, the interrupt routine jumps, based on an interrupt service jump table

112

a

to a data available routine. That routine must read data from the virtual UART in the modem module

114

.

One must appreciate how standard UART service drivers would read this data from a physical UART. Typically, a x86 assembly language “IN” operation would be performed from the appropriate input/output location. This could be done at ring zero, at which the code of

FIG. 7

operates, but in this case, the UART to be read from is a virtual UART. Therefore, instead of performing an “IN” operation, the source code of CPQFMW95.VXD

112

replaces each “IN” instruction with a macro. This macro causes in-line code to be compiled that, instead of performing an “IN” operation, calls the appropriate routine in the virtual UART coupled to CPQFMW95.VXD

112

. For write operations to the UART, the corresponding “OUT” input/output operation is replaced with a similar macro.

In this way, standard physical UART virtual device driver code can be used for CPQFMW95.VXD

112

, with the “IN” and “OUT” input/output instructions replaced with corresponding macros. Further details of the software interaction of

FIG. 7

are found in the flowcharts of

FIGS. 9A through 15

.

But further, the modem module

114

can remain virtually unchanged between operating systems. It simply presents the “virtual” UART interface to a operating system device driver, with the device driver being slightly modified to call that interface rather than doing a physical input or output. But because of the virtualized interface, the device driver need not be otherwise changed—if it can talk to a UART, it can talk to the virtualized UART.

The interface of the modem controller

114

to the PCMCIA card

30

is done through a standard PCMCIA interface. This portion of the modem module

114

is also preferably isolated from the remainder of the modem module

114

, so that changes in the hardware interface can be localized. This interface source code is found in Appendix E.

The modem module

114

is also preferably isolated from the actual system interrupts, specifically interrupts from the DSP

58

on the PCMCIA card

30

itself, by the VPICD.386

116

. In this way, the modem module

114

is not dependant on the hardware configuration of the interrupt sources. Further, the modem module

114

is preferably called every 10 ms so that it can perform whatever data processing is necessary to maintain communications with the DSP

58

.

FIGS. 8A and 8B

illustrate the routines used by CPQFMVCD.386

122

to determine if a modem according to the present invention is installed in the computer system. Referring first to

FIG. 8A

, control commences with a routine VCD_DISPATCH_IO

200

following a trapped I/O. This routine is contained within the CPQFMVCD.386

122

software. Control next proceeds to step

202

and a call is made to VCHD_ DISPATCH_IO, which is contained within the CPQFMW31.386

126

module. This routine (

FIG. 8B

) first determines if a controllerless modem port has been trapped. If so, control proceeds step

214

and the carry flag is cleared. Otherwise, control proceeds to step

216

and the carry flag is cleared. In either case, control next proceeds to step

218

and a return is made to VCD_DISPATCH_IO

200

.

Following this return, control proceeds to step

204

where the status of the carry flag is examined. If the carry flag is set, control passes to step

206

and the I/O call is service in a traditional manner. If the carry flag was not set by VCHD_DISPATCH_IO

200

, the data call is serviced as a controllerless modem I/O. Following either of steps

206

or

208

, control next proceeds to step

210

for a return.

It is contemplated that the arrangement of software modules could be used to support modems operating over conventional RS-232 COM ports or ISDN lines, as well as next-generation parallel port modems.

It can now be appreciated that a modem implemented according to the disclosed embodiment includes various microcontroller and UART functions are implemented in a virtualized modem module. This software implementation results in substantial monetary savings and increased data rates. Further, the microcontroller and the UART functions are preferably implemented as a module independent from other operating system software, so that the virtualized versions of the microcontroller and the UART can be easily ported to other operating systems.

The Modularity of the Controllerless Modem

Referring again to

FIGS. 5

,

6

, and

7

, one appreciates the distribution of the controllerless modem functionality according to the invention. The CPQFMW31.386

126

module and the CPQFMW95.VXD

112

module in

FIGS. 5 and 6

are different manifestations of a virtual device driver, the former compatible with the Windows® 3.1 operating system and the other compatible with the Windows® 95 operating system, respectively. The interfaces that these device drivers must present to their associated operating systems are different, but in general they are written to form a software layer between the various system components that must access a UART and the UART itself. To that end, these virtual device drivers, when called by other system software, typically access a physical UART through a series of input/output operations directed to that UART's I/O ports. The writing of device drivers for various operating systems is well known, but once standard device drivers have been written for a new operating system, it is desirable to leave that code unchanged.

But in the controllerless modem according to the invention, the physical UART is of course not present. For each operating system, extensive device drivers for such UARTs, however, do exist. According to the invention, rather than discard this extensive amount of code, or greatly modify it to integrate it into the modem module

114

itself, the interface between the modem module

114

and the virtual device driver is in the form of a “virtual” UART. In this way, one can use standard virtual device drivers with only minor modifications to communicate with the new system implemented modem module

114

. Because the modem module

114

includes a “virtual UART,” the only real modification necessary to these virtual device drivers is that they replace their input and output operating with corresponding “virtual” operations in the form of calls to the “virtual UART” rather than actual input/output operations to a physical UART itself.

Thus, for changes in operating systems, one only has to slightly revise the appropriate virtual device driver corresponding to the CPQFMW95.VXD

112

module or the CPQFMW31.386

126

module. If the modem hardware

30

remains unchanged, however, the same modem module

114

can be used with little modification. Conversely, if the modem hardware, such as the DSP

58

, is changed, then different code for the “virtual” microcontroller in the modem module

114

can be used to access that new DSP.

Using this modular software approach, porting to new operating systems becomes rather simple. Standard modem or UART software for that new operating system can be used—software which should be readily available—and the virtual modem controller in the form of the modem module

114

is simply ported to the new operating system, even being recompiled to a different CPU system

10

if necessary presenting a “virtual UART” interface to the virtual device driver.

UART Basics

In IBM PC compatible computers, UARTs present a standard series of ports at input/output addresses starting at a base port. These input/output addresses are typically accessed using input and output instructions in the x86 instruction set. Specifically, a typical instruction used to input from one of these ports is “IN AL, DX”, which inputs into the AL register the data located at the I/O address specified by the DX register. Similarly, data in the AL register is output to the port specified in the DX register by execution of an “OUT DX, AL” instruction.

The standard UART used in the IBM PC is the 8250, or one of its compatible successors, the 16450 or 16550. The standard ports in such UARTs are:

Register

Offset

DLAB

Receiver Buffer Register (DAT)

00h

0

Transmitter Hold Register (DAT)

00h

0

Interrupt Enable Register (IER)

01h

—

Interrupt Identification Register (IIR)

02h

—

Data Format Register (Line Control Register) (LCR)

03h

—

Modem Control Register (MCR)

04h

—

Serialization Status Register (Line Status Register)

05h

—

(LSR)

Modem Status Register (MSR)

06h

—

Scratchpad Register (SCR)

07h

—

Divisor Latch Register, Low Byte (DLL)

00h

1

Divisor Latch Register, High Byte (DLH)

01h

1

DLAB = Divisor Latch Access Bit (Found in LCR)

Data written to or read from each of these registers has a standard meaning, which is well known to the art. For example, a write to the transmitter hold register DAT will place a data byte in the transmitter hold register for later transmission over the serial line. As another example, the line status register LSR provides data bits such as a transmit hold register empty bit THRE, a transmit shift register empty bit TSRE, a break detection bit BRKI, a framing error bit FRMR, a parity error bit PARE, an overrun error bit ORRE, and receive data available bit RDRI.

A standard device driver similar to the CPQFMW31.386

126

module and the CPQFMW95.VXD

112

module would typically directly access these hardware registers at these I/O ports using input/output instructions. According to the invention, virtually the sole change to these virtual device drivers is that each “IN AL, DX” and “OUT DX,AL” instruction is replaced with a corresponding macro instruction “INALDX” and “OUTDXAL.” These macros, when compiled, create a call to glue logic which simulates the register accesses to a 16450 UART. This logic is found in the SIM 450.C routine located in Appendix C, and is furter described in detail below in conjunction with

FIGS. 12A through 15

. This glue logic accepts the identical parameters of the standard input and output instructions to a standard, physical UART and returns corresponding identical data. Therefore, a standard device driver that would normally access a hardware UART can be used, but instead through the SIM450.C virtual UART interface of the modem module

114

.

Before turning to the operation of this virtual UART interface, a few other minor adaptations to the virtual device software modules

112

and

126

and the modem module

114

should be recognized. First, when the modem module

114

was previously implemented in its own dedicated microcontroller

40

of

FIG. 2

, it could essentially run continuously because the microcontroller

40

would have no have other functions. Because the modem module

114

is now implemented for execution by a CPU system that has other duties, however, the modem module

114

must instead relinquish control after it has carried out its necessary functions. This essentially requires little, other than to ensure that rather than going to a holding loop, the modem module

114

returns to the operating system.

Just as the modem module

114

must periodically return to the operating system, it must also periodically be called by the operating system to execute its desired functions. This is generally done through timer software within the operating system itself. That is, a standard timer device is requested to call the modem module

114

periodically so that it may carry out its desired functions. This is accomplished in two ways. First, the modem module

114

is periodically called by the timer. Second, because the DSP

58

will periodically request servicing by the modem module

114

, it provides an interrupt to the VPICD.386

116

module, which in turn will cause both the modem module

114

and the virtual device module

112

or

126

to be serviced.

Modification to Standard UART Virtual Devices

Turning to

FIGS. 9A and 9B

, these figures present an illustrative flowchart of how standard routines within the CPQFMW95.VXD

112

module go about accessing the modem module

114

. A PPORTOPEN routine

300

is presented for illustration. This routine

300

would generally be called by other routines within the operating system software, such as the VCOMM.386

108

module and the CPQFMDB.VXD

110

module. Of course, numerous other routines exist within the CPQFMW95.VXD

112

module which are called by other routines in the operating system. These various modules access the UART to both send and receive data to and from a serial device and to control the UART. But this illustrative routine

300

is shown to illustrate how these physical calls are easily replaced with virtual calls.

Beginning at step

302

, the routine

300

determines whether a port exists but has not yet been opened. If untrue, control proceeds to step

304

, where the routine returns either because the port does not exist or because it is already opened. Otherwise, control proceeds from step

302

to step

306

, where the data structures for the port are established. Then proceeding to step

308

, the EDX register is loaded with the port base address of the serial port desired to be opened plus an offset of 03h. This offset corresponds to the line control register LCR port offset for a standard 8250, 16450, or 16550 UART. Thus, the EDX register now has the appropriate port address for an input from the LCR port.

Proceeding to step

310

, an “INALDX” routine

350

is executed. As is discussed below in conjunction with

FIG. 10

, this routine

350

is actually preferably a macro that forms expanded in-line code to call the appropriate glue logic in the virtual UART interface, which in turn calls the modem module

114

. In step

310

, the “INALDX” macro performs the precisely same function as if the line control register LCR of a physical UART had been read from using an “IN AL,DX” instruction of an x86 processor. More specifically, the AL register now contains the data input from the “virtual” line control register LCR. Proceeding to step

312

, the high order bit of the AL register is set, which corresponds to the divisor latch access bit DLAB of the line control register LCR, and then proceeding to step

314

, a corresponding “OUTDXAL” macro is executed, which sets the DLAB within the line control register LCR of the “virtual” UART according to the invention. Control then proceeds to step

316

, where the EDX register is loaded with the base port address plus 00h, which corresponds to the divisor latch low byte register DLL. At step

318

, the INALDX macro is executed, reading in the divisor latch low order byte DLL from the virtual UART. At step

320

, the AL register is saved, and the EDX register is loaded with the base port address plus 01h, which corresponds to the divisor latch high byte DLH. Proceeding to step

322

, this byte is read in using the INALDX macro. Then proceeding to step

324

, the low and high order bytes of the divisor latch are combined and stored. At step

326

, AL is loaded with the original line control register LCR input value. Then proceeding to step

328

, the OUTDXAL macro is executed, restoring the line control register LCR to its original value—i.e., the DLAB is disabled if originally disabled. Then proceeding to step

330

, other setup is executed.

The point of this sequence of instructions is that the virtual UART located within the modem module

114

is accessed identically as though it were a real UART. The preceding sequence has been executed to set the divisor latch to an appropriate value, which effectively sets the baud rate. It must be appreciated that there is effectively no “baud rate” in the virtual UART because data is virtually instantaneously transferred between the modem module

114

and whatever device driver is calling that software through the virtual UART. But standard UART device drivers expect to be able to set and access the baud rate, so the virtual UART provides access to virtual divisor latch bytes, even if they really do not do anything. In this way, existing hardware UART device drivers are easily modified for use with the virtual UART of the modem module

114

.

To complete the routine, control then proceeds to step

332

, where if errors are detected, control proceeds to step

334

where the routine returns. If there were no errors, control instead proceeds from

332

to step

336

, where the port base address plus the appropriate offset for the modem control register MCR is input. Then the OUTZ bit of that data is enabled and is output using the OUTDXAL macro at step

338

. Control then proceeds to step

340

, where a call is made to unmask the interrupt request line IRQ. As discussed below, the virtual UART also causes “virtual” invoke an appropriate operating system interrupt service routine. Proceeding from step

340

, control then returns at step

342

.

Turning to

FIG. 10

, the two macro routines INALDX

350

and OUTDXAL

360

are shown. The INALDX routine

350

substitutes for the standard IN AL,DX instruction on the x86 series of microprocessors, while the OUTDXAL routine

360

correspondingly substitutes for the OUT DX,AL instruction. These are not callable routines, but are instead macros, which are assembled in-line in the CPQFMW95.VXD

112

module, the CPQFMDB.VXD

110

module, and the corresponding routines in FIG.

6

. The INALDX routine

350

and the OUTDXAL routine

360

in effect substitute a call to glue logic for the standard input/output instructions.

The INALDX routine

350

begins at step

352

, where it saves any registers that will be changed. Proceeding to step

354

, a virtual device driver call is made to a glue routine VIPD1_REG_READ. This routine, further discussed below in conjunction with

FIG. 11

, strips the physical address off of the DX register, leaving an offset, and then calls the virtual UART routines discussed below in conjunction with

FIGS. 12A-15

.

Proceeding to step

356

, the registers are restored and the result of the call at step

354

is stored in the AL register. Then, at step

358

, the in-line macro is done so other code continues to execute.

The OUTDXAL routine

360

works in a similar way, beginning at step

362

, where it stores the registers. Control then proceeds to step

364

, where a glue logic routine (see

FIG. 11

) is called, specifically VIPD

1_REG_WRITE. Control next proceeds to step 366, where the register is restored, with the routine completing at step 368.

It will be appreciated that if the INALDX routine

350

and the OUTDXAL routine

360

were simply replaced with the appropriate I/O operation, then the various device drivers would operate normally in conjunction with a hardware UART with virtually no changes.

Turning to

FIG. 11

, shown are the VIPD1_REG_READ routine

370

and the VIPD1_REG_WRITE routine

380

. These routines, called at steps

354

and

364

of

FIG. 10

, are in effect glue logic for bridging between the virtual UART of the modem module

114

and the remainder of the operating system. The VIPD1_REG_READ routine

370

begins at step

372

, where it performs a binary AND operation of the address in the DX register with 07h, stripping off the physical address and leaving an offset to the appropriate port of a standard UART.

Proceeding to step

374

, the VIPD

1_REG_READ routine 370 calls a routine SIM

450_READ

400

. The SIM450_READ routine

400

of the virtual UART simulates a read from a port of a 16450 UART. This routine

400

performs a “read” from the appropriate “port” of the virtual UART. Proceeding to step