JPH1083365A - Computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce size and cost and to efficiently update functions by realizing the hardware part of a modem by a software module. SOLUTION: A modem card 30 is connected to a computer through a slot connector 28 but not provided with a microcontroller, UART(universal asynchronizing receiver-transmitter) 46, etc., before being necessitated. The functions of these are realized by a virtual modem controller called by the operating system of the computer itself. The virtual modem controller includes virtual UART, which looks a hardware from an operating software, and is provided with an entry point for a call to replace with an input/output instruction. Therefore, a standard device driver code written for executing input/output operation is converted to operate virtual UART.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates to a modem for use in a personal computer, and more particularly, to a host CPU having a controller and a UART function using software organized as virtualized drivers and modem modules. And the module is virtualized U
It relates to a modem that communicates through an ART interface.

[0002]

BACKGROUND OF THE INVENTION Most personal computers today include some form of modem function. Typically, a high-speed modem system is built into the option card and is available from the International Telegraph and Telephone Consultative Committee (CCITT: I
nternational Telegraph and Telephone Consultative
Committee), V.22, V.22b
is, V.32, V.32bis, and V.34 (28.
8Kbps) protocol to support various modem communication protocols, such as "data pump" (data
pump). The data pump itself typically provides D, which performs modulation, demodulation, and echo cancellation.
SP (digital signal processor) and analog-
Digital (A / D) and digital-analog (D /
A) Includes a coder / decoder (CODEC) that performs the conversion. The analog signal from the telephone line is digitized by the CODEC and then demodulated by the DSP to extract the original digital data sent from the external device. When this procedure is reversed, the data is transmitted to the external device by the modem.

[0003] In conventional modems, the support logic for interfacing the modem to the computer system typically includes a microcontroller, thereby via a I / O bus a universal asynchronous receiver and transmitter (UART). receiver tr
Ansmitter establishes a communication link, controls a sequence of events, initiates a call, or answers a call, and sends or receives digital data from a computer system. The microcontroller also typically performs error correction procedures, such as those according to the V.42 protocol, and compression / decompression procedures, such as those according to the V.42bis protocol recommended by CCITT.

[0004] UARTs inherently serialize data residing on a serial interface, typically a bus (ie, serial transmission, such as over an RS-232 communication link, and reception of such data, It is designed as an intelligent microchip for its conversion to parallel form and transmission over a bus). Access to the UART chip is typically obtained through I / O ports (typically COM1 and COM2) of the personal computer system. A typical representative is a U.S.A. made by National Semiconductor Corporation.
ART8250 and 16450 chips.

[0005]

The hardware portion of a modem device accounts for most of the underlying cost of such a modem. In addition, these hardware parts also affect the size of the modem. It would be desirable to reduce the number of parts in the modem, as it would reduce costs.

Furthermore, in today's circumstance where technology is changing rapidly and becoming obsolete, ease of upgrade and portability of data across different operating system platforms are difficult.
y) is important to modem manufacturers. Manufacturers face the problem of recovering hardware development costs despite shortening the product life cycle. Therefore, any reduction in such hardware development is equally desirable.

[0007]

SUMMARY OF THE INVENTION In a modem according to a preferred embodiment of the present invention, the UART and microcontroller functions are virtualized and implemented as software ("modem module") running on a host processor. The modem module interfaces with a second layer (the "virtual device drive layer"), which includes an operating system specific virtual port driver that interacts with the operating system. This dicotomized architecture has the advantage that the modem module software is virtually invariant when using the modem with a different operating system (OS). Most operating systems already have the ability to communicate with the UART (abili
ty). Therefore, modifying only the virtual device drive layer is simpler and more cost effective than trying to modify both layers.

[0008] Implementing the hardware portion of the modem as a software module also offers additional advantages. Leveraging the potential of today's powerful microprocessors eliminates the shortcomings associated with physical UARTs and provides high-speed modem performance that is substantially improved over "standard" modems. Therefore, the modem according to the present invention can achieve lower cost, higher speed, and easier functionality than the conventional modem card.

[0009]

DETAILED DESCRIPTION OF THE INVENTION Referring to FIG. 1, a simplified block diagram of a computer system C including a modem card 30 is shown. Computer system C includes a central processing unit (CP) coupled to host bus 16.
U) The system 10 is built in. The host bus is C
The PU system 10 has a memory called a main memory 12.
It functions to interface to the rest of the computer system C, including the array. The CPU system 10 is an Intel Corpora
486 or PENTIUM, or a microprocessor, cache controller,
And a more complete CPU system including other components. Video system 14
Are also connected to the host bus 16.

[0010] The host bus 16 is coupled to an I / O bus 20 through a bus controller 18. The bus controller 18 uses an industry standard architecture (IS
A: Industry Standard Architecture (Bus) or Extended Industry Standard Architecture (EISA)
Preferably, it is compatible with a Tandard Architecture) bus. The exact architecture of the I / O bus 20 is not critical to the invention.

Various components conventionally arranged on a system board of the computer system C are connected to the I / O bus 20. These are BIOS
And a read only memory (ROM) 32 for providing system and other system level instructions, and an 8042 keyboard controller 34. The keyboard portion 36 and the auxiliary port or pointing device port 38
4 is connected. Hard disk drive 24
Is connected to the I / O bus 20 via the IDE controller 22.
It is connected to the. The IDE controller 22 has a built-in buffer control logic, and generates a chip select for the IDE device during data reading and data writing to the IDE device.

When the modem card 30 is connected to the slot connector 2
8, PCMCIA (Personal Computer Memory Card)
CardInternational Association) Interface 2
6 is connected. PCMCIA interface 2
6 enables connection to the I / O bus 20. The PCMCIA specification 2.0, originally intended as a memory expansion (standard 1.0) interface, uses a PCMCIA interface for fax modems, SCSI adapters, Global Positioning System (GPS) reception. Various I / O devices, such as machines, allow credit card-sized cards to be used. For simplicity, it is assumed that the modem functions discussed below include the ability to process facsimile, data, and voice information. This is because the communication protocol for each of these is involved.

The computer system of FIG. 1 is an example, and numerous other computer system designs may be used. Further, modem card 30 may be located directly on I / O bus 20 or on any other bus utilized by computer system C, including host bus 16. The exact location of the modem is not critical to the invention.

Referring briefly to FIG. 2, a conventional modem
A hardware block diagram is shown. Conventional modems have a data access configuration (DAA).
through an angement) to a telephone line (not shown). The data access configuration electrically separates the modem 30 from the telephone line and provides the Federal Communications Commission (FCC).
EMI / RFI (electromagnetic / radio frequency interference)
interference / radio frequency interference). The DAA 54 also typically separates the received signal from the transmitted analog signal,
Generate a ring signal to notify the computer system to respond. DAA 54 is a public switched telephone network (PS).
Preferably, it is compatible with a public switched telephone network (TN) interface. DAA54
Receives signals from a telephone line via a telephone jack, such as the RJ11C used in standard telephones.

Further, conventional modems include a microcontroller 40 which requires a DSP 58 and support memory 64, RAM 42 and ROM 44, a physical UART 4
6, and peripheral interface device (PID: perip
heral interface device) 48. In such prior art modems, microcontroller 40 is typically
The communication with the CPU system 10 is performed through the UART 46. The CPU 10 uses a separate UART,
Data transmission / reception with 46 is performed. On the other hand, UART 46
It supplies data to the microcontroller 40 and sends data from the microcontroller 40 to the CPU system 10.

However, the microcontroller 40
Cannot simply receive data from the CPU 10, send it over the telephone line, or simply receive data from the telephone line or send it to the CPU 10. That is, the standard HayesAT
Contains the software needed to implement a modem command set, such as a standard Hayes AT command set. Microcontroller 4
0 includes software that receives an ASCII command according to the AT command set by the UART 46 and performs various functions based on the command.
For example, the "ATH" command causes the microcontroller 40 to "hang up" the DAA 54 and disconnect the modem link. Other commands are known from the AT command set. In addition, microcontroller 40 also implements various error correction and data compression protocols. All of these functions are known to those skilled in the art. When the software is in communication mode rather than command mode, microcontroller 40
Data is transferred between T46 and the DSP 58. The DSP 58 then converts this data to the appropriate digitized signal level and converts the data to the CODEC 56
(See FIG. 4). To end the data communication mode and enter the command mode, the microcontroller 40 preferably operates according to the AT command set, switches to the command mode, and causes the host PC to supply the AT command through the microcontroller 40. Thus, a series of three plus signs "+
++ ". One common microcontroller used for microcontroller 40 is a controller with an embedded Motorola MC68302.

Referring now to FIG. 3, there is shown a block diagram of modem hardware according to an embodiment of the present invention disclosed herein. Physical components that are no longer required by being implemented in software are indicated by dashed lines. As mentioned above, prior art modem systems typically include a microcontroller 40 (FIG. 2), which provides data to DSP 58, a monitor and a DAA.
54 was controlled to perform on-hook or off-hook as necessary. To establish a communication link, the microcontroller 40 sends out an appropriate sequence of signals to originate or answer a telephone call. However, in the modem according to the preferred embodiment, the various functions of the microcontroller 40 and the UART 46 are based on the virtual modem
Implemented in module 114 (FIGS. 5 and 6). This software implementation resulted in significant economic savings and increased data rates. Further, the microcontroller 40 and the UART
46 is preferably implemented as a module independent of other operating system software so that microcontroller 40 and virtual versions of microcontroller 40 and UART 46 can be easily moved to other operating systems. To

