WO1992001263A1 - Workgroup controller architecture for multiple display stations to be used with x windows - Google Patents
Workgroup controller architecture for multiple display stations to be used with x windows Download PDFInfo
- Publication number
- WO1992001263A1 WO1992001263A1 PCT/US1991/004696 US9104696W WO9201263A1 WO 1992001263 A1 WO1992001263 A1 WO 1992001263A1 US 9104696 W US9104696 W US 9104696W WO 9201263 A1 WO9201263 A1 WO 9201263A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- controller
- display
- window
- providing
- network
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
- G06F3/1423—Digital output to display device ; Cooperation and interconnection of the display device with other functional units controlling a plurality of local displays, e.g. CRT and flat panel display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
- G06F3/1454—Digital output to display device ; Cooperation and interconnection of the display device with other functional units involving copying of the display data of a local workstation or window to a remote workstation or window so that an actual copy of the data is displayed simultaneously on two or more displays, e.g. teledisplay
Definitions
- This invention relates to the architecture and design of an X Window display station; in particular, this invention relates to the architecture and design of a controller for controlling multiple X window display stations.
- the X Window system is a network-based graphics windowing system for display stations, including but not limited to terminals, workstations, and personal computers.
- the X Window display software (the “server") provides application programs (the “clients”) facilities to control the graphics displayed at the display station. These facilities are typically commands at a high level of abstraction, so that the programmers of the client application programs are provided a uniform interface independent of the specific implementation of the display station.
- the specification for the X window system hereinafter the "X Window standard,” was developed at MIT and has been widely adopted as an industry standard. A comprehensive description of the X Window standard may be found in "X Window System User's Guide", by Valerie Quercia and Tim O'Reilly, published by O'Reilly and Associates, and is hereby incorporated by reference in its entirety.
- An X Window display station consists of (i) a video display, (ii) a keyboard, (iii) a pointing device, commonly known as a "mouse", (iv) a connection to a host bus or a network of one or more host computers, and (v) the capabilities required of an X Window server, as required by the X Window standard.
- each X Window display station has a self-contained controller which controls that display station and only that display station. That conventional display station including its controller may be stand ⁇ alone, or may be integrated within the cabinet of one of 5 the host computer systems on the network.
- Figure shows a conventional X Window network. As shown in Figure 1, six conventional X Window display stations 100-105 are provided on an industry standard network, such as Ethernet, together with two host computer systems 110 and
- FIG. 10 111 Figure 1 illustrates two common configurations for providing X Window display stations.
- Display stations 100-104 are conventional X Window display stations each having its own controller module (controller modules 100c- 104c) communicating over the Ethernet network with devices
- controller module 111c which is integrated with the host computer 111.
- the integration of host computer 111 and controller module 111c may be effectuated 0 simply by host computer 111 and controller module 111c residing in the same cabinet, and communicating by a local host bus lllh.
- the conventional architecture requires one controller per display station. As is readily seen in Figure 1, 5 since resources are not shared among the display stations, each display station must have fully duplicated X window resources to implement X Window functionalities. Other resources, such as memory and disks, are also limited to that available locally at the X Window display station or 0 accessible on the network. Each display station is also required to have a complete communication link to the network. Such configurations are expensive and wasteful, since many of the duplicated resources are not used simultaneously on a network such as shown in Figure 1. 5 Another conventional architecture has the host computer CPU execute the server program for one or more display devices. This architecture degrades the performance of the host computer.
- an architecture of a single controller for an X Window system is provided.
- This controller controls multiple display stations (the "workgroup") , provides connectivity between any member of the workgroup and the network, and provides a X Window server for each display station in the workgroup to client application programs everywhere.
- the controller in accordance with the present invention may be stand-alone or integrated within the same cabinet of a host computer.
- a workgroup in accordance with the present invention may coexist ⁇ on the same network with other conventional X Window systems. Normally, a client application program will not be able to distinguish an X Window server of the workgroup controller from a conventional X Window server.
- Figure 1 shows X Window display stations 100-105 in the prior art connected to two host computer systems 110 and 111 on an Ethernet.
- Figure 2a shows Commercial X terminals 201-203 connected to a Z-controller 210c on an Ethernet network with conventional X Window display stations 204-206, in accordance with the present invention.
- Figure 2b shows a Commercial X terminal 200 sharing host resources 236-238 through a Z-controller 210c, in accordance with the present invention.
- Figure 3 shows Commercial X terminals 301-303 connected to a Z-node 311 on an ethernet network with conventional X window display stations 304-306, in accordance with the present invention.
- Figure 4a is a block diagram of a Z-controller 40, called "EISA Z16 Turbo Controller,” in accordance with the present invention.
- FIG. 4b is a block diagram of a Z-controller 41, called "AT/EISA Z8 Turbo Controller,” in accordance with the present invention.
- FIG. 4c is a block diagram of a Z-controller 42, called "EISA Z4 Controller,” in accordance with the present invention.
- Figure 4d is a block diagram of a custom circuit providing control function for the host bus, and the 16 MS-DOS window mapper.
- Figure 5 is a block diagram of a Z-node 50 in accordance with the present invention.
- FIG. 6 is a block diagram of a Commercial X terminal 60, in accordance with the present invention.
- Figure 7a is a block diagram showing software modules of a Commercial X terminal and a Z-controller, in accordance with the present invention.
- Figure 7b is a block diagram showing software modules of a Z-controller and a host computer, in accordance with the present invention.
- Embodiments of the present invention may be either integrated with a host computer or "stand-alone".
- the controller module of an embodiment of the present invention which is integrated with a host computer is referred to as a "Z-controller”
- the controller module of an embodiment of the present invention which is stand-alone is referred to as a "Z-node”.
- An X Window display station connected to a Z-controller or Z-node is referred to as a "Commercial X terminal”.
- the Commercial X terminals connected to a Z-controller or Z-node are collectively known as the Z-controller's or the Z-node's "workgroup.”
- network access is provided by the network communication facility in the host computer.
- the Z-node however, has its own network communication facility.
- FIG 2a shows three Commercial X terminals 201-203 controlled by a Z-controller 210c
- Z-controller 210c is integrated with host computer 210 on an Ethernet network to which conventional X Window display stations 204-206 are also connected. Since the Z-controller 210c is designed to provide an X server facility for each Commercial X terminal connected to it, the client application program running on a processor in the network, such as host computer 211, will not be able to distinguish the conventional X Window display stations from a Commercial X terminal connected to the Z17 controller 210c.
- the conventional X Window display stations 204 and 206 are respectively similar to the stand-alone display station 100 and the integrated display station 105 shown in Figure l.
- a Commercial X terminal such as Commercial X terminal 201
- a Commercial X terminal has neither a controller module providing X server functionalities nor direct access to the network.
- the Commercial X terminal 201 has merely, in the module labelled 201b, a frame buffer, circuities for frame buffer control, keyboard and mouse control, and a high speed link (called "x-Net") to the Z-controller.
- X server functionalities and network access facilities in Commercial X terminal 201 are provided by the Z-controller 210c and the host computer 210 respectively.
- a Commercial X terminal can be implemented without a high performance central processing unit (CPU) , its associated memory and network access facilities, resulting in enormous cost savings.
- the conventional X Window display station is typically equipped with 2-4 megabytes of main memory.
- each Commercial X terminal of a workgroup of sixteen shares 2-8 megabytes of Z-controller main memory and, when active, requires dedicated allocation of only 0.25-0.5 megabytes of Z- controller main memory.
- FIG. 2b shows in further detail host resource sharing using a Z-controller 210c.
- Z-controller 210c is
- the resources on host bus 219 are typically memory-mapped or 1/0 mapped to the host
- EISA Extended Industry Standard Architecture
- FIG. 25 all the resources on the host bus 219.
- other X Window display stations are shown on the Ethernet 235, including conventional X Window display stations 204- 206, and another Z-controller/Commercial X configuration 212.
- Figure 2b also shows on Ethernet 235 processors 213 -30 and 214 running client applications programs.
- the link between the Commercial X terminal 200 and the Z-controller 210c is provided by the point-to-point connection 220, which is one of the x-Net connections linking each Commercial X terminal in Z-controller 210c's workgroup to
- the x-Net may be implemented by any high speed (3-10 Mbits per second, for example) point-to-point communication link or a local area network. Indeed, The x-Net may itself be a Ethernet-like point-to-point local area network connecting each of the Commercial X terminals in the workgroup to the Z-controller. A lOBase-T twisted pair Ethernet, for example, is suitable for this application, while still avoiding the high cost of an attachment unit interface (AUI) coaxial Ethernet network. (A 10BASE-T Ethernet has a range of 100 meters, whereas a standard AUI Ethernet may effectively communicate over a coaxial cable distance of 0.5-1.5 kilometers). Typical information passed on the x-Net includes keyboard and pointing device input data, keyboard and audio control data, cursor positions and pattern data, configuration data, and frame buffer updates.
- Typical information passed on the x-Net includes keyboard and pointing device input data, keyboard and audio control data, cursor positions and pattern data, configuration data, and frame buffer updates.
- Figure 3 shows Commercial X terminals 301-303 connected to a Z-node 311, which is connected to an
- the Z-controller is a board or a set of boards capable of supporting 16-128 Commercial X terminals.
- the Z-controller resides in the cabinet of a host computer, and communicates with the host computer over a host bus.
- One implementation may have the Z-controller local memory mapped to the address space of the host computer.
- the host computer's resources such as memory, disk or network access, are made available through "virtual access" to the Z-controller, and, in turn, to each Commercial X terminal in the workgroup the Z-controller supports, such that each Commercial X terminal may be viewed, as compared to the resources found in a conventional X Window display station, as having virtually unlimited memory and disk resources.
- FIG 4a shows an embodiment of a Z-controller 40 called the "EISA Z16 Turbo".
- the Z-controller 40's main processor 400 is implemented by a reduced instruction set computer (RISC) type processor chip SPARC IU L64091, available from LSI Logic Corporation, although other high performance microprocessors may also be used.
- the processor 400 is supported by an integrated system controller 401 using a 11 SPARC ISC L64951 chip, which provides system control functions, such as cache management, memory mapping and peripheral control.
- system control functions such as cache management, memory mapping and peripheral control.
- the use of an integrated system controller chip is well known in the art.
- a memory cache comprising the cache data unit 402, cache tags unit 403 and cache logic unit 404 is provided.
- the design of a cache memory is also well-known in the art.
- On-board memory is provided by the electrically programmable read only memory (EPROM) 405, the dynamic random access memory (DRAM) 406, and electrically erasable and programmable read-only memory (EEPROM) 407.
- EPROM 405 contains the bootstrap firmware for Z-controller 40's operation, which is executed upon power-up or receipt of a reset signal.
- DRAM 406 provides the main memory for processor 400. Although shown as having four megabytes installed, the amount of installed memory may be more or less depending on the operating environment. Obviously, higher performance is generally achievable with more on-board memory.
- EEPROM 407 provides non-volatile storage for such data as user options, or configuration data for system initialization. In order to support graphical operations at the
- VRAM video random access memory
- the X Window system software running on processor 400 directs graphical operations on the video images in VRAM 409 before Z-controller 40 sends the updated image to the corresponding Commercial X terminal in the workgroup.
- One method of updating images on a Commercial X terminal is described in copending application entitled "Selective Content Synchronization of Multiple Image Buffers" by Jonathan D. Garman, Serial No. 07/551,594, filed July 10, 1990, assigned to Athenix Corporation, and is hereby incorporated by reference in its entirety.
- a graphics processor 408 using a TMS34010 graphics processor obtainable from Texas Instruments Corporation, is provided to improve graphics performance. As will be seen in other embodiments of the present invention, this graphics processor improves the overall performance of the Z-controller, but is not necessary for the operation of the Z-controller.
- MS-DOS processor 410 Also shown in this embodiment in Figure 4a is MS-DOS processor 410, provided to accommodate users who may want to run MS-DOS compatible application programs.
- MS-DOSTM 1 is a popular operating system running on IBM PCTM family personal computers
- This MS-DOS processor 410 is provided strictly for the user's convenience and is not necessary to practice the present invention.
- the MS-DOS processor 410 is the subject of copending application
- MS-DOS processor 410 may be implemented by a microprocessor, such as 386DX of the x86 microprocessor family, available from Intel Corporation.
- a Z-controller communicates over a host bus with the host computer to which it is integrated.
- controller 40 is provided bus controller module 411 to implement the interface to the host's EISA bus. Controller module 411 implements the EISA standard bus interface in addition to direct memory access (DMA) protocols, block update monitor controls, refresh control and MS-DOS window mapper. A block diagram for the controller module 411 is provided in Figure 4d.
- DMA direct memory access
- the bus control logic 470 implements the host bus control function for the Z- controller.
- DMA control logic 490 provides the control for DMA operations.
- the DMA control logic comprises a DMA address register 492, a DMA control module 493 which provides the DMA protocol signals, and DMA count register 491 which keeps count of the amount of data to be transferred.
- MS-DOS window mapper unit 480 which provides the mapping function between the MS- DOS processor's address space and the MS-DOS window's address space (in the frame buffer) .
- MS-DOS window mapper unit 480 comprises arithmetic logic units 482 and 484, row address offset table registers 481, column-per-row register 485, MS-DOS frame buffer starting address register 486, MS-DOS address input register 487, and data mapper 483.
- the method for providing the MS-DOS window mapping function is described in the above-incorporated copending application,entitled "Address Display Mapper for a Sharable MS-DOS processor.”
- the Z-controller 40 supports up to sixteen Commercial X terminals connected to its sixteen ports P1-P16. These sixteen ports are provided by two integrated multiport repeater 79C980 circuits 414 and 415, available from Advanced Micro Devices, Inc. Each circuit 414 or 415 is controlled by an Ethernet controller circuit 412 or 413, each implemented by a 79C900 circuit, also available from Advanced Micro Devices, Inc. The Ethernet controller circuits 414 and 415 are memory or I/O mapped onto the local address or data bus.
- FIG 4b shows an embodiment of a Z-controller 41 of the present invention, called "AT/EISA Z8 turbo controller".
- the Z-controller 41 of Figure 4b includes the RISC processor 400, integrated system controller 401, cache units 402-404, EPROM 405, DRAM 406, and EEPROM 407 as in Z-controller 40 of Figure 4a.
- Z-controller 41 also includes a MS-DOS processor 410 for the user's convenience.
- Z-controller 41 does not have the graphics processor 408, hence providing a lower level of performance than that attainable by Z-controller 40 of Figure 4a.
- the VRAM module 409 is controlled by the bus controller module 411.
- Z-controller 41 is a less expensive embodiment of the present invention suitable for a smaller workgroup. Accordingly, only eight Commercial X terminals are supported by Z-controller 41, rather than sixteen as in Z-controller 40 of Figure 4a.
- the eight ports P1-P8 are provided by integrated multiport repeater module 415 and controlled by Ethernet controller module 413.
- the integrated multiport module 415 and Ethernet controller module 413 are similar to the identically numbered modules of Z-controller 40 in Figure 4a.
- Figure 4c is another embodiment of the Z-controller in accordance with the present invention, called "EISA Z4 controller".
- Figure 4c shows Z-controller 42 supporting up to eight Commercial X terminals on ports P1-P8, as in Z-controller 41 in Figure 4b.
- Z-controller 42 does not have separate VRAM and DRAM modules.
- a static column random access memory (SCRAM) module 406 is provided.
- SCRAM memory array provides rapid sequential accesses to a "column" of data upon one initial access, i.e. a large number of data stored in consecutive addresses are provided one by one in consecutive address order in rapid succession without incurring the time cost Of initial access for- each of datum addressed, other than for the first datum.
- SCRAM module 406 memory access performance is increased.
- the main processor 400 manages the video random access memory implemented in SCRAM module 406.
- the Z-node replaces a Z-controller's host bus interface with an interface to the network, and supports from 64 to 128 Commercial X terminals. Because the Z-node provides network access facilities without intervention by a host computer, access to network resources are made even more efficient. Therefore, the Z-node is better suited than the Z-controller to exploit network resources, such as remote disk access and virtual memory paging facilities, to provide the Commercial X terminals with disk and memory facilities accessible on the network.
- FIG. 5 shows an embodiment Z-node 50 of a Z-node called the "Z node Turbo.”
- Z-node 50 is similar in implementation to the Z-controller 40, with the EISA bus interface being replaced by an Ethernet controller 416 providing access to the Ethernet network.
- Ethernet controller 416 is implemented by the controller chip 79C900 available from Advanced Micro Devices, Inc.
- Figure 5 also shows that Ethernet controller 416 is capable of interfacing with standard AUI Ethernet (10BASE5 of IEEE standard 802.3), with CheaperNet (10BASE2 of IEEE standard 802.3, also known as thinnet Ethernet coaxial cable) through transceiver 418, or with a 10BASE-T Ethernet network (10BASE-T of IEEE standard 802.3) through transceiver 417.
- a 10BASE-T Ethernet is discussed above in conjunction with x-Net implementation
- transceiver 418 is implemented by a 7996 transceiver
- transceiver 417 is implemented by a 79C98 transceiver. Both 7996 and 79C98 transceivers are available from Advanced Micro Devices Inc.
- FIG. 6 shows an embodiment of a Commercial X terminal 60 with up to four video displays 604a-604d, in accordance with the present invention.
- the Commercial X terminal is controlled by a relatively low cost microcontroller 600, such as a 80C31 controller available from Intel Corporation.
- the firmware for controller 600 is stored in EPROM 601.
- a relatively small main memory 602 is needed to support controller 601, such as the 8K bytes of static random access memory (SRAM) shown in Figure 6.
- EEPROM 603 allows non-volatile storage of information such as configuration data.
- Each display 604a-604d comprises a frame buffer 606 implemented by VRAMs. In Figure 6, the frame buffer 606 is shown to contain one megabits of information.
- the size of the frame buffer is determined by the resolution of the display.
- the control of the display is provided by logic module 605, which provides support for direct memory access (DMA) , hardware cursor, block update monitor, refresh control, mouse and keyboard controls.
- a shifter 607 provides a serial link for output of video data to the video display circuitry, controller 600 communicates on the x-Net through the Ethernet controller 608 and transceiver 609, to the Z-node or Z- controller to which Commercial X terminal 60 is connected.
- Each display station 604a-604d is also provided a display device, a mouse and a keyboard.
- the optional 604b-604d circuitry creates very low cost display/mouse/keyboard stations by sharing the common controller 600, and the circuits labelled 602-603 and 608-609.
- X-software The-"software modules necessary to support a Commercial X terminal
- Z- software the software modules necessary to support a Z-controller or Z-node
- a Commercial X terminal's X-software comprises the software modules x-Net node 750, x-Help 753, Keyboard or mouse code 751, and x-System monitor 752.
- the x-Net node 750 is the communication software to implement the network protocol for communication with the Z-controller or Z-node to which the Commercial X terminal is connected.
- This x-Net node software 750 must be compatible with the x-system monitor 752, which is the operating system running on the Commercial X terminal.
- the x-Help module 753 contains utilities which enable the user to establish a correct connection to the Z-controller or Z-node.
- the features in the x-Help ⁇ module 753 may include a local terminal emulation capability, screen-based tables for setting addresses and communication parameters for selecting protocols, and for monitoring status.
- Z-software is compatible with the Z operating system 700, which may be a custom or a standard real-time operating system, such as Virtual Real Time Executive (VRTX) available from Ready Systems, Inc. Communication protocols with the Commercial X terminals are provided by x-Net module 713.
- the Z-Help module 701 contains utilities which enable the user to establish a correct connection between the Z-controller and the host computer (which in the case of a Z-node, may comprise multiple hosts) .
- the Z-Help module 701 also contains general instructions on how to use the features of the Z- controller, such as how to initiate local applications (e.g. lightweight applications such as MS-DOS applications) , how to establish connections to remote hosts (network help) , and status messages relating to the booting process, the shared resource utilization (e.g. how much free memory is available) , font availability, Z- controller workload (e.g. CPU busy percentage) , and the like.
- Z-software terminal driver for supporting a Commercial X terminal comprises two parts: common Display Manager 703, and terminal-specific display code 703-1 to 703-n.
- the common Display Manager 703 is reentrant software common to all Commercial X terminals supported.
- the common Display Manager 703 manages for the Commercial X terminals the shared resources such as font tables 706, which contains bit-map images of common symbols useable in any of the Commercial X terminals supported.
- Other shared resources managed by the common Display manager 703 include backing store 705, which provides a common pool of memory buffers allocable for use by any Commercial X terminal in the workgroup, such that each Commercial X terminal appears to have a larger amount of memory than is actually installed.
- Each Commercial X terminal is allocated one of the display code areas 703-1 to 703-n, for storing terminal-specific parameters, and low level routines specific for driving the physical hardware of the particular Commercial X terminal residing in that display code area.
- the common Display Manager 703 updates each Commercial X terminals at, on the average, 50 milliseconds intervals.
- the concept behind the implementation of the X-server is analogous to the sharing concept of the common Display Manager 703, i.e. the X-server also comprises common and terminal-specific parts: common X-server 704 and terminal X-servers 704-1 to 704-n. Again, only one copy of the reentrant code in the common X-server 704 need be resident to support the multiple Commercial X terminals in the workgroup. A pool of memory buffers is managed by the common X-server 704 and such buffers are allocable for use by any of the Commercial X terminals in the workgroup. Terminal-specific parameters are stored for each Commercial X terminal at one of terminal-specific areas X- servers 704-1 to 704-n. Thus, high efficiency resulting from sharing of resources and elimination of redundancy is achieved. To the client application software, the X- server provided by the Z-software for each Commercial X terminal is indistinguishable from a conventional X- server.
- Z-software also provides Network Access Manager 712, Disk Access Manager 711 and Memory Access Manager 710 to access network, disk and memory resources either at the host computer connected to a Z-controller, or everywhere in the network accessible by a Z-node.
- the Z-node requests directly over the network the needed network, memory or disk resources.
- the resources are requested over the host bus and provided by the host Computer.
- Z-software supports conventional X Window utilities such as TFTP (trivial file transfer protocol) , TFTP or NFS 2 (Network File System) font server, and RARP (Resource Arbitration Resolution Protocol) .
- TFTP trivial file transfer protocol
- NFS 2 Network File System
- RARP Resource Arbitration Resolution Protocol
- Each Z-controller or Z-node is powerful enough such that, in addition to acting as X-server and display manager to multiple Commercial X terminals in the workgroup, the Z-controller or Z-node is able to execute many programs locally.
- An example is the module Lightweight Applications 707, which represents client application programs executed locally on the Z- controller's or Z-node's processors (either the main processor or the MS-DOS processor) .
- the MS-DOS applications module 708 specifically highlights the ability to support MS-DOS compatible programs on the Z- controller or Z-node.
- Figure 7b shows the software interface between Z-
- NFS is a trademark of Sun Microsystems, Inc., CA. software and the software environment of the host computer. Z-software on the Z-controller or the Z-node side is already described above in conjunction with Figure 7a.
- the host computer communicates with Z-software through the Z-application program 770 running on the host.
- This Z-application program 770 which is compatible with the host operating system 777, allows Z-software on the Z- controller to access host resources, such as network access, through protocol software Ethernet 771, TCP/IP 772, TELNET 774, or other network protocols 773.
- host resources may also include network wide file access provided by NFSTM (Network File System) facility 775.
- the host computer may run application programs, including X Window clients, such as client application program 776, which requests service from the X-server in the Z-software on the attached Z-controller.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Digital Computer Display Output (AREA)
Abstract
In accordance with the present invention, a system supporting multiple X Window display stations (201, 202, 203) under one controller is provided. Each controller (211c) may be either integrated with a host computer (210), or stand-alone (311). In a network (238) environment, a stand-alone controller (210) provides to the multiple X Window display stations access to resources throughout the network, such as memory (238) and disks (237). A controller (211c) integrated with a host processor provides the multiple X Window display stations access to resources or the host computer. Sharing of resources results in enormous cost savings.
Description
WORKGROUP CONTROLLER ARCHITECTURE FOR MULTIPLE DISPLAY STATIONS TO BE USED WITH X WINDOWS
Field of the Invention This invention relates to the architecture and design of an X Window display station; in particular, this invention relates to the architecture and design of a controller for controlling multiple X window display stations.
Background of the Invention
The X Window system is a network-based graphics windowing system for display stations, including but not limited to terminals, workstations, and personal computers. The X Window display software (the "server") provides application programs (the "clients") facilities to control the graphics displayed at the display station. These facilities are typically commands at a high level of abstraction, so that the programmers of the client application programs are provided a uniform interface independent of the specific implementation of the display station. The specification for the X window system, hereinafter the "X Window standard," was developed at MIT and has been widely adopted as an industry standard. A comprehensive description of the X Window standard may be found in "X Window System User's Guide", by Valerie Quercia and Tim O'Reilly, published by O'Reilly and Associates, and is hereby incorporated by reference in its entirety.
An X Window display station consists of (i) a video display, (ii) a keyboard, (iii) a pointing device, commonly known as a "mouse", (iv) a connection to a host bus or a network of one or more host computers, and (v) the capabilities required of an X Window server, as required by the X Window standard. Conventionally, each X Window display station has a
self-contained controller which controls that display station and only that display station. That conventional display station including its controller may be stand¬ alone, or may be integrated within the cabinet of one of 5 the host computer systems on the network. Figure shows a conventional X Window network. As shown in Figure 1, six conventional X Window display stations 100-105 are provided on an industry standard network, such as Ethernet, together with two host computer systems 110 and
10 111. Figure 1 illustrates two common configurations for providing X Window display stations. Display stations 100-104 are conventional X Window display stations each having its own controller module (controller modules 100c- 104c) communicating over the Ethernet network with devices
15 running client application programs, such as host computers 110 and 111. Display station 105, however, is controlled by controller module 111c, which is integrated with the host computer 111. The integration of host computer 111 and controller module 111c may be effectuated 0 simply by host computer 111 and controller module 111c residing in the same cabinet, and communicating by a local host bus lllh.
The conventional architecture requires one controller per display station. As is readily seen in Figure 1, 5 since resources are not shared among the display stations, each display station must have fully duplicated X window resources to implement X Window functionalities. Other resources, such as memory and disks, are also limited to that available locally at the X Window display station or 0 accessible on the network. Each display station is also required to have a complete communication link to the network. Such configurations are expensive and wasteful, since many of the duplicated resources are not used simultaneously on a network such as shown in Figure 1. 5 Another conventional architecture has the host computer CPU execute the server program for one or more display devices. This architecture degrades the
performance of the host computer.
Thus, a configuration in which a group of X Window display-stations on a network share resources without noticeably degrade the performance of the host system is highly desirable.
Summary of the Invention
In accordance with the present invention, an architecture of a single controller for an X Window system is provided. This controller controls multiple display stations (the "workgroup") , provides connectivity between any member of the workgroup and the network, and provides a X Window server for each display station in the workgroup to client application programs everywhere. The controller in accordance with the present invention may be stand-alone or integrated within the same cabinet of a host computer. A workgroup in accordance with the present invention may coexist~on the same network with other conventional X Window systems. Normally, a client application program will not be able to distinguish an X Window server of the workgroup controller from a conventional X Window server.
This invention will be more fully understood in conjunction with the following description taken together with the accompanying drawings.
Brief Description of the Drawings
Figure 1 shows X Window display stations 100-105 in the prior art connected to two host computer systems 110 and 111 on an Ethernet.
Figure 2a shows Commercial X terminals 201-203 connected to a Z-controller 210c on an Ethernet network with conventional X Window display stations 204-206, in accordance with the present invention.
Figure 2b shows a Commercial X terminal 200 sharing host resources 236-238 through a Z-controller 210c, in accordance with the present invention.
Figure 3 shows Commercial X terminals 301-303 connected to a Z-node 311 on an ethernet network with conventional X window display stations 304-306, in accordance with the present invention. Figure 4a is a block diagram of a Z-controller 40, called "EISA Z16 Turbo Controller," in accordance with the present invention.
Figure 4b is a block diagram of a Z-controller 41, called "AT/EISA Z8 Turbo Controller," in accordance with the present invention.
Figure 4c is a block diagram of a Z-controller 42, called "EISA Z4 Controller," in accordance with the present invention.
Figure 4d is a block diagram of a custom circuit providing control function for the host bus, and the 16 MS-DOS window mapper.
Figure 5 is a block diagram of a Z-node 50 in accordance with the present invention.
Figure 6 is a block diagram of a Commercial X terminal 60, in accordance with the present invention.
Figure 7a is a block diagram showing software modules of a Commercial X terminal and a Z-controller, in accordance with the present invention.
Figure 7b is a block diagram showing software modules of a Z-controller and a host computer, in accordance with the present invention.
Detailed Description of the Preferred Embodiments
Embodiments of the present invention may be either integrated with a host computer or "stand-alone". In the following, the controller module of an embodiment of the present invention which is integrated with a host computer is referred to as a "Z-controller", and the controller module of an embodiment of the present invention which is stand-alone is referred to as a "Z-node". An X Window display station connected to a Z-controller or Z-node is referred to as a "Commercial X terminal". The Commercial
X terminals connected to a Z-controller or Z-node are collectively known as the Z-controller's or the Z-node's "workgroup." In a Z-controller, network access is provided by the network communication facility in the host computer. The Z-node, however, has its own network communication facility.
Figure 2a shows three Commercial X terminals 201-203 controlled by a Z-controller 210c, Z-controller 210c is integrated with host computer 210 on an Ethernet network to which conventional X Window display stations 204-206 are also connected. Since the Z-controller 210c is designed to provide an X server facility for each Commercial X terminal connected to it, the client application program running on a processor in the network, such as host computer 211, will not be able to distinguish the conventional X Window display stations from a Commercial X terminal connected to the Z17 controller 210c. The conventional X Window display stations 204 and 206 are respectively similar to the stand-alone display station 100 and the integrated display station 105 shown in Figure l.
Unlike the conventional X Window display station, such as display station 204, a Commercial X terminal, such as Commercial X terminal 201, has neither a controller module providing X server functionalities nor direct access to the network. Instead, the Commercial X terminal 201 has merely, in the module labelled 201b, a frame buffer, circuities for frame buffer control, keyboard and mouse control, and a high speed link (called "x-Net") to the Z-controller. X server functionalities and network access facilities in Commercial X terminal 201 are provided by the Z-controller 210c and the host computer 210 respectively. Because of this transfer of functionality to the Z-controller, unlike a conventional X Window display station, a Commercial X terminal can be implemented without a high performance central processing unit (CPU) , its associated memory and network access
facilities, resulting in enormous cost savings. As an example of such savings, the conventional X Window display station is typically equipped with 2-4 megabytes of main memory. By contrast, to attain similar performance, in 5 accordance with the present invention, each Commercial X terminal of a workgroup of sixteen shares 2-8 megabytes of Z-controller main memory and, when active, requires dedicated allocation of only 0.25-0.5 megabytes of Z- controller main memory. Thus, for a workgroup of sixteen
10 Commercial X terminals, the conventional requirement of 32-64 megabytes of memory is satisfied by 10-12 megabytes, in accordance with the present invention.
Figure 2b shows in further detail host resource sharing using a Z-controller 210c. Z-controller 210c is
15 connected to the host bus 219, on which is also connected an interface to the Ethernet 235, a tape resource 236, a disk resource 237, and memory resource 238. The resources on host bus 219, including Z-controller 210c, are typically memory-mapped or 1/0 mapped to the host
20 computer's address space as required, so that communication among the resources and the host computer may be effectuated by a conventional host bus protocol, such as Extended Industry Standard Architecture (EISA) , thereby providing the Z-controller 210c local access to
25 all the resources on the host bus 219. In Figure 2b, other X Window display stations are shown on the Ethernet 235, including conventional X Window display stations 204- 206, and another Z-controller/Commercial X configuration 212. Figure 2b also shows on Ethernet 235 processors 213 -30 and 214 running client applications programs. The link between the Commercial X terminal 200 and the Z-controller 210c is provided by the point-to-point connection 220, which is one of the x-Net connections linking each Commercial X terminal in Z-controller 210c's workgroup to
35 controller 210c. The x-Net may be implemented by any high speed (3-10 Mbits per second, for example) point-to-point communication link or a local area network. Indeed, The
x-Net may itself be a Ethernet-like point-to-point local area network connecting each of the Commercial X terminals in the workgroup to the Z-controller. A lOBase-T twisted pair Ethernet, for example, is suitable for this application, while still avoiding the high cost of an attachment unit interface (AUI) coaxial Ethernet network. (A 10BASE-T Ethernet has a range of 100 meters, whereas a standard AUI Ethernet may effectively communicate over a coaxial cable distance of 0.5-1.5 kilometers). Typical information passed on the x-Net includes keyboard and pointing device input data, keyboard and audio control data, cursor positions and pattern data, configuration data, and frame buffer updates.
Figure 3 shows Commercial X terminals 301-303 connected to a Z-node 311, which is connected to an
Ethernet network with conventional X Window stations 304- 306 and host computers 310 and 312. Commercial X terminals 301-303 are not different from the Commercial X terminals 201-203 shown in Figure 2. Unlike Z-controller 211c of Figure 2a, however, the Z-node 311 is not integrated with a host computer. Hence, the Z-node 311 has to provide its own communication facility for accessing the Ethernet network. The connection between a Commercial X terminal, such as 301-303, and the Z-node 311 is over the x-Net, the same as between Commercial X terminal 201 and Z-controller 211c shown in Figure 2a.
The Z-controller is a board or a set of boards capable of supporting 16-128 Commercial X terminals. As mentioned above, the Z-controller resides in the cabinet of a host computer, and communicates with the host computer over a host bus. One implementation may have the Z-controller local memory mapped to the address space of the host computer. By integrating with the host computer, the host computer's resources, such as memory, disk or network access, are made available through "virtual access" to the Z-controller, and, in turn, to each Commercial X terminal in the workgroup the Z-controller
supports, such that each Commercial X terminal may be viewed, as compared to the resources found in a conventional X Window display station, as having virtually unlimited memory and disk resources. Figure 4a shows an embodiment of a Z-controller 40 called the "EISA Z16 Turbo". As shown in Figure 4a, in this embodiment, the Z-controller 40's main processor 400 is implemented by a reduced instruction set computer (RISC) type processor chip SPARC IU L64091, available from LSI Logic Corporation, although other high performance microprocessors may also be used. The processor 400 is supported by an integrated system controller 401 using a 11 SPARC ISC L64951 chip, which provides system control functions, such as cache management, memory mapping and peripheral control. The use of an integrated system controller chip is well known in the art.
To provide efficient memory access, a memory cache comprising the cache data unit 402, cache tags unit 403 and cache logic unit 404 is provided. The design of a cache memory is also well-known in the art. On-board memory is provided by the electrically programmable read only memory (EPROM) 405, the dynamic random access memory (DRAM) 406, and electrically erasable and programmable read-only memory (EEPROM) 407. EPROM 405 contains the bootstrap firmware for Z-controller 40's operation, which is executed upon power-up or receipt of a reset signal. DRAM 406 provides the main memory for processor 400. Although shown as having four megabytes installed, the amount of installed memory may be more or less depending on the operating environment. Obviously, higher performance is generally achievable with more on-board memory. EEPROM 407 provides non-volatile storage for such data as user options, or configuration data for system initialization. In order to support graphical operations at the
Commercial X terminals, video random access memory (VRAM) 409 is provided. The X Window system software running on
processor 400 directs graphical operations on the video images in VRAM 409 before Z-controller 40 sends the updated image to the corresponding Commercial X terminal in the workgroup. One method of updating images on a Commercial X terminal is described in copending application entitled "Selective Content Synchronization of Multiple Image Buffers" by Jonathan D. Garman, Serial No. 07/551,594, filed July 10, 1990, assigned to Athenix Corporation, and is hereby incorporated by reference in its entirety.
In this embodiment, a graphics processor 408, using a TMS34010 graphics processor obtainable from Texas Instruments Corporation, is provided to improve graphics performance. As will be seen in other embodiments of the present invention, this graphics processor improves the overall performance of the Z-controller, but is not necessary for the operation of the Z-controller.
Also shown in this embodiment in Figure 4a is MS-DOS processor 410, provided to accommodate users who may want to run MS-DOS compatible application programs. (MS-DOS™1 is a popular operating system running on IBM PC™ family personal computers) . This MS-DOS processor 410 is provided strictly for the user's convenience and is not necessary to practice the present invention. The MS-DOS processor 410 is the subject of copending application
"Application Address Display Window Mapper for a Sharable MS-DOS processor", by Jonathan D. Garman, Serial No. 07/551,592, assigned to Athenix Corporation, filed July 10, 1990, and is hereby incorporated by reference in its entirety. MS-DOS processor 410 may be implemented by a microprocessor, such as 386DX of the x86 microprocessor family, available from Intel Corporation.
As discussed above, a Z-controller communicates over a host bus with the host computer to which it is integrated. Thus, in the example of Figure 4a, Z-
1 MS-DOS is a trademark of Microsoft, Inc. , Washington IBM is a trademark of International Business Machines, N.Y.
controller 40 is provided bus controller module 411 to implement the interface to the host's EISA bus. Controller module 411 implements the EISA standard bus interface in addition to direct memory access (DMA) protocols, block update monitor controls, refresh control and MS-DOS window mapper. A block diagram for the controller module 411 is provided in Figure 4d.
As shown in Figure 4d, the bus control logic 470 implements the host bus control function for the Z- controller. DMA control logic 490 provides the control for DMA operations. The DMA control logic comprises a DMA address register 492, a DMA control module 493 which provides the DMA protocol signals, and DMA count register 491 which keeps count of the amount of data to be transferred.
Also shown in Figure 4d is MS-DOS window mapper unit 480, which provides the mapping function between the MS- DOS processor's address space and the MS-DOS window's address space (in the frame buffer) . MS-DOS window mapper unit 480 comprises arithmetic logic units 482 and 484, row address offset table registers 481, column-per-row register 485, MS-DOS frame buffer starting address register 486, MS-DOS address input register 487, and data mapper 483. The method for providing the MS-DOS window mapping function is described in the above-incorporated copending application,entitled "Address Display Mapper for a Sharable MS-DOS processor."
The Z-controller 40 supports up to sixteen Commercial X terminals connected to its sixteen ports P1-P16. These sixteen ports are provided by two integrated multiport repeater 79C980 circuits 414 and 415, available from Advanced Micro Devices, Inc. Each circuit 414 or 415 is controlled by an Ethernet controller circuit 412 or 413, each implemented by a 79C900 circuit, also available from Advanced Micro Devices, Inc. The Ethernet controller circuits 414 and 415 are memory or I/O mapped onto the
local address or data bus.
Figure 4b shows an embodiment of a Z-controller 41 of the present invention, called "AT/EISA Z8 turbo controller". The Z-controller 41 of Figure 4b includes the RISC processor 400, integrated system controller 401, cache units 402-404, EPROM 405, DRAM 406, and EEPROM 407 as in Z-controller 40 of Figure 4a. Z-controller 41 also includes a MS-DOS processor 410 for the user's convenience. However, Z-controller 41 does not have the graphics processor 408, hence providing a lower level of performance than that attainable by Z-controller 40 of Figure 4a. In the absence of graphics processor 408, the VRAM module 409 is controlled by the bus controller module 411. Without the graphics processor 408, Z-controller 41 is a less expensive embodiment of the present invention suitable for a smaller workgroup. Accordingly, only eight Commercial X terminals are supported by Z-controller 41, rather than sixteen as in Z-controller 40 of Figure 4a. The eight ports P1-P8 are provided by integrated multiport repeater module 415 and controlled by Ethernet controller module 413. The integrated multiport module 415 and Ethernet controller module 413 are similar to the identically numbered modules of Z-controller 40 in Figure 4a. Figure 4c is another embodiment of the Z-controller in accordance with the present invention, called "EISA Z4 controller". Figure 4c shows Z-controller 42 supporting up to eight Commercial X terminals on ports P1-P8, as in Z-controller 41 in Figure 4b. Unlike Z-controller of Figure 4b, however, Z-controller 42 does not have separate VRAM and DRAM modules. In their place, a static column random access memory (SCRAM) module 406 is provided. A SCRAM memory array provides rapid sequential accesses to a "column" of data upon one initial access, i.e. a large number of data stored in consecutive addresses are provided one by one in consecutive address order in rapid succession without incurring the time cost Of initial
access for- each of datum addressed, other than for the first datum. By using SCRAM module 406, memory access performance is increased. In this embodiment, the main processor 400 manages the video random access memory implemented in SCRAM module 406.
The Z-node replaces a Z-controller's host bus interface with an interface to the network, and supports from 64 to 128 Commercial X terminals. Because the Z-node provides network access facilities without intervention by a host computer, access to network resources are made even more efficient. Therefore, the Z-node is better suited than the Z-controller to exploit network resources, such as remote disk access and virtual memory paging facilities, to provide the Commercial X terminals with disk and memory facilities accessible on the network. A network connecting Commercial X terminals linked to a Z- node tends to recover from failure more rapidly than a network of conventional X Window display stations because the single bootstrap program in the Z-node EPROM recovers for sixteen or more display stations, rather than one in a conventional X-Window display station. Because the Z-node has a single network address, the net traffic at start-up after power failure is greatly reduced, leading to rapid recovery from network failure. In accordance with the present invention, Figure 5 shows an embodiment Z-node 50 of a Z-node called the "Z node Turbo." Z-node 50 is similar in implementation to the Z-controller 40, with the EISA bus interface being replaced by an Ethernet controller 416 providing access to the Ethernet network. As shown in Figure 5, Ethernet controller 416 is implemented by the controller chip 79C900 available from Advanced Micro Devices, Inc. Figure 5 also shows that Ethernet controller 416 is capable of interfacing with standard AUI Ethernet (10BASE5 of IEEE standard 802.3), with CheaperNet (10BASE2 of IEEE standard 802.3, also known as thinnet Ethernet coaxial cable) through transceiver 418, or with a 10BASE-T Ethernet
network (10BASE-T of IEEE standard 802.3) through transceiver 417. (A 10BASE-T Ethernet is discussed above in conjunction with x-Net implementation) . In Figure 5, transceiver 418 is implemented by a 7996 transceiver, and transceiver 417 is implemented by a 79C98 transceiver. Both 7996 and 79C98 transceivers are available from Advanced Micro Devices Inc.
Figure 6 shows an embodiment of a Commercial X terminal 60 with up to four video displays 604a-604d, in accordance with the present invention. In this embodiment, the Commercial X terminal is controlled by a relatively low cost microcontroller 600, such as a 80C31 controller available from Intel Corporation. As shown in Figure 6, the firmware for controller 600 is stored in EPROM 601. A relatively small main memory 602 is needed to support controller 601, such as the 8K bytes of static random access memory (SRAM) shown in Figure 6. EEPROM 603 allows non-volatile storage of information such as configuration data. Each display 604a-604d comprises a frame buffer 606 implemented by VRAMs. In Figure 6, the frame buffer 606 is shown to contain one megabits of information. The size of the frame buffer is determined by the resolution of the display. The control of the display is provided by logic module 605, which provides support for direct memory access (DMA) , hardware cursor, block update monitor, refresh control, mouse and keyboard controls. A shifter 607 provides a serial link for output of video data to the video display circuitry, controller 600 communicates on the x-Net through the Ethernet controller 608 and transceiver 609, to the Z-node or Z- controller to which Commercial X terminal 60 is connected. Each display station 604a-604d is also provided a display device, a mouse and a keyboard. The optional 604b-604d circuitry creates very low cost display/mouse/keyboard stations by sharing the common controller 600, and the circuits labelled 602-603 and 608-609.
The system software modules necessary to support the
Commercial X terminals, the Z-controller or Z-node are next described in conjunction with Figures 7a and 7b.
The-"software modules necessary to support a Commercial X terminal ("X-software") and the software modules necessary to support a Z-controller or Z-node ("Z- software") are illustrated in Figure 7a. As shown in Figure 7a, a Commercial X terminal's X-software comprises the software modules x-Net node 750, x-Help 753, Keyboard or mouse code 751, and x-System monitor 752. The x-Net node 750 is the communication software to implement the network protocol for communication with the Z-controller or Z-node to which the Commercial X terminal is connected. This x-Net node software 750 must be compatible with the x-system monitor 752, which is the operating system running on the Commercial X terminal. The x-Help module 753 contains utilities which enable the user to establish a correct connection to the Z-controller or Z-node. The features in the x-Help~~module 753 may include a local terminal emulation capability, screen-based tables for setting addresses and communication parameters for selecting protocols, and for monitoring status.
Z-software is compatible with the Z operating system 700, which may be a custom or a standard real-time operating system, such as Virtual Real Time Executive (VRTX) available from Ready Systems, Inc. Communication protocols with the Commercial X terminals are provided by x-Net module 713. The Z-Help module 701 contains utilities which enable the user to establish a correct connection between the Z-controller and the host computer (which in the case of a Z-node, may comprise multiple hosts) .
The Z-Help module 701 also contains general instructions on how to use the features of the Z- controller, such as how to initiate local applications (e.g. lightweight applications such as MS-DOS applications) , how to establish connections to remote hosts (network help) , and status messages relating to the
booting process, the shared resource utilization (e.g. how much free memory is available) , font availability, Z- controller workload (e.g. CPU busy percentage) , and the like. Z-software terminal driver for supporting a Commercial X terminal comprises two parts: common Display Manager 703, and terminal-specific display code 703-1 to 703-n. The common Display Manager 703 is reentrant software common to all Commercial X terminals supported. Only one copy of the common display Manager 703 need be resident even though multiple Commercial X terminals are active. With this approach, the common Display Manager 703 manages for the Commercial X terminals the shared resources such as font tables 706, which contains bit-map images of common symbols useable in any of the Commercial X terminals supported. Other shared resources managed by the common Display manager 703 include backing store 705, which provides a common pool of memory buffers allocable for use by any Commercial X terminal in the workgroup, such that each Commercial X terminal appears to have a larger amount of memory than is actually installed. Each Commercial X terminal is allocated one of the display code areas 703-1 to 703-n, for storing terminal-specific parameters, and low level routines specific for driving the physical hardware of the particular Commercial X terminal residing in that display code area. The common Display Manager 703 updates each Commercial X terminals at, on the average, 50 milliseconds intervals.
The concept behind the implementation of the X-server is analogous to the sharing concept of the common Display Manager 703, i.e. the X-server also comprises common and terminal-specific parts: common X-server 704 and terminal X-servers 704-1 to 704-n. Again, only one copy of the reentrant code in the common X-server 704 need be resident to support the multiple Commercial X terminals in the workgroup. A pool of memory buffers is managed by the common X-server 704 and such buffers are allocable for use by any of the Commercial X terminals in the workgroup.
Terminal-specific parameters are stored for each Commercial X terminal at one of terminal-specific areas X- servers 704-1 to 704-n. Thus, high efficiency resulting from sharing of resources and elimination of redundancy is achieved. To the client application software, the X- server provided by the Z-software for each Commercial X terminal is indistinguishable from a conventional X- server.
Z-software also provides Network Access Manager 712, Disk Access Manager 711 and Memory Access Manager 710 to access network, disk and memory resources either at the host computer connected to a Z-controller, or everywhere in the network accessible by a Z-node. In a Z-node environment, the Z-node requests directly over the network the needed network, memory or disk resources. By contrast, in a Z-controller environment, the resources are requested over the host bus and provided by the host Computer.
Z-software supports conventional X Window utilities such as TFTP (trivial file transfer protocol) , TFTP or NFS2 (Network File System) font server, and RARP (Resource Arbitration Resolution Protocol) .
Each Z-controller or Z-node is powerful enough such that, in addition to acting as X-server and display manager to multiple Commercial X terminals in the workgroup, the Z-controller or Z-node is able to execute many programs locally. An example is the module Lightweight Applications 707, which represents client application programs executed locally on the Z- controller's or Z-node's processors (either the main processor or the MS-DOS processor) . The MS-DOS applications module 708 specifically highlights the ability to support MS-DOS compatible programs on the Z- controller or Z-node. Figure 7b shows the software interface between Z-
NFS is a trademark of Sun Microsystems, Inc., CA.
software and the software environment of the host computer. Z-software on the Z-controller or the Z-node side is already described above in conjunction with Figure 7a. The host computer communicates with Z-software through the Z-application program 770 running on the host. This Z-application program 770, which is compatible with the host operating system 777, allows Z-software on the Z- controller to access host resources, such as network access, through protocol software Ethernet 771, TCP/IP 772, TELNET 774, or other network protocols 773. Such host resources may also include network wide file access provided by NFS™ (Network File System) facility 775. The host computer may run application programs, including X Window clients, such as client application program 776, which requests service from the X-server in the Z-software on the attached Z-controller.
The above description of the embodiments is intended to be illustrative of the general principles of the present invention. The skilled person in the art will be able to, upon consideration of the above description in conjunction with the accompanying drawings, derive modifications and variations within the scope of the present invention.
Claims
1. An X Window system connectable to a local area network comprising: a plurality of display stations each including a keyboard, a pointing device, and a video display; controller means for controlling said plurality of display station, for providing connectivity between said plurality of display stations and said network, and for being an X Window server to client application software for each of said plurality of display stations.
2. An X Window system as in Claim 1, wherein said controller means comprises high speed links from said controller means to each of said display stations.
3. An X Window system as in Claim 1, wherein said controller comprises a microprocessor.
4. An X Window system as in Claim 1, wherein said controller comprises a MS-DOS processor.
5. An X Window system as in Claim 1, wherein said controller is capable of running client application program.
6. An X Window system as in Claim 1, wherein said controller means comprises a graphics processor.
7. An X Window system as in Claim 1, wherein said controller comprises video random access memory.
8. An X window system as in Claim 1, wherein said controller comprises volatile and non-volatile memory components.
9. An X Window system as in Claim 4, wherein said controller comprises window mapping means for mapping MS- DOS addresses to addresses in each of said displays' address space.
10. An X Window system as in Claim 1, wherein said controller means comprises a bus interface for integration with a host computer having a local host bus.
11. An X Window system as in Claim 10, wherein said host computer is capable of sharing with said controller memory, mass storage media and communication means for accessing said network.
12. An X Window system as in Claim 1 wherein said controller comprising a network interface.
13. An X Window system as in Claim 12, wherein said network is connectable to disk resources and said controller means comprises disk access means for accessing said disk resources.
14. An X Window system as in Claim 13, wherein said network is connectable to virtual memory paging facilities and said controller means comprises memory access means for accessing said virtual memory paging facilities.
15. A controller for controlling multiple display stations comprising: a microprocessor; memory means for storing and retrieving programs and data accessible by said microprocessor; frame buffer means for storing and retrieving frame buffers for each of said display stations; and, high speed link means for providing connection to each of said display stations.
16. A controller as in Claim 15, wherein said memory means comprises a cache means for increasing memory access performance, and non-volatile memory means for storing the firmware of said controller and system parameter values.
17. A controller as in Claim 15, wherein said high speed link means comprises at least one ethernet controller and a plurality of integrated multiport repeater controlled by said ethernet controller for communication with each of said display stations.
18. A controller as in Claim 15, further comprising a MS-DOS processor.
19. A controller as in Claim 15, further comprising a graphics processor.
20. A controller as in Claim 15, further comprising a host bus controller for providing communication between a host computer and said controller.
21. A controller as in Claim 15, further comprising an ethernet controller for providing communication between said controller and an external local area network.
22. An X Window display terminal capable of supporting at least one video displays comprising; an internal bus; a microprocessor connected to said internal bus; memory means for storing and retrieving program and data accessible by said microprocessor on said internal bus; network controller means accessible on said internal bus for providing communication between said display terminal and an external network; display control logic means accessible on said internal bus for providing each video display direct
memory access control, hardware cursor control, refresh control, and input and output control for a keyboard and a pointing device; and a plurality of video random access memory means, each connected to said display control logic means and each associated with one video display, for storing pixels of said video display and for providing serial interface to said video display.
23. A system for providing an X Window server on a controller to service X Window clients for each of a plurality of display stations, comprising: display means on each of said display stations for receiving input from a keyboard and a point device and providing output to a video display; display communication means on each display station for providing communication between said display means and said controller; controller display communication means on said controller for providing communication between each display communication means and said controller, said controller display communication means having a common communication module for providing common display communication functions shared by all of said display stations and a plurality of second communication modules each associated with one display station for providing communication functions specific to the display communication means of said display station; and
X Window server means for receiving instructions from an X Window client and for providing display control functions in accordance with said instructions through said controller display communication means, said Window X server means having a first X Window server module for providing display control functions common to all of said display stations and a plurality of second X Window
server modules each associated with a display station, for providing display control functions specific to said associated display station.
24. A system as in Claim 23, further comprising memory means for providing backing store for each of said display stations.
25. A system as in Claim 23, further comprising font tables sharable by all of said display stations,
26. A system as in Claim 23, further comprising network access manager means for providing network access functions for said X Window server means.
27. A system as in Claim 23, further comprising disk access manager means for providing disk access functions for said X Window server means.
28. A system as in Claim 23, further comprising host access manager means for providing said X Window server means access to resources available on a host computer.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US55169490A | 1990-07-10 | 1990-07-10 | |
US551,694 | 1990-07-10 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1992001263A1 true WO1992001263A1 (en) | 1992-01-23 |
Family
ID=24202301
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1991/004696 WO1992001263A1 (en) | 1990-07-10 | 1991-07-02 | Workgroup controller architecture for multiple display stations to be used with x windows |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU8321291A (en) |
WO (1) | WO1992001263A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0501901A2 (en) * | 1991-02-28 | 1992-09-02 | International Business Machines Corporation | Display station controller |
US5590266A (en) * | 1994-10-11 | 1996-12-31 | International Business Machines Corporation | Integrity mechanism for data transfer in a windowing system |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4688170A (en) * | 1983-09-22 | 1987-08-18 | Tau Systems Corporation | Communications network for communicating with computers provided with disparate protocols |
US4804950A (en) * | 1985-11-07 | 1989-02-14 | Spacelabs, Inc. | Table driven multichannel data acquisition and display for signal monitoring |
US4965559A (en) * | 1988-05-31 | 1990-10-23 | Motorola, Inc. | Multi-channel graphics controller |
-
1991
- 1991-07-02 AU AU83212/91A patent/AU8321291A/en not_active Abandoned
- 1991-07-02 WO PCT/US1991/004696 patent/WO1992001263A1/en unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4688170A (en) * | 1983-09-22 | 1987-08-18 | Tau Systems Corporation | Communications network for communicating with computers provided with disparate protocols |
US4804950A (en) * | 1985-11-07 | 1989-02-14 | Spacelabs, Inc. | Table driven multichannel data acquisition and display for signal monitoring |
US4965559A (en) * | 1988-05-31 | 1990-10-23 | Motorola, Inc. | Multi-channel graphics controller |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0501901A2 (en) * | 1991-02-28 | 1992-09-02 | International Business Machines Corporation | Display station controller |
EP0501901A3 (en) * | 1991-02-28 | 1993-06-16 | International Business Machines Corporation | Display station controller |
US5485570A (en) * | 1991-02-28 | 1996-01-16 | International Business Machines Corporation | Display station controller |
US5590266A (en) * | 1994-10-11 | 1996-12-31 | International Business Machines Corporation | Integrity mechanism for data transfer in a windowing system |
Also Published As
Publication number | Publication date |
---|---|
AU8321291A (en) | 1992-02-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0751656B1 (en) | Protocol independent and adaptive network interface | |
EP1399829B1 (en) | End node partitioning using local identifiers | |
US5872968A (en) | Data processing network with boot process using multiple servers | |
EP1787207B1 (en) | Dynamic resource allocation | |
US6519645B2 (en) | Method and apparatus for providing configuration information using a queued direct input-output device | |
US6836885B1 (en) | Method and apparatus for display of windowing application programs on a terminal | |
US8489848B2 (en) | Data communications between the computer memory of the logical partitions and the data storage devices through a host fibre channel adapter | |
US5574862A (en) | Multiprocessing system with distributed input/output management | |
JP3293073B2 (en) | How to get an interface to transfer data from a network to an open system | |
EP4155925A1 (en) | Data transmission method, processor system, and memory access system | |
DE112005001502T5 (en) | Sharing a physical device with multiple customers | |
US5119494A (en) | Application address display window mapper for a sharable ms-dos processor | |
US6345241B1 (en) | Method and apparatus for simulation of data in a virtual environment using a queued direct input-output device | |
JP2002287996A (en) | Method and device for maintaining terminal profile by data processing system capable of being structured | |
US6321350B1 (en) | Method and apparatus for error detection using a queued direct Input-Output device | |
US6341321B1 (en) | Method and apparatus for providing concurrent patch using a queued direct input-output device | |
US6345324B1 (en) | Apparatus for transferring data using an interface element and a queued direct input-output device | |
US6339803B1 (en) | Computer program product used for exchange and transfer of data having a queuing mechanism and utilizing a queued direct input-output device | |
WO1992001263A1 (en) | Workgroup controller architecture for multiple display stations to be used with x windows | |
US6324600B1 (en) | System for controlling movement of data in virtual environment using queued direct input/output device and utilizing finite state machine in main memory with two disjoint sets of states representing host and adapter states | |
US6339801B1 (en) | Method for determining appropriate devices for processing of data requests using a queued direct input/output device by issuing a special command specifying the devices can process data | |
US6345329B1 (en) | Method and apparatus for exchanging data using a queued direct input-output device | |
US6697854B1 (en) | Method and apparatus for providing configuration information using a SIGA vector and utilizing a queued direct input-output device | |
US6339802B1 (en) | Computer program device and an apparatus for processing of data requests using a queued direct input-output device | |
US6243767B1 (en) | System for register partitioning in multi-tasking host adapters by assigning a register set and a unique identifier in each of a plurality of hardware modules |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AU CA JP NO |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): AT BE CH DE DK ES FR GB GR IT LU NL SE |
|
NENP | Non-entry into the national phase |
Ref country code: CA |