ADAPTABILITY OF A GRAPHIC SYSTEM PROCESSOR TO

THE GRAPHICAL KERNEL SYSTEM

by

KALAR S. RAJENDIRAN, B.E.

A THESIS

IN

COMPUTER SCIENCE

Submitted to the Graduate Faculty of Texas Tech University in

Partial Fulfillment of the Requirements for

the Degree of

MASTER OF SCIENCE

Approved

Accepted

August, 1988

1 i

/ -o.'l^ C op' ^

ACKNOWLEDGEMENTS

I am deeply indebted to Dr. Mieheal Parten for his

guidance and support throughout this thesis. I am also

grateful to Dr. William Marey and Dr. Donald Gustafson for

serving on my committee and providing useful suggestions.

I would like to thank Texas Instruments Incorporated for

funding the project.

I would also like to thank my family and friends

for their love and encouragement, which enabled me to

undertake and complete my Master's Degree.

11

CONTENTS

ACKNOWLEDGEMENTS ii

LIST OF FIGURES vii

CHAPTER

I. NEED FOR A GRAPHICS STANDARD 1

II. GRAPHICAL KERNEL SYSTEM 3

Introduction 3

GKS Levels of Functionality 4

Generation of Application-Oriented

Subsets 4

Implementation Feasibility 4

Upward-Compatibility 5

Workstations 5

Coordinate Systems and Transformations 5

Coordinate Systems 5

Transformations 7

Windows and Viewports 7

Output 8

Output Primitives 8 Attribute Specifications 8

Segments 8

111

InputJ Introduction to

Logical Input Devices 9

Error Handling 12

III. PROBLEM STATEMENT AND PROPOSED WORK 13

Inherent Problems in Adopting

any Standard 13

Initial GKS Implementations 13

Problem in Implementing GKS on PCs 13

Advent of New Graphics Chips 14

Research Objective 14

Achieving the Research Objective 15

Choosing the Proper Chip 15

Choosing the Language of

Implementation 16

Design and Implementation 17

Testing 18

IV. TMS 34010 GRAPHIC SYSTEM PROCESSOR 19

Overview of TMS 34010 19

Developments Leading to the 34010 20

TMS 34010 Design Approach 21

TMS 34010 Execution Model 22

General Purpose Instructions 27

Graphics Instructions 2^

X-Y Addressing 29

1 V

PixBlT 31

Window Clipping 32

Pixel Processing 33

Plane Mask 34

Transparency 34

Expand 36

Single-Pixel Instructions 36

Compare Point to Window 38

Summary 38

V. FUNCTIONAL DESCRIPTION AND

IMPLEMENTATIONAL DETAILS 39

Introduction 39

Fill Area Function

and its Requirements 40

What the 34010 Offers 41

Can GKS Requirements be Easily M e f 44

Implementation Approach Adopted 44 Polyline Function

and its Requirements 47

What the 34010 Offers 48

Can GKS Requirements be Easily Met? 49

Implementation Approach Adopted 50

Text Function

and its Requirements 51 What the 34010 Offers 52

Can GKS Requirements be Easily M e f 52

Implementation Approach Adopted 54

Transformation Functions

and their Requirements 55

Normalization Transformation Functions 55

Workstation Transformation Functions 56

Clipping 57

What the 34010 Offers 57

Can GKS Requirements be Easily Met? 58

Summary 58

VI. CONCLUSION 59

Testing 59

GKS Text Function 59

GKS Filiarea Function 64

GKS Polyline Function 65

Extent of TMS 34010's Utilization 66

GKS Polyline Function 66

GKS Filiarea Function 66

GKS Text Function 67

Clipping 67

Result 68

Future Work 70

BIBLIOGRAPHY 72

APPENDIX 74

V 1

LIST OF FIGURES

4.1. Conversion from x-y address to linear address 30

4.2. Expansion of 1-bit-per-pixel representation to a color image 37

5.1. Testing whether P lies inside a Polygon 42

5.2. Types of Polygon 45

6.1. Text generated by GKS Text Function 60

6.2. Hollow Polygon generated by GKS Filiarea Function 60

6.3. Solid Polygon generated by GKS Filiarea Function 61

6.4. Pattern-filled Polygon generated by GKS Filiarea Function 61

6.5. Solid Polyline generated by GKS Polyline Function 62

6.6. Dashed Polyline generated by GKS Polyline Function 62

6.7. Dotted Polyline generated by GKS Polyline Function 63

6.8. Dashed-Dotted Polyline generated by GKS Polyline Function 63

v 1 1

CHAPTER I

NEED FOR A GRAPHICS STANDARD

The old proverb "a picture is worth a thousand words"

is as true for computer systems as for other media.

Naturally, computer graphics is the most versatile and

most powerful means of communication between a computer

and a human being. Hence, the fact that the origins of

computer graphics can be traced back almost to the advent

of digital computers should not come as a surprise to

anyone. Since then, graphics hardware technology has

evolved rapidly with time, producing better and better

graphics devices. As each new device hit the market, many

different graphics application software packages were

written by different software vendors to exploit the

special features of each device. Many of these software

packages would work only on one computer system. The

source of incompatibility was in-line graphics calls to

system-dependent functions. This approach resulted in

application software that was difficult* if not

impossible, to transport to other computers. This

underlined the urgent and compelling need - or a

universally accepted, hardware-independent graphics

standard.

Basically, the standard was to provide the general

graphics capabilities required by application programs

through standard functions with a fixed number of

parameters. Each computer graphics system was expected to

make these standard graphics functions available to

application programs. The use of system-dependent graphics

function calls was to be restricted to within these

standard graphics functions. The application programmer

could then concentrate on his specific problem without

having to develop graphics capabilities as well. The

strongest single justification for the development of a

standard was the promotion of program portability.

However, programmer portability, that is, the ability of

an application programmer to move from one installation to

another with minimal retraining, was another strong point

in favor of a standard.

CHAPTER II

GRAPHICAL KERNEL SYSTEM

Introduction

The Graphical Kernel System (GKS), which is the

subject of this chapter, covers the most significant parts

of computer graphics. The Graphical Kernel System is the

first international standard for programming computer

graphics applications. It offers functions for picture

generation, picture presentation, segmentation,

transformations and input. However, the extent of the

functional capabilities is not the only important aspect

of the standardization of the Graphical Kernel System.

There is an even more important advantage of the GKS

standardization.

For the first time, a methodological framework for

the various concepts within the field of computer graphics

has been developed. This is the base for a common

understanding and a common terminology for creating

computer graphics systems, for using computer graphics,

for talking about computer graphics and for educating

students in computer graphics methods, concepts and

app1icati ons.

GKS Levels of Functionalitv

GKS, as a general-purpose graphical kernel system, is

designed to address most of the existing graphics devices

as well as most graphics applications. GKS systems have to

be installed on various processors with different

qualities like restricted memory sizes, slow external

storage media, and virtual memory management.

Obviously, it is not sensible to use one fixed GKS

system for all the different purposes. Rather, it is

desirable to tailor GKS to the special qualities of the

specific environments existing at each time. An important

means for adapting a GKS system to achieve the above

mentioned goal is provided by the definition of suitable

subsystems, called levels.

Generation of Application-Oriented

Subsets

For every representative set of application classes,

a suitable subset of graphics functions was selected?

thus, no extra burden in acquiring, installing, learning,

memorizing, and handling unnecessary functions is placed

upon the system and application programmers.

Implementation Feasibility

The capabilities of the overall GKS are distributed

among the levels in such a way that subsystems of

considerably smaller program sizes can be implemented.

This is accomplished by isolating specific concepts and

assigning them to the single levels. Thus, concepts can be

integrated or omitted as a whole. This decreases

compilation, linkage editor, and program performance time

and supports the usage of small memory machines.

Upward-Compatibility

All GKS functions are defined to have identical

effects on all levels in which they exist. Regardless of

which GKS level an application program is written for, it

will run on every higher level achieving the same results.

Workstations

GKS develops the concept of a workstation which, in

its simplest form, is a single display area that may or

may not have input capabilities. An application program

may be concurrently connected to one or more workstations,

with the graphics it produces displayed on all active

workstations. The application program may also dynamically

open and close workstations.

Coordinate Systems and Transformations

Coordinate Systems

It IS common practice for an application programmer

to define his graphical elements in a coordinate system

that is related to his application. Output devices that

are used for presenting the visual image of the elements,

however, normally require the use of a device specific

coordinate system. In order to meet these requirements

while maintaining device independence, three coordinate

systems (WC, NDC, and DC) have been defined in GKS as

explained below. The application programmer uses the world

coordinate <WC) system for specifying picture elements.

The world coordinate system is the standard user

coordinate system. Conceptually, every output primitive is

defined with its own world coordinate system.

Since different output devices have different device

coordinate systems, GKS defines, as an abstraction of

these device coordinate systems, one single normalized

device coordinate (NDC) space. The relative positioning of

output primitives is defined by mapping all the defined

world coordinate systems onto the NDC space.

Although NDC space conceptually extends to infinity,

the part of NDC space in which the viewport must be

located and that can be viewed at a workstation is the

closed range CO,l]xCO,l]. The normalized picture in NDC

space can be stored and manipulated via the segment

mechan i sm.

The NDC space is mapped onto the device coordinates

(DC) of every workstation that is to display the picture.

Every type of workstation may have a different device

coordinate space and a different mapping. The device

coordinate space is always a bounded space since it

represents the extension of the display surface of a

physical, and hence bounded, device.

Transformations

A transformation that defines the mapping from the

world coordinate system onto the single NDC space is

re-ferred to as a normalization transformation. A

transformation that defines the mapping of NDC space to

any one of the active workstations is re-ferred to as a

workstation transformation. Other types of trans­

formations can be applied to segments and take place in

the NDC space.

Wi ndows and Vi ewports

In GKS, the rectangular portion of a plane that