Turning now to FIG. 4, a modem card 30 according to the present invention is shown in more detail. PCMCIA
Host Interface Application Specific Integrated Circuit (ACI)
C: application specific integrated circuit) PID
Modem 62 via the PCMCIA slot connector 28 using the computer system C
It is connected to the. PID2 62 is EEPROM64
Is also connected. The EEPROM 64 has a PID2
62 (CIS: Card Info)
rmation Structure). In the preferred embodiment, the EEP
ROM 64 is manufactured by National Semiconductor Corporation. PID2 6
2 further includes an interface ASIC V32INF
C2, while this is connected to DSP chip 5
8 is provided. DSP58
Performs calculations to give the desired modem function. In the preferred embodiment, DSP 58 comprises AT & T Corporation.
General-purpose DSP1 manufactured by (AT & T corporation)
6A.

The DSP 58 generally converts digital data from the computer system C into a digitized analog waveform and supplies it to the CODEC 56. CO
The DEC 56 then supplies the true analog waveform to the DAA 54. Also, the DSP 58 receives a digitized analog waveform from the CODEC 56. CODEC5
6 receives the true analog waveform from DAA 54 and converts this analog data into digital data for computer system C. In addition, DSP58
Preferably also performs echo cancellation and cancels the signal echoed back to modem 30 by the transmitted signal.

The CODEC 56 includes RXD, TXD, SY
By using four signals called NC and CLK, DSP5
8 is connected. The RXD and TXD signals are received and transmitted digital signals, and the SYNC and CLK signals are conventional signals used between DSP 58 and codec 56. V32INFC2 60, DSP58
And CODEC 56 cooperate to generally provide “
It forms what is called a “pump” 50. Data pump 50 is typically a modem data pump chip set that supports various protocols for modem communication. In the preferred embodiment, data pump 50 is A
T & T Microelectronics (AT & TMicroelectronic
s), DSP16A-V32IN
FC2-LT V.32bis plus FAX Dat
a A Pump Chip Set is used.

Codec 56 is an RXA or DAA 54
, And supplies a TXA, that is, a transmission analog signal to the DAA 54. CODEC 56 is D
The analog data from the RXA signal is digitized for processing by SP58. Similarly, digital data TXD received from DSP 58 is converted to analog format on a TXA signal.

As mentioned above, DAA 54 functions to separate modem 30 from the telephone line in order to meet national regulations for FCC or EMI / RFI interference control. Data received by the DAA 54 from an external device is filtered and transmitted from the CODEC 56 to the DAA 54 on the TXA signal.
Are supplied in analog form. Similarly, data transmitted by modem 30 is transmitted from CODEC 56 to DAA
At 54, it is provided on the TXA signal and then asserted by the DAA 54 on the telephone line. The data is preferably transferred serially between the DSP 58 and the CODEC 56. Further details of the illustrated DAA circuit can be found in "Modem Havin
g Separate Modem Engine and Data Access Arrangemen
Pending US Patent Application Serial No. 08/30, entitled "t"
No. 4,262, and is referenced in the present application.

DAA 54 is an RJ-11 telephone jack 5
2 to a standard telephone line. Telephone jack 52 is provided for supplying and receiving certain telephone signals, as is known to those skilled in the art. Since many different types of telephone lines and other transmission media are possible, telephone jack 52 and DAA 54 are configured to be compatible with whatever telephone line means or transmission medium is used. Because the invention is not limited to any particular type of transmission medium, telephone jack or DAA, the ones shown here are used for illustrative purposes only.

The modem 30 according to the preferred embodiment includes a plug
Ideally, it should be able to identify itself according to the method described in the And Play External COM Device Specification. In addition, to qualify for the Windows® 95 logo, the modem 30 supports at least 9600 bits per second (bps) with the V.42 / V42bis protocol for data modems, and TIA-6
02 (Hayes® compatible) AT command set and extended functions for flow control of V42 / V42bis, compatible with at least 9600 bps V.29 fax function of class 1 (TIA-578A), In addition, it must support a UART interface compatible with 16459A / 16550. Windows 95 is an older 8250 UAR
It also supports T chips.

Background of Window® 95 At the heart of Window® 95 is a 32-bit protected mode operating system called a virtual machine manager (VMM). VMM provides services to manage exceptions such as memory, processes, interrupts, and general breach of protection. VMM is a virtual device (VxD)
Work together to allow the virtual device to intercept interrupts and defaults, access the hardware devices of the application, and manage installed software. Both VMM and VxD execute at privilege level 0 (also called ring 0) in a single 32-bit flat model address space. Code executing on ring 0 can perform any task that the processor can handle, and can operate on any memory address in the computer system. Ring 1 has more privileges than ring 2, while ring 2 has more privileges than ring 3. Windows® 95 uses only Ring 0 and Ring 3.

In Windows 95, VxD is a 32-bit protected mode module,
By managing the hardware devices of the computer and supporting the software, the device supports an independent VMM. VxD is a direct memory access (DMA)
All hardware devices in a typical computer system C are supported, including devices, IDE controllers, serial ports, parallel ports, keyboards, and video card adapters. VxD is required for any hardware device that has a programmable processing mode, that is, retains data for any period of time. That is, if the state of a hardware device can be changed by switching between multiple virtual machines or applications, the device must always have a corresponding VxD.

Windows 95 supports the addition of hardware devices by allowing users to install custom VxDs. Also, Vx
D is also allowed to support the software, but not the corresponding hardware devices.

Modem Software Referring now to FIG. 5, there is shown various software configurations of the Windows 95 operating system implementing a controllerless modem according to the present invention. Modem software is organized as a software layer that intervenes between the application that wants to use the modem and the modem itself. Windows (R) 95 is Windows (R) 3.x and DOS
Is upward compatible. In the modem according to the embodiment disclosed herein, therefore, Windows 9
5 32-bit applications 100, Windows
(Registered trademark) 3.x 16-bit application 1
02 and the Windows (registered trademark) 95 DOS application 104. All of these applications run on Ring 3 and each interface with the modem module 114 in a slightly different manner.

In a 32-bit application 100, service requests are processed by VCOMM.386 108, a virtual communication driver. VCOMM.386
108 allows the protected mode to accommodate high speed data ports and conventional RS-232 serial ports (COM ports). VCOMM.386 10
8 manages all access to the communication device and can handle up to 128 serial ports.

VCOMM.386 108 is compatible with Windows
One of the standard modules used in the <RTIgt; 95 </ RTI> operating system, which remains unchanged according to the present invention. Various interfaces
Protocols are well known to those skilled in the art.

16 bits for Windows (registered trademark) 3.x
In the case of application 102, such an application cannot use the Windows® 95 architecture, and therefore requires a slightly different execution path. Communication software written for Windows (registered trademark) 3.x is a Win16Comm API (not shown).
Service is basically requested by using
It also envisages interfacing with another standard module of ndows® 95, the communication driver COMM.DRV106. COMM.DRV
106 is a set of exported functions (exported functio
n) and the application calls this
Implement a Windows (registered trademark) communication API. Windows
In (Registered Trademark) 95, COMM.DRV 106 is not connected to any specific communication hardware,
Not replaced, as was done in previous versions of ows®. COMM.DRV106
Access communication resources by communicating directly with VCOMM.386 108 as if it were a physical port.

Windows® 3.x application 102 and 32-bit application 100
Then, VCOMM.386 108 is the CPQFMW9
5. Interface with VXD112. CPQF
The MW95.VXD 112 is a virtual port driver and can directly call the services of VCOMM.386 or it can be used by VCOMM.386 to access a communication port. In Windows 95, VCOMM.386 requires a virtual port device driver to communicate with physical hardware. CPQFMW95.XVD112 provides this virtual device driver. However, instead of communicating directly with the UART, as described below, the CPQFMW95.VXD 112 communicates with the modem module 1 through a virtual UART, which is represented by a bold line.
14 is communicated. In the preferred embodiment, the virtual UART is included in the modem module 114. In prior art systems, the UART chip is the hardware portion of the COM port of the computer system and actually communicates between the CPU system 10 and any device attached to the COM port. As described above, UARTs typically serialize and transmit parallel data, insert start, parity, and stop bits, receive serial data, and convert it to parallel data. The physical UART provides a variety of optional functions, including clock control and configurable registers. The necessary UART functions are implemented in software in the modem according to the preferred embodiment. CPQFMW95.
Details of the interface between the VXD and the modem module 114 are described below in connection with FIG. Appendix A shows the source code in assembly language.

[0033] Modem module 114 also includes modem code, which is typically programmed into a physical microcontroller. For compatibility with Windows® 3.x, the modem module 114 has two parts: CPQFM19A.38.
6 114a and CPQFM19B.386 114b
, But can be integrated in an implementation of Windows® 95. As mentioned above, the modem module 114 is operating system independent. The data terminal equipment (DTE) portion of the modem module 114 emulates the equipment (ie, computer, telephone, fax, etc.) located at the end of the transmission line that supplies or receives data. ). Further, the data communication equipment (DCE) portion of the modem module 114 emulates a data transmitter, typically a modem. In the preferred embodiment, the DTE portion of module 114 and DTE
The serial data exchange interface between the CE parts is based on EIA (Electronic Industries Association) R
It complies with the S232C standard.

Referring briefly to the Windows® 95 DOS application 104, data again reaches the modem module 114 through a different path. The data is first CPQFMDB.VXD110
Go to This is Windows (registered trademark) 95DOS
Interface, a port virtualized VxD that simulates the communication hardware for applications running in a "DOS box". This source
The code is shown in Appendix B. After registering with VCOMM.386, CPQFMDB.VXD110 is allowed to retransmit data to virtual port driver CPQFMW95.VXD112. CPQFMDB.VXD1
The interface between 10 and CPQFMW95.VXD 112 is shown in more detail in FIG.

