Method and appartus for emulating a peripheral device to allow device driver development before availability of the peripheral device

I claim:

1. A system for emulating a peripheral device, comprising:

a host bus;

a memory coupled to said host bus containing a device driver code and a peripheral device emulation program;

a first general purpose processor coupled to said host bus and executing said code;

a second general purpose processor coupled to said host bus and having a communication channel accessible by said first general purpose processor, said second general purpose processor executing said peripheral device emulation program, said first general purpose processor accessing said communication channel when said device driver code performs an I/O access to the peripheral device being emulated to provide an I/O address and an I/O command, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response;

wherein said memory further contains a communications packet having a plurality of parameters, and wherein communication between said device driver code and said peripheral device emulation program is accomplished via said communications packet; and

wherein said plurality of parameters include an address parameter and a command parameter, said address parameter containing a value indicating a peripheral device port, said command parameter indicating an I/O command to be performed to said peripheral device port, and wherein said peripheral device emulation program performs a function according to said values stored in said address and command parameters.

2. A system for emulating a peripheral device, comprising:

a host bus;

a memory coupled to said host bus containing a device driver code and a peripheral device emulation program;

a first general purpose processor coupled to said host bus and executing said code;

a second general purpose processor coupled to said host bus and having a communication channel accessible by said first general purpose processor, said second general purpose processor executing said peripheral device emulation program, said first general purpose processor accessing said communication channel when said device driver code performs an I/O access to the peripheral device being emulated to provide an I/O address and an I/O command, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response;

wherein said communication channel of said second general purpose processor includes an interprocessor interrupt port, and wherein said first general purpose processor asserts an interprocessor interrupt to said interprocessor interrupt port when said device driver code performs said I/O access to the peripheral device being emulated;

wherein said memory further contains an interprocessor interrupt packet having a plurality of parameters, wherein communication between said device driver code and said peripheral device emulation program is accomplished via said interprocessor interrupt packet; and

wherein said plurality of parameters include an address parameter and a command parameter, said address parameter containing a value representing a peripheral device port, said command parameter representing an I/O command to be performed to said peripheral device port, and wherein said peripheral device emulation program performs a function according to said values stored in said address and command parameters.

3. The system of claim 2, wherein said plurality of parameters further include a mask parameter having a value representing a vector pointing to said peripheral device emulation program in said memory, and wherein assertion of said interprocessor interrupt by said first general purpose processor includes writing said mask parameter to said interprocessor interrupt port.

4. A system for emulating a peripheral device, comprising:

a host bus;

a memory coupled to said host bus containing a device driver code and a peripheral device emulation program;

a first general purpose processor coupled to said host bus and executing said code:

a second general purpose processor coupled to said host bus and having a communication channel accessible by said first general purpose processor, said second general purpose processor executing said peripheral device emulation program, said first general purpose processor accessing said communication channel when said device driver code performs an I/O access to the peripheral device being emulated to provide an I/O address and an I/O command, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response;

wherein said communication channel of said second general purpose processor includes an interprocessor interrupt port, and wherein said first general purpose processor asserts an interprocessor interrupt to said interprocessor interrupt port when said device driver code performs said I/O access to the peripheral device being emulated;

wherein said peripheral device emulation program includes an emulation interrupt handler, said emulation interrupt handler being invoked when said interprocessor interrupt is asserted by said first general purpose processor; and

wherein said memory further contains an operating system, wherein said first general purpose processor is controlled by said operating system, and wherein said emulation interrupt handler being executed by said second general purpose processor is independent of said operating system.

5. A method of emulating a peripheral device in a multiprocessor computer system, wherein the multiprocessor computer system includes a first general purpose processor, a second general purpose processor, and a memory, all coupled to a host bus, the memory containing a device driver code, the first general purpose processor for executing said device driver code, the second general purpose processor having a communications channel accessible by the first general purpose processor, the method comprising the steps of:

loading a peripheral device emulation program into the memory;

the device driver code performing an I/O access to the peripheral device to be emulated to provide an I/O address and an I/O command;

the first general purpose processor accessing the communication channel of the second general purpose processor in response to the device driver code performing said I/O access;