coordinates come from is called a window, and the

rectangular portion of a plane that coordinates map into

IS called the viewport.

Through the use of windows and viewports, GKS can

select different portions of the virtual picture and

8

display it in a specified portion of each workstation

display surface. The viewport for a device is expressed in

device coordinates.

Output

Output Primitives

Output primitives are the functions used to construct

graphic images (e.g., draw a line, fill a polygon, draw

text, etc.).

Attribute Specifications

This is the ability to specify how various primitives

will appear (e.g., a line can be drawn with different

styles, color, and width). Furthermore, GKS defines a

conceptual model for specifying attributes, called

bundling.

Segments

GKS provides a way to collect and store the

primitives that make up all or part of a picture. Such a

collection of primitives is called a "segment," which is a

group of graphic output primitives identified by a unique

name. Segments may be made visible or invisible,

highlighted, deleted, renamed, transformed, assigned a

priority and made detectable or undetectable.

Input: Introduction to Logical Input Devices

An application program using a GKS implementation

obtains graphical input from an operator by controlling

logical input devices which deliver logical input values

to the program. If, for instance, a position is required

in an application program, a "LOCATOR" device is to be

selected (instead of a physical cursor device). If a

character string is required, the logical device "STRING"

has to be used (instead of a physical keyboard). Whereas

the application program can control the available logical

input devices, the mapping o-f logical to physical devices

is done by the implementation.

Log ical Input CI asses and Values

GKS provides six logical input classes namely

LOCATOR, STROKE, VALUATOR, CHOICE, PICK, and STRING. Each

input class determines the type of logical input value

that the logical input device delivers. The six input

classes and the logical input values they provide are as

foilows.

Locator

A position in world coordinates (a pair ot REAL

numoers) and a normalization transformation number.

10

stroke

A sequence of positions in world coordinates and a

normalization transformation number.

Valuator

A REAL number.

Choice

A non-negative INTEGER value which represents a

selection from a number of choices. A zero indicates "no

choice. "

Pick

A PICK status (OK,NOPICK), a segment name and a pick

identifier. Primitives outside segments cannot be picked.

String

A string of CHARACTERS.

Openating Modes

Each logical input device can be operated in tnrae

modes, called operating modes. At any time, it is in one f

and only one, oi^ the modes set by the invocation of a

function in the group SET <input class) MODE. The tnrqo

operating modes are REQUEST, SAMPLE and EVENT. Input f'-om

devices is obtained in different ways depending on the

mode.

11

Request

A specific invocation of REQUEST <input class)

causes an attempt to read a logical input value from a

specified logical input device, which must be in REQUEST

mode. GKS waits until the input is entered by the operator

or a break action is performed by the operator. The break

action IS dependent on the logical input device and on the

implementation. If the break occurs, the logical input

value IS not valid.

Samp 1e

A specific invocation of SAMPLE (input class) causes

GKS (without waiting for an operator action) to return the

current logical input value o-f a specified logical device,

which must be in SAMPLE mode.

Event

GKS maintains one input queue containing temporally

ordered event reports. An event report contains the

identification of a logical input aevice and a logical

input value from that device. Event reports are generated

asynchronously, by operator action only, from input

devices in EVENT mode.

The application program can remove the oiaest event

report from the queue, and examine its contents. The

12

application can also flush all event reports of a

specified logical device from the queue.

Error Handling

GKS has a well defined set of errors which will be

reported back to the application program. The philosophy

adopted is that all errors are reported by putting details

of the error in the error file which was specified when

GKS was opened. A typical error will record the following

i nformation.

1) An error number indicating which error has

occurred.

2) The name o-f the GKS function that was being

executed when the error was detected.

There is a full set o-f error numbers so that a

particular error can be precisely identified. What happens

when an error has been recognized depends on the

application program. If no special action has been

specified, GKS calls the installation supplied error

handling procedure.

CHAPTER III

PROBLEM STATEMENT AND PROPOSED WORK

Inherent Problems in Adopting any Standard

When standard interfaces are written into software,

they are implemented with complex algorithms that execute

slowly, resulting in performance loss C8]. Graphics

standard interfaces are no exception to this. But the

effect of performance loss is accenuated in the case o-f

graphics. This is very often the reason software vendors

bypass standards in order to gain better performance.

Initial GKS Implementations

Initial implementations of GKS were designed to run

on main-frames and mi n i-computer s because o-f their fast

floating-point hardware, high processor cycle times, large

memory (or at least virtual memory system), etc. With

personal computers becoming more popular and memory costs

beginning to drop, the implementation of GKS on PCs is

becoming desirable.

Prob1 em 1n Imp 1emen11ng GKS on PCs

The processors powering most o-f the personal

computers do not support any special graphics

instructions. This makes it necessary to implement certain

graphics functions using complex algorithms. Conseaupntlv.

13

14

the code of a graphics system on these processors becomes

large and inefficient. If the graphics system were

implemented using GKS specifications, the system would

become even more inefficient due to the more general

nature and additional functions needed in the code.

Implementing GKS on a PC has not seemed very attractive.

Advent of New Graphics Chips

Texas Instruments, Intel, and Advanced Micro Devices

have recently developed new graphics chips. The companies

claim that their chips will improve the graphics

performance of personal computers tremendously. These new

graphics processor chips may allow an efficient GKS

implementation on a PC.

Research Obi ective

Graphical Kernel System (GKS) was defined before

graphics processors became available for PCs. The research

objective is to determine if GKS is a viable standard for

the TMS 34010 Graphic System Processor (available for

PCs), by implementing portions of GKS on it and

determining if the implementation makes use of the power

of the graphics processor.

15

Achieving the Research Objective

Choosing the Proper Chip

The TMS34010 Graphic System Processor was chosen for

our GKS implementation based on the following criteria.

a) The first and most important requirement is the

compatibility of the chip being chosen, with the family of

most popular personal computer models (IBM PC and its

clones). The TMS34010 GSP can easily be interfaced to the

TI PCs, IBM PCs and its compatibles.

b) The GSP chip is a general-purpose processor chip

with special graphics capabilities in contrast to the

chips from other manufacturers.

e) Graphics operations require the manipulation of

many variables during the drawing process and the

availability of many general purpose registers enhances

the speed of operation by reducing time-consuming data

swapping between memory and registers. The TMS34010 GSP

has a total of 31 32-bit registers.

d) The horizontal and vertical timing of a raster

display system is usually fixed. So the sweeper must

provide new data at precise intervals. For this reason,

the sweeper is given priority access to the frame buffer.

On high resolution systems, this decision can have a

significant impact on performance. The period of time the

16

frame buffer is not used by the sweeper is the time

alloted to the processor to manipulate graphic data to be

displayed. With conventional memory components, this

percentage of time approaches zero as display resolution

increases. This problem can be solved by using Video RAM.

(VRAMs consist of a conventional memory element and a

large shift register. The shift register is loaded with a

number of bits with a single memory cycle. These bits can

then be shifted out independently of other access to the

memory element.) The TMS34010 GSP has built-in VRAM

interface and display control circuitry in contrast to the

chips from other manufacturers.

e) The GSP has on-chip instruction cache which also

helps in improving the performance.

Choosing the Language of Implementation

Choosing a programming language for a particular

application is based on three criteria, namely,

1) application characteristic,

2) language features required, and

3) practical considerations.

Application Characteristic

This characterizes the kind of application on hand,

I.e., scientific, systems, business, etc. In this case,

17

it is "systems" and one of the best suited languages for

this application is the "C" language.

Language Features Required

"C" is a structured programming language which

provides a lot of different data types including user-

defined data types. This will prove very helpful for our

implementation.

Practical Considerations

The portability of "C" language is very high and a

"C" compiler is available for the TMS34010 GSP. Also the

"C" language is gaining in popularity and should stay in

widespread use for a long time to come (Wherever the

advanced/special features of the TMS34010 can be taken

advantage of, TMS34010 assembly language will be used).

Design and Implementation

The data structures required to support the following

GKS functions will be designed and the functions

themselves will be implemented. These functions were

chosen for implementation because they are the basic

graphical functions of "Minimal GKS" C173, which is a

subset of the Graphical Kernel System standard. Research

conducted at Sandia Laboratories has demonstrated that

18

Minimal GKS is easy to learn and use, yet powerful enough

for non-trivial, real-world applications. Hence, these

functions are expected to help in achieving the research

objective mentioned before.

FILL AREA POLYLINE SELECT NORMALIZATION TRANSFORMATION SET CHARACTER HEIGHT SET LINETYPE SET CLIPPING INDICATOR SET POLYLINE COLOUR INDEX SET FILL AREA COLOUR INDEX SET COLOUR REPRESENTATION SET TEXT COLOUR INDEX SET VIEWPORT SET WINDOW SET WORKSTATION VIEWPORT SET WORKSTATION WINDOW TEXT

For a major portion of the implementation, "C"

language (TMS34010 "C" Compiler) will be used. Wherever

the advanced features of the TMS34010 can be taken

advantage of, TMS34010 assembly language will be used.

Testing

Each function will be tested for correctness. A

demonstration program will be written using the

implemented functions.

CHAPTER IV

TMS 34010 GRAPHIC SYSTEM PROCESSOR

Overview of TMS 34010

The TMS 34010 Graphics System Processor is a 32-bit

graphics microprocessor capable of executing high-level

languages. It combines a full general-purpose instruction

set with a powerful set of graphics instructions that

includes arithmetic as well as Boolean pixblts (pixel

block transfers). Because it is completely programmable,

the 34010 can be used in many different graphics and

nongraphics applications. It was designed to support a

wide range of display resolutions and pixel sizes, as well

as applications such as LASER printers, ink jet printers,

data compression, and facsimile transmission.

The 34010 includes such system features as an onboard

instruction cache, full interrupt capability, wait and

hold functions, and display timing control, as well as