The modem module 114 is a PCMCI
It communicates through A interface 26 and PCMCIA slot connector 28 to hardware on modem card 30 (specifically, DSP 58). In data communication,
Information sent by the modem module 114 to the DSP 58 includes carrier start and stop commands and data to be sent. The modem module is
A modem AT command known to those skilled in the art is used to determine how to send data to DSP 58.
After receiving the data, the DSP 58 generates a carrier signal,
Modulate data over telephone lines.

The hardware that implements modem module 114 is generally identical to the software used to program microprogram 40 in prior art systems. It can be written in high-level code, such as C, and allows porting between various processors. Further, if the modem module 114 was originally written in C for the microcontroller 40, it can be used as the modem module 114 according to the present invention by simply recompiling it.

The code for the microcontroller 40 is
It is generally well known in the art. This is R.
Available from a number of sources, such as Scott & Associates. Usually this is written in a high-level language,
It can be used with various microcontrollers 40. However, referring to the microcontroller 40 of FIG. 2, it should be understood that the code used for the microcontroller 40 allows for communication with the UART 46 and the DSP 58. According to the present invention, UART 46 is instead implemented as "virtual" code contained in Appendix C. Therefore,
Because a "glue interface" is required for the microcontroller 40, it communicates with software routines instead of the hardware UART, instead of the UART 46, and the computer interface.
Virtualize the UART normally present in the system itself. This "paste" routine is also shown in Appendix C. These routines are also used to communicate with the PCMCIA modem card 30 through the PCMCIA interface.

The hardware interrupt generated by the DSP 58 includes an interrupt handler VPICD.3861.
16 through the virtual port driver CPQFMW9
5. Transmitted to VXD112. VPICD.386 1
16 is a standard Microsoft VxD, which is installed as soon as the system is booted. The port driver must install such an interrupt handler when performing input / output processing using the queue.

A block diagram depicting various software configurations of Window® 3.1 implemented in accordance with the present invention is shown in FIG. The modem software is organized as a software layer inserted between the Window 3.1 and Window 3.1 DOS applications 102, 104 and the mounted modem card 30. ing.

In the DOS application 104, reads and writes are port dependent and are received by the CPU system 10 and CPQFMVCD.386 1
22. CPQFMVCD.386 122
Is a low-level virtual communication driver (Vx) that processes DOS and Windows 3.1 applications.
D). CPQFMVCD.386 122 is a port virtualization VxD CPQFMDB.VXD110 (FIG. 5).
Performs some of the functions of Windows®
3.1 includes additional software to actually communicate with the physical port. Window (registered trademark) 95
Separates the virtual interface provided by VCOMM.386108 and CPQFMDB.VDX110 from the actual physical interface provided by CPQFMW95.VXD112 and modem software 114 as shown in FIG. Therefore, CPQFM
VCD.386 is preferably modified so that the data stream can be sent to a prior art modem or other serial port device. For the DOS application 104 that does not use the modem 30 without a controller, the CPFMVCD.386 122
Acquire the data stream and select COMBUFF.386 1
24 (standard Microsoft VxD) to buffer it.

For applications requiring a modem 30 without a controller, the data is CPQFMW
It is buffered through 31.386 126. CP
QFMW 31.386 126 is actually a COMBU
Implement some parts of the FF.386 124 code.
CPQFMW 31.386 126 is included as Appendix D. Next, the data is transferred to the modem module 11.
4 and subsequently sent out to the modem hardware. All serial port data is CPQFMV
CD.386 122. CPQFMVCD.3
86 122 has routine calls that allow it to communicate with the CPQFMW 31.386 126 register.
In the embodiment disclosed herein, CPQFMVCD.386
122 is Microsoft VxD, CPQFM
It has been slightly modified to recognize W31.386 126. The communication between CPQFMVCD.386 122 and CPQFMW31.386 126 is shown in more detail in FIGS. 8A and 8B.

However, the modem module 114
Is the same in both the implementation of Windows 3.1 in FIG. 6 and the implementation of Windows 95 in FIG. That is,
Only the virtual device driver which communicates with the virtual UART inside the modem module 114 is different. In Windows (registered trademark) 95, CPQFMW95.
Communication with the virtual UART code of the modem module 114 is performed using the VXD 112 (Additional Material A). In the Windows 3.1 version, it is assumed that the modem CPQFMW31.386 126 performs this role.

In the Windows® 3.1 application 102, communication is handled by the Windows® protected mode API SSCom.drv120. SSCom.drv 120 uses a software hook to create a CP.
Pass the data to QFMVCD.386 122. afterwards,
Data travels along the same path used for DOS applications.

The CPQFMCFG.EXE 130 is a hidden Windows (registered trademark) application and is started together with Windows (registered trademark) 3.1. CP
QFMCFG.EXE 130 is the card service 132
Registered in. Card Services 132 uses sockets
It is a high-level interface to services (manufacturer dependent method of transmitting PCMCIA cards). PCMC
When the IA card 30 is inserted, the card service 132
Checks whether the card is a modem card 30 without a controller according to the present invention. On the spot, CPQF
Call MW31.386126 to indicate that a compliant card has been implemented. Then, CPQFMW3
1.386 126 is CPQFMVCD.386 122
, To direct subsequent modem data to the modem module 114. QUEUES 134
SSComm.drv120 and CPQFMW31.3
Used to buffer data communicated between 86126.

The virtualized UART is CPQFMW31.3.
86 and the modem module 114 are represented by the bold lines. VPICD.386 116, modem module 114, and other system components perform essentially the same functions as discussed with respect to FIG.

Referring to FIG. 7, CPQFMW95.V
The interface between XD 112 and modem module 114 is shown in detail. As described above, the interrupt handler VPICD.386 116 sends a hardware interrupt from the DSP 58 to CPQFMW95.VXD.
Transmit to 112. Furthermore, "virtual" from virtual UART
Finally, the interrupt handler VPIC
D.386 116. Shown is the CPQF
This is the case of received data going into the received data register of the virtual UART in the modem module 114 coupled to MW95.VXD. In that case, the "interrupt" is sent to the serial interrupt service routine in the CPQFMW95.VXD 112 by the modem module 11
4. Check the interrupt source in another register of the same virtual UART of 4. Based on this interrupt source, the interrupt routine jumps to an available routine based on the interrupt service jump table 112a. This routine must read data from the virtual UART in the modem module 114.

The standard UART service driver is
One has to consider how to read this data from the physical UART. Typically, x86 assembly language "IN" processing is performed from the appropriate input / output location. This can be done on ring 0. In ring 0, the code of FIG. 7 operates, but in this case, the UART to be read is a virtual UART. Therefore, instead of executing “IN” processing, CPQFMW9
5. The VXD 112 source code replaces each "IN" instruction with a macro. This macro calls the appropriate routine in the virtual UART that is coupled to CPQFMW95.VXD112 instead of compiling in-line code and performing "IN" processing. Regarding the writing process to the UART, it corresponds. "
OUT "input / output processing is replaced by a similar macro.

Thus, by replacing the "IN" and "OUT" input / output instructions with the corresponding macros, the standard physical UART virtual device driver can be replaced with the CPQFMW.V
Can be used for XD112. Details of the software interaction of FIG. 7 are shown in the flowcharts of FIGS.

However, furthermore, the modem module 114
Can remain virtually unchanged between operating systems. This is simply a "virtual" connection to the operating system device driver.
Instead of representing a UART interface and slightly modifying the device driver to provide physical input or output,
Call that interface. However, no further changes need to be made to the device driver for the virtualization interface. If it can be transmitted to the UART, it can also be transmitted to the virtualized UART.

Modem for PCMCIA card 30
The interface of the controller 114 is a standard P
This is performed via the CMCIA interface. This part of the modem module 114 is preferably separated from the rest of the modem module 114 so that changes in the hardware interface can be limited in part. The source of this interface
The code is shown in Appendix E.

The modem module 114 also preferably isolates itself from actual system interrupts, in particular, from the PICCD.386 116, from the DSP 58 of the PCMCIA card 30 itself. In this way, the modem module 114 does not depend on the hardware configuration of the interrupt source. In addition, the modem module 114 preferably calls every 10 ms to allow any necessary data processing to be maintained to maintain communication with the DSP 58.

FIGS. 8A and 8B illustrate the use of CPQFMVCD / 386 to determine if a modem according to the present invention is installed in a computer system.
Reference numeral 122 denotes a routine used. First, FIG. 8A
With reference to the control, the routine VCD_DISPAT
Starting at CH_IO 200, this is followed by captured I / O. This routine is called CPQFMVCD.28
6 Included in the 122 software. Control then transfers to step 202 where VCHD_DISPATC
Call H_IO. This is CPQFMW31.3
86 included in the 126 module. The routine (FIG. 8B) first determines if it has captured a modem port without a controller. If so, control transfers to step 214 to clear the carry flag. If not, control transfers to step 216 to clear the carry flag. In either case, control then passes to step 218 and returns to, or returns to, VCD_DISpatch_IO 200.

Following this return, control proceeds to step 2
Go to step 04 to check the status of the carry flag. If the carry flag is set, control passes to step 206 and the I / O call is performed as before. Carry flag is VCHD_DISPA
If not set by TCH_IO200,
Make a data call as a modem I / O without a controller. Following either step 206 or 208, control then transfers to step 210 and returns.

Using the configuration of this software module, a conventional RS-232COM port or ISDN
It is conceivable to be able to support a modem that operates on a line, and also on a next-generation parallel port modem.

It will be apparent that the modem implemented by the present invention includes various microcontrollers and the UART function is implemented in a virtualized modem module. This software implementation results in significant economic savings and increased data rates. Further, by implementing the microcontroller and UART functions as modules independent of other operating system software, virtualized versions of the microcontroller and UART can be easily ported to other operating systems. It is preferable to do so.