the second general purpose processor responding to said access of the communication channel by invoking said peripheral device emulation program, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response;

wherein the memory further contains a communications packet having a plurality of parameters, the method further comprising the steps of:

the device driver code writing certain of said plurality of parameters in said communications packet to communicate to said peripheral device emulation program; and

said peripheral device emulation program writing certain others of said plurality of parameters in said communications packet to communicate to the device driver code; and

wherein said plurality of parameters include an address parameter and a command parameter, said address parameter containing a value written by the device driver code for indicating a peripheral device port, said command parameter containing a value written by the device driver code for indicating an I/O command to be performed on said peripheral device port, and wherein said peripheral device emulation program performs a function according to said values stored in said address and command parameters.

6. A method of emulating a peripheral device in a multiprocessor computer system, wherein the multiprocessor computer system includes a first general purpose processor, a second general purpose processor, and a memory, all coupled to a host bus, the memory, containing a device driver code, the first general purpose processor for executing said device driver code, the second general purpose processor having a communications channel accessible by the first general purpose processor, the method comprising the steps of:

loading a peripheral device emulation program into the memory;

the device driver code performing an I/O access to the peripheral device to be emulated to provide an I/O address and an I/O command;

the first general purpose processor accessing the communication channel of the second general purpose processor in response to the device driver code performing said I/O access; and

the second general purpose processor responding to said access of the communication channel by invoking said peripheral device emulation program, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response; and

wherein the multiprocessor computer system further includes a secondary storage device, said secondary storage device storing an emulate parameter and a first set of a plurality of macro commands, the method further comprising the step of:

compiling said first set macro commands if said emulate parameter is defined to a first value,

and wherein said step of the device driver code performing said I/O access includes the step of:

the device driver code issuing one of said compiled first set macro commands, wherein each of said compiled first set macro commands includes an instruction for causing said first general purpose processor to access the communication channel of said second general purpose processor.

7. The method of claim 6, wherein the multiprocessor computer system further includes an actual peripheral device coupled to the host bus, wherein said secondary storage device further stores a second set of a plurality of macro commands, the method further comprising the step of:

compiling said second set macro commands if said emulate parameter is defined to a second value,

wherein said step of the device driver code performing said I/O access includes the step of:

the device driver code issuing one of said compiled second set macro commands to perform an I/o access to said actual peripheral device, wherein each of said compiled second set macro commands includes an actual I/O command for issuing to said actual peripheral device.

8. A method of emulating a peripheral device in a multiprocessor computer system, wherein the multiprocessor computer system includes a first general purpose processor, a second general purpose processor, and a memory, all coupled to a host bus, the memory containing a device driver code, the first general purpose processor for executing said device driver code, the second general purpose processor having a communications channel accessible by the first general purpose processor, the method comprising the steps of:

loading a peripheral device emulation program into the memory;

the device driver code performing an I/O access to the peripheral device to be emulated to provide an I/O address and an I/O command;

the first general purpose processor accessing the communication channel of the second general purpose processor in response to the device driver code performing said I/O access; and

the second general purpose processor responding to said access of the communication channel by invoking said peripheral device emulation program, wherein said peripheral device emulation program responds to said I/O address and I/O command to emulate the peripheral device response; and

wherein the multiprocessor computer system further includes a third general purpose processor coupled to the host bus, the method further comprising the steps of:

loading a second peripheral device emulation program into the memory; and

the third general purpose processor executing said second peripheral device emulation program for concurrent emulation of a peripheral device on the second and third general purpose processors.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to peripheral devices, and more particularly, to a method of emulating peripheral devices to allow for the development of device drivers before availability of the peripheral devices.

2. Description of the Related Art

Historically, computer systems have developed as single microprocessor, sequential machines which process one instruction at a time. However, performance limits are being reached in single microprocessor computer systems. As a result, multiprocessor computer systems comprising multiple microprocessors are developed that work in parallel on different tasks or different parts of a task. The multiple microprocessors are typically connected via a host bus. Also, an expansion bus for connection to peripheral devices is typically connected to the host bus through an interface. Because of the increased performance demands, peripheral devices often include a bus master, which can directly communicate with the memory of the computer system, freeing the system microprocessors up for other activities.

An operating system executes on the various microprocessors, and serves as the interface between the various application programs and the hardware of the computer system. The operating system communicates with the various peripheral devices via I/O control programs referred to as device drivers. A device driver acts as an interface between the operating system and the corresponding peripheral device. The device driver provides control commands to activate the peripheral device and to check the device status to determine when it is ready for a data transfer. The device driver also performs error checking when transfers are occurring to ensure that the transfer has completed successfully. Further, the device driver responds when the peripheral device indicates completion of the control commands.

To write a device driver program, a detailed knowledge of the peripheral device is required. Consequently, device drivers are typically provided by manufacturers of the peripheral device. In many instances, the actual peripheral device hardware may not be available while the device driver is being developed by the manufacturer. As a result, actual testing and any debugging changes that need to be made must wait until the actual hardware becomes available. This increases the development time for the device driver, and as a result, the peripheral device, thereby delaying the availability of the new peripheral device. If a large portion of the device driver testing and debugging could occur without the need for the actual peripheral device hardware, the overall time to develop a peripheral device would be decreased, resulting in more rapid computer system improvement. It is further desirable that this testing be performed under conditions close to those present if the peripheral device were present. It may be possible to develop emulators to simulate peripheral device operation, but the emulator would operate on the same microprocessor as the device driver, thus providing a highly artificial environment which provides little testing of numerous portions of device driver operation, such as multitasking, multi-threading, and real time operation.

SUMMARY OF THE PRESENT INVENTION

The method and apparatus according to the present invention performs an emulation of a peripheral device. The emulation is performed by one or more free microprocessors in a multiprocessor computer system. In the preferred embodiment, during the power up initialization phase of the device drivers, the emulation program is loaded by a host microprocessor from the hard disk drive to an allocated region in system memory. After the emulation program is loaded, control vectors to the entry point of the emulation program. Because there are 4 microprocessors in the preferred embodiment, the emulation program can be divided into different tasks and run on up to 3 free target microprocessors, that is, those microprocessors not being accessed by the operating system software. If multiple microprocessors are used, the microprocessor ("master" microprocessor) on which the first instance of the emulation program is running is set up to accept an interprocessor interrupt (IPI) from the host microprocessor. The IPI is a means by which the host microprocessor performs an interprocessor communication with another microprocessor in the preferred embodiment. Once the target microprocessors have been properly initialized, the target CPUs remain idle until an interprocessor interrupt is asserted by the host microprocessor to the master CPU. If emulation mode is selected, then I/O commands issued by the device driver cause the host microprocessor to issue an IPI to the master microprocessor, which responds by invoking an I/O emulation interrupt handler for performing the actual peripheral device emulation. Upon completion of the I/O emulation, the host microprocessor is notified. Thus, by running the emulator program on one or more target CPUs to emulate a peripheral device, the device driver developer can test various features of the device driver such as multi-tasking, multi-threading and real time operations.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 is a block diagram of an exemplary multiprocessor computer system that incorporates the preferred embodiment of the present invention;

FIG. 2 is a block diagram of a central processing unit in the multiprocessor computer system of FIG. 1;

FIGS. 3A and 3B are a flow diagram of a routine for loading an emulator program from a hard disk drive into a memory in the multiprocessor computer system of FIG. 1;

FIGS. 4A and 4B are a flow diagram of a subroutine called by the routine of FIGS. 3A and 3B to perform the actual loading;

FIG. 5 is a flow diagram of a subroutine for starting the emulator program on a target microprocessor;

FIG. 6 is a flow diagram of the portion of the emulator program that performs initialization functions;

FIGS. 7A and 7B are a flow diagram of a subroutine called by the routine in FIG. 6 for performing certain initialization steps;

FIG. 8 is a flow diagram of a subroutine called by the routine of FIG. 6 that connects an I/O emulation interrupt handler to a particular interrupt level of the programmable interrupt controller in the central processing unit of FIG. 2;

FIG. 9 is a flow diagram of an exemplary I/O command macro; and