test and emulation support. Unique among today's

microprocessors, the 34010 addresses all memory down to

the bit level with variably sized fields rather than the

common byte or word addressing. For example, the 34010 can

push a 5-bit quantity onto a stack. This field-processing

capability is an integral part of the basic architecture.

19

20

Developments Leading to the 34010

The developments leading to the 34010 began at Texas

Instruments four years ago. Bitmapped graphics was just

starting to find wide use in high-end systems where color

was important, and the dominance of vector stroke/scanned

high-end graphics systems was diminishing. Terminal and

personal computer text displays were almost exclusively

handled by hardwired text controllers that generated text

typically of 80 columns by 25 rows.

Groups such as those at Xerox, Palo Alto Research

Center were demonstrating that bitmapped graphics could

provide better human interfaces and text capabilities as

well as more advanced graphics. The improved capability

and falling cost of dynamic RAMs indicated that bitmapped

graphics would soon be widely used in almost all display

systems.

During this period the first VLSI devices aimed at

bitmapped graphics were introduced. These chips provided

hardwired implementations of a few graphics primitives

such as one-pixel-wide line and circle drawings, but text

was generated by a hardwired block text display mode that

was not compatible with the display of bitmapped graphics.

Texas Instruments decided that to simply extend the number

of hardwired algorithms would be a fundamental mistake for

sev eral reasons, specifically:

21

1) The number of functions would be fixed. Not only

would hardwiring support relatively few algorithms, but «

new or different algorithms could not be supported.

2) Even the most basic functions could require many

attributes such as line style, width, color, and endpoint

shape. Hardwiring would mean selecting the attributes to

be supported and those to be left out.

3) Customers' experience in quality graphics

absolutely required very fine control over the algorithms.

Conceptually, drawing to a bitmap means selecting the

nearest "integer" pixel, and thus some rounding error

shows up as "jaggies" or aliasing.

4) The format of display lists or commands varies

according to user requirements. For example, simple block

text might require a simple format, while variably sized

text requires more complex display lists. The only way to

support any format is to have a programmable processor

interpret the commands.

TMS 34010 Design Approach

The 34010 designers removed all arbitrary barriers

imposed by hardwired controllers on both text and

graphics. With the 34010, graphics algorithms could be

added as required by a particular application or graphics

standard. General purpose instructions have been used to

22

interpret display lists with special graphics instructions

used for fast pixel manipulations. A complete general-

purpose instruction set that could support high-level

language programming (such as C) has been blended with

very powerful graphics instructions such as the pixblts.

The 34010 has been designed to give this flexibility

without sacrificing speed in comparison with the hardwired

controllers. Hardware such as an instruction cache, a

large register file, a barrel shifter, a field mask, etc.,

have been added for the efficient implementation of any

function.

TMS 34010 Execution Model

The 34010 has a 32-bit internal architecture. The CPU

is made up of a 256-byte instruction cache? control ROM

(CROM) and control logic? and the data path, which

includes two 32-bit ALUs, barrel shifter, mask-merge

logic, 31 32-bit user registers, left-most-one detection

hardware, and window comparators. In addition to the CPU,

the 34010 has CRT control, DRAM (Dynamic RAM) interface, a

separate host processor interface, and an independent

memory processor that pipelines accesses to the memory

while arbitrating between the various sources generating

requests--al1 integrated on a single chip.

23

The 34010 combines some of the best attributes of the

so-called RISC (Reduced Instruction Set Computer) and CISC

(Complex Instruction Set Computer) approaches into a

single architecture. Each approach has its merits, and the

design goal with the 34010 was to properly blend these

merits. Consistent with the Berkeley RISC concepts, the

34010 has a large register file, simple direct-instruction

decoding, low instruction pipelining for fast jumps, move-

to-register instructions that zero-extend or (optionally)

sign-extend external operands of different sizes to the

full register size of 32-bits, and fast register-to-

register operations. However, unlike the Berkeley RISC

machine and similar to CISC machines, the 34010 allows for

multiple-cycle instructions such as multiplies, divides,

and the very complex pixblt instructions? pipelined

writing to memory? memory-to-memory move instructions? and

a wider selection of addressing modes. Additionally, the

34010''s instruction cache boosts performance without

requiring very fast external memory.

Every memory-to-register, register-to-memory, or

memory-to-memory operation is in effect a field extract or

field insert. For example, a memory-to-register move

operation involves reading a field at a given bit address

in memory and either sign-extends or zero-extends the

24

number to 32-bits before it goes into a register. Memory-

to-memory move instructions involve reading (extracting) a

field at one bit address and storing (inserting) the field

at a second bit address. These operations can involve

reading, barrel shifting, merging data, and performing

read-modify-write operations.

The 31 registers in the register file are organized

as two registers, the A and B files, which share the stack

pointer. Effectively, the stack pointer can be thought of

as both A15 and B15. All of the registers can be used as

address or data registers. Of these, only the stack-

pointer register is fully dedicated in that it is assumed

to point to the stack on which context information is

saved in the event of interrupts or subroutine calls. The

more complicated graphics functions use some or all of the

B file registers as default parameters. When these

graphics functions are not being used, these registers can

serve any purpose. The A file registers have no predefined

function in any instruction and are therefore totally at

the user's disposal.

The single-register operand instructions can use any

of the 31 registers. With two-register operand

instructions, all 31 registers are available as the source

operand register, but the destination register must be

from the same register file (either A or B) as the source.

25

The move register to register is an exception in that it

can be used to move an A file register to a B file

register or vice versa. Also, as mentioned earlier, the

stack pointer is in both files, so that data from either

file can be moved to or from the stack.

In typical applications, the large register file can

greatly improve performance, as all frequently used

variables can be kept in the file for fast access and

manipulation. An advantage with the 34010's register file

is the ability to support the mixture of high-level-

language control and assembly-coded, time-critical

functions in separate register files and thus accelerate

context switches. The first C compiler used only 13 of the

A file registers (more than some other 32-bit CPUs have),

leaving the B file totally free for assembly code. These

registers will often be used by graphics instructions,

which can involve many parameters. For example, the

complex pixblt uses 15 registers to specify all the

possible parameters and to store intermediate variables in

the case of an interrupt.

Much of the 34010's power comes from the microcode

contained in the CROM, which controls all of the hardware

in the CPU. There are 808 microstates and 166 outputs, and

26

nearly half of this very large CROM is devoted to the

implementation of the pixblt instructions.

The 256 bytes in the instruction cache are organized

as four segments of 32 16-bit words each. Each segment has

a corresponding register which contains the base address

of the section of memory from which the segment can be

loaded. Thus the 34010 can execute code from the cache,

which is located in four completely separate areas of

memory. The four segments of memory can also be

contiguous, allowing fairly lengthy loops to reside

entirely in cache. If execution begins in a new area of

memory, the new segment replaces the least recently used

segment.

These replacements are controlled by the LRU

register, which retains a record of the segment least

recently used. Segments are further divided into eight

subsegments, each with an associated "present flag" to

indicate whether the subsegment has actually been loaded.

Segments are loaded one subsegment at a time. Thus a

segment would be brought into a cache by loading and

executing four words, bringing in the next four, and so

on

27

General Purpose Instructions

The general-purpose instructions of the 34010 are

designed to support a complete programming environment,

including the use of high-level languages.

As mentioned earlier, the 34010 supports bit

addressing and fields rather the more common byte

addressing. Consequently, all memory operations involve

field extraction and/or insertion. The data quantities

moved are specified by one of two field sizes, which are

programmable and contained in the status register. The

field size can be from 1 to 32 bits in length and can

begin on arbitrary bit boundaries within a memory word.

When data moves from memory into a register, the

field is right justified and either sign- or zero-extended

to 32 bits. Register-to-register Boolean, arithmetic, and

shift instructions then use the 32-bit data paths to

perform 32-bit operations in a single CPU cycle.

The addressing modes for the MOVE instructions

reflect the register-based nature of the machine.

Register-to-memory, memory-to-register, and memory-to-

memory moves are supported for the five types of

addressing modes. These are register indirect, register

indirect predecrement (by the field size), register

indirect postincrement (also by the field size), register

28

indirect with displacement, and absolute addressing. The

34010's large register file and fast register-to-register

instructions make it easy to synthesize more complicated

addressing modes.

The integer arithmetic instructions include addition,

subtraction, add with carry, subtract with borrow, and

signed and unsigned multiplication and division. Most

simple integer operations and all eight Boolean operations

execute at six million instructions per second out of the

instruction cache. The signed and unsigned multiplications

use 2-bits-at-a-time hardware to give a 64-bit product in

roughly 3 micro-seconds.

The barrel shifter and sign control logic are used to

perform rotate left/right, shift left logical, shift right

arithmetic and shift right logical by any amount

(specified either in a register or as a constant) from 1

to 32 bits in a single CPU cycle.

The program flow control instructions give the user

conditional jumps, subroutine calls and returns,

deerement-skip-jump instructions for looping, program

counter and register exchange, and 32 software traps. The

34010 is designed to execute conditional jumps quickly,

requiring only one cycle if the jump is not taken and two

if the jump is taken.

29

Instructions are also included for status register

modification, including interrupt enabling/disabling and

setting of the field size and field extension control.

Graphics Instructions

In addition to the conventional linear addressing,

the 34010 supports an optional x-y addressing function for

graphics instructions. Most of these instructions provide

a choice between x-y and linear addressing. For example,

the pixblt instruction allows the source and destination

array pointers to be in either format. Consequently there

are four different versions of the instruction.

X-Y Addressing

With x-y addressing, a single 32-bit value is treated

as separate 16-bit x and y halves. The two 16-bit values

are converted automatically--within the instructions that

use x-y addressing--to a linear address needed by

memories. The generation of the linear address is a

function of the x and y values, the x-y array's "pitch"