Modularization of a Controllerless Modem Referring again to FIGS. 5, 6 and 7, the functional distribution of a controllerless module according to the present invention is shown. CPQFMW31.386 in FIGS. 5 and 6
126 modules and CPQFMW95.VXD11
The two modules are different examples of virtual device drivers, each of which is compatible with the Windows 3.1 operating system and the other is Windows
Compatible with the ® 95 operating system. Although the interfaces that these device drivers must each adapt to the corresponding operating system are different, they typically form a software layer between the various system components that must access the UART and the UART itself. It is written as follows. To this end, these virtual device drivers, when called by other system software, typically access the physical UART through the I / O port of the UART and a series of targeted I / O operations. It is known to write device drivers for various operating systems, but once a standard device driver has been written for a new operating system, it is desirable to keep the code unchanged.

However, in a modem without a controller according to the present invention, a physical UART does not exist. However, for each operating system,
There is a wide range of device drivers for UARTs. In accordance with the present invention, instead of discarding or modifying this bulk of the code and integrating it into the modem module 114 itself, the interface between the modem module 114 and the virtual device driver is based on the "virtual" UART. Taking the form. In this manner, the new system can communicate with the implemented modem module 114 using standard virtual device drivers and with only minor modifications.
Since the modem module 114 includes a "virtual" UART, the actual changes required for these virtual device drivers are:
It merely replaces those I / O operations with corresponding "virtual" operations in the form of calls to "virtual UARTs", rather than actual I / O operations on the physical UART itself.

Therefore, in response to changes in the operating system, the appropriate CPQFMW31.386 12 corresponding to the CPQFMW95.VXD112 module
The six modules need only be modified slightly. modem·
If the hardware 30 does not change, the same modem module 114 can be used with little change.
Conversely, changing the modem hardware, such as DSP 58, allows the new DSP to be accessed using a different code for the "virtual" microcontroller in modem module 114.

With this modular software approach, porting to new operating systems is rather simple. Standard modem or UART software for the new operating system can be used. The software is readily available and includes a virtual modem
Simply port the controller to the new operating system and, if necessary, another CPU with a "virtual UART" interface to the virtual device driver
It is also possible to recompile into system 10.

UART Basics On an IBM PC compatible computer, the UART has a series of standard ports at input / output addresses starting from the reference port. To access these I / O addresses, I / O instructions in the x86 instruction set are generally used. That is, the instruction used to input from one of these ports is "IN AL, DX", and the data located at the I / O address specified by the DX register is input to the AL register. Similarly, to output the data in the AL register to the port specified by the DX register, an “OUT DX, AL” instruction is executed.

The standard U used in IBMPC
The ART is 8250, or one of the compatible generic products is 16450 or 16550. The U
The standard ports in ART are as follows.

[0062]

Table 1 Register Offset DLAB Receive Buffer Register (DAT) 00h 0 Transmission 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) (LSR) 05h- Modem Status Register (MSR) 06h- Scratch Pad Register (SCR) 07h- data written to the divisor latch registers (located in the LCR) lower bits (DLL) 00h 1 divisor latch registers upper bits (DLH) 01h 1 DLAB = divisor latch access bit these registers or Data is read from these, with known standard meaning in the art. For example, performing a write to the transmit holding register DAT places a data byte in the transmit holding register for later transmission over a serial line. As another example, the line status register LSR includes a transmission holding register empty bit THRE, a transmission shift register empty bit TSRE, and an interruption detection bit B
RKI, framing error bit FRMR, parity error bit PARE, overrun error bit ORRE, and received data available bit R
It has data bits such as DRI.

Standard device drivers, similar to the CPQFMW31.386 126 module and the CPQFMW95.VXD112, typically use I / O instructions to directly access these hardware registers at these I / O ports. According to the present invention, virtually one change to these virtual device drivers is made for each "INA"
Replace the "L, DX" and "OUT DX, AL" instructions with the corresponding macro instructions "INALDX" and "OUTDXAL." These macros, when compiled, simulate register access to the 16450 UART. Make a call to the paste logic, which is described in SIM 450.
It is in the C routine and will be described in more detail below in connection with FIGS. The paste logic receives the same parameters of a standard I / O command to a standard physical UART and returns the same corresponding data. Therefore,
Normally, standard device drivers that access the hardware UART can be used, but will instead be through the SIM 450.C virtual UART interface of the modem module 114.

Before proceeding to the operation of the virtual UART interface, the virtual device software module 11
2, 126, and some other minor modifications to the modem module 114. First, if the modem module 114 had previously been implemented in its own dedicated microcontroller 40 as shown in FIG. it can.
Here, since the modem module 114 is implemented to be executed by a CPU system having other tasks, the modem module 114 will instead relinquish control after performing its necessary functions. There must be. There is little need for this, and rather than the modem module 114 going into a holding loop,
It only ensures that you return to the operating system.

Since the modem module 114 must periodically return to the operating system,
Operating system to perform its desired function
The system must also call the modem module 114 periodically. This is usually done by timer software, inside the operating system itself. That is, the modem module 114 is periodically
Call to perform the desired function, a standard timer device is required. There are two ways to achieve this. First, the modem module 114 is called periodically by a timer. Second
Since the DSP 58 periodically requests service from the modem module 114, the DSP 58
An interrupt is provided to the D.386 116 module, which causes both the modem module 114 and the virtual device module 112 or 126 to execute.

Changing the Standard UART Virtual Device Turning now to FIGS. 9 and 10, these figures show that when accessing the modem module 114, the CPQFMW9
5. Shows an example of a flow chart of a standard routine executed inside the VXD112 module. PP
An ORTOPEN routine 300 is provided for illustration. This routine 300 usually has a VCOMM.3
86 108 modules and CPQFMDB.VXD110
Called by other routines within the operating system software, such as modules.
Of course, there are many other routines within the CPQFMW95.VXD112 module that are called by other routines in the operating system. These various modules access the UART to send and receive data to and from the serial device and control the UART. However, this example routine 300 illustrates how a physical call can be easily exchanged for a virtual call.

Starting from step 302, the routine 30
0 determines whether the port exists but is not yet open. If not, control transfers to step 304 and the routine returns because the port does not exist or the port is not yet open. Otherwise, control proceeds from step 302 to step 306.
And establish a data structure for this port.
Next, the processing shifts to step 308, where the offset 03h is added to the port reference address of the serial port to be opened.
Is loaded into the EDX register. This offset is the standard 8259, 16450, 1655
Corresponds to the offset of the line control register LCR port with respect to 0UART. Thus, the EDX register will now have the appropriate port address for input from the LCR port.

The process proceeds to step 310, where "INALD
X "routine 350. As discussed below in connection with FIG. 11, this routine is actually a virtual UAR.
Preferably, it is a macro that forms the extended inline code that calls the appropriate paste logic in the T interface. On the other hand, the virtual UART interface calls the modem module 114. In step 310, the "INALDX" macro uses the x86 processor's "IN AL, DX" instruction to create a physical UAR.
Performs exactly the same function as when reading from the T line control register LCR. More specifically, the AL register now contains the data input from the "virtual" line control register LCR. Control goes to step 312 to set the high-order bit of the AL register. this is,
Corresponds to divisor latch access bit DLAB of line control register LCR. Next, proceed to step 314,
Execute the corresponding "OUTDXAL" macro, and set the D in the line control register LCR of the "virtual" UART according to the invention
Set LAB. Control then proceeds to step 316, where 00h is added to the reference port address,
Load DX register. This corresponds to the divisor latch lower bit register DLL. In step 318, execute the INALDX macro to read from the virtual UART into the divisor latch low byte DLL. Step 32
At 0, the AL register is saved and the reference port address plus 01h is loaded into the EDX register. This corresponds to the divisor latch upper byte DLH.
In step 322, the byte is read using the INALDX macro. Next, proceeding to step 324, combining the lower and upper bytes of the divisor latch,
Store. In step 326, the original line control register LCR input value is loaded into AL. Next, the process proceeds to step 328, where the OUTDXAL macro is executed to restore the line control register LCR to its original value. That is,
Disable DLAB if it was originally disabled. Next, the process proceeds to step 330 to execute other settings.

The point of this series of instructions is that the virtual UART located within the modem module 114 is also accessed as if it were a real UART. The above sequence was performed to set the divisor latch to the appropriate value, and indeed set the baud rate. Virtual ARTs have virtually no "baud rate" because data is transferred virtually instantaneously between the modem module 114 and any device driver that has called this software through the virtual UART. Must be considered. But standard UA
Since the RT device driver sets the baud rate and keeps in mind that it is accessible, the virtual UART
Gives access to the virtual divide latch byte without actually doing anything. Thus, it is easy to modify an existing hardware UART device driver to be usable with the virtual UART of the modem module 114.

To complete the routine, control then transfers to step 332 where, if an error is detected, control transfers to step 334 and the routine returns. If there were no errors, control returns to 332 instead.
Then, the process goes to step 336 to input the port reference address plus an appropriate offset for the modem control MCR. Next, the OUTZ bit of the data is enabled, and in step 338, the data is output using the OUTDXAL macro. Control then transfers to step 340 where a call is made to unmask the interrupt request line IRQ. As discussed below, virtual UARTs are also suitable operating system interrupt services.
Generate a "virtual" interrupt to the routine. Step 3
Moving from 40, control then returns at step 342.