FIG. 10 is a flow diagram of the I/O emulation interrupt handler.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1, a computer system C is shown which is a multiprocessor system preferably comprising four central processing units (CPUs) in the preferred embodiment, although the present invention may be incorporated into a system having only two CPUs. The CPUs are general purpose processors such as the 80486 and Pentium processors from Intel Corporation or other processors from other manufacturers. The elements of the computer system C that are not significant to the present invention other than to illustrate an example of a fully configured computer system are not discussed in detail. Most of the functions and device blocks shown in FIG. 1 are preferably mounted on a system board (not shown). The computer system C preferably includes four CPUs referred to as CPUs 20, 21, 22 and 23, which are connected to a host bus 24. The CPUs 20-23 are referred to as CPU0, CPU1, CPU2 and CPU3, respectively, indicating the preferred logical port assignments. In the preferred embodiment, at least four CPU connectors are provided on the host bus 24 for receiving interchangeable CPU cards 20-23, where the CPUs 20-23 are essentially identical in configuration and function. In the preferred embodiment, the computer system C is capable of supporting up to a maximum of 8 CPUs. The port assignments are initially determined by the physical slot that a CPU card is plugged into, although logical port assignment is preferably programmable.

A memory controller 30 is coupled to the host bus 24 and also to a main memory array 32, preferably comprising several banks of DRAMs. Memory mapper logic 34 is coupled to the host bus 24, the memory controller 30 and the memory array 32, and provides memory mapping functions to facilitate memory accesses to the memory array 32. The computer system C includes an expansion bus 42 which is preferably the Extended Industry Standard Architecture (EISA) bus, although other types of expansion buses are contemplated. Other architectures include those having both an EISA expansion bus and a PCI mezzanine bus. In the PCI-EISA systems, APIC or open-PIC subsystem are used. A corresponding EISA bus controller (EBC) 40 is coupled between the host bus 24 and the EISA bus 42. The EBC 40 provides various bus cycle translation and conversion functions to facilitate transfers between the host bus 24 and the EISA bus 42. A system data buffer (SDB) 44 is coupled to the host bus 24, the EISA bus 42 and the memory array 32. The SDB 44 functions to buffer and transfer data between the host bus 24 and the memory array 32, between the host bus 24 and the EISA bus 42, and between the EISA bus 42 and the memory array 32.

A logic block referred to as a central system peripheral (CSP) 46 is coupled to the host bus 24, the EISA bus 42 and is also coupled to a keyboard controller 62. The CSP 46 is preferably coupled through a MUX bus 50 to a logic block referred to as the distributed system peripheral (DSP) 88A in the CPU 20, to a DSP 88B located in the CPU 21, to a DSP 88C located in the CPU 22, and to a DSP 88D in the CPU 23. The MUX bus 50 comprises a plurality of lines for transferring signals between the CSP 46 and the DSPs 88A-D.

The EISA bus 42 includes a plurality of EISA slots 52 and 54 for receiving EISA interchangeable expansion cards such as, for example, network interface or hard disk interface cards. The EISA bus 42 is coupled through buffers 56 to a bus referred to as an X bus 60. A number of peripheral devices are coupled to the X bus 60, including the keyboard controller 62, a real time clock (RTC) 64, an electrically erasable programmable read only memory (EEPROM) 66, a floppy disk controller 68 and a peripheral controller chip 70, which includes numerous ports and UARTs (universally asynchronous receiver/transmitters). The EEPROM 66 contains certain basic operating routines, referred to as the BIOS, to perform power up functions in the computer system C. The power up functions include the initialization of device drivers for the peripheral and I/O devices. The X bus 60 is also coupled to a hard disk controller 69, which provides control and data signals to a hard disk drive 71.

The CSP 46 includes various system functions, including a refresh controller 90, a MUX bus interface 92 coupled to the MUX bus 50, a direct memory access (DMA) controller 94, an EISA or central arbitration controller (CAC) 96 and other miscellaneous system board logic functions which are generally referred to as the SGC 98. The refresh controller 90 controls the refresh of the DRAMs in the memory array 32, and the DMA controller 94 controls direct memory accesses to the memory 32 by the peripheral and I/O devices. The MUX bus interface 92 receives various interrupt request signals IRQ3-IRQ12, IRQ14 and IRQ15 from the various peripheral and I/O devices. The MUX bus interface 92 then transmits corresponding interrupt request signals to the DSPs 88A-D via the MUX bus 50. The SGC 98 in the CSP 46 includes the CPU restart logic and force A20 logic and asserts corresponding RSTAR and LOW A20 signals, which are provided to the MUX bus 50.

Other miscellaneous transfers are required to inform the DSPs 88A-D of the occurrence of several miscellaneous events within the CSP 46. Both the assertion and deassertion of these events are transferred on the MUX bus 50. Upon power up, the computer C automatically determines which CPUs are installed in available physical CPU slots and assigns logical port numbers. A power up timeout signal is asserted if a CPU does not respond before timeout of a timer indicating that the CPU is not installed.

Referring now to FIG. 2, a block diagram of the CPU 20 is shown. The CPUs 20-23 preferably operate in a very similar manner, except that only the CPU 20 generates a memory refresh in the preferred embodiment since it is preferably the host CPU, that is, it is assigned to logical CPU0. The CPU 20 is now described, it being understood that the following description applies also to CPUs 21-23. The CPU 20 includes a microprocessor 72 which is preferably either the Pentium or the 80486 microprocessor from Intel. The microprocessor 72 is coupled to a processor bus 76, which includes control, data and address portions as shown. A second level cache controller 78 is coupled to the address and control portions of the processor bus 76. A cache memory 80 is coupled to the address and data portions of the processor bus 76. The cache controller 78 connects to the cache memory 80 via various control lines to provide a unified writeback and instruction cache which is transparent to system software.

Cache interface logic 82 is coupled to the cache controller 78 through control lines and is coupled to the control portion of the processor bus 76 and the host bus 24. The address pins of the cache controller 78 are connected to a transceiver 84, which in turn is connected to the host bus 24. The address signals provided by the transceiver 84 are also connected to the cache interface logic 82. The data pins of the cache memory 80 are connected to a cache data buffer 86, which is connected to the host bus 24. The cache data buffer 86 is connected to the DSP 88A via a local I/O bus 90 comprising local I/O address data and control lines.

The DSP 88A includes a programmable interrupt controller (PIC), NMI logic, various timers and a multiprocessor interrupt (MPINT) logic. The PIC preferably comprises two cascaded 8-bit interrupt controllers INT-1 and INT-2, each similar to the Intel 8259 to provide 15 levels of interrupts. Control, mask, and edge/level control registers are provided in the DSP 88A for each of the interrupt controllers INT-1 and INT-2. The INT-1 has inputs IRQ0-IRQ7, where IRQ2 is the cascaded interrupt IRQ2 from INT-2. INT-2 receives inputs IRQ8-IRQ15. The CSP 46 provides the interrupts IRQ1, IRQ3-12 and IRQ14 and IRQ15, as described previously, across the MUX bus 50 to the PIC.

Certain of the IRQ inputs to the PIC are asserted by peripheral devices such as keyboards, hard disk drives, floppy disk drives, display monitors and other components. Each peripheral device notifies the microprocessor that it requires servicing by asserting an IRQ signal to the PIC, which functions as an overall manager in accepting interrupt requests from the peripheral devices. The IRQ0 signal is provided by the various timers and provides a system timer interrupt for a time of day, diskette timeout and other system timing functions. The IRQ13 interrupt is shared with a DMA interrupt, a correctable memory error interrupt, a coprocessor error interrupt and several CPU IRQ13 programmable interrupts. The PIC determines which of the incoming requests has the highest priority and whether any of the IRQ lines are masked. The PIC then issues an interrupt INT to the microprocessor 72 based on this determination. In response to the assertion of the signal INT, the microprocessor 72 finishes completion of the current instruction. Next, the microprocessor 72 saves the state of the interrupted program which includes its address and the contents of certain registers onto a stack to allow resumption of the interrupted program once the interrupt has been serviced.

The microprocessor 72 then asserts an interrupt acknowledge cycle on the local I/O bus 90, which causes the appropriate one of the 8259 interrupt controllers to provide an 8-bit interrupt vector onto the local bus 90. The microprocessor 72 then determines the branch address of the interrupt service routine based on the interrupt vector. The interrupt service routine is then executed to perform the functions requested by the peripheral device. After completion of the interrupt service routine, an end-of-interrupt (EOI) cycle is executed to the PIC.

The NMI logic in the DSP 88A generates an NMI interrupt via a signal NMI to notify the local microprocessor 72 of conditions in the system that need immediate attention before the microprocessor 72 may proceed with its current task.

The MPINT logic allows CPU interprocessor interrupts (IPIs) and other interrupt sources to be shared at any interrupt level, thus allowing for greater software flexibility in a multiprocessor environment. The MPINT logic generates interrupt levels MPIRQ0-15, which are generated in response to interprocessor interrupts. Each programmable CPU interrupt may be individually enabled, disabled, set or cleared in any interrupt level through multiprocessor interrupt control/status ports. The MP interrupt ports are generally referred to as control ports when written to and status ports when read. Each level of interrupt, generally represented by the letter X, is an integer from 0 through 15 excluding level 2, where each of the interrupt levels MPIRQ0-15 has its own MP interrupt control/status port. Predetermined values written to the control ports can thus enable or set an interrupt level MPIRQX to respond to an IPI. The status for each of the interrupt levels X can be obtained by reading the corresponding MP interrupt status port. The microprocessor 72 may access its own MP interrupt ports via a local bus access and may access the MP interrupt ports of other processors through the host bus 24.

Interprocessor interrupts are mapped to interrupt level MPIRQX via a CPU interrupt mask port and a CPU programmable interrupt port. The MP interrupt request outputs (MPIRQX) are ORed with the IRQX inputs within the PIC, thus allowing for the sharing of interprocessor interrupt levels with normal system interrupts.

In the ensuing description, it is assumed that the CPU 20 is the host CPU, although any of the other CPUs 21-23 can be the host. Thus, if the other three CPUs 21-23 are not being used by the operating system, a virtual device emulator (VDE) can be executed on one or more of the CPUs 21-23. The VDE can be subdivided into multiple tasks and run on multiple target CPUs. When more than one CPU is used to execute the VDE, the CPU 21 is preferably referred to as the master CPU.

The virtual device emulator is separated into two portions. The first portion is the emulator loader (EMLOADER.SYS) and is run on the host CPU 20. The second portion is the emulator (EMULATOR.EXE). The loader EMLOADER.SYS, which is operating system dependent, loads the emulator EMULATOR.EXE into system memory 32 for execution by one or more of the target CPUs 21-23. The emulator EMULATOR.EXE is operating system independent and is thus executed on the target CPUs free of operating system control.

The peripheral device developer can enable or disable emulation of peripheral and I/O devices by setting a parameter EIO.sub.-- EMULATOR high or low, respectively. In the preferred embodiment, the device drivers are written as C code. To perform I/O commands to peripheral devices, the device drivers execute various macro commands. Two sets of macro commands are available, wherein the compiler or assembler compiles one set based upon the state of the parameter EIO.sub.-- EMULATOR. One set of macro commands perform the actual I/O command to an existing peripheral device, whereas the other set of macro commands issues an interprocessor communication sequence to pass the I/O command to the master CPU 21 for performing emulation of peripheral devices. The first set of macro commands is utilized when the parameter EIO.sub.-- EMULATOR is set low at compile time, which indicates that emulation mode is not selected, and the second set of macro commands is utilized if the parameter EIO.sub.-- EMULATOR is set high at compile time, indicating that emulation mode is selected. In emulation mode, the I/O commands, addresses and data are passed via an IPI packet located preferably in the memory 32. In addition, in the preferred embodiment, a parameter EIOCOMPLETE is included in the IPI packet to allow the target CPUs 21-23 to notify the host CPU 20 that an I/O emulation has completed. In an alternative embodiment, one or more of the target CPUs 21-23 can assert interprocessor communication sequences via IPIs back to the host CPU 20 to notify the host CPU 20 that emulation has completed.

Referring now to FIGS. 3A and 3B, the flow diagram of the program that loads the emulator EMULATOR.EXE into system memory 32 is shown. The program is merely one embodiment of loading the emulator file from the hard disk drive 71 into the memory 32, it being contemplated that other loading methods exist. During the computer system power up process, one of the functions performed by the booting procedure is to initialize the device drivers. The loader EMLOADER.SYS is invoked during the initialization of the device drivers. Beginning in step 200, it is determined if a free CPU is available. This is accomplished by searching the CPU chain for a CPU that is not being used by the operating system, that is, the CPU is in sleep mode. If a free CPU is found, then control proceeds to step 202. Otherwise, control proceeds to step 204, where a flag CPUNOTAVAIL is set high to indicate to the host CPU 20 that all of the available CPUs are being accessed by the operating system. From step 204, control returns to the power up BIOS routine.

In step 202, a portion of low memory is allocated to store a Real Mode routine STARTUP. Because the routine STARTUP is executed in Real Mode, it is loaded into the lower 1 Mbyte of the memory 32. The routine STARTUP is used to perform BIOS INT 13H physical disk services to load the emulator EMULATOR.EXE from the hard disk drive 71 into the memory 32. In the preferred embodiment, INT 13H calls must be executed to perform any physical disk services to the hard disk drive 71. The software interrupt INT 13H causes a BIOS disk service routine to be invoked to provide the appropriate commands to the hard disk drive controller 69. Because different types of hard disk drives require different command and data sequences, the BIOS disk service routine necessarily acts as an interface between the OS and the hard disk drive controller 69. If the INT 13H call is issued in the loader EMLOADER.SYS, the host CPU 20 would have to be transitioned from Protected Mode to Real Mode. Such a transition involves high overhead and is thus undesirable. Since it has already been determined that one of the CPUs 21-23 is not currently in use, and thus is in Real Mode, the routine STARTUP can be executed on the free CPU. In this manner, the host CPU 20 need not be transitioned from Protected Mode to Real Mode.

Certain of the registers associated with Protected Mode operation of the 80486 and Pentium microprocessors are described briefly for a better understanding of the following description. The registers include the system flags register EFLAGS, whose bits control I/O, maskable interrupts, debugging, task switching, and the virtual-8086 mode. Among these flag bits is the Interrupt-Enable Flag IF, which when set enables the microprocessor to respond to maskable interrupt requests. Clearing the IF flag disables the interrupts.

Another set of registers is referred to as the memory management registers, which include the Global Descriptor Table Register GDTR and the Interrupt Descriptor Table Register IDTR. The register GDTR contains the 32-bit base address and the 16-bit segment limit for the global descriptor table (GDT). When a reference is made to data in memory, a segment selector is used to find a segment descriptor in the GDT. The segment descriptor contains the base address for a segment. The register IDTR contains the 32-bit base address and 16-bit segment limit for the interrupt descriptor table (IDT). When an interrupt occurs, the interrupt vector is used as an index to obtain a gate descriptor from the IDT. The gate descriptor holds a pointer used to start up the interrupt handler.

The 80486 and Pentium microprocessors also include control registers CR0, CR1, CR2, CR3 and CR4. The control register CR0 contains system control flags to control modes or to indicate states which apply generally to the microprocessor rather than to the execution of an individual task, which is controlled by the flags register EFLAGS. The control register CR3, referred to as the page directory base register, contains the 20 most significant bits of the address of the page directory. Since the page directory must be aligned to a page boundary (each page contains 4K bytes), the lower 12 bits of the register CR3 are not used as address bits.

The 80486 and Pentium microprocessors include segment registers that contain 16-bit selectors. The selectors point to tables in memory, where the tables hold the base address for each segment. The segment containing the instructions being executed is the code segment, whose selector is contained in the CS register. An instruction pointer register EIP contains the offset into the segment pointed to by the CS selector.

A stack is an allocated region in memory that contains the return address, parameters passed by the calling routine, and temporary variables allocated by the procedure. Many stacks can be allocated in memory. The stack segment register SS is used to point to the current stack. The stack pointer register holds an offset to the top-of-stack in the current stack segment.

From step 202, control proceeds to step 206, where parameters to be loaded into the code segment and instruction pointer registers associated with the real mode routine STARTUP and the emulator EMULATOR.EXE are initialized. The Real Mode routine STARTUP contains two entry points STARTUPBIOS and STARTUPEM. If emulation of peripheral devices is desired, that is, the parameter EIO.sub.-- EMULATOR is defined high, then the compiler or assembler utilizes a first set of hard disk macro commands, which vector to the entry point STARTUPBIOS of the routine STARTUP to perform the INT 13H physical disk services. Otherwise, a second set of hard disk macro commands are utilized by the compiler or assembler which directly perform the INT 13H physical disk services. Once the emulator EMULATOR.EXE is loaded into the memory 32, control vectors to the entry point STARTUPEM, which causes the target CPU to transition from Real Mode to Protected Mode and causes the target CPU to vector to the entry point of the emulator EMULATOR.EXE.

Next, in step 208, the Real Mode routine STARTUP is copied into the allocated lower 1 Mbyte of the memory 32. Next in step 210, the image size of the emulator EMULATOR.EXE is determined. In the preferred embodiment, this is accomplished by reading the first two sectors of the image header of the emulator file located on the hard disk drive 71. The number of pages required to store the emulator image is then retrieved from information stored in these two sectors. Next, in step 212, a physically contiguous portion of the memory 32 is allocated for the emulator file. The starting address of the allocated region of memory for the emulator EMULATOR.EXE is stored in IMAGEB. Proceeding next to step 214, the subroutine LOADIMAGE is called to load the emulator file from the hard disk drive 71 into the allocated chunk of memory. The arguments passed to the subroutine LOADIMAGE are the name of the emulator EMULATOR.EXE and the address IMAGEB.

Referring now to FIGS. 4A and 4B, the flow diagram for the subroutine LOADIMAGE is shown. Starting in step 300, the emulator file stored on the hard disk drive 71 is opened. In the preferred embodiment, INT 13H calls must be executed to perform an access to the hard disk drive 71. However, as noted above, the program EMLOADER.SYS runs in Protected Mode on the host CPU 20 and thus is unable to issue the real mode INT 13H call. Therefore, the INT 13H call must be performed by the Real Mode routine STARTUP, which is executed on the target CPU. To invoke the routine STARTUP, the CS:IP pointing to the entry point STARTUPBIOS is loaded into a warm reset vector, which is preferably stored at physical address 0.times.467. A reset command, represented by the signal RSTAR being asserted, provided to the target CPU would cause control to vector to the location specified by the warm reset vector. In the preferred embodiment, if the emulation mode is selected by defining the parameter EIO.sub.-- EMULATOR high, then a disk services command issued to the hard disk drive 71 causes the signal RSTAR to be issued to the target CPU.

Proceeding next to step 302, the first two sectors of the image header of the emulator file is read. Next, in step 304, it is determined from information in the two sectors if the emulator file is executable on an 80486 or Pentium microprocessor or is a WINDOWS NT image. If any of the above conditions are true, control proceeds to step 308; otherwise, control proceeds to step 306, where the emulator file on the hard disk drive 71 is closed. From step 306, control returns to step 214 in FIG. 3A.

In step 308, the starting page number and the number of pages NPAGE required to store the entire emulator image is retrieved from the header information in the first two sectors. Proceeding next to step 310, the entire image header of the emulator file is read into the allocated region starting at address IMAGEB of the memory 32.

Proceeding next to step 312, the base address PAGEADR�INDEX! for the emulator image on the hard disk drive 71 is calculated. The address PAGEADR�INDEX! is the starting address of page INDEX. Proceeding next to step 314, the variable INDEX is initialized to the value 0. Next, in step 316, the header of the first page or section is read from the hard disk drive 71. The section header is accessed to determine if the particular page or section contains code or initialized data. In step 318, if it is determined that the particular section contains uninitialized data, control proceeds to step 320, where the memory region starting at address IMAGEB+PAGEADR�INDEX! corresponding to the accessed section of the hard disk drive 71 is cleared. From step 320, control proceeds to step 324.

If it is determined in step 318 that the page or section starting at address PAGEADR�INDEX! in the hard disk drive 71 contains code or initialized data, control proceeds to step 322, where the entire section is read from the hard disk drive 71 into the memory 32 at address IMAGEB+PAGEADR�INDEX!. From step 322, control proceeds to step 324, where the variable INDEX is incremented by 1 to access the next page or secti