(the linear address difference between two vertically

adjacent pixels), and a 32-bit offset that allows the x-y

address to be relative to any point in memory. The

conversion process is shown in Figure 4.1. The clipping of

30

Pitch

\ onsM

(y^) 4

16 BITS

Z

16 BITS

z Y Address X Address Mat.

Unear Offset

T 32-Bit Linear Address

Y Address X Address

Figure 4.i: Conversion from x-y address to linear address

31

figures and arrays to fit within a rectangular region is

also supported by x-y addressing.

Other instructions for x-y address manipulation

perform x-y addition, subtraction, and comparison. Moves

between registers of x or y halves are also provided.

PixBlT

The pixel block transfer instructions give the user a

powerful tool for manipulating two-dimensional arrays of

pixels. Pixblt supports the combinations of two

rectangular arrays of pixels using any of the 22 Boolean

and arithmetic pixel processing operations, plus

transparency, plane masking, and window clipping options.

In addition to simple filling, the FILL instruction

supports a single value operating on a rectangular array

of pixels with any of the pixel processing options.

The basic pixblt instruction combines the pixels in

the source array with those in the specified destination

array. The relative word alignments of the source and

destination arrays can be totally arbitrary. Edge

conditions are taken care of, and pixels are moved a

memory word at a time except at the edges, where read-

modif y-wr ites may have to be performed. An add'^d

complication for the two-array transfer is the bit

alignment of the source and destination arrays, which may

32

be aligned differently with respect to memory word

boundaries. Thus the source data must be shifted to align

to the destination location before it can be written. This

instruction aligns the source and destination arrays

automatically and with very little, if any, decrease in

performance.

An important feature supported in pixblts is the

ability to have different values for the source and

destination pitches. For example, an array only 16 bits

wide can be stored off screen packed as 16-bit words. When

transferred to the bitmap, the source pitch is 16 bits,

while the destination pitch is the number of bits in one

line of display memory.

Window Clipping

A window is specified as a rectangular region that is

optionally protected from being overwritten. Probably the

most common use is the implementation of a viewport

concept. Only the pixels that lie within the window are

written to the bitmap.

Four different window clipping options are supported.

The "no clipping" option ignores windowing boundaries and

does not protect any pixels. The "clip-to-fit" option

prohibits pixels outside the window from being written.

The "interrupt on window violation" immediately aborts the

33

operation if any point in an operation will lie outside

the window. The window violation interrupt is then set and

will be taken immediately if it is enabled. The "pick"

option determines whether any pixel lies within the

window. With the pick option, all pixel drawing is

inhibited and the window violation interrupt is issued

whenever a pixel would be drawn within the pick region.

For the pixblt instructions with the clip-to-fit

option, the destination array is preclipped to the window

before any data is transferred. This preclipping avoids

the potential waste of large amounts of time computing

addresses ^or pixel transfers that will end up being

clipped. Adjustment of the source array is based on

adjustment of the destination array.

Pixel Processing

Every pixel transferred with the graphics

instructions of the 34010 can use pixel processing

operations, which combine each source pixel with the

corresponding destination pixel before overwriting the

destination pixel with the result. Both logical and

arithmetic processing are supported. Less familiar but

very important for pixblts are thp arithmetic operations

that operate on entire pixels rather than on the

ndividual bits within pixels. For multiple-bits-per-pixe1

34

applications, these operations are not only desirable but

necessary. Six of these options are supported. The entire

list of 22 pixel processing options is shown in Table 1.

Plane Mask

The plane mask enables the user to inhibit writes to

some or all of the bits within a pixel. For example, when

a pixel contains information for a group of planes, the

bits associated with a given plane or planes can be

protected. Thus text can be modified in one plane while

the graphics information in other planes remains

unaffected. This mask is applied to pixel data as it is

read into the chip as well as to the data to be written

externally.

Transparency

Transparency detection can be selected to treat zero-

value pixels as transparent. This detection is applied to

the result of pixel processing and plane masking. With

transparency enabled, a pixel o-f zero value does not

overwrite the destination pixel, leaving the background

unchanged. In this way, only the part of a rectangular

array that makes up the desired shape (such as a text

character) is actually written. The overlaying of text on

graphics then becomes a very simple task.

35

TABLE IJ The 22 pixe1-processing options

PP

00000 00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 01101 OHIO 01111

s s

s s

s s

s s-

Operation

s AND D AND D-

0 OR

XNOR

Description

> D Replace > D AND sour > D AND sour > D Replace

D- -> D OR sourc D -> D XNOR sou D- -> D Negate d

NOR D -> D NOR sour OR D -> D OR sourc

D -> D No Chang XOR D -> D XOR sour AND D -> D AND NOT

1 -> D Replace S- OR D -> D OR NOT s S NAND D -> D NAND sou

S- -> D Replace de

desti ce wi ce wi desti e wit rce w estin ce wi e wit e in ce wi sourc desti ource rce w st ina

nation th dest th NOT nation h NOT d ith des ation. th dest h desti destina th dest e with nation with d ith des tion wi

with source, ination. destination, with zeroes, estination. tination.

ination. nation. tion. ination. destination. with ones. estination. tination. th NOT source.

Although the destination array is not changed by this operation, memory cycles still occur.

The following six pixel-processing codes perform

arithmetic operations on pixels of size 4, 8, and 16 bits

PP Operation Descr iption

10000 D • S -> D 10001 ADDS(D,S) -> D 10010 D - S -> D 10011 SUBS(D,S) -> D 10100 MAX(D,S) -> D 10101 MIN(D,S) -> D

Add source to destination Add S to D with saturation Subtract source from destination Subtract S from D with saturation Maximum of source and destination Minimum of source and destination

36

Expand

The pixblt with expand option is very useful for

transforming a 1-bit-per-pixel shape such as a text font

to a color image in the bitmap. Each pixel is expanded

from 1 bit to either a "one color" or "zero color," which

can be 1, 2, 4, 8, or 16 bits in length. This process is

illustrated in Figure 4.2. After expansion, any of the

arithmetic and Boolean operations can be applied, as well

as such options as transparency and plane masking.

Single-Pixel Instructions

There are several instructions for manipulating

individual pixels. A set of single-pixel transfer (pixt)

instructions supports both x-y and linear addressing for

either the source or destination pointers. Windowing,

pixel processing options, transparency, and plane masking

are all supported for this instruction.

The Draw and Advance (DRAV) provides the basis for

incrementally drawing figures such as lines and circles.

This instruction combines a single-pixel draw (with pixel

processing operations) with an addition to both the x and

y halves of an x-y address pointer.

37

PfxBIt WITH EXPAND 4 BITS/PIXEL EXAMPLE

BRING 4 SIT "BWAflY- OR IJNEXPANOEO' IMAGE INTO GSP FOR EXPANSION

IREGJSTER

| 5pm i nToin fornoTTi ^EEB'^^^ EXECUnE eCPANO

i f e m (Oiohol f o i o ^ (0 l ] fe«^SULTANT 16 BfT EXPANDED IMAGE \MTH PITCH2 OISPLACEMENT

•••••••••••••••••••••a •^•B ••••«•••••••••••••••••••••••• - - , •••••«••••••••••••••• ' • •• -• #•••, ••••••^^••••••••••••••••••••s

•••• ••••• •••••••••••••••••••••v''V*vas* ••* •«••• ••••«•••••••••••••••• »•••• •••••• ••••••••••••••••••••• •••«•• •«-. •••«•«.. • ••• . •••«•«• •••••••••••••••««•«••.: «aa«a«9 ••• ••«•«• . • •••' •••••• ••• , «•••••«•>••••••« •••••A •*. ••••••^ •••••••«••••••••••••• • " T ' * * n * • • • • • • • • • • • • • • • • • • • a i . a A B A A • • « - • • • • • A > • • • • • • « • « • • • • • • • • • • • • • • « • - lB««Ba««aaaa«B««aasaaaa . . 4 * « * • • •

- _ ' • •a8aaa«aa*B«a««aa«aaaa« • d a a a . aaa ' a v n a a a a a a a

' aaaaa.^ aaaaaS a a •aaaafli aaaaaafl • •

a a S ^ • • • a a a * ' aaaaaai • aa««a

' Snaaaaaaaaaaaaaaaaaa^^^^l • . aaaaaaaaaaaaaaaaaaaaa^^^^

a* » aaaaaaaa* i a a « mmm aas ^ ^ Baaaa

•iiiiniiiiiiiiiiiiiiiniiimiT'" I I

aaaa«a«aa««a«aa»aaa«a«aa«aaaaaaaa««aaaaa»2rr»

OFF SCREEN DATA MEMORY

IN PfTCHI OISPLACEMENT (BINARY FONT

TA8LQ

n»»»»m»»»{»{»»»l{»»»»

worn WORD N • 4 SCREEN IMAGE

OFF-SCREEN MEMORY

F i g u r e 4*2* E x p a n s i o n of 1 - b i t - p e r - p i x e l r e p r e s e n t a t i o n t o a c o l o r image

38

Compare Point to Window

One additional instruction extremely useful in the

software implementation of many graphics algorithms is

Compare Point to Window (CPW). Executing in a single

cycle, CPW compares the x and y values of a given point to

the corresponding values of both the window start and

window end registers, generating a 4-bit code. This code

indicates in which of the nine regions relative to the

window the point lies. This concept, is best known for its

use in the Cohen-Sutherland line clipping algorithm.

Summary

The design philosophy was, to support whatever

graphics functions are required in any application rather

than to restrict graphics to a few primitive functions.

Consequently, the 34010 provides a unique combination of

general programmabi1ity and graphics processing power on a

single integrated chip. As a result, systems developers

can program the 34010 to do any graphics or non-graphics

task.

CHAPTER V

FUNCTIONAL DESCRIPTION AND

IMPLEMENTATIONAL DETAILS

Introduction

The GKS standard, as already discussed in chapter II,

is based upon the seven major conceptual elements, which

are output, input, workstations, coordinate systems and

transformations, windows and viewports, segments, and

levels of functionality. They were chosen in order to

provide a set of functions for computer graphics

programming that can be used by a majority of applications

that produce computer generated pictures.

The purpose of this chapter is to discuss in detail

the different GKS functions that have been implemented to

help achieve the research objective, which is to determine

if GKS is a viable standard for the TMS 34010 Graphic

System Processor available ior PCs. These functions were

chosen for the implementation because they are the

basic graphical functions of "Minimal GKS" C17], which is a

subset of the Graphical Kernel System standard. Research

conducted at Sandia Laboratories has demonstrated that

Minimal GKS is easy to learn and use, yet powerful enough

for non-trivial, real-world applications. The approach

adopted is to describe each GKS function and its

39

40

requirements followed by its parameter description

(language independent). This is followed by what features

the 34010 offers for efficiently implementing this

function and how these features help. This is followed by

a discussion of whether the GKS requirements can be easily

met using these features. This is followed by the

algorithm chosen for the implementation.

Fill Area Function and its Requirements

The GKS Fill area function generates a closed

polygon which may be hollow or filled with a uniform color

or a pattern. This function's purpose is the display of

areas. The areas are defined by their bounding polygons.

There are no restrictions concerning the shape of the

polygon? it may be a convex polygon or a seIf -1ntersectmg

polygon. However, insular structures, i.e., areas with

holes which need several separate polygons to be defined,

have been excluded from GKS. Such structures were regarded

as being outside the scope of a kernel system and,

therefore, must be handled on top of GKS.

The parameters of the GKS Fill Area function are

the number of points n defining the fill area boundary

(where n >= 3 ) , and the coordinates of those n points in

w orld coordinates.

41

The effect of the GKS Fill Area function is to

generate a Fill Area primitive. The polygon defined by the

n points is filled according to the fill area interior

style currently selected. The boundary is drawn for style

HOLLOW and is not drawn for other interior styles.

Although the interior of a convex polygon is

straightforward to identify, that is not the case with a

self-intersecting polygon. Consequently, GKS defines the

interior of a polygon in the following way as shown in

Figure 5.1. For any given point, create a straight line

starting at that point and going to infinity. If the

number of intersections between the straight line and the

polygon boundary is odd, the point is within the polygon,

otherwise it is not. If the straight line passes a vertex

of the polygon tangentially, the intersection count is not

affected.

What the 34010 Offers

The 34010 offers the following features which are

useful (as explained below) in implementing the fill area

function.

1) Optional x-y addressing for instructions such as

add, subtract, and compare. With the ADDXY and SUBXY

instructions, simultaneous swaps between the x and y

coordinates of two points (xl,yl) and (x2,y2) can be made.

42

?l: points to be tested N: intersection count

Figure 5.i: Testing whether P lies inside a polygon

43

This kind of swapping is required when sorting the

vertices of a polygon or when drawing the outline of the

polygon to be filled and y2 is less than yl. With the

CMPXY instruction, the x and y coordinates of two points

(xl,yl) and (x2,y2) can be simultaneously compared. This

IS useful in determining the minimum enclosing rectangle

for the polygon to be filled and in clipping the minimum

enclosing rectangle to the window region specified by the

WSTART and WEND registers.

2) Moves between registers of x and y halves. With

the MOVX and MOVY instructions, the x portion alone or the

y portion alone of a point can be changed without

affecting the other portion of the point. This is also

useful in determining the minimum enclosing rectangle of

the polygon to be filled.

3) A pixel block transfer instruction. This

instruction is useful in implementing a pattern fill on a

polygon. It is achieved by storing the particular pattern

to be used in the form of a bit map and transferring the

bit map onto the screen using the PIXBLT instruction.

During execution, the PIXBLT instruction expands the

zeroes in the bit map into the background color (color

value stored in register B8) and the ones in the bit map

44

into the foreground color (color value stored in register

B9).

4) A single CPU cycle left-most-one instruction. This

instruction is very useful in scanning the horizontal line

for fill regions.

5) Allows the number of bits per pixel to be

programmed. This makes it easy to draw the outline of the

area to be filled in a 1-bit-per-pixel scratchpad area by

setting the pixel size to one bit.

Can GKS Requirements be Easily Met?

The GKS requirements for the fill area function can

be easily met using the above features of the 34010. There

are many different approaches to area filling, and often

there are very important trade-offs between the speed and

the complexity of the object that each algorithm can

render. As already mentioned, GKS does not place any

restriction on the type of polygon that can be defined by

an application program. The polygon can be a convex

polygon as in Figure 5.2(a) or it can a self-intersecting

polygon as in Figure 5.2(b).

Implementation Approach Adopted

One way to implement area filling is as follows

First compute and store (in an array) all of the

45

(a)

(b)

Figure 5.2: Types of Polygon (a) Convex Polygon (b) Self-intersecting Polygon

46

intersections of the horizontal scan lines with the lines

making up the boundary of the area to be filled. Then sort

these by values of y and then by values of x. Once this is

done, the filling is achieved by plotting horizontal lines

between pairs of coordinates from the above array. But

there are two major problems with this method. First, the

size of the array must be predicted very closely.

Moreover, even for small fill areas, the size of the array

required is large and thus this method is inefficient in

terms of memory usage. Second, this method cannot handle a

self-intersecting polygon like the one shown in Figure

5.2(b).

An alternate approach computes and stores at one

time, only the intersections of one horizontal scan line

with the boundary of the area to be filled and plots

horizontal lines between the appropriate pairs of

coordinates. This way, the size of the array required is

reduced. But, this affects the area filling speed by

adding computations inbetween every two horizontal scan

lines. Also, self-intersecting areas cannot be handled by

this method either.

Another method to implement filled polygons is to

first draw the outlines defining the polygon at 1 t*it per

pixel into a scratchpad area. The scratchpad will have a

1-bit-per-pixel mapping of the screen image and is at

47

least as large as the minimum enclosing rectangle of the

image. Once the outline is drawn, the pixel size is reset

to 4 bits and each horizontal line of the scratchpad space

is scanned for fill regions along that line. A bit value

of one represents an edge of a fill region, and each pair

of one bits represents a horizontal fill region. Once a

fill region is identified, filling is done to the

corresponding part of the display memory at the full pixel

depth which is 4 bits. This method can handle self-

intersecting polygons in addition to not requiring a lot

of memory.

Since this method helps satisfy all of the GKS

requirements for the Fill Area function, this method was

adopted for this implementation.

Polvli ne Function and its Requ irements

The GKS Polyline function generates a sequence of

straight lines which connects the given points. The points

are specified in world coordinates. GKS requires a minimum

of four different line types (SOLID, DASHED, DOTTED and

DASH-DOT) to be offered by any GKS implementation.

The parameters of the GKS Polyline function are the

number of points n defining the (n-1) line segments (where

n >= 2), and the coordinates of those n points in world

coordinates.

48

The effect of the GKS Polyline function is to

generate a sequence of connected straight lines, starting

from the first point and ending at the last point.

What the 34010 Offers

The 34010 offers a LINE instruction which performs

the Bresenham line-drawing algorithm. All that is needed

is to setup the initial values (shown in the pseudo-code

below) in the appropriate B file registers and then to

call the LINE instruction.

The Bresenham algorithm is the most popular

algorithm for drawing lines. It converts the equation of a

line into an iterative process of comparing test values

over the horizontal distance subtended by the line. The

values are incremented and tested repeatedly. Each time

the value of x or y increases to make a new pixel

possible, the pixel is plotted. The test increments are

derived before the line is drawn, from the slope of the

line and the differentials of its horizontal and vertical

components. The pseudo-code for the algorithm follows.

Pseudo-code for Bresenham 's line drawi ng algor i thm

Given a line from (xl,yl) to (x2,y2)

dx is the difference between the x components of endpoints dy IS the difference between the y components of endpoints IX is the absolute value of dx

49

iy is the absolute value of dy inc is the larger of dx and dy

plotx is xl

ploty is yl (the beginning of the line) X starts at 0 y starts at 0

plot a pixel at plotx, ploty

for i = 0 to inc step 1

increment x using ix increment y using iy set plotflag to FALSE

if X > inc set plotflag to TRUE decrement x using inc increment plotx if dx is positive

otherwise decrement plotx endif

if y > inc set plotflag to TRUE decrement y using inc increment ploty if dy is positive

otherwise decrement ploty endif

if plotflag is TRUE plot a pixel at plotx,ploty

}

Can GKS Requirements be Easily Met?

Although the LINE instruction offered by the 34010

IS helpful in efficiently implementing a SOLID line from

the starting point to the ending point, it does not help

in efficiently implementing the other line types (DASHED,

DOTTED and DASH-DOT). To use the LINE instruction for

implementing the other line types, the given line segment

50

must be broken down into smaller solid line segments

(depending upon the line type chosen) and the LINE

instruction invoked. This would involve a lot of

computation which will affect the drawing speed. Also, for

different line types, the code for breaking down the line

segment into smaller solid segments will be different.

An alternative approach for implementing other than

SOLID line types, would be to use the pixel transfer

instruction PIXT (plots a single pixel), and plot only the

pixels that need to be displayed depending upon the line

type chosen. The actual procedure adopted is described

below.

Implementation Approach Adopted

Based on the above discussion, it was decided to

use the LINE instruction for SOLID lines and to use the

following approach for other line types.

An appropriate bit pattern is stored for each line

type and duplicated repeatedly along the path of the line.

The bit pattern is tested in each of its bit position in

rotation. Whenever the tested bit position has a one and

the plotflag (in the pseudo-code) is TRUE, a pixel is

plotted? otherwise no pixel is plotted.

In other words, the Bresenham line-algorithm is

completely coded, with additional code to perform the

51

above mentioned testing before plotting each pixel. The

actual code is shown in the appendix.

Text Function and its Requirements

Pictures usually contain inscriptions giving

additional textual information. The GKS text function

allows the generation of character strings on the display

surface. The application program specifies the character

string and GKS automatically translates this string into

geometrical data describing the shape of the individual

characters in the string. Any GKS implementation is

required to support at least the ASCII-character set.

Also, GKS allows textual information to be displayed at

different sizes.

The parameters of the GKS Text function are the

starting point where the text is to be displayed (in world

coordinates), and the character string that needs to be

displayed.

The effect of the GKS Text function is to generate

the character string specified. The text position which is

given in world coordinates is transformed to device

coordinates before being used for displaying the character

string.

52

What the 34010 Offers

The 34010 offers the pixel block transfer

instruction with expand option (Figure 4.2). This proves

very useful in transforming a 1-bit-per-pixel shape such a

text font to a color image on the display. A "one" in the

bitmap is expanded to the foreground color and a "zero" in

the bitmap is expanded to the background color. The

background and the foreground colors themselves are stored

using 4 bits (pixel size) in the B8 and B9 registers

respectively.

Can GKS Requirements be Easily Met?

Although the above mentioned 34010 feature can help

in implementing the GKS text function in an efficient

fashion, the resulting textual information will be of a

fixed size only. But GKS allows text to be displayed at

arbitrary sizes. Even if a whole lot of different-sized

characters are stored in the form of bitmaps, the number

of different sizes available would still be limited. Also,

this approach would be inefficient in terms of storage

memory.

Thus the GKS requirement cannot be easily met using

the above feature.

An alternative approach to implementing the GKS

Text function is to use the stroked character text

53

generation method. In this method, characters of the

alphabet and other graphics symbols are stored in shape

tables and referenced by their ASCII character codes. Each

character is defined by a finite number of line segments

(strokes) and stored in the shape table in the form of

endpoint coordinates. The concept can be explained more

clearly using an example. Consider the letter "B. " One way

of defining this character is as follows.

00*01**02****^»**05

* * 16 * » #

* * 26

» 32»#»»M#»35

* » 46

M M 56 M M M

60*61*62*******65

The above definition of the character is made up of

a lot of two digit numbers. The first digit of each two

digit number is the x coordinate of a line endpoint. The

second digit is the y coordinate of the line endpoint.

Lines to be drawn are indicated by asterisks. This can be

represented in a line list form as follows! 0005 0516 1626 2635 3546 4656

54

5665 6560 0161 0262 3235

All other characters can be similarly coded and

stored in a shape table and the result is a complete

stroke text font. With this approach, the GKS requirements

can easily be met.

Implementation Approach Adopted

Based on the above discussion, stroked character

text generation becomes the choice for this implementation

of the GKS text function. The 34010 feature that is used

in this approach is the LINE instruction.

But there is another feature which the 34010 offers

which helps in generating text at the highest precision

level (stroke precision defined below). This feature is

the window clipping feature and will be explained in

detail when discussing transformation functions.

GKS allows three different levels of precision at

which text can be generated by a GKS implementation. They

are the string precision, the character precision, and the

stroke precision.

The string precision is the most primitive form of

text generation. When this precision is adopted, a given

character string is displayed if it falls completely

55

within the selected window region. If not, the whole

character string is discarded.

The character precision is better than the string

precision. When this precision is adopted, only those

characters (of the given character string) that are not

completely inside the selected window region are

discarded.

The stroke precision is the highest precision level

at which text can be displayed in a GKS implementation.

When this precision is adopted, only those portions of the

character that overlaps a window boundary are discarded.

The other parts of the character as well as the other

characters of the given string are displayed.

Transformation Functions and and their Requirements

Normalization Transformation Functions

A normalization transformation is defined by two

rectangles, a "window" within world coordinate space and a

"viewport" within the range CO,l]xCO,l] of NDC space. The

window and the viewport together define a transformation

which maps the content of the window onto the viewport.

Although GKS allows several normalization

transformations to be defined, only one of them can be

active for output of primitives at any time.

56

The parameters of the GKS Set Window function are

the transformation number n (where n >= 0) and the window

limits XMIN, XMAX, YMIN, and YMAX in world coordinates

(where XMIN < XMAX and YMIN < YMAX).

The parameters of the GKS Set Viewport function are

the transformation number n (where n >= 0) and the

viewport limits XMIN, XMAX, YMIN, and YMAX in normalized

device coordinates (where XMIN < XMAX and YMIN < YMAX).

Workstation Transformation Functions

The workstation transformation is specified in a

manner similar to the normalization transformation by a

window within the range C0,l]xC0,13 of the NDC, called the

"workstation window," and by a viewport within the display

surface, called the "workstation viewport." GKS requires

an application program to define both the workstation

window and the workstation viewport with the same aspect

ratio. If they are not defined so, the GKS implementation

should shrink the workstation viewport to a rectangle with

the same aspect ratio as the workstation window.

The parameters o-f the GKS Set Workstation Window

function are the workstation identifier and the

workstation window limits XMIN, XMAX, YMIN, YMAX in

normalized device coordinates (where XMIN < XMAX and YMIN

< YMAX).

57

The parameters of the GKS Set Workstation Viewport

function are the workstation identifier and the

workstation viewport limits XMIN, XMAX, YMIN, YMAX in

device coordinates (where XMIN < XMAX and YMIN < YMAX).

Clipping

GKS provides a mechanism to clip graphical output

to a clipping rectangle. All parts of primitives within or

on the boundary of the clipping rectangle will be

displayed. Everything else will be discarded. This applies

to all output primitives.

The GKS clipping mechanism involves both the

normalization transformation and the workstation

transformation. The clipping rectangle is obtained by

determining the intersection of the viewport rectangle and

the workstation window rectangle. The actual clipping is

performed against the clipping rectangle when output is

displayed on a workstation.

The parameter of the GKS Set Clipping Indicator

function is the clipping indicator (CLIP or NOCLIP).

What the 34010 Offers

The 34010 provides a hardware window clipping

feature that confines graphics drawing operations to a

specified rectangular window. The limits of the current

58

window are specified in the WSTART (window start) and WEND

(window end) registers. WSTART specifies the minimum XY

coordinates in the window, and the WEND specifies the

maximum XY coordinates in the window.

Can GKS Requirements be Easily Met?

Yes, the GKS requirements can be easily met using

the above feature of the 34010. All that needs to be done

is to determine the intersection of the viewport rectangle

and the workstation window rectangle and store the

starting and ending corners of this rectangle in the

WSTART and WEND registers. Once this is done, all the

output primitives that are written to the display surface

are automatically clipped to this window.

Summary

This chapter described the different GKS functions

that were implemented and the algorithms that were chosen

for the implementation along with the reasons for choosing

them. The different features offered by the 34010 for

implementing each of these GKS functions were also

discussed.

CHAPTER VI

CONCLUSION

Testing

The GKS functions implemented were tested for

correctness from a functional point of view. In functional

testing, the program or system is treated as a black box.

It is subjected to different inputs, and its outputs are

verified for conformance to expected results. The

software's ultimate user is concerned only with function,

and hence functional testing inherently takes the user's

point of view.

Expected results were generated for all the

different inputs used for testing. Sample outputs

generated by the text, filiarea, and the polyline

functions are shown in Figure 6.1 through Figure 6.8.

These figures show only relevant portions of the display

screen.

GKS Text Function

Figure 6.1 is a sample output generated by the GKS

Text Function. Seven different text strings are displayed.

The trailing end of each of the seven text strings has

been truncated at the clipping window boundary. The last

character of the second, third, fifth, and the seventh

59

60

t b c (A«C sitt i J I* 1 a i n o w x * s ^iA«'*>>* ^ a b c < I * r v r i i J l « l a n n o v ^ s ^ CUIVWM^

Al>c<t*rgrt»&JlcIai*io9<cr>sCiA««ft>

a b c d e F g r M J1<1 A B C D E F G H I J K L ^

aifcc d e £ grhi I J 1< 1 nn * l > c < l » f f 9 l t i J l c l a * v t o s > c

Figure 6.1J Text generated by GKS Text Function

Figure 6.2J Hollow Polygon generated by GKS Filiarea Function

61

Figure 6.3J Solid Polygon generated by GKS Filiarea Function

S [3 S S S la S S b-3 S lisi I3 S SI3 S S t*. 1 ^mM^^^^'^'^'^

Figure 6.4: Pattern-filled Polygon generated by GKS Filiarea Function

62

Figure 6.55 Solid Polyline generated by GKS Polyline Function

Figure 6.6J Dashed Polyline generated by GKS Polyline Function

63

Figure 6.7. Dotted Polyline generated by GKS Polyline Function

Figure 6.8: Dashed-Dotted Polyline generated by GKS Polyline Function

64

text strings which are y, w, M, and q respectively, have

been partially truncated. This verifies the fact that text

has been implemented with stroke precision.

The window, viewport, workstation window and

workstation viewport boundaries used while generating the

sample text were [0,550,0,550 3, CO,1,0,ID, C0,1,0,1J, and

[80,380,50,3503 respectively. The starting position and

the character height of each of the seven character

strings from top to bottom were [(100,200),193,

[(150,225),183, [(141,250),193, C(135,300),363,

[(120,330),363, [(150,360),313, and [(135,400),273

respectively, all in world coordinates.

GKS Filiarea Function

Figure 6.2 is a sample output of a hollow polygon

as generated by the GKS Fill Area Function. The left

boundary of the clipping window has truncated the top

portion of the polygon and that is the reason the polygon

is not a closed one. As can be seen, the polygon is a

self-intersecting polygon.

Figure 6.3 is a sample output of a solid filled

polygon as generated by the GKS Filiarea Function. The top

portion has been truncated for the same reason as in

Figure 6.2. As can be seen, the filled portions of the

65

polygon are in accordance with the GKS definition of the

interior of a polygon as described in Figure 5.1.

Figure 6.4 is a sample output of a pattern filled

polygon as generated by the GKS Filiarea Function.

The window, viewport, workstation window, and

workstation viewport boundaries used while generating the

sample polygon were [0,500,0,500 3, [0,0.7,0,0.73,

[0,0.7,0,0.73, and [0,300,50,350 3 respectively. The

coordinates of the vertices of the polygon were [100,703,

[211,4093, [300,3213, [200,4003, and [500,3783, all in

world coordinates.

GKS Polyline Function

Figure 6.5 is a sample output of a solid polyline

as generated by the GKS Polyline Function. It is a

sequence of four self-intersecting line segments. Figure

6.6 through Figure 6.8 are sample outputs of a dashed

polyline, dotted polyline, and a dashed-dotted polyline

respectively, as generated by the GKS Polyline Function.

The window, viewport, workstation window, and

workstation viewport boundaries used while generating the

sample polylines were the same as the ones used while

generating the sample polygons. The coordinates of the

sequence of points which form the polylines were [100,703

66

[211,4093, [300,3213, [200,4003, and [500,3783, all in

world coordinates.

Extent of TMS 34010's Utilization

The use made of the 34010 from the point of view of

each of the GKS functions implemented is summarized below.

GKS Polyline Function

The LINE instruction of the 34010 was used for

implementing the SOLID line type. The PIXT (pixel transfer

instruction) instruction was used for implementing the

DASHED, DOTTED and DASH-DOTTED line types, for reasons

mentioned in chapter V. Many steps were saved in

implementing the SOLID line type by using the LINE

instruction because the LINE instruction performs the

Bresenham line-drawing algorithm. But, whatever was gained

was lost in implementing the other than SOLID line types

mentioned above, because the whole algorithm performed by

the LINE instruction had to be recoded with a few

modifications. The net result was that there was no saving

achieved in the code size of the GKS polyline function.

GKS Fill Area Function

The ADDXY, SUBXY, CMPXY, MOVX, MOVY, PIXBLT. and

LMO (Left-Most-One) instructions of the 34010 were used in

implementing the GKS fill area function. Using these

67

instructions saved many steps as explained in chapter V.

Also, the 34010 allows the number of bits per pixel

(PSIZE) to be programmed, which makes it easy to draw the

outline of the area to be filled in a 1-bit-per-pixel

scratchpad area by setting PSIZE to 1. If this feature

were not available, computations have to be performed

using bit masks, to create the 1-bit-per-pixel outline

mentioned above. The net result was that there was a

saving achieved in the code size of the GKS fill area

function.

GKS Text Function

The LINE instruction of the 34010 was used for

implementing the GKS text function. The window clipping

feature of the 34010 was used to achieve the highest

precision level (stroke precision) at which text can be

generated in GKS. This window clipping feature of the

34010 eliminated the need clipping routines to clip output

primitives to the window boundaries. The net result was

that there was a saving achieved in code size of the GKS

text function.

Clipping

The hardware window clipping feature of the 34010

that confines graphics drawing operations to a specified

68

rectangular window, was used to implement clipping. All

that needs to be done is to determine the intersection

(rectangle) of the viewport rectangle and the workstation

window rectangle and store the starting and ending corners

of this rectangle in the WSTART and WEND registers. Once

this is done, all the output primitives that are written

to the display surface are automatically clipped to this

window. The net result was that there was no need for

elaborate clipping routines which means a big saving in

terms of program code.

Result

Computer Graphics programming can be divided into

two major parts. The first part involves transforming

coordinate values from one coordinate system to another

(WC, NDC, DC), which amounts to performing a lot of

computations. The second part involves the actual

generation of images on the computer screen. The first

part is computation intensive. The second part is pixel

manipulation intensive. Consequently, computer graphics

processing becomes a very heavy burden on the processor.

The objective of using the GKS standard

specifications was to achieve portability of graphics

application software. The objective o-f using the Graphic

System Processor was to offload the graphics processing

69

from the main processor, so that the main processor is

f^ree to do some other processing.

From the discussion so far in chapters 5 and 6, it

IS seen that the 34010 helps implement a subset of GKS

(Minimal GKS) efficiently, by allowing savings to be

achieved in the code required to implement the GKS

functions (as explained under the heading "Extent of TMS

34010 Utilization"). It is also seen that the

implementation makes use of the power of the graphics

processor. Also, the main processor is required only to

load the application program along with the required GKS

functions onto the 34010. Once that is done, the

processing is done entirely on the 34010. Thus, the above

mentioned two objectives have been achieved.

In addition to the above mentioned features, the

34010 features an instruction cache, a barrel shifter and

a large register file (30 general-purpose registers). The

barrel shifter helps shifting from 1 to 32 bits in a

single CPU cycle. Graphics operations require the

manipulation of many variables during the drawing process

and the availability of a large register file enhances m e

speed of execution by reducing time-consuming data

swapping between memory and registers. Consequently, tne

overall system performance is also improveo.

70

From the above discussion, it seems that GKS is a

viable standard for the 34010 Graphic System Processor.

Future Work

The research indicated that the 34010 provides features

such as pixel processing, plane masking, and transparency

for performing certain graphics operations.

Pixel processing (PixBLT) operations are useful for

manipulating bit-mapped mixtures of graphics and text.

The plane mask feature enables the user to inhibit

writes to some or all of the bits within a pixel. With

this feature, text can be modified in one plane while the

graphics information in other planes remain unaffected.

With the transparency feature enabled, a pixel of

zero value does not overwrite the destination pixel,

leaving the background unchanged. In this way, only the

part of a rectangular array that makes up the desired

shape (such as a text character) is actually written. The

overlaying of text on graphics then becomes a very simple

task.

Although these above operations will prove useful

in the area of electronic publishing, they are not

addressed by GKS. It may be a worthwhile effort to extend

GKS to address these graphics operations. This will help

71

users in the electronic publishing industry also to adopt

GKS.

The research also indicated that the 34010 does not

support any special feature to perform complete coordinate

transformations in hardware. But, as explained before

coordinate transformation is a major part of computer

graphics programming and is computation intensive in

nature. Consequently, it may be a worthwhile effort to

upgrade the 34010 for performing complete coordinate

transformations in hardware.

BIBLIOGRAPHY

1. Texas Instruments, TMS 34010 User's Guide. 1986.

2. Texas Instruments, TMS 34010 Software Development Board User's Guide. 1987.

3. Texas Instruments, TMS 34010 Assembly Language Tools User's Guide. 1987.

4. Texas Instruments, TMS 34010 C Compiler User's Guide. 1986.

5. Asal, M., Short, G., Preston, T., Simpson, R. , Roskell, D., and Guttag, K., "The Texas Instruments 34010 Graphics System Processor," IEEE Computer Graphics and Applications. Oct. 1986, pp 24-39.

6. Stock, R., and Robertson, B., "New Chips Unleash Super Graphics, " Computer Graphics World. Jun. 1986, pp 24-32.

7. Kinnucan, P., "Graphics Chips -- Here Comes the Second Wave," The S. KLEIN Computer Graphics Review. Winter 1987, pp 29-32, p 81.

8. Haber, L., "Chip makers boost PC graphics performance, " Mini-Micro Systems. Aug. 1986, pp 33-36.

9. Sobelman, G.E., and Krekelberg, D.E., Advanced C |_ Techniques and Applications. QUE Corporation, 1986.

10. Waggoner, C.N., "The GKS Advantage," Computer Graphics World. Oct. 1984, pp 19-42.

11. Enderle, G., Kansy, K., and Pfaff, G., Computer Graphics Programmi ng. GKS -- The Graphics Standard, Springer-Verlag, 1984.

12. Duce, D.A., Hopgood, F.R.A., Gallop, J.R., and Sutcliffe, D.C., Introduction to the Graphical Kernel System (GKS), Academic Press, 1986.

13. Greenaway, D.S , and Warman, E.A., (editors), Eurographics 82 -- Proceedings of the Internationa 1 Conference and Exhibition. University of Manchester, Institute of Science and Technology, North-Holland, 1983.

72

73

14. ISO 7942 Information processi ng systems - computer graph ics - Graph ical Kernel System (GKS) funct lonal description. ISO, 1985.

15. ANSI X3.124 Information systems - computer graphics -Graphical Kernel System (GKS) functional description, ANSI, 1985.

16. Baker, P.M., and Hearn, D., Computer Graphics, Prentice-Hall, 1986.

17. Simons, R.W., "Minimal GKS," Computer Graphics, Volume 17, Number 3, July 1983, pp 183-189.

18. Johnson, N., Advanced Graphics in Cl Programming and Techn iques. Osborne McGraw-Hill, 1987.

19. Beizer, B., Software Testing Techniques, Van Nostrand Reinhoid Company, 1983.

APPENDIX

/MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM/

/* GKS Polyline Function. This function is called by the */ /* application program. This function in turn calls the */ /* line function (assembly code) for SOLID line drawing */ /* and the point function (assembly code) for drawing */ /* the DASHED, DOTTED and DASH-DOTTED line types. */

gpolyline(npoints,points) Gint npoints; Gpoint *points^

Gint plot,ploty,plotx,xl,yl,x2,y2,inc,ix,iy, xstore,ystore;

Gint xtemp,ytemp,dx,dy,i,j; unsigned short style,style_mask; Gpoint *point_storeJ Gint stx,sty; Gfloat Sxl,Sx2,Syl,Sy2,xv,yv;

if (Ipolyln && hollowfill) set_colorl(WSSTLIST.colortable[GKSSTLIST.curfi1Icolorind3);

else set_color 1(WSSTLIST.colortable[GKSSTLIST.cur 1inecolorind3);

winviewstruc.winwide = (short) WSSTLIST.viewportDC.xmax -(short) WSSTLIST.viewportDC.xmin;

winviewstruc.winhigh = (short) WSSTLIST.viewportDC.ymax -(short) WSSTLIST.viewportDC.ymin;

winviewstruc.winleft = (short) WSSTLIST.viewportDC.xminj winviewstruc.wintop = (short) WSSTLIST.viewportDC.yminJ

winviewstruc.vuwide = (short) WSSTLIST.viewportWS.xmax (short) WSSTLIST.viewportWS.xmin;

winviewstruc.vuhigh = (short) WSSTLIST.viewportWS.ymax (short) WSSTLIST.viewportWS.ymin;

winviewstruc.vu1 eft = (short) WSSTLIST.viewportWS.xminJ winviewstruc.vutop = (short) WSSTLIST.viewportWS.yminj

set_visrect(winviewstrucptr);

74

75

Sxl =

(GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC. xmax -GKSSTLIST.transtable[GKSSTLIST.curntrannum3.VIewportNDC.xmin)/ (GKSSTLIST.transtable[GKSSTLIST.curntrannum3.windowWC.xmax -GKSSTLIST.transtable[GKSSTLIST.curntrannum3.windowWC.xmin);

Syl =

(GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC. ymax -GKSSTLIST.transtable[GKSSTLIST.curntrannum 3.viewportNDC.ymin)/ (GKSSTLIST.transtable[GKSSTLIST.curntrannum3.windowWC.ymax -GKSSTLIST.transtable[GKSSTLIST.curntrannum3.WindowWC.ymin)?

Sx2 = (WSSTLIST.viewportWS.xmax - WSSTLIST.viewportWS. xmin)/ (WSSTLIST.windowWS.xmax - WSSTLIST.windowWS. xmin); Sy2 = (WSSTLIST.ViewportWS.ymax - WSSTLIST.viewportWS. ymin)/ (WSSTLIST.WindowWS.ymax - WSSTLIST.windowWS. ymin) ;

point_store = points^

if (GKSSTLIST.curlinetype == 1) /* SOLID Line */ { for (i = i; i < npoints; i++) { XV = Sxl * (points -> X -GKSSTLIST.transtabie[GKSSTLIST.curntrannum 3.WindowWC.xmin) •

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC.xmin; yv = Syl * (points -> y -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.ymin)

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC. ymin; xl = (int) (Sx2 * (XV - WSSTLIST.WindowWS.xmin)

•»• WSSTLIST. viewportWS. xmin ) ; yl = (int) (Sy2 * (yv - WSSTLIST.windowWS.ymin)

* WSSTLIST.viewportWS.ymin);

if (i == 1) C xstore = xi; ystore = yi; }

points*•; XV = Sxl * (points -> X -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.xmin) •••

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC.xminj yv = Syl * (points -> y -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.ymin)

76

GKSSTLIST.transtabie[GKSSTLIST.curntrannum 3.viewportNDC.ymin; x2 = (int) (Sx2 * (xv - WSSTLIST.windowWS.xmin)

• WSSTLIST.ViewportWS.xmin);

y2 = (int) (Sy2 * (yv - WSSTLIST.windowWS.ymin) • WSSTLIST.ViewportWS.ymin);

line(xl,yl,x2,y2); } if (Ipolyln i& hollowfill)

Iine(x2,y2,xstore,ystore); } else {

switch(GKSSTLIST.cur linetype) {

case 2: style = OxFFOO; /* DASHED line */ break;

case 3: style = OxCOOO; /* DOTTED line */ break;

case 4: style = OxCFFC; /* DASH-DOTTED line */ break;

} styie_mask = style;

for (i = 1; i < npoints; i++) { XV = Sxl * (points -> X -GKSSTLIST.transtabie[GKSSTLIST.curntrannum 3.windowWC.xmin) •f

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC.xmm; yv = Syl * (points -> y -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.ymin) •f

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC.ymin; xl = (int) (Sx2 * (XV - WSSTLIST.windowWS.xmin)

• WSSTLIST.viewportWS.xmin); yl = (int) (Sy2 * (yv - WSSTLIST.windowWS.ymin)

•»• WSSTLIST. viewportWS. ymin ) ;

points* *; XV = Sxl * (points -> X -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.xmin) +

GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.viewportNDC.xmin;

77

yv = Syl * (points -> y -GKSSTLIST.transtabie[GKSSTLIST.curntrannum3.windowWC.ymin) +

GKSSTLIST.transtable[GKSSTLIST.curntrannum 3.ViewportNDC.ymin; x2 = (int) (Sx2 * (xv - WSSTLIST.windowWS.xmin)

• WSSTLIST.ViewportWS.xmin); y2 = (int) (Sy2 * (yv - WSSTLIST.windowWS.ymin)

• WSSTLIST.ViewportWS.ymin);

dx = (x2 - xl); dy = (y2 - yl); ix = abs(dx); iy = abs(dy); inc = max(ix,iy);

plotx = xi; ploty = yi; xtemp = O; ytemp = O;

for (j = O; j <= inc; j**) {

if (style_mask == 0) style_mask = style;

xtemp •= ix; ytemp *= iy; plot = o; if (xtemp > inc)

{ plot = i; xtemp -= inc; plotx *= sign(dx); }

if (ytemp > inc) { plot = i; ytemp -= inc; ploty *= sign(dy); }

if (plot 8f& style-mask & 0x0001) point(plotx,ploty);

style-mask >>= i; } /* end of for j = 0 to <= inc */

> /* end of for i = 1 to (npoints - 1) */ } /* end of else block */

} /M end of function Gpolyline() */

78

* line function M

* Draw a line from point (xs,ys) to point (xe,ye) using * Bresenham's line algorithm. *

* Usage: line(xs, ys, xe, ye); MMMMMMM*MMM*MMMMM**MMM*****MMMMMMMMMM*******MMMMMMMMMMMMM

.title 'draw a line'

.file 'line.asm'

.nolist .copy "macros.hdr" . list

DECLARE GLOBAL FUNCTION NAME

.globl _1ine

ENTRY POINT

.line: MMTM SP,B2,B7,B10,B11,B12,B13,B14

* Calculate XY addresses for line start and end points. MOVE A14,B14 MOVE *-B14,B2,l ; Get start x MOVE *-B14,Bll,l ; Get start y SLL 16,B11 MOVY B11,B2 ; B2 = (yO,xO) MOVE *-B14,B10,l ; Get end x MOVE *-B14,Bll,l ; Get end y SLL 16,B11 MOVY B11,B10 ; BIO = (yl,xl) MOVE B14,A14

* Determine which octant line is in, and set up accordingly. CLR B7 SUBXY B2,B10 ; BIO = (y1-yO,xl-xO) = (b,a) JRYZ horiz JRXZ vert JRYNN bpos JRXNN bneg_apos

bneg_aneg: SUBXY B10,B7 ; B7 = (:b:,:a!) MOVI -1,B11 ; Bll = (-1,-1) JRUC cmp_b_a

bneg-apos: SUBXY B10,B7 MOVX B10,B7 ; B7 = ( :b: , la! )

79

MOVI JRUC

bpos: bpos_aneg:

MOVY MOVI JRUC

bpos.apos: MOVI

cmp_b.a: MOVI

MOVE SRL CLR MOVX CMP JRGT

a-lt-b: MOVX RL MOVY SLL SUB ADDK

* If drawi * Otherwis

MOVE M

JRN lineO:

JRUC a_ge_b:

SLL SUB MOVE

M

JRNN linei:

JRUC * Handle s hor1z :

JRXNN ADDXY SUBXY MOVE

* Handle s vert:

ADDXY

ng e,

0FFFF0001h,Bll cmp_b_a JRXNN bpos-apos

SUBXY B10,B7 B10,B7 01FFFFh,Bll ; cmp_b_a

MOVE B10,B7 010001h,Bll ;

CLR B12 -1,B13

B7,B0 16,BO BIO B7,B10 BO,BIO a-ge_b

MOVE BO,BIO B7,B0 16,B7 B11,B12 1,B0 BIO,BO 1,B10 in ••'Y direction, use LINE 1. Bll,Bll

Bll = (-1,1)

1 inel LINE done

MOVX 1,B0 BIO,BO Bll,Bll

B11,B12

; B7 = (;bI, Bll = (1,-1)

Bll = ; B7

(1,1) = ( lb f ' a: )

B13 = FFFFFFFF (set pattern to all

BO = b

BIO = a

1 's)

a and b swapped

BO = 2b - a

use LINE 0.

if drawing in •Y direction, otherwise use

use LINE LINE 1

BO = 2b - a if drawing in -Y direction. use LINE 1

1 ineO LINE 1 done

pecial case of horizontal JRXZ pixel do_fill B10,B2 B10,B7 B7,B10

pecial case of vertical JRYNN do_fill B10,B2 ; change

otherwise use LINE 0

line.

change start to (yl,xl) make dx positive

line.

start to (y1,xl)

80

NEG BIO ; make dy positive * Draw horizontal or vertical line. do_fili: MOVE B10,B7

ADDI 010001h,B7 ; no check for dx or dy overflow FILL XY JRUC done

* Draw dot if start and end points are the same, pixel: DRAV B12,B2 * Restore registers and return. done: MMFM SP,B2,B7,BIO,Bl1,B12,B13,B14

RETS 2 ; Return to calling routine . end

PERMISSION TO COPY

In presenting this thesis in partial fulfillment of the

requirements for a master's degree at Texas Tech University, I agree

that the Library and my major department shall make it freely avail­

able for research purposes. Permission to copy this thesis for

scholarly purposes may be granted by the Director of the Library or

my major professor. It is understood that any copying or publication

of this thesis for financial gain shall not be allowed without my

further written permission and that any user may be liable for copy­

right infringement.

Disagree (Permission not granted) Agree (Permission granted)

^ J' — L.

Student's signature Student's signature

Cl -^ n J,

Date Date