Turning to FIG. 11, two macro routines INALDX 350 and OUTDXAL 360 are shown. The INALDX routine 350 replaces the standard INAL, DX instructions on the X86 series of microprocessors. On the other hand, OUTDXAL routine 36
9 correspondingly replaces the OUT DX, AL instruction. These are not callable routines, but instead are macros, which are assembled inline in the CPQFMW95.VXD112 module, the CPQFMDB.VXD110 module, and the corresponding routine in FIG. The INALDX routine 350 and OUTDXAL routine 360 actually exchange calls to the paste logic with standard I / O instructions.

The INALDX routine 350 is a step 3
Starting from 52, all the changed registers are saved. Proceeding to step 354, the paste routine V
Make a virtual device driver call to IPD1_REG_READ. This routine is discussed further below in connection with FIG. 12, but stripping the physical address of the DX register, leaving the offset, and then calling the virtual UART routine. This routine is discussed below in connection with FIGS.

The flow shifts to step 356 to restore the register, and stores the result of the call in step 354 in the AL register. Next, at step 358, the inline macro is executed so that other code continues to execute.

The OUTDXAL routine 360 operates in a similar manner, starting at step 362, where the registers are stored. Next, control transfers to step 364 where the paste logic routine (see FIG. 12), ie, VIP
Call D1_REG_WRITE. Next, control passes to step 366 to restore the registers and the routine is completed at step 368.

INALDX Routine 350 and OUT
By simply replacing the DXAL routine 360 with the appropriate I / O operations, the various device drivers are virtually unchanged.
It will be appreciated that it works normally with hardware UARTs.

Turning to FIG. 12, VIPD1_REG_R
EAD routine 370 and VIPD1_REG_WR
The ITE routine 380 is shown. These routines are called in steps 354 and 364 of FIG.
Paste logic to bridge between T and the rest of the operating system. VIPD1_
The REF_READ routine 370 begins at step 372, where it performs a binary AND operation on the address in the DX register with 07h, strips off the physical address, and leaves an offset at the appropriate port of a standard UART.

The flow shifts to step 374, where VIPD1_R
The EG_READ routine 370 is a routine SIM45
Call 0_READ400. Virtual UART IM
450_READ routine 400 is 16450 UAR
Simulate the lead from the port of T. This routine 400 performs a "read" from the appropriate "port" of the virtual UART. Proceed to step 376 to
The PD1_REG_READ routine 370 returns to the macro inline code of the INALDX routine 350 (FIG. 11) that called it.

The VIPD1_REG_WRITE routine 380 operates similarly. Starting at step 382,
The address is stripped from the DX register by a binary AND operation with 07h. Next, the process proceeds to step 384,
Call the SIM450_WRITE routine 500,
The “write” to the “port” of the virtual UART is executed.
Next, the flow shifts to step 386, where VIPD1_REG_
WRITE routine 380 returns the OUT that called it.
DXAL routine 360 inline code (FIG. 1)
Return to 1).

VIPD1_REG_READ Routine 3
70 and VIPD1_REG_WRITE routine 3
80 is shown in the source code of Appendix C.
The INALDX routine 350 and the OUTDXAL routine 360 are shown, for example, as macros in the source code of Appendix A. All of these flowcharts are exemplary, and further details can be found in the source code of the appendix.

Read and write rules for virtual UART
Turning to Chin FIGS. 14 and 15, SIM450_READ
The routine 400 is shown. This is VIPD1_
Called in step 374 of REG_READ routine 370 (step 12). SIM_450READ
Before moving on to the details of the routine 400, some notational conventions will be described. Data used only in the SIM450_READ routine 400 is typically stored in one structure. This is the same as the source code list attached as Appendix C, SIM450. H and SIM450. Located in the H module,
It can be found in the source code of the routine. The main data structure is the SIM450_DATA structure, in which the traditional C program notation is used
Store variables in a structure. For example, the contents of the "virtual" scratchpad register is SIM450_DA
It is in the TA / SCRATECH variable. Since the short notation is used instead of the list "SIM450_DATA" as a preface to each reference to this data structure, SIM450_DATA. SCRATC
The H variable is simply a .SCRATCH variable.

Further, for clarity, SIM450_R
Certain details have been omitted from the flowchart of the EAD routine 400. Specifically, SIM450_RE
The AD routine 400 communicates with the modem module 114 through a series of calls implemented within the modem module 114 itself. Modem module 114 includes a number of "hooks", which allow it to communicate with different types of software interfaces in various ways. Thus, referring again to FIG. 2, the modem module 114 can be implemented within the microcontroller 40 to communicate with the UART 46 or, alternatively, communicate with various other types of devices through its paste routine. Communication can be performed.
"Hooks" to the modem module 114 include a number of software calls that call for both setting various control parameters and sending and receiving data. Typically, data is sent to and received from a data array maintained by the SIM450.C module itself. Instead of discussing each of these routines in detail, some of these routines will be discussed schematically,
We will describe how they interface with the SIM450.C module.

As will be appreciated by those familiar with modem technology, modem module 114 typically includes code for communicating data to and from the SIM450 code over telephone lines, but , Standard Ha
Also includes control software that implements the "AT" command set. That is, when the modem module 114 is in the transmit / receive mode, the actual data is transmitted and received over the telephone line. This mode is typically terminated by the user entering three consecutive "++" symbols, a standard "AT" escape sequence.
This causes the modem module 114 to enter the control mode. In that mode, the modem module 114
Responds to "AT" commands from the computer itself, but does not communicate data over the telecommunications link.

One type of communication mode implemented by the modem module 114 is a flow control mode, in which data transmission to the modem module 114 is initiated and initiated using any software code. Terminate or use hardware flow control model. In the latter case, the transmission erase bit (cl
ear to send bit) CTS and send ready bit (r
eady to send bit) Indicates whether data can be sent or received using RTS. This code is SIM45
0. C is not shown in the flowchart, but is in SIM450.C attached in Appendix C. It will be easy to understand how to incorporate this code.

SIM450_READ Routine 400
Is executed as a series of case statements. The first case starts at step 402 where control transfers when the value called corresponds to an offset in the scratchpad register SCR. Standard UART
Now, this corresponds to a port offset of 07h.
in that case,. Load the contents of the SCRATCH variable into temporary variable B. Next, control proceeds to step 404, where the routine returns with the contents of the B variable as a parameter.

To better understand the operation of the simulated UART, consider briefly FIGS. 9-14 in connection with reading a scratchpad register. While the DX register contains the reference address of the desired port plus an offset of 07h corresponding to the scratch pad register SCR, INALD
Assume that X routine 350 is to be executed. Then, IN
The ALDX routine 350 determines in step 354 that V
Calls the IPD1_REG_READ routine 370, which strips off all but the 07h offset, and in step 374 the SIM 450
Call the _READ routine 400. Next, in step 402, the .SCLATCH variable is loaded into the variable, and the process returns in step 404. Next, in step 356 of the INALDX routine 350, this data is stored in the AL register. In this way, a "read" has been performed from the "virtual" scratchpad register SCR.

The rest of the standard registers can be read in a similar manner. The SIM450_READ routine 400 moves to step 406 if the offset corresponds to the modem status register MSR.
In this case, in step 406, the contents of the modem status register .MSR are loaded into the B variable. This variable contains the contents of the virtual UART's MSR register. Proceeding to step 408, the delta bit of the .MSR variable is cleared. These bits are. MSR
The lower 4 bits of the variable, since the last reading of the .MSR variable, the data carrier detect bit (DCD), ring indicator bit (RI), data set ready bit (DSR), or clear transmission (CT
S) Bits (all of which are in the upper four bits of the .MSR variable) correspond to the bits used in a standard UART to detect if they have changed. It should be understood that this simulates the functionality of a standard UART.

In step 410, the LOOP bit of the modem control register variable .MSR is checked. If this bit is true, the virtual UART is 16450 UAR
Loop back, the standard mode of operation for T
In mode. If not, control transfers to step 404 and the SIMU450_READ routine 400 returns with the contents of the .MSR variable. In step 410. If the LOOP bit of the MCR variable is true, control instead passes to step 412, where the lower 4 bits of the .MSR variable included in the B variable and the lower 4 bits of the left shifted .MCR variable.
Store the bit in B. If the LOOP bit of the .MCR variable is set, this is returned in step 404 since this is the appropriate value to return for reading the modem status register MSR in the standard UART.

When reading from the line status register LSR is performed, the control shifts from step 400 to step 414. At step 414, the contents of the line status register variable .LSR are loaded into the B variable, and then the control is performed. Moves to step 416, where 01
Loaded the contents of the .LSR variable into the .LSR variable, masked the appropriate bits,
Clear error, overrun, and frame error bits. Next, control proceeds to step 418, where EVALUATE_INT
The ERROR routine 600 is called (FIGS. 18 and 19), and the routine 400 then returns at step 400.

The EVALUATE_INTERRUPT routine 418 evaluates whether a virtual “interrupt” should be performed. The virtual interrupt is shown in FIG. 5 and FIG.
Invoked by a call to one of the interrupt service routines located in the various device drivers.
Of course, there is also a standard interrupt service routine for use by a true hardware interrupt from the UART, which service is therefore "virtual"
Called when an interrupt is required. EVALUAT
The E_INTERRUPT routine 600 is called at the appropriate time when it is necessary to trigger such a virtual interrupt. For example, a standard UART line status
When reading the register LSR, if additional data is available and the interrupt is enabled, an interrupt is executed to indicate that the additional data is actually available. This is the case where at least the interrupt is evaluated and it is determined whether the interrupt should be executed. EVALUATE_INTERRUPT
Routine 600 makes this evaluation.

To read the modem control register MCR, control transfers from step 400 to step 420. At step 420, the contents of the modem control variable MCR are loaded into the B variable, and control returns at step 404.
Similarly, when reading the line control register LCR, control transfers from step 400 to step 422. Step 4
At 22, the contents of the line control variable / LCR are loaded into the B variable. Control then returns the contents of B in step 404.

When reading the interrupt identification register IIR,
Step 420 is entered from step 420. Step 4
At 24, the contents of the interrupt identification variable .IIR are loaded into the B variable. Next, control proceeds to step 426, where B
The variable (which now contains the contents of the .IIR variable) is compared to the constant ITHR. This constant indicates the pending interrupt (pe
nding interrupt). If they are equal, reading from the interrupt identification register IIR clears this type of interrupt and must be cleared. To do this, load the interrupt transmission empty interrupt variable .IIR_TX with 0. This gives E
This interrupt is cleared in the VALUE_INTERRUPT routine 600. This routine 600
Is called in step 428. Control then returns at step 404.

When reading the interrupt enable register IEN, step 400 is entered from step 400. In step 430, first, the line control register L
By examining the divide latch access bit variable .CLAB, which represents the contents of the DLAB bit in CR,
It is determined whether the division latch access bit DLAB is set. If not, control transfers to step 432 where the interrupt enable variable .I
Load the contents of EN into B variable. This is done because if the divide latch access bit DLAB is not set, a read from the IEN register will return the register's normal interrupt enable value. Next, control transfers to step 404, where the value is returned.

In step 430, if DLAB is set, control transfers to step 434, where the contents of the divide latch high variable .DLH are loaded into the B variable. This variable is used to determine the baud rate, and in the disclosed embodiment, by maintaining it strictly,
The virtual UART makes the operating system appear to be a standard hardware UART. Again, this is because the "baud rate" of the virtual UART may actually be how fast the processor can operate. That is, the virtual UART does not artificially reduce the baud rate of a normal UART (if at all possible). Next, control transfers to step 404,
Here, the high byte of the division latch is returned.

Referring to FIG. 14, the last option entered from step 400 is read from the DAT port. This indicates that data is read from the reception buffer or the divisor latch of the virtual UART according to the setting of DLAB. This processing is performed in step 436 and the DLA
It is determined whether B is set. If so, control transfers to step 438 where the divisor latch low variable .DLL is loaded into the B variable. This is an appropriate operation because the divisor latch access bit is true. Next, control transfers to step 440 where the SIM 45
The 0_READ routine 400 returns with the value loaded into the B variable.

From step 436, if DLAB is not set, control transfers to step 442 instead. This step is performed if the received data is available.
This is the start of a sequence for reading the received data from the virtual UART implemented by the IM450.C code.
In step 442, the received data ready bit RDR in the line status register variable .LSR
Clear I. This is because data is read from the reception buffer in the following steps. If no more received data is available, then set the RDRI register, but this read will first
Clear the bit. Proceed to step 444, where EVA
The LUATE_INTERRUPT routine 600 is called to determine whether to cause an interrupt to the operating system. For example, if data is still available, an interrupt occurs.

The flow shifts to step 446, where it is determined whether the amount of data in the transmission buffer from the modem module 114 is larger than zero. If it is greater than zero, it indicates that there is data to read from the modem module 114; otherwise, there is no data available from the modem module 114. Modem transmit buffer
If the count variable .TX_CNT is greater than zero, control transfers to step 448 where data from the modem's transmit array is loaded into the B variable. The transmit array contains the data transmitted from the modem module 114.
In addition, the .TX_CNT variable is decremented to indicate that data from modem module 114 has been read from the transmitter.

From step 446, the transmission count variable.
If TX_CNT is greater than 0, indicating that no data is available from the modem module 114, control passes to step 450 where the NULL character, ie, 0, is loaded into the B variable. Control then transfers to step 452 from both steps 448 and 450.

In step 452, .TX_CNT
If the variable is not equal to 0, the modem module 114
, Indicating that more data is available, control transfers to step 454 where the line status register variable. Set the receive data ready indicator bit RDRI in the LSR, EVALUATE_I
The call to the NERRUPT routine 600 evaluates the interrupt. If the .TX_CNT variable is equal to 0, control transfers from step 452, and in any case from step 454, to step 440.

FIGS. 15 to 17 show SIM450_WR
A flowchart of the ITE routine 500 is shown. The source code for this routine is also in the SIM450.C source code listing in Appendix C. Again, for clarity, some of the details regarding flow control have been omitted. However, usually, the virtual device driver has a corresponding hardware UAR
Whenever performing an output to a hardware port on T, call the SIM450_WRITE routine 500 instead.

This routine 500 is also shown in the form of a case statement. If the selected port offset corresponds to the scratchpad register SCR, control passes to step 502, where. SCRATCH
Set the variable equal to the VALUE variable and select OU in FIG.
As shown in TDXAL macro 360, parameter
Transfer to L register. Control transfers from step 502 to step 506, where the SIM450_WRITE routine 500 returns to its calling routine. The calling routine here is VIPD1_REG_
Shown as WRITE routine 380.

When writing to the modem control register MCR is performed, control proceeds from step 500 to step 506, where the modem control register variable .M
Set CR equal to the VALUE parameter. Next, control transfers to step 508 to update the flow control. This is necessary because the modem control register variables MCR are OUT2 *, IYT1 *, RST *, DTR
Because it includes a number of bits, such as *, and other modem controls that can affect flow control.

The process proceeds to step 510 where the SIM 450
_WRITE routine 500 is an EVALUATE_I
Call NTERRUPT routine 600. This is done because a change in the value of the .MCR variable may require the initiation of an interrupt to the operating system driver code. Next, control returns in step 506.

The I / O write is performed by the line control register LCR
If so, control proceeds to step 50
Move from 0 to step 512. In step 512,. Load the VALUE parameter into the LCR variable,
Next, control transfers to step 514 to update any parity processing tables. This is because the three bits inside the .LCR variable are intended for parity settings of no parity, radix parity, even parity, mark parity, or space parity.

From step 514, control is passed to step 51.
Then, the process goes to 6 to determine whether the DLAB bit in the VALUE variable is set. If true, step 518 sets the .DLAB variable equal to one. If false, control transfers to step 520,
here,. Set the DLAB variable to 0. Therefore, the .DLAB variable is. Reflects the current value of the DLAB bit in the LCR variable. From step 520, control transfers to step 522 where the .MCR variable LOOP
Determine if the bit is set. If so, control is passed to step 524 because the loop back mode is set, and if the SBRK bit in VALUE is true, the BRKI bit in the .LSR register is set to true. If not set, the BRKI bit in the .LSR register remains unchanged. That is, when the virtual UART is in the loop back mode, the interrupt input bit of the virtual UART is set to correspond to the interrupt output bit of the virtual UART.

From steps 518, 522, 524, control then transfers to step 526, where EVALUATE_
The INTERRUPT routine 600 is called to determine whether the operating system should perform a UART interrupt.

FIG. 16 shows another state. Writing is U
If it corresponds to a write to the ART interrupt enable register IEN, control transfers from step 500 to step 528, where. Determine if the DLAB variable is set to true. If so, control transfers to 530 where the divisor latch high byte variable .DLH is set equal to the VALUE parameter. This is done because when setting the DLAB bit, the divisor latch is accessed by reading and writing to the IEN and DAT registers. Next, control proceeds to step 530.
From step 532, where control returns to the calling routine.

If the .DLB variable is not true, control transfers from step 528 to step 534 where the empty transmit hold bit ETHR of the interrupt enable register .IEN is
To inspect. If this bit is true, it indicates that an interrupt will occur when the transmit holding register (ie, DAT) is empty. If this bit is not set,
Control transfers to step 536 where the ETHR bit of the VALUE parameter is checked, and if true, control transfers to step 538. In step 538, the transmission holding register empty bit in the line status register variable .LSR is checked. When set, it indicates that an interrupt based on the empty transmission holding register has just been turned on, and that the transmission holding register is actually empty, so that a transmission interrupt occurs. Then, the control proceeds from step 538 to step 540, where the interrupt interruption interrupt identification register transmission variable .IRR_TX is set to 1, that is, true.

From steps 534 through 538 and step 540, for all other states, control transfers to step 542, where the interrupt identification register variable.
Set IEN equal to the VALUE parameter. Next, control proceeds to step 544, where EVALUATE
Call the _INTERRUPT routine 600. If step 540 is reached, indicating that the transmit holding register is empty and that an interrupt based on an empty transmit holding register has been turned on, an interrupt will occur;
EVALUTATE_INTERRUPT routine 60
At 0, an interrupt is generated to the operating system software. From steps 530, 544, control transfers to step 532, where a return is performed.

If the UART register to be written is the outgoing data register DAT, control proceeds to step 500
To 546, where the divisor latch access bit variable .DLAB is examined. If true, the divisor latch low bit variable .DLL is loaded with the VALUE parameter in step 548, and then control returns in step 532.

At step 546, if the .DLAB variable has not been set, control passes to step 530, where the LOOP bit of the modem control register variable .MCR is examined. If this is set, the loop
In the back mode, control is passed to step 55.
2 where the input of bytes to the modem module transmit buffer routine PUT_TX_BYTE7
Execute 00. This will be further described below with reference to FIG. It will be appreciated that the PUT_TX_BYTE routine 700 corresponds to entering a byte in the transmit buffer and moving from the modem module 114 to the virtual UART. Thus, entering a byte into the transmit buffer would actually be received by the virtual UART. This is appropriate in step 552 since the data to be written is actually read by the UART in loop back mode. Control transfers from step 552 to step 532 and returns to the calling routine.

If not in loop back mode, control transfers from step 550 to step 544 to reset the transmit hold register empty bit THRE and the transmit shift register empty bit TSRE in the line status register variable .LSR. . This is because the bytes of data to be written to these registers are being prepared. Next, control transfers to step 556,
Call the EVALUATE_INTERRUT routine 600. From step 556, control proceeds to step 55.
8 (FIG. 17), and the modem module receive buffer counter. It is determined whether RX_CNT is smaller than the maximum value. If so, the receive buffer of the modem module 114 indicates that there is still room to receive another byte from the virtual UART. This byte is OUTD
As output by the XAL macro, the routine has reached step 558 as a result. Accordingly, control proceeds to step 560 where the VALUE parameter is stored in the receive array RX_ARRAY of the modem module 114 after performing the appropriate parity conversion based on the current parity setting of the virtual UART.

Next, the control shifts to step 562, and.
Increment the RX_CNT variable to reflect the addition of data to the receive array. From step 518, if the .RX_CNT variable exceeds the maximum buffer size, or in any case from step 562, control transfers to step 564 to determine whether the .RX_CNT variable is less than the flow off condition. Is determined. If false, it means that the operating system virtual device must stop sending more data until the modem module 114 processes the data.
Referring to step 554 above, here the transmit hold register empty bit THRE and the transmit shift register empty bit TSRE were reset in step 554 in the line status register variable .LSR. Therefore, virtual device drivers in the operating system must not write to the UART until these bits are set. Because these are the LSRs through the SIM450_READ routine 40
When reading the variable, these bits indicate that the transmit buffer is full. Thus, if the receive array of modem module 114 is full, these bits are left unchanged and control transfers from step 564 to step 568, where a return is performed.

If not, control transfers from step 564 to step 566, taking the appropriate action to transfer additional data through the virtual UART to the modem module 11.
4 can be written. First, the interrupt identification register transmit variable .IIR_TX is set to true to indicate that an interrupt will occur and, if necessary, to indicate that the transmit buffer has extra space for data. Line status register variable. Set the transmit hold register empty bit THRE and the transmit status register empty bit TSRE of the LSR to true to indicate that these registers are empty and ready to accept data from the operating system. Show. Next, EVALUATE
Calls the _INTERRUPT routine 600 so that an appropriate interrupt can be raised to the operating system. From step 566, control transfers to step 568, where control returns to the calling routine.

Virtual Interrupt Turning to FIGS. 18 and 19, SIM450_EVAL
UART_INTERRUPT routine 600, ie,
A simplified representation of the EVALUATE_INTERRUPT routine 600 is shown. Calling this routine 600 is when the virtual UART must determine whether to generate a soft interrupt to the operating system virtual device. As described above, the operating system is a UART
Has an interrupt entry point, which is called when a hardware interrupt occurs. This interrupt entry point is typically the entry point for an interrupt from an IRQ3 or IRQ4 interrupt request line. These early housekeeping (hous
As part of ekeeping, the virtual device driver must set an entry point for such interrupts. The SIM450.C module contains an entry point called at the address to be moved on interruption from the UART. This is because when the virtual UART is appropriate to execute an interrupt, the SIM450_EV
This entry point is set as a routine called by the ALUATE_INTERRUPT routine 600.

SIM450_EVALATE_INT
Before moving on to the specific code of the ERRUPT routine 600, as a general overview, the routine 600 includes a virtual UA
A check is made to determine if the various settings of the data variables inside the RT indicate that they are appropriate in generating a call to the interrupt service routine in the virtual device driver of the operating system. Such a condition is that, for example, the transmission holding register becomes empty, and the corresponding interrupt is set to the interrupt enable register variable .IE.
N enabled. Of course, there are other conditions for generating an interrupt.

Starting from step 602, the transmission holding register bit THRE of the current line register variable .LSR
With the previous store line status register variable .OLD_LSR transmit hold register empty bit TH
Check the RE. If THRE is set in the .LSR variable but cleared in the .OLD_LSR variable, then SIM450_EVALUATE_I
This means that the transmit holding register has been emptied since the last call to the NTERRUPT routine 600. In this case, control is performed from step 602 to step 60.
4 and sets the transmission empty interrupt variable .IIR_TX to 1 to indicate that an interrupt condition exists. Otherwise in step 604, and step 602
, Control passes to step 606 where the old line status register variable .OLD_
LSR contains the current line status register variable.LS
Load the value of R.

Proceeding to step 608, the various states of the interrupt enable register variable .IEN are examined.
In step 608, the interrupt enable variable .I
The error of the status register ERLS bit in EN is set to the line status register variable. LSR break bit BRKI, frame error bit FRM
Check with R, parity error bit PARE, and overrun error bit OVRE. ER
The LS bit, if true, indicates that an interrupt should be initiated by any of these error conditions in the line status register variable .LSR. Therefore,
If this condition is true, control transfers from step 608 to step 610, where the interrupt identification register variable .IIR
Is set to the value corresponding to the interrupt base on the line status register (this value is 06h).

In the case of a false state, control transfers from step 608 to step 612, where the transmission empty interrupt variable .IR_ together with the interrupt transmission holding register interrupt bit ETHR of the interrupt enable register variable.
Check TX. If both are true, the interrupt due to the transmit holding register being empty is enabled and the transmit holding register is actually empty, as shown in step 604 above, or at step 540 in FIG. 13B. As shown, this interrupt has just been enabled. In either case, an interrupt is executed to notify the operating system that the transmit holding register is empty. Therefore, in step 614, the interrupt identification register variable .IIR
Is set to a value corresponding to the interrupt (the value of 02h).

Otherwise, control transfers from step 612 to step 616, where the received data ready interrupt bit R of the line status register variable .LSR is
DRI to interrupt enable register variable .IEN
Enable data available interrupt bit ERD
Inspect with A. If both are true, indicating that data is available from the modem module 114, and because such data is set to be interrupted when such data is obtained, control passes to step 618 where the interrupt identification register is set. The variable .IIR is set again to an appropriate value (here, 04h).

Otherwise, control transfers from step 616 to step 620, in which the enable modem status register interrupt bit EMSR of the interrupt enable register variable .IEN is set to the delta value in the modem status register variable .MSR. Check with bits. The delta bit, when true, indicates that the corresponding upper bit of the modem status register variable .MSR has changed since the last time the .MSR variable was read. If one of these bits has changed and the corresponding interrupt is enabled, control proceeds to step 6.
22 and the interrupt identification register variable .IIR is
Set to the value (0h) corresponding to the interrupt based on the modem status register.

Otherwise, control transfers from step 620 to step 624, where the interrupt identification register variable.
Set IIR to a no-interrupt value, which is a value of 01h. Further, an interrupt active variable. INT_ACTI
VE is set to false, indicating that no interrupt is currently occurring.

Steps 610, 614, 618, 622
In the interrupt identification register variable.
A bit is set to its active low state to indicate that an interrupt is pending, according to a standard UART. Therefore, from these steps, the interrupt is set pending and the interrupt identification register variable .I
The IR contains an identification of this type of interrupt. From steps 610, 614, 618, and 624, control proceeds to step 626 (FIG. 19).

In step 626, the .IIR variable is compared with the no-interrupt value INOI, the interrupt active variable .INT_ACTIVE is checked, and the OUT2 bit of the modem control register variable .MCR is checked. INT_ACT if .IIR variable is not equal to no interrupt condition
The IVE variable becomes false, indicating that no interrupt is currently being processed. In addition, control is transferred to step 628 by enabling output OUT2, thereby indicating that an interrupt should be generated, and the interrupt active variable .I
NT_ACTIVE is set to 1 to indicate that an interrupt is currently occurring, and then at step 630,
Determine if the entry was set due to an interrupt (which would have been generated by proper initialization of the SIM_450 code). From step 630, if an entry has been set for the interrupt, step 632
Call the interrupt entry at. Otherwise, from steps 626 and 630, and always from step 632, control transfers to step 634,
A return to the calling code is performed.

Interrupt active variable .INT_ACT
With respect to IVE, its operation may be understood by referring to FIGS. If the interrupt is active, the .INT_ACTIVE variable is
Do not reset to false until there are no pending interrupts in checks 08, 612, 616, 629. This prevents many spurious interrupts.

Modem Module The previous routines illustrate the interface of the virtual UART as a form for various virtual device drivers in the system software. The virtual UART also has an interface to the modem module 114. As noted above, the appropriate code for modem module 114 is typically R. Scott
Provided by numerous modem software developers such as & Associates. These sources typically do not specify a controller, but instead write controller code written in a high-level language, so that they can be compiled and run on a variety of platforms. For example, the illustrated controller code may be high-level code compiled for execution on a 68302 microcontroller, but here instead be used by the present invention to execute on an X86 series processor. Compiled.

This controller code has various "hooks" through which external data is transmitted and received from the computer. The main example, SIM450_PU
T_TX_BYTE Routine 700 and SIM_45
The 0_GET_RX_BYTE routine 750 is shown in FIG.
Is shown in

Starting from 702, SIM450_PUT
The _TX_BYTE routine 700 includes a transmit array TX_
Input 1 byte to ARRAY. Again, the transmit array is from the modem module 114 to the virtual UART. Proceeding to step 704, a timer is started and if the modem module 114 is not called for a certain time (about 10 milliseconds), an interrupt to the modem module 114 is generated after this time. This delay allows the modem module 114 to transfer another byte to the virtual UART. Start timer and UAR
If there is no application that drains to T, "expire out" the character. In the actual UART, characters are overwritten and OVERRURU
N errors occur.

In the SIM450_GET_RX_BYTE routine 750, the modem module 114 reads a byte from its receive buffer. Receive buffer is S
Fulfilled by IM450 routine. Beginning at step 752, a temporary variable B is stored in the receive buffer RX.
Load the next byte in ARRAY. Step 7
Moving to 54, the receive buffer count RX_CNT is decremented to indicate that one byte is less available in this array. Proceeding to step 756, it is determined whether the receive buffer count RX_CNT is less than the flow-on threshold RX_FLOW_ON. If it is small, there is enough space in the buffer and the virtual U
Since extra characters can be accepted from the ART, control transfers to step 758 where the transmit hold register empty bit THR in the line status register variable .LSR is
Check E. If this is true, control proceeds to step 7
Moving to step 60, the transmission empty interrupt variable .IIR_TX is set to 1, that is, true, and an interrupt is given to indicate to the virtual device driver that the virtual UART transmission holding register is empty. Also, the transmission status register empty bit TSRE and the transmission holding register bit THR of the line status register variable .LSR
Set E to true to indicate that these registers are empty and available to accept data from the operating system virtual device driver. Finally, the EVALUATE_INTERRUT routine 60
Call 0 to determine whether to interrupt the virtual device driver of the operating system. From steps 756, 758, and 760, control proceeds to step 7
62, and the EVALUATE_INTERRUPT
Call the routine 600 again. Finally, step 7
A transition is made to 64 and the routine returns to the modem module 114 with the value in the temporary B variable as a parameter.

Conclusion From the above description, how a virtual UART is provided as an addition to the modem module 114, the modem module 114 can communicate data with this virtual UART, and the virtual UART is It will be appreciated that the system software will effectively make it appear as a physical UART. Usually, the only major change that needs to be made to a virtual device driver that accesses the physical UART is to convert the device driver's I / O instructions into appropriate macros that resend these I / O instructions as calls to the virtual UART code. It just replaces it.

This software partition provides a very clear path to the new operating system and different modem modules. modem·
To move this modem controller to a new operating system due to the virtual UART interface that precedes module 114, change the operating system's virtual device driver to call instead of I / O instructions. What should be done is to execute. Since the virtual UART is effectively viewed as a physical UART, no other data structure or parameter changes are required.

Similarly, when changing the modem module itself, only the interface with the virtual UART needs to be changed. Since the virtual UART interface maintains a standardized state, there is no need to change existing virtual device drivers.

Computer System C and DSP 5
The physical link between the eight can be implemented in various ways, such as multiple input / output ports. The modem module 114 also includes hooks for proper communication with the DSP, which make it easy for the DSP to connect itself to the modem module 114 to any type of hardware interface. Changes are possible. Preferably, this is a PCMCIA with a standard interface through multiple mailbox registers.
Card form. The modem module code for the implementation of this interface is shown in source code Appendix A, but again this is not critical and a wide variety of interfaces are possible.

The foregoing disclosure and description of the invention has been presented for purposes of illustration and description, and is not limited to size, shape, material, construction, circuit elements, wire connections, and contacts, as well as the illustrated circuits and structures, and Various changes may be made in the details of the method of operation without departing from the scope and spirit of the invention.

[Brief description of the drawings]

FIG. 1 is a simplified block diagram of a computer system having an optional modem card according to the present invention.

FIG. 2 is a block diagram showing conventional modem hardware in a PCMCIA card.

FIG. 3 is a block diagram of the modem hardware in a disclosed embodiment of the invention, showing the hardware portion removed.

FIG. 4 is a detailed block diagram of a modem card according to the present invention.

FIG. 5 is a block diagram illustrating various software components in a Windows® 95 environment for use with a modem implemented in accordance with the present invention.

FIG. 6 is a block diagram illustrating various software components in a Windows 3.1 environment for use with a modem implemented in accordance with the present invention.

FIG. 7 shows CPQFMW95. FIG. 3 is a block diagram illustrating the VXD and modem module interface in more detail.

FIG. 8 shows a C to determine if a modem according to the present invention is installed in a computer system.
PQFMVCD. 386 is a flowchart of a routine used.

FIG. 9 illustrates a portion of a flowchart of a PPORTTOPEN routine that handles "virtual" input / output operations for a virtual UART according to the present invention.

FIG. 10 is a diagram showing the remaining part of the flowchart of the PPORTTOTEN routine.

FIG. 11 is a flowchart of macro inline code generated for a "virtual" input / output operation.

FIG. 12 is a flowchart called by the macro of FIG. 11;

FIG. 13 shows an SI executed when a call is made to the virtual UART.
FIG. 21 is a diagram showing a first part of a flowchart of an M450_READ routine.

FIG. 14 is a diagram showing a second part of the flowchart of the SIM450_READ routine.

FIG. 15 shows an SI executed when a call is made to the virtual UART.
First of flowchart of M450_WRITE routine
It is a figure showing a part.

FIG. 16 is a diagram showing a second part of the flowchart of the SIM450_WRITE routine.

FIG. 17 is a diagram showing a third part of the flowchart of the SIM450_WRITE routine.

FIG. 18: SIM_450_EVALUATE_ determining when to interrupt by virtual UART
FIG. 9 is a diagram showing a part of a flowchart of an INTERRUPT routine.

FIG. 19: SIM_450_EVALUATE_INT
FIG. 11 is a diagram showing the remaining part of the flowchart of the ERROR routine.

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

Continuation of the front page (71) Applicant 591030868 20555 State Highway 249, Houston, Texas 77070, United States of America (72) Inventor Peter Jay Brown 77069, Texas, USA Ashmore Drive 6919 (72) ) Inventor Don A. Dykes, USA 77770, Texas, Jones Road, Houston 152 (72) Inventor Andrew El Love 77388, Texas, United States, Springing, Woodsboro Drive 2411 (72) Inventor Kevin Double・ Iris 77375, Texas, United States, Tomball, Waldwick 15419

Claims (15)

[Claims] 1. A general-purpose computer system for executing a modem controller code for use with a modem that does not include a microcontroller for executing the modem controller code, the processor for executing instructions, An I / O bus coupled to the processor, the I / O bus having a digital signal processor and configured to communicate with a hardware modem without a controller, the processor comprising: a general-purpose computer; A general-purpose computer system executing both system code and said modem controller code and communicating data and commands between said executed modem controller code and said digital signal processor. 2. The computer system of claim 1, wherein the system further comprises an operating system executed by the processor.
A system driver for a hardware UART device, the device driver being called by the operating system to perform serial operations with the hardware UART device; and a virtual UART executed by the processor. A virtual UART that provides data entry and exit to the modem controller code and provides an entry point corresponding to reading from and writing to the hardware UART; The computer system of claim 11, wherein the virtual device driver is modified to call the entry point to perform reads and writes to and from the virtual UART, instead of the hardware UART. 3. The computer system according to claim 2, wherein said virtual UART emulates a 16450 UART. 4. The computer system according to claim 2, wherein the device driver is Windows (registered trademark).
A computer system, which is the virtual device driver of 3.1. 5. The computer system according to claim 2, wherein the device driver is Windows (registered trademark).
95. A computer system, wherein the computer system is a virtual device driver. 6. The computer system according to claim 2, wherein said processor is an x86 series processor, and said instructions include an "IN AL, DX" and an "OUT DX, AL" instruction.
A computer system wherein the virtual device driver is modified by replacing it with a call to the entry point. 7. The computer system according to claim 2, wherein the virtual UART provides a personalized interface to the device driver, and the virtual UA
A computer system, wherein the operating system can be changed to a second operating system having a second device driver without significant modification to RT. 8. The computer system according to claim 2, wherein the virtualized UART provides a personalized interface to the device driver and eliminates the controller without significant modifications to the device driver. A computer system, wherein the hardware modem can be changed to a hardware modem without a second controller. 9. A computer system for use with a modem having a digital signal processor, but not having a microcontroller executing modem controller code, the processor executing instructions comprising the modem controller code. A virtualized version of a physical hardware interface, the virtualized version providing a virtualized interface to the running modem controller code; and a physical hardware interface. A device driver written for replacing the instructions intended for the physical hardware interface with calls to the virtualization interface. Computer system. 10. The computer system according to claim 9, wherein said virtualized interface is an interface compatible with virtualized 16450. 11. The computer system according to claim 9, wherein the device driver is a Windows 3.1 virtual device driver. 12. The computer system according to claim 9, wherein the device driver is a Windows (registered trademark) 95 virtual device driver. 13. A method performed in a general purpose computer system, the method comprising performing a modem communication without using a hardware modem controller, providing a digital signal processor for communicating over a communication link. Executing modem controller code for communication with the digital signal processor on the general purpose computer system; and a hardware interface for communication from the modem controller code to the digital signal processor. Providing an operating system for the general purpose computer system.
System device driver software and a modem controller running on the general purpose computer system
Providing a virtualized version of the hardware interface between the operating system device driver software and the modem controller code. And the step of causing the data to be transmitted. 14. A general-purpose computer system for use with a microcontroller-less modem that executes modem controller code and executes the modem controller code, comprising: a processor for executing instructions; and a processor coupled to the processor; A disk drive for storing the modem controller code; a main memory for storing the modem controller code; and an input / output bus coupled to the processor, wherein the input / output bus has a digital signal processor and no controller. An I / O bus configured to communicate with a hardware modem, wherein the processor executes both general-purpose computer system code and the modem controller code, and executes the modem controller code. And said desi General purpose computer system, characterized by communicating data and commands between the Le signal processor. 15. The computer system according to claim 14, wherein the system further comprises an operating system executed by the processor.
A system, comprising: an operating system stored in the disk drive and the memory; and a device driver for a hardware UART device.
Being called by the operating system to perform serial operation of the hardware UART device;
A device driver stored on the disk drive and the main memory; and a virtual UART executed by the processor for communicating data with the modem controller code. And the virtual UART stored in the disk drive and main memory to provide entry points corresponding to reading from and writing to the hardware UART.
Wherein the virtual device driver is modified to call the entry point to read from and write to the virtual UART instead of the hardware UART. Computer system.