GSXBYTE.WS4
-----------
- "Realizing Graphics Standards for Microcomputers"
Fred Langhorst (DRI) & Thomas Clarkson (GSS)
"BYTE", February 1983, p.256
(Retyped by Emmanuel ROCHE.)
Use of the Virtual Device Interface (VDI) graphics system will make portable
graphics application software possible.
Emerging standards for interactive computer graphics herald an era in which
serious graphics applications will be as ubiquitous as spreadsheet and word-
processing programs. By promoting program portability, making it possible to
run the same programs on different computer systems, standards will create
large markets for both software and hardware graphics products. As a result,
the development of sophisticated graphics applications for microcomputers will
be economically feasible. The benefit for the end user will be more software
offerings of higher quality at reduced cost.
A history of graphics standards
-------------------------------
The earliest graphics standards were de facto standards created by a small
number of manufacturers who established dominance in the field by producing
various successful graphics output devices, such as Calcomp plotters and
Tektronix graphics terminals. When these companies added software support (for
example, Tektronix's Plot-10 package), their implementation of graphics-
device-control routines became the common graphics language for applications.
This situation lasted until the early 1970s, when the need for broader and
more flexible standards was recognized.
In 1974, the Special Interest Group on Computer Graphics (SIGGRAPH) of the
Association for Computing Machinery (ACM) held the Workshop on Machine-
Independent Graphics at the National Bureau of Standards, near Washington.
This conference marked the beginning of formal efforts in the United States to
standardize graphics. The goal: to define a generic method for describing
pictures that could be output to a variety of graphics devices, such as hard-
copy plotters and vector or raster video displays.
The International Workshop on Graphics Standards Methodology held in 1976 in
Seillac, France (near Blois), accelerated the work begun by SIGGRAPH. A
significant development was the decision to break the standardization task
into two components: first, to develop methods for making applications
programs portable, and second, to develop a functional description of a "core"
or basic graphics system.
In 1977, the Graphic Standards Planning Committee released its first draft of
a graphics standard, the SIGGRAPH Core Standard. This draft incorporated input
and output capabilities for a range of graphics devices, but did not address
the emerging field of raster graphics. Then, after two more years of work, the
committee released a major publication, the Status Report of the Graphic
Standards Planning Committee, at the annual SIGGRAPH conference in 1979.
Included was a methodology and specification for the Core Graphics System,
raster-graphics extensions to the Core System, a description of Metafile (a
device-independent picture file), and a model for distributed graphics
systems. This document also provided the impetus for the formation of the ANSI
(American National Standards Institute) Technical Committee X3H3 for Computer
Graphics Programming Languages. Formed in 1979, this ANSI group is now the
major graphics-standardization body in the United States. Meanwhile in Europe,
the Deutsches Institut fur Normung (DIN), the German standardization
institute, was working on a parallel effort to produce its Graphical Kernel
System (GKS).
Current standards efforts
-------------------------
Present efforts in standardization focus on two main interface levels: the
programmer interface and the device interface. The programmer interface refers
to the conceptual model, as well as the syntax, that the programmer uses when
incorporating graphics functions into an application program. The device
interface refers to the protocol used for communication between the device-
independent and the device-dependent functions (sometimes called the DI/DD
interface). The programmer interface standardizes the calling sequence and
functions of a graphics-procedure library, while the device interface defines
a device-driver protocol that is consistent for all graphics devices.
┌─────────────────────────┐
│ Applications program │
└────────────┬────────────┘
│
Programmer interface level - - - -│- - - - - - - - - - - GKS interface
│
┌────────────┴────────────┐
│ Graphics utility system │
└────────────┬────────────┘
│
Device interface level - - - - - -│- - - - - - - - - - - VDI interface
│
- - ───────┬────────────────────┬─┴─────────────────────────┬─────── - -
│ │ │
│ ┌───────┴───────┐ ┌────────┴─────────┐
│ │ Device Driver │ │ Universal NAPLPS │
│ └───────┬───────┘ │ Device Driver │
│ │ └────────┬─────────┘
│ │ │
┌─────────┴──────────┐ ┌───────┴────────────────┐ ┌────────┴─────────┐
│ Physical device, │ │ Physical device, │ │ Videotex device │
│ standard interface │ │ non-standard interface │ └──────────────────┘
└────────────────────┘ └────────────────────────┘
Figure 1: The two main levels of graphics standardization are the
programmer and device-interface levels. The Graphical Kernel System
(GKS) provides a standard interface between the application program
and graphics utility programs. The Virtual Device Interface (VDI)
standardizes the interface between graphics utilities and device
drivers.
The Graphical Kernel System
---------------------------
The Graphical Kernel System (GKS) is the principal emerging standard at the
programmer level. GKS has felt the influence of many national organizations,
including ANSI in the United States, and is justifiably described as an
international standard. Now a Draft International Standard, the GKS
specification is frozen, awaiting final adoption as an ISO (International
Organization for Standardization) standard.
GKS allows portability of graphics application programs between different
computer installations by providing a consistent interface in high-level
programming languages such as FORTRAN and Pascal. It also improves a
programmer's ability to work on different systems by providing a graphics
model and syntax that are common to several systems. This is accomplished by
standardizing the way in which graphics functions are accessed, and by
providing graphics output on a virtual device surface defined in normalized
device coordinates. The application program may then control the way
individual workstations interpret the normalized coordinates, which are
translated to real-device coordinates for display, although the other layers
of the system are fooled into thinking they are communicating with the
idealized virtual device.
Reflecting the rigors of its origin in the flexibility it provides, GKS
supports a full set of drawing primitive commands (with variable attributes)
for data input and drawing, support for multiple workstations, and device-
independent picture segments. It also supports raster graphics through a
comprehensive set of area-fill and pixel-array primitives. While GKS provides
device independence for standard functions, non-standard operations are also
made available through the Generalized Drawing Primitive, a well-defined
mechanism to escape from GKS that allows a programmer to access the unique
capabilities of a particular device.
Let us take a look at some parts of the GKS specification.
GKS workstations
----------------
A GKS workstation is a single display surface, and one or more input devices.
The display surface is usually a cathode-ray-tube screen, although it could be
a plotter bed or some other device. Multiple workstations that may operate in
a single, interactive graphics session might include, for example, a raster
display, a plotter, and a storage display tube. GKS provides the logical
interface through which the application program controls physical devices,
allowing the application to redirect the flow of graphics data to another I/O
device at any time.
GKS graphics primitives
-----------------------
The basic drawing primitives in GKS are the polyline, polymarker, and text
primitives. The polyline primitive draws a sequence of vectors (straight
lines) between pairs of points that form a sequence specified as an array
(sort of a "connect the dots" command). A single line is merely a special case
of the polyline, defined by specifying both endpoints (rather than relying on
a sometimes ambiguous and confusing current-position model). The polymarker
primitive, chiefly used to identify points on plotted curves, is similar to
the polyline, except that a marker symbol, rather than a vector, is drawn at
each specified point. The text primitive allows text strings to be displayed
at any position, with any orientation.
GKS also supports raster devices with fill and pixel-array primitives. The
fill operation paints the interior of a closed polyline (polygon) with a
specified color or pattern (such as a crosshatch). The pixel-array primitive
allows a two-dimensional array of pixels of different colors, called a cell,
to be defined. The cell may then be replicated over an arbitrary area simply
by giving the desired boundaries. This operation finds many uses in imaging
applications, such as video-frame displays, cartography, and other scientific
areas.
Some graphics-output devices have incorporated unusually powerful capabilities
into their repertoire, such as the ability to draw arcs, circles, and bars.
GKS allows an application program to access these capabilities through a
special escape mechanism called the Generalized Drawing Primitive. By passing
an identification number and the required parameters to the driver, any unique
feature of the device may be invoked. In effect, the Generalized Drawing
Primitive is a standard way to be non-standard.
Attributes
----------
Associated with each output primitive are attributes that alter the object's
appearance. For example, the polyline primitive has line-type (solid, dashed,
etc.), width, and color attributes. Polymarkers have attributes of style,
size, and color; the styles comprise a choice of common ASCII (American
Standard Code for Information Interchange) characters. Text primitives have
attributes of size, color, and orientation; and multiple character fonts can
be accessed if they are available in the graphics device. Color indexes may be
defined by associating a desired color specified in RGB (Red-Green-Blue)
intensities with a color-index number; the color values of primitives are then
given as the appropriate index.
Viewing and transformations
---------------------------
GKS allows the user or programmer to define a coordinate space, called the
world coordinate space, that is appropriate for each application. This world
coordinate space is mapped into device coordinates in a controlled manner
through two distinct operations: normalization transformations and workstation
transformations. GKS first transforms world coordinates into a normalized-
device-coordinate (NDC) space by defining a working region, or window, in
world-coordinate space. NDC space acts as an abstract viewing surface or an
intermediary space between applications and devices. The NDC space is then
transformed into the device coordinates (DC) of the workstation. When multiple
workstations are used, each may have a distinct view of the application by
setting its own workstation window. The last transformation allows the
workstation to set a viewport, the active region of the device's potential
workspace, which can be used for scaling and translating the original picture.
(Drawing impossible to translate to ASCII "graphics")
Figure 2: GKS provides a versatile set of viewing transformations. A
window may be defined in the application's conceptual "world space",
which selects a portion of that space to be viewed. The window is
mapped to an area or viewport in an intermediate virtual space called
the normalized-device-coordinate (NDC) space. This space appears
identical to all devices in the system. Each workstation can then
define its own window into the NDC space; each workstation window is
mapped to its own viewport on the device display surface. This
transformation allows each workstation to have a separate view of the
NDC space.
Graphics input
--------------
A full set of input operations allows an application program to receive input
from a broad range of interactive input devices. The input operations are
grouped into five classes: choice, locator, pick, string, and valuator. This
vital flexibility allows GKS to support the optimum input device for a
particular working environment. The result is improved interactivity through
which the full potential of the graphics man/machine interface can be
realized. The request-locator function returns the position of an image entity
in world coordinates, while the request-valuator function returns an
indication of the current value of a continuous valuator device such as a
potentiometer. The request-choice function returns an integer that represents
one of a set of choices. The pick function returns the graphics segment number
that corresponds to the objects being selected with graphics input. Finally,
the request-string function reads character input from a keyboard device. The
way in which these logical functions are implemented (through a joystick, a
mouse -- like the one used with the Apple Lisa --, function keys, etc.) is
workstation-dependent.
Inquiries
---------
To aid the programmer, GKS provides an inquire capability that allows the
application program to find out information about its system environment: the
current operating state, primitive attributes, viewing operations and
transformations, and device capabilities.
Device-level interfaces
-----------------------
Two emerging standards are addressing the hardware-driver interface level. One
of these, the North American Presentation-Level-Protocol Syntax (NAPLPS), was
developed by a team at Bell Laboratories as an extension of graphics
developments in the Canadian Telidon videotex system. NAPLPS (pronounced "nap-
lips") has been adopted by AT&T as a standard for transmitting text and
graphics over telecommunication lines. In some computer-graphics applications,
NAPLPS probably will "sit below" another, more general, device interface
called the Virtual Device Interface (VDI). This relationship is illustrated in
Figure 1, where the NAPLPS block is placed under the dashed line of the
Virtual Device Interface.
The VDI standard is being developed by the ANSI X3H33 Technical Committee as a
standard interface between device-independent software and graphics devices.
VDI makes all devices appear as identical virtual graphics devices by defining
a standard input/output protocol. The unique characteristics of the physical
graphics device are isolated in the device-driver software module. This
technique has been employed by individual vendors to make their own products
compatible with a wide range of devices, similar to the way operating systems
such as Unix or CP/M are interfaced to a multitude of hardware configurations.
VDI takes the concept a step further by providing potential industry-wide
compatibility.
The VDI specification is expected to be frozen during the Summer of 1983. For
the graphics-equipment manufacturer, the adoption of this standard means that
a VDI driver for a particular graphics device need be written only once. All
graphics applications that conform to VDI would then be able to communicate
with the device through the standard device driver. Long-range benefits will
be more evident as equipment and semiconductor manufacturers begin
implementing more of the software-driver functionality in hardware -- in
effect, moving the VDI interface down into the graphics device itself. This
development in graphics is a direct parallel to other standardization efforts,
such as the Shugart Associates Standard Interface (SASI) for disk-drive
subsystems. The SASI hardware and protocol specification allows OEMs (so-
called "Original Equipment Manufacturers") to freely mix disk subsystems and
host computers made by different firms. The popularity of this approach stems
from the many benefits it offers to the industry: less design effort expended
reinventing the wheel, numerous second sources of parts, higher reliability
with a proven design, reduced costs, and larger markets. Similar benefits will
accrue to computer graphics as a result of the standardization efforts that
are at last bearing fruit.
Graphics standards as products
------------------------------
Although the cost of hardware, especially semiconductor memory, is usually
cited as the major inhibitor to truly widespread use of interactive graphics,
this is becoming less and less accurate. The lack of universal standards has
dulled the impact of the dramatic reduction in component costs in the past
decade. The impending advent of these important standards paves the way for
implementations of computer graphics that will enjoy widespread availability
and economies of scale. The success of this approach has been demonstrated in
the microcomputer world by such de facto standards as the 8080-compatible
microprocessors and the CP/M operating system.
Digital Research Inc. (DRI), in collaboration with Graphics Software Systems
Inc. (GSS), has recently responded to the potential offered by the new
standards by expanding the capability of the CP/M family of operating systems
with an upgrade called the Graphics System Extension, or GSX. This upgrade
provides full graphics capabilities to the user through the normal CP/M
function-call access mechanism. The architecture of GSX has been carefully
designed to allow the extended CP/M to maintain compatibility with non-
graphics applications, and to use system resources in a way that is consistent
with a small-system environment, according to the structure shown in the
following figure.
┌────────────────────────────────────┐
│ Application layer │
│ ┌──────────────────────────────────┤
│ │ Language layer │
│ │ ┌────────────────────────────────┤
│ │ │ Graphical Kernel System (GKS) │
├─┴─┴────────────────────────────────┤
│ Operating System │
├────────────────┬───────────────────┤
│ CP/M │ GSX │
├────────────────┼───────────────────┤
│ Other hardware │ Graphics hardware │
└────────────────┴───────────────────┘
Figure 3: This layer model shows the relationship of GKS and VDI to
other components in a graphics system. Each module may call the
functions of the adjoining layer below. An example of this is the
Graphics System Extension (GSX) to the popular CP/M family of
operating systems.
Digital Research has also provided a package called GSS-Kernel that presents a
GKS interface to the graphics-application programmer using the graphics
functions provided by GSX. GSS-Kernel, a linkable run-time library, will
increase programmer productivity while providing program portability through
the standard GKS interface. In addition, applications using GSS-Kernel will be
source-code compatible with large computer systems running GKS procedures
libraries.
GSX architecture
----------------
GSX is composed of three major components: the Graphics-Device Operating
System, the Graphics Input/Output System, and the GENGRAF utility routine. The
Graphics-Device Operating System, or GDOS, is analogous to the BDOS (Basic
Disk Operating System) module in the standard CP/M system, and contains the
device-independent portion of GSX. The Graphics Input/Output System, or GIOS,
contains the device-dependent drivers which, like the Basic Input/Output
System (BIOS) in standard CP/M, provide the necessary "glue" to connect GDOS
with the particular characteristics and command sequences of a specific
graphics device. Finally, the GENGRAF utility configures a graphics-
application program to run in the GSX environment.
FFFF ┌──────┐
│ BIOS │
├──────┤
│ BDOS │<──┐
┌───├──────┤ │ Non-graphics
Device Driver--│-->│ GIOS │ │ function calls
GSX ─┤ ├──────┤ │
│ │ GDOS │<──┤
└───├──────┤ │ BDOS
│ TPA │ │ function
│ │ │ calls
0100 ├──────┤ │
│ Page │ │
│ Zero │───┘
0000 └──────┘
Figure 4: GSX consists of the device-independent (GDOS) and device-
dependent (GIOS) components. These are loaded at run time below the
BDOS module in high memory. Initial loading of GIOS and GDOS from the
disk is performed by a loader routine attached to the application
program by the GSX GENGRAF utility when the program is created. During
operation, graphics workstations may be changed by making a request to
GDOS that causes a new device driver to be loaded from the disk.
Figure 4 shows the relationship of software components of a GSX-extended CP/M-
80 system. GDOS and GIOS form a path to graphics devices that is essentially
parallel to the BDOS and the BIOS. Normal operating system calls, such as
reading from or writing to the console or a disk drive, are initiated by the
BDOS, and the BIOS provides the device-dependent interface. Graphics calls are
intercepted and serviced by GDOS, and passed to the appropriate device-
dependent driver within GIOS. In reality, only one device-driver routine is
resident in memory at any time; the other device drivers are stored on disk.
The application program may request use of a new workstation at any time, and
GSX will insure that the proper device driver is loaded as needed. This choice
of implementation maximizes the memory available for the application program.
Graphics-Device Operating System
--------------------------------
Access to all graphics operations is through function calls to GDOS, made in
the same manner as BDOS calls, except that an additional parameter list is
specified to transfer graphics information. This information includes a
graphics operation code, a control array, a parameter array, and a point
array. Point locations are passed to GSX in a normalized-device-coordinate
space. Here, all point locations are specified with x,y coordinates between
0,0 and 32767,32767. GDOS then transforms the NDC coordinates into the device
coordinate system through a scaling operation using device-specific
information that was passed when the current workstation was opened for use.
This scheme not only provides a VDI-compatible method of passing coordinate
values, but also allows points to be specified as integer arrays, thus saving
memory space and processing time.
GDOS is also responsible for dynamic workstation assignment. Each device on a
system is associated with a workstation-identification (ID) number. When GDOS
receives a request to assign a workstation (change the currently active
graphics device), it determines which driver corresponds to the indicated
workstation ID, and loads that driver into memory. The new driver is loaded
into memory in the same locations formerly occupied by the previous driver, so
that memory requirements are minimized. The logical association of workstation
ID number to a particular device is made through an assignment table, a text
file stored on the system disk. You can alter the correspondence of
workstation ID to specific device drivers simply by editing the assignment
table file with any text editor.
Graphics Input/Output System
----------------------------
The GIOS component of GSX contains the device-dependent code that translates
between the Virtual Device Interface and the unique characteristics of a real
graphics device, making all graphics devices appear to the application program
as identical virtual devices. The VDI specifies the pseudo-operation code for
a graphics operation, as well as a set of input and output arguments. The
input arguments include an array of control parameters, an array of input
parameters, and an array of input point coordinates. The output arguments
include control parameters, output parameters, and output point coordinates.
The control, input, and output parameters are unique to the particular
operation being performed (see Table 1).
Table 1. Operation codes available under the Graphics System Extension (GSX).
# Description
-- -----------
1 Open workstation: initialize a graphics device
(load driver routine if necessary)
2 Close workstation: stop graphics output to this workstation
3 Clear workstation: clear display surface
4 Update workstation: display all pending graphics on workstation
5 Escape: enable special device-dependent operation
6 Polyline: output a polyline
7 Polymarker: output markers
8 Text: output text starting at a specified position
9 Filled area: display and fill a polygon
10 Cell array: display a cell array
11 Generalized Drawing Primitive: display a GDP function
12 Set character height: set text size
13 Set character-up vector: Set text direction
14 Set color representation: define the color associated with a color #
15 Set polyline line type: set line style for polylines
16 Set polyline line width: set width of lines
17 Set polyline color index: set color for polylines
18 Set polymarker type: set marker type for polymarkers
19 Set polymarker height: set size for polymarkers
20 Set polymarker color index: set color for polymarkers
21 Set hardware text font: set device-dependent text style
22 Set text color index: set color of text
23 Set interior fill style: set interior style for polygon fill
24 Set fill style index: set fill style for polygons
25 Set fill color index: set color for polygon fill
26 Inquire color representation: return color representation values
27 Inquire cell array definition: return definition of cell array
28 Input locator: return value of locator
29 Input valuator: return value of valuator
30 Input choice: return value of choice device
31 Input string: return character string
32 Set writing mode: set current writing mode
(replace, overstrike, complement, erase)
33 Set input mode: set input mode (request or sample)
Often, the capabilities specified by the VDI standard are not provided by a
particular graphics device. In some cases, the device-driver software emulates
the required function. For example, four line styles are specified by VDI:
solid, dashed, dotted, and dashed-dotted. If a graphics device does not have
the ability to produce these directly, their automatic generation is emulated
in software. For example, if a dotted line cannot be produced by a device, the
required line style is produced by generating a series of short solid lines
with intervening spaces.
GENGRAF
-------
The final component of GSX is the GENGRAF program. GENGRAF is a utility
program used by the application programmer to configure a graphics program for
use with GSX. GENGRAF appends a special loader routine onto the graphics
program. This loader brings GDOS into memory, and loads the default graphics-
device driver before execution of the graphics program begins; therefore, GSX
(GDOS and GIOS) is brought into memory only when a graphics-application
program is executed. Otherwise, the programmer has use of the full user-
program space available under CP/M.
The loading and linking of GSX is completely transparent to the user at run
time. In CP/M-80, the linkage to GDOS is established by the GENGRAF loader at
run time by a substitution of the GDOS entry point in place of the normal BDOS
vector at memory location 5. GDOS intercepts all operating-system function
calls. If the call is a standard CP/M request, it passes control to BDOS; if
the function call is for a graphics operation, GDOS services the request.
Because GDOS is loaded below GIOS, memory is automatically allocated for GIOS
and GDOS; the size of the transient program area (TPA), determined by the GDOS
entry point, is automatically adjusted. The memory map in Figure 4 shows how
GDOS and GIOS are loaded into memory at run time below the standard CP/M-80
components, BDOS and BIOS. The GSX extension to CP/M-86 works slightly
differently, by reserving a special interrupt vector for GSX communications.
Also, the memory-management facilities of CP/M-86 take care of loading the GSX
modules into the free memory available.
Conclusion
----------
The adoption of the GKS and VDI standards at the programmer and device-
interface levels offers potential object-code portability for microcomputer
graphics-application programs. Not only will programmers see a consistent
interface to graphics functions in their high-level programming languages, but
compilers and graphics run-time libraries can be generic, with device
dependencies residing in the operating system. Because of this, each hardware
OEM will install the graphics portion of an operating system only once.
Compilers and other utilities that conform to the VDI standard will then be
able to access the virtual devices of a system without special adaptation. In
time, the hardware manufacturer, confident of a stable device interface, will
begin to place higher-level functions into the device hardware (or firmware).
Eventually, graphics devices may incorporate a full VDI interface, eliminating
the need for device drivers entirely.
New products, such as GSX and GSS-Kernel, that are based on the emerging
standards, will contribute to the realization of widespread, low-cost computer
graphics. In the past, the adoption of formal standards or the emergence of de
facto standards has proved to be a powerful market stimulant. Because of its
unique emphases on low cost and a competitive software environment, the
microcomputer industry is especially sensitive to the benefits of graphics
standardization. Graphics users owe a debt of gratitude to the many
researchers who distilled an inherently complex technology into a consistent
and flexible set of useful constructs. In the end, we shall all benefit from
the power of computer graphics.
EOF