Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5088033
Binkley , ; et al.
February 11, 1992
Title
Data processing system emulation in a window with a coprocessor and I/O emulation
Abstract
An emulating data processor includes a host system and an emulating processor with outputs to and inputs from the host system. The emulating processor executes sequences of instructions executable by a PC being emulated, but a host processor independently executes sequences of its instructions which are different from PC instructions. Circuitry monitors the emulating processor outputs and provides information to the host system so that it can emulate the environment of the PC CPU, emulating both memory and I/O devices. The memory accesses of the emulating processor are mapped into the host system memory, so that the host processor is protected from defective PC software on the emulating processor. The display updates of the emulating processor are detected and provide information for the host processor in updating a part of its display which provides the information a PC display would provide simultaneously with the display characteristic of the host system. An input/output processor handles I/O operation requests of the emulating processor, using the host system I/O devices to emulate some of the PC I/O devices. Output operations to the printer may go either to a local printer or to a file for subsequent printing, so a buffer which can be unloaded to either destination emulates the PC printer. Floppy operations may be handled either by a floppy disk controller like that of the PC or by a software controller of a file in host rigid disk memory which may be accessed as a PC floppy disk, so that a data structure containing parameters of the operation is loaded and provided to the appropriate controller. Rigid disk operations are handled by another file in host rigid disk memory which may be accessed as a PC rigid disk, and an appropriate I/O operating system routine is provided so that the emulating processor can pass the operation parameters through to the host rigid disk controller in a group of registers. Keyboard input operations may come either from the host keyboard or directly from a data structure managed by the host processor, in each case converted to PC codes, and another buffer which can be loaded from either source emulates the PC keyboard. The host system emulates the environment of the emulating processor while emulating the user interface of the PC.
Inventors:
Binkley; Joseph H.
(Palo Alto,
CA
)
, Caro; Perry A.
(Palo Alto,
CA
)
, Dillon; John B.
(Palo Alto,
CA
)
, Fay; Charles R.
(Long Beach,
CA
)
, Gibbons; Jonathan
(Mountain View,
CA
)
, Hooks; Hilary N.
(Newark,
CA
)
, Kadifa; Abdo G.
(Sunnyvale,
CA
)
, Lee; Jeffery W.
(Sunnyvale,
CA
)
, Lynch; William C.
(Palo Alto,
CA
)
, Mock; Clayton W.
(Redwood City,
CA
)
, Neely; Everett T.
(Montara,
CA
)
, Tallan; Michael L.
(Mountain View,
CA
)
, Thompson; Geoffrey O.
(Palo Alto,
CA
)
, Vukkadala; Gaya
(Sunnyvale,
CA
)
, Wick; John D.
(Palo Alto,
CA
)
, Woods; Donald R.
(Los Altos,
CA
)
Assignee:
Xerox Corporation
(Stamford,
CT
)
Appl. No.:
499196
Filed:
March 23, 1990
Current U.S. Class:
703/24
Current International Class:
G06F 13/10 (20060101)
Field of Search:
364/2MSFile,9MSFile
U.S. Patent Documents
3643252
February 1972
Roberts, Jr.
3932843
January 1976
Trelut et al.
3955180
May 1976
Hirtle
4031517
June 1977
Hirtle
4149148
April 1979
Miller et al.
4149238
April 1979
James et al.
4204206
May 1980
Bakula et al.
4253145
February 1981
Goldberg
4278973
July 1981
Hughes et al.
4315310
February 1982
Bayliss et al.
4365294
December 1982
Stokken
4365295
December 1982
Katzman et al.
4437184
March 1984
Cork et al.
4456954
June 1984
Bullions, III et al.
4458331
July 1984
Amezcua et al.
4463442
July 1984
Dachowski et al.
4484266
November 1984
Becker et al.
4484302
November 1984
Cason et al.
4550386
October 1985
Hirosawa et al.
4555775
November 1985
Pike
4564903
January 1986
Guyette et al.
4590556
May 1986
Berger et al.
4591975
May 1986
Wade et al.
4617624
October 1986
Goodman
4621319
November 1986
Braun et al.
4648034
March 1987
Heninger
4665482
May 1987
Murray, Jr. et al.
4695945
September 1987
Irwin
4703420
October 1987
Irwin
4709328
November 1987
Anthony, Jr. et al.
4713751
December 1987
Dretton et al.
4716526
December 1987
Mori et al.
4722048
January 1988
Hirsch et al.
4727480
February 1988
Albright et al.
4727491
February 1988
Culley
4729094
March 1988
Zolnowsky et al.
4731736
March 1988
Mothersole et al.
4757441
July 1988
Buckland et al.
4787026
November 1988
Barnes et al.
4812975
March 1989
Adachi et al.
4833596
May 1989
Buckland et al.
4899136
February 1990
Beard et al.
4934036
June 1990
Beard et al.
4939507
July 1990
Beard et al.
Foreign Patent Documents
0165517
Dec., 1985
EP
0168034
Jan., 1986
EP
0197499
Oct., 1986
EP
0205949
Dec., 1986
EP
0210345
Feb., 1987
EP
0223383
May., 1987
EP
0229336
Jul., 1987
EP
0229700
Jul., 1987
EP
0237671
Sep., 1987
EP
2119977
Nov., 1983
GB
Other References
Mike Heck "Quadlink Running Apple Software on an IBMPC", Interface Age, May 1984, pp. 108-110. .
Moskowitz "Applin-Card-Enchancing Your Apple", Interface Age Aug. 1983, pp. 107-108, 111. .
Morganstein "Alf's 8088 Coprocessor for Your Apple", Byte, Dec. 1984, A. 38, 40-43. .
Peck "Expanding Your Apple's Applications", Byte, Dec. 1984, pp. A45-A47, A122-126. .
Libertine, J. A., "The Xerox 16/8 Professional: A Workhorse for the Office", Business Computer Systems, May 1984, pp. 147, 149, 151. .
Xerox Corporation, "16/8 Professional Computer", one sheet Brochure. .
Xerox Corporation, "Xerox 16/8 Professional Computer--Two Computers in One--Meeting Leaders Guide", 1-11, 1983. .
"New Systems Abound at the National Computer Conference", Byte, Jul. 1983, p. 7. .
"Honeywell MicroSystem 6/10", Honeywell Information Systems CU60-01, 1983. .
"MicroSystem 6/10", Honeywell Information Systems CU60-04, 1985. .
"How Would You Design A MicroSystem", Honeywell Information Systems GB 83-00. .
"Honeywell Introdueces Networking Microcomputer", Honeywell Inc., 1983. .
"First Public Showing of MicroSystem 6/10 at NCC", Honeywell Inc., 1983. .
"Honeywell Offers Powerful Networking Microcomputer", Honeywell Inc., 1983. .
Irwin, J. W., "Use of a Coprocessor for Emulating the PC AT", in F. Waters, Ed., IBM RT Personal Computer Technology, IBM, Austin, 1986, pp. 137-141. .
Krishnamurty, R., and Mothersole, T., "Coprocessor Software Support", in F. Waters, Ed., IBM RT Personal Computer Technology, IBM, Austin, 1986, pp. 142-146. .
Goering, R., "Apollo Entry Fuels CAE/CAD Workstation Battle", Computer Design, Mar. 1, 1986, pp. 26-27. .
"Copydisk", Xerox Corp., Palo Alto, 1980. .
Rose, C.D., "Apollo Fights Back with New Work Stations", Electronics, Feb. 24, 1986, pp. 20-21. .
Mace, S. and Sorenson, K., "Amiga, Atari Ready PC Emulators", InfoWorld, vol. 8, No. 18, May 5, 1986. .
"IBM, Introduces High-Speed, Personal or Multi-User Workstations with New Technology for Technical Professionals", Business Wire, Inc., Jan. 21, 1986. .
8010 Star Information System Reference Library, 5.0 Update, Xerox Corporation, 1984, pp. 119-188. .
"M8.0 Operating System Sofware Bulletin", Xerox Corporation. .
Seawright, L. H. and Mackinnon, R. A., "VM/370--A Study of Multiplicity and Usefulness", IBM Syst. J., vol. 18, No. 1, 1979, pp. 4-17. .
Deitel, H. M., An Introduction to Operating Systems, Addison-Wesley, Reading, Mass., 1984, pp. 601-629. .
Madnick, S. E. , and Donovan J. J., Operating Systems, McGraw-Hill, New York, 1974, pp. 549-563. .
Smith, D. C., Irby, C., Kimball, R., and Harslem, E., "The Star User Interface: An Overview", AFIPS 1982 National Computer Conference Proceddings. .
Hall, D. E., Scherrer, D. K., and Sventek, J. S., "A Virtual Operating System", Communications of the ACM, vol. 23, No. 9, Sep. 1980, pp. 495-502..~
Primary Examiner:
Lee; Thomas C.
Assistant Examiner:
Donaghue; Larry
Attorney, Agent or Firm:
Beran; James T.
Parent Case Text
This is a continuation of application Ser. No. 06/856,526, filed Apr. 28, 1986, now abandoned.
Claims
What is claimed:
1. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation and for receiving output signals from the central processor while performing the target system I/O operation, the target system further including communication means for communicating the output signals from the central processor to the target system I/O device; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, one of the signals being a target I/O output signal that is one of the output signals received by the target system I/O device while performing the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising I/O monitoring circuitry for detecting the target I/O output signal and for obtaining monitoring data relating to the target system I/O operation;
the environment means further comprising I/O device data from which the environment means can determine a current emulated state of the communication means;
the environment means further comprising device emulating means for emulating the target system I/O operation by using the I/O device data to determine the current emulated state of the communication means; the device emulating means accessing the I/O device data based on the monitoring data in response to the target I/O output signal;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
2. The system of claim 1 in which the monitoring data include control data indicating an input operation, the device emulating means retrieving the control data and providing input signals to the emulating processor based on the I/O device data if the control data indicate an input operation.
3. The system of claim 1 in which the monitoring data include address data indicating a type of I/O operation, the I/O device data including respective data for the indicated type of I/O operation, the device emulating means retrieving the address data and emulating the type of I/O operation based on the respective data for the indicated type of I/O operation.
4. The system of claim 1 in which the target I/O output signal includes an address indicating a suboperation performed by the target system I/O device while performing the target system I/O operation; the I/O device data including respective data for the indicated suboperation; the monitoring data obtained by the I/O monitoring circuitry including the address; the device emulating means emulating the target system I/O operation by accessing the respective data for the indicated suboperation and emulating the target system I/O device in response to the monitoring data that includes the address.
5. The system of claim 4 in which the device emulating means further identifies the suboperation performed by the target system I/O device from the address included in the monitoring data.
6. The system of claim 4 in which the target I/O output signal includes status data indicating whether the suboperation performed by the target system I/O device is an input I/O operation, the monitoring data obtained by the I/O monitoring circuitry including the status data; the environment means further being for determining whether the status data included in the monitoring data indicates that the suboperation performed by the target system I/O device is an input I/O operation and, if so, for providing input data to the emulating processor.
7. The system of claim 6 in which the environment means further stops operation of the emulating processor whenever the status data included in the monitoring data indicates that an input I/O operation is requested and permits the emulating processor to resume operation after the requested I/O operation has been emulated, the emulating processor executing a routine for retrieving the input data when it resumes operation.
8. The system of claim 1 which the target I/O output signal includes an indication of whether the target system I/O device performs an input operation while performing the target system I/O operation, the I/O monitoring circuitry further obtaining form the target I/O output signal a read signal indicating whether the target system I/O device performs the input operation.
9. The system of claim 8 in which the I/O monitoring circuitry is further connected for providing an interrupt to the emulating processor, the I/O monitoring circuitry providing the interrupt if the read signal indicates the target system I/O device performs the input operation.
10. The system of claim 9 in which the emulating processor has a non-maskable interrupt input line, the I/O monitoring circuitry being connected to provide the interrupt on the non-maskable interrupt input line.
11. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation and for receiving output signals from the central processor while performing the target system I/O operation, the target system further including communication means for communicating the output signals from the central processor to the target system I/O device; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals provided by the emulating processor including a target I/O output signal that is one of the output signals received by the target system I/O device while performing the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising a corresponding I/O device corresponding in function to the target system I/O device;
the environment means further comprising I/O device data from which the environment means can determine a current emulated state of the communication means;
the environment means further comprising device emulating means for emulating the target system I/O operation in response to the target I/O output signal by using the host processor and the corresponding I/O device and by using the I/O device data to determine the current emulated state of the communication means, the device emulating means accessing the I/O device data in response to the target I/O output signal;
the I/O device data comprising a data structure for transferring data between the emulating processor and the host processor during emulation of the target system I/O operation;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions; the host processor being connected for accessing the data structure; the sequence of the host system instructions including an operation accessing the data structure.
12. The system of claim 11 in which the corresponding I/O device is a printer controller, the data structure being a multi-character printer buffer for transferring characters to the printer controller, the device emulating means further managing the printer buffer to generate input signals for the emulating processor reflecting the status of the buffer.
13. The system of claim 11 in which the corresponding I/O device is a keyboard controller, the data structure being a multi-character keyboard buffer for transferring codes from the keyboard controller, the device emulating means further interrupting the emulating processor when the buffer contains at least one code.
14. The system of claim 11 which the corresponding I/O device is a display controller, the host system comprising a bitmap memory loaded by the host processor and read by the display controller, the data structure being for transferring display parameters to the display controller, the device emulating means further requesting the host processor to load display update information into the bitmap memory.
15. The system of claim 11 in which the device emulating means loads the data structure based on data received from the emulating processor in order to transfer the loaded data to the host processor and unloads from the data structure data received from the host processor in order to transfer the unloaded data to the emulating processor.
16. The system of claim 11 in which the target I/O operation signal includes status data indicating whether the suboperation performed by the target system I/O device is an input operation or an output operation, the monitoring data obtained by the I/O monitoring circuitry including the status data; the corresponding I/O device being equivalent to the target system I/O device, the device emulating means further providing output data from the data structure to the corresponding I/O device when the status data indicates the requested operation is an output operation and retrieving input data from the corresponding I/O device when the status data indicates the requested operation is an input operation.
17. The system of claim 16 in which the target system I/O device is a floppy disk controller, the data structure including a data block for holding the input data to transfer floppy operation parameters to the floppy disk controller and for holding the output data to transfer floppy operation results to the emulating processor.
18. The system of claim 11 in which the environment means further comprises memory for storing the data structure, the environment means further comprising an input/output processor connected for accessing the data structure in the memory to transfer data between the emulating processor and the host processor; the device emulating means operating the input/output processor to transfer data between the emulating processor and the host processor during emulation of the target system I/O operation.
19. The system of claim 18 in which the device emulating means further operates the input/output processor to load data from the emulating processor into the data structure and retrieve the loaded data from the data structure for transfer to the corresponding I/O device.
20. The system of claim 18 in which device emulating means operates the host processor to perform the host operation during emulation of the target system I/O operation; the host processor operation providing a host I/O operation signal requesting an I/O operation and providing data from the data structure with the host I/O operation signal, the input/output processor further transferring the data provided with the host I/O operation signal to the corresponding I/O device.
21. The system of claim 20 in which the target I/O output signal includes output data, the device emulating means further operating the input/output processor to receive the output data, load the output data into the data structure, and receive the host I/O operation signal from the host processor.
22. A system for emulating a target system having a central processor for executing a set of target system instructions, the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions, the host processor providing a host I/O operation signal requesting an I/O operation during execution of the host system instructions; the host system further comprising a set of I/O devices; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing an emulator I/O operation signal requesting an I/O operation during execution of the sequence of target system instructions;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions; the environment means comprising an input/output processor for responding to the host I/O operation signal and the emulator I/O operation signal by controlling the set of I/O devices to perform requested I/O operations for the emulating processor and the host processor;
the input/output processor further being for stopping the emulating processor while the I/O devices perform the requested I/O operation in response to the emulator I/O operation signal;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
23. The system of claim 22 in which the target system includes a set of I/O devices and the environment means comprises a memory accessible to the input/output processor and to the emulating processor, the emulator I/O operation signal being a request for one of the target system I/O devices; the input/output processor responding to the emulator I/O operation signal by emulating the one target system I/O device to obtain a result and by loading the result into the memory so that the emulating processor can retrieve the result and continue to execute the sequence of target system instructions.
24. The system of claim 22 in which the environment means further comprises a bus shared by the input/output processor and the emulating processor, the environment means further comprising means for controlling which of the input/output processor and the emulating processor has control of the bus, the controlling means giving control of the bus to the emulating processor only after the input/output processor signals the controlling means to allow emulating processor control.
25. The system of claim 24 in which the host system further comprises memory having a part accessible to the input/output processor through the bus and a part accessible to the emulating processor through the bus, the input/output processor and the emulating processor each providing an address on the bus while accessing the respective part of the memory, the environment means further comprising mapping means for determining which of the input/output processor and the emulating processor is accessing memory and for mapping the address on the shared bus into the part of memory accessible to that processor.
26. The system of claim 25 in which the mapping means comprises mapping registers for providing information for mapping the address into the respective part of memory accessible to the processor accessing memory, the mapping register being accessible only to the input/out processor so that the emulating processor cannot change the part of memory which is accessible to it.
27. The system of claim 25 in which the part of memory accessible to the emulating processor is also accessible to the host processor, the mapping means further being for ensuring that the operations of the host processor in executing a sequence of host system instructions are not altered by the operations of the emulating processor in accessing memory.
28. The system of claim 25 in which the part of memory accessible to the input/output processor and the part of memory accessible to the emulating processor share an overlapping area of memory, the input/output processor and the emulating processor using the overlapping area of memory to transfer information to each other.
29. The system of claim 28 in which the set of I/O devices includes a rigid disk controller, the overlapping area of memory including a register block; the input/output processor using the register block to transfer rigid disk operation results to the emulating processor, the emulating processor executing a loading routine for loading the register block and an unloading routine for unloading the register block.
30. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation, the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals provided by the emulating processor including a target I/O operation signal requesting the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions; the environment means comprising a corresponding I/O device corresponding in function to the target system I/O device; the environment means emulating the target system I/O operation in response to the target I/O operation signal by using the corresponding I/O device, the environment means further comprising a data structure for transferring data between the emulating processor and the corresponding I/O device during emulation of the target system I/O operation;
the environment means further comprising memory for storing the data structure, the environment means further comprising an input/output processor connected for accessing the data structure in the memory to transfer data between the emulating processor and the corresponding I/O device during emulation of the target system I/O operation;
the corresponding I/O device providing data for transfer to the emulating processor during emulation of the target system I/O operation, the host processor being connected for accessing the data structure in the memory, the host processor further loading the data provided by the corresponding I/O device into the data structure for transfer to the emulating processor;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
31. The system of claim 30 in which the input/output processor further provides the data from the corresponding I/O device to the host processor, retrieves the data loaded by the host processor from the data structure and provides the retrieved data to the emulating processor.
32. A data processing system for emulating a target data processing system having a central processor for executing a set of target system instructions, the central processor providing I/O operation requests to a set of target system I/O devices while executing a sequence of the target system instructions, the target system further including communication means for communicating I/O operation requests from the central processor to a first one of the target system I/O devices; the emulating data processing system comprising:
a host system having a host processor for executing a set of host system instructions and a set of host system I/O devices, the host processor providing I/O operation requests requesting operations of the host system I/O devices while executing a sequence of the host system instructions; and
an emulating processor for executing a sequence of the target system instructions, the emulating processor providing I/O operation requests to the host system during execution of the target system instructions, a first one of the I/O operation requests being one of the I/O operation requests provided by the target system central processor to the set of target system I/O devices;
the host system further comprising input/output means for receiving the I/O operation requests from the host processor and from the emulating processor and for handling the I/O operation requests using the host system I/O devices so that the host processor continues to execute the sequence of host system instructions while the emulating processor executes the sequence of target system instructions;
the input/output means comprising I/O monitoring circuitry for detecting the first I/O operation request from the emulating processor and for obtaining monitoring data relating to the requested I/O operation;
the input/output means further comprising I/O device data from which the input/output means can determine a current emulated state of the communication means;
the input/output means further comprising device emulating means for emulating the first target system I/O device by using the I/O device data to determine the current emulated state of the communication means; the device emulating means accessing the I/O device data based on the monitoring data.
33. The system of claim 32 in which the input/output means further comprises an input/output processor, the device emulating means operating the input/output processor to emulate the first target system I/O device so that the emulating processor continues to execute the sequence of target system instructions.
34. A data processing system for emulating a target data processing system having a central processor for executing a set of target system instructions and target interface means for providing external transfer of signals in a manner characteristic of the target system in response to the central processor, the emulating data processing system comprising:
a host system having host interface means for providing external transfer of signals and a host processor for controlling the host interface means to provide external transfer of signals in a manner characteristic of the host system and different from the manner characteristic of the target system; the host interface means comprising a user interface for transferring signals between a user and the host system, the host processor controlling the user interface so that the signals are transferred in a manner characteristic of the host system user interface while simultaneously being transferred in a manner characteristic of a target system user interface; the user interface comprising a display controlled by the host processor; and
an emulating processor for executing a sequence of the target system instructions, the emulating processor providing output signals and receiving input signals during execution of the target system instructions;
the host system receiving output signals from the emulating processor and providing input signals to that the emulating processor continues to execute the sequence target system instructions; the host processor controlling the host interface means in response to the output signals to provide external transfer of signals in a manner characteristic of the host system while simultaneously providing external transfer of signals in a manner characteristic of the target system; the host processor controlling the display so that the signals provided by the display to the user provide the appearance of a display characteristic of the host system while simultaneously providing within that display a display characteristic of the target system; the display characteristic of the host system including a set of windows; the host processor controlling the display to provide the display characteristic of the target system in one of the windows in the display characteristic of the host system.
35. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation, the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, one of the signals being a target I/O operation signal requesting the target system I/O operation; the target I/O operation signal including an indication of whether the requested I/O operation is an input operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising I/O monitoring circuitry for detecting the target I/O operation signal and for obtaining monitoring data relating to the target system I/O operation; the I/O monitoring circuitry further obtaining from the target I/O operation signal a read signal indicating whether the requested I/O operation is an input operation; the environment means emulating the target system I/O operation based on the monitoring data in response to the target I/O operation signal; the I/O monitoring circuitry further being connected for providing an interrupt to the emulating processor if the read signal indicates the requested I/O operation is an input operation;
the environment means further being connected to hold and release the emulating processor, the environment means holding the emulating processor upon completion of execution of one of the sequence of target system instructions during which the target I/O operation signal was provided and then releasing the emulating processor after loading input data for the emulating processor, the emulating processor responding to the interrupt when the environment means releases it by retrieving the input data and using the retrieved input data to correct erroneous data resulting from the completion of execution of the target system instruction;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
36. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the set of target system devices including a target system memory and target system I/O devices; the target system further including communication means for communicating signals from the central processor to a first one of the target system I/O devices; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals including memory access signals and I/O operation signals; each memory access signal requesting access to the target system memory; each I/O operation signal requesting a respective I/O operation of the target system I/O devices;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising I/O device data from which the environment means can determine a current emulated state of the communication means;
the environment means further being for receiving a first one of the signals from the emulating processor; the environment means further comprising device emulating means for emulating an I/O operation of the first target system device if the first signal is one of the I/O operation signals requesting an I/O operation of the first target system device; the device emulating means accessing the I/O device data in response to the first signal and using the I/O device data to determine the current emulated state of the communication means;
the environment means further comprising memory; the memory being accessed in response to the first signal if the first signal is one of the memory access signals;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions; the host processor accessing the memory in executing the sequence of the host system instructions.
37. The system of claim 36 in which the memory includes a part that is accessible to the emulating processor, the environment means further being for mapping the first signal into the part of memory accessible to the emulating processor if the first signal is one of the memory access signals, the environment means further being for ensuring that the operations of the host processor in executing the sequence of the host system instructions are not altered by the operations of the emulating processor in accessing memory.
38. The system of claim 36 in which the host system further comprises interface means for providing external transfer of signals, the host processor accessing the memory to retrieve data stored by the emulating processor and controlling the interface means based on the retrieved data.
39. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation, the target system further including communication means for communicating signals requesting the target system I/O operation from the central processor to the target system I/O device; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals provided by the emulating processor including a target I/O operation signal requesting the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising an equivalent I/O device to the target system I/O device;
the environment means further comprising means for simulating the equivalent I/O device;
the environment means further comprising I/O device data from which the environment means can determine a current emulated state of the communication means;
the environment means further comprising device emulating means for emulating the target system I/O operation in response to the target I/O operation signal by using the I/O device data to determine the current emulated state of the communication means, the device emulating means accessing the I/O device data in response to the target I/O operation signal; the device emulating means determining in response to the target I/O operation signal whether to emulate the target system I/O operation by using the equivalent I/O device or by using the simulating means;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
40. The system of claim 39 in which the environment means comprises a memory and the target system I/O device is a controller for a memory medium, the environment means further managing a part of the memory to be accessible as if it were the memory medium, the simulating means simulating the equivalent I/O device by accessing the managed part of memory.
41. The system of claim 40 in which the target system I/O device is a floppy disk controller; the environment means managing the part of the memory to be accessible as if it were a floppy disk.
42. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system I/O devices that provides an environment for the central processor; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals including an I/O operation signal requesting an I/O operation of the target system I/O devices;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means further being for receiving the I/O operation signal from the emulating processor and for emulating the respective I/O operation of the target system devices in response to the I/O operation signal; the environment means further stopping the emulating processor while emulating the respective I/O operation in response to the I/O operation signal;
the environment means further comprising a memory accessible to the emulating processor; if the requested I/O operation is an I/O input operation, the environment means further being for loading input data into the memory while the emulating processor is stopped;
the environment means further being for permitting the emulating processor to resume operation after the requested I/O operation has been emulated;
the emulating processor further being for retrieving the input data from the memory when it resumes operation;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
43. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the set of target system devices including a target system memory and target system I/O devices; the target system further including communication means for communicating signals from the central processor to a first one of the target system I/O devices; the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals including memory access signals and I/O operation signals; each memory access signal requesting access to the target system memory; each I/O operation signal requesting a respective I/O operation of the target system I/O devices;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising I/O device data from which the environment means can determine a current emulated state of the communication means;
the environment means further being for receiving a fist one of the signals from the emulating processor; the environment means further comprising device emulating means for emulating an I/O operation of the first target system device if the first signal is one of the I/O operation signals requesting an I/O operation of the first target system device; the device emulating means accessing the I/O device data in response to the first signal and using the I/O device data to determine the current emulated state of the communication means;
the environment means further comprising memory; the memory being accessed in response to the first signal if the first signal is one of the memory access signals; the memory being accessed in response to the first signal so that the emulating processor continues to execute the sequence of the target system instructions as if it were the central processor of the target system;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
44. The system of claim 43 in which the first signal includes a memory address if the first signal is one of the memory access signals; the environment means further comprising mapping circuitry for receiving the first signal if the first signal is one of the memory access signals and for mapping the memory address in the first signal to a corresponding location in the memory so that the corresponding location is accessed in response to the first signal.
45. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation, the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals provided by the emulating processor including a target I/O operation signal requesting the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions; the environment means comprising a printer controller corresponding in function to the target system I/O device; the environment means emulating the target system I/O operation in response to the target I/O operation signal by using the printer controller, the environment means further comprising a multi-character printer buffer for transferring characters from the emulating processor to the printer controller during emulation of the target system I/O operation; the environment means further managing the printer buffer to generate input signals for the emulating processor reflecting the status of the buffer;
the environment means further comprising a memory, the host processor being connected for storing a series of characters from the printer buffer in the memory for subsequent printing, the environment means determining whether to provide the characters from the buffer to the printer controller or to store the characters for subsequent printing;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
46. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation, the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, the signals provided by the emulating processor including a target I/O operation signal requesting the target system I/O operation;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions; the environment means comprising a printer controller corresponding in function to the target system I/O device; the environment means emulating the target system I/O operation in response to the target I/O operation signal by using the keyboard controller, the environment means further comprising a multi-character printer buffer for transferring characters from the keyboard controller to the emulating processor during emulation of the target system I/O operation; the environment means further interrupting the emulating processor when the keyboard buffer contains at least one code;
the emulating processor executing an instruction causing it to provide an overflow signal if an input keyboard buffer under its control cannot accept a code from the multi-character keyboard buffer, the environment means further providing the code which could not be accepted to the emulating processor again in response to the overflow signal;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
47. A system for emulating a target system having a central processor for executing a set of target system instructions and a set of target system devices that provides an environment for the central processor, the target system devices including a target system I/O device for performing a target system I/O operation the emulating system comprising:
a host system having a host processor for executing a set of host system instructions different from the target system instructions; and
an emulating processor for executing a sequence of the target system instructions; the emulating processor providing signals during execution of the sequence of target system instructions, one of the signals being a target I/O operation signal requesting the target system I/O operation; the target I/O operation signal includes an address corresponding to the target system I/O device;
the host system further comprising environment means connected for providing an environment for the emulating processor so that the emulating processor continues to execute the sequence of target system instructions and connected for providing an environment for the host processor so that the host processor executes the host system instructions;
the environment means comprising I/O monitoring circuitry for detecting the target I/O operation signal and for obtaining monitoring data relating to the target system I/O operation; the monitoring data obtained by the I/O monitoring circuitry including the address; the environment means emulating the target system I/O operation in response to the target I/O operation signal by emulating the target system I/O device based on the address in the monitoring data;
the environment means further comprising a memory storing an I/O operating system for enabling the emulating processor to execute the sequence of target system instructions and for causing the emulating processor to provide at least one non-target I/O operation signal not provided by the target system central processor, the non-target I/O operation signal requesting a non-target I/O operation that is not performed in the target system but that relates to emulation of the target system I/O operation; the I/O monitoring circuitry further being for detecting the non-target I/O operation signal and for obtaining monitoring data relating to the non-target I/O operation; the environment means further performing the non-target I/O operation in response to the non-target I/O operation signal based on the monitoring data;
the host processor independently executing a sequence of the host system instructions while the emulating processor executes the sequence of target system instructions.
Description
BACKGROUND OF THE INVENTION
The present invention relates to the emulation of one data processing system by another. More specifically, the present invention relates to the modification of a host data processing system to emulate another, dissimilar target system with a central processor (CPU) which is capable of executing a set of instructions different than those executable by the host system's CPU.
Many techniques for emulating a target data processing system are known. Such a technique may alternatively be described as a simulation of the target system, as making another system compatible with the target system, or as providing the target system as a virtual machine on a host system. U.S. Pat. No. 4,253,145 contains a helpful discussion of virtual machines in the prior art, most of which simulate mainframe computers so that programs written for the simulated computer can be run on the virtual machine.
In recent years, a vast amount of software has been written for a microprocessor-based data processing system called the IBM PC or IBM PC XT ("PC"), produced by International Business Machines Corporation. In order to make their products more useful, many manufacturers have developed systems which are either equivalent to the PC or can be made to operate in an equivalent manner by the use of software. Hardware and software technology have progressed rapidly, however, so that systems far more powerful than the PC can be produced for roughly the same cost. To devote such a system to the running of PC software is to sacrifice capabilities it could otherwise have. Therefore, it would be useful to have a technique for modifying one of these more powerful systems so that it could run software written for the PC without limiting its other capabilities.
SUMMARY OF THE INVENTION
The present invention provides techniques for modifying a system so that it can run PC software while retaining its own characteristic capabilities. For example, the present invention makes it possible for a host system capable of displaying more information than a PC to display within its own characteristic display all the information a PC would provide on its display, making that information available for manipulation by an operator using the features of the more powerful host system. Furthermore, the present invention makes it possible to execute PC software in such a manner that if the PC software cannot be executed, and therefore results in a crash, the host system will be protected and will continue to operate with full capabilities.
The present invention combines a host system with an emulating processor which is capable of running software written for a target system. The emulating processor is added so as not to prevent the host system CPU from performing its own independent operations while the emulating processor is operating, even though the two processors have different instruction sets. Also, the host system can provide an external interface which includes the features of an external interface of the target system while retaining those of the host system. For example, the host system can provide a display which includes the target system display but retains the display features of the host system.
The emulating processor is thus added in a manner which protects the host system CPU from crashes in the target system software, since the host system CPU is not executing the software which leads to the crash and may continue with its independent operation. Rather than being surrounded by the devices found in the target system, the emulating processor provides its output signals to the host system and receives input signals from the host system. Those input signals from the host system enable the emulating processor to continue to run target system software. The host system continues to operate as an independent system while supporting emulation of the environment which the emulating processor would have if it were the central processor of the target system. The host system CPU can therefore continue to operate independently with its own capabilities despite failure of the emulating processor due to defective or malicious software.
A number of previous techniques have made use of more than one processor in operations resembling emulation. None of the known techniques, however, combines a host system with an emulating processor which executes a different instruction set while the host system processor continues its independent operation. Similarly, none of the known techniques combines a host system with an emulating processor so that the host system interface for providing external transfer of signals operates in a manner characteristic of the host system while simultaneously operating in a different manner characteristic of a target system being emulated.
U.S. Pat. No. 4,564,903, for example, illustrates a technique for using more than one processor in a virtual machine system, with each of several multiprocessors executing as a virtual machine, and an I/O processor providing a channel between I/O devices and the main storage shared by the multiprocessors, the I/O processor servicing the I/O operations of the multiprocessors. U.S. Pat. No. 3,932,843 shows a similar technique in which two operational computers simulate the execution of a program on a target system for testing and development of the program, while a simulation computer simulates the peripheral equipment of the operational computers in response to their I/O operations.
It is also known to use a processor in a local terminal to access a remote computer, the display of the local terminal appearing as if it were a standard terminal of the remote computer. In this arrangement, there is no emulating processor, only the emulation of the display of the remote processor by the local terminal.
Techniques are also known in which a system is modified so that it can emulate another system by adding a board or card. These systems conventionally can operate only in one of the alternative modes at a time, however, so that an added processor is only able to perform emulation while the host system's CPU is either disabled from executing its own instructions or dedicated to servicing the I/O requests of the added processor, and therefore the host system's CPU cannot operate independently while the added processor is emulating. Furthermore, the display provides either the display of the host CPU or, if the added processor is operating, the display of the added processor, but not both at once. The host system capabilities are in effect sacrificed while the added processor is operating.
Although each of the above techniques uses more than one processor to perform emulation, none uses an emulating processor which executes a different instruction set than the host system CPU while the host system CPU continues to operate independently. Furthermore, none of the above techniques has an interface which, during emulation, provides at the same time the characteristic features of a host system interface and the characteristic features of a target system interface, which differ from the host system interface.
In emulation according to one aspect of the invention, a host system has a host processor which executes a sequence of host system instructions and performs its independent operations while an emulating processor executes a sequence of target system instructions. The host system instruction set differs from the target system instruction set. The host system receives output signals from the emulating processor and provides input signals so that the emulating processor continues executing.
The target system includes a set of devices which provides an environment, referred to as its processor environment, in which the target system's central processor executes. According to a further aspect of the invention, the host system provides an equivalent environment to the emulating processor by providing input signals to the emulating processor corresponding to the input signals provided by the target system devices and by accepting output signals from the emulating processor. The host system may include circuitry which monitors the emulating processor for an output requesting an I/O operation and provides an I/O signal. The host system may further include emulating means for emulating that target system device in response to the I/O signal. The independent operations of the host processor may include I/O operations making use of I/O devices which are also used to emulate the target system devices. A target system device which is a memory medium may be emulated using a host system file which can also be accessed by the emulating processor as a memory medium. This memory medium file may be used to transfer data under the control of one processor to the control of the other, by selecting a screen object providing access to the file, by indicating a destination such as an emulated I/O device used by the emulating processor to access that type of memory medium and by providing the file to the destination processor.
The target system and the host system each have an interface for external transfer of signals and a processor controlling that interface. The processor in each system controls its interface in a manner characteristic of that system and different from the other system. According to another aspect of the invention, while the emulating processor executes target system instructions, providing output signals to and receiving input signals from the host system, the host processor controls the host interface to provide a transfer of signals in a manner which is characteristic of the host system and is simultaneously characteristic of the target system.
The host system interface may, for example, include a user interface having a display screen. The display characteristic of the target system may appear in part of the host system display screen, included within the display characteristic of the host system. This makes it possible for information transferred to the user through the target system display part to be manipulated according to information transferred from the user in a manner characteristic of the host system.
These and other objects, features and advantages of the invention will become more apparent from the attached drawings together with the following description and the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a functional block diagram showing the major components of an emulating system according to the invention.
FIG. 2 is a is a schematic diagram illustrating emulation of the processor environment and user interface of a target system.
FIG. 3 is a flowchart showing basic steps in emulation of a target system's processor environment according to the invention.
FIG. 4 is a flowchart showing a general technique for main memory emulation by memory mapping according to the invention.
FIG. 5 is a flowchart showing a general technique for I/O device emulation according to the invention.
FIG. 6 is a flowchart showing a general technique for display emulation according to the invention.
FIG. 7 is a block diagram showing a host system architecture like that of the Xerox 6085.
FIG. 8 is a block diagram showing in more detail the IOP subsystem of FIG. 7, including the PC emulation option according to the invention.
FIGS. 9A and 9B are a generalized circuit diagram showing in greater detail the components of the IOP subsystem of FIG. 8.
FIG. 10 is a state diagram of the mode control operation of bus arbiter/mode control of FIGS. 9A and 9B.
FIG. 11 is a block diagram of the components of the PC emulation option of FIG. 8.
FIG. 12 is a block diagram of the display trapper of FIG. 11.
FIGS. 13A, 13B, and 13C are a detailed circuit diagram of the display trapper of FIG. 12.
FIG. 14 illustrates schematically the relation between the contents of the display trapper PROM of FIGS. 13A, 13B, and 13C and the regions of the PC display.
FIG. 15 is an information flow diagram showing the monitoring operation of the display trapper of FIG. 12.
FIG. 16 is an information flow diagram showing the operation of reading the contents of the display trapper of FIG. 12.
FIG. 17 is a block diagram showing the I/O trapper of FIG. 11 in relation to other components.
FIGS. 18A-18E show, respectively, the high byte address register, the low byte address register, the status register, the low byte data register and the high byte data register of the I/O trapper of FIG. 17.
FIG. 19 shows interrupt generating circuitry in the I/O trapper of FIG. 17.
FIG. 20 shows a decoder in the I/O trapper of FIG. 17.
FIG. 21 is an information flow diagram showing the operation of reading the contents of the I/O trapper of FIG. 17.
FIG. 22 is a block diagram showing the dedicated I/O devices of FIG. 11.
FIGS. 23A and 23B are a detailed circuit diagram showing the programmable interval timer and speaker port of FIG. 22.
FIG. 24 is a detailed circuit diagram showing driving circuitry which serves the speaker port of FIGS. 23A and 23B.
FIGS. 25A and 25B are a detailed circuit diagram showing the programmable interrupt controller of FIG. 22.
FIGS. 26A, 26B, and 26C are a detailed circuit diagram showing the PCE CPU of FIG. 11.
FIG. 27 is a detailed circuit diagram of phase locked loop circuitry which is part of the PC option of FIG. 11.
FIGS. 28A-28L are detailed circuit diagrams of various circuits in the PCE option of FIG. 11, including, respectively, a buffer bank for PCE CPU signals; a buffer bank for IOP signals; gated inverter banks; high byte address latch; low byte address latch; high byte address driver and data transceiver; low byte address driver; low byte data transceiver; high address bit drivers; a delay circuit with flip-flop; a PCE resetting an buffer enable delay circuit; and a delay element.
FIG. 29 is a detailed circuit diagram of ready signal circuitry.
FIG. 30 is a detailed circuit diagram of EPROM control signal circuitry.
FIG. 31 is a block diagram of the memory mapper of FIG. 11.
FIG. 32 is a block diagram showing the relationships between other components and the Dispatcher run on the IOP of FIG. 8 and which controls I/O device emulation.
FIG. 33 is a flowchart showing relevant features of the operating system of the IOP of FIG. 8.
FIG. 34 is a state and transition diagram for a task managed by the operating system of FIG. 8.
FIG. 35 is a block diagram showing communication between the IOP and Mesa CPU of FIG. 7.
FIG. 36 is a flowchart showing the downnotify task of the Dispatcher of FIG. 32.
FIG. 37 is a flowchart showing the interrupt task of the Dispatcher of FIG. 32.
FIG. 38 is a flowchart showing steps which typify the I/O device emulators of FIG. 32.
FIG. 39 is a flowchart showing the NMI correction routine by which the PCE CPU of FIG. 11 receives information from one of the device emulators.
FIG. 40 is a flowchart of the status operation of the IOP task within the printer emulator of FIG. 32.
FIG. 41 is a flowchart of the char operation of the printer emulator task.
FIG. 42 is a flowchart of the strobe operation of the printer emulator task.
FIG. 43 is a flowchart of steps taken by the Mesa CPU as part of the printer emulator of FIG. 32.
FIG. 44 is a flowchart of a procedure DMAController within the DMA emulator.
FIG. 45 is a flowchart of a procedure DMAPages within the DMA emulator.
FIG. 46 is a state and transition diagram for the floppy disk emulator of FIG. 32.
FIG. 47 is a flowchart of the floppy emulator IOP task.
FIG. 48 is a flowchart of the step of setting up the IOCB in the task of FIG. 47.
FIG. 49 is a flowchart of the routine Q and DQIOCB which is called within the floppy emulator task of FIG. 47.
FIG. 50 is a flowchart of the branch based on the emulator state in the task of FIG. 47.
FIG. 50A is a general flowchart showing functional steps by which a memory medium file such as a virtual floppy is created and managed.
FIG. 50B shows the contents of a virtual floppy.
FIG. 50C is a flowchart of the operations of an emulated floppy disk controller which accesses the virtual floppy of FIG. 50B.
FIG. 51 is a flowchart of an IOP task within the fixed or rigid disk emulator of FIG. 32.
FIG. 52 is a flowchart of steps taken by the Mesa CPU as part of the keyboard emulator of FIG. 32.
FIG. 53 is a flowchart of an IOP task within the keyboard emulator of FIG. 32.
FIG. 54 is a flowchart of an IOP procedure within the display controller emulator.
FIG. 55 is a flowchart of an IOP task which reads the display trapper contents according to FIG. 16 and helps emulate the PC user interface.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
I. General Features
The general features of the invention can be understood from FIGS. 1-6. FIGS. 1 and 2 show features of systems according to the invention, while FIGS. 3-6 show features of methods according to the invention.
FIG. 1 shows the basic functional blocks of a data processing system according to the invention. As noted above, the underlying problems is that modifying a system to emulate another system ("the target system") usually sacrifices some capabilities of the system being modified. This problem is particularly acute when the system being modified is much more powerful and versatile than the target system, so that valuable capabilities are lost during emulation. System 10 in FIG. 1, however, solves this problem by providing emulation without loss of capabilities.
The focus of emulation in system 10 is the emulating processor 12, which is capable of executing sequences of the same instructions which the central processor of the target system can execute. This means that if one of those sequences of instructions is presented to the emulating processor 12, it will perform operations which permit it to continue to execute that sequence until the sequence is completed. While executing, it will provide output signals and receive input signals.
If emulating processor 12 were in fact the central processor of the target system, it would be connected to a set of devices which would provide a processor environment, receiving its output signals and, in response, providing appropriate input signals to it. Therefore, even though emulating processor 12 is capable of executing sequences of the same instructions as the target system central processor, it must also be in an environment which is equivalent to the processor environment. The emulated environment 14 in FIG. 1 represents this environment, which is in effect an interface which receives output signals from and, in response, provides input signals to emulating processor 12 corresponding to the input signals which would be provided by the set of devices in the target system. As a result, emulating processor 12 can continue to execute the sequence of instructions as if it were the target system central processor.
Emulated environment 14, rather than being provided by a set of devices as in the target system, is provided by host system 16, the system which is modified for emulation. As discussed below in greater detail, host system 16 is modified by a combination of hardware and software to provide appropriate input signals in response to output signals from emulating processor 12. These modifications are made without sacrificing the capabilities of host system 16, but rather by supplementing its capabilities, so that the resulting system has more capabilities than host system 16 by itself.
FIG. 1 also shows input and output (I/O) devices 18 connected to host system 16. Emulation would be somewhat cumbersome, however, if the user were unable to treat host system 16 as if it were the target system being emulated. Therefore, an important additional feature of the invention is to emulate the target processor's user interface in a manner which does not sacrifice the capabilities of the host system 16.
FIG. 2 shows in more detail the emulated environment 14 and the I/O devices 18 which provide the emulated user interface, all supported by host system 16. The emulated environment 14 includes emulated terminal 22, with emulated keyboard 22a and emulated display monitor 22b. It would also be possible to include emulated mouse 22c as part of emulated terminal 22. Emulated environment 14 may also include emulated floppy disk drive 24, emulated fixed or rigid disk 26 and emulated printer 28. Emulated environment 14 further includes emulated main memory 30 and also includes a number of other emulated devices or components discussed below. Referring to each of these devices as "emulated" implies only that they appear to the emulating processor 12 as if an equivalent actual device were connected to it. System 10 may not in fact include a corresponding actual device, or the corresponding actual device may not in fact be involved in the operation of an emulated device. In other words, host system 16 is capable of providing input signals to emulating processor 12 in the same manner as any of the emulated devices were it present.
The actual I/O devices 18 also emulate the user interface of the target system in the manner illustrated in FIG. 2. Of particular importance is display 32, which may emulate the target system's display within a part 34 of its screen, referred to as a window. At the same time, display 32 may continue to provide the host system's display in the background around window 34, in window 36 and elsewhere on the screen. Keyboard 38, mouse 40 and floppy disk drive 42 emulate the target system user interface differently, by being operable in the conventional manner by host system 16, but with host system 16 converting input data from and output data to these devices as if they were the corresponding devices in the target system. In other words, host system 16 interprets keystrokes, mouse clicks and data read from a floppy as if they were coming respectively from the target system keyboard, mouse and floppy disk drive. Network or Ethernet connection 44 may also be provided, permitting access to remote printers or workstations. Local printer 46 could also be provided, and it may be fed data as if it were the target system printer. The rigid disk 48 also participates in user interface emulation by providing an emulated rigid disk and virtual floppy disks which the user may treat as if they were part of the target system.
The specific emulated devices and actual I/O devices shown in FIG. 2 are merely illustrative. These devices would be appropriate for emulation of an IBM PC by a Xerox 6085 workstation, but other devices could be provided for emulation of other target systems by other host systems. The basic principle of emulating the processor environment and the user interface is extremely useful for an emulation implemented according to the invention.
FIG. 3 is a flowchart showing basic functional steps in emulation of the emulating processor's environment according to the invention. In box 50, emulating processor 12, during execution of a sequence of target system instructions, outputs information, such as an address and a number of bits of status information, indicating a type of operation. The operation may be a memory access or an I/O device operation. This information is received by a part of host system 16 which then determines in box 52 whether the requested operation is an I/O device operation.
If the requested operation is not an I/O device operation, host system 16 permits or enables the memory access by emulating processor 12 to proceed, in box 54. Emulating processor 12 may read or write to its main memory which is mapped into the host system memory as discussed below.
If the test in box 52 determines that an I/O device operation was requested, the information output by emulating processor 12 is trapped or stored, including address, status and, if an output operation is requested, data information, in box 56. Then host system 16 services the I/O request by emulating the I/O device requested, in box 58, providing appropriate inputs to enable emulating processor 12 to continue to execute the sequence of instructions.
FIGS. 4 and 5 are generalized flowcharts showing in more detail how host system 16 performs some of the functions in FIG. 3. FIG. 4 shows how host system 16 may provide emulated main memory 30 during a memory access in box 54 in FIG. 3 and FIG.
5 shows how host system 16 may emulate an I/O device in emulated environment 14 while servicing an I/O request in box 58 in FIG. 3.
The main memory emulation technique of FIG. 4 permits host system 16 to allocate any appropriate part of memory to be the main memory for the emulating processor, while permitting host system 16 itself to also access that memory for its own purposes. In box 62, host system 16 receives an address from emulating processor 12. In box 64, host system 16 maps the address received according to an algorithm which is transparent to emulating processor 12. If emulating processor 12 calls for a read operation, as determined in box 66, host system 16 returns the data from the mapped address to emulating processor 12, as shown in box 68. But if a write operation is called for, host system 16 writes the data from emulating processor 12 to the mapped address in box 72. In box 74, concurrently with the above operations, another circuit in host system 16 receives the address and detects whether data is being written to a display bank in memory. If so, the updated display region is recorded. Subsequently, host system 16 retrieves the recorded information and updates the actual display, as discussed below in relation to FIG. 6.
FIG. 5 shows a technique for emulating an I/O device such as a floppy disk drive, keyboard, fixed disk drive, or printer. Host system 16 receives output I/O signals from emulating processor 12 in box 80, including address, status and, if an output I/O request, data, as mentioned above, and determines in box 82 to which I/O device the signals are directed. Then, in box 84, host system 16 calls a routine which emulates that device, making use of any appropriate resources actually available to host system 16, which may include a corresponding actual I/O device or dissimilar I/O devices. During the emulation routine, a test as in box 86 typically determines whether the I/O request is an output (OUT) or input (IN) request. An OUT request is typically handled by emulating the output operation, in box 88, while an IN request is typically handled by returning appropriate input signals in box 90. A number of specific emulation routines are discussed in greater detail below.
Emulating processor 12 typically accesses memory frequently, in order to retrieve its instructions and manipulate its data. I/O device operations are only requested occasionally, however, and emulating processor 12 typically operates so that the I/O device has more time in which to provide the responsive input signals. Therefore, the hardware and software implementation of memory emulation, as summarized in FIG. 4, is much different than I/O device emulation, summarized in FIG. 5, as is more fully described below.
We have already noted that the emulation of the target system's user interface is relatively straightforward for such devices as the keyboard and floppy disk drive. In each of these cases, it is basically necessary to convert or translate data into the form it would have if it had been generated or stored on the emulated device. The emulation of the display, however, is a special case, due to the problem of providing a display simultaneously having the characteristics of the target system display and the characteristics of the host system display. As with the more straightforward devices, it may be necessary to convert or translate the display update data from emulating processor 12, but it will also be necessary to integrate that data into a display with display data from host system 16.
FIG. 6 shows a technique according to the invention which solves this problem, enabling host system 16 to present a display characteristic of the host system which includes an emulated display characteristic of the target system based on data from emulating processor 12. This technique depends on information recorded in the step in box 74 in FIG. 4, in which a circuit in host system 16 records the region of the display which has been updated when emulating processor 12 writes data to its display bank in memory, which may be a character buffer or a bitmap memory. The technique of FIG. 6, however, is asynchronous with the step in box 74, even though it is performed by another part of host system 16.
In box 90, host system 16 determines whether any of the display regions have been updated based on the information recorded in box 74, if any. The record for each region may be a bit, referred to as a dirty bit, indicating when set that that region has been updated. If none of the dirty bits have been set, host system 16 waits for a time interval in box 94 before again performing the test in box 92. But if at least one dirty bit has been set, all of the dirty bits are retrieved and the record of dirty bits is cleared, in box 96. In box 98, another part of host system 16 is notified that the dirty bits have been retrieved, and proceeds to update a display object for the emulated display. In doing so, host system 16 will retrieve data from the emulating processor's display bank and will convert that data, if necessary, before loading it into the display object's data structure. The display object's data structure, however, is managed in much the same manner as other display object data structures in host system 16, so that even though its contents have the characteristics of a target system display, those contents appear within a display characteristic of the host system.
A display object data structure includes data which can be loaded into the host system bitmap memory by software running on the host system CPU, and which will then occupy only a part of the display, such as a window. The manner in which the data is loaded and the size and location of this window are determined by the software which loads the display object into the bitmap memory, preferably under control of the user. This elegant solution provides a display which can include both an emulated screen characteristic of the target system in a window and a background display including other windows and other display features characteristic of host system 16. This opens up the possibility of transferring data between the emulated screen and other windows under user control, a feature discussed in greater detail in coassigned U.S. patent application Ser. No. 856,525, now U.S. Pat. No. 4,899,136, incorporated herein by reference in its entirety.
The general features of the invention described above could be implemented in many ways with any of a multitude of different host systems emulating any of a multitude of target systems. The following detailed description shows more specifically how the Xerox 6085 system may be modified to emulate the IBM PC.
II. Host System Architecture
Implementation of the invention on a specific host system will depend heavily on that host system's architecture. Yet the invention could be implemented on any host system of suitable architecture and processing capabilities. The architecture of the host system must, of course, permit transfer of data as necessary between the emulating processor and the host system.
FIG. 7 shows the major subsystem of a system 100 with an architecture like the Xerox 6085. The main processor in system 100 is the Mesa processor 110, including Mesa CPU 112 and its control store 114. The Mesa processor 110 may be implemented in a number of ways, but is currently implemented as discrete components on a printed circuit board which, when running a microcoded Mesa emulator stored in control store 114, provides the architecture defined in the Mesa Processor Principles of Operation, Version 4.0, (May 1985) Xerox Corporation. Mesa processor architecture is further discussed in Johnsson, R. K. and Wick, J. D., An Overview of the Mesa Processor Architecture, Proc. of the Symposium on Architectural Support for Programming Languages and Operating Systems, Palo Alto, March 1982, also appearing in SIGARCH Computer Architecture News 10(2) and SIGPLAN Notices 17(4). Any suitable processor of comparable power could be used in place of Mesa processor 110 in system 100, and it may be preferable to implement Mesa CPU 112 on a single VLSI chip. Mesa processor 110 is connected by Mesa bus 116 to display/memory subsystem 120 and by an input/output processor (IOP)-Mesa interface 118 to the IOP subsystem 150.
Display/memory subsystem 120 includes memory controller 122 and display controller 124, each of which is connected to Mesa processor 110 by Mesa bus 116 and also to IOP subsystem 150 by IOP bus 140. These controllers are also currently implemented as components on printed circuit boards, but they may also each be implemented as a VLSI chip, with compatibility obtained by using the same chip for both controllers or by other appropriate means. Memory controller 122 controls main memory
126, determining which of several components, including Mesa processor 110 and IOP subsystem 150, currently has access to main memory 126 and providing memory refresh as necessary. Display controller 124 similarly controls access to display bank 128, which contains the bitmap memory, and reads from it to provide information for display on display monitor 130.
The subsystems described above remain substantially the same with or without the emulation feature of the present invention. As discussed below, Mesa CPU 112 executes some additional software during emulation. Parts of main memory 126 are used to store information to emulate the main memory of the emulating processor 12 and to emulate the devices which provide the processor environment, and it is helpful to have two sets of mapping registers in memory controller 122, as discussed below. Otherwise, the changes which must be made in system 100 to perform emulation according to the invention are in IOP subsystem 150.
FIG. 8 shows system 100 again, but with IOP subsystem 150 shown in greater detail. IOP bus 140 is the main data path through IOP subsystem 150. The components connected to it include controllers for a number of I/O devices, including floppy disk controller 142, connected to floppy disk drive 152; Ethernet controller 144 connected to Ethernet 154; rigid disk controller 146, connected to rigid disk drive 156; serial controller 148a, connected to receive signals from keyboard 158, including mouse signals; and serial controller 148b, connected to an RS232C port. The processor responsible for servicing these controllers is the I/O processor (IOP) 160, which may be an Intel 80186 microprocessor, as discussed below. IOP 160 also has access to RAM 162 and EPROM 164, which are connected to IOP bus 140. A bus arbiter/mode control, discussed below, arbitrates bus control requests from Ethernet controller 144, rigid disk controller 146 and IOP 160.
FIG. 8 shows PC Emulation (PCE) option 200 attached to IOP bus 140 in order to implement the present invention on system 100. PCE option 200 is preferably a discrete unit, such as a printed circuit board with attached components, so that it can be installed as an extension of IOP bus 140 without otherwise modifying the hardware of system 100. It may be necessary, however, that some components within IOP subsystem 150 and memory controller 122 be designed to accept PCE option 200. The emulating processor is within PCE 200, as discussed below.
FIGS. 9A and 9B show the IOP bus structure of FIG. 8 in more detail, with many of the same components being shown with like reference numerals and with part numbers. Rigid disk controller 146 is connected to bus 140 through DMA controller 146a and FIFO buffer 146b. Ethernet controller 144 is connected to Ethernet 154 through serial interface 154a. FIG. 9A also shows bus arbiter/mode control 170 connected to IOP 160 so that arbiter/mode control 170 can send a hold request to IOP 160, which can reply with a hold acknowledge signal. FIG. 10, discussed below, provides more details about the mode control feature of arbiter/mode control 170.
FIGS. 9A and 9B show a number of additional connections to bus 140, generally involving buffers, drivers or latches, all of which are referred to below as connectors. Connectors 165a connect IOP bus 140 to the part of IOP bus 140 on the backplane, to which PCE option 200 is also connected. Connectors 165b connect to RAM 162 and EPROM 164, discussed above. Connectors 165c connect the data bus to a number of components, including floppy disk controller 142 and serial controllers 148a and 148b, discussed above, and additional components discussed below. Connectors 165d connect to an expansion bus for connecting additional options to the IOP bus 140.
The components connected through connectors 165c also include timer 166a, interrupt controllers 166b, 166c and 166d and socket 166e. Timer 166a provides timing signals to other components, such as serial controllers 148a and 148b. Master interrupt controller 166b receives interrupt request signals from a number of devices, several of which, including Mesa CPU 112, provide their requests through slave interrupt controller 166c, which may in turn receive interrupt requests from expansion bus devices through slave interrupt controller 166d. PCE 200 provides its interrupts directly to master controller 166b as the lowest priority interrupts. When no higher priority interrupts are present, master controller 166b will provide an interrupt request to IOP 160, also received by arbiter/mode control 170 and will also provide the starting address of the routine for servicing that interrupt. The routine for servicing a PCE interrupt is discussed below. Socket 166e provides a connection which can be used for debugging by connecting to another system.
Additional components connected through connectors 165c include control register 167a, host address PROM 167b, EEPROM register 167c, EEPROM 167d, MP/CS interface 167e, reset register 168, input port 169a and socket 169b. Control register 167a receives signals from IOP 160 and provides appropriate control signals to a number of I/O devices, including the speaker and floppy disk drive. Host address PROM 167b holds the unique Ethernet address of system 10, and can be accessed by IOP 160. EEPROM register 167c drives a number of LEDs and holds data used in writing EEPROM 167d at the time system 10 is installed. EEPROM 167d stores the configuration information for system 10 which is read at boot, and, for example, will contain data indicating whether PCE option 200 is included in system 10 or not. MP/CS interface 167e is a connector to the Mesa CPU 112 and its control store 114, a RAM, making it possible for IOP 160 to send and receive signals with CPU 112 and to write control store 114 in order to load it during boot of system 10. Reset register 168 receives signals from IOP 160 and provides appropriate reset signals to a number of devices, including PCE 200, Mesa CPU 112 and most of the I/O device controllers. Input port
169 a is a port to a number of manual switches, permitting direct operator input for operation and testing of system 10. Socket 169b permits connection to bus 140 for debugging purposes.
Except as noted above, many of the components in FIGS. 9A and 9B do not relate directly to PCE 200. In addition to arbitrating requests from DMA controller 146a and Ethernet controller 144 for use of bus 140, however, arbiter/mode control 170
switches bus 140 between two modes, one in which IOP 160 has control and another in which a processor in PCE 200 has control. FIG. 10 shows a state diagram illustrating the mode control operation of arbiter/mode control 170. Circuitry to implement this state diagram could be implemented in many ways, including a circuit with discrete logic components or a dedicated VLSI chip.
In FIG. 10, IOP 160 has control of IOP bus 140 in state 180. This control is subject, however, to requests from DMA controller 146a and Ethernet controller 144 for use of bus 140, each of which may have priority over IOP 160. Such requests will therefore result in a hold request to IOP 160, and, when IOP 160 acknowledges the hold, the requesting controller will take control of the bus as needed. Upon completion of such operations, control will return to IOP 160, so that the mode control remains in box 180.
The only transition to another state from state 180 is transition 182, which occurs when IOP 160 sends a command to allow PCE 200 to have control of bus 140 at a time when no hold requests or interrupts to IOP 160 are pending. All other events follow the epsilon transition back to state 180, as shown. If IOP 160 sends the allow PCE command when an IOP interrupt or hold request is pending, this epsilon transition will be followed.
When transition 182 occurs, the mode control enters state 190, in which PCE 200 has control of bus 140. In this state, PCE 200 can access memory 126 through bus 140 and can proceed to execute a sequence of instructions until one of the transitions back to state 180 occurs. Transition 192 occurs whenever an interrupt is asserted to IOP 160, including an interrupt indicating that PCE 200 has requested an I/O operation. Similarly, transition 194 occurs whenever a hold request is made, such as on behalf of DMA controller 146a or Ethernet controller 144. PCE 200 does not originate hold requests. As long as neither an IOP interrupt or a hold request occurs, all events will follow the epsilon transition back to state 190, and PCE 200
will retain control of bus 140.
In effect, IOP 160 invites PCE 200 to use bus 140 at appropriate times as determined by IOP software. If no IOP interrupts or hold requests are pending when the invitation occurs, PCE 200 then takes control of IOP bus 140 and continue to operate until IOP 160 or another device asserts control or until PCE 200 requires I/O operations to be performed by IOP 160. In addition to performing mode control according to FIG. 10, arbiter/mode control 170 contains circuitry which, when a hold signal is sent to PCE 200 to cause it to relinquish control of bus 140, prevents other circuitry from taking over bus 140 until PCE 200 acknowledges the hold. Arbiter/mode control 170 contains additional circuitry, not shown, which arbitrates between requests from rigid disk controller 146, Ethernet controller 144 and IOP 160 and which ensures that when an interrupt occurs, IOP 160 services it. The arbitration circuitry may treat a hold acknowledge from PCE 200 substantially the same as a hold acknowledge from IOP 160.
The software modifications which accompany the addition of PCE option 200 are discussed in greater detail below, but first we turn to a discussion of the architecture of PCE option 200.
III. PCE Board Structure
PCE option 200 may conveniently be implemented as a separate board which may be added to system 10 by connecting it to IOP bus 140 on the backplane. FIG. 11 shows the major functional components of PCE option 200, including PCE CPU 210, an 80186
which operates as a coprocessor with IOP 160; PCE bus 220, which serves as the PCE board bus and which also serves as an extension of IOP bus 140 during memory transactions; display trapper 230; I/O trapper 250; and dedicated I/O devices 300.
FIG. 11 also shows how both IOP 160 and PCE CPU 210 are connected to system memory 126 through mapper 400, discussed below in relation to memory emulation. As will be seen, the mapper 400 connects each of the 80186 processors to its own respective section of memory based on the addresses provided by the respective processor. A set of mapping registers for each processor provides the high order bits for addressing that processor's section of memory.
Display trapper 230 and I/O trapper 250 monitor the operations of PCE CPU 210 for display updates and I/O operations, respectively. Upon detecting an I/O operation, I/O trapper stores or traps relevant PCE CPU 210 outputs and then signals IOP
160 with an interrupt. As discussed in greater detail below, IOP 160 takes control of IOP bus 140, retrieves the trapped data, and performs the appropriate operations to permit PCE CPU 210 to continue to execute a sequence of IBM PC instructions when it again has control of IOP bus 140. Display trapper 230, on the other hand, simply records the display regions which have been updated in the form of dirty bits, and IOP 160 asynchronously retrieves the dirty bits and requests a display update. Therefore display trapper 230 is substantially different than I/O trapper 250.
A. Display trapper
Display trapper 230 monitors the updating of display memory by PCE CPU 210 and records which area of the display was updated. FIG. 12 shows the major functional blocks within an embodiment of display trapper 230.
Address to register file map 232 receives an address from PCE CPU 210, and provides two outputs--an address output and a data output. The address output indicates which sector of the PCE display memory is being updated, while the data output indicates more precisely what part of that sector is updated by providing a bit corresponding to each part. If a part is updated, its bit is changed from 0 to 1, referring to as a "dirty bit".
Address multiplexer (MUX) 234 receives the address output from file map 232 and may also receive address outputs from IOP 160. In response to control signals from IOP 160 and PCE CPU 210, address MUX 234 provides the appropriate address at its output. Similarly, data MUX 236 receives the data output from file map 232 and also receives data output from dirty bit register file 238, and provides the appropriate data at its output in response to control signals from IOP 160 and PCE CPU 210.
Dirty bit register file 238 receives the address from address MUX 234 and the data from data MUX 236, together with control signals indicating whether to perform a read operation or to write the data received at the address received. As dirty bits are received from file map 232 through data MUX, they are stored in corresponding locations in register file 238 through a series of write operations, until IOP 160 reads them, at which time the locations read are cleared of all dirty bits. Master dirty bit store 240 contains a single bit indicating whether any dirty bits have been stored in any of the registers in register file 238. Latch 242 holds the outputs from register file 238 and master dirty bit store 240 for subsequent reading by IOP
160.
FIGS. 13A, 13B, and 13C show a circuit implementing the functional blocks of FIG. 12 according to the invention. As shown, file map 232 and address MUX 234 share a component, PROM 232a, which serves primarily to translate an eight bit display memory address from PCE CPU 210 into a four bit register file address and a dirty bit on one of four data lines. This translation can be understood more clearly from FIG. 14, showing part of the contents of PROM 232a and the relationship between the addresses and the display memory locations.
A standard IBM PC provides either monochrome or color/graphics display, and uses memory locations B0000-B3FFh (h meaning the preceding numbers are hexadecimal) as its monochrome display buffer and B8000-BBFFFh as its color/graphics bitmap memory. The emulator of the present invention may provide optionally monochrome or color display, and its display memory potentially includes memory locations B0000-BFFFFh, although not all of this memory is necessary to emulate the standard PC. The 16 bits for the four hex digits other than B are therefore sufficient to determine the location of a byte within the emulating processor's display memory. Only eight address bits are provided to PROM 232a, however, with the six lower-order bits being omitted and the two higher-order bits being handled separately to select one of four display memory buffers, as described below.
As can be seen from FIG. 14, each eight bit address provided to PROM 232a corresponds to a 32 character block, within which the omitted lower-order bits indicating a character. If any of those 32 locations is updated, the corresponding dirty bit will have a value of one in the four bits D3-D0 at the output of PROM 232a, and each dirty bit corresponds to five of the 32 character blocks or two lines of the display.
PROM 232a also serves as part of address MUX 234 because the values at its outputs D7-4 provide the lower four bits RAMADDR3-0 of a register file address. Since there are four dirty bit locations at each register file address in register file
238, and each dirty bit corresponds to two lines of the display, each four bit register file address corresponds to eight lines of the display, as shown in FIG. 14. These four bits are provided under control of a signal from PCE CPU 210, PCEDISPCS', which also controls buffer 234a, which provides the remaining four bits RAMADDR7-4 of the register file address as discussed below. PCEDISPCS' therefore causes an eight bit address RAMADDR7-0 to be provided to register file 238.
Buffer 234a provides RAMADDR7-4 based on PCEMCS3'-0', only one of which is on at a time. PCEMCS3'-0' are signals from PCE CPU 210 derived from the higher order bits A19-14 of a display memory address. PCE CPU 210, during boot, loads a special routine which is part of the implementation of the invention. This routine is executed so that, each time PCE CPU 210 writes to its display memory, one of PCEMCS3' -0' goes on to indicate which one of the four available banks of display memory is being accessed and, correspondingly, which of four banks of registers in register file 238 is addressed, the MCS2 bank being for monochrome display, the MCS0 bank being for color or graphics display, and the MCS1 and MCS3 banks being unused in emulating the standard PC. Each bank contains 16 registers, each register storing four dirty bits. RAMADDR3-0 indicate which register within a selected bank is addressed.
Address MUX 234 also includes buffer 234b and 2-to-4 bit decoder 234c which are selected by the signal IOP-DISPCS' as the source of the register file address when IOP 160 is reading register file 238. IOP 160 provides six address bits, the higher order pair of which are decoded to indicate which bank is addressed, the lower order bits indicating the register within that bank. Thus the function of address MUX is to select between the address provided by buffer 234b and decoder 234c, on the one hand, and the address provided by PROM 234a and buffer 234a on the other.
Data MUX 236 performs a different type of multiplexing, in which a respective one of OR gates 236a performs a logical OR operation on each of the data outputs of PROM 232a and the corresponding data output of register file 238. In effect, each previously set dirty bit will remain dirty, while new dirty bits will be added, until IOP 160 reads the register file 138. The results of the OR operations are stored in a bank of flip-flops 236b by the signal DELAYQ2', and flip-flops 236b are cleared by IOP-DISPCS' when IOP 160 reads register file 238. The Q outputs of flip-flops 236b are applied as data input to register files 238.
Register file 238 includes RAM 238a and circuitry for controlling its writing and reading. As discussed above, RAM 238a receives an address on lines RAMADDR7-0