ADVANCED

COMPUTER
GRAPHICS
 ADVANCED
COMPUTER
GRAPHICS
Economics Techniques
and Applications

Edited by

R. D. PARSLOW
and

R. ELLIOT GREEN
Department of Computer Science,
Brunei University, Uxbridge, England

~ PLENUM PRESS, London and New York· 1971

 Plenum Publishing Company Ltd.,
Donington House,
30 Norfolk Street,
London, W.C.2

U.S. Edition published by

Plenum Publishing Corporation,
227 West 17th Street,
New York, New York 10011

Copyright © 1971 by Plenum Publishing Company Ltd.

Softcover reprint of the hardcover 1st edition 1971

All Rights Reserved

No part of this book may be reproduced in any form
by photostat, microfilm, or any other means without
written permission from the Publisher.

SBN: 306-30517-8
Library of Congress Catalog Card Number: 7.7-137740

lSBN-13: 978-1-4613-4608-1 e-lSBN-13: 978-1-4613-4606-7

DOl: 10.1007/978-1-4613-4606-7
 Contributors

S. E. ANDERSON, The John Hopkins University, Applied Physics Laboratory, 3631 Georgia Avenue,
Silver Springs, Maryland, U.S.A.
A. P. ARMIT, The University Mathematical Laboratory, Corn Exchange Street, Cambridge CB23QG,
England.
J. ATIYAH, Racal Research Limited, Newtown, Tewkesbury, Glos., England.
A. W. BEEBY, Research and Development Division, Cement and Concrete Association, Wexham
Springs, Slough, Bucks., England.
D. A. BELL, Division of Computer Science, Ministry of Technology, National Physics Laboratory,
Teddington, Middlesex, England.

E. D. BERHOLD, Dept. of Engineering, University of California, Los Angeles, California 90024, U.S.A.
M. P. BERHOLD, Dept. of Engineering, University of California, Los Angeles, California 90024, U.S.A.
A. BERN HOLTZ, Laboratory for Computer Graphics and ~patial Analysis, Memorial Hall 114, Grad-
uate School of Design, Harvard University, Cambridge, Mass. 02138, U.S.A.
R. D. BERGERON, Center for Computer and Information Sciences, Brown University, U.S.A.
A. BIJL, Architecture Research Unit, Department of Architecture, The University of Edinburgh, 55
George Square, Edinburgh, EH8 9JU, Scotland.
H. G. BOWN, Department of Communications, Shirley Bay, P.O. Box 490, Terminal 'A', Ottawa 2,
Ontario, Canada.
G. BRACCRI, Istituto di Elettrolecnica ed, Elettronica, Politecnico di Milano, Piazza L. da Vinci 32,
20133, Milano, Italy.
V. M. BRIABRIN, Assistant Professor, Computer Centre of the Academy of Sciences of the U.S.S.R.,
Vavilova40, Moscow, U.S.S.R.
A. BRITCH, Department of Building Science, University of Liverpool, Musprat(Laboratory, Liverpool,
England.
G. A. BUTUN, University of Leicester, Department of Engineering, Leicester LEI 7RH, England.
D. W. CARDWELL, Oak Ridge National Laboratory, Oak Ridge, Tennessee 37830, U.S.A.
M. A. CHACE, Concomp Project, University of Michigan, 611 Church Street, Ann Arbor, Mich. 48104,
U.S.A.
S. H. CHASEN, Senior Staff Scientist, Head, Man-Computer Systems, Lockheed Georgia Company,
Marietta, Georgia 30060, U.S.A.
D. COHEN, Professor of Computer Science, Aiken Computation Laboratory, Harvard University,
Cambridge, Mass., U.S.A.
I. W. COTTON, Sperry Rand Corporation, Univac Data processing Division, P.O. Box 8100, Phila-
delphia, Pennsylvania 19101, U.S.A.
S. W. CRAWLEY, Professor of Architecture, Department of Architecture, The University of Utah,
Salt Lake City 84112, U.S.A.
J. D. CUTRELL, Civil Engineering, University of Colorado, Boulder, Colorado 80302, U.S.A.
R. J. DOWE, Applications Development Dept., Control Data Corporation, Northwest Industrial Park,
3rd Avenue, Burlington, Massachusetts, 01804, U.S.A.

v
D. K. EWING, Computer-aided Design Division, Ministry of Technology, East Kilbride, Glasgow,
Scotland.
W. S. ELLIOT, Imperial College, Centre for Computing and Automation, Royal School of Mines
Building, Prince Consort Road, London, S. W.7, England.
P. FALK, c/o Dr. B. J. Shepherd, IBM, P.O. Box 66, Los Gatos, California 95030, U.S.A.
L. J. FEESER, Associate Professor, Civil Engineering, University of Colorado, Boulder, Colorado 80302,
U.S.A.
J. FERENCZY, Research Institutefor Automation of the Hungarian Academy of Sciences, Budapest XI,
Kendeu,13-17,Hungary.
D. FERRARI, Istituto di Elettrotecnica ed, Elettronica, Politecnico di Milano, Piazza L. da Vinci, 32,
20133 Milano, Italy.
J. D. FOLEY, Information Control Systems, 109 E. Madison, Ann Arbor, Michigan, U.S.A.
A. R. FORREST, University Mathematical Laboratory, Corn Exchange Street, Cambridge, England.
S. FOSBURG, Laboratory for Computer Graphics and Spatial Analysis, Graduate School of Design,
Harvard University, Cambridge, Mass. 02138, U.S.A.
R. A. FREEDMAN, Control Data Corporation, Digigraphics System Division, Northwest Industrial
Park, Third Avenue, Burlington, Mass. 01804, U.S.A.
R. G. GILLESPIE, Associate Director, Computer Center, University of Washington, Seattle, Wash-
ington 98015, U.S.A.
A. GIORGINI, Assistant Professor of Hydromechanics, Purdue University, School of Civil Engineering,
Lafayette, Indiana 47907, U.S.A.
W. J. HANSEN, Applied Mathematics Division, Argonne National Laboratory, 9700 South Cass
Avenue, Argonne, Illinois 60439, U.S.A.
L. HAZLETT, Motorola Semiconductor Division, 5005 East McDowell Road, Phoenix, Arizona 85008,
U.S.A.
N. M. HERBST, I.B.M., Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, N. Y.
10598, U.S.A.
R. J. HUBBOLD, University of Leicester, Department of Engineering, Leicester LEI 7RH, England.
K. B. IRANI, The University of Michigan, Systems Engineering Laboratory, Dept. of Electrical
Engineering, Ann Arbor, Michigan 48104, U.S.A.
J. H. JACKSON, The University of Michigan, Systems Engineering Laboratory, Dept. of Electrical
Engineering, Ann Arbor, Michigan 48104, U.S.A.
A. P. JENKINS, Imperial College, Centre for Computing and Automation, Royal School of Mine
Building, Prince Consort Road, London, S. W.7, England.
C. B. JONES, Imperial College, Centre for Computing and Automation, Royal School of Mine Building,
Prince Consort Road, London, S. W.7, England.
M. E. KORYBALSKI, Concomp Project, University of Michigan, 611 Church Street, Ann Arbor,
Mich. 48104, U.S.A.
E. R. KINEGER, Computing Center, University of Colorado, Colorado. U.S.A.
J. LAVICK, Supervisor, CAD, McDonnell Automation Center, Bldg. 105, Level 3 232-8043, P.O. Box
. 516, St. Louis, Missouri 63166, U.S.A.
F. A. LECKIE, University ofLeicester, Department ofEngineering, The University, Leicester LEI 7RH,
England.
T. M. P. LEE, Mail Station 8611, Sperry Rand Corporation, Univac, P.O. Box 3525, St. Paul, Minne-
sota55101, U.S.A.
P. A. LUNDAY, I.B.M. Limited, Los. Angeles, Development Center 1930 Century Park West, Los
Angeles, California 90067, U.S.A.

vi
K. J. MACCALLUM, Imperial College of Science and Technology, Centre for Computing and Auto-
mation, Prince Consort Road, London, S. W.7, England.
J. W. MACHANIK, President, Merlin Systems Corporation, Computer Research and Time-Sharing,
1044 Northern Blvd., Roslyn, New York 11576, U.S.A.
M. A. MACLEAN, Department of Communications, Shirley Bay, P.O. Box 490, Terminal 'A', Ottawa
2, Ontario, Canada.
L. P. McNAMEE, Room 3731 BH, Dept. of Engineering, University of California, Los Angeles,
California 90024, U.S.A.
J. C. MICHENER, Center for Computer and Information Sciences, Brown University, U.S.A.
R. L. PHILLIPS, Associate Professor, The University of Michigan, College of Engineering, Dept. of
Aerospace Engineering, Gas Dynamics Laboratories, Building 422, Ann Arbor,
Michigan, U.S.A.
R. F. D. PORTER GOFF, University of Leicester, Department of Engineering, The University,
Leicester LEI 7RH, England.
P. A. PURCELL, Royal College of Art, Industrial Design (Engineering) Research Unit, KensingtOn
Gore, London, S. W.7, England.
J. J. QUANN, Head, Experiment Computation Section, Code 565, National Aeronautics & Space
Administration, Goddard Space Flight Center, Greenbelt, Maryland 20771, U.S.A.
M. P. RANA WEERA, Department of Engineering, University of Leicester, Leicester, England.
J. ROHN, Sussex Research Associates Ltd., 25 Duncan Street, Toronto 2B, Canada.
A. R. RUNDLE, Elliott-Automation Systems Ltd., Elstree Way, Borehamwood, Herts., England.
M. A. SABIN, Project Applications Engineer, Mathematical Services, B.A.C., Weybridge, Surrey,
England.
L. J. SCHAEFER, Adage Inc., 1079 Commonwealth Avenue, Boston Massachusetts, 02215, U.S.A.
R. L. SCHIFFMAN, Computing Center, University of Colorado, Colorado, U.S.A.
D. SEWELL, Computer Systems Consultant, Computer Communications Department, Mobil Oil
Corporation, 150 East 42nd Street, New York, 10017, U.S.A.
G. SHEARING, Senior Research Scientist, Division of Computing Research, CSIRO, Australia.
B. J. SHEPHERD, I.B.M., P.O. Box 66, Los Gatos, California, 95030, U.S.A.
S. SHERR, Manager Display Planning, Advanced Planning Department, Hazeltine Corporation, Little
Neck, N. Y.1l362, U.S.A.
P. SMITH, Computer-Aided Design and Manufacture, Rolls Royce Limited, Aero Engine Division,
P.O. Box 31, Derby, England.
J. R. STEIN, Computing Center, University of Colorado. Colorado, U.S.A.
P. STEUBER, Sun Printers, Whippendell Road, Watford, WDI 7QH, Herts., England.
H. P. J. TAYLOR, Research and Development Division, Cement and Concrete Association, Wexham
Springs, Slough, Bucks., England.
D. W. TEDD, Computer-Aided Design Division, Ministry of Technology, East Kilbride, Glasgow,
Scotland.
B. T. TORSON, Project Manager, Computer-Aided Design and Manufacture, Rolls Royce Limited,
Aero Engine Division, P.O. Box 31, Derby, DE2, 8Bl, England.
A. VAN DAM, Center for Computer and Information Sciences, Brown University, U.S.A.
P. K. WALL, Technical Manager-REDAC, Racal Research Limited, Newtown, Tewkesbury, Glos.,
England.

vii
V. L. WALLACE, Academic Visitor from University of North Carolina, Imperial College, Royal School
of Mines Building, Prince Consort Road, London, S. W.7, England.
P. E. WALTER, County Architect's Department, West Sussex County Council, Sussex, England.
P. M. WILL, I.B.M., Thomas J. Watson Research Center, Yorktown Heights, N. Y. 10598, U.S.A.
J. H. WILLIAMS, I.c.G. Systems, Interactive Computer Graphics, 6 St. James Avenue, Boston,
Massachusetts 02116, U.S.A.
R. WILLIAMS, Dept. of Electrical Engineering, School of Engineering & Science, New York University,
University Heights, Bronx, N. Y.10453, U.S.A.
M. S. WOLFBERG, Massachusetts Computer Ass. Inc., Lakeside Office Park, Wakefield, Mass. 01880,
U.S.A.
A. G. YOUNG, University ofLeicester, Department of Engineering, The University, Leicester LEI 7RH,
England.

viii
 Contents
Contributors v
Introduction xiii

PART 1
Fundamental Issues Facing Computer Graphics
The Lessons of the "60's" P. A. Lunday 3
Fundamental Problems Facing the Growth of
Man/Computer Graphics S. H. Chasen 17
Aspects ofInteractive Graphic Systems R.J.Dowe 27
Some Comments on Supporting Multiple
Interactive Graphic Consoles in a Productive
Environment P. Smith, B. T. Torson 41
Digital Television: a low cost approach to
multi-terminal graphics S. Sherr 49

PART 2
Computer Aided Design - General Applications
An interactive Graphical System using Computers W. S. Elliott,
linked by Voice Grade Line A. P. Jenkins, C. B. Jones 71
Conversational Design of Stochastic Service K. B. Irani
Systems from a Graphical Terminal L. Wallace, J. H. Jackson 91
Anatomy of an interactive Graphics Display
Project: an Engineering Tool R. G. Gillespie ... 103
Computer Graphics in the Dynamic Analysis M.A. Chace,
of Mechanical Networks M. E. Korybalski 115
Structural Operational Data Sets from Arbitrarily E. D. Berhold,
Arranged Computer Graphic Symbols M. P. Berhold, L. P. McNamee 161
A CAD approach to Blanking Die and
Technology Design J. Ferenczy 179
Computer-Aided design at McDonnell-Douglas J. J. Lavick 195
Graphics Oriented Fractionator Analysis and
Simulation Tool (GOFAST) D. Sewell 219
A Display System for Processing Engineering D.K.Ewing
Drawings D. W. Tedd 245

PART 3
Electronic Design Applications
A Graphic Language for Describing and G. Bracchi,
Manipulating two-dimensional patterns D. Ferrari 263

ix
 Interactive Graphical Input for Circuit Analysis M. A. Maclean, H. G. Bown 279
Practical Layout of Printed Circuit Boards
using Interactive Graphics J. Atiyah, P. K. Wall 301
Computer Graphics for integrated Circuit Design L. Hazlett 313

PART 4
Civil Engineering Applications of Computer Graphics
Perspective Views and Computer Animation
in Highway Engineering L. J. Feeser, J. D. Cutrell 327
The use ofInteractive Computer Graphics in J. R. Stein,
Soil Engineering Analysis and Design E. R. Krueger, R. L. Schiffman 345
Structural Design Using Interactive Graphics A.G. Young 367
Computer Representation Display and
Interrogation of Structural Building Data R. F. D. Porter Goff 381
Interactive Use of the Light-Pen in finite
Element Limit Load Analysis M. P. Ranaweera, F. A. Leckie 397
Computographical Description of the Dynamics
of a Turbulence Model A. Giorgini 407

PART 5
Architectural Applications
Computer Aided Architectural Design A. Bijl 433
A Generalised Program for Transforming
Relationship Values into Plan Layouts A. Bernholtz, S. Fosburg 449
An Associative Data Structure to Describe
Building Component Assemblies A. L. Britch 463
The Computer as an aid for the Architect P. E. Walter 477
Computer Graphics System for School Design P. A. Purcell 487
Computer Graphics in Architecture J. H. Williams 513
The Craft Program Improvements and
Proposed Improvements J. Rohn ... 531
Building Design by Computer Graphics S. W. Crawley 541

PART 6
Nuclear and Space Science Applications
The application of Computer Generated Graphs
and Diagrams to the Development of
Advanced Nuclear Reactors D. W. Cardwell ... 555
A Laboratory for Interactive Programming,
Processing and Display in Space Science J.J.Quann 577

x
 PART 7
Pattern Recognition Developments
Design of an Experimental Laboratory for
Pattern Recognition and Signal Processing N. M. Herbst, P. M. Will 595
Display Assisted Design of Sequential Decision
Logic for Pattern Recognition D.A. Bell 629
Interactive Signal Processing R. A. Freedman 635

PART 8
Text Processing with On-Line Visual Display
A demonstration of magazine page layout using
a graphic display terminal P. Steuber 655
Graphic Editing of Structured Text W.J. Hansen 681
On-Line text editing using visual display V. M. Briabrin 701

PART 9
Computer Generated Animation
Generating Computer Animated Movies from
a Graphic Console S. E. Anderson 717
Production of Computer Animated Films from a
Remote Storage Tube Terminal R. L. Phillips 723

PART 10
Developments in Display Systems
Project Merlin: A Graphics Operating System M. L. Berman,
J. W. Machanik, S. Shellans 735
On the Application of Graph Theory to Computer
Data Structures R. Williams 775
Design of Software and Formats for
Interactive Graphics Support L. J. Schaefer 803
Software Capabilities of the Adage Graphics
Terminals A. van Dam, R. D. Bergeron 831
Storage Tube Graphics-a Comparison of Terminals A. van Dam, J. C. Michener 851
Microcoded Multiprogramming Display B. J. Shepherd
Control Unit A. S. McAllister and P. Falk 887
An Interactive Graph Theory System M. S. Wolfberg 905
Development and Production of Design Charts
Using a Digital Plotter A. W. Beeby, H. P. J. Taylor 923

PART 11
Graphic Languages
A Fortran package for Interactive Graphics G. A. Budin 947
Visplay, the C.S.I.R.O. Graphical Fortran System G. Shearing 967
Software for Satellite Graphics A. R. Rundle 995

xi
Optimum Systems Design of Computer Driven
Graphics Terminals J. D. Foley 1007
TDD-An Interactive Three Dimensional Drawing
Program for Graphical Display and Lightpen R. J. Hubbold 1035
Languages for Graphic Attention-Handling I. W.Cotton 1049

PART 12
Computer-generated Geometric Shapes
Interrogation Techniques for Parametric Surfaces M. A. Sabin, B. A. C. Weybridge 1095
Analysis of an Efficient Homogeneous Tensor
Representation of Surfaces for Computer Display T. M.P. Lee 1119
On Linear Differences Curves D.Cohen 1143
Interactive Surface Design A. P. Armit, A. R. Forrest 1179
The use oflnteractive Graphics for the
Preliminary design of a Ship's Hull K. J. MacCallum 1203

PART 13
For Reference
Some Commercially Available Computer
Graphics Systems 1217
Index 1225

xii
 Introduction

Computer graphics is no longer merely a technique of promise. The case studies in this book prove that
it is a technique which has already identified itself with progress in an astonishingly wide range of app-
lications, to the extent that it has been necessary to group many chapters into sections dealing with
specific categories, such as the design of electrical circuits, civil engineering, architecture, nuclear and
space science and text editing.
In the last couple of years, computer graphics has blossomed out from the stage in which it was
confined almost exclusively to the large scale industries of aircraft and automobile engineering. It has
also developed additional advantages, mote than the simple idea of doing the same thing more quickly.
Now the technique offers entirely new ways of doing old things, with consequent greater efficiency and
accuracy; and it also brings a way of doing new things, which were previously not possible. In the
introduction to their paper in Part 12, Armit and Forrest state: "We do not discuss those systems which
are merely computer versions of existing design methods, but rather those systems which make use of
techniques for design which are beyond the possibilities of conventional drafting." Similarly, Ranaweer3;
and Leckie end their paper in Part 4 with the comment: "Thus the man and the machine can work as
a team to arrive at a solution better than that which can be arrived at by either one alone".
Naturally, the major concern of most of those who are working or who would like to work with
computer graphics is the question of economics. What is it worth to a company to take advantage of
the benefits to be achieved through the technique? Many of the chapters in this volume trace the pro-
gress made in evaluating the worth of computer graphics and many describe the current attitude to
computer graphics of firms which have investigated the economics of their applications. In almost every
chapter, the standpoint is one of regarding computer graphics as a practical industrial tool or research
instrument and then showing how it is best applied and how it can be used most effectively and econ-
omically.
There is an urgent need for the cross-fertilisation of ideas from one industry and application to
another. This is a major objective of this volume and of the symposium from which the material has
been compiled. At the Computer Graphics 70 International Symposium staged by BruneI University,
Uxbridge, Middlesex, in April 1970, no less than 110 renowned experts presented papers or chaired
discussions, sharing their experiences with delegates from not only the world of computers but also from
every major branch of industrial, commercial and professional activity. To ensure an even wider audience
so that the information presented would be of the utmost assistance in furthering the development of
computer graphics, the papers have been selected and edited specially for this volume and a smaller
companion volume entitled "Computer Graphics in Medical Research and Hospital Administration"
now available from Plenum Press.
This main volume, "Advanced Computer Graphics - economics, techniques and applications",
is, as far as can be ascertained, the most comprehensive work on the subject ever published. It is con-
cerned with computer graphiCs as the most efficient man-machine interface. Most of the chapters are
based on design work requiring highly sophisticated vector display terminals or hard-copy plotters for
high accuracy output. Other chapters are concerned with the use of alphascope terminals; here the
emphasis is on visual man-machine interaction by means of text alone.
A volume of this size, with its complex text and its wealth of illustrations, would normally not see
the light of publication for at least 18 months from the date of completion of the editing. However, as
speed in the dissemination of the data contained here, is so vital in what must be the most rapidly
developing sector of modern industry, we have opted for the direct reproduction by photographic
means of the original author's typescripts. This has resulted in cutting at least twelve months off the
production time.

xiii
 We are extremely grateful for the excellent co-operation we have received from the individual
authors whose papers are published here, and to their various organisations which have agreed to
publication of work done on their premises. Thanks are also due to those session organisers from
Computer Graphics 70 who were so effective in helping to arrange for so many authoritative people
to contribute their material. The session organisers were:

M. B. CLOWES, Senior Research Fellow, Department of Experimental Psychology, Sussex University.

S. A. COONS, Computer Science and Information Science, Syracuse University, New York.
A. VAN DAM, Center for Computer and Information Sciences, Brown University.
F. GREATOREX JR., Dabcovitch Inc.
B. HERZOG, Concomp Project, University of Michigan.
F. R. A. HOPGOOD, Graphics Applications Programming Group, Atlas Laboratory.
G. K. HUTCHINSON, Director of Computer Center, University of Wisconsin.
K. C. KNOWLTON, Bell Telephone Laboratories.
D. W. LEWIN, Department ofElectronics, University of Southampton.
C. MACHOVER, Vice President Marketing, Information Display Inc.
T. J. MOFFETT, Manager, Interactive Graphic Systems, TRW Systems Group.
M. L. V. PITTEWAY, Head of Computer Science Dept., Brunei University.
R. L. SCHIFFMAN, University of Colorado.
ALAN SUTCLIFFE, HeadofICLProgramResearch Unit.
J. B. THOMAS, Computer Science Department, Brunei University.
P. E. WALTER, County Architect's Dept., West Sussex County Council.
D. WHITE, Head of Computer Policy Branch, Department of Health and Social Security.

We should also like to express our gratitude to Sydney Paulden, for his invaluable help in prepar-
ing the material for press.
ROBERT D. PARSLOW
R. ELLIOT GREEN
September 1970

xiv
 PART I

Fundamental Issues Facing

Computer Graphics
 THE LESSONS OF THE "60's"

P. A. Lunday

I.B.M. Limited, Los Angeles Development Center,

1930 Century Park West, Los Angeles, California 90067,
U.S.A.

While it is recognized that the topic is Computer Graphics in

the 70' s, it seems pertinent to make an assessment of what
happened in the 60' s. Hopefully, one can profit by history to
enhance the future. This paper is not intended as any global pro-
nouncement on the subject at hand but repreSents a number of
personal observations and opinions related to this very dynamic
field of computer sc ience.

During the Fall Joint Computer Conference in San Francisco in 1964,

major public announcements and demonstrations were conducted on
computer graphics. I believe these demonstrations signaled that
interactive computer graphics equipment could be applied via a
broad base of applications on a commercial basis.

The system demonstrated was the IBM Alpine. The demonstrations

were concentrated primarily on the use of the system for purposes
of design. Reactions to the demonstrations ranged from great
scepticism to almost fanatical enthus iasm.

In the five years since this conference, there are still a great many
questions and problems that seem to have been unanswered. Not
the least of these questions is why this dramatic and dynamic field
has not exploded as people anticipated that it would. I think it is
generally accepted that the expansion of the field has been a dis-
appointment to a great many people. We are still looking for
answers to questions associated with the types of applications that
appear to be profitable, the method of justifying the equipment,
types of software that are required, the nature and type of hardware
that is most appropriate, the costs of installation, etc.

3
Many of these questions still appear truly unanswerable. On the
other hand, it may be possible to assist us in our course of the 70's
by examining the experiences of the past five years. Even though
specific questions may not be answered, certainly the scrutiny of
the problem can be useful. Furthermore, in cases where we cannot
answer the question then maybe it is appropriate to understand why
the questions can't be answered.

For this reason, the following topics will be discussed in greater

detail:

• Characteristics of interactive graphics applications

• Examination of the evolution of the system support
that has been provided
• The role of the graphics hardware
• Examination of the long-range potential in light of
our current level of understanding

INTERACTIVE GRAPHICS APPLICATION CHARACTERISTICS

In almost every conference or meeting on interactive graphics one hears

relatively little about programming per se. The main topics are typically
associated with "problem solving". Are we discussing the problems of
interactive problem solving, interactive graphics, or both?

The implication is that the user is interacting with the computer system
and programs during the solution to his problem. Carried a step further,
we find that the" user can deal with the problem in his terms rather than
those of the computer. In fact, I believe our experience of the last
several years begins to indicate that we are dealing with a subtly but
dramatically different approach to the solution to problems on computers.

While there does not seem to be any great consistency or trend in appli-
cations, there are several which appear to have proven profitable in a
production environment. These would include:

1. Numerical control
2. Electronic circuit des ign
3. Circuit layout
4. Structural analys is
5. Optical deSign

These applications have the characteristics of involving a relatively

large number of engineers. When this is combined with a manpower

4
savings of something greater than six to one, and a turnaround improve-
ment of ten to twenty to one, the applications can become very attractive.

Early in our evaluation of computer graphics, we evaluated existing appli-

cations. One study that we conducted involved a selection of ten
candidate applications from a library of about a thousand engineering
programs. Each application was examined in some detail, both from a
user and an implementation standpoint. At first blush, an interactive
graphics implementation of these applications appears to be very attrac-
tive. Further study, however, indicated that the use frequency and total
number of users attracted was so low that it would be very difficult to
justify the conversion. We extended the study to consider the number of
additional programs in the library and generally came to the same
conclusions.

On the other hand, we examined some very low use applications which
turned out to have extremely high potential for manpower savings. These
applications were not frequently used on computers because the turnaround
time provided was inconsistent with the requirements of the user. These
programs were used in the solution of basic engineering design problems.
Their appeal to the user was reflected in his ability to easily communicate
the input data and understand the procedures required by the application
programs. In other words, we had high economic potential, user appeal,
and a mass market.

Our conclusions were that the typical engineering application in today's

computer environment is a complex, sophisticated program that is the
only effective way of obtaining solutions. These applications are typi-
cally used by a very small number of engineers. Probably somewhere
between five and ten per cent of the staff. On the other hand, there are
great masses of engineers who are solving problems without the use of
computers at all. These applications are typically in the design/
drafting or bas ic engineering environment and represent a potential for
something in the order of five to ten times those currently in use on
computers.

Another way of expressing the potential is to examine the explosion

that is occurring in the use of "conversational" or interactive program-
ming systems. Users are finding substantial improvements in
programming productivity with the application of these systems. In
addition, much larger numbers of people have access to the computer.

The benefits achieved by these approaches involve the concept that the
programmer can generate his results while interacting with the central

5
computer. Is it not reasonable for us to look at conversational
compilers, as semblers, etc., as the "applications" of the programmer.

If we look at computer programming in the application context, several

observations can be made:

1. Much of the emphasis on time sharing, over the past several

years, has been directed at a single application area.

2. That the economic potential is extremely large is indicated

by the wide acceptance of the concepts.

3. Problem execution is more often than not treated in the terms

of the computer discipline as opposed to the user discipline.

Another facet of the concept embodies the characteristic of the inter-

active application. Solutions are based on the evaluation of a number of
alternatives. An engineer or scientist must be able to deal with the com-
puter in the same way. The computer system needs to be structured in a
way which permits interaction with the solution of the problem during its
execution, dynamic change of the parameters, and evaluate the results
in the user's terms. One of the most significant values of computer
graphics facilities is that one can deal with information in terms that are
best suited to the engineer or user. This imposes on the system designer
a requirement to structure the application programs in a new way.

The application system requires a clear functional definition of applica-

tion modules, a clear separation of the input/output from the modules,
and substantial variations in the physical structuring of data files.

An expansion of the application requirements naturally leads to considera-

tion of the data base requirements. All indications are that these
requirements exceed anything we have previously encountered.

Data base records that exceed a million bytes in length will not be
uncommon. When you couple the size requirement with dynamic
access, the task is rather imposing. It is not my intent to imply
that the problem won't be solved but it certainly must be identified
I

as one of the major requirements we have before us.

During the past several years we have produced systems which

addres s many of these problems. For example the Problem Language
I

ANalyzer (PLAN) System was deSigned to provide a basic faCility that

links a large library of application modules with a data base and a

6
user-defined language. It allows the user to define the language in
his own terms. In addition, we have done a great deal of work on
data base support in the form of the IMS/360 System. Embedded in
IMS/360 is Data Language/I (DL/I) which was designed to separate
the structure from the application program.

Both of these programs cannot help but provide us with a much better
understanding of the kind of techniques that are necessary for solu-
tions to these problems. What is really important about these two
systems is that they evolved from studies of a broad range of
manufacturing and engineering application programs. Not because
of one application - but because we needed a broad based method-
ology to addres s a wide range of problems.

The nature of the computer software support for" interactive problem

solving" is different than that developed over the past several years.
It is only.recently that we have begun to understand these differences.
In many cases these software differences are very subtle but their
solutions are complex.

In summary, I would make the following points:

1. The availability of interactive graphics equipment has

stimulated much activity in the field of "interactive"
problem solving. It is becoming apparent that many new
techniques are required to design, execute, and operate
computer systems in this environment.

2. Those users who have attempted to attack the problem on

a very broad application base have had only marginal
success. Where efforts, have been directed to a relatively
few applications dealing with large numbers of users,
some fairly spectacular successes have been achieved.
3. The potential for Significant results in the field remains.
The problems associated with achievement are becoming
more clearly defined.
4. Future conversion to this type of environment can be
facilitated by maintaining a conscious awareness of the
requirements for modularity of application functions and
separation of the data management facilities from the
application programs. An awareness of these facts, plus
complete and accurate documentation, can substantially
reduce the complexity and cost of future conversions.

7
EVOL UTION OF THE SYSTEM SUPPORT

Any discussion of computer systems is typically very difficult due to the

complexity of such systems. Most users don't really care what goes on
inside of their computer as long as their problem is correctly solved.
On the other hand it is the computer system that dictates how applica-
I

tion modules can be structured how the input/output devices can be

I

attached I how the data can be managed I how the computer resources can
be shared how demands are serviced etc. In the world of batch
I I

computing I these problems are not too germain. In the world of interac-
tive problem solving these functions carry far greater significance to
I

the application deSigner and I therefore I need to be better understood.

One of the first problems we were confronted with in computer graphics

was the sharing of computer resources with other programs. A typical
graphics application uses only a very small part of the available central
processing unit capacity. The capacity of course will vary with the
I I

size of the processing unit and the nature of the application. On a

System/360 Model 65 we have found that this percentage will range
generally between 2 and 10 per cent per 2250 console. This statistic
alone dictates that the central processing unit be shared by other
consoles and/or application programs.

Our first successful implementation of a solution to this problem was

demonstrated in May of 1966. A modification of Operating System/360
was provided which subdivided computer core into fixed size partitions.
While all partitions were under the control of the Operating System I

each one looked to the user like a computer of its own. This system
permitted us to operate two 2250's in separate partitions with a batch
program in the background.

This was based on a multiprogramming concept which has Since been

expanded and incorporated into the supported versions of OS/360.
The multiprogramming fixed task system (MFT II) requires that the par-
tition size be fixed when the system is initiated. The variable task
system (MVT) allows dynamic variation in the number and size of
partition. Most large users are operating under MVT.

We next directed our attention to time sharing/time slicing. Sporadic

and uneven responses to a user's requests are not satisfactory from a
human factors standpoint. This was unnecessary for the first applica-
tion programs since console actions generated only very short bursts
of CPU load. This p'roduced something of a natural time Slicing in
the multiprogramming environment. Most of the programs were written

8
in serially reusable form and natural I/O waits allowed for uniform
servicing of the consoles. As the number of consoles or CPU load
increase, the need for time slicing evolves. Several techniques to
provide this facility were designed and the function is now supported
under OS/360.

The fact that these facilities exist under OS/360 has proven to be one
of the major factors allowing graphics experimentation in recent years.
Without them, dedication of the CPU would be required. With them,
the resources are shared at virtually no cost to the main line batch
user.

Our attention was next directed to the question of user interface to the
system. When confronted with the recognition that the 2250 consoles
will, in all probability, be located remotely from the computer a new
I

problem arises. How does the user activate his console? How does
he select his job? How is accounting controlled? How are files
identified? How does he terminate his session? etc. Here again we
were confronted with a problem with no previous experience in the
OS/360 environment.

Several systems are now available which accomplish these objectives.

The one which we produced in Los Angeles and released as a Type III
program is known as the Graphics Terminal Services (GTS). This sys-
tem provides the following features on locally attached 2250's or
2260's:

1. Logon

2. Job scheduling function (foregound or background)

3. Data Set Edit - The ability to create or update any

information stored in the system in the form of
partitioned data sets

4. SYSOUT - The ability to examine the results of

compilations executed either in the foregound or
background

5. Logoff

There are numerous other system considerations that can have an effect
on the success of the installation. Conservation of core storage is
perhaps one of the most difficult. As the number of consoles and

9
applications grow, this becomes more of a factor. Under almost any
circumstances the need for rather specific constraints must be placed
on the application architect. This includes the size of resident
executors, trans ient modules, data blocks, common res ident code, I/O
routines, system control blocks, buffers, etc.

Summary of systems experience-

1. Much of the progress with graphics has been associated with

techniques that have been developed from an in-depth
understanding of existing system support.

2. It will probably be necessary for some time to come to

integrate graphics systems into the" in-house" main computer
complex to produce economical results.

3. There are sufficient pieces of the basic systems requirements

available today to get started.

4. One can and should approach any implementation with clearly

defined procedures which will minimize future conversion
problems.

5. The systems environment needs to be much more clearly

understood by the application architect than in previous batch
techniques. (Note that the user will require far less under-
standing of computers.)

ROLE OF GRAPHICS HARDWARE

I believe that the role that the interactive graphics terminal plays in the
systems environment needs to be put into perspective. Let's consider
some of the device-oriented functions required by the system. These
would include: buffering, light pen tracking, incremental vectors,
absolute vectors, alphanumeric data entry, light pen interrupts, function
key attentions, alphanumeric display, interrupt identification, channel
load, CPU load, display resolution, refresh cycles, etc. These are but
some of the functions that immediately come to one's attention.

Generally, the implementation of these functions can be considered for

either the hardware or the software. In essence, these are tradeoffs
which can be considered either to reduce the price of the hardware or the
software.

10
If one is motivated primarily by a requirement to reduce the price of the
device ,the software approach would appear favorable. This means, of
course, that the functions required for the interactive graphics systems
would have to be totally software oriented.

On the opposite side, of course, is the fact that the functions can be
implemented in the hardware and produce a higher device cost with a
lower software requirement.

It is practically impossible to make a direct assessment of the economic

tradeoffs. Our experience does, however, lead us towards the hardware
implementation. In the past several years we have had considerable
experience on both sides. In those cases where software was used to
emulate the number of hardware functions, the programs became so com-
plex as to be almost unusable. In addition, they required such a
significant amount of the computer's capacity that they severely
restricted our ability to attach the required number of devices. To
superimpose this kind of a problem on what is already a complex system/
application software requirement could prove rather damaging.

I point this out simply because recognition of this problem is important.

The problem is compounded because price is very obvious. The
subtleties of the software are, however, not in the least obvious.

Another problem which seems to be frequently misunderstood is the

adaptation of remote interactive graphic devices. The problem is often
associated with the device itself when it really is a communications
problem. The interactive graphics system requires a broad-band, high
speed communication link between the central computer and the device.
This requirem~nt is generated because of the requirement of high
volume, burst mode type of data. Common carrier facilities which match
the requirements of the system are not yet economically available.

The most common solution we have found to this problem is the attach-
ment of what are known as channel extenders to the system. This
allows the user to extend his device up to ·about 12, 000 feet from the
computer system.

LONG RANGE POTENTIAL IN LIGHT OF OUR CURRENT UNDERSTANDING

I believe it is safe to say that the computer explosion in the last ten years
has been primarily associated with record keeping functions. It is some-
what paradoxical that the early stimulus for the market of large commercial

11
computer systems was provided by the scientific community. It is true,
however, that one can hardly rent a car, cash a check, fly an airplane,
buy stocks, etc. , without becoming either directly or indirectly involved
with a computer record keeping system.

As previously mentioned, relatively few engineers or designers have direct

access to the computer. Most of the problems that are currently solved
are relatively large or extremely complex. The inputs to these problems
are typically extracted from laboriously produced drawings or schematics,
computations of basic attributes, or the extraction of specifications or
standards which require many hours of engineering time. It would appear
to me that these basic functions are the ones which warrant the greatest
attention.

I believe this contention can somewhat be borne out by the tremendous

acceleration in demand for the time-shared terminal or small computer by
the engineer. Typically, however, the engineer must still learn the trade
of the programmer and deal with the computer in the programmer's terms.
The successful graphics user has been given an opportunity to deal with
the computer in terms most closely associated with his discipline. If
this concept can be exploded on a broad basis, then an explosion of
computer use in the engineering community can be expected which is akin
to that which occurred in the record keeping functions.

This is, of course, all well and good except that a question is typically
asked, "who can afford it?" This is a perfectly valid question and
certainly deserves attention. I believe this question carries much the
same connotation as it did to general purpose computers 15 years ago.

Before addressing this question, I think I should restate a part of the

premise of this paper. We are addressing the question of interactive
problem solving in terms that are consistent with the discipline
involved. This does not involve teaching the engineer to become a
computer programmer. On the other hand, the application des igner must
become something of an engineer. The environment must be thoroughly
understood and agreed to, the basic application functions clearly defined,
and the data base requirements understood. Nothing that is embodied in
the cost chara9teristics of either the hardware or software could change
this requirement. I believe that once these concepts are understood the
cost characteristics of the environment take on far different significance.

Certainly the high cost of the computer graphics environment has been a
deterrent to a number of potential users. Most of the early users have,
in fact, spent conSiderable sums of money in developing these

12
capabilities. In light of the apparent slow progress and the level of
investment required ,one would normally expect a regres s ion in develop-
ment. . My impression is that just the OPPOSite is true - the development
activities of the early users have continued at an equal or higher rate
than in the past. It appears that the advantages cited five years ago
have been achieved in a sufficiently broad range of applications that the
efforts are continuing.

An examination of the life cycle of a product from deSign to shipment can

probably shed some light on the reasons for this continued effort. The
effective implementation of interactive computer graphics techniques in
this cycle can have a more direct bearing on our ability to condense it
than any other single facet of the presently known computer techniques.
The proven advantages of this technology involve a substantial reduction
in manpower and greatly improved turnaround time. When applied across
a broad range of bas ic applications the ultimate potential is extremely
I

high.

This leaves the question open relative to the smaller user. He certainly
has the same problems as our larger customer but not on so grand a
scale. How then can he afford to become profiCient with the techniques
implied. We have atte,mpted to address this question with a system
previously mentioned known as PLAN.

PLAN was originally designed for the IBM 1130 computer. For those who
are not familiar with the 1130 it is a small binary computer which is
I

relatively inexpensive. It can operate as a stand-alone system or be

attached via teleprocessing linkage to a large central computer. It also
has a faCility for attaching a 2250 console to it.

While PLAN was not originally designed for graphics it was deSigned
I

for interactive problem solving. It provides a facility which allows the

user to develop a library of functional modules the ability to catalog
I

and index these modules the ability to dynamically load the modules
I I

and the ability to define the language of use in the user's own terms.
We have used the system to great advantage for the development of a
number of our application programs.

The PLAN System not only provides the user with an inexpensive way of
deSigning conversational application programs but gives him a tool
which will permit a better understanding of the technologies being
discussed.
An extension of the PLAN System known as PLAN Graphics Support (PGS)
I

is available if one wishes to attach a 2250 console.

13
I previously mentioned our selection of Operating System/360 as the
major vehicle for our development. We looked at a number of highly
specia:lized systems programs and rejected them because of user cost
considerations. Our main thrust has been to integrate the interactive
graphics funcUons within the framework of our customers' main line
teleprocessing and batch systems environment. This, of course I is
OS/360.

When the 2250 is attached to a large computer in the OS environment,

the user is typically charged by the hour. We have found relatively
little consistency in the per hour cost figures that are represented.
They typically range from $50 an hour to $200 an hour. These figures
are a direct result of the internal accounting procedures that are used
within the various organizations.

Once a broad base of utilization is established, these figures can drop

Significantly. At today's hardware and terminal costs it can be shown
that rates.ranging from $20 to $50 an hour are achievable.

In summary, I would make the following observations:

1. The potential for profitable applications in the interactive

computer graphics environment still exists. Most early
users are continuing to press for expansion of the
facilities which have been developed.

2. There are low-cost entry systems which can minimize the

cost exposure. These systems embody much of the
methodology that is required in the larger systems.

3. While the hourly cost of terminal usage is still high it

I

can be brought in line with current prices. This will

happen when the application base is sufficient
to bring enough users into the system.

SUMMARY AND CONCLUSIONS

I have attempted to provide some detail in some of my personal experi-

ences related to the field of interactive computer graphics. These
points of view are the result of about five years experience in dealing
almost full time with the problems involved. They do not necessarily
represent the generally accepted views of the IBM Company but have
been accepted in many circles.

14
While there are still many problems that have not been resolved, I
remain confident that the potential for profit in the field is huge. To
me it is significant that the problems have been identified as rapidly
as they have. A great deal of support has been provided during the
past several years. There is certainly sufficient capability to permit
one to get started in the field. I believe the progress of the last five
years represents far greater advances than all the previous years
combined.

Our major chores during the coming years will be to consolidate and
expand on this support. This will require further experience and
analysis in order to continue to address the basic problems.

Five years ago we predicted it would be ten years before we came close
to our ultimate objectives -- I still believe this to be a realistic predic-
tion.

15
 FUNDAMENTAL PROBLEMS FACING THE
GROWTH OF MAN COMPUTER GRAPHICS

S. H. Chasen
Senior Staff Scientist, Head, Man-Computer Systems,
Lockheed Georgia Company, Marietta, Georgia 30060,
U.S.A.

ABSTRACT

The paper describes four broad problem areas which face the growth of
man computer graphics. They are economics, the realization of the
true potential, software, and implementation. Some solutions are
suggested. For example, economics can be attacked through better
system utilization, better system integraticn, and by assessing other
attributes. The problem of realization of potential is addressed
through a discussion of the principles of computercentrics and optimal
design and analysis is explained.

In addressing the software problem, the potential role of modeling

and simulation is discussed. A point is made regarding the increasing
dependence on good judgement for software and other system assessments.
Suggestions for solving the last treated problem of implementation
are given in terms of the vested interests of users and in terms of
picking initial applications where technical interfacing problems are
minimal. In concluding, the paper states that the very nature of
man-computer graphics portends inevitable growth even though the in-
herent problems are substantial.

17
FUNDM~NTAL PROBL&~ FACING THE GROWTH OF l~-COMPUTER GRAPHICS

The age of interactive computing has brought forth an opportunity to

advance technology perhaps more than has conventional or batch com-
puting. Commensurate with this opportunity are the increasing com-
plexity of the computer system and the relative decrease in available
expertise. These problems are basic, but there are many other prob-
lems that must be overcome before interactive computing in general
and interactive graphics in particular can mature into its fun po-
tential. (Interactive computer graphics is called Ilman-computer
graphics" or IIMCGII at Lockheed-Georgia and this term will be used in
the sequel.) Like an astute investor who p1rrchases good quality
securities while earnings and prices are low, the technical world
has exhi bi ted great confidence in the future of r-'lCG as is evidenced
by the rapidly expanding interest and investment in the field. There
are few computer conferences today that do not include MCG concepts
as a significant part of their programs. The widespread interest
has spread into governmental circles as well as the academic and in-
dustrial communities.

In mid October of last year, for example, there was a major confer-
ence in the U. S. that treated the subjects of Computer Aided Design
(CAD) and Computer Aided I1anufacturing. This conference was spon-
sored by the Department of Defense and the principal industry associ-
ators. Experts were gathered from about the country to form working
panels that would set forth positions on a number of relevant topics.
Since interactive computer graphics is closely aligned with CAD, many
of the statements about CAD apply to graphics. This is particularly
t~ue of the introductory statement of the panel position on CAD state-
of-the-Art. It stated lllike many other areas of computer usage, CAD
is at an interesting adolescent stage. If we regard ourselves as
parents of this adolescent, we feel the same concerns over its growth
as we would toward any charges we brought into the world. We can
only barely remember how we conceived it; we recognize that its growth
is inevitable and we feel that we should be guiding it in a way that
encourages it to ripen into a responsible and respected member of
societyll. This very descriptive passage certainly applies to MCG
except, perhaps, an adolescent status may be too generous. Only a
very few activities have had iive years of experience. Therei'ore, a
kindergarten stage might be more appropriate.

18
It is not without a deep appreciation of the youth of MCG that we face
the problems that it must overcome in its growing process. Perhaps
the most prevalent and the most fundamental problem is that of eco-
nomics.

Getting into a meaningful productive use of MCG is a relatively ex-

pensive proposition today. The user must add the costs of facilities,
development, and administration to the basic cost of hardware. To
bring about minimum costs, the MCG system must be heavily utilized
and the computer should be employed for cmnventional batch while higher
priority graphic CQnsoles are not calling upon the computer. Without
attempting to go into a detailed breakdown of all related costs, it
seems that about $6000 per month is realistic for an adequate gra~hic
console that can be used to solve a variety of fairly complex appli-
cations with acceptable interactive response times. Unfortunately,
most installations have not, to date, brought about the efficiencies
necessary to even approach the $6000 figure. However, $6000 is still
a tough figure with which to cope. It is equivalent to almost $40
per hour based on 8 hours per day ~tilization. In the U. S. where a
console operator may cost approximately $10 per hour including over-
head and fringe benefits, the operator must produce almost five times
his conventional production to defray the cost of the system. It
should be recognized that pure cost is by no means the only criterion
for the use of graphics. The reduction in cycle time, the improvement
in product quality, opportunities for new systems approaches, and
more rapid and comprehensive learning are characteristic of MCG and
are certainly non-trivial. It is difficult to assess these attributes
and it is quite difficult to judge what levels of expenditure are
warrented to bring them about. Regardless of these advantages, there
can be no proliferation of MCG as long as costs remain at such levels.
If ~very man were to have access to a graphic console, the cost of
present operations would increase by a sizeable multiple.

The question is often asked, "what would be the cost level required
to bring about heavy utilization?" That is, of course, a qualitative
question which might be addressed by making an analogy to an entirely
different problem--a flood. When a river rises out of its banks,
each foot of further rise results in coverage of vast areas of land.
The coverage is a function of the statistics of the terrain. In a
similar way, any decrease in system costs for graphics will result in
tremendous increases in utilization. Correspondingly, the amount of
justification required prior to implementation would be drastically
reduced. The expected exponential expansion in utilization as a
function of reduced costs is depicted in Figure 1.

In spite of the inhibiting influence of high costs, economic benefits

have been documented in isolated cases. As an example, during the
first nine months of use, the Lockheed-Georgia Company realizes a

19
saving of $250,000 using MCG for structural analyses on the C-5A in
lieu of using conventional computing procedures. It is interesting

tl = COST OF FOUR TIMES SALARY OF OPERATOR

OPERATORS NUMBER IN THE HUNDREDS
t (ESTIMATED)
2 COST EQUAL TO SALARY OF OPERATOR
OPERATORS NUMBER IN HUNDREDS OR THOUSANDS
FIGURE 1: EXPONENTIAL GROWTH OF USERS VERSUS
DECREASING COST FOR UTILIZATION

to note that the saving was a result of reduced man hours for data
reduction. Based on a less than optimal graphic console rate of
$75/hour, purely computational costs were approximately equivalent.

20
Another major problem facing the growth of MCG is the full realization
of its true potential. Of course, no one can anticipate the many
innovative ways in which the MCG system will be manifested. In fact,
only the more experienced can see beyond the near term values as
applied to specific applications. Certainly, specific applications
are useful in demonstrating to management the nature of the concepts
and in stimulating their minds towards MCG use on a wider spectrum
of applications. But relatively few realize that such MCG benefits
are comparitively minor in terms of a more comprehensive computer-
centric potential. In such a system, it will be possible to view
multiple applications in proper perspective. In industry's present
mode of highly specialized operations, we tend to optimize in short
linear steps as exemplified by the chain of Figure 2.

A, B, AND C ARE THREE SPECIALTY AREAS THAT PERFORM AN UNPREDICTABLE

SEQUENCE OF ANALYSES
FIGURE 2: "DAISY CHAIN" OF PROJECT EVENTS

21
In this chain, the operation is characterized by the three specialty
areas, A, B, and C. Each specialty performs its analyses and design
contribution in the best way it can. The process toward project
completion is passed on from one specialty to another with frequent
repeated efforts on the part of each specialty. The actual sequence
or order of specialty action may differ from project to project, but
the objective is to complete the total project in minimum time and
minimum cost with maximum quality. The "daisy chain" is quite eratic,
in general, and is ripe for straightening.

Another way to view this problem is represented in Figure 3. Here

the process is simplified for the sake of discussion. The project
requires the application of a sequence of five specialties--each
performs its function once and only once. If we define the conven~
tional or established sequence as A, B, C, D, and E, then two
possible sequences might be as depicted in the figure.

Tne first sequence follows the process in the established order.

When specialist, liB", is asked why he always takes data from "A"
and gives to "C", he will probably state that that is the way it has
always been done. He may know very little about the roles played
by "D" and "E". The convention has long been established although
there may be no one around who can describe how and why it got that
way--it just grew. Hopefully, it grew in some rational or orderly
fashion, but that may not be the actual case. If the process had
evolved in a wild or malignant way, we would like to perform tech-
nical surgery to bring the process to a reasonably normal and logical
sequence. With the advent of MCG systems, it becomes feasible to
think of multiple applications that might be interrelated through a
computercentric system. This system will provide the capability for
a console operator to call upon different applications in such a way
that he can personally perform larger segments of the design and
analysis processes. More people will be afforded a clearer picture
of the interrelationships and the relative roles of various functions
that constitute the entire process. With such an overview, one might
redirect the illustrative sequence as depicted by the second sequence
of Figure 3. If the length of the path is proportional to time or
cost, then the second path represents a time or cost reduction by a
factor of two.

It is in this sense that MCG offers its greatest potential. We will

be able to learn more clearly how and why we do things and we will
be, therefore, given the opportunity to "optimize" our processes.

As in most cases where we attempt to pick a word or a phase to charac-

terize a concept, the term, computercentrics, can be easily misunder-
stood. Some people feel that it implies the concept of displacing
man's role by complete automation. This belief is incomplete contra-
diction to what is intended. The term, computercentrics, was initiated
at Lockheed-Georgia to imply the enhancement of man's capacity by

22
giving him the best of possible opportunities for technical, communi-
cation and computational power. It is certainly true that some of the
more mundane jobs may be gradually eliminated. However, a gradual
C

D
EXISTING SEQUENCE

D
PROPOSED SEQUENCE = 1/2 EXISTING SEQUENCE

FIGURE 3: COST OR TIME DIAGRAMS TO PERFORM THE

SAME FIVE EVENTS
evolution affords ample time for people to adapt and change to new
occupations which will be the outgrowth of the expanding technology.

The efficient handling of multiple applications and their generated

data logically leads to another major problem that must be given high

23
priority. This is in the area of software. With the proliferation
of hardware devices, there is a veritable infinitude of configuration
possibilities. Along with this hardware are the ever increasingly
sophisticated executive systems which attempt to blend the best fea-
tures of the hardware, the application program, and the console oper-
ator in such a way that the console operator is permitted to do what
comes naturally to him in a harmonious diologue between man and com-
puter. Unfortunately, there seems to be no scientific approach which
dictates specifications for software systems that adapt to changeable
hardware and applications. Ideally, it is desirable to create a
general software package which can adapt to most anything, but too
much generality leads to severe problems in capacity and in acceptable
on-line response times. Unquestionably, this is a delema. When we
get one attribute within tolerances, other attributes are likely to
fall outside of tolerances. We have a significant problem in getting
sufficiently versatile software with adequate capacity and acceptable
on-line response times at prices we can afford. In other words, the
practical system is inherently expensive.
The increased complexity of the software, the hardware, and the appli-
cations'makes trouble shooting or debugging somewhat more difficult.
WIlen an error occurs on an MCG system, it is by no means always clear
as to what failed. For example, on a prototype structures problem
at Lockheed-Georgia, the screen would "bomb out" whenever a vector
went through the center of the screen at coordinates, zero, zero. It
was not known whether or not an overflow condition was caused or
whether there was some peculiarity in the scope. It was eventually
determined that there was a loose wire in the scope that set up tran-
sients whenever the vector went through the scope center. These
transients can play havoc with hardware and are often set up by
nothing more than a power surge.

The problem of designing efficient software is further increased by

the requirements imposed on data structure techniques, data management
techniques, and the treatment of geometry.

The increased system complexity as a function of both the increasing

variety of hardware and increased user options point to a requirement
for the development of configuration simulation. The art of modeling
and simulation is often overlooked simply because it is difficult to
establish adequately meaningful models from which we can make decisions
with confidence. Furthermore, the prerequisite skills to create such
models is in extremely short supply. Such models require the ability
to create and blend the representation of a system in simple terms,
statistical distributions and Monte Carlo techniques, deterministic
functions, and mathematical formulas. Unfortunately, those who are
given the responsibility to evaluate existing and potential systems
often have little of these skills. More unfortunately, they often
are unaware of the serious falacy that the average time for a sequence
of events is most difficult to judge when the process contains many
branch points and a variable number of iterations.

24
As systems become more complicated, the opportunity to make precise
analytical assessments becomes increasingly difficult. Perhaps 90%
or better of our decisions are largely judgemental in nature. We
are forced into relying more and more on the technical judgements of
those in whom we have either recognized their judgemental ability or
in whom we have designated the judgemental responsibility. Character-
istically, the latter case is far more prevalent. As our technical
personnel mature, it is most essential that we learn how to figure
their "scoring potential", as in English football. We must be careful
to avoid persuasive theories from those who have a history of inaccuracJ
On the other hand, we must be careful not to criticize the kicking
techniques of those who have demonstrated a superior ability to score
goals. It is essential that we learn how to identify high quality
judgement and expertise.

The last problem that will be discussed in this paper is that of

transferance of technology and implementation. Man is a creature of
habit. He is basically insecure in the face of new concepts. Further-
more, the productive demands which are made upon many technical men
preclude their spending much time evaluating new or conjectured con-
cepts. When a new computer technique is conceived for example, how
can one tell what will be its effectiveness unless it is put into
service--and trial and error is generally impractical. Perhaps the
most universal problem in inhibiting the introduction of new concepts
is the "not invented here il or "NIH" attitude. Those who may have or
may feel that they have the charter to develop new techniques may not
provide them because they may have other time absorbing assignments
or because they may not have adequate skills within their organization.
Whatever may be the reason, they are not likely to look favorably on
someone else who performs services for which he does not have a clear
mandate. One effective partial solution to the NIH problem is for
the conceiving activity to share its role with others who may feel
that they have the developmental charter. The hope would be that
all concerned activities would feel that they had a vested interest
in the final outcome. We have observed many situations where cul-
tured team work has led to significant advancements with an adequate
supply of laurels for all. MCG has its best chance of success if
researchers, developers, and users can realize that inlightened self-
interests are satisfied through constructive cooperation with a minimum
concern over who invents the concept.

A very practical problem in introducing MCG is the interface problem.

How can the new techniques be smoothly introduced? It must be under-
stood that any new tool such as MCG normally supplements but does not
replace existing tools. The technical interfacing problems are sig-
nificant and they dictate a carefully planned evolutionary approach.
Initial applications must be relatively easy to introduce. This was
the case with the Lockheed-Georgia numerical control application in
1965. The introduction of MCG did not change the fact that a part
programmer starts with a blueprint and the system produces a C/L tape.
Interfacing, therefore, was easy to accomplish.

25
In summary, the principal problems have been cited as economics,
realization of full potential, software, and implementation. Some
solutions have been suggested. The economics problem can be attacked
through better system usage, better system integration, and by assess-
ing the value of other attributes. The problem of realization of
potential can be addressed by emphasizing the very nature of inter-
act.ive computation. The concept of computercentrics promises the
breadth of understanding necessary for more optimal design and analysis.
The ever increasing problem of developing complex software can be
attacked to some extent through modeling and simulation. Dependence
on judgement is becoming increasingly essential in assessing software
potential. Therefore, it is suggested that more emphasis be given
to the recognition of those who have developed a proficiency in
applying good judgement. The last treated problems are transition
and implementation. They can be attacked by getting concerned organ-
izations to have vested interests and by picking initial applications
where technical interfacing problems are minimal.

In conclusion, the problems facing the growth of MCG are quite sig-
nificant. Whereas we might expect to take a few discouraging back-
steps on the steep climb to success, the very nature of MCG portends
its inevitable success.

26
ASPECTS OF INTERACTIVE GRAPHIC SYSTEMS

Richard J. Dowe

Applications Development Dept., Control Data Corpora-

tion, Northwest Industrial Park, 3rd Avenue,
Burlington, Massachusetts, 01804, U.S.A.

1. INTRODUCTION

During the last decade, were you a clock watcher? Leonard da Vinci
wrote" A clock (is) to be used by those who grudge the wasting of time. " 1
Those of us who were involved in the advancement of computer graphics
during the last decade might ponder that question. How many of us were
clock watchers? Was there a wasting of time?

This paper discusses various aspects of interactive graphics,

treating of the developments which occurred in the Sixties and the
developments which will be necessary in the Seventies. It attempts to
isolate some of the critical features of an interactive graphic system and
to offer an explanation of how these features contribute to system
performance. To be considered are the effects of multi -programming,
the requirements of on-line mass storage, the evolving role of the graphic
system executive core memory, communications techniques, and remote
versus local display terminal features. System-effective design
alternatives or tradeoffs are discussed and some features of Control Data's
current interactive graphic system are outlined.

27
II. CRITICAL SYSTEM FEATURES

A. COMPUTER OPERATING SYSTEMS

1. Progress in Utilization of Computer Operating Systems

In the early part of the last decade, the principle

limiting factor to cost effective graphic systems was the constraint of
the executive operating system. The nature of the executive operation
was such that the computer system, in most situations, was fully
dedicated to one application utilizing one console. Advancement was
later made from this relationship of one executive to one application to
one graphics console to a situation where the central computer system
supported a multi-console configuration. However, this improvement-
still suffered from the restriction of allowing only one application to be
run at a time. The limitation made application efforts so expensive that
only large organizations of substantial financial resources were able to
utilize interactive graphic systems. Clearly what industry was seeking
was a means of overcoming the system-effectiveness barrier and
bringing interactive graphic systems within the reach of a major portion
of the business and scientific world.

2. Utilization of Computer Time

In addition to the concern for having a computer system

available to perform various functions was the concern for how well
computer time was being utilized once it was available. The individual
user of a graphics system, be he programmer or scientist, operates in
a continuous thinking process while at the display console; but he is not
necessarily continuously interacting with the system, nor is he
physically at the display console all of the time. This pattern of graphics
utilization by the individual made it imperative that the means be
developed for many individuals to have the computer system available to
serve their various needs concurrently while allowing other activities,
such as batch processing, to be on-going on a continuing basis.
Furthermore, the interactions of the various users should be
independent so that any programming and user errors of one job would
have no effect on other jobs.

3. An Approach to a Solution

In the latter part of the 1960's, a significant

improvement was made in computer operating system technology,
primarily in the development of multi-programming capability. This

28
development provided the impetus for improvements in interactive
graphic display systems in both hardware and software capabilities.

The effects of these developments have not yet been

adequately evaluated; however, initial experiences seem to indicate a
major drawback. That is that these graphic computer systems are still
limited in the number of consoles they can simultaneously support.
Projected requirements for the mid 1970's indicate a need for multi-
console systems of from 20 to 50 terminals. There are current
examples of five-console systems (for example, the General Motors
Research Laboratories) and 12-console systems (The Lockheed ... Burbank
facility). Also, at Convair, San Diego there is a multi-console
installation with two 274 display systems at a remote location (11 miles
from host computer). In general, however, the bulk of the remaining
users have single-console systems.

B. MASS STORAGE CHARACTERISTICS

Characteristic of interactive graphic applications is the

extensive amount of mass storage required. This amount of mass
storage is due to the number of application programs or subroutines
(from 2500 to 3000 separate routines) per application system and to the
sizes of the application data files.

Experience to date indicates that the ~~tal size of data files

for graphic applications run around 10 10 bytes. ( However, several
minutes of elapsed time can be tolerated when a console operator
attempts to bring online a portion of this total file. Online response is
then required for that portion of the file only. An online response must
be satisfied within 30 to 50 miliseconds. The online storage for
application data is in the order of three times 10 5 bytes per console job.
Mass storage requirements for pro~ram instructions for an application
system ranges from 6 to 8 times 10 bytes of instruction data. However,
during the actual operation of a console job, instruction data accessed
from this large file is in the order of 1. 5 times 10 4 bytes.

C. RESIDENT CORE MEMORY REQUIREMENTS

The resident executive core requirements for an interactive

graphics system is highly dependent upon the system characteristics;
i. e., it is dependent on the number of functions serviced by the display
terminal rather than the number of functions performed at the host
computer. In the CDC 3300 multi-programming interactive graphics
system, the resident executive core requirements are 3600 24-bit words

29
of memory. Latter are described the features of this system and the
types of activities performed by this resident executive. However, it is
reasonably certain that this amount of resident executive space is a
maximum requirement because in the next generation of graphic systems
more of these functions will be performed at the terminal.

Core memory requirements for the application program is

also highly dependent on the characteristics of the application system.
Experience with CDC 6000 and 3000 users indicates an application core
memory requirement in the order of 15-25,000 words. However, both
of these systems feature the capabilities of random access from mass
storage of program tasks through a multi-task (overlay accessing)
application system and of file data through a data manager system. These
capabilities provide the means of minimizing core memory needs per job.

D. COMMUNICA TIONS TECHNIQUES

Communication costs are affected directly by the rate of

data transfer and the distance between the display terminal and the host
computer. Figure 2-1 depicts the communication system cost relative
to data transfer rate and distance. Figure 2-2 portrays the
relationship of data transfer rates for responses for an average bit
count. This relationship is expressed in terms of time to respond. It

Transfer Distance

Rate 200 Ft. 1000 Ft. 1 Mi. 25 Mi. 100 Mi.

2000 BPS $ 83 $ 83 $ 83 $ 83 $ 83
2400 BPS $ 78 $ 78 $ 78 $150 $ 308
40800 BPS $440 $440 $ 440 $815 $1940
6x10 6 BPS $ 0 $ 10 $1010 n/a n/a

Figure 2. 1 Monthly Communication Costs

Note: Channel and/ or multiplexer charges excluded

Worst Case
Transfer Avg. Response Response
Rate 3K Bit Count lOOK Bit Count
2000 BPS 1. 500 SEC. 50.00 SEC.
2400 BPS 1. 200 SEC. 41.00 SEC.
40800 BPS . 070 SEC. 2.45 SEC.
6xl0 6 BPS .005 SEC. D.16SEC.
Figure 2. 2 System Response ... Time per Transfer

30
is evident that in those interactive graphic systems where both a rapid
response and a remote terminal capability is necessary the communica-
tion costs are going to be high. Ideally one would like to configure a
total system such that applications requiring high response rates are
performed by locations adjacent to the host computer and those activities
tolerant of slower response rate are performed at remote locations.

However, an emerging axiom for the next generation graphic

system is that in all cases the interactive graphics terminal and system
design must insure independence of the communication interface. The
graphics system must be made easily compatible with all ranges of data
transfer rates.

E. DISPLAY TERMINAL CAPABILITIES

Early interactive display terminal systems were characterized
by either utilizing directly the main computer memory as its refresh
buffer or where an independent refresh buffer was used of still being
directly coupled to the central processing unit. It was the central
processing unit that interpreted all operator actions. The next
generation graphic terminal systems (mid to late f960' s) featured a
further division of functions between the central processing unit and the
display terminal, e. g., CDC's 3344/274 system. This evolutionary path
in the design of displa;y terminals has been characterized by Messrs.
Sutherland and Meyer(3) as resembling a circle and the terminal design
process as being on a 'wheel of reincarnation.' I take exception,
however, to their notion that when a display system requires more
capability it is the central processor unit rather than the display terminal
that needs improvement. This I.believe is a misinterpretation of the
role of the host computer in a highly interactive system with many
terminals. Current experience indicates that to support future multi-
console requirements a larger amount of system functions must be
performed at the terminal. Experience at General Motors Research
Laboratories showed that something on the order of 600 responses per
hour were requested of the central processing unit. (~) Estimates of the
amount of data transfer necessary for each of these requests ranged from
a 6000-bit average data transfer to a 100, OOO-bit worst case data
transfer, this worse case being a total redisplay of from 3000 to 4000
vectors. In a system in which many of the features that have been
performed by the central processing unit are transferred to the display
terminal, this rate of response is halved. Where the load on the CPU
can thus be reduced, the number of consoles that the system can
support may be increased.

31
 3000 IGS - DIRECT CHANNEL COMMUNICATIONS

- - HOST COMPUTER - - -

MASTER OPERATING
SYSTEM
APPLICATION
• SOFTWARE INTERRUPT
PROGRAM HANDLER

• HARDWARE INTERRUPT
HANDLER

• DISPLAY ITEM QUEUING

GRAPHIC
• A/N QUEUING
SUBROUTINES
• CONSOLE COMMUNICATION
CONTROL TABLE

FORTRAN
CALL
INTERFACE
~ BUFFER INTERFACE

6000 IGS - REMOTE COMMUNICATIONS

- - - HOST COMPUTER - - -

SCOPE
APPLICATION OPERATING
SYSTEM
PROGRAM COMM.
•
PACKAGE
•
(IMPORT)
• COMM. PACKAGE
GRAPHIC
(EXPORT)

SUBROUTINES
•

FORTRAN
' - - - - - CALL
INTERFACE
~ BUFFER INTERFACE

FIGURE 3.1 DISTRIBUTION OF

32
 - - DISPLAY SUBSYSTEM--

CONTROLLER

• 4.16K BUFFER

8
• HARDWARE
TRACKING
~

• HARDWARE MOVE

• MACRO FUNCTION

• SUBROUTINE
FUNCTION

UP TO EIGHT
_I.--

L
DISPLAY SUBSYSTEMS
PER CHANNEL

TERMINAL COMPUTER - - - ---DISPLAY SUBSYSTEM--

TERMINAL OPERATING SYSTEM

CONTROLLER
• DISPLAY STREAM GENERATOR

• INTERRUPT PROCESSOR
..-- • 4-8K

8
BUFFER
• SOFTWARE TRACKING
roo !---
• MACRO
• A/N QUEUING
FUNCTION
• DISPLAY ITEM QUEUING

.. CONSOLE COMM. CONTROL

TABLE

[ BUFFER INTERFACE
I--

L-
UP TO SIX
DISPLAY
SUBSYSTEMS

SOFTWARE FUNCTIONS

33
III. CDC's CURRENT INTERACTIVE GRAPHICS SYSTEM DESIGN
PHILOSOPHY

In early 1969, Control Data released to the field as a standard

product. an interactive graphics system for 6000 and 3000 computer
lines. The 6000 IGS supports both local and remote terminal
capabilities. Figure 3. 1 depicts the distribution of the software system
capability between the host computer and the display terminal. In this
instance, the display terminal is a 1700 computer along with the 274/1744
display system. The 3000 IGS is a direct channel connection. The basic
software system design for the 3000 IGS is similar to the 6000 IGS. The
software system capabilities outlined show a design consistency in both
approaches. The 6000 IGS system utilizes the terminal computer to
perform many of the functions; for example, alphanumeric text input
queuing and display item data queuing, whereas in 3000 graphics these
are done by the resident executive system. The 6000 IGS approach does
represent a still further distribution of functions from the host computer
to a terminal computer.

I'll now discuss the characteristics essential to an interactive

graphics capability, utilizing the 3000 system as an. example. The lower
3000 (3300/3500) computer line features theMASTER Operating System.
MASTER is a multi-programming system. It provides the framework
for a multi-console interactive graphics system. This graphics system
operates in a real-time mode.

One important characteristic of our graphics software design, and

a principle guideline, has been the need to maintain a commonality, a
compatibility among our computer hardware systems. This need
resulted in our developing a basic graphics software package conSisting
of a set of FORTRAN-callable subroutines. We have implemented this
set of subroutines not only in the 3300 system, but also in our 6000
interactive graphic system and in our 1700 stand-alone system.

The MASTER multi-programming system supports the simultaneous

operation of completely independent application jobs. Each job is
protected from the actions and flaws of other jobs. Any job may use one
or more graphics consoles.

A significant advantage of the MASTER approach is the fact that

jobs of various sizes can be processed at one time and that core can be
dynamically allocated so that the number of jobs being executed
Simultaneously can vary from one time period to another time period.
This can be accomplished without any modifications to the operating
system.

34
 Functionally, the basic graphics package is divided into these parts:
application executive routines, graphic utility routines, graphic interface
routines, and the resident executive interrupt handler routines. Of these,
the first three types of basic graphics subroutines are co-resident with
the graphics application instructions and data. The application executive
is a set of library routines that provides the control mechanism for
segmenting and sequencing application tasks or overlays. This
capability allows for efficient random accessing of application tasks.
The graphics utility routines are a set of library subroutines of general
application to graphics. These encompass scissoring, list processing,
and byte stream generation. Graphic interface routines provide tasks
for editing the display buffer, for controlling light pen and keyboard
inputs, for light pen tracking, and for alphanumeric text inputs. The
resident executive interrupt handlers consist of subroutines for
processing both hardware and software (that is, application-program-
generated) interrupts.

A principle feature of the 3300 IGS System is its processing of

many graphic console operator actions independent of interaction with
the graphic application program. This gives the operator a feeling of
immediate response to many of his requests while imposing a minimal
load on the CPU. This capability is enhanced through innovations in
both our graphic hardware and software designs. Software techniques
include the queuing of display item ID data and of alphanumeric data.
This queuing of tasks is performed by the resident hardware interrupt
handlers.

Akin to this feature is the ability to dynamically alter the

functional meaning of display item identification data without accessing
the controller's display item buffer. This is done by modifying resident
table settings. These table settings allow the hardware interrupt
handlers to interpret the functional meaning of an operator's action;
for example, a display item which has been selectable as a function
button may become ignored (not selectable) or may be classified as a
single pick item.

Hardware techniques that reduce CPU load time include hardware

tracking and hardware erase features. Hardware tracking is the
capability of the display system to move (by following the light pen)
the position of the tracking cross at operator direction. It executes this
capability off line, i. e., independent of the central processing unit.
Hardware erase is achieved by the independent movement of a segment
of the display core buffer up and over the old data (the data to be erased)
to a new core buffer position. This action is initiated by receipt of a

35
command from the central processing unit. Both of these features place
little or no load on the CPU while providing an immediate response to
the console operator.

The interactive graphic system, just briefly outlined, has been

implemented under these design philosophies:

1. Application programs are to be written entirely in FORTRAN.

2. The application programs may be as simple as a single

FORTRAN program run as a load-and-go from compilation
or be as comprehensive as a package requiring several
hundred subroutines to provide graphic support.

3. The display consoles are completely independent in their

actions. The operating system provides all the sequencing,
resource allocation, and sign-on/ sign-off duties without
reference to consoles.

4. All of the graphic hardware is accessible to the application

programs.

5. Application errors are confined to the application job where

they may be diagnosed by conventional methods. This means
that the actions of one job can in no way affect the execution of
other jobs.

6. Only the real-time graphic executive and associated table-

manipulation programs are resident in core. All other graphic
system programming exist as library subroutines loaded as
needed into the application jobs. Interconnection of
subroutine calls and data passage to and from the calls are
strictly an application programming function.

7. All of the file handling and mass storage capability of the

standard operating system is available to the application job
for data structuring. Library subroutines are provided to do
generalized mass storage and in-core list processing.

8. The system of library subroutines is provided to aid the

application programmer in forming the many small tasks that
characterize a graphics job. Core space allocation, mass
storage residence, job priorities, and all other functions of
multi-job, random task processing are invisible to the
application programmer.

36
 9. Low priority batch jobs are able to co-exist with graphic jobs
with no appreciable effect on console response.

IV. NEXT GENERATION GRAPHIC TERMINAL CHARACTERISTICS

On the premise that the multi-programming operating systems

currently available are limited in the number of graphic terminals they
can service. I feel that the area for improving system capacity lies not
only in large and faster central processing units but also in an improved
design of the interactive graphic system. Some essential criteria for
the next generation graphics system are these:

a. The display terminal must support both a remote as well as a

local location. The display terminal must operate in an
identical fashion regardless of its location. The system must
be a harmonious mix of interactive graphic displays regardless
of distance from host computer.

b. The host or main computer must be of the "super" class. It is

responsible for the maintenance of large data files and performs
the number-crunching type functions.

c. The load on the host computer mU,st be reduced. Specifically,

this display terminal must support at least these kinds of
functions:

(1) display management

(2) the creation and deletion of display items
(3) the modification of display items
(4) the interactive processing of light pen and keyboard
interrupts
(5) the queuing and processing of alphanumeric text input
(6) light pen tracking
(7) the queuing and processing of display item data

Of additional consideration in the design of the display terminal is

the need for hardcopy output in the form of a film or printed paper. In
either case, outputs of this type are required within a reasonable time
after an initial request (less than five minutes). The final consideration
for the display terminal is that all of the above features have to be
implemented at a conSiderably cheaper price than they have been to date.

V. SUMMATION

To briefly review the growth, or lack of growth of interactive

37
graphics, it seems that in the early to mid 1960 time period the limiting
factors were:

1. Inefficient operating systems (particularly the need to use a

dedicated computer).

2. The high costs incurred by the user in the development and

implementation of an interactive graphics application. This
high cost of development was due in part to the fact that little
or no system interfaces were provided by the computer
manufacturers, and that in those instances where they were
provided, they were too restrictive and limiting in their
utility. This necessitated the user developing an operating
system and a graphical interface as a prelude to expending
effort in the application area.

3. The complexity of the problem itself, it truly was an R&D

effort.

However, one of the main themes of this paper is to emphasis that

in the latter part of the 60 I S great improvements in system interfaces
have been realized. Multi-programming and multi-console interactive
graphics is providing an environment to improve the cost ... to-performance
ratio. The still limiting factor in the growth and spread of interactive
graphics is the lack of cost effective applications. It is in this area that
the emphasis now needs to be stressed.

There are still consideqtble costs associated with the development of

graphical applications. A primary objective of the organization that I
represent is to provide graphic applications system support to our users
and to act as an organizing force in bringing together users with similar
interests to participate in joint graphic application development efforts.

REFERENCES:

1. Linscott, R. N., ed; The Notebooks of Leonardo da Vinci; New York

Random House, Inc., 1957; p. 279.

2. Kyle, R. L., Keydata Symposium, Interactive Graphics;

Boston, Massachusetts; May 13, 1969; pp. 15-20.

3. Myer, T. H., and Sutherland, I. E.; "On the Design of Display

Processors;" Comm. of A. C. M. : Vol. II, No.6, June 1968;
pp. 410-414.

38
4. Hart, D. E., Keydata Symposium, Interactive Graphics;
Boston, Massachusetts; May 13, 1969; pp. 112

BIBLIOGRAPHY:

1. Joyce, J. D. and Cianciolo, M. J.: lIImproving Man-Machine

Graphic Communication, II Proceedings of the Fall Joint Computer
Conference, Volume 31, 1967; pp. 713-721.

2. Licklider, J. C. R., riA Picture is Worth a Thousand Words and it

Costs, II Proceedings of the Spring Joint Computer Conference;
Volume 34, 1969; pp. 617-621.

39
SOME COMMENTS ON SUPPORTING MULTIPLE
INTERACTIVE GRAPHIC CONSOLES IN A
PRODUCTIVE ENVIRONMENT

P. Smith and B. T. Torson

Computer-Aided Design and Manufacture, Rolls Royce

Limited, Aero Engine Division, P.O. Box 31, Derby,
Englanq.

1, Current Hardware/Software Configuration

At. the time of writing the equipment in use at Rolls-Royce

relevant to this paper is an IBM System/360 Model 65 with 1 million
bytes of main core and 1 million bytes of slow core plus direct
access, magnetic tape facilities and normal input/output devices,
The terminals supported are 24 typewriter terminals used for
writing and executing fairly small programs, a remote job entry
device consisting of a card reader and line printer and 3 2250
Model Ill's, One of the 2250's is in the Design area 1400 cable
feet from the computer, the other two are in the computer building;
but work is in hand to move a second display into a user area
which will be over 600 cable feet from the computer, Associated
with each 2250 is a Polaroid camera for immediate hard copy,

The operating system used is a modified version of MVT

(multiprogramming with a variable number of tasks); the major
modifications are

to allow use of locally written accounting routines.

to guarantee core availability for 2250 programs during

appropriate hours.

to be able to load (and unload) reentrant routines which

are used by all graphics application programs, without
having to reload the operating system.

These latter two facilities were devised by an IBM Systems

Engineer to solve problems arising from support of multiple
graphic consoles under MVT, One of the imposed system requirements
was that a user had to be able to have loaded into the computer the
program which he wished to use, without communication with or

41
assistance from the computer operator. The Graphic Terminal
Services package (G.T.S.), which enables job scheduling as above
via the 2250, is used for both 2250 programs and also for scheduling
certain batch programs.

As far as the application programmer is concerned a far smaller

machine than described above is available to him. Each application
must be planned to work within lOOK of core and not to use card or
paper tape input/output devices or magnetic tapes. In addition
applications are chosen which will not require more than 10% of the
central processor unit time, this may affect the planning of the
program. The programmer must also bear in mind the fact that each
2250 program will be time-sliced with the other 2250 programs in use
at the same time. All application programming is carried out in
Fortran using the IBM Graphics Subroutine Package (G.S.P.), but
where necessary Fortran callable assembler language routines have
been written.

2. User Considerations

The majority of the users of our 2250's know very little about
computing, their most common contact with computing is via a 2250.
This must be remembered when considering the following paragraphs.

(i) Various areas of the division have staff associated with

the Project, in particular a Staff Design Engineer works
full time co-ordinating the support activities of other
designers and specialists. Close co-operation between
the user area and computer personnel takes place in the
devising and implementing of 2250 programs; in addition
associated non-computer procedures are also devised where
appropriate. The selection of problems to be tackled
is carried out on a divisional baSis by the Chief Design
Engineer and other senior managers.

(ii) A document has been prepared which describes the facilities

of a 2250, how to enter accounting information, how to
select required program and what action to take in various
abnormal situations. In addition the document contains
a glossary of those terms which a user may hear quoted
but with which he would not normally be familiar e.g. CPU,
disc file.

(iii) Each program adheres to certain standards such as the

layout of the top 1 inch of the screen; this contains date,
user identification, problem identification, program title~
Its purpose is so that photographs of the screen contain
relevant administrative information. Any program
termination causes a warning message to be displayed if
the user has not filed his data.

42
 At no point in the execution of the program is the user
left in doubt as to what is happening and what options
are available to him. Where appropriate, messages are
displayed which provide guidance as to the effect of
particular options. In addition if the user selects
the PRINT (PLOT) option the displayed word changes to
PRINTED (PLOTTED).

(iv) All programs are written in such a way that poor input
data cannot cause program termination, either an error
message indicating invalid input data is displayed or the
program must complete the calculation and display answers
from which the user will realise that something is wrong.

(v) As each program is completed a users guide is prepared by

the Staff Design Engineer. This will cover the input data
required, a description of the effect of each option, any
(engineering) technical advice relevant to use of the program
and details of parameters which should be permanently
recorded for a completed design.

3. Programmer Considerations

In addition to the implication of items (iii) and (iv) of

User Considerations the programmer is particularly concerned with the
integrity of user data and filing. It must be appreCiated that at a
single point in time 3 independent graphics users and two batch
programs may be accessing the same user file. Further that it must
be possible to implement new programs which access a file, possibly
requiring storage of additional information within the file.
Standard file handling routines have therefore been written which
effectively act as interfaces between an application program and the
file. These file handling routines meet all the requirements which
are listed above. In fact there are two sets of routines one for
use primarilywith arbitrary 2 and 3 dimensional geometry, the other
for use in application programs which only deal with specific
components.

In certain applications it is necessary to provide a RECOUP

facility. This uses a file into which, at regular intervals during
interactive work, a copy of the current problem status is recorded;
if a system failure occurs and the program has to be reloaded the
RECOUP file may be read and the loss of time by the user reduced
to an acceptable level.

Believing that programmers writing 2250 programs should take

advantage of the 2250's capabilities during testing a number of
standard routines are used, some having been implemented by R.R.,
to assist in this. These include:-
 Sysout Processor:- this allows the programmer to view
his output which would normally be
printed; he can select that which
he wants to be printed and
eliminate that which he does not.
This avoids the necessity of having
to wait for printed output.

Xyg Output Processor:- this allows the display of any

information defined in terms
of (X,Y,~) points and connecting
lines. Such data is generated as
input to structural analysis programs
and as output to devices such as a
plotting or drafting machine.
Powerful additional facilities
compared to passive devices, of
scaling, translation and rotation
are also possible.

In practice this routine is used

as a program in its own right to
rapidly check information before
it is passed to a drafting machine.

Overlayanalysers:- many application programs, in order

to operate within the allowed core,
are heavily overlayed. Several
utility programs which analyse
overlay structures have been found
useful.

Monitors: - there is a limit to the amount

of overlaying which is desirable.
For this and other reasons it has
been found necessary to continue
to use monitors. A monitor is
defined as a means of allowing
sequential execution of independent
program modules within a fixed
region of core without core
fragmentat ion.

General Input/Output These vary from simple routines

Routines:- which facilitate the entering of
a single numerical value by either
light pen and digit panel or
keyboard to one which allows user
controlled display of 2 variable
data with many interrogation
facilities.

44
 The programmers also plan implementations with testing on the
2250 in mind. In addition to the obvious modularity of program
this implies such things as displaying diagnostics on the screen,
providing a data dump option at all program waits and in extreme
cases including a routine which allows scanning and modification
of core at selected points are used.

4. Evaluating Economics

A major factor in deciding the economics of interactive graphics

equipment is the accounting philosophy adopted. In most computer
installations the charge made for computer usage includes a percentage
to pay for supporting staff and other overheads. If the same
percentage as for batch programs is applied to graphics programs it
raises the console/hour charge to an inhibitive level. The graphics
user makes no demands on the progress and scheduling staff, the
punch and verifier staff, schedules his own jobs without computer
operator intervention and generally causes less output per job to be
produced than the batch user. When these things are considered the
case for applying a lower overhead factor seems quite clear.
Variation between installations in their accounting philosophy and
eqUipment utilisation preclude any definitive statements on the
economics of a particular application across installations.

Based on numerous examples the following statements regarding

interactive computer graphics are true:-

(i) the same results can be achieved as from conventional

batch processing methods in a fraction of the lapsed time
(e.g. two weeks reduced to two hours);

(ii) alternatively, much deeper analysis can be carried out in

the time available, and hence better designs are possible;

(iii) the computer costs of obtaining identical results by the

use of interactive computer graphics are often no greater
than by conventional methods and in some cases can be
considerably less;

(iv) problems can be solved which are incapable of solution by

any other method in a reasonable time.

When considering the economics of using graphics eqUipment

it must be possible to place a value on the relevant factor(s)
from the follOWing list:-

(i) the saving of lapsed time;

(ii) the saving of engineer time - it should be remembered

that it is basically easier to increase computer capacity
than to recruit skilled engineers;

45
4. Evaluating Economics (Continued)

(iii) the design of a product or component with improved

perf or manc e ;

(iv) the successful completion of a task which would have been

impossible otherwise.

Using these facts plus implementation and running costs it is

possible to draw up a balance sheet showing the economic consequences
of a proposed programme of work. In practice it seems easier to
reach a decision with respect to design analysis type program dealing
with a specific part or component. The situation is much more
confused when a general program such as for drafting is considered.
In this case the program can be used to assist the drafting of
almost any kind of part. However, only where

(i) complex geometric calculations;

(ii) a group of similar parts;

(iii) a large proportion of the geometry is available from other

programs, or

(iv) the geometry once defined will be used in other programs

also,

are the economics currently favourable.

Study of the economics of our current situation shows that in

addition to straightforward ways such as increased equipment
utilisation there are technical areas where improvements are possible.
One is improved core utilisation; another in the drafting
application is to provide improved c'apability to deal with
topologically similar shapes. Work is proceeding on these and
other possible improvements.

5. Applications in Use or Under Development

Previous lectures, references 1 and 2, have described graphics

programs, in use at Rolls-Royce, which are of the design analysis
type. Articles, reference 3 and 4, describe a system, available
at Rolls-Royce, which can be used to assist a draftsman in the
preparation of drawings. The lecture, reference 5, describes an
extension to the design/drafting system which provides a user
controlled means of generating a mesh over a two dimensional
shape.

The initial work on turbine blade design concentrated on the

assisting in the design of aerofoils. This work is being extended

46
to include recently developed methods of analysis; in addition
work is being carried out to assist in the design of the blade overall.

In reference 1 a program of use in designing discs was described.

This program performs a significant amount of computation to assist
in the optimisation of the disc profile. Further study has shown
that having obtained a preliminary profile it is better to allow
the designer to modify the profile and the program to calculate the
stresses. This uses less computer time than further optimisation
runs and is more natural for the designer. The new program, which
allows profile modification, is now in use. It accepts as input
a profile from the optimisation program and optionally provides
output which can be used as input in the mesh generation program,
reference 5. It will be possible to access the geometry in an
Numerical Control program for turning machines.

The deSign/drafting program has been extended to include a

spline entity and to allow the checking of interference between
two parts or between a tool, and holder, and the part to be machined.

A program is in use which allows the display and modification

of data which is a function of two variables. This is used for
error checking and elimination in data entered into the computer
such as component performance data. Another program allows the
display and checking of three dimensional structure.s. In both
cases elapsed time and man time is saved in achieving the desired
situation of having the correct data in the computer compared with
e.g. plotted output. The latter progrrun has a facility which
varies the intensity of the lines on the screen. This is used to
make intensity vary with depth into the structure.

References

1. Mechanical Design Using Graphics - B. T. Torson. In Computer

Graphics Techniques and Applications Ed. R. D. Parslow,
R. W. Prowse and R. Elliot Green. Plenum, London. 1969.pp 161-167.

2. Interactive Computer Graphics at Rolls-Royce - B. T. Torson.

In Pertinent Concepts in Computer Graphics - Proceeding of
Symposium held at Illinois University March/April 1969.

3. DeSign/Drafting via Computer Graphics (1) - J. J. Lavick and

B. K. Winters. In International Science and Technology 1970.

4. DeSign/Drafting via Computer Graphics (2) - W. R. Jones and

B. T. Torson. In International Science and Technology 1970.

5. DeSigning Disc Profiles for a Gas Turbine using an Interactive

Display Device - M. A. Bayfield and R. D. McKenzie. The
International Symposium on Structural Optimisation, October 1969
Istanbul.

47
 DIGITAL TELEVISION
A LOW COST APPROACH TO MULTI TERMINAL
GRAPHICS

Sol Sherr

Manager Display Planning, Advanced Planning Depart-

ment, Hazeltine Corporation, Little Neck, N. Y. 11362,
U.S.A.

Abstract

The basic technique of digital television as applied to

graphics is discussed, and its advantages and disadvantages are
presented. Future improvements and areas of cost reduction are
indicated. Several operating systems are described in some de-
tail and others in the implementation stage noted as representing
present and future applications.

INTRODUCTION

One of the problems that has continued to harass the

designer and user of graphics is the high cost of a system, in-
particular when more than one or two terminals have been re-
quired to make the system effective. While some single termi-
nal low cost systems have been offered, which might make a
multi-terminal system economically practical, their limited
capability has tended to restrict their applications and they
have not broadened the market to anywhere near the extent that
their price had indicated. I am referring here specifically to
those terminals using a storage tube (1) that may be purchased
for between $12K and $15K on a one terminal basis. However, the
characteristics of the storage .CRT, while lending itself to cost
reduction introduce the concomitant deficiencies in brightness,
contrast, resolution and update time that have limited its ac-
ceptance. The need, therefore, is for a system which offers the
performance found in standard CRTls and yet begins to approach
this low cost at least on a multiterminal basis.

Digital television provides such a system and it has been

used for several applications (2, 3, 4) with excellent results
and every indication that these systems can be used for a wide
range of applications at a per terminal cost approaching that of

49
the low cost single terminal system; and with performance equiv-
alent to or better than that attained with other approaches usir
either random inputs to the CRT or analog television derived
from a vidicon camera or an analog scan converter.
The advantages of television techniques in general (which
will be discussed in detail a little later) as a means for
achieving low cos~ displays in a multi-console system have been
described in several other papers, (2, 5, 6) and examples of
such systems are the display/control system for the manned
space center (6) and the University of New South Wales Graphi-
cal Data System (5, 7). However, the first uses a vidicon
camera to convert fO television format from the image produc€d
on a Charactron R (8), and the second uses an analog scan
converter to provide video signals which are stored on a video
disc. In both cases, the conversion process used leads to
degradation of the image due to the Kell factor (described late)
and image smearing due to the retentivity of the vidicon and
scan converter. Thus while operational experience with these
systems has been excellent, and has substantiated the claims as
to the advantages of TV systems, digital TV retains these advan-
tages while removing the specific disadvantages just adduced.
As an example of digital TV replacing analog TV techniques,
the present Manned Space Flight Center system was certainly
good enough to help land men on the moon, but it is in the
process of being partially replaced by a digital TV system as
the result of experience with a small evaluation system.
While it is true that there are some small deficiencies
associated with digital television (as will be covered more
fully later), these have not proved to be detrimental and are
far outweighed by the performance improvements and low terminal
cost attainable with this technique. The deficiencies are
primarily in the esthetics of the characters and images re-
sulting from digital techniques, (although even these may be
overcome by appropriate design) and usually do not detract
from the legibility, usefulness and total quality of the dis-
played information. These factors will become more apparent
after I describe the basic technique and illustrate it by means
of specific applications.
TECHNICAL DISCUSSION

Digital television is something of a misnomer in that

there must be a conversion from the digital signals to analog
form before they are applied to the CRT. However, all pro-
cessing, storage, conversion to TV format, and display gen-
eration are done with digital signals and to that rather con-
siderable extent digital television is an apt description of
this form of presentation. The system may be illustrated by

50
means of the block diagram shown in Figure 1. The unique parts
of this diagram are the blocks termed Data Processing Unit and
Picture Assembly Unit which accept digital inputs in any com-
patible computer language and convert them into a video pic-
ture in the picture assembly memory with a memory location
corresponding to each element of the visual image. Several
designs have been described (3, 9, 10) for performing this con-
version, but in general, the process may be understood by ex-
amining the expanded form of the Digital Television Display
System given in Figure 2. For example, if the input contains
a 26 bit code with 6 bits defining an alphanumeric at a par-
ticular location, the character generator logic converts it
into a dot matrix character by causing the appropriate lines of
the program logic to be in the "ONE" state. The program and
address logic similarly selects the designated memory locations
to be driven by the character generator logic and the output
lines are routed to the correct location by means of the address
logic operating on the position bits in the computer word.
r--------------,
FROt.l ENCODED

DIGITAL {
COMPUTER
T DATA
PROCESSING
CHARACTERS
lINES,SYt.lBOlS PICTURE
ASSEt.lBLY
PICTURE DATA PICTURE
REFRESH J.-I VIDEO/SYNC

-t-I
SIGNALS
DATA TO UNIT UNIT UNIT TO DISPLAY
COt.lPUTER
I
I I
I I
I DISPLAY
ENTRY
I
I CONTROLS
I
L ______________ ,-1
Figure 1 - Digital Television System Block Diagram·

Once the starting point is selected, the write lines are con-
nected to the correct memory locations and energize them as
directed. The operation is performed on each computer word in
sequence until the entire frame is stored in the picture
assembly memory at which time the computer may be disconnected
and move on to other tasks until another frame is ready for
generation or some change is to be made in this frame. At this
point a complete equivalent of the visual information is con-
tained in the picture assembly memory, with each memory element
in the state corresponding to its associated element in the
visual image. The information is then transferred from the

51
video assembly memory to the appropriate tracks on the re-
fresh memory, and the system is now prepared to process the
data for another display. This procedure is followed until
processing for all display consoles is complete and all are
being driven from the refresh memory.

DATA PICTURE PICTURE

PROCESSING ASSEMBLY REFRESH
r--- - --, r----,
UNIT UNIT
r------~
UNIT

I CHARACTER
II II II I
I
CIRCLE,GRID CORE
II MAGNETIC TV
I
INT/EXT

II
& VECTOR MEMORY DRUM SYNC SYNC
I GENERATORS ,,
FROM I II II :
DIGITAL {
COMPUTER I INPUT
BUFFER
PROGRAM
LOGIC &
II WRITE,
READ,&
II DECODE TO SERIAL
COMPOSITE,
} NON-COMPO
DATA
TO
I MEMORY COORDINATE, I ADDRESS II LOGIC VIDEO VIDEO & SYI
TO MULTIPLI
L ______ :..1 L __ ~ L ______ :.J
CONVERSION LOGIC CONVERSION
COMPUTER DISPLAYS

CURSOR DATA

r.- -.-----,
A/N &FUNCTION DATA I· KEYBOARD
~----4-'-;';"';;":;';"":';';':"':"';":''''-=-''''-----.:.t 'MESSAGE
DATA ENTRY
CONTROLS
.,'
ORGANIZER (AT EACH I
L
' ______ DISPLAY)
-~

Figure 2 - Expanded Block Diagram Digital Television System

It is possible to perform this conversion operation re-

petitively on each frame (as is done in several types of
alphanumeric displays using digital TV) and thus remove the
requirement for a picture assembly memory, but this is dif-
ficult to accomplish. when vector generation is required. A
vector is generated by having the vector generator examine
the end points as specified by the computer and convert them
into the series of points that are the best fit to a straight
line (11), which are then stored in the video memory for trans-
fer to the refresh memory. Since well over 100 ~ s may be
necessary to complete the vector it is apparent that only a
limited number of vectors could be handled in one frame time.
This will be returned to when we consider some future develop-
ments.
ADVANTAGES
We now come to some of the advantages of this technique
for multiconsole applications. One significant advantage is
52
that each console can display its full complement of data at
the selected refresh rate without affecting any of the other
consoles. This is because the central refresh memory drives
each console independently and an increase in data does not
cause any interactions. While a common memory could be used
for non-TV systems, these are subject to data limitations, and
in general if the amount of data increases beyond some limit
either the refresh frequency is reduced, or the data must be
transferred to another console. This leads to the next im-
portant advantage of digital television displays; the ex-
tremely large amounts of data that can be displayed at uniform
brightness, due to the raster format and preorganization of
data, which results in constant writing speed and the ability
to energize the beam equally at every point in the raster.
Other significant advantages are the ability to accommodate
large numbers of slave displays and to add additional active
consoles at minimum cost by providing an expansion capability
in the refresh memory.
It should also be noted, as has been previously stated,
that while similar advantages can be achieved with an analog
scan converter or video disc the digital technique overcomes
several deficiencies in the analog approach such as reduced
resolution due to the Kell factor, (12) smearing of moving
data as a result of scan converter storage, and difficulty in
achieving selective updating. The Kell factor results from
the possibility that some data points may not be covered by a
scanning line, and it has been empirically established as
causing a resolution decrease to 0.7 of that before scan con-
version. The digital approach eliminates this factor entirely
since every data pOint is exactly associated with a display
point. This feature also leads to exact registration between
computer generated backgrounds and the alphanumerics or other
symbology. Smear is eliminated by using a randomly accessible
core memory for frame assembly. As a result the digital ap-
proach has all of the advantages accruing to raster scan,
while avoiding the limitations associated with analog scan con-
verters.
Other useful features of the digital TV techniques are
the ability to mix inputs from other TV sources (TV cameras,
scan converters) and the ability to use simple TV monitors as
the display units. The TV mixing is an important feature of
several systems described later in this paper, and the use of
standard TV monitors has permitted low cost display stations
to be an integral part of this system. This has significant
impact on the total system, resulting in reduced cost, power
and weight, and improved reliability and maintainability.
Color is incorporated into the system by using 3 channels,
one for each primary color, and driving a standard color monitor.

53
Large screen displays of the TV projector or Light Valve variety
can be included readily, since they can be treated as simple
additional monitor stations. Various data entry devices are
also included in several of the systems to be described such
as light pens, keyboards, and track balls.
Finally, the technique is inherently compatible with the
matrix displays presently under development, whether they use
light emitting diodes (LED) plasma panels or liquid. crystals.
Thus there appears to be no reason why these cannot be incor-
porated as they become available.
DISADVANTAGES
Since nature abhors an optimum solution, if I may be
permitted to paraphrase a common bit of conventional wisdom,
the advantages just described must have at least a few asso-
ciated disadvantages. Prominent among these is the need for
relatively large memory capacity. Given the need for a million
data points or 1000 x 1000 TV lines of resolution, the memory
capacit~ needed is 10 6 bits per channel in the refresh memory
plus 10 bits in the frame or video assembly unit. The situ-
ation would be even worse if a separate video assembly memory
were used for each channel system. In that case, which is the
equivalent of a single channel system, the memory costs could
be much too high. As a result, the digital TV approach is
generally not economical for single channel systems, although
even all core systems have been found preferable to non-TV
systems due to certain other special requirements such as
mixing TV inputs and providing remotely located slaves. How-
ever, it should be noted that memory costs are dropping rapid-
ly, and the time is probably not too distant when large scale
random access memories will be low enough in cost ( 5 cents/bit)
to be used extensively in this type of system, (13) while
large capacity rotating memories are anticipated at less than
0.01 C/bit (14). At present the approach is to minimize random
access cost by using a common assembly memory and a low cost
drum or disc memory for multiple channel refresh. The cross-
over point appears to lie between 2 and 5 channels, and has
come down from the 8 to 10 channels of a few years ago.
Another potential limitation is in the resolution that can
be attained practically. While theoretically any resolution up
to the spot size of the CRT is possible, in practice the rapid
growth in memory size (as the square of the resolution increase]
and in video bandwidth makes anything beyond 1000 x 1000 lines
rather impractical. Thus line widths of about 16 mils on a 16"
diameter viewing area, or a minimum character height of about
0.1" are the best attainable at present. This has not been a
significant limitation in most applications to date, (since
smaller characters are generally not desireable for human engi-

54
neering reasons) and it may be anticipated that advances in the
technology will allow 2000 line systems to be built before too
long if required. Remember that a 0.111 character on a 1211 x 1211
viewing surface allows maximum character density of over 10,000
characters, and the human is probably not capable of using more
than 4000 at anyone time. Figure 3 is an example of a 4000
character display and it is apparent that much greater data
density would be self-defeating from the human factors (English
translation - ergonomics) point of view.

Figure 3 - 4000 Character Display

Another possible drawback, perhaps more esthetic than

operational, is in the appearance of the characters, particu-
larly when a 5 x 7 matrix is used. However, if the characters
are made up of a larger matrix of dots (7 x 9) scanned by the
television l.ines, the shape tends to be as shown in Figure 4,
which is an enlarged view. The actual appearance is as shown
in Figure 5~ with the dots merging. Tests have demonstrated

55
that legibility is not affected, if this larger matrix (7 x 9
or 9 x 11) is used (15, 16) but the appearance is still some-
what different from that found in high quality cursively

ABCDEF
GHIJKL
MNOPQR
STUVWX
YZ1234
56789-
?&/+ 1 •
Figure 4 - Dot Matrix Characters

written or extruded characters, shown for comparison in Figure

5b. However, the high quality requires rather complex character
generation equipment, and if anything approaching comparable
complexity is use' the character shape is more like that shown
in Figure 5c. In addition, a number of the deficiencies asso-
ciated with cursively written characters, are eliminated such
as:
a) non-uniform brightness due to overlapping points and
variable speed writing;
b) non-uniform character space and tilt
c) repositioning errors when displayed picture changes,
and
d) flicker at high data density
As a result, the overall picture quality of digital television

56
is at least as good as that attained from cursive writing tech-
ques in any practical sense. Thus the deficiencies of the TV
character are more apparent than real, and once the user has
climbed over the esthetic barrier, recognition of over 95% will
be achieved. Thus while it may not satisfy esthetes it is more
than adequate for~operational needs.

ABCDEFGHIJKLMNOPQRSTUVWXYZ1234?&/+,.
a

xy Z [ ] b. 181
P Q RS T U VW
H I J K L MN e RK[]EF5HI JKLMNDP
@AB C DE F G QR5TUVWXYZI~3Y~6

8 9 •• # < -- > ?. 7SglZ) . 1 17-+= [J <>9:1

0 123 4 5 67 c

b
Figure 5 - Comparison of DTV and Cursive Characters

As a final point, the difficulty in using some of the new

color CRT's should be noted. As previously stated the system
is compatible with standard TV color CRT monitors and no problem
is encountered here. However since these are somewhat resolution
limited it may be necessary to go to a beam penetration type of
device (17). This is a single beam multi-layered phosphor CRT
which operates by changing the acceleration potential to cause
the beam to energize the selected phsophor. Higher resolution
is achieved by eliminating the mask or grid structure found in
the shadow mask or chromatron color CRT's. However, rather

57
high voltages (2-4KV) must be switched at high speed (30ns) in
the television format, so that it may be necessary to organize
the data on a color basis and use a sequential rather than
parallel technique. Alternates are possible such as higher
resolution shadow masks, the current sensitive color CRT (18),
or even the discarded color wheel, and if the need arises they
will probably become available so that this restriction does
not appear significant.
DESCRIPTION OF OPERATING SYSTEMS
A number of systems have been installed which use the
digital TV technique and have had a considerable amount of
operating experience. Table 1 lists a set of nominal para-
meters for one of these systems, and I have selected 5 as rep-
resentative of differing levels of complexity and performance
capability. These do not include all aspects of possible mech-
anization, but are sufficient to illustrate the use of digital
TV in actual applications and provide adequate performance
history to determine reliability, maintainability and ease of
use. o.ther configurations are feasible and can be adapted to
user requirements.
FEDERAL AVIATION AGENCY - AIR TRAFFIC CONTROL (3)
Several years ago the Federal Aviation Agency had a need
for a system which could add alpha numeric blocks, lines and
vectors to the radar data being presented on the CRT, and re-
place the small plastic chips used to manually track the radar
targets. The radar was scan converted by means of an analog
scan converter to a 945 line television format, and the sym-
bology needed to be in the same format and capable of being
mixed with the scan converted radar. The technique developed
by Hazeltine Corporation for accomplishing this was essentially
the one briefly outlined in the technical discussion, and sub-
sequent systems evolved into that shown in Figure 6, where the
block labelled ANG-3 (Alpha Numeric Generator 3) may be ex-
panded into Figure 2. This system is presently operative at
the common IFR room at J.F.K. International Airport, New York,
New York, U.S.A. and the Air Traffic Control Centers at
Atlanta, Georgia; Jacksonville, Florida; and Atlantic City,
New Jersey. The ANG-3 accepts inputs from the computer and
converts them into the symbols, alpha-numerics, lines and vector,
in the TV format, which are then mixed with the scan converted
radar and presented on both the CRT's and large screens. This
is a fully interactive system ".~ith as many as 12 channels driven
independently f~om a single ANG-3 and input functions accom-
plished by an AN Keyboard, trackball and function module, one
set for each operator or controller. Update rates for all dis-
plays are between 0.6 and 2.4 seconds depending on the amount

58
of data and the number of displays being updated. Figure 7 is
a photograph of the appearance of the display on both the CRT
and the large screen, which latter uses an Eidophor light valve

---:1
ATC
RADAR & I SCAN
CONVERTERS
TV
VIDEO r---
DISPLAYS
(CRT 1
BEACON I MIXER LARGE -SCREEN)

- - ::J
~----,
I ---, I
RADAR & TRACKING
r---r - ---I
I
ATC
RADAR &
I BEACON
r---. 1 DISPLAY
IANG-3 I
VIDEO
I I
BEACON DIGITIZERS
PROCESSING
COMPUTERS ~ ___ .J

L.:_ _:J
Figure 6 - Air Traffic Control System

projector. Operational experience has been excellent, and re-

liability is so high that it is being used on a 24 hour day, 7
day week basis. These installation are prime examples of the
advantages of digital TV where TV data from another source must
be mixed and when multiple consoles are a necessity.
BROOKHAVEN NATIONAL LABORATORY - SCIENTIFIC RESEARCH
Another example which illustrates the flexibility of the
digital TV approach is the display system delivered by Hazeltine
to Brookhaven National Laboratory, Upton, New York, U.S.A. for
use in research into atomic nuclei. In this case, a computer
HAZELTINE DIGITAL-VIDEO DISPLAY SYSTEM DDG.-3

"Type:

Digital TV Raster Scan - Alphanumeric and graphic with twenty (20)

independent display channels.

a) Information retrieval or inquiry

b) Text editing
c) Comp~ter aided design
d) Map drawing with random line and connecting line capability
e) Real time moving vehicle display
f) X, Y plotting

59
Character Parameters:
a) Character Generator - Dot Matrix size is proqrarmnable, any
size up to 16 x 16
b) Character Repertoire - 128
c) Character Size - 1/8 11 high with desirable 3 x 4 aspect ratio
on 8 11 to 1411 TV Monitor (other sizes as
proqrarmned)
d) Maximum characters per line - 146 non-overlapping, over 1000
overlapping characters
.) Maximum lines of characters per display - 68 non-overlapping
seven line high characters
ptsplay Parameters:
I

a) Screen Size/Resolution - any standard 525 line TV Monitor/

1024 dots each of 480 lines)
b) Refresh Rate - 60 fields with 2:1 interlacing, p~r second
c) Input device -
1. Keyboard
2. Light Pen
d) Interface equipment required -
1 •. To computer - IBM Data Adapter unit
e) Interface data rate -
1. 625,000 bytes per second
2.625,000 characters per second
f) Maximum distance to control unit 1000' or up to 5000' optiona:
g) Memory -
1. 16K (16 bit) Video Core
2. 12K (16 bit) Buffer Core
3. 10 Megabit Drum Refresh
Physical Parameters:
a) Size (desk unit) - l411w x l2"h x 19"d
b) Weight (desk unit) - 66 pounds
c) Power Required - 1.6 amperes at 115/1/60
d) Drum Size - 30" x 30" X 30"
e) Cabinet Size - 72"h x 80"w x 34"d
f) Cabinet Power - 2 KW at 120/3/60

Table 1 - Representative Parameters of DTV System

60
was available to do the conversion to digital TV format, and the
display system was limited to a Picture Refresh Unit, interfacing

Figure 7 - Display of Air Traffic Control Data

directly with the central computer as shown in Figure 8. In

this case a drum memory with 32 independent channel capacity was
provided although only two were initially furnished. This is an
excellent example of the expansion capability inherent in this
approach which is presently being implemented. The display pre-
sents scatter diagrams of up to 32000 random points without
flicker and at high brightness.

NASA-HUNTSVILLE-LAUNCH and SPACE FLIGHT MONITOR (4)

Another system has been installed by Monitor Systems at

the NASA Huntsville facility for displaying and monitoring pre-
launch, launch and in-flight conditions during the Apollo mission.

The system converts digital signals into digital TV format

for display of alphanumeric and graphical data on standard TV

61
monitors and on Eidophor projectors. The system obtains data
from the Kennedy Space Center and supplies outputs for ten in-
dependent displays. Figure 9 is a block diagram of this system,

PICTURE
REfRESH
UNIT
r------~
I I
I
MAGNETIC TV
SYNC
DRUM SYNC

I
I
DIGITAL INPUT I
OUTPUT
I
....---1. .
ENCODE,
COMPOSITE
} VIDEO l SYNC
DATA TO MULTIPLE
INTERFACE DISPLAYS

r.- ------,
DISPLAY
ENTRY I TRACKBALL TRACKBAL L I
CONTROLS I LOGIC (PER DISPLAY> I
L ______ ~

Figure 8 - Scientific Research System

and it is apparent that it contains all the elements of the

basic system shown in Figure 2. The magnetic core character
generator memory illustrates one means whereby the character ger
erator may have its font programmable as to size and shape.
This technique has been used in some of the other systems where
a fixed font using microcircuit logic was not satisfactory.
Display processing time is approximately 0.1 second for com-
plete updating of a typical display or something over one sec-
ond for the full set of 10 displays.
NASA - Satellite Test Center (2)
A very large system has been installed by Philco Ford at
the Satellite Test Center. This system is capable of driving

62
up to 64 consoles and 64 group displays. This system is shown
in block diagram form in Figure 10. It includes a number of in-
put devices, with digital maps and background storage which
INSTRUCTIONS
'110" COMPUTER
(DlllfCT CONNECTIONI

I'''UT
INSTIIUCTIONS DATA-sn INTE~fACE fOR

"
IN'UTS VIA COMMUNICATIONS LIN"

INPUTS fRO .. ~OCA~

INSTRUCTION DISP~A' [DITOR5
CONTRO~
I
L _} TO/FROM
Tv
SYNC PERIPHER&l5
I I I I II
r---------~

" *

MCl9"·hc-di,C
SYSTEM OUTPUT
REFRESH
CONTRO~ BuFFERS
"["OR'[S

CHAHNE l UPOA T E
TO
VIDEO RECORDER

" OPTlONA~

CO .. POSITE VIDEO
TO MONITORS
(VIA SWITCH M'TAllI:, MIXERS
a TRA .. SMIS$ION liNKS
AS R[I/UIR[DI

Figure 9 - NASA Launch and Space Flight Monitoring System

illustrate the excellent registration attainable as has been

noted previously. The basic system is of the same type as the
others, using a core video assembly memory to create the frame,
and a magnetic disc memory for refreshing the various displays.

NASA - Unmanned Space Flight Monitoring

A very recent example of a fully microcircuited system

containing a large number of features is the one delivered by
Hazeltine to the Unmanned Space Flight Center. This system is
part of the NASAls Satellite Tracking and Data Network (STADAN)
and is incorporated in the larger network as shown in Figure 11.
The DDG-3 has the complete capability pictured in Figure 2, in-
cludes a keyboard and light pen at two stations, operator con-
trols for 19 stations and is capable of driving 20 display
channels. The DDG-3 permits the display operator to call up,
via the light pen, information on any satellite experiment
stored in the data bank and permits editing of the data with the
keyboard prior to returning them to the data bank. Real time
display of vehicle data is also possible using the random
graphic and connecting line capability of the DDG-3. The system
can display alphanumerics and special symbols in typewriter or

63
single symbol format, draw line segments between any pair of
points as specified by computer, display connected line segmentE
connecting all points specified in a computer generated list ane
has two completely interactive channels for editing and data
Manual Inputs
Hard Copy Requests ~
r--j---, r------,
Cursor. r- Dig;t;l--' r - [)i;;ital - 1 r - - ~- -l r - - - - - -,
~ Keyboard , I I I
Op'~'
: Keyboards , Map and , , Map and , , Hard Copy
r - - - - - - JI I
I
and I
Track Ball ,
, Background
, Storage
,
I
I Background'
, Storage ,
I
,
Selection
LogiC and
~
, I
Console
Hard
I
, }
I Track Balls ~ Control I I Computer , I Picture , , Bc~;e I , Copiers ,
L ---f-- J L J L El"ments J L J L
L
-r---
Logic.J Language
1---r 1- -"1- - -1- -
er J
- -§- -C:lsole Display No. I
Manual Inputs
f Console Display No.2
Console Display No.3
BASIC SYSTEM I r---
Console
Console
Display
Display
No.4
No.5
Picture ~ Console Display No.6
Digital , Element Picture
From Computer :---.
Interface Element r----o Console Display No.7
Symbol and Assembly
Other +- Logic Vector and Symbol and Recall
Digital Source ---. Generator Library -Core Data ~ Console Display No.6
Recirculators

1
Memory

J,;r---------'i
~ Group Display No. I
I 1 ~ Group Display No.2

Lr-
~ ~ Group Display No.3

_1_ --, J- 1
Manual
Inputs
r--l--,
,
.1
I
I
Background I
Digitizer I
r-
II Input
Data
Recall
I
I
1
r- - -
,
I
I
Video'
Color 1
I
I
Video
Switch
I
1
I 1
1 ---=- Gr~~ Display No. 64
Options
, Core I I Encoders J ., Matrix I
L ____ ..JI
1 I Memory I
L--f--~ L _____ J
I ,
L _____ J
_ Inputs from TV Cameras

Figure 10 - NASA - Satellite Test Center System

call-up. It has a large repertoire of 128 large and 128 small

characters, and the character size is programmable in any matri:
size up to 16 by 16, changed by manual or computer entry. This
system well illustrates the flexibility and versatility of
digital television techniques in graphics applications and is
representative of the performance that can be attained.

OTHER SYSTEMS

In addition to the systems described, mention should be

made of the one at NASA-Cape Kennedy and several due to be
delivered by Hazeltine to NASA-Houston and Boeing, as well as
other smaller systems provided by Hazel tine, 'MQni tor and
Philco Ford for various uses. These systems are basically
similar to those described previously and are referred to only
to show the extent of digital television usage. O~her ap~li­
cations such as utilities and process control are In the lm~
plementation stages of which the one being developed by
Philco.~Ford is representative (19). The growth is rapid and

64
Teletype Data
Prom D!'.TA
IIOn:l,torinq ~
.~
SET
And Traclt1n
Stations
Composite
~ Computer
, Digital
" Display
, Generator j
Video
Iwitchinq
& Distri-
~
Video & Synch
--" To 20 In-
-) DDG-3 ~ bution \., dependent
I Network
Displays
IlI'.TA
fWlK ~

Figure 11 - NASA - Satellite Tracking and Data Network

the systems are already too numerous to be covered adequately in

a single paper.

CONCLUSION

A number of graphics display systems have been built using

digital television techniques. While the major applications to
date have been to command/control, there is no inherent reason
why these techniques cannot be applied to many other areas, in-
particular those where several independent console stations
allow taking full advantage of the reduced cost and improved
reliability to be attained with digital TV. Further cost re-
ductions are anticipated and we may expect these applications
to expand. New display devices may be used without altering the
basic system approach so that improved display devices may be
readily incorporated as they become available. All these fea-
tures make digital TV a most attractive technique for graphics
display both now and in the foreseeable future.

REFERENCES

(1) R. H. Stotz and T. B. Cheek, IIA Low Cost Graphic Display

for a Computer Time-Sharing Console Proceedings, 8th ll ,

National Symposium, Society for Information Display,

San Francisco, California, May 1967, pp 91-100

(2) H. C. Hendrickson, IIA High Precision Display System for

Command and Control II , Information Display, Vol 4, No.4
July/August, 1967 pp 32-36

(3) G. E. Fenimore, IIGeneration of Alpha Numeric Flight Data

on Bright Displays, II Proceedings, Third National Symposium,
Society for Information Display, San Diego,California
February 1964, pp 192-204

65
(4) Monitor Systems - Monitor 8500 Digital Display Generator
Data Sheet. News Release, December 5, 1968.
(5) Malcolm Macauley, IIA Low Cost Graphic 'rerminal, II AFIPS
Conference Proceedings, Vol 33, Part I, December 1968,
Thompson Book Company, Washington, D.C. pp 777-785
(6) H. C. Hendrickson, liThe Display Control Complex of the
Manned Space Mission Control Center, II Information Display,
Vol 4, No 3, May/June 1967, pp 52-58.
(7) G. A. Rose IIComputer Graphics Corrununication System ll IFI.r)
Congress 68, Vol 1, August, 1968, pp 211-220
(8) R. E. Thoman, IIA Computer Generated Display System,1I
Proceedings, Third National Symposium, Society for Infor-
mation Display, San Diego, California, February, 1964 pp
146-167
(9) W. J. Dunn, E. F. Linsky and R. A. Battaglia, IIAlpha-
numeric Generator Operation ll Proceedings, Sixth National
Symposium, Society for Information Display, September 1965,
New York City pp 155-166
(10) V. E. Hupp and H. F. Horseman, IIDigi tal Television Message
Generator, II Proceedings, Fourth Na.tional Symposium, Societ~
for Information Display, Washington, D.C., October, 1964,
pp 353-370
(11) R. A. Metzger, IIComputer Generated Raster Segments in a
Raster Display, II AFIPS Conference Proceedings, Vol 34, 1965
pp 161-172
(12) H. R. Luxenberg and R. Kuehn, Eds., IIDisplay System Engi-
neering, II McGraw Hill Book Company, New York, 1968, pp 157-
158
(13) L. C. Hobbs, !'Present and Future State of the Art in Com-
puter Memories,1I IEEE Transactions on Electronic Computers,
Vol EC-15, No 4, August, 1966 P 545
(14) B. Segallis, IISpecial Report on Memories,1I Electronic Pro-
ducts, January, 1968, p 28
(15) D. A. Shurtleff, IIStudies in Television Legibility - A
Review of the Literature, II Information Display, Vol 4, No ]
January/February 1967, pp 43-48
(16) G. C. Kinney, M. Marsotta and D. J. Showman, IIStudies in
Display Feasibility XII. The Legibility of Alphanumeric
66
 Symbols for Digitalized Television, II Mitre Technical Re-
port, MTR-206, April 1966
(17) S. Sherr, IIFundamentals of Display System Design, II John
Wiley and Sons, New York, 1970, pp 82-84
(18) T. E. Sisneros, P. A. Faeth, J. A. Davis and E. H. Hilborn,
IIA Current Sensitive, Single-Gun Color CRT, II Presented at
1968 National Technical Conference of SID, November, 1968.
(19) G. W. Oprea, Jr. IIControl Center Computerizes Energy Dis-
play Operation Electrical World, August 26, 1968 pp 73-
ll ,

76

67
 PART 2

Computer Aided Design

AN INTERACTIVE GRAPHICAL SYSTEM USING
COMPUTERS LINKED BY VOICE GRADE LINE

W. S. Elliott, A. P. Jenkins and C. B. Jones

Imperial College, Centre for Computing and Automation,

Royal School of Mines Building, Prince Consort Road,
London, S.W.7, England.

1. INTRODUCTION
Ninke (Ref.1) has reviewed the different approaches which
have been taken to the design of computer configurations
having gr~phical input-output. Since the advent of single
display consoles attached to a large computer (DAC-1 and
Sketchpad) development has aimed at allowing more consoles
to be attached to a large central computer, minimising the
hardware and operating costs of each console and allowing
the location of consoles to be remote from the computer. In
GRAPHIC-1 (Ref.2) a small general-purpose computer was
interposed betvveen the central computer and. the display
console; Ward (Hef.3) describing the ESL Display at .M.LT.,
also concluded that a small computer must be used bet'v'leen a
display console and a central time-shared computer.
Ninke (Ref.1) states that GRAPHICS-2 achieves satisfact-
ory performance with a 2000 b.p.s. line; two London
University projects (Ref.4) are to use 2400 and 4800 b.p.s.
respectively.
The present paper describes in detail the Imperial
College system in which the satellite graphics configuration
is a PDP-9 and 3L~0 display, the cent ral computer is the
Univac 1108 at the National Engineering Laboratory, East
Kilbride, and the link is a voice-grade line, during 1968 a
dialled-up asynchronous 1200 b.p.s. circuit and later a
4800 b.p.s. private, synchronous circuit.

The work was supported by the Science Research

Council and the .Ministry of Technology.

71
 The PDP-9 configuration (Appendix A) has a 16K core
store (18 bits, 1.25~ cycle time), with hardware multiplier,
two 'DEC tape' magnetic tape transports, Type 340 display,
lightpen and communications interface equipment. A 166K
word disc file is being added.
Preliminary work on interactive graphics (Refs. 5 & 6)
was done on a PDP-7 with 8K core store and no backing store.
Experience in this work pointed to the need for a 16K core
store and for back-up by DECtape and disc.
For asynchronous data transmissions via Post Office Datel
200 or Datel 600 modems, a DEC Type 636 Communications
Adaptor was used. For synchronous' transmission at 4800 b.p.s.
a Recal/Milgo modem is used, and the Adaptor to interface the
PDP-9 to this transmission system was built by the project
team.
Of the computers available for connection to the PDP, the
Univac 1108, with the time-sharing operating system, 'EXEC 8',
seemed the most suitable. An offer of facilities on the
1108 at the National Engineering Laboratory in East Kilbride,
Scotland, 'liaS therefore accepted, under an arrangement to
collaborate in CAD work with that Laboratory. The NEL 1108
(Appendix A) is a single processor system with 128K core
(36 bit s, 750r cycle time , effective access time 375r by
interleaving), six FH 432 fast drums (262K words) and two
FASTRAND drums (22M words, 92 ms access time).
Tests with asynchronous transmission at 1200 b.p.s.,
dialled up, were carried out in 1968. At the same time,
plans were made for a synchronous 4800 b.p.s. private line to
NEL, (shared with Chilton Atlas Laboratory) and this, it is
expected, will be commissioned early in 1970.
The system was designed to be used for CAD research,
with 'weak' interaction between the PDP and the 1108,
(that is, initiating, from the satellite, an analysis run
in the 1108, observing the results, and initiating are-run
with changed parameters; this has been named 'iterative
design'). System resources were decided at an early stage,
and were determined by what was available for use, or by
what could be purchased with strictly limited funding.
Study of the optimum arrangement of system resources in a
satellite graphics system reported in a thesis by Foley
(Ref.7) shows that the balance of resources in the present
system is not a long way from the optimum.
This particular system was developed for the CAD research
because no large time-sharing machine was available for use
at Imperial College. Since the development was initiated,

70
arrangements were made for the College Computer Unit to hav6
a Control Data Corporation 'Digigraphics' Display System,
linked through the College CDC 1700 terminal computer by
wideband line to the London University CDC 6600. Some
applications (Section 9) will be investigated on the CDC
system, thus giving a comparison of cost-effectiveness between
the PDP/1108 facility with voice grade line and the CDC 274/
6600 system with wideband line.
The CDC Graphics terminal system, like the IBM 2250/1130,
has good facilities but is relatively costlyQ For the CAD
research, having in mind eventual application outside the
largest units of industry, it was required to keep a strict
limitation on the capital cost of the satellite station; this
consideration restricted choice to the PDP-9/340, the Elliott
905/928, and similarly priced computer/display SUbsystems.
The PDP-9 was chosen on the grounds of availability of
cassette tapes and of a disc store and because prior work had
been carried out on a PDP-7.
An additional and important reason for developing the
system, rather than purchasing 'ready made' from a manufact-
urer was to permit the tailoring of it to the particular needs
of the CAD research.

2. SYSTEM ENVIRONMENT
2.1 THE 1108 SYSTEM
The Operating System in use on the 1108 is EXEC 8, a
time-sharing executive supporting two kinds of user, Batch
and Demand. Batch work is normally entered via a card-reader,
with output appearing on a line-printer, while Demand use is
currently restricted to teletype terminals, although the
software is being extended to handle alphanumeric displays as
well. Demand users have access to almost all the executive
facilities available to Batch users, but because of the
on-line mode of working, errors which would cause a Batch
run to terminate are not fatal to a Demand run.
A run cannot communicate with any other run directly,
but it can cause any number of Batch runs to be initiated.
(It can communicate indirectly with another run via a common
data file on a backing store.) The run to be initiated must
be in a catalogued file on Fastrand.
A Batch run may raise itself to Real Time status with a
priority ranging from three to thirty-five (levels one and
two are reserved for interrupt handling and executive actions

73
respectively). This means that the run will not be swapped
out of core, and will have priority over Demand runs. This
is necessary for software which has to handle communications
equipment. The executive contains handlers for all standard
peripherals, and, in addition, will handle arbitrary devices
connected to a Multiplexor (the CTMC). When the system is
configured, details of the devices attached to the CTMC are
defined, e.g. data transfer rate. The user has then to
assign a device to his run and initialise communications by a
call to an executive function (CMS). He may then transfer
data to and from the device by calls to other executive
functions CCMO and CMI). A Line Terminal Table must be
associated with the device, the address of the buffer to or
from which data is being transferred, the number of
characters to be transferred, and the address to which control
will be transferred on completion of the operation. A time
may also be specified within which the operation is to take
place, and a status code is returned on completion which will
indicat~ whether the transfer was successful, was terminated
due to a time-out, or failed for other reasons. The data
buffer must be organized for two 8-bit characters per word.
The hardware and the system I/O routines impose no
restrictions on the character set used, and make no error or
parity checks. All 8 bits of each character are therefore
available for useful information.
The executive allows for a program to be divided into
independent Activities, which may be named. Any Activit~
may suspend itself by calling an executive funct~on (DACT).
It may be reactivated when another Activity makes an
executive request (ACT) supplying the name of the suspende.d
Activity; it will then proceed from the point of deactivation.
Some Activities will be registered as Interrupt Activities and
will be given control by the executive interrupt handler, on
the occurrence of externally specified interrupts. These
Activities have a very high priority and consequently they
are terminated when they make any executive request. They
can therefore, do little more than some elementary error
checking; and reactivate some lower priority activity.
This facility takes the burden of interrupt handling off the
user, whilst still enabling him to provide his own I/O
completion routines.
Another type of activity allows the user to retain
control in the event of certain errors. This activity must
oe registered with executive together with a mask, which
defines the types of error to be handled; other errors cause
termination of the run. When this routine is activated by
the system, a two-word packet is set to indicate the cause of
failure, and the address at which the error occurred. The
routine may take appropriate action, for example to correct

74
the error, and resume the interrupted activity, or to clear
up outstanding details and make a controlled exit. This is
obviously a very useful facility.
2.2 THE PDP SYSTEM
The initial version of the PDP Line Handler was imple-
mented with the PDP-7 Programming System (Ref. 8). This

T~E

1108
~
N~E

PDP
- N~E
-
DATA
~

LENGTH
-
CHECK-
~

S~
-
Fig. 1. Format of control messages

system did not prov.ne any device handling Executive facility,

and in-house software was written and used for this implement-
ation. On the PDP-9, the Advanced Software System (Ref.9)
has been used, and programs are run under control of the
'Keyboard Monitor'. Under this system, the user writes his
programs in a device-independent manner, using input/output
calls which refer to a particular '.DAT slot'. Prior to
running his program, the user effects the correspondence to
physical devices by assigning a particular device handler to
each of his .DAT slots. During execution these handlers are
called by the Monitor to transfer data between buffer areas
in the user's program and external devices. A variety of
modes of data conversion are available in the system; that
most resembling the machanism of the Link is DUMP mode, in
which delimited areas of core are transferred. A Link
transfer, however, requires data additional to that required

75
by normal peripheral devices, namely 1108 and PDP program
names, so that the standard I/O calls could not be used.
Instead, a basic device handler has been written for
the Link which simply sends and receives buffers in Image
Alphanumeric mode i.e. containing 8-bit alphanumeric
characters, one to a word. The more elaborate functions of
packing and message sequencing are performed by a separate
package which is intermediate between the user program and
the basic device handler. The device independent feature
is still useful in permitting a program designed for the
Link to be assigned other devices for debugging purposes;
it can be made to read from and punch onto paper tape, for
example.

3. DESIGN OF THE LINK HANDLER

Three types of messages are employed in the communication
between the two machines. These are:
(i) blocks of data, which constitute
input and output files of analysis
programs;
(ii) control messages, which are used to
exchange information prior to a data
transfer, and
(iii) acknowledgement messages which convey
to the sender of each of the preceding
types of messages whether or not they
were received correctly.
Control messages are of a fixed length, since in the
idle state the 1108 Link Handler is awaiting a control
message, and must issue an executive request for a fi~ed
number of characters. Nine characters will accommodate
all the information in the longest control message. These
characters are allocated as shown in Fig.1, and convey
information about the type of message, an 1108 program name,
a PDP program name, the amount of data to be sent, and a
checksum. Only the message type and checksum characters
are mandatory in a control message but when the other
information is relevant it will occupy the specified
positions.
Blocks of data have fixed maximum length and begin with
a toggle character and end with two checksum characters.
The data to be transmitted consists of an arbitary number of
18-bit words to be read into or out of an area of PDP core.
These are packed sequent ially into data blocks, of which
76
more than one may be required. Maximum-length blocks are
always used, except for the final block, the length of which
is chosen to accommodate the remaining words. The maximum
block-length is 255 characters, of which 3 are toggle and
checksum, and 252 are characters representing unpacked 112
18-bit PDP words.
If a block is to fit into an integral number of 28-word
Fastrand sectors and if it is to use an integral number of
8-bit characters, then its length should be a multiple of
56 words. The 112-word block-length selected seemed to
accord with what was known about error rates on the line.
Larger blocks reduc e overheads in turnaround time and
acknowledgement, but are more likely to be corrupted during
transmission.
The checksum employed in both control and data blocks is
a sixteen-bit number, sent as 2 8-bit characters, which is
the sum of all the preceding characters in the block.
Clearly ,compensating errors can cause the checksum to be
accepted for a faulty block, but this method is simple and
effectively detects most of the types of transmission error
encountered in use.
An acknowledgement message is always sent after
reception of a control or data message, and consists of two
repeated characters, either ACK(036) for acknowledgement,
or NAK(025) for negative acknowledgement. Both of the
repeated characters must be received as ACK, otherwise NAK
is ass~ed. There is a possibility of failure here, in the
case where ACK is sent and is received as NAK, but it is
difficult to see how to avoid this without getting into a
vicious circle of acknowledgements of acknowledgements and
so on.
If a NAK is received, the sending Handler automatically
repeats the message concerned, and will do so until its
reception is ACKd, or u'ntil a resend count is exceeded; this
signifies that something is seriously wrong with the line or
with the system status and an operator message is accordingly
given.
The routines called by the users programs in the 1108
and in the PDP, to accomplish data transfer, are described
in Appendix B.
4. THE FILE HANDLER
To enable link users to set up and manipulate data files
in the 1108 a set of routines known as the File Handler is

77
being written. These routines will be available to the Batch
programs running in the 1108 and will appear as Fortran
subroutines. They will also be available to the PDP user via
the Line Handler, giving him immediate access to a large
backing store. It is hoped that the response time for this
direct use will be limited only by the line speed and by the
mean access ....time of the backing store (92ms for Fastrand).
The PDP makes requests to the File Handler in the form of
9-character messages, of which the first character defines the
operation to be performed, and the last two characters
constitute a checksum. The remaining characters, or 48 bits,
will be used for the various parameters for the different .
operations.
A new data file may be created by a call to the SETUP
routine, specifying the file's name and size, the maximum
size of Block required, and whether the file is temporary or
permanent. A file may not be used until it has been ASSIGNed
to a Batch run (or the equivalent for direct use from the PDP).
A parameter fer the Assign eperatien will determine whether
the file is te be shared between a Batch run and the PDP
simultaneeusly, .or whether this assignment is fer exclusive
use. The Assign .operation alse cepies the User's.Directery
frem Fastrand, where it must be kept while the file is net
in use, ente fast drum,where it may be accessed mere
efficiently. A further request, RELEASE, perferms the
reverse eperatien.
The data files may be split inte Blecks .of (n + 3)
different sizes, where n is a user-defined parameter. The
sizes are restricted te 2 m secters, where m = -2, -1, 0, 1,
---n, and one sector is 28 words. (This is, in effect,
the physical recerdslze.) The user may call fer a Bleck .of
a given size and may assign a 12-bit name te it. A Directery
asseciating user-defined names with Fastrand addresses and
lengths is kept en fast drum (FH 432).
The user may subsequently read .or write the entire bleck
inte .or frem his cere area (i.e. in the 1108 .or the PDP cere
area, depending upen whether the call was made frem an 1108
Batch pregram .or directly frem the PDP). He is respensible
fer returning it te free sterage when he ne lenger requires
it.
The bleck may be further subdivided inte Facters by
asseciating a user-defined Facter-name with an .offset
pesitien within a particular bleck. A Facter may then be
used fer reading and writing as a Bleck, but can .only be
deleted when the Bleck centaining it is returned te free-
sterage. Nete that a Facter-name, like a Bleck-name, is

78
associated with a unique Fastrand address, rather than with
an offset, and is therefore used in place of a Block-name,
rather than as (Factor-of-Block).
It is believed that in addition to providing a multi-
level implicit structure to the file, the provision of
Factors effectively counterbalances the disadvantages of the
restricted block sizes. It is hoped that it will encourage
users to have large Blocks, thereby necessitating fewer
accesses to Fastrand, and improving efficiency.
When a file is set up it will be immediately split into
blocks of the largest size needed by the user. Whenever a
request is made for a block of given size, and there are no
blocks of that size available, a larger block is split to
provide it. Free storage will therefore eventually become
split into small blocks, and garbage collection will be
necessary. Two routines will be provided for this purpose:
Normal Garbage Collection, which will search through free
store and build contiguous small blocks into larger ones,
producing blocks of maximum size wherever possible, and
Panic Gar~age Collection, which will relocate all used
blocks into contiguous sectors, and divide the remaining
space into blocks of maximum size.
The File Handler will maintain (n + 3) chains of pointers,
the ruth chain containing all free blocks of size 2m sectors
(m = -2, -1,0, 1, --, n), and a table in core will contain
pointers to the beginning of each chain. A request for a new
block, or for returning an old block, will therefore require
only one access to Fastrand.
The details of the organisation of the directory have
not been finalised, but it will be such that the Standard
Univac search and random-read software may be employed to
advantage. Seven-word blocks will always occur 4 to a
sector, and 14-word blocks 2 to a sector, so that the larger
blocks never occupy fractions of sectors.
With a facility' of this natu~,it is likely that the
user will make errors of various kinds, for example,
duplicating a Block or Factor name, writing beyond the end
of a Block, etc. A means must be provided, therefore,
whereby he is informed of such errors BO that he may recover
from them without fatal results. For Batch programs this is
achieved by the user supplying the name of one of his
subroutines when he assigns the file at the beginning of a
program. In the event of an error this routine will be
called, and an error code will be supplied indicating the
cause of error. For direct use from the PDP a 9-character

79
message will be returned following acknowledgement of the
request, indicating success or failure of the operation, and
in the latter case, the cause of failure. Receipt of this
message will, of course, be acknowledged by the PDP.
5. OPERATING REQUIREMENTS
To connect the machines over the asynchronous line the
user has to dial the number of the phone attached to the
modem in the computer room at NEL. A computer operator
will answer it, and the DATA button on each telephone must be
depressed. If the connection proves noisy the operator has
to be informed and a new line dialled. It sometimes is
possible to secure a better line by dialling from NEL. The
1108 operator must additionally check that the multiplexor
controlling the line is in the READY state. This last
operation is the only one necessary to use the synchronous
line, since there is a permanent connection between the
modems at each end.
The software to handle the 1108 end of the line resides
on backing store.
A teletype connected direct to the 1108 via Datel 200
link is used to initiate the operation of the Handler, and
is available for program preparation and full 'Demand' use
of the 1108. It has been of particular use in debugging the LiI
Handler, as it was possible to follow the operation of the
handler in real time and dump each message received at or
sent from the 1108 on the on-line teletype. Since this was
situated alongside the PDP-9 it was a very simple matter to
monitor the complete sequence of events. Development was
carried out by the programmer of the 1108 handler and the
programmer of the PDP handler, working side by side at the
teletype to NEL and the PDP console teletype respectively.
There will eventually be no need for this teletype, as
it is hoped that the .1108 line handler will be built into
the Executive, and will be initiated on receipt of a code
sent from the PDP-9 over the link.
6. ERROR CHARACTERISTICS OF THE LINE
The frequency and pattern of mis-transmission of
characters on the dialled-up line from Glasgow to London has
been investigated. During a number of sessions,a fixed 256
character buffer was transmitted repeatedly from the 1108
to the PDP, and a record of received characters was punched
for subsequent analysis. The results indicatlt that the bit
error rate was of the expected order, 1 in 10 (Ref.10), but
80
 Fig. 2. Examples ot bit streams, interpreted as sent
and as received with errors

KEY: @ start bit

/ stop bit
,I
• idle bit

( n ) octal byte of decoded character

" / (2) ( 6 ) ( 2 ) @ ... • ... • / (J) ( J ) ( 1 ) @ • •

Sent 1 1 101 1 0 0 1 0 0 1 1 1 Sent 1 1 110 1 100 101 1
Error X Error X

Received 1 1 101 1 0 0 1 0 0 0 1 1 Received 1 1 0 1 0 1 10010111

... • / (1) ( 4 ) ( 4 ) @ ! • , / (1) ( J ) ( 1 ) @ ... •

-.-~~.-

Example .B
Example A
•
• ., .. / (1) ( 7 ) ( • /.(1) ( 7 ) ( 0 ) 0 • • • • ...
1 ) @ • • • • •
Sent 1 1 1 101 1 1 1 0 0 1 0 1 1 1 1 1 1 1 0 1 1 1 1 0 0 0 0 1 1 1 1 1

Error X

Received 1 1 110 1 1 1 100 101 1 111 110 1 1 1 100 0 0 1 101 1

• / (J) ( J ) ( 6 ) @ / (1) ( 7 ) ( 7 ) • • / (J) ( 0 ) ( J ) @ • .,

I
-----

Example C
00
...... FIGURE 2.
they also reveal some interesting consequences of the
formatting scheme employed for asynchronous transmission. A
bit sequence is transmitted by frequency-~odulation, using
one or other of two particular frequences fo r 0 and 1 bits.
The receiving modem converts this signal into a sequence of
voltage levels, corresponding to 0 and 1 bits. An 8-bit
character to be transmitted is framed by the interface
hardware with 3 formatting bits; a start bit (0) preceding
the character, and two stop bits (1) following it. This
bit stream is fed to the modem, which then remains in an
idle state, effectively transmitting 1 bits, until the
next character is supplied.
Thus an arriving bit stream may be represent ed as in
Fig.2 where the examples read from right to left in order
of arrival of the bits. The interface logic can be thought
of as starting in an idle state in which it is awaiting a
zero start bit, then counting off 8 bits and assembling a
character, then ignoring one stop bit, before reverting to
the initial idle state.
The simplest type of error occurs when any of the data
bits are corrupted, as in exampleB. Corruption of a start
bit or an idle bit can lead to a character being assembled
too late or too early, as in example A. In this example,
correct interpretation is resumed after the bad character,
but it is possible, as example C shows, for the original
error to propagate, and to give a series of spurious
characters, before returning to correct synchronisation.
In this example three characters are discovered where
only two were sent. These considerations make it less than
straight forward, from a comparison of received and trans-
mitted characters, to infer the incidence of errors in the
bit stream. Moreover, since transmission is asynchronous,
and any number of idle bits can occur between characters,
there is no precise correspondence between the character
rate and the bit rate. Assuming however, that characters
are supplied as fast as the modem can accept them, and that
there are 11 transmitted bits per 8-bit character, the bit
error rate was calculated as 0.79 x 10-4 , corresponding to
a character error rate of 0.86 x 10-3.
The bit error rate was expected to be about 1 x 10-4
for the 1200 b.p.s. dialled up line, but for a leased line,
which avoids exchange switching (the principal cause of
line noise), a rate of the order of 10-6 can be expected
(Ref.10).. Considerable variation in the quality of dialled-
up lines has been experienced, and whilst the system has
built-in re-send mechanisms to combat noise, it can become

82
paralysed when noise is particularly bad. This has often
necessitated re-dialling the connection. Both the improved
overall error rate and the avoidance of redialling have
been strong considerations in deciding to use a leased line
for further development of the system. It is known (Ref.10)
that even with the leased line there can be wide temporal
variations in error rate.

7. SYSTEM PERFORMANCE
As with any project of this nature, teething troubles
were experienced in both the software and the hardware. It
was often difficult to locate faults in the software of
either machine, in the hardware interfaces at either end,
or due to noise on the line. There was also considerable
delay due to faults in the 1108 operating system, although
this is now reasonably reliable.
As 1108 program was written to receive a block of data
from the PDP, reflect it back down the line, and also dump
it on the on-line teletype. A PDP program was written to
interface to this, and the operation of these enabled hard-
ware faults to be diagnosed.
The debugging of the software in both machines was
facilitated by the use of the teletype, as mentioned in
Section 5.
It is difficult to assess the average turn-around time
for analysis programs initiated by the PDP. It varies
enormously according to the load on the 1108, the size of
program, and the amount of peripheral usage required by the
program.
If there are several batch runs currently active in
the 1108, the analysis program may be kept in the backlog
for some time, despite the fact that it is entered as high
priority and therefore rises to or near to the top of the
queue. Once the run is scheduled, its running time is
affected considerably by Demand runs, which have priority
over all batch jobs, and which may use up to 80% of CPU
time. With our limited usage to date, whilst running
small batch programs to demonstrate the use of the link,
turn-around times of 20 seconds have been experienced under
favourable conditions. Times of the order of 2 minutes are
to be expected when there is a moderate load on the 1108 and
under very bad conditions a wait of half-an-hour would not
be impossible.
It should be noted that under all conditions other than
a failure of the Executive, the 1108 Line Handler will
83
respond immediately to messages received from the satellite
machine.
8. AOOPl'ION OF 1108 LINE HANDLER BY OTHER USERS
Consideration has been given to the use of the 1108
Line Handler by the Computer-Aided Design Division of NEL,
to handle an Elliott 905, with Graphic Displ~" over a
synchronous 4800 b.p.s. link. Because this machine has the
same word-length as the PDP-9 (18 bits) the alterations
necessary reduce to one card image, which ~ecifies the
channel and unit number 0 f the line terminal, together with
some minor changes for accounting and administrative pUIposes.
It would be an equally simple matter to interface any other
l8-bit word-length machine to the 1108. Software equivalent
to that used in the PDP-9 would, of course, have to be written
for the Elliott 905 and for any other machine.
Initially each satellite machine would have its 'own'
copy of the Line Handler resident in the 1108, but it may
prove desirable to make the Handler re-entrant so that all
satellites use the same one. This should not be an inordinately
difficult undertaking as 1108 system routines are available for
this purpose.
9. USE OF THE SYSTEM FOR INTERACTIVE GRAPHICS
The system was designed for use by research projects in
computer aided ship design, circuit design and architectural
design (CASD, CACD and CAAD).
Each project is making assumptions about the best
assignment of tasks to each computer. Basic software
(Display, Link and File Handlers) is where desirable, shared;
each project can develop in its own way, building on the
basic Handlers if by so doing programming effort will be
reduced.
In the Ship Project, MacCallum (Ref.11) has implemented
surface definition routines in the PDP-9, enabling a naval
architect to define a first approximation to hull form by
lightpen. Parameters from this definition will be sent by
the link to the 1108 where a program by Jenkins (Ref.12)
will use the parameters to define the surface in a form
suitable for analysis programs. Performance curves will be
calculated by Fortran programs in the 1108. Output data
from these programs, in Fortran afr~ys, will be accepted by
an Output Graphics Package (Khan' 3) and resulting PDP
display file will be placed in a buffer area for the Link
Handler to transmit for display by the PDP-9.

84
 Other uses in the Ship Project, for which preparations
are in hand, are Longitudinal Strength Ana~is and Steelwork
Detailing.
A Longitudinal Strength Program (Ku0 14 ) has been run
on the 1108. Input data for the Program will be a represent-
ation of a compartmented cargo ship; different loads will be
placed by the designer, using the lightpen or teletype, into
different compartments. Graphical output from the program,
seen on the PDP Display, will indicat e, for different stations
along the ship, the shear force and bending moments. The
loading distribution may then be altered for a re-run of the
program.
The CACD project has developed a Linear Analysis Program
with Output Graphics, working in the PDP-9 (Drew, 16).
An Input Graphics package for this or other circuit
analysis programs is being tested. The link is to be used
to allow larger analysis programs to run in the 1108, input
data having been prepared in the PDP-9.
Use of the system for architectural design is possible
but unclear. Sections of the architectural profession and
the construction industry are 0 f the opinion that interactive
graphics will be an important aid to architecture. The
M.o.P.B.W. Report on C.A.C.D. (Ref.16) presents this finding
but is not specific as to applications which can now be
implemented and which would be cost-effective. \vhen such
an application emerges, it could be implemented on the link.
The overall objective in setting up and using the linked
computer system is to get experience of' its application to a
few real-world problems. It is hoped by this to gain
information on (i) the balance bet !rJeen ergonomic factors,
(such as response time) and system resources (such as band-
widths and satellite computer pm'Jer), (ii) the extent to
which software can be shared bet\Jeen applications as diverse
as for example, ship design and circuit design, and (iii)
design considerations and operating problems of a system
based on a voice-grade data link to a distant computer.

The authors gratefully acknovJledge the co-operation of

colleagues at the National Engineering Laboratory; the work
of I1rs. Suzanne Llewellyn, who VJaS seconded for six months
by Univac and wrote part of the 1108 Line Handler; and the
work of Mr. H. G. Carpenter and I"1r. P. w. Fenwick in making

85
the arrangements for and setting up the hardware elements of
the data links. Mr. Fenwick designed the Data Adaptor for
the synchronous link.
The work is being done under Science Research Council
Grant B/SR/2071 and a Ministry of Technology Contract
entitled IIApplication of Computer Graphics to Ship Designll.

REFERENCES
1. Ninke, W. H. I1A Satellite Display Console System
for a Multi Access Central Computer ll
Proc. IFIP Congress 68 August 1968.
2. Ninke, W. H. I1GRAPHIC - 1 - A Remote Graphical
Display Console System l1 • Proc.
FJCC, 1965 pp. 834-846.
3. Ward, J. E. I1Systems Engineering Problems in
Computer-Driven CRT Displays for
Man-Machine Communicationl1. IEEE
Transactions on Systems Science
and Cybernetics June 1967.
4. Linders, J.G. "Two London University Display and
Kirstein, P.T. Remote Access Projects".
5. MacCallum, K. J. "Display and Manipulation of 3-
Dimensional Surfaces", Imperial
College Centre for Computing and
Automation Report CTG 67/5, and
"Further Use of a Display for
Surface Design", CCA Report CTG 68/1.
6. Newman, W. M. "A System for Interactive Graphical
Programming" AFIPS Conf. Proceedings
Vol. 32 1968 SJCC. pp.47-54.
7. Foley, J. D. 110ptimal design of Computer-Driven
Display Systems". Technical Report
34. Systems Engineering Laboratory,
EE Department, University of Michigan
Ann Arbor, March 1969.
8. PDP-7 User's Handbook. DEC Manual F-75.
9. Advanced Software System Monitors. DEC Manual DEC-9A-
l1ADO-D.
10. Private communications from the GPO
and ICL and "Telecommunications and
86
 the Computer", Martin J. p.360 et.
seq. Prentice Hall, 1969.

11. MacCallum, K. J. liThe use of Interactive Graphics for

the Preliminary Design of a Ship's
Hull" See this volume. (Part 12).
12. Jenkins, A. P. IIProposal for File Handling Scheme
on 1108". Imperial College CCA
Technical Note TN/69/2.
13. Khan, I. J. IIFortran Graphics Package - General
Description and User's Guide",
Imperial College Computer Graphics
Group Report 69/3.
14. Kuo, C. "A Note on Still Water Bending
Miller, N. S. Calculation by a Digital Computer".
University of Glasgow, Naval
Architecture Department, Res.
Eeport No .10.
15. Drew, A. J. "A Prototype Computer System using
graphics for the Interactive design
of Linear Electric Networks". To
be presented at the 4th Colloquium
on Microwave Communication.
Budapest, April 1970.
16. M.o.P.B.W. Research Development Paper
flComput er-Aided Architectural
Design Part 1, Re£orts of three
Working Groupsfl, 1'969.

APPENDIX A

HARDWARE CONFIGURATION
By P. W. Fenwick

The PDP-9 is a single accumulator machine with a

core store of 16K 18-bit words of 1.2 access time,
using single address instructions with one level of
indirect addressing. The "Extended Arithmetic Element fl
provides a multiplier-quotient regis.ter and a step

87
counter enabling mu1ip1ication to be done in 15 •
Backing store is DECtape (2 transports); a 166K word
disc file is to be added shortly. The display is a
DEC type 340 point-plotting display using a binary rate
multiplier to generate vectors. Data words are taken
from PDP-9 core store by autonomous transfer with sub-
routine jump capability. Display interaction is by
light pen. The PDP-9 is interfaced to asynchronous
modems (Datel 600 or 200) by a DEC 636 Communications
Adaptor. For synchronous line communication a Racal
4400/48 modem is connected to a purpose-built interface
which recognizes and strips off initial tlsync tl
characters at the start of a block of data. The Racal
modem uses an eight phase-shift modulation system
encoding three bits at a time. This enables 4800 b.p.s.
transmission in a 1.6KHz bandwidth centred on 1.7KHz.
The Univac 1108 at NEL is a single processor
~onfiguration with a core store of 128K 36 bit words, of
750 access time. Store accesses are interleaved,
giving an effective 375 access time. Successive
instructions are overlapped, and instructions can operate
on double full, half, third, quarter or sixth words.
128 integrated circuit 120 registers are addressed as
the first few words of store. These control registers
include 16 accumulators and 15 index registers, 4 of
which overlap the accumulators. Backing store consists
of six fast drums, storing 262K words with 4.3 m sec
access time, and two slower drums storing 22M words with
22 m sec access time. Six 800 b.p.i. tape transports
provide a 6K word/sec transfer rate with backward read
facility.

APPENDIX B

HANDLING ROUTINES

The routines called by the user's programs in each

machine to accomplish data transfer are as follows:-

PDP/ CALL OFLLK (A,IDA,IDB,N)

Sends N words, beginning at address A, to the 1108, preceded
by a header containing IDA and IDB, each of which is a pair
of alphanumeric characters. IDA represents the last two
characters of the name of a file supplied by the user on the

88
1108, to which control will be given by the 1108 Handler,
and which will cause the user's program to be run. IDB
identifies this particular request from the PDP,and will
subsequently be used when requesting the corresponding
output.
1108/ CALL PDPIN (A,N,M)
Reads into array A N words, beginning at the Mth word, of
the data received from the PDP.
1108/ CALL PDPOUT (A,N,M)
Writes N words from array A into the output file, starting
at the Mth word.
1108/ CALL PDPFIN
Indicates to the Handler that the output file is complete.
PDP/ CALL IFLLK1 (IDB,N)
Requests number of words N in the output file for PDP
program IDB, returns -1 if the output file is not yet
ready.
PDP/ CALL IFLLK (IDB,A)
Requests transmission of output file for PDP program IDB
from the 1108 into PDP core, starting at address A.
PDP/ CALL EOT
Removes the 1108 Handler from core and ends the session.

89
 CONVERSATIONAL DESIGN OF STOCHASTIC
SERVICE SYSTEMS FROM A GRAPHICAL
TERMINAL
K. B. Irani, V. L. Wallace, J. H. Jackson

The University of Michigan, Systems Engineering Laboratory, Dept. of Electrical

Engineering, Ann Arbor, Michigan 48104, U.S.A.

It is frequently desirable to design stochastic service systems

which cannot be adequately analyzed by normal queueing theoretic
models. Such systems consist, in the most usual instances, of
numerous waiting lines (or "queues"), servers, and controlling or
directing stations which determine the discipline of task flow through
the system. These systems are often realistic representations, for
high-traffic design purposes, of behavior in diverse fields such as
plant management, telephone switching, air traffic contr-ol, electronic
warfare, logistics, and computer system specification and control.

Improved techniques for the design of such systems are greatly

needed. For example, a design problem of this type which has not
yet been adequately resolved is at the heart of a current crisis in the
development of executive systems for demand-paged, multiprogrammed,
timeshared computer systems. Problems of this type are also found
frequently in the course of selecting the equipment and executive
control strategies which permit a modern large-scale computer system
to serve a specific environment. These problems have, in the past,
required painstaking study and could not be answered generally enough
to be treated routinely. Increasingly, as the "computer utility"
concept gains acceptance, these "queueing" problems will assume a
more and more dominant position as the source of computer system
inefficiency.

Similar needs for improved techniques are found everywhere that

high-traffic problems occur. This is the natural result of the trend
of every technology toward ever larger and more complex systems,
with ever greater levels of traffic. New techniques should permit a
more routine design of individual systems and strategies for specific
environments.

91
 One of the major hopes for significant improvement of design
capabilities using queueing models lies in the so-called "conversational"
computer techniques, whereby the calculating power of a computer
can be closely coupled to the creative power of a design engineer.
If a designer can freely pose alternative models to a computer and
get immediate evaluation of various performance criteria, he may
then generate enough insight (via cut-and-try procedures) to guess a
near-optimal design for a system far too large or tightly interrelated
to be treated by conventional optimization techniques.

However, the use of conversational techniques for the analysis

and design of stochastic service systems requires development of a
problem-oriented programming system which is specifically tailored
to the demands of conversation. The input language must be terse,
the calculations must be fast and reproducible, the variety of models
available must be broad, and the results should be in a graphic,
insight-provoking form.
The most promising approach to developing such a system is to
use graphic displays for the man-computer communication, and to use
recursive numerical methods [4] applied to Markovian models for the
analysis. Graphical input to the computer in the form of queueing
network diagrams provides an ideally compact medium for description
of problems, while an output in the form of graphs provides a suitably
insight-provoking form for results.

The recursive techniques provide fast calculations with excellent

accuracy (hence reproducibility) of the calculated results [3]. They
also can be applied to a wide variety of models. This variety of
models is considerably broader than is feasible with closed form
analysis, but not as general as the slower, less accurate simulation
methods. The detail available in numerically solvable models is
also midway between that available using closed form analysis and
simulation methods.

There are three basic operations involved in a programming

system to serve these goals. They are:

1) the servicing of the graphic operations,

2) the translation of the diagram to the form required for
(Markov chain) input to the solution system, and
3) the solution of the Markov chain.

A programming system which performs these operations has been

implemented on a DEC 339 display terminal and IBM 360/67. The
92
system consists of two parts: SELMA [1] and QAS [2]. SELMA
(Systems Engineering Laboratory's Markovian Analyzer) resides in
the display terminal and services all graphic operations, whereas
QAS (Queue Analyzer System) resides in the IBM 360/67 and both
translates diagram information into Markov chain form and solves
Markov chains.

The subject of this paper is the behavior of SELMA/QAS as

viewed by a user of the system. Since the function of QAS is to
prepare a solution based on information obtained from SELMA, the
user does not interact with QAS directly. Consequently, all of the
interaction between the user and the system is supported by SELMA
and does not depend on the large computing facility. For this
reason, the discussion which follows is limited to SELMA.

Since no standard set of network element symbols is defined for

Markovian queueing networks, the set of symbols shown in Figure 1
was defined for use in SELMA/QAS. Each port shown in this figure
represents an attachment point for a connection, whereas each
parameter dot represents an attachment point for a numerical
parameter value. The queue symbol represents a finite queue whose
maximum length is the value of its parameter. An item which is
available at the queue's input port enters the queue whenever the queue
is not full. An item is available at the queue's output port whenever the
queue is not empty. The server symbol represents a service channel
which has an exponentially distributed random service time. The
parameter is the mean service rate. The server can hold only one
item at any time, but it has three states: it may be idle, it may be
servicing an item, or it may have serviced an item and be unable to
release it through its output port because the connection at its output
port cannot accept it. The source symbol represents an infinite
source of items to be introduced into the queueing network, whereas
the exit symbol represents an infinite sink for removing items from
the queueing network.

An element is created by referencing a light button which denotes

its type. A tracking cross appears with the element symbol so that
the symbol may be moved to any desired position on the screen.

The creation of new symbols is the only operation required for

the construction of a queueing network which requires the use of
light buttons. All other operations (except for the inputting of
parameter values) are performed by first pointing the light pen at
the part of the diagram which is to be mOdified, and then moving the light

93
Input Port
/ Output l'ort

Parameter Dot
Queue

Output Port

yt/
•
Server
Parameter
Dot

Input Port

Output "Port

~/ Exit

Source

Figure 1

Element Symbols

94
pen in a manner which is indicative of the operation to be performed.
For example, the operations which may be performed on unconnected
element symbols are shown in Figure 2. A symbol is deleted by
pointing the light pen at it, and then stroking vertically across it.
However, if the user instead moves the pen away from the symbol,
the symbol is moved with the light pen.

(
f
\
~
.' \
I ',
/
i \

\
I I
,
I I

,,
\
I
\
I \
I
I
I
/. -
\
I
\
I

, / \
, I

~, I ,,f,,
\ '

"
(

Deleting a Symbol

--- - - - -)'
-----
- • -

Moving a Symbol

Figure 2
Operations on Unconnected Element Symbols

95
 In addition to these operations on unconnected element symbols,
all operations which are required to connect and disconnect elements
are performed with motions of the light pen. However, before these
operations can be described, the types of connections which may be
formed must be described.

Element symbols may be connected by the following five types of

connections:

1) simple connection,
2) random branch,
3) priority branch,
4) random merge, and
5) priority merge.

The first of these, the simple connection, associates an output port of

an element with an input port of either the same or another element.
An item flows from the output port through the connection to the input
port whenever an item is available at the output port and the input port
can accept it. A branch associates one output port with several input
ports. If the branch is a random branch, all of the associated input
ports must be free to accept an item before an item can flow through
the branch. When this condition is true and an item is available at
the associated output port, the item flows through the branch to an
input port which is selected according to probabilities associated with
the input ports. If the branch is a priority branch, at least one of
the associated input ports must be free to accept an item before an item
can flow through the branch. When this condition is true and an item is
available at the associated output port, the item flows through the
branch to one of the free input ports which is selected according to
priorities assigned to the input ports. A merge associates several
output ports with one input port. If the merge is a random merge,
an item must be available at every associated output port before one
of them can flow through the branch. When this condition is true and
the associated input port can accept an item, one of the available
items is selected according to probabilities associated with the output
ports to flow through the branch to the input port. If the merge is a
prior ity merge, an item must be available at at least one of the
associated output ports before one of them can flow through the branch.
When this condition is true and the associated input port can accept
an item, one of the available items is selected according to priorities
assigned to the output ports to flow through the branch to the input port.

All connections are originally generated as simple connections,

96
which later may be extended to form branches or merges. The drawing
of a simple connection is started by pointing to an unconnected output
port of an element symbol. The connection is completed by drawing
a line from this output port to an unconnected input port with the light
pen. As the user moves the light pen, the actual line that is drawn is
not a straight line between the output port and the position of the light
pen, but it is a sequence of horizontal and vertical line segments which
approximates the path of the light pen.

Whenever a simple connection is to be converted to a branch or

a merge, the type of branch or merge (i. e., random or priority) must
be established. This is accomplished by moving the light pen in a
pattern which corresponds roughly to the shape of a node which is to
be placed at all intersections of lines in the branch or merge to identify
its type. This node is a dot for a random branch or me rge and a diamond
for a priority branch or merge. Consequently, no special motion is
required to generate a random branch or merge, whereas a circular
motion is used to generate a priority branch or merge. The steps
required to generate the various types of branches and merges are depicted
in Figures 3 and 4.

Once a branch or a merge is formed, more element ports may

be associated with it by drawing additional connection lines. No
distinctive motion of the light pen is required to determine whether
a dot or a diamond is to be placed at the intersection of the new
connection line with the branch or merge, since the type of branch or
merge is already established.

The values of the probabilities and priorities which are associated

with branches and merges, as well as the values of parameters
which are associated with certain element symbols, are assigned
through the use of 12 push buttons, which represent the decimal
digits 0 through 9, a decimal point, and a backspace character. A
parameter value is specified by supplying a sequence of from one to
four characters. The value is displayed in the lower right-hand corner
of the screen as it is inputted, and only the parameter dots and parameter
values in the diagram are sensitized to the light pen. If the light pen
is now aimed at a parameter dot or parameter value, that item is
replaced with the new parameter value which was inputted on the push
buttons.

The light buttons for creating symbols, the light pen motions which
are used to modify the diagram, and the push button facility for
inputting parameter values are sufficient tools for generating the
diagram. However, a queueing network may become so large that its
diagram will not fit onto the display screen. For this reason, the
97
~ . .I I
I
I
I
I · ~ 8 II
• I--

\Y
( 1)

8- -8-
I
I
I

~---)

.
(2)

- • .{~
/

.~
/ •
(3)

I
I
/-, {J
.-\
)
Random Branch

-/- I \~/
1
I
I
'I
I

----) 8
I

\I
(1)
(2)
- • /""-.
'\,v
• • r-

• •
[ ~
Priority Branch
Figure 3
Generation of Branches

98
-1 • I [ .r -1 • I • 1-
-8 (1)
- •
(2)
Light pen
remo ved here

~. I I• 1-
-8 1
----1

(3)
Random Merg e

-1·11--- &
.
1:\

-8-(:)J
I

(2)

• • •

•
(3)
Prior ity Merge
Figur e 4
Generation Merg es

99
diagram is considered to be drawn on a 75"x 75" piece of "paper" which
may be moved to various positions under the screen through the use of
a light button.

By means of light buttons, the user may request either a graph or

a typed table of the steady-state probability of either a single element or
the entire model being in a state versus the state number. If a graph
is requested, it is displayed as a histogram. Only the maximum and
minimum values of the abscissa and ordinate are labeled; however, the
user may cause the abscissa and ordinate value of any point on the
graph to be labeled by referencing that point with the light pen. Facility
is also provided to expand sections of the graph in order to observe
detail when many abscissa values are plotted.

In the event that the user requests a solution and the diagram is
either incomplete or incorrect, a large flashing arrow is placed on the
diagram to indicate the location of an error, and an appropriate comment
is typed on the teletype. The flashing arrow is removed from the
diagram when the error is corrected.

In addition to the light pen and push button operations, SELMA also
supports several operations which are invoked by keyboard commands.
These operations allow the user to save queueing, networks on files
at the IBM 360/67, to retrieve queueing networks from these files, to
destroy the current network in preparation for beginning a new one,
and to terminate execution of both SELMA and QAS.

The interactive operations which SELMA supports may be classified

according to the frequency with which they are performed. The most
frequent operations are those which are used to modify the diagram.
Consequently, an attempt has been made to make these operations very
natural to the user. In particular, coarse motions of the light pen are
used for all of these operations except specification of parameter values
and creation of new element symbols. Less frequent operations, such
as specifying results, are also performed with the light pen, but through
the use of light buttons, which are not quite so natural to use. Finally,
very infrequent operations, such as saving and retrieving networks,
are relegated to the teletype. This classification of the various operations
together with the resulting implementations of them, has provided a
terse problem-oriented language for the conversational analysis of
Markovian queueing networks.

100
 References

1. Jackson, J. H., SELMA: A Conversational System for the Graphical

Specification of Markovian Queueing Networks, Technical Report 23,
Concomp Project: also SEL 45, System Engineering Laboratory,
University of Michigan, Ann Arbor, Michigan, October 1969.

2. Randall, L. S., 1. S. Uppal, G. A. McClain, and J. F. Blinn,

Implementation of the Queue Analyzer System (QAS) on the IBM
360/67, Technical Report 22, Concomp Project; also SEL 43,
Systems Engineering Laboratory, University of Michigan, Ann
Arbor, Michigan, to be published.

3. Wallace, V. L., and R. S. Rosenberg, "Markovian Models and

Numerical Analysis of Computer System Behavior", Proc. AFIPS
Spring. Joint Computer Conference, Vol. 28, 1966, pp. 141-148.

4. Wallace, V. L., and R. S. Rosenberg, RQA-1, The Recursive

Queue Analyzer, Technical Report 2, Systems Engineering
Laboratory, University of Michigan, Ann Arbor, Michigan,
February 1966.

101
 THE ANATOMY OF AN INTERACTIVE
GRAPHICS DISPLAY PROJECT:
AN ENGINEERING TOOL
R. G. Gillespie

Associate Director, Computer Center, University of

Washington, Seattle, Washington 98015, U.S.A.

After experimental use of an interactive display system

(IBM 360/75 and 2250), a project was initiated at the
end of 1967 to develop a practical service for engineering
use. Since the predominant amount of engineering work
was on the CDC 6600 at the Boeing Commercial Airplane
Division, that computer system was chosen to be the base.
An interesting display system (Adage AGT-30 computer,
hybrid array and scope) was chosen. One of the primary
objectives of the project, in contrast to other display
projects aimed at a particular application, is to make
interactive display services available easily through any
FORTRAN program on the CDC 6600. The progress of the
project from the setting of design objectives through the
design, evaluation of displays, sub-operating system design
for both the display and 6600 to the initial use of the
system will be covered candidly with an attempt to discuss
errors and successes both technical and management.

INTRODUCTION

The emphasis in this paper is on the analysis of the methods

for transferring new computing capabilities into practical use
within an engineering environment. Webster's New World Dic-
tionary defines anatomy as lithe dissecting of a plant or ani-
mal in order to determine the position, structure, etc. of its
parts". The structure that we are analyzing is the structure
of the project itself, rather than the structure of the soft-
ware and hardware which provides the graphics facilities.

103
1. Problem(s)

The basic objective of the development project was to place

into the hands of an engineering staff the interactive graphic
capabilities that could be used productively (meaning that
these facilities would be used on actual engineering work). The
major problem was to develop a new tool sufficiently reliable
and attractive to gain commitment for its use by the engineer-
ing staff. Thus, the approach to the development project--the
strategy--would influence the success.

The formulation of a strategy for a development project is pro-

duced by a number of iterations where the risk, resources and gain
are balanced. This iteration is not always explicit, but the
questions below need to be considered:

a. Who needs the result? How important is it to them?

Do they have management support? How well do they
understand the risks? How clearly defined is what
they need? How much time will be committed during
development?

b. How many different organizations/groups are involved?

How well do they work together? What other tasks
would be of higher priority? How much time will be
spent on review and resource decisions?

c. Is it more important to meet a schedule than to

polish versions of the task? If a new tool is being
developed, how clear is it that the initial specifi-
cations are good? Will the implementers have any
similar experience? Can any existing work be used?
Who else has done similar work? Why did they succeed?
Fail?

d. If the result is successful, what does it imply?

Could additional resources be provided?

e. What are the attitudes of the groups and people in-

volved? Who will lead the project? What are the
strengths of those involved? Weaknesses?
Every development project has to take into account the risk
that it will fail to meet the objectives. A balance between
new facilities and ideas and amount of investment versus pre-
dictability of schedule had to be considered. These consider-
ations involve some numbers: for instance, the value of inter-
active graphics was seen as reduced engineering design flow
time plus improved design, and it was estimated that the pro-
ject would cost at least ten man years and $100,000 for com-
puting resources.

104
The judgment was made to risk the investment because of the po-
tential payoff. Since it was realized that we needed more than
a demonstration, we needed to choose a strategy that increased
the chance that the tool developed (interactive graphics) matched
the requirements of the tool users.

2. Background

In order to understand the management approach, we need to re-

view briefly the nature of the organizational environment. This
project was initiated in November, 1967, at the Commercial Air-
plane Division of the Boeing Company. At the Boeing Company
the programming and computing organization was organizationally
separate from the engineering organizations. In this framework
no programming was done by the engineering staff, and the en-
tire job of programming was carried out within the computing
organization. Within the computing staff the research group
had the primary objective of exploring new techniques in com-
puting, demonstrating, and investigating new tools. A heavy
emphasis was naturally placed on the cost-effectiveness of
the proposed activities. Unfortunately, it is easier to compare
the value of a new version of an old tool against the old version
rather than to determine the impact of a new tool which may
affect the way work is performed.

While there had been a history of generally futile efforts in

the development of graphics applications for practical use,
there did exist considerably advanced applications programs
which used the large-bed plotters, CalComp plotters and SC4020
devices. At the time period the project was considered the
CDC 6600 was the computer used for the engineering work.

3. Management Approach

Since the primary objective was to develop a tool for engineer-

ing use, it was decided that the organization of the project
would take a different form from the generally loose research
investigation. Before the engineers would use a new tool like
graphics, they would need a commitment on its life and sched-
ule. Our experience with development projects of this size
(10 to 15 man years) led to a carefully scheduled project and
management plan. An essential part of the plan was the series
of documents and review sessions. The documents were part of
the product and helped schedule the early phases of the project.
The table below summarizes the approach to accurate scheduling
and review through a series of documents and reviews:

105
 Size Reviewed for:
Design 2-3 What is the goal of the task?
Objectives pages What functions will it provide?
What resources will it take?
What technical approach w1ll be followed?
Prelimi- 10-15 What interfaces are there with other software?
nary De- pages What functions and operating sequence will
sign there be?
What schedule is proposed?
Des1gn l5-? Deta1l spec1f1cat1on of des1gn.
pages
A necessary condition for meeting requirements is the adequate
representation of the users on the review boards which should
function after each document. This provides the proper feed-
back from the potential users at a state which allows change.
(The cost of adding a room to a house after it's half built is
high! )
The initial review of the design objectives is important in
order to make sure that the resources will come in order to
support the project. In this project, applications program-
mers familiar with engineering areas joined the project at the
start, but no members of the engineering staff.
The design review sessions were publicized ~nd meant to be a
time for argumentative exchange rather than rubberstamping.
Comments from outside the group developing a tool for someone
else are necessary in order to avoid self-centered satisfaction.
Also, development groups have a tendency to assume the future
user knows all about programming.
Another part of the management approach was to draw a detailed
PERT chart in order to work out an understanding of all the ele-
ments and interfaces. This turned up user training, manuals,
and testing, and many overlooked tasks. A useful function of
the chart was to provide a clear plan for later versions of the
project. Many projects are planned as if they will not be re-
vised and changed. Also, by having a later version displayed
we were able to emphasize the importance of the scheduled reviews.
The ground rule was emphasized: changes to the specifications
received after review points will go into version 2! Ordinarily,
it is hard to measure the impact of a few changes on the schedule,
but this control is necessary and moves the change review to a
management, rather than technical, problem.

Thus, the general strategy was to include people representing

the users on the design team, publish a sequence of design doc-
uments in increasing detail, provide active review points, and
carefully schedule the activities.

106
4. Previous Graphics Experience Affecting the Objectives
As in many other large engineering organizations, the excite-
ment generated by the idea of blending computing with graphic
display led to a number of experimental projects at the Boeing
Company. The last of the projects at the Commercial Airplane
Division used an IBM 360/75 and 2250 display system. And, as
was also discovered, the difficulties of developing a workable
display were compounded by the early throes of the IBM 360 op-
erating system. Little progress was made in two years toward
providing a usable and economically feasible project. And, in
that time, engineering computing began to use the CDC 6600.
Also, increased scheduled use of the 360 system for data pro-
cessing problems forced the experimental development to a
3 a.m. to 5 a.m. schedule for use. This provided a real test
of enthusiasm for prospective users. These changes led to a
breathing point and review in the autumn of 1967, when it was
proposed to generalize about the results and start afresh.
Summarizing the experience are these comments:
a. Conversion of large engineering problems from one com-
puter to another provided too large an entrance fee
for graphics.
b. To o'ur surprise, more time was spent at the terminal
looking at character displays, programming, etc.,
than inspecting graphs.
c. Trying to debug a multiprogramming system while de-
veloping a graphics capability increased the effort
needed by an order of magnitude.
d. Graphics services which would allow easy use of ex-
isting programs (minimum conversion) would increase
the likelihood of practical use.
e. Remote facilities were needed (when the engineering
force was scattered over a 100 square mile area).
f. While much excitement was generated over drawing and
light pens, plotting facilities might give a quicker
payoff with lower investment.
g. Users would not spend much time working at their ap-
plications if there were not a production guarantee
on the pilot system.
h. Core requirements for graphics service rise and ex-
ceed whatever core is available.
Review of those points and other requirements led to the ob-
jectives.
107
5. Design Objectives

Based on the previous experience, it was decided that the combi-

nation of a small computer and a scope would provide the best ap-
proach, meeting the general objectives stated in November of
1967:

a. Interactive graphic pilot production service on the

CDC 6600 should be available in the summer of 1968.

b. The terminal will be capable of being remote from the

central complex.

c. The pilot service will have the capability to expand

into a production service.

The design objectives document functional descriptions of the

services to be available from the terminal and the 6600 and al-
so the likely description of a terminal itself. The small com-
puter would control the display scope and provide the facilities
for card reading, storage, and printing, thus offering remote
service capabilities independent from graphics. The terminal
service was expected to provide to the user the ability to gener-
ate data, submit jobs to the 6600, print, block, translate, ro-
tate, scale, change initial conditions, generate data, modify
the programs, etc.

The project team was assembled and organized to include four

members of the software research group, including several who
had worked on previous graphics display projects, two members
of the applications programming group who would provide
the interface for the engineering area, and one man from the
manufacturer of the terminal chosen. This was done in order to
make sure that the flavor of the project development was not
guided entirely by the research objectives of the research
group. The formal sequence of documents and review was proposed
in order to insure the proper review of the general design and
also to catch problems at the early stages.

6. Evaluation

The design objective documents were used as a base for devel-

opment of an evaluation of hardware alternatives. Considerable
time (six months) was spent on evaluating equipment and program-
ming systems. Also, this time was spent on reviews of the ob-
jectives of the project by other groups within the programming
staff. This time introduced a lag in the equipment acquisition
that proved to be crucial.

108
The equipment was reviewed and costs compared. A development
project rule was used to make the final decision: between equal
cost alternatives, choose the alternative that provides the
greatest opportunity for learning. An Adage graphics terminal
was chosen that provided an interesting combination of analog
and digital techniques for control of the display. Coordinate
transformation was handled through a hybrid array, thus allowing
smooth translation and rotation of images.

7. Hardware Environment

The CDC 6600 was supplemented by an Adage AGT/30 graphics ter-

minal connected by telephone lines. There was a considerable
delay, and the terminal was not delivered and accepted until
January, 1969. The AGT terminal included the following hardware:

DPR2 digital computer with 16K core memory (30 bit word,
2 microsecond cycle time)

Coordinate transformation of 2-D and 3-D images

Vector generator that provides depth queueing by beam in-

tensity modulation on the Z axis

Graphics console which includes a 13" x 14" CRT display,

alphanumeric keyboard, function switches, light pen,
joystick/bowling ball, and variable control dials

3-D windowing device and character generator options

Disk memory system of 675K words

Magnetic tape drive

Card reader, 200 CPM

Printer, 600 LPM

This terminal provided display capabilities that allowed smooth

rotation, translation, etc. without involving the CDC 6600.
This separation of functions provided a means for minimizing
complex program calculations that would have been needed to pro-
vide those functions all digitally. Since these tasks were ex-
pected to be in heavy demand, based on previous graphics use,
less storage and time would be needed at the small computer
also.

109
8. Software Environment
In order to provide an interactive environment, several steps
were taken. Rather than rebuild the existing CDC 6600 SCOPE
operating system (and one of the design constraints was LEAVE
THE OPERATING SYSTEM ALONE:), we chose to develop for our use
a timesharing system called SHARER, which was developed at New
York University. This provided swapping facilities for a limite
number of terminals but matched our requirement for the ability
to use existing large FORTRAN problems with little modifica-
tion. The diagram on the next page shows the general structure
of the system:

CDC 6600 I'-........ AGT/30

Memory AGT 30 ---- Memory / ,/
Disk
"--
In use
Plotted
Data
---- ...
Monitor Console
II

'-- Display
Menus ------ ... Scope

- EXPORT
SHARER
PrJ.vate
r
'--Raw
Data
---- Plot

Disk Files

r
Common Import Teletype
Files (Disk)

The plotting programs on the AGT/30 took information from the

CDC 6600 in the standard plotting package formats in use. Thi:
allowed quick demonstration of the display for programs alread:
using plotting and also provided reduction in conversion prob-
lems.

9. Functional Capabilities
The user at the AGT terminal (and also using the SHARER tele-
type terminal) could perform these functions:
a. Create, manipulate, edit, and delete CDC 6600 program
and data files.
b. Initiate a CDC 6600 job from the terminal.
c. Interact with his CDC 6600 program while it was run-
ning through SHARER.

110
 d. Dynamically display 2-D and 3-D graphical data on the
AGT scope that is generated by his CDC 6600 program
using the Numerical Plotting System (NPS) or the Gerber
routine GDRFT5.

e. Rotate, translate and scale the displayed data.

f. Obtain a hardcopy of his displays via off-line plotter.

g. Load programs through the card reader.

It should be noticed how confusing the definition of "interac-

tive" became with versions of this system. Programmers tended
to say the system was not interactive since they knew the data
flow. But "interaction" took place on several levels:

a. With the program directly through SHARER (programs

could have new routines added for output during cal-
culation, for example).

b. With the display on the scope, direct action through

the devices like the joystick (which controlled rota-
tion, translation and scaling).

c. Through the AGT/30 program, to choose a new menu

(organized tasks) or select other data, etc.

It was expected that extensive use of the system would aid in

generalizing about the proper separation of functions between
the 6600 and AGT/30 programs.

10. Schedule

The original schedule slipped due to delays in ordering/eval-

uating/delivering the equipment. However, once installed, the
tasks were completed at the rate initially planned. The sched-
ule of events is shown below:

Design SHARER AGT/30 Evaluation

Objectives Use Delivery

1 1 ~ yse

1967 1968 1969

11. Experimenta~ Use

An earlier assumption was that the flow of documents des crib-

111
ing the functions available and the participation by the vari-
ety of people from the engineering and other groups would serve
to excite the engineering staff enough to attract considerable
enthusiasm and interest. However, it was not realized to what
extent the engineering staff's time was scheduled. It was qUitE
difficult to attract engineers to invest their time (which had
to be almost supplemental to their normal work) on a facility
for which there was no long term commitment. And their jobs de-
pended on successfully completing commitments. Unfortunately,
is often easy to say to an experienced engineer that he should
change his analysis techniques, without realizing that emotion
and habit are part of the process. And he may be cautious for
good reason since it is often more important to do something
that will work at a higher cost than to risk the consequences
of holding up an engineering schedule.

A free use period of four hours a day provided one incentive,

and the applications investigated included two-dimensional plot!
of output from MIMIC programs (simUlation of an analog computer
structural .analysis for design of wings using two-dimensional
displays, two-dimensional plots of pressure distributions,
three-dimensional display of SST structure, two-dimensional
plots of stress versus shock flow, two-dimensional displays of
supersonic engine inlet design, two-dimensional air-foil cross
sections and camber lines which could be superimposed to form
a 3-D wing.

Some of the applications showed the value of providing the com-

mon plotting programs. Programs could be demonstrated in a day
occasionally on the scope, and this ease of use satisfied our
original objectives. That objective was important because it
would have cost too much and taken too much time to redo engi-
neering design programs--even if desirable. However, analysis
of benefits other than flow time generally proved intractable.
It was difficult to equate the flow time with out of pocket
dollars saved. The engineering manager is asked the question:
how much can your budget be reduced due to these new services?
Few people are prepared to answer that question. Some general
attempts were made to analyze the whole engineering design cycl
These studies showed that large amounts of time in a design
cycle were spent iterating through the computer, isolating and
correcting data errors prior to analysis. In the design of a
wing, for instance, two-thirds of the cycle was spent correct-
ing data for structural analysis programs. And this kind of
problem looked like one where the scope and man provided a
sizable reduction in flow time, since the man could inspect a
pattern for errors far faster than examining columns of numbers
This symbiotic relationship between man/scope/computer is amos
adequate distribution of functions. Man is best at finding
patterns.

112
Also, this brought the problem of cost justification to the right
level: if the wing design cycle could be cut by x days, how much
would it be worth? With engineering schedules tighter and tight-
er, the problem of cost justification could return to the chief
engineer--who makes the critical resource allocation decisions.
But that investigation did not provide a production commitment
for the graphics terminal.

And, as a reminder that the study of anatomy is more difficult to

do on a living organism, the graphics project was terminated in
April of 1970. Boeing Company financial problems (familiar to
those concerned with the airplane industry) caused a very sharp
razor to be used to make immediate cash savings. And the devel-
opment and experimental period, while developing useful applica-
tions, did not yield any production commitments. Individual
engineers were enthusiastic, but the resource problems forced
the decision to lay aside the potential at the Commercial Airplane
Division. The delay at the start was crucial--but was the
accepted risk.

12. Conclusions

Hardware

The special facilities provided by the hybrid array and digital

computer were used in about 20% of the applications. And the
isolation of these functions provided a potential for multiple
display that was not investigated. An added function for draw-
ing arcs would have been useful in order to reduce the number of
individual vectors generated. With the system as implemented in
use, about 2,000 vectors was the maximum number without flicker.
New cheap displays might meet the simple class of plotting and
engineering analysis well enough. Complex displays still require
large leverage on the benefits.

Design Approach

The functional split between the terminal and major computer

worked, and use of the SHARER system provided an easy breadboard
version of the system. However, many users could not tell what
problems were basic to the approach versus which were just tem-
porary aberrations of the crude initial versions of the software.
It was important that a member of the design team worked and sat
next to the system during the application development use in or-
der to catch the unfiltered impressions and ideas.

Many users hesitated to ask for changes because they tried to

113
judge how complex they were, rather than asking the designers.
And, sometimes extensive looking modifications or additions to
the functions were simple (and vice versa).

Management
It will be important to point out that the problem faced was
that of inserting into the normal working process for engineer-
ing (which is not clearly defined) a new tool. There was a
much greater lag than expected, and the project's loss of
time proved crucial. Do not underestimate the time lag from
functioning to production.
The organization of the project allowed schedules to be met
and a large number of people to know about and influence its
development. The separation between programmers, applications
groups and the engineering staff enlarged the time and encum-
bered communication. The engineering staff needs to be a part
of any project which is building a tool for its use. As in
other situations where innovation is necessary, an engineering
graphics fanatic was needed to present forcefully, in engineer-
ing terms, the need for change.

ACKNOWLEDGMENT
I would like to express my thanks to the members of the Graphics
Team at the Boeing Company who devoted their technical efforts
and emotional resources to a difficult task.

114
 COMPUTER GRAPHICS IN THE DYNAMIC
ANALYSIS OF MECHANICAL NETWORKS
M. A. Chace
M. E. Korybalski

Concomp Project, University of Michigan, 611 Church

Street, Ann Arbor, Mich. 48104, U.S.A.

ABSTRACT

Computer graphics is particularly appropriate for

studying the time response of two-dimensional mechanical

dynamic systems. This paper discusses the interactive

use of a DEC-338 graphics terminal for input and display

related to a generalized FORTRAN IV applications program

named DAMN--Dynamic Analysis of Mechanical Networks. The

DEC-338 is remotely timeshared to the University of

Michigan IBM System 360/67 central computer, operating

under the MTS timesharing system.

1. INTRODUCTION

This paper deals with the use of computer graphics in

an attempt to apply computer-aided design to realistic

machinery. Here the term machinery denotes mechanical

machinery, including devices as high-speed card punches,

115
automotive suspensions, washing machines, tractor back-

hoes, and control linkages. Approximately one tenth of

all engineers are concerned primarily with design of this

class of maChinery!l)Characteristics of realistic machin-

ery include the following:

1. Large scale multi-dimensional movement. In con-

trast to the vibration of structural systems, the

time response of machinery may involve transla-

tional movements comparable to the size of the

machine itself. Angular coordinates may move

through complete rotations. Typically these

displacements occur in multiplanar two-dimensional

space, although often machinery is designed for

motion which can only be described three-dimen-

sionally.

2. Detailed constraint. Most realistic machinery does

not conform to the lumped mass-spring-damper model

used to explain vibration. Typically parts are

interconnected, not only by elastic and damping

elements, but by other parts as well. These part-

to-part contacts frequently form complicated loop

structures. Moreover the contacts themselves are

varied. Some are essentially simple hinges or

keyways and are fixed in location relative to

the contacting parts. However, others shift

116
 location throughout the motion of the machine.

An example is the contact between a cam and a

follower.

3. Multifreedom dynamics. Despite the extensive con-

straint present in machinery, it is still necessary

to regard it as having more than zero degrees of

freedom. (The classical approach to machinery

involves just this assumption--that machinery is

kinematic in nature, with zero freedom once all

input motions are specified.) Multifreedom be-

havior may be introduced by elastic elements such

as timing belts or flexible beams, by motors which

lack the power to bring the machine almost instantly

up to speed, or by unusual interaction of a normally

rigid system (automobile crash).

4. Nonlinear elements. Typically the elements of

realistic machinery are not ideal springs and

dampers but instead such items as bushings or

pneumatic elements. For large scale motion, these

cannot be represented in a single linear model.

5. Intermittency. Often a machine will change its

structural identity, perhaps irregularly, at times

during its motion. Higher pair contacts may open

because of inertial loads, or parts which are

normally fixed in position may begin to move due

to overload.
117
 6. Multidisciplinary designs. Mechanical designers

tend to actively couple electronic, optical, fluid,

and other diverse elements in their machine design.

7. Additional. Other deviant characteristics of

machinery will typically be observed according

to the product with which a machine is associated.

For example, thread manufacturing machinery has

parts which, in effect, change mass with time

as more thread is wound onto a spool.

Effective computer-aided design of any type of engineering

system requires at its foundation a generalized program which

will accept not only changes in the values of the para-

meters of a specific device but will also accept changes

in the identity of the device itself. As suggested by the

foregoing characterization, the development of a true general-

ized program for computer-aided design of realistic machinery

is an imposing task. In fact, the program discussed in this

paper is somewhat more limited than the ideal. It accommo-

dates large scale motion but only for two-dimensional systems.

This, however, sets it apart from most dynamics programs de-

signed for the study of vibration. It accommodates the con-

straint of part loop closure and therefore applies to two-

dimensional kinematic systems such as those covered by KAM(2)

and the generalized matrix kinematic programs written at

. . (3)
Northwestern Unlverslty. KAM and the Northwestern

118
program cover three-dimensional systems also, but do not

extend to dynamics. Because of problems of detail, the

present program is limited in covering higher pairs and

nonlinear elements, and has reasonable limits on problem

size. But it does provide a working basis for a large

fraction of computer-aided machine design. The program

algorithms were aimed toward a system representation for

machinery similar to that which has been so successful

for electrical and structural systems. Because of the

complexity previously cited, a complete, consistent

identification with either network state variable tech-

niques(4) or bond graph(5) techniques has not yet been

made. However the identification is sufficiently close

that the program has been named DAMN (Dynamic Analysis

of Mechanical Networks).

Computer graphics is a most helpful adjunct in applying

the DAMN program to machine design. Graphic output allows

the designer a very rapid appreciation of the relation of

the several problem coordinates as they perform in two-

dimensional space. He can immediately sense the phase

relations, accelerations, possible interference problems

and other features which are obviously difficult to inter-

pret from a collection of individual plots of the variables.

Because of the effectiveness of graphic output there is an

increased emphasis on the worth of an interactive capability

to the designer. The program has been designed to allow

119
immediate change in either the parameters defining the
design of a specific system (masses, stiffness coefficients,
geometric lengths, etc.) or the topological data which
distinguishes one system from another.
Figure 1 shows generally the relation between program,
remote graphic input/output, the University of Michigan
central computer facility, and the DAMN program itself.
The DEC-338 display terminal of course includes a PDP-8
computer connected to a graphic display unit. This is
connected in full-duplex mode over normal telephone lines
to another computer, also a pDP-8, modified for communi-
cations use and termed the Data Concentrator. In effect
the graphic terminal can communicate with the DAMN pro-
gram at any level for flexible simulation of a specific
device or set of devices. The DAMN program itself is
written entirely in FORTRAN IV. It is resident on disc
storage at the University of Michigan computation center
and is executed on the University's IBM 360/67 computing
system(6). The graphics output program also shown is
written primarily in FORTRAN IV, but is importantly de-
pendent on the DF Routines written by the Concomp Project
for the support of the remote graphic terminal. (7) At

present, light pen input is not used in a major way.

Instead desired parameter changes are typed in from a
teletypewriter unit on line to the DEC-338 display termin-
ale

120
 ,--. -
6A."t""'C-\-\
I,
I
I I
I I
I
I
ITOPOLQG\CI!I..L I '?\40We:. L\We.
t.-,\ O\.)\~" tQPQ\...DG'C~""-- - ~ C.O)..J \....\E:c...\ \ 0\-..1
PROGR.b.N\S DA\"A / '\. I
\
DA.TA I D\'S'PLJI...'I
Ic.o\.jct.\Sn~.".,,\C' crE'R "-\ \ \..l A.\-.

YOD\\='{ '" / I
DIME.\o..1SIOt..lA.L
'DA..\A. )--...... _ ~
I R..E"'10TE. GRAP\-\\C
"\"6 R",,\ \ "'-l ~L
I
I
GRA.'?\-\\C. S
I
'-(B~
OUTPUT I
PRoOG'RA.N\
l
I I
Figure 1. Flow diagram of opera-
I tion of the DAMN Program in graph-
I ic output mode. The display ter-
EVALU..b..TE I minal is remotely connected by
I '---~I "'-lE>CT - 5\1:.. P voice grade telephone lines to the
I computing center where the program
I ACC.~L~'C.A.\\()\J itself is run. Data communication
....
t-:I
is performed by a modified DEe-B
.... I I computer, termed the data concen-
~ trator.
L-------
 The DAMN program was created as part of a project
sponsored primarily by the Ford Motor company for the

computer analysis of mechanical dynamic systems. The project

was substantially assisted also by the Concomp Project, itself
sponsored by the Advanced Research Projects Agency of the
u.s. Department of Defense. The DAMN program is viewed as
a prototype program useful to students for gaining an appre-

ciation of comp.uter-aided design of mechanical systems and

revealing the worth of analytical methods and computer
characteristics for subsequent programming of a more ad-
vanced, comprehensive system. However, experience with
DAMN to date has been very favorable, particularly the
level of detail and speed with which the response of
mechanical system~ can be determined, and the character-
istics of graphic display of mechanical systems.
In Section 2. the analytical background and program
structure of DAMN will be reviewed more specifically.
Section 3. will detail the graphic programming and system
facilities and discuss experience with specific machanical
systems which have been simulated in graphic computer runs.

2. BACKGROUND OF PROGRAM

2.1 Constituitive Elements

The DAMN program is designed to represent machinery
systems by a simultaneous set of second order ordinary
differential equations. The essential progr.amming problem

122
is the development of the coefficient terms in these equa-

tions regardless of the machinery system that has been de-

fined to the program via the input. To facilitate this a

lumped parameter view of machinery is taken, in which

machinery is seen to consist of eight constituitive elements:

(1) Parts. Rigid, inextensible objects of zero or

finite size, mass and moment of inertia.

(2) Fields. Conservative or non-conservative forces

applied between one part and another.

(3) Generators. Motion sources, inputinq either a

rotational or translational motion.

(4) Rotations. Contacts allowing a single degree

of freedom of rotation of one part relative

to another.

(5) Translations. Contacts allowing a single degree

of freedom of translation of one part relative

to another.

(6) Markers. Points, unit vectors or the combination

of a point and unit vector, fixed translationally

or in orientation relative to a specified part.

(7) Keyed Assemblies. Assemblies of one or more

parts related entirely by translational contact.

(8) Loops. Sequences of parts and contacts forming

an independent closed chain.

All data input to the DAMN program is categorized under the

first six elements. Categorization under the elements

123
 "Keyed Assembly" and "Loop" is made internally by the
program, but the user is not expected to recognize these
elements themselves. The user also specifies the output
he desires in terms of the relative displacement, velocity
and acceleration of selected pairs of markers. The program
is being developed to also compute reaction force at rota-
tions and translations.
Based on the data input in the preceding categories
the program constructs a set of second order ordinary
differential equations and numerically integrates these
through the range of time specified by the user. In
general, numerical integration is a slower process than
the direct, algebraic computation ordinarily possible for
kinetn.atic syetel,lls, but it is a practical necessity
for large nonlinear systems. Most of the equations con-
structed correspond to Lagrange equations. One of these
is constructed for the angle of each keyed assembly in the
system, and one for the displacement of each translation.
Thus, the coordinates for two-dimensional mechanical sys-
tems are chosen as keyed assembly angles and translational
displacements. Additional differential equations are
created to represent constraint.

2.2 Definition of Constraint

Figure 2.1 shows a revealing though very academic
example of a machine. The coordinates for this system

124
 /
/

~,

{
/ i- - e '\/ ~r-~~a
\
\ I
'- I
/
/
~/
"j

/
\ /
\. /
...... - -- ./

Figure 2.1. Schematic of a hypothetical machine in terms of

constituitive elements. A closed loop is formed by three keyed
assemblies, each circumscribed by a closed dashed line. The
keyed assemblies are connected by rotations (pin joints). 'In
this example within each keyed assembly there are two parts
connected by a translation (keyway joint). In later schematics
translations are denoted more conveniently by small triangles.
The angles 6 2 and 6 3 shown are the angles of the keyed assem-'
blies relative to ground.

are the angles of the two movable keyed assemblies 2 and

3, plus the three translational coordinates sll' s2l' and
s3l. For any situation of forces acting between the parts
in this example, the system is dynamic with three degrees
of freedom. However, the fact that the parts are connected
in a closed chain or loop means that the coordinates are

125
 interrelated by the following equation:

(I)

-+
Equation (I) simply states that the sum of part vectors r
and translation vectors ; around the closed loop is O. The
A A

components of this equation in the directions i and j

correspond to two scalar equations in the coordinates 8 2 ,

83' s2l' s3l' and sll. When the problem of Figure 2,1 is
represented by DAMN, the second derivative of the components
of equation (I) is included as a pair of constraint differential
equations supplementing the Lagrange equations.
As a limiting case the constraint conditions are the
conditions normally used to solve kinematic problems (zero
degree of freedom). For example, in Figure 2.1 if the slips
s2i and s3l are prevented and the angle of keyed assembly
number 2 is specified as a function of time, the system becomes
kinematic slider crank mechanism, as shown in Figure 2.2. In thj

case only the constraint equations are necessary to solve the

system, either by direct evaluation of algebraic equations as
equation (I), or by numerical integration of a derivative of
equation (I).
For a program to simulate three-dimensional machinery
another basic constraint condition must be included--specifi-
cally the condition of angular constraint around a closed
loop of keyed assemblies.

126
 I
/ -
I
( 3

{
/' -- ---
2
-.......
'"
J

,/

' - - -...-/ /

--
\

'" --
/"

'" /
/

I
-
/'
\ /
,---
Figure 2.2. Schematic of a kinematic slider-crank mechanism.
In this example enough freedom is removed ~rom the loop~ig­
inally shown in Figure 2.1, that the constraint condition it-
self (equation (1» is sufficient for determination of system
time response, given an input of 82 versus time.

2.3 Dynamic Conditions--Lagrange's Equation

The dynamic condition on which the DAMN program is based
is the Principle of Least Action, or Hamilton's Principle.
As applied to mechanical systems this states that a system will
respond so as to minimize the integral over time, of the work
due to all effects, by the surroundings on the system. In
equation form this condition is presented as the variation of
an integral equal to 0:

127
 o f otW{q.
.
,q. ,t)
].]. = 0 (2)

By use of variational mathematics this condition is developed

to the following set of differential equations, one for each

coordinate qi.

i = 1,2,3 •.. m (3)

Here, the work W done by the surroundings on the system includes

kinetic and potential energy effects, plus effects due to non-

conservative forces such as those of damping. Ordinarily

these are ~he only effects considered. However, a basic

assumption of equation (3) is that the coordinates qi are

independent. Because of the loop constraints mentioned in

section 2.2 this condition is not normally met by the coord in-

ates recognized by DAMN for machinery systems. To overcome

this difficulty the loops are treated as broken for purposes

of Lagrange's Equation. Formally, the coordinates q.]. are

therefore independent as required. However, the Lagrange

Equations thereby produced are accompanied by second order

loop constraint equations which as a practical matter insure

that the loops remain closed. Also the work terms in the

Lagrange Equations now include Lagrange multiplier terms for

each component of loop constraint. These have the form ~,¢.

J J
where the ~j are reaction forces and the ¢j are loop constraint

128
functions. The ultimate form of Lagrange's Equation with

constraint is the following:

d [
a(T-V- In
j=l
A . <p • )]
J J
a(T-V-
2n
I
j=l J J
A. <p • )

Q. (4 )
dt '.
aq. aq.1.
=
1.
1.

m{d
t.
d
crt [a~m~
ae.Q,
-
aT
m
°.Q,m
I
m
e
m
+
m . 1
1=
1
~
j=l
e.
1
-+
b.1
ae.Q,

e. 2 (b.
1 1
A A

x k) + s .. (s .. x k) + 2 s .. e. (s .. )
1J 1J
A

1J 1
A

1J lOb~)
(5 :

t.
aT
d
crt
m
= m ([
m
~
E e.(kxb.)-e. h.
' 1 J. =1 1 1 1 1
1.. A -+ • 2-+

1=
(6 )

e.1 (k .. )]O;o)
~1
A

+ s .. s .. + 2 s .. x
1J 1J 1J J;vP

As it stands Equation (4) is difficult to program for

general application. What is instead required is a set of

relations directly of the form of second order ordinary

differential equations. The principal problem here is the

complicated set of operations performed on the kinetic energy

terms. By viewing a mechanical system in terms of its

constituitive elements it is possible to determine general

expressions for the Lagrange equation kinetic energy terms,

for the mass of one specific part, part m. These expressions

are the following:

129
Figure 2.3. A chain of keyed assemblies from ground to the
center of mass of a particular part. In constructing the
Lagrange equation kinetic energy terms for each part m (equa-
tions (5) and (6», summations are made over the chain of
keyed assemblies to the part center of mass, and over the in-
dividual translations wfthin each keyed assembly in the chain.

These relations are especially interesting when the resemblance

is noted to' the general expression for the second derivative
of a .
s~ng
1 e vector, +r.

130
 + -
•• A A A
(7 )
r = e(kx~) .2~ + r r + 2r8(k x r)
In Equations (5) and (6) the summation over ~ is a summation

over all the keyed assemblies in a chain from ground to the

part whose mass is being considered. The summations over

j are summations of translational terms within a given keyed as-

sembly i, included in the chain mentioned. Figure 2.3 illustrates

-+ •
the elements involved in this summation. The vectors b i are pos~-

tion vectors which span the ith keyed assembly, from the contact

at which the chain enters to the contact at which it leaves. Two

equations are required, (5) and (6), because the Lagrange Equa-

tion must be written both for coordinates which are angles of

keyed assemblies 8~ and coordinates which are-displacements of

translational contacts, s~p.

As far as the assembly of inertial terms is concerned,

at each integrating step DAMN polls each part having finite

mass and accumulates coefficient terms as defined by equations

(5) and (6).

The other terms in equation (4) are much easier to

evaluate. The Lagrange multiplier terms A. '¢. result in a

J J
matrix of coefficients which is exactly the transpose of the

matrix of coefficients obtained in a second order constraint

condition. Forces due to potential energy effects (operations

on V) are simply included in the collection of nonconservative

force terms Q .. Table 1 shows the construction of the force

~

terms, differing according to whether the Lagrange equation

131
 Table 1

Form of the Generalized Force Terms

in the Lagrange Equation

Type of
Applied Displacement Angular
Force Coordinate, Stp Coordinate, 0 t

Translational
-+
F • '"
S
Force k tp

Rotational
Force (torque)
Zero

-+
F,k. - kth actual applied translational force in the SystE

-+
tk - kth actual applied rotational f.orce (torque) in thE

system, applied between a pair of parts i and j

0£ - angle of the £th keyed assembly

5 _ the pth translation within the £th keyed assembly

£p

l32
coordinate is angular or translational and whether the actual

applied force is a translational force or a rotational force

(torque) •

The forces included in the Q.1 term are distinguished

as being displacement or velocity dependent, not acceleration

dependent. This term therefore includes spring forces,

damping forces, and any other force whether linearly or non-

linearly dependent on displacement and velocity. One standard

force type available in DAMN is a "wall force" which has

magnitude zero until a specified pair of points thought of as

the terminals of a force field move within a distance com-

parable to an integration step of each other. The force

function then increases very rapidly for very small decrease in

point separation. In effect the points are prevented from

exact coincidence. This particular force type provides a

basis for including a wide variety of intermittent mechanisms

and impact situations within DAMN.

At present DAMN is not organized to accept a complete

variety of one-of-a-kind forces. Such acceptance requires

allowing the user to input force functions in either subroutine

or tabulated form, certainly a feasible extension of the program

A similar restriction now exists for one-of-a-kind motion for

generators and part contacts dependent on surface profile.

When the reaction force computation capability is completed

DAMN will accept applied forces which are themselves dependent

133
on reaction force (Coulomb friction force). Meanwhile this

force type is excluded.

The essential form of the dynamic and constraint conditic

necessary to DAMN can be represented as an Equation (8):

All Al2 Al , Cll C2l · .. Cnl ql f1

C12 q2 f2
I
A22

motion
I. Lagrange multo
matrix
I coefficients

... .. .
Aml
Cll
-
C12
AJ Clm

Clml
Cnm
-~
Al
f

gl
m

C2l
."
A2 g2

constraint equation All zeros

coefficients

A
n

Here the differential equations are represented as a set of

simultaneous linear algebraic equations in the variables q.and

1

A .. The coefficient matrix is partitioned in four submatrices.

J
The upper left submatrix contains the coefficients A .. of the
1J
second order acceleration terms from Lagrange's Equation. Spe-

cifically these are radial and tangential acceleration coeffi-

cients. The main diagonal coefficients of this matrix are

constants and the submatrix is symmetric. However, the off

134
diagonal terms are nonlinearly dependent on problem coordinates,

specifically the angles of keyed assemblies. The upper right

and lower left submatrices happen to be the transpose of each

other, although the lower left submatrix is formed directly from

the second order terms of the constraint conditions, whereas the

upper right submatrix is composed of Lagrange multiplier coeffi-

cients from the Lagrange equations themselves. These coeffi-

cients are also nonlinearly dependent on the angles of the

keyed assemblies. The column vector of dependent variables in-

cludes the second derivatives of the keyed assembly angles plus

the second derivatives of the translational variables. The

lower subvector includes the Lagrange multiplier terms which

originate from Lagrange's equation. On the right is a column

vector of elements which themselves are large summations of dis-

placement and velocity dependent forces, applying to the partic-

ular Lagrange or constraint equation identified with their row.

None of these terms however are dependent on coordinate second

derivatives.

The actual integration process takes place as outlined in

the lower left of Figure 1. First, the initial conditions are

used to evaluate all of the coefficients in equation (8) at time

equal zero. Then Equation (8) is solved as a simultaneous set

of linear algebraic equations for the q's and the A's. In con-

cept the q terms are numerically integrated to determine corre-

sponding velocity and displacement, then fed back to compute the

coefficient terms in Equation (8) for a next step. At present

135
the integrating program used is HPCG (Hamming Predictor-Correc-
tor Generalized) available from the IBM Scientific Subroutine
Package (7) • The integration takes place in small steps with a
simultaneous equation solution in each step until a user-speci-
fied output increment is completed. At that time current values
of all problem coordinates are transmitted to the graphics out-
put program and processed there for immediate display, or if a
printed output has been elected, the results are stored on disc
until the end of the entire run, at which time they are printed
out.
The integration process outlined here is simple, but not
the most efficient process possible. For example, it is prob-
ably feasible to integrate without having to solve equation (8)
at every integrating step. Also, with this particular set of
variables and the Lagrange multiplier technique, the number of
differential equations exceeds the degree of freedom of the
system by the amount 2c, where c is the number of scalar con-
straints. Alternate approaches may, in fact, yield a smaller
number of equations in the set. However, the Lagrange equation
approach has been especially easy to interpret and free from
artificial singularity problems because of the close physical
correspondence of each of the Lagrange and constraint equations
For the size of problems considered so far (order 10 X 10) in-
tegration speeds have been more than adequate for analysis, as
discussed in Section 3.0. However, use of the program for com-
puter controlled synthesis will require at least an order of

136
magnitude increase in speed - probably feasible.

2.4 Relation of Topological and Dimensional Programs

~ careful distinction has been made between topological and
dimensional subroutines within DAMN. Here, the term
"topological programs" denotes those which determine informa-
tion which is independent of part dimensions, or any system
displacements or forces. A good example of a topological pro-
gram is the subroutine which determines the independent loops of
parts and contacts in an arbitrary machine system. The results
of this program are, of course, unaffected by the state of the
machine displacement. As shown in Figure 1, the program was de-
signed so that all computations which are topological in nature
are performed before the beginning of numerical integration.
The results of these computations are stored as integer informa-
tion in a set of program tables, termed plex tables. In essence,
one such table exists for each of the constituitive elements
defined in Section 2.1. These plex tables are held in memory
throughout both the topological and dimensional programs. The
information contained considerably increases the speed with
which coefficient values can be determined for the numerical
integration process.
The DAMN program is network-based in the sense that most of
the topological routines use network mathematics corresponding
closely to that used in electrical or structural analysis
problems. For example, the minimum number of independent part-

137
 contact loops is determined by processing a branch-node inci-

dence matrix where parts are interpreted as nodes and contacts

as branches.

3. GRAPHICS SYSTEMS AND APPLICATIONS

3.1 Systems Viewpoint

DAMN is a set of FORTRAN IV subroutines which are ex-

ecuted in either batch or timeshared mode on the University's

IBM 360/67 central computer. All such programs are under the

control of a supervisory program named UMMPS (University of

Michigan Multiprogramming System) which supervises a time-

sharing monitor, MTS (Michigan Terminal System), and an aux-

TABLE 2

Functions of the Supervisory Programs of the

The University of Michigan IBM 360/67

UMMPS (University of Michigan Multiprogramming System)-

The system program which supervises the timesharing
system. Inaccessible to the general user. Inter-
faces the 360 hardware to MTS. Controls the loading
and execution of user's programs and I/O and process
interrupts.

MTS (Michigan Terminal System)- User-oriented system pro-

gram. Contains assemblers, translators, and system
programs which are accessed by a user by issuing the
appropriate command. Monitors both terminal and batch
jobs.

HASP (Houston Automatic Spooling Priority System)-

Interacts with UMMPS to assign priority to batch jobs
for effective execution of programs. Control is even-
tually passed on to MTS to actually execute program.
Inaccessible to general user.

138
iliary batch monitor HASP (Houston Automatic Spooling Priority

System). HASP assigns priorities to batch jobs. In general,

the user does not have access to UMMPS or HASP and must com-

municate to the central computer through MTS by means of the

MTS command language~8) Figure 3.1 shows the interrelation of

these programs to the user. Table 2 outlines the important

functions of UMMPS, HASP, and MTS.

Currently MTS can service about 75 users in a timeshared

mode. For maximum efficiency, batch jobs are first assigned

aopriority by HASP. These are then passed to MTS, highest

priority first, for execution. Batch jobs are processed by

three IBM 2540 card read-punch units, one IBM.2501 card reader

and five IBM 1403 line printers. Terminal jobs utilize stan-

dard IBM and AT&T communications equipment and are serviced

by one IBM 2702 and one IBM 2703 communications terminal.

In the U of M communications network, a special control

unit named the Data Concentrator can be accessed by any terminal

user. The Data Concentrator is itself a PDP-8 computer contain-

ing four 4096-word banks of storage and a 1.5 microsecond ac-

cess core memory. It is controlled by a supervisory program

called RAMP. The Data Concentrator was developed to adapt

special terminal equipment to the timesharing system, and its

applications include interfacing certain non-IBM special-pur-

pose communications equipment to MTS~9) For DAMN it interfaces

a DEC-338 CRT display unit to the central computer making

possible the graphic display feature. Teletype communication

139
 CEWTR.A.L
COfV\PUTEr.2.
(3CoO I ~-,) -
~

"

UMMPS !if. - -.-.--;.-----~-.--,

,
,,
I

,
~
I

1
MT5 ~A.:5P

~- ~

TERM1WAL 'BATC\4

PiCj\lre 3.1. Relation of U of M system softwaee in the exe-

cution of batch and timeshared jobs on the 360/67 central
computer. Terminal jobs are executed according toMTS com-
mands. Batch jobs are first assigned a priority by HASP,
then executed in timeshared coordination with terminal jobs.
Overall control, is accomplished by UMMPS.

140
to the central computer through the Data Concentrator is es-

sentially the same as through the IBM equipment.

3.2 The Graphic Terminal

The graphic terminal used for DAMN output is a DEC-338

CRT display. The U of M Concomp Project developed the neces-

sary support routines to interface the DEC-338 to the central

computer. A user communicates with the central computer over

voice-grade telephone lines by means of an AT&T 201 data phone.

This configuration provides the user with some of the speed

advantages of the central computer, coupled with t e medium-

cost graphics ability of the 338.

The 338 also serves as a remote graphics terminal time-

shared to MTS at the Ford Motor Company in Dearborn, Michigan

(25 miles distant), and the Whirlpool Corporation in Benton

Harbor, Michigan (160 miles distant), These terminals have

the same capabilities as those located at the University and

provide industry an unusually direct association and utility

with programs of their interest, such as DAMN.

3.3 Description of DF Routipes

Also developed by Concomppersonnel was a comprehensive

set of FORTRAN-callable subroutines named the DF routineJ10)

(Display File routines) which, when executed on the central

computer, construct DEC-338 code to draw lines, display

labels, and recognize figures through light pen detection.

After construction, the code is transmitted through a 201

141
 data set to the 338. Then the 338 displays the file until

a change is initiated by the user's control progEam. In con-

structinga display file, control program tasks include Xl)

creating a construction buffer, (2) constructing figures by

use of lines and labels, and (3) transmitting the file with

an appropriateaame.

Other applications of the DF routines on the graphic ter-

minal include construction of surfaces, design of electric

circuits, and simulation of arterial fibrilation. The DF

routines are also used by a number of computer orien.t:eQ

~ourses at The University of Michigan. Table 3 gives a brief

description of the DF routines used by the DAMN program.

3.4 DAMN User Graphics Options

The primary objective of the DAMN graphics output program

is the construction and display of a schematic diagram of a

mechanical system. For this purpose the DAMN user specifies

the lines, symbols, vectors, and title to be drawn, and the

output program calls on the appropriate DF routines. The DAMN

. user has the option of defining whate~er lines, vect~rs, or

symbols he wishes. Other information which must be specified

in the data are seale factors and a time increment

which determines when the next frame will be shown. The op-

tions available to the graphics user and the information re-

quired to generate the display are summarized in Tables 4 and

! respectively.

142
 TABLE 3

Definitions of DF Routines used in the DAMN

graphics output program

DFINI Initializes construction buffer in central computer.

All code generated by subsequent calls of DF Routines
will be placed in this buffer (display file).

DFXYC Draws one line in display file.

DFLAB Constructs one label in display file.

DFOCT Inserts a user specified four digit octal number into

construction buffer. Used by graphics output program
to change intensities of lines.

DFPJM Allows a program to push jump or calIon a display file

which is defined as a subroutine. In the graphics out-
put program there are three symbols which are defined
in this way.

DFaOl The subroutine to transmit the display file over the

AT&T 201 data phone to the DEG-338 and display.

DFSN Erases the DEC-338 screen.

3.5 Organization of Graphics Output Program

Figure 3.2 is the flowchart for the graphics output pro-

gram and Figure 3.3 shows example output. To construct the

frames, the DAMN graphics output program uses two display

files. Static labels such as the title and headings for velo-

city, acceleration, and time are placed in the first display

143
 o
?

f{J
IJ1
)-

l- I- 2'
v UJ-I!
4 uJ
~ ~ j ~O5~
I!lo
W ~ ~
0 t ~~~~
n! Q 2 :ZLflIOIi-
0
V
~ o ?
U W'>

144
 "-.10
c.O\..J"5."fR.\..lCT
L\~"E'5

+
CO\-..ls-r~ucti !
VEC",\OR.
i
i ~'e:,t::..tJS j
!

CO"-JSTRUC
\...10
TABLE.

SC.t:....L"E:
'Ve c.","\ OR-5,
C.CM?UTE
MAG.~\T\.lDE
i

Figure 3.2. Flow chart of the

graphics output program. Program
TA.'i3U LA.'S.
flow on the left represents the con- 'J'E c...\:"o~
struction and transmission of stat- t-.l\A..<s'~ \TU D~
ic labels. These labels are con- *- -n"4~ T
I
structed at the first output step
and are branched over on subsequent
output steps. Program flow on the
right represents the construction ~\.. \.). 0 .. \ ) .
.... of each frame. ~ "-"'-I . .-
r----~
~
file. As an example, labels are shown in Figure 3.3 in

the upper right side of the frame. These labels are con-

structed, transmitted, and displayed on the first pass of the

output program and are branched over on subsequent output

steps. Also constructed in the first pass are the three sym-

bols (), ()and ~ and the labels for the vector heads. The

vector heads are constructed by concatenating the EBCDIC

marker identification number to the EBCDIC letters A and V

and placing the result in an array.

Figure 3.3. Example graphics output. Rigid parts are repre-

sented by straight lines or polygons. Any number of velocity
and acceleration vectors can be shown. In this example two
velocity vectors (symbols V3 and V5) and two acceleration
vectors (symbols A6 and A7) are shown. Generators and fields
are not displayed.

146
 TABLE 4

Graphic Options and Description of Output

Available to DAMN User

Lines- There are two types of lines, dark and light intensity.
By convention dark lines or a polygon of dark lines repre-
sent rigid parts and light lines represent axes, springs,
paths of translation, or any line which is not descriptive
of a rigid part. A line is input by specifying its two
end point markers and its intensity.

Symbols- The user has available three symbols: a 1/4" circle,

a 1/4" circle crossed in the middle, and a 1/4" triangle.
In this program the crossed circle represents a rotation
which contacts a moveable part to ground, a circle repre-
sents a rotation between two moveable parts, and a tri-
angle represents a relative translation. The symbol
positions are defined by specifying the marker I.D.
number for the marker at which the symbol is fixed.

Vectors- Velocity and acceleration vectors of any marker rela-

tive to ground can be displayed.

Title- A title of up to 48 characters can be displayed.

The second display file contains the lines which describe

the parts in the system, symbols, and velocity and acceleration

vectors including their respective magnitudes. The position

of the lines (parts) and the direction and magnitude of vec-

tors change with each frame and must be redrawn after each

output from the main DAMN program. The output program con-

structs the system by recognizing key markers, such as end-

points of lines, relocating these markers relative to a base

ground marker, and scaling all markers down to screen size.

147
 TABLE 5

Description of Data Necessary For Generation

of DAMN Graphic Display

Base- The user must specify the ground marker I~D. number de-
fined in the analysis data and its position on the screen.
The ground coordinates of all other markers are referencec
to this.

Scale Factors- Scale factors are required to predict the maxi-

mum dimensions of the system, and the-velocity and accel-
eration vectors.

Time Increment~ The interval of time between display of each

new frame must be specified.

The output program then calls appropriate DF routines to draw

the specified lines and symbols. As an example, Figure 3.3

is a schematic of a compound pendulum of two links. Two lines

were drawn to describe the links and two symbols were drawn to

represent rotations between one link and ground and between

the two links, respectively.

The output program must also construct velocity and ac-

celeration vectors if any are requested. Examples of velo-

city and acceleration vectors are shown in Figure 3.3. Again,

the output program must recognize, relocate, and scale the

motions of key markers. The magnitude and direction of the

vectors are computed in the main DAMN program and the output

program has only to scale these vectors and calIon the ap-
propriate DF rout~nes. Additionally, the output program must

1~
access the EBCDIC label for vector heads and call a DF routine

to add them to the display. Magnitudes of vectors must also

be converted from floating point numbers to their EBCDIC

Figure 3.4a. Three-dimensional view of a two-link compound

pendulum moving in a gravitational field. Part 1 is ground
and parts 2 and 3 the two links. Both parts 2 and 3 have
appreciable mass and moment of inertia, and undergo arbitrar-
ily large displacements. This is a two-freedom unconstrained
dynamic system.

equivalent and tabulated on the upper right-hand side of the

screen. Finally the second display file is transmitted to

complete the process. The output program then returns to the

analysis program to await the coordinates for the next output

step.

149
 3
Figure 3.4b. Two-d1mensional schematic of the compound pen-
dulum shown in Figure 3.4a.

The timing and quality of the display are highly depen-

dent on the number of options the user chooses, the number of
people who are timesharing at the same time, and the number of

dependent variables that the analysis program must solve. Aver

age timing experience is cited in the examples which follow.

3.6 Description and Examples of Output

Example 1 Two degrees of freedom, unconstrained, dynamic com-
pound pendulum.
Figure 3.4& shows a sketch of a compound pendulum with

150
Figure 3.6a. Automobile hood mechanism used in connecting hhe
hood to the body. The mechanism consists of six parts. Part
1 is the automobile body and part 6 the hood. A spring is
stretched across parts 5 and 6 and is sufficiently strong to
raise the hood from a near-horizontal position. The motion of
the hood is impeded by a rotational viscous damper (not shown)
between part land part 2. This is a single-freedom, con-
strained dynamic system.

151
Figure 3.6b. Two-dimensional schematic representation of the
hood mechanism of Figure 3.6a. Rotations (pin joints) are
represented by small circles; parts are represented by straight
lines and polygons.

two degrees of freedom. Each link has mass and moment of

inertia. The schematic representation of this problem is

152
F1gure 3.5. A series of photo-
graphs of the DEC-338 graphic
display screen taken during a
program run simulating the mo-
tion of the compound pendulum
shown in Figures 3.4a and 3.4b.
Velocities V3 and VS are
the velocities of the points
at the ends of the links; vec-
tors A6 and A7 are the accel-
eration of the centers of mass
of each link. Problem time
begins at t=O and is incre-
mented to t=.6 secs.
153
Cl1
~
-

Figure 3.7. A
of photographs of the
DEC-338 graphic dis-
play screen taken
during a program run
simulating the mo-
tion of automobile
hood linkage shown
in Figures 3.6a and
3.6b. The system
moves under the in-
fluence of a trans-
lational spring and
a rotational viscous
damper. Vector Vl7
is the veloci ty of
the center of mass
of the automobile
hood. Problem time
begins at t=O and is
incremented in ap-
proximately equal
steps to t=l.l sees.
shown in Figure 3.4b. Parts 2 and 3 initially have zero velo-

city and are acted upon by an unbalanced gravitational force.

Figure 3.5 is a series of photographs of the compound pendulum

as it is seen on the DEC-338. Labels V3 and V5 define the

magnitudes and directions of the velocities of the ends of

the links. Vectors A6 and A7 are the acceleration vectors

of the mass centers of the links. For this problem DAMN must

integrate a system of two second-order differential equations

to obtain the velocity and position of each link. The DAMN

output program draws two lines and two symbols, solves for

four vectors and their magnitudes, and displays 37 frames per

minute at approximately 25% MTS system load capacity.

Example 2 Automobile hood linkage

Figure 3.6 a. is a drawing of a simplified automobile hood

linkage, and a schematic of this linkage is shown in Figure

3.6"b. This linkage consists of five moving parts and ground

(part 1). Parts 2-6 all have mass and mass moment of inertia.

A spring is stretched between parts 5 and 6, with sufficient

strength to raise the hood. Also a torsional spring and a

viscous damper are placed between parts I and 2.

Figure 3.7 is a series of pictures taken at regular time

intervals during the motion of this system. As shown, the os-

cillation decays rapidly due to the damping. Only one vector,

the velocity vector V17, is shown, representing the velocity

of the center of mass situated at the center of the hood (oaly

155
the rear half of the hood is shown). A system of nine second-

order differential equations is solved as described in Section

2 and the output program displays 7 lines, 7 symbols, and the

velocity vector.

Figure 3.8. Photographs of the DEC-338 graphic display screen

showing other systems simulated by DAMN.

Figure 3.8a. A kinematic two-slider mechanism driven by a

constant velocity input motion. Vectors V7 and Vl2 are the
velocities of the sliders.

Other Examples

Figures 3.8a through 3.8d show other systems which have

been simulated by DAMN. These examples show that DAMN can

accept a wide variety of situations such as rotational and

156
translational contact, kinematic constraint, multifreedom dy-

namic systems, constrained dynamic problems, inertially-driven

problems, etc. These and other examples also showed that the

Figure 3.Sb. A one-freedom four bar linkage (no input mo-

tion). Each link has mass, moment of inertia and-anitial
velocity. Vectors VIO and AIO are the velocity and accelera-
tion of the mass center of the coupler.

number of frames/min. was more often dependent on data trans-

mission time than on problem integration time. Experience has
also shown that graphics is particularly useful in analyzing
systems which undergo large deflections and is less interest-
ing for small-scale vibration.

3.7 Man-machine Interaction

An additional feature of the DAMN graphics output pro-
gram is man-machine interaction through the use of an inter-
pretive conunand language. This is not yet fully developed,

157
 Figure 3.8c. A simplified two-dimensional automobile suspen-
sion system. The canted line is the frame, supported ver-
tically by two springs (not shown) one at each end. The ver-
tical line shows vertical displacement of the center of mass,
and provides a reference for a rotational damper (not shown).

Figure 3.8d. A two-dimensional simulation of a washing

machine. The rotating tub is represented as a sinusoidal oscil-
lator mounted on a base plate suspended from the frame by links.
The effect of an eccentric mass in the tub is represented by
specifying a mass for the oscillator.

158
but at present a user can interrupt the display at any point

and by issuing an appropriate command, terminate the program,

access a new data set, alter the display or change system

parameters. When the user wishes to modify the display he

first issues additional subcommands. Through these subcom-

mands he adds or deletes lines, symbols, or vectors, alters

scale parameters, and changes the frame increment. This fea-

ture allows the user to add a temporarily significant vector

for a particular interval of time and then delete it to sim-

plify the display. As planned, the command language will allow

the user to add or deleee fields or generators, and to alter

part geometry and field or generator parameters, then restart

the system and examine the effects of the change.

REFERENCES

1. Survey performed in 1967 by the Engineers Joint Council

under contract to the National Science Foundation.
Published in Engineer, March-April, ]969.

2. IBM Application Description Manual H20-0493, Program

Information Department, IBM Corporation, Hawthorne, N.Y.

3. Uicker, J. J., Jr., J. Denavit and R. S. Hartenberg, "An

Iterative Method for the Displacement Analysis of Spatial
Mechanisms", J. Appl. Mech., ser. E, vol. 87, pp 309-314,
1965.

4. Stern, Thomas .. E., Theory of Nonlinear Networks and Systems,

Addison-Wesley, Reading, Mass., 1965.

5. Karnopp, Dean and Rosenberg, Ronald C., Analysis and

Simulation of Multiport Systems, M.I.T. Press, Cambridge,
Mass., 1968-.-

159
 6. Carnahan, Brice, and Wilkes, J. 0., Introduction tQ Digita
Cgmputing and Fortran IV withMTS Applications, 1968 .
('Available from Ulrichs 800k Store ,Ann Arbo:r;, 'Miah:t.fJan).
7. IBM Manual H20-0205-2, System/360 Scientific Subroutine
Package, (360A-CM-03X) Version II.
8. MTS Manual, Computing Center, University of Michigan, Ann
Arbor, ,Michigan, 1967.
9. Mills, D. L., The Data Concentrator, Technical Report 8,
May 1968, 113 pp.
10. Cocanower, A. B., The DF Routines User's Guide, Memorandum
23, May 1969, 5 pp-.-- --

.Acknowledgment
The authors gratefully acknowledge the interest and finan-
cial support of particularly the Advanced Analytical Technolocn
Department, Ford Motor Company, and the ConcolJlP Project--itsel.f
sponsored by the Advanced Research Projects Agency of the U.S.
Department of Defense. The support of Structural Dynamics
Research Corporation and the Whirlpool Corporation is also
appreciated. The project would have been impractical.witho\lt
the hardware and systems software facilities of the University
of Michigan Computing Center and the graphic systems software
support completed by Dr. Alfred Cocanower and the staff of the
Concomp Project.

160
 STRUCTURED OPERATIONAL DATA SETS
FROM ARBITRARILY ARRANGED COMPUTER
GRAPHIC SYMBOLS
E. D. Berhold, M. P. Berhold
Dept. of Engineering, University of California, Los
Angeles, California 90024, U.S.A.
and
L. P. McNamee
Dept. of Engineering, University of California, Los
Angeles, California 90024, U.S.A.

Abstract
A method is presented for generating operational graphic and computa-
tional data sets from an arbitrary arrangement of symbols on a computer
graphic display console. Graphical data sets are formed by first develop-
ing the desired engineering symbols by means of the GRAF language, and
then structuring the symbol reference points, types, and identifiers by a
unique dot -grid display. Computational data sets are then formed by re-
lating the design parameters and computational steps to the graphical data
sets by assigning state points to the display of symbols on the CRT.
Also included is a description of how the data sets for an aircycle air-
conditioning application program are constructed and operated.
1. 0 Introduction: Data structures of graphic and computational routines
are usually developed separately, with very little attention given to a com-
bined program effort. (1) The techniques presented herein provide an effec-
tive means for generating the required data sets directly to enable the de-
signer to keep the overall program objectives in perspective.
The general approach is presented first. This includes a brief descrip-
tion of the GRAF language, the dot -grid routine, and the state point assign-
ment method, and their synergetic effect in constructing the graphical and
computational data sets. The application of these techniques are then illus-
trated by implementing an aircraft aircycle airconditioning system design
program on an IBM 2250 display unit that feeds into an IBM 360/91 digital
computer.
2.0 Construction of Graphic Data Sets: The construction of graphic data
sets, such as the array shown in Figure 1, calls for the definition and de-
velopment of the desired engineering symbols and the structuring of the
symbols to conform to a dot -grid pattern.

161
 (Aetu1. 51.. 18 SO br 13)

?3
- IIt'IIIaCI COCWlDADS PIIOOIWI ,LAGS STATE usm CODE COJlPOllEllT
PODiTS ATTQlTIOIiS 110 IIAMES

D~ PODiT OUfLl'f POll! ~

£-<
~£-< j ~ £-<
~ £-< 1&0
fs1 j!j ~ ~ 15
u ~ ~
Q
~ ~ ~
;
1&0
~ ~ ~ B
rl ~ fs1
I ~ l!i 8
~ ~ 0::
~ CIl ....
a a a s s ~£-<
0
~ CIl ...:
£-<
~ I 8
£-< :z; ~
CIl £-<
CJ)
! ~
u i ft ~ ~
£-< i ~ ~ 0::
I
~ ~ ~ ~
~
CIl
fil
U j!j ::> ;;'!
~ 0 8 8 ii!
1,2,
1 ),4 DUCTS

2 6 HI (Bl ••d 51de)

TURBDlE
3 7 (Tll.rbin. 1Dd)

FIDW
8 COIITROL
• SHUT OFF
S 9 VALVE

6 10 BlEED ua

1 11 SEPARATOi

12 OaD'ICE
•
, 13 MIIEa

10 16 SDII AD

11 61. Bl (S1M Side)

'l'IIRBDI:
12 n (c..pne.... . .)

Figure 1 Graphic Data Array

 The GRAF Language(2): The symbol drawing routines are written by the
user by means of the GRAF language and are stored in the computer mem-
0ry subject to recall by the user. The GRAF (Graphics Addition to Fortran)
subroutine package provides a means of communicating with the IBM 2250
display by giving the FORTRAN programmer the ability to control the dis-
play. He can create and modify displays composed of points. lines and
characters. plot and erase these displays from the screen. use the light
pen to select parts of a display in order to feed information back to the
problem program. use the programmed function keys and indicator lights,
and enter information using the alphameric keyboard through the use of
calls to the GRAF subroutines.

e e ee
@ 0 e ®®
END
DUCT
Fe
VALVE
SO
VALVE

C) SOO
60000<:9
o OOC)
~

08
Figure 2 IBM 2250 Function Keyboard

Once the graphic subroutines are established they can be called by the
function keyboard on the IBM 2250 display unit.(3) The function keyboard
format selected for the aircycle application case is shown in Figure 2.
Graphic symbols, such as those shown in Figure 3, would be displayed at a
desired point on the CRT by activating the appropriate function key and by
positioning the light pen at the desired location. To account for the possi-
bility that mistakes can be made in plotting, an ERASE routine is avail-
able for erasing the last symbol drawn and resetting the graphic data array.

163
 I~ shou.ld be noted that the symbol terminals are separated by equal
multlple dlstances from each other. This characteristic is central to the
dot -grid routine used in constructing a system diagram on the CRT and in
generating the graphic data sets. Because of the dot-grid routine, the
correspondence between the symbols arbitrarily placed on the CRT and the
data sets can then be established.

DUCTS t 1

HEAT
EXCHANGERS

~
FLOW CONTROL

-0-
.n=
SHUT OFF VALVE SEPARATOR

x
ORIFICE MIXER

Figure 3 Graphic Symbols

Dot -Grid Routine The dot -grid routine provides the mechanization to
force the light pen detected coordinate points of each reference location of
symbols in the program to be corrected to standard values so that they can
be referenced by any part of the program. The routine can be called any
time the main program is in control to establish the location for draw-
ing a component. It is also frequently employed when an error has been
made in the drawing and it is necessary to have a new starting location. It
is also the means for locating the branch points when other branches are
added at a node.
The dot -grid routine plots a set of dots on the upper portion of the scree!
in a grid-like fashion. (See Figure 4a). Each dot is located at a distance of

164
170 raster units from its neighbor in the vertical and the horizontal direc-
tion. When the routine is called, the grid appears on the screen and re-
mains there until a light pen detect occurs. When detection occurs. the
actual x -y coordinates of the point in raster units are returned to the pro-
gram.

Figure 4a Display of Dot -Grid Array

In order to insure that tolerances do not influence the exact integer loca-
tion of the coordinate another routine is used. This routine in effect forces
each point to be recorded as a particular predetermined set of coordinate
numbers. The means by which this is accomplished is to take the x and y
coordinate and divide it by 170 after the point has been translated by a
quarter of an inch or 85 raster units. The integer divide routine in FOR-
TRAN then truncates the decimal portion of the coordinate number and
there is left the actual coordinate position. after translation to cancel the
original translation.
Therefore. any point roughly within 1/4 inch in the x and the y direction
from the coordinate will be recorded as the x -y coordinate location in-
tended for the grid.
Once the corrected x and y coordinates are determined. they are placed
in common storage as integer variables for use in any of the program sub-
routines.

165
 When data are entered into the graphic data array (Figure 1), two steps
are required. First, the necessary symbol coordinate points are entered
along with a special code for the number located in the function key num-
ber storage position of the table. In addition, another number, which is
indexed after each component subroutine is completed, is placed in column
5 of the graphic data array. A new row is selected whenever additional
coordinates are recorded. This row also has column 5 labeled with the
same number as that used for the symbol coordinates. This number is a
cross -reference when the data are entered. The cross -referenced number
and the coded number defined above for the symbol terminals are provided
to differentiate the data used in subsequent computations.
3. 0 Construction of Computational Data Sets: The relationship between
the graphical data sets and the computational data set is established by a
state point labeling routine. The routine consists of two basic parts. The
first part identifie~ the particular state point with the components connec-
ted at that state point. The second part rearranges the graphic data array
into a new structure where the order is related to the computation se-
quence.

Figure 4b Display of Computational Array

State Point Routine At the user level the designer begins the labeling by
selecting a starting point or the input to the system. The light pen is
placed over the point to be labeled causing four points to appear around

166
the selected point. One of these points, depending on which number loca-
tion is desired, is light penned. The state point number is then plotted at
the location of the point selected from the four points previously displayed.
The program then corrects the state points selected in accordance with
the method used in the dot-grid routine. The integer array is then searched
and each x-y coordinate pair of the table which agrees with the selected
state point coordinates is identified by placing the state point in a column
associated with that set of coordinates, depending on the coordinate point
column location. Generally, at least two components are labeled with this
state point. If the point is a branch then the number of components at the
branch is the number of components labeled. When each point has been
labeled, the user presses the "END" function key for the state point plot-
ting.
The array structuring then takes place. First the array is rearranged
so that the inlet state point of each component is placed in numerical order,
with increasing' order from the top to the bottom of the table. Each of the
other numbers located in the various columns of the row in which the inlet
state point is located are also relocated at the same time., In effect, the
rows of the table are rearranged in ascending order with the top of the
table being considered as the starting point. Where multiple entries of a
single state point number occur as the result of a branch, the rows are
located in the order in which they originally were entered.
After the rearrangement of the table has been completed, the compo-
nents with more than two parts become separated. For example, in order
to provide communication between the compressor and turbine ends of the
cooling turbine in the sample aircycle problem, a means is required for
locating all of the data relevant to the cooling turbine. This is accom-
plished by going through column 5 of the integer array.
This column was filled with index numbers during the symbol drawing
routines as the turbine, heat exchanger, and mixer were plotted. Two
rows with the same index number, other than zero, are associated with
each other by placing the row number of the corresponding element in
column 8 of the given row. For this example, the turbine end data set row
of the cooling turbine will have the row number of the compressor end data
set located in column 8, while column 8 of the row containing the com-
pressor end data set will contain the row number of the turbine end later
set.
The indexing scheme is necessary to prevent a mixing of SUbcomponents
when there are multiple components of the same type, such as might occur
if there are three heat exchangers used in the system. The indexing
assures that all the subcomponents are associated with the proper mate to
form the whole set.

167
COMPUTE Routine: When the state points have been added, the program
is available for computation. This procedure is called by pressing the
COMPUTE function key which activates the COMPUTE routine. This sub-
routine, in effect, is a control program that calls into operation the re-
lated set of subroutines used during the computation process.
When the COMPUTE routine is called, a tutorial appears on the screen
followed by a menu. The menu represents the choices of action which are
available to the user as follows:
1. The entry of the state point numbers of the desired component in
computational order.
2. Display and entry of variable values.
3. Display and entry parameters within component computational sub-
routines.
4. Performance computation.
5. Automatic computation of next component.
6. Data entry into program.
7. Open reference scratch pad area.
8. Menu' display.
9. Return to main program.
To provide sufficient area on the CRT, the menu is replaced by a com -
mand row containing the numbers of the menu. By selecting one of the
numbers with the light pen, the activity associated with that number of the
menu is activated. Following is a detailed description of the menu items.
State Point Entry: Selection of this item calls the dot -grid routine. To
select the state points of the component or SUbcomponent for which some
activity is required. The two state point numbers selected are then plotted
in large letters at the lower left-hand area of the region used by the dot-
grid routine. The order of state point selection is relevant since the order
of selection determines the computational order.
At the program level, the coordinates and entry order of the two points
are recorded. The graphic data array (Figure 1) is then searched to deter-
m.ine if the ordered set selected match is the set of coordinates contained
in a particular row. If the match is not found in the first search through
the array, ordering of the two points is reversed to indicate that a reverse
computation is desired. The array is then searched for the match.
Once the match is obtained, the state points are plotted on the CRT and
the row indicator variable (IS) is reset with the row number in which the
match was found. The variable IS is the key that links the graphic data
array set with the computational data sets so that the computational data
becomes structured in the same order as the graphic data array.
Display of Variables: Selection of the number "2" of the menu causes the

168
 (Actual Sis. 18 2$ by $0)

VARIABLE STORAGE
PARAMETER STORAGE AS

REQUIRED BY COMPONENT ~
I::>
~ !§ ~ !§ COMPUTATIONAL SUBROUTIXE
.
Ii! ~ ~ :. ~ ~ ~ :. ~
1
2
)

4
$:
6
7
8
. 9
10
11
12
1)
..... L-.
- _- -- - - -- - --V
- - .....
- ..1\
47
48
49
50

IOTIS I 1 iOW IlUlEEIlS CORRESPOlID TO DTmiR TABLE ROW IIUIIBEIS

2 OLD AllAY IS THi SA. COIIFlDURATIOI IICEFT THAT IT IS 20 BY $0 D SIZE
) BOIi 1.8 OOITAIXS IllTA J'K>II COIlfOlilllT ROW fOR I'IlEVIOUS COIlPUTATIOli
II BOIi iii CO.TADS lilT! COITADiI) D COIll'OllEH ROW AT TIlE START 01 TU COIlPUTATml

.......
ffi Figure 5 Computational Data Array
contents of the variable portions of the IS row of the current data array
(CDA) and old data array (ODA) to be displayed. (Figure 5). For instance
in the air cycle application these variables are the inlet temperature,
pressure and airflow rate and the outlet pressure and temperature. The
variables are listed in the heading of the display as "FI! for pressure, liT"
for temperature and "w" for weight flow. Each variable is followed by
the state point number associated with the particular variable location.
Three sets of variables are displayed. (See Figure 4b) The "NOW"
row contains the variable values currently stored in CDA, the 1I0LDII row
contains the values of the variable which were stored in ODA during the
previous operation; the last set is labeled "NEW" and will contain either
the same values as before and the IINOW II row contains the results of the
calculation just completed. The values in the IlNOW Il row are in the un-
protected mode and therefore can be changed with the alphameric keyboard,
To accomplish this change the I! JUMP" key is depressed to move the
cursor under the block into which the new value is to be entered. To store
the new data in CDA for later use, the IIENDfI key on the alphameric key-
board is depressed in conjunction with the "ALTII key.
At the program level, operation of the "ENDlt key causes the variable
information contained in the current data array (CDA) to be transferred
to a 50 by 20 temporary storage array called (ODA).
Display Parameters: This routine, activated by light penning number "3",
causes a flag to be set in column 12 of the currently selected array or IS

BLEED
IN
2 3
4 5
SINK
IN

17 15 16

Figure 6a Simple Aircycle

170
row in the graphic array. The COMPUTE operation then calls the compu-
tational subroutine associated with the type of component currently selected.
Each of the component computational routines contains a check for the flag

30 31
BLEED
IN 5

29
23

11 SINK
IN

28 21 ......_ _ _...... 26 25 24

Figure 6b Bootstrap Cycle

which causes the parameter input requests to be displayed for new input or
a change. When parameters are to be changed, the subroutine is executed
as though it were the first time that it was called. At the end of the routine,
the flag is removed so that a further call to the routine will not require
parameter entry.
It is noted that the parameter input requests are called automatically
the first time a subroutine is called.
Performance Computation: This activity, selected by light penning number
"4", causes the subroutine associated with the component function key num'"
ber stored in column 13 of the graphic data array to be called.
When the computation subroutine returns control to the COMPUTE
routine, the Variable Display is presented with the results of the computa-
tion entered in the IINEW II row. The results can then be entered into the
current data array for every component which has as one of its state point
numbers, the same state point number as the outlet of the current compo-
nent. An alternative is .to enter data into only the CDA for the current com-
ponent. By operating the IIEND" key the data is entered into the current
component position only. By selecting "6" with the light pen, the data is

171
entered into CDA in the outlet position of every component with inlet or
outlet state points, the same as the current output state point.
Automatic Computation: By selecting number "5", the next component is
entered into current status for computation automatically. The new cur-
rent component state point numbers are displayed in the same order and
the COMPUTE instructions are executed.
This instruction increments only one component at a time so that it must
be selected repeatedly for a series of components. The routine avoids the
necessity for selecting every component to be computed with the light pen.
Enter Data: This command is internal to the compute command {number-
1t41t} routine previously described. The action resulting from the selection
of this command at any other time is the display of an error message.
Scratch Pad: Command "7" opens up an area at the bottom of the CRT in
which the user may type messages that are helpful to him as memory aids.
Menu Display: This part of the program is activated by selection of num-
ber "8 11 with the result that the full menu is displayed to refresh the mem-
ory of the user as to which action results from the selection of a particular
number.
Exit: When number IIgll is selected, the graphic data array and CDA are
printed and program control returns to the main program.
4.0 Air Cycle Application Example~4} The design of aircraft air cycle,
air -conditioning systems was chosen to demonstrate the application of the
graphic on-line technique. As is normally the case with systems that-rely
heavily on the principles of thermodynam.ics, fluid flow, and aerodynamics j

virtually every component is best represented by either nonlinear algebraic

equations (5 -9) or by relationships based on empirical data. (10. 11) The
solution of this design problem is enhanced by combining a human decision
maker with a computer program designed such that the designer can inter-
pret and interact with the solution of the problem. Typical air cycle sys-
tem configurations are presented in Figure 6.
4. 1 Air Cycle System Component Graphic Routines: Refer to Figure 3 for
symbol configuration of the component routines discussed.
Duct Routine: Subroutine DUCTR is used to draw a line of approximately
one -half inch length. These lines are the symbols which represent the
ducts that interconnect the various major system component symbols.
By pushing one of the first four function keys (I through 4) in Figure 2, a
line is drawn either upward. downward. to the right, or to the left, re-
spectively. If a particular button is pushed three times in succession. for
instance, a line one and one -half inches long is drawn. To turn a corner.
the user pushes the function key which draws in the desired direction.

172
 To exit from the subroutine, EDUCTR is called. This routine stores
the coordinate points and appropriate codes in the graphic data array and
places an arrowhead on the end of the duct.
A technique which was developed for this routine involves consecutive
operation of a single function key a number of times. To avoid a discon-
tinuous appearance in the line at half-inch intervals, the routine is arranged
so that the previous plot is erased and the buffer is reset before the next
line is drawn. For example, first a half-inch line is drawn. This line is
erased and then a one-inch line is drawn. This line is erased and is re-
placed by a one and one-half inch line, etc.
Where branching occurs, a duct must be ended at the branch point. In
other words a branch point must terminate the upstream duct and be the
starting point for the required downstream ducts which may be two or more
in number.
Heat Exchanger Routine: This routine is the most complex graphic routine
as it provides many options with respect to configuration and orientation.
First a 'light pen detect on a dot grid is made to locate the center of the
heat exchanger symbol. Next, the direction of the sink air flow is indicated
by light penning either "vertical" or lIhorizontal. II This places a rectangle
on the CRT with two attached lines indicating the raIn air inlet and outlet
connections. GRIDR (the dot-grid routine) is used twice to record the x-y
coordinate s of the connections.
Next the CRT requires the location of the bleed air inlet position. The
light pen selects the corner of the rectangle nearest to the inlet. At the
same time the user indicates how many passes are desired in the bleed
air side. The bleed air ducting is then plotted to complete the heat ex-
changer symbol. Once again, GRIDR is used to enter the connection co-
ordinates.
The choices in this routine are the rotation (horizontal or vertical),
location of bleed air inlet (one of the four corners), and the number of
bleed air passes (one, two, or three). These options are not related to
the actual configuration or performance of the heat exchanger.
The options were provided to prevent awkward situations from occuring
in the drawing of the ducts and thereby wasting space on the screen if a
large system is being drawn.
Turbine Routine: The cooling turbine drawing routine was used to demon-
strate the use of a rotation and reflection matrix so that the major portion
of the symbol is drawn by using one quarter of the symbol. This is ro-
tated and reflected to provide a complete turbine symbol.
To place the symbol on the screen, the center of the turbine is located
with GRIDR in response to CRT instructions. To prevent complicated duct

173
 routing, the turbine inlet / compressor outlet connections may be located
either above or below by light penning the appropriate corner of the tur-
bine/compressor.
The next procedure is to locate the x -y coordinates as was done in the
heat exchanger routine. In this case J however J the first two coordinates
must be associated with the turbine end in the direction of air flow. The
compressor end coordinates are then entered, also in the direction of the
air flow.
Flow Control Valve/Orifice Routine (FCVALR/ORIFCR): The center of
these symbols is selected with a GRIDR whIch is internal to the program.
Next the direction of flow J HORIZONTAL Or VERTICAL J is selected. The
symbol, is then· plotted. GRIDR enters the exit coordinates of the valve
into the graphic data array while the entrance coordinate is the same as
the last coordinate of the preceding symbol.
Shut Off Valve Routine (SOVALR): This symbol routine uses an improve-
ment over the method described above. Here the symbol is placed on the
CRT by pressing the shut...,off valve function key and then one of the keys
used for DUCTR depending on the direction of air flow. The valve is then
plotted starting at the coordinate of the last point plotted in the previous
routine in the program.
Bleed Air Inlet (BLEEDR): This routine indicates the bleed air source
with an "X" located by GRIDR. Accompanying the IIXII is the label IIBLEED
AIR IN. \I
Water Separation Routine (WASEPR): The water separator routine utilizes
a full set of rotation matrix instructions. The symbol could be drawn at
any rotational angle; however, only 90 degree increments are used.
To place the water separator on the screen, GRIDR is used to select the
center of the water separator without benefit CRT instructions. The air
flow direction is indicated by selecting the appropriate arrow with the light
pen.
Mixing Duct Routine (AMIXR): The configuration is selected by deleting
one of the connecting ducts on the symbol located at the bottom of the CRT
with the light pen. GRIDR is then used to select the center of the position
at which the mixer is to be located.
The symbol is plotted and GRIDR appears to enable the end points to be
entered into the integer table. The three connecting points are entered in
such a way that the final point entered corresponds to the outlet of the
mixer.
In this program the mixer symbol only accommodates the mixing of

174
two streams of air. If more streams join at a point, another mixer is
required for each extra stream.
3.3 Description of Computing Data Structures and Routines: The follow-
ing subparagraphs describe the use and operation of the AIRCYC compo-
nent computational subroutines called from COMPUTE. (12, 13)
Duct Routine (DUCT): This subroutine computes the inlet or outlet
pressure in a particular duct depending on the order of the state point
entry. The computation can be made by the use of a (J~p curve, or the duct
diameter and equivalent length can be used.
When this routine is called, the first action is to request an input if the
use of a (J~p curve is intended. If not, then function key 30 is depressed
causing the display to request the duct parameters, duct length and diam-
eter, all in inches.
In the first case, (J~p is entered from a curve in the space provided
with the appropriate units of either inches of water or mercury.
The subroutine then computes the duct pressure drop as a function of
either the inlet or outlet pressure and temperature depending on whether
or not reverse or forward computation instructions have been entered. The
only requirement for attention is if the Reynolds number exceeds 3000
when duct parameters are used. If this occurs, the CRT will display a
message requesting friction factor data.
Heat Exchanger Routine (HEAT): The subroutine first determines which
side of the heat exchanger is involved. This is done by testing column 13
of the graphic data array to see if the normal function key number or the
coded number is present. If the coded number is present, the average
temperature of the cooling or ram air temperature across the heat ex-
changer is determined using the data obtained from the bleed air side cal-
culation. This data is found by reference to column 8 which contains the
row numbers in CDA of the data for the bleed air side of the heat exchanger.
The pressure drop is then computed with the data which was input by the
alphameric keyboard in response to a displayed request for data.
If the coded number is not present, the temperature drop across the heat
exchanger is computed using the parameters and variables requested from
the display. A procedure contained in this routine provides for linear in-
terpolation to determine values between curves. If this method is chosen
for entering the heat exchanger effectiveness, a light pen detect will allow
machine interpolation to be accomplished.
After the temperature drop has been computed, the pressure drop
parameters are entered into the display. This permits computation of the
pressure drop for the hot side of the heat exchanger.

175
Cooling Turbine Routine (TURBIN): First a test to determine which end of
the cooling turbine is to be analyzed is made. When the turbine end is to
be analyzed, the turbine speed is requested. Next the turbine flow factor J
turbine wheel diameter, the tolerance allowance between the assumed flow
and the flow which will pass through the turbine at the existing inlet condi-
tions, and the turbine nozzle effective area are requested. The turbine
pressure ratio and the corrected turbine speed are displayed for use in
obtaining chart data.
The next request is for the turbine efficiency which is obtained from a
set of curves using the velocity factor and the pressure ratio displayed
along with the request. The temperature drop is then computed.
The flow tolerance test then checks the assumed weight flow and the
turbine nozzle flow. If the required flow is not within the required toler-
ance value entered earlier, the routine is ended.
For the compressor part of the routine in a bootstrap system, the first
request is for the compressor wheel diameter. Next the compressor
pressure ratio, Mach number and efficiency are requested given the com-
pressor flow factor. When the simple cycle is required, the display re-
quests the corrected speed and corrected airflow rat~ given the turbine
power factor and compressor pressure ratio.
When the bootstrap turbine routine is finished, a check determines if
the tem.perature drop across the turbine is equal to the temperature rise
across the compressor.
Flow Control Valve Routine (FCV): The flow control maximum is
checked against the assumed flow. If the assumed flow is less than the
flow control maximum flow then the pressure drop across the valve is
computed.
On the first time through the calculation, or when the parameter flag is
set, the flow control constant is entered.
If the flow control valve is controlling the downstream or discharge J
pressure is indeterminate. The discharge pressure can be determined by
reverse direction calculations if it is required.
Shut-Off Valve Routine (SOV): The shut-off valve subroutine is designed for
butterfly valves since an analytical expression is available for the geome-
trical area. This requires that the open angle and valve diameter be en-
tered into the display in the spaces provided. If other types of valves are
desired, then the effective area must be entered into the appropriate block.
The routine calculates the effective area for the butterfly valve and then
calls the orifice subroutine for computation of the weight flow. When the

176
effective area (CA) is input, the orifice subroutine is called directly.
Water Separator Routine (SEP): If the parameter display has not been
selected, a check is made to see if the airflow rate has changed. If the
parameter display has been selected or if the airflow rate has changed, the
parameter acquisition routine is activated.
The first request is for dew point temperature of the air at the given
temperature and pressure as well as the inlet humidity and the saturated
humidity.
The routine then checks to determ ine if the air is saturated. If the air
is not saturated, the subroutine requests the dry <r.D.P value at the given
weight flow via the display. The dry separator pressure drop is then com-
puted in the desired direction.
If the air is wet (supersaturated), the routine requests the wet <rAP as
well as the efficiency at the given airflow rate.
Water ,separation performance is then computed to give the outlet hu-
midity level and the outlet dry air rated temperature.
The pressure drop is computed next, but it must be noted that when the
separator is removing moisture both the separation calculation and the
pressure drop calculation must be done in the forward direction because
the humidity values are based on the separator inlet pressure.
Orifice Routine (OR F): This subroutine requests the user to input the
effective orifice area (CA) of the orifice and then computes the airflow
rate using the inlet and outlet pressure values previously stored.
When using this routine which is also called by the shut-off valve routine,
the designer must be certain that both the inlet and outlet pressures are
supplied, otherwise erroneous results will be obtained because of division
by zero.
Mixing Duct Routine (MIX): The mixing duct subroutine operates on data
already stored in the machine. Consequently no input is required of the
user. The routine is called only when the user knows that the inlet data is
available and desires to know the results of the mixing operation.
5.0 Conclusions: The techniques for generating data sets from an arbi-
trary assignment of computer graphic symbols have proved effective in
reducing the number of man-hours in bringing an interactive system to an
operating point. Additional savings can also be achieved by: (1) automating
some of the computational steps to include groups of system components at
one time, and (2) developing a new language to handle more of the program
setup procedure. These considerations are currently under investigation.

177
 BIBLIOGRAPHY
1. Karplus, Walter J., Editor, On Line Computing, New York McGraw":
Hill, 1967.
2. Moore, Gwenn, Users Guide for GRAF: Graphics Additions to
FORTRAN, Los Angeles, University of California, Health Sciences
Computing Facility, 1968.
3. International Business Machines, !tUse of the IBM 2250 Display Unit, 11
IBM Data Processing Application, White Plains, International Bus-
iness Machines Corporation, Technical Publications Department.
4. ASHRAE Guide and Data Book: Fundamentals and Equipment, New
York, American Society of Heating, Refrigerating, and Air Condi-
tioning Engineers, 1965.
5. Shapiro, Ascher H., The Dynamics -and Thermodynamics of Com-
pressible Fluid Flow, Vol. I, New York, The Ronald Press, 1953.
6. Kays, W. M., and London, A. L., Compact Heat Exchangers, 2nd
edition, New York, McGraw -Hill, 1964.
7. Ba~meister, Theodore, Editor, Mechanical Engineers Handbook,
6th edition, New York, McGraW-Hill, 1958.
8. U. S. Ames Aeronautical Laboratory Research Staff, "Equations;
Tables, and Charts for Compressible Flow," NACA Rep. 1135, U. S.
National Advisory Committee for Aeronautics, 1953.
9. Andersen, Blaine W., The Analysis and Design of Pneu-Systems,
New York, John Wiley, 1967.
10. Airesearch, "Psychrometric Chart for Various Pressures," Internal
Publication, Los Angeles, Airesearch Manufacturing Company, 1959.
11. Siders, R. A., et al., Computer Graphics, New York, American
Management Association, 1966.
12. Berhold, E. D., "Interactive Designs of Nonlinear Systems Using
Computer Graphics, " Master Thesis, Computer Science Department,
University of California, Los Angeles, 1969.
13. Berhold, E. D., Berhold, M. P., McNamee, L. P., "Computer
Graphics: A Powerful Simulation Tool for Nonlinear Algebraic and
Emperical Design Problems," submitted to Simulation, Decem.ber
1969.

178
A CAD APPROACH TO BLANKING DIE AND
TECHNOLOGY DESIGN

J. Ferenczy

Research Institute for Automation of the Hungarian

Academy of Sciences, Budapest XI. Kendeu, 13-17,
Hungary.

Preface
Some years ago, a group of workers in the Research
Institute for Automation of the Hungarian Academy of Sci-
ences started working on interactive design techniques.
It was decided to try and find a domain which should meet
the following requirements:
- contain typical problems of machine design and technology
- make possible a linkage with the parallel research groups
engaged in the numerical control of machines, NC processors
and postprocessors studies, the development of display
software and display hardware and language problems,
- in short a CAD programme with the greatest possible ver-
ticality, setting out from the design stage and going
right through to complete manufacture of the product.
The programme, presented here - is a typical instance
of these ideas, comprising the whole series of design-steps,
leading from the graphical part description to NC machining.
At the same time, it can serve as a basis for a comprehen-
sive programme package, containing other vertical programmes,
ultimately to build up a cold press technology design system.
Economic aspects - though subsidiary of the conception were
not neglected. In fact, the computer aided tool design prog-
ramme may fill a long-felt gap in the machine and electronic
industry. The programme was worked out with the cooperation
of the technology and tool design branches - mostly of
electric and electronic production of high precision pressed
workpieces.

A short technological survey of the programme

The blanking die and technology design programme be-
gins with the geometrical part description written in an
APT compatible language - actually in 2C,L or EXAPT III,

179
and with the addition of technological data, such as: mate-
rial, tolerances, standard constructional data of die ho-
sings, press machines and economic factors. The first module
of the programme checks the technological instructions and
configuration of the part drawing, tolerances, gaps, roun-
dings and critical lengths. Only if all of these are in
accordance with the technological requirements, does it start
further steps. If not, it returns the drawing to the operator
with detailed redesign instructions.

The task of the next modules of the package are basic

technological calculations, selection of die housing and
press machine type and the listing of parts from a standard
collection. Further modules are the strip pattern design,
determination of the number of steps and simultaneously wor-
king stamps, choice of the stripper plate, economic calcula-
tions and instructions for the shop, including mounting of
the tool.
The last module represents an interface to the processor
and postprocessors for NC machining - milling and superfinish
operations - or in a more favourable version numerically cont-
rolled electroerosion. In addition, a postprocessor for a
plotter is necessary to draw the stripper plate design and
an other for the display console.

The operational structure of the programme

The programme is written in accordance to the require-
ments of interactive operation. The main part is the execu-
tive., as will be seen in detail.
The programme is divided into modules, due partly to
practical computing reasons concerned with segmentati,on,
further to the changeability of the modules.
An other feature characterising this structure is the
greatest possible flexibility.
All of the technological data changeable with time or
fields of application are maintained separately from the main
blocks of the structure.
The structure is shown in the block diagram IFig.l.l.
Right of the executive are the linkages of the periphericals
and the blocks necessary for their work, such as the display
postprocessor PPl, postprocessors or processors PP2, PP3, PN
to plotter and NC machine, menu programme IMPI and manipula-
tion programme IMOI for the display. Left 6f the executive
the A and B fields - enclosed by dashed lines - contain
the calculations of which the topics are given in the sub-
blocks from 1 to 3 and from 5 to 7 . Some subroutines
like L and ETA, the interaction block of stripper plate
pattern design, are outside of A and B, because they are di-
rectly linked to the executive. Similarly the geometrical in-
put block is outside of the main parts, being a changeable

180
2C ,L or other equivalent programme, likewise the subroutines
marked T, K, S giving the area, contour length and center of
gravity.

Input data ; Linked proqram I Module• connec- Peripheral.,proce ••ors,

: ..... and ,ubrou~ted to the exe- po.tproce ••or. and dis-
u4 table. tine. ,cutive play operating programs

V V V 11 ht pen
2el
or
EXAP'l'III

Input data and Linked program-Module. connec- peripherals, processors,

table. me. and subrou-ted to the exe- postprocessors and dis·'
tinel cutive play operating program·
mes
Fig. l.
The input data handling is directed by a monitor prog-
ramme, independent of the working modules. This structure
makes it possible for the use of the programme not be restric-
ted to a single factory or one standard system. All of the

181
modules are completed by checking routines, suitably planted
in the correspondent blocks.

Dialogue operations
This selected field of CAD appeared from the early
stages of programme writing complicated enough to offer an
opportunity to use an interactive communication mode between
operator and computer. Later a whole series of critical nodes
appeared to be tractable only by these more sophisticated
techniques. The solution of these sectors would be hopeless
without the interactive method.

Fig. 2.

Fig. 3.

182
 Fig. 4.

Fig. 5.

The dialogue can be shown by some characteristic figu-

res selected from the procedure. The Fig.2. is the workpiece
as it appears on the CRT screen. The next three - 3, 4 and
5 are taken from the checking programme section. Each of them
shows moments, in which the computer rejects the drawing.
Further figures from 6 to 13 are chanacteristic items
of the strip design phase.
The factor, called ETA - see Figs.7,8,9 - as it is given
by the computer, represents the actual efficiency of strip
utilization in every phase of the operators work as he deve-
lopes new configuration with the light pen. In the early sta-
ges of programme development we had an idea that one of the
well-known strip pattern optimisation programmes would cal-
culate the most economic pattern on the basis of a determinis-

1~
 Fig. 6.

Fig. 7.

tic programme. Finally this idea turned out to be too optimis-

tic because the best patterns were rejected as not feasible
by the following computer check.
We had much the same experiences with the checking of
critical distances and gaps. The difference was, that a prog-
ramme more than twenty times the length of the section actu-
ally inplanted could have given proper results. The worst side
of the deterministic programmes seems to be an unbearable
storage requirement. For instance, in the case of the patterns,
shown on Fig.10, the critical gap could have been calculated

1M
 Fig. 8.

Fig. 9.

by storing the whole pattern in incremental.form. Instead of

this, the same checking job done by the light pen needs only
the storage of three or maximally four geom~trical elements,
and only the calculation of the minimal gap, between them in
the area, marked by the light pen - is needed.
Nearly all of the geometrical manipulations can be
treated in the same manner and with the same conclusions:
the decisions involving geometry and at the same time techno-
logical knowledge offer mostly logically indefinite problems.
This is the case with the choice of the housing type in the

185
 Fig.10.

Fig.ll.

programme Isee Figs. 14, 15, 16, 181, or with the mosaic par-
titioning IFig.19/. Sometimes economic decisions are needed
in addition to geometrical and technological problems. In
the stage, shown in Fig.ll, the computer gives a proposition
as a result of an economic calculation but it leaves the fi-
nal decision to the operator.
At the same time, a long series of well determined
mechanical calculations are at hand which can be called in
by the executive or by the operator, like some subroutines

186
 Fig.12.

Fig.13.

generally used in machine design. IInertia, tensile strength

and others.l.
With these the operator deals frequently, using the
benefits of the dialogue - by changing the initial data, so
that he is enabled to create a great number of different ver-
sions unthinkable in a conventional design environment.

connection to other programmes

The size of the programmes connected to the main parts -

187
is considerably larger than that of the part specially written
in the frame of the tool design programme. The initial prog-
ramme - as stated above - is at present the 2C,L* part des-

* Copious information and much assistance in the implementati-

on of the 2C,L programme was made available to the author's
Institute by the National Engineering Laboratory, East Kilbri-
de, Scotland, whose assistance we are glad to acknowledge.

Fig.14.

Fig.lS.

1~
 Fig.16.

Fig.17.

cription. Three procedures, linked directly to the CLTAPE -

contour length, area and center of gravity - are standard
routines of all the engineering design programmes.
They are called occasionally by the main programmes,
by the executive or by the operator. The final sections of
the programme are the processors and postprocessors for NC
machines and for the plotter which similarly to the operating
system of the display, are written for general purposes. The
only exception is the menu programme which contains special
data of standardised figures. The terminal programmes, menti-
oned here are accessible by the executive, or by one of the

189
 Fig.18.

Fig.19.

A-B modules or by the operator. The executive is designed to

prevent inconsistencies.

Further Development
The programme discussed here is written partly to be
used independently, partly to serve as the base for package
for cold press technology design.

100
 The vertical programmes for bending, drawing and for-
ming comprise several steps which have been solved by one or
other module of the base programme.
First of all, the geometrical description and the
connected subroutines as well as the biggest parts of the
terminal programmes will remain unchanged. Only an extended
version of the menu will be necessary. On the other hand, the
basic programme is in its entirety the opening section of the
cold press technology project, be it bending or drawing or
forming. In this way, more vertical programs may be connected
in series and in addition a considerable number of modules may
be used repeatedly.
The main parts - referring to A and B in the basic
programme - will be changed as well as the related part of
the executive.
In fact, the extension of the performance of the ori-
ginal programme can be implemented at the price of a fraction
of what was alloted to the basic programme.

Summary
The paper is concerned with an interactive computer
programme for blanking die and technology design, written by
the author in the Research Institute for Automation of the
Hungarian Academy of Sciences.
The paper gives a short survey of the technological
contents and performance of the programme. It describes the
structure of its operation, and connection to other program-
mes. The main part of the paper is related to the experiences
of interactive programme writing and development for a wider
system.

References
1 Barker, A.J.: Numerical engineering in car body manu-
facture.
Machinery and Production Engineering,
1968. July, 31. p.268-277.

2 Cameron, S.H., Ewing, D., Liveright, M.: Dialog: A

Conversational Programming System with a
Graphical Orientation.
Communications of the ACM, 10.6. 1967. June
p.349-357.

3 Coons, S.A.: An outline of the requirements for a

computer aided design system.
Proc. Spring Joint Compo Conf. 1963. p.299-304.

4 Ferenczy, J.: SajtolQszerszam es sajtolasi techno16-

gia interaktive tervezese.

191
 MTA Automatizalasi Kutat6 Intezet, Film,
1967. Dec.

5 Ferenczy, J.: Sajto16szerszamok szamit6gepes inter-

aktiv tervezesi m6dszere.
Szamit6gep alkalmazasa a gepiparban Konferencia
Miskolc, 1969. Jan.

6 Gould, I.H.: Some problems of computer aided design.

Computer Bulletin, 1966.Dec. p.64-68.

7 Grivachevsky, A.C.: Razrabotka i isledovanie meto-

da konstruirovaniya shtampov s ispolzovani-
em ECVM
A~ademiya Nauk, Hinsk, 1967.

8 Hatvany, J.: Nehany uj iranyzat a gepgyartas automa-

tizalasaban.
III. Automatizalasi Kollokvium, Budapest,
1966.Dec.

9 Hatvany, J.: Ember es gep informaci6cserejenek uj

eszkozei.
Ipari Meres es Szabalyozas Szimpozium,
Balatonszeplak, 1967.

10 Hatvany, J.: Uj m6dszerek a szamjegyes vezerles alkal-

mazasaban.
OMFB Ismerteto tanulmany, 4-8ll-IT, Bp.
1968.0ct. 63 pp.
11 Hatvany, J., Kovacs, M., Pikler, Gy.: Szamjegyes
vezerlesli szerszamgepek szamit6gepes prog-
ramozasa.
MTA Automatizalasi Kutat6 Intezet Kozlemenyek,
3. Bp. 1969.
12 Herzog, B.: Symbolic input for design.
Proc. of the IFIP Congr. 65.

13 Keidel, W.D.: Les Limites de l'intelligence Arti-

ficielle
Automatisme - Tome XIII.
No 9, Sept. 1968. p.338-34l.

14 Licklider, J.C.R.: Man-computer symbiosis.

IRE Trans. Human Factors in Electronics,
HFE-l. 1960.March. p.4-10.
15 Licklider, J.C.R.: Principles and problems of console

192
 design.
Proc. of the IFIP Congo 65.

16 Licklider, J.C.R., Clark, W.E.: On-line man-computer

Communication.
Proc. of the SJCC, San Francisco, 21.
1962.May. p.113-128.

17 Myer, T.H., Sutherland, I.E.: On the Design of

Display Processors.
Communications of the ACM, 11.6. 1968.June
p.4l0-4l4. --

18 Pikler, Gy.: EXAPT 1. szamitogepes programozasi

nyelv honositasi feladatai es tapasztalatai.
Szamitogep alkalmazasa a gepiparban Konferen-
cia, Miskolc, 1969. Jan.

19 Siders, R.A.: Computer Aided Design.

IEEE Spectrum, 1967.Nov. p.84-92.

20 Sutherland, IiE.: Computer Inputs and Outputs.

Scientific American, 215.3. 1966.March,
p.86-97.

21 Welbourn, D.B.: The Use of Computers with Graphical

Input/Output.
The Chartered Mechanical Engineer, 1966.Nov~
p.487-489, 494.

193
 COMPUTER-AIDED DESIGN
at
MCDONNELL DOUGLAS

J. J. Lavick
McDonnell Automation Center, Bldg 105, Level 3
232-8043, P.O. Box 516, St. Louis, Missouri 63166,
U.S.A.

ABSTRACT

In the last several years, Computer-Aided

Design techniques have moved from dream to reality.
Activity and interest are currently at an all time
high. As the variety of computer graphics hardware

broadens and costs fall, as software availability

increases, the use of interactive display devices
throughout the Design process will rise exponentially.
This paper discusses the Design process, the CAD
evolution, and various "interactive computer graphics"
applications related to Design that are presently
in work at MCDONNELL DOUGLAS CORPORATION (ST. LOUIS).

1. INTRODUCTION
1.1 Scope
Like many complex processes, the concept of Computer-
Aided Design (CAD) is today greatly misused, misinternreted,
and misunderstood. CAD is a very broad subject and since its

195
spectrum of definition is so vast, I will not attempt to
generalize a definition here today, but will simply present to
you one company's point of view of CAD and, more specifically,
highlight some of the areas using computer graphic techniques.
Since the MDC interpretation of CAD is related to computer
systems utilized in the design of some geometrically-oriented
product, this paper will clearly ignore such computer graphic
activities at MDC as ECAP (Electrical Circuit Analysis Program)
CSMP (Continuous Systems Modeling Program), MIS (Management
Information System), etc. CAD at MDC is not completely
restricted to programming/user systems that utilize a CRT
device. Therefore, from time to time, batch, conversational
batch, and passive graphic techniques will be briefly mentioned
1.2 The Design Problem
The difficulty of CAD definition is inherent to the
"design process" itself which, at best, is arduous in descrip-
tion. The design process, a mix of graphic and analytic
functions, is identifiable by its three primary phases;
(a) conception, (b) definition, and (c) communication. Under-
standably, the distinction between these phases is not always
clear. Nonetheless, they mark not only the overall characteris
tics of the design cycle but also continually reoccur through-
out the subprocesses of the cycle. The conceptual phase con-
sists of the construction of a preliminary layout which can be
used for weight and space allocation studies. Various struc-
tural arrangements are proposed and initial trade-offs are
evaluated. Finally, a tentative configuration selection is
made. During the definition phase, preliminary layout work is
updated and finalized. From this, weight and cost optimization
studies can be performed on configuration subsystems from which

Figure 1 - Computer-Aided Design at MDC Figure 2 - Basic Design Stages at MDC

(Title Illustration)

196
final sizing of structural elements can be completed. General-
ly, prior to establishing the final design specifications,
interference and tolerance effects on manufacturing, assembly,
and performance are reviewed. In many aspects, the communica-
tion phase of the design process is the most important. Engi-
neering drawings which describe detail parts and assemblies
must unambiguously communicate the structural concepts derived
by the designer. These graphic descriptions must be precise
and easily interpreted by subsequent functions--design evalua-
tion, manufacturing, and ultimately the customer. Figure 2
illustrates the basic design stages as seen at MDC. The pro-
cess is highly characterized by the TRANSMISSION, MANIPULATION,
and CIRCULATION of information interacting among all stages.
Figure 2 does not intend to imply that currently all data
involved in this cycle at MDC is captured by a central computer.
However, MDC presently employs many computer based methods that
are considered CAD techniques. More specifically, graphic
consoles are gradually being introduced into these CAD
activities.

Figure 3 - Modes of CAD Usage at MDC Figure 4 - DUAL MAIN (Central Files)
Computer Configuration

1.3 The Computer-Aided Design Environment

Traditionally, designers have been non-computer users.
Gradually at MDC, we are revising this philosophy. Education
and computer availability are key fact~rs in achieving this
revolution. In the following illustrations you will see that
MDC is involving the use of computer-aides not only in the pro-
duction phase, but in the CONCEPT FORMULATION, ADVANCED DESIGN,
and DETAIL DESIGN stages. Figure 3 illustrates the modes of
CAD usage that denote this availability. BATCH processing is
centralized at Building 105 (MCAUTO)headquarters and represents
the high volume computer system use at present. RJE access to

197
the various batch systems located there present a CONVERSA-
TIONAL/BATCH facility to all MDC users and has been in suc-
cessful production use for some time now. As an example of
this mode MDC has located throughout its Engineering user
locations over 30 terminals that serve as remote access to
MCAUTO's ASP (Attached Support Processor) 360/65-75 System.
(As of this writing, various terminals include: (19) 1050's,
(28) 1130's, (7) 2780's, (4) 2260's, and various combinations
of smaller 360 model computers.) Various other related CAD
equipment, accessible via these terminals include (4) Bensen
Lehrner plotters, (1) Calcomp Plotter, (3) ORTHOMAT drafting
machines, (2) TRIDEA Line Tracers, and various NC Machine
Tools. True time-sharing facilities at MDC are provided using
TELETYPE terminals on MDC's "DIRECT ACCESS" Computing System
using a GE 420 central computer. The last mode of CAD usage
is the INTERACTIVE CRT terminals. Since the interest and
theme of this conference is in this area, the remainder of this
paper will dwell on Interactive Computer Graphics (ICG) as
related to CAD.
2. ICG HARDWARE/SOFTWARE
2.1 Equipment at MDC
Figures 4 - 7 describe the ICG equipment configura-
tion at MDC (St. Louis). The SYSTEM 360/(65) used for graphics
is part of a "dual main" three computer hookup. One computer
(Model 65) performs job-scheduling, I/O processing, and remote

Figure 5 - ICG Computer Configuration Figure 6 - ICG System Architecture

communication functions. The other two computers (models 65

and 75) perform all data processing activities and are both
on-line to centralized data files. Advantages of this system
include a continuous and flexible stream of cost-sharing
background processing, additional program core residency for

198
graphics programs using LCS, centralized data files for both
interactive and batch users, and remote data communication
terminals for high/medium speed printer, cald read, tape
punch, etc. operations. The rCG Model 65 contains 768K bytes
of central memory coupled with one million bytes of low speed
(LCS) core. Remote IBM 2250 CRT terminals are hardwired to
user sites, as far as 12,000 feet, using the IBM 2916 Long
Line Channel Adapter device. Software features include
an OS/MVT multi-programming environment, fixed size region
"fencing" for graphics, High Speed Core/LCS inter-region

Figure 7 - leG Remote Facilities Figure 8 - User In vol vemen t

communication, use of GTS (Graphic Terminal Scheduler) for job

scheduling, data editing, and debugging facilities, and use of
GSP (Graphic Subroutine Package) for application program devel-
opment.
2.2 User Involvement
One of the most difficult aspects of developing pro-
ductive CAD tools is the lack of definition and general agree-
ment of the designer's requirements. What is certainly needed
is a much closer association between the designers (users) and
those developing the systems and hardware. Neither group can
get along independently, but together, significant computer
aids to design can be developed. Our attempt to achieve this
close contact at MDC has been to directly involve CAD users
with a centralized programming staff tkat supports these func-
tions. (Reference Figure 8). The CADlCAM software group, cen-
tralized within the MCDONNELL Computer Division also has pro-
ject members in FULL TIME residence from various users (Engi-
neering Design, Loft Engineering, Manufacturing, Planning, etcJ
departments. The applications described in the following
section represents in majority the achievements of this group.

199
 2.3 CAD Overview
In order to integrate CAD techniques into the over-
all DESIGN CYCLE let's again review the DESIGN OVERVIEW PROCESS
as seen at MDC. Figure 9 illustrates the constant interchange
of information between various combinations of men and/or com-
puters at different stages of the project. Some techniques are

Figure 9 - Computer-Aided Design Overview Figure 10 - Use of Various CAD Devices

manual, some involve use of computers. Figure 10 simplifies

MDC's use of various automation techniques and I/O devices.
Figure 11 describes the interactions and development of speci-
fications as the process takes effect. Once performance data
and other criteria are properly assembled and analyzed, struc-
tural definitions begin to crystallize for further testing.
For example, in the CONCEPTUAL DESIGN phase, the initial
geometry, space allocations, and general structural arrange-
ments are established. To carry the process further, ADVANCED
DESIGN decisions are made to finalize geometry using various
optimization techniques. Inputs from various projects (aero-
dynamics, armament, equipment, power plant, thermodynamics,
stress, structures, weights, etc.) determine basic performance
and shape criteria. Input parameters consist of such items as
airfoil data, angles, areas, approximate shapes, clearances,
diameters, dimensions, envelopes, etc. Geometry and section
property analysis routines are used to verify results. Once
the DETAIL DESIGN process begins, a mathematical definition
of the design is established; i.e., LOFT Surface descriptions,
LOFT surface index Maps, LOFT Data Sheets, and both preliminary
and detail engineering drawings. Wind tunnel models are de-
veloped and the design is further tested. At this point the
MANUFACTURING cycle begins, thus involving Part Production,
Tooling, Planning, Quality Control, Inspection Assembly,
etc., operations.

200
 I do not mean to imply by the above discourse that
MDC is, by any stretch of the imagination, fully CAD oriented.
We, like all of industry, are constantly striving to improve
and advance engineering techniques. Since the design process
can readily be seen as extremely complex, change can be very
difficult, at best, to incorporate. Many of our attempts to
automate MDC processes have been highly successful. Others
have failed. With the advent of computer graphics we feel
the potential is very high. Our first thoughts were to bridge
the gaps in the overall process with a complete interactive
CAD system. We know now that this is not possible at this
time. Engineering drawings and certain manual techniques will
continue to be utilized for some time to come. Our current
philosophy with respect to CAD at MDC is to concentrate on
those individual areas that can readily augment isolated phases
of MDC design. The following illustrations sample some of
these activities and areas of concentration.
3. ICG APPLICATION AREAS
3.1 Advanced Design (Aerodynamics)
Figure 12 is an example of an Advanced Design Aero-
dynamics type of ICG application. This program is utilized to
calculate the hypersonic aerodynamic characteristics of com-
pletely arbitrary three-dimensional shapes. The program fea-
tures geometry viewing, checking, and correction capabilities,
as well as calculation and display of vehicle aerodynamics as
determined by simple modified Newtonian theory. 3D space co-
ordinates determine plane quadrilateral sections as pressure

Figure 11 - Performance Analysis and Structural Figure 12 - Hypersonic Arbitrary-Body Aerodynamic

Definitions (DESIGN ITERATIONS) ~ Application

coefficients are calculated for each quadrilateral section.

The program resolves the force in the required body axis sys-
tem and sums the distributions of each element to give all the
required AERODYNAMIC coefficients (lift, drag, LID, etc.)
to be displayed versus angle of attack.
201
 3.2 Advanced Design (Avionics)
Figures 13 and 14 are displays from a preliminary
design aid developed with the MDC Avionics Department. In
this application, the program determines vision errors relative
to the pilot eye position and geometry of the canopy windshield.
The program utilizes the MDC "centralized (LOFT Surface) data
files" for canopy definitions as the Avionics engineer goe~
directly to the CRT terminal and enters coordinates of the
pilot eye position and the canopy windshield configuration to
be analyzed. Program output consists of graphs involving a
mathematical analysis of asmyth and elevation parameters

Figure 13 - OPTICS Study (Degrees AZIMUTH vs. Figure 14 - OPTICS Study (Degrees AZIMUTH vs.
Milliradians of ERROR) Degrees ELEVATION)

versus windshield displacement distortions. Before use of

computer graphics, this program took a minimum 24 hours of
turnaround time to run one case and receive plotter output.
In a recent exercise using the CRT console, two windshields
and ten eye positions were analyzed in less than two hours
accompanied by acceptable (polaroid) hardcopy output. Another
asset of this program was the reduction of total manpower in-
volved from five persons down to one person.
3.3 Advanced Design (Structural Analysis)
One of the thus far successful CAD applications in
the aerospace industry is the analysis of structures. Figures
15 and 16 show scope displays used to check the input data for
a complex 3D structural analysis batch run. The granhics pro-
grams known at MDC as "3D Bars and Joints Geometry Checking"
have the capability of handling a maximum size structure of
300 joints and 650 bars. Figure 15 illustrates node errors on
a trimetric view of a DC-IO inboard wing section. Figure 16
denotes a typical tutorial message used to assist the operator

202
in correcting basic geometry. At present the only benefit of
the CRT system is verification of the input geometry via com-
puter drawn pictures of the aircraft shape from various viewing

Figure 15 - Structural Analysis (DC-lO Inboard· Figure 16 - Structural Analysis (DC-lO Outboard
Wing Section) Wing Section)

angles and different picture scales. Correction of the data

elements (bar, joint, node location, etc.) can be made at the
console. Once the data is satisfactorily assembled it must be
input to a batch processing program currently known at MDC as
FORMAT (Fortran Matrix Abstraction Technique). FORMAT was sub-
sequently used in this example to analyze shear and spar load-
ing conditions. FORMAT accepts data describing structural con-
figurations and external loading and generates the basic matri-
ces required in the analysis of complex structures by the
Redundant Force Method or the Direct Stiffness Method. The
Force Method Matrix Generator provides for bars that carry
axial load, bending and shear in two planes, and torsion, and
panels that carry shear only. The displacement method matrix
generator provides for bars that carry axial load, bending and
shear in two planes, and torsion, and rectangular and triangu-
lar panels that carry in-plane forces only. Both generators
provide for thermal load. Applied loads and reactions can be
either translational or rotational forces.
Numerous batch processing programs have been develop-
ed by the aerospace industry for analysis of complex structures
by matrix methods. It is our eventual hope to complete the
loop by interfacing the batch ana1ysis~portion with on-line
graphics program. The amount of data required to describe
large structures often exceeds the capacity of some structures
to involve 2000-3000 elements, about 1000 nodes, and require
the solution of upwards of 5000 simultaneous equations.
Current problems, therefore, to be overcome include the size of
data sets (FORMAT can handle matrices of order 2000 by 2000),

203
 format of data input, and interaction response criteria for
the on-line user.
3.4 Advanced Design (Structural Optimization)
As mentioned earlier, a key aspect of the design
cycle is the conceptual phase where initial geom~try, space
allocations, general structural arrangements, etc., must be
generated and evaluated to establish overall design limits.
Various optimization programs have been developed to
achieve this within a minimum elapsed time span. CADE (Compu-
ter -Aided Design Engineering) is such a program developed by
MDC. It is basically a structural optimization program uti-
lized to evaluate various configurations in terms of overall
vehicle geometry, engine placement, fuel cell-landing gear-
wing locations, etc. Not only does CADE feature the optimiza-
tion analysis but the resultant output data is directly compa-
tible with the data structure of MDC's interactive Design!
Drafting (DD) system. Dominant among, the central problem of
computer graphics is the lack of standardization in this area.
Many programs that feature related functions cannot be inte-
grated because they were developed independently with unique
and non-standard data structures.
Figure 17 describes a typical se~ of requirements and
design parameters that serve as input data to CADE. Figures
18-21 illustrate graphic display of the optimized vehicle and
various aids from the DD system that can be utilized to

REOUIREMENTS

DESIGN PARAMETERS

Figure 17 - CADE OPTIMIZATION Requirements Figure 18 - CADEIDD Vehicle OPTIMIZATION

and Design Parameters

evaluate the design. It is interesting to note from the exam-

ple of Figure 19 that the result.ant output established a wing
greater than the body section. The center line of vehicle
needed obvious adjustment. Due to the input thrust conditions
the indicated engine requirements were established. Figure 20'
204
illustrates manipulating the graphic output at the console us~
ing "scaling" and "geometric attributes" functions. Figure 21
denotes the user determining section properties (area, moments,
volume, weight, c.g., etc.) for isolated components such as
the engine.

Figure 19 - CADE/DD Vehicle (Plan/Shear Views) Figure 20 - CADE/DD Vehicle (Scaled/Geometric

Attributes)

3.5 LOFT Engineering

Many application programs, either interactive graph-
ics and/or batch mode, have been developed to support the LOFT
operation at McDonnell. The primary responsibility of LOFT
Lines Engineering Group is to translate conceptual design in-
formation into a precise mathematical definition for all ex-
ternal surfaces of the aerospace vehicle and any internal sur-
face of complex shape or that presents tooling or assembly co-
ordination problems. These programs also provide various forms
of geometric data (contour plots or coordinates, slopes, curva-
ture, volume, area, etc.) derived from the LOFT-defined shape
definition. Various programs have been developed to intersect
PLANE sections with MDC LOFT Surfaces. These PLANE sections
can be offset for milling or plotting purposes. Using matrix
transformation concepts, data can be transformed through
various systems (airplane system to wing system to NC machine
system, etc.)
Figure 22, a trimetric view of the Phantom F4 air-
craft, illustrates the complexity and mUltitude of surface
patches required to define an aerospace vehicle. Figure 23
illustrates the typical cross reference scheme employed in
correlating section zones and surface numbers. Figures (24-26)
are examples of the type of surface definitions utilized at
MDC. Figure 27 describes the coding form for "Surface Input
Definitions" in the CONVERSATIONAL/BATCH mode. Control curves

205
may be input as equation coefficients or by point-slope data.
Surface patch controls, geometry, transformation matrices,
surface bounds, and TYPE are stored using .the common routine

Figure 21 - CADE/DD Vehicle (Scaled/Section Figure 22 - Trimetric View of Phantom F-4 Aircraft
Properties)

Figure 23 - LOFT Surfaces and Surface Index Map Figure 24 - LOFT Typical CONIC Surface

GPUNCH. Figure 28 describes the coding form for "access" of

centralized LOFT Data Files, again in batch mode. LOFT pro-
grams and other related applications are fully integrated using
MDC's FLAG/APT programming system. Existing LOFT surfaces are
accessed from a disk file by the following format: "symbol=
LOFT/(surface name)". The surface names are determined by the
LOFT department and when these surface names are given an APT
~ymbolic name they may be used as part, drive and check sur-
faces in the APT/360 system. Thus various users (Tooling,
Planning, Design, etc.) can access these files through FLAG/APT

206
part programs for drafting, design layouts, NC tape verifica-
tion, milling, and inspection purposes. As seen in the exam-
ple, input data consists of APT geometry definitions, identity
of LOFT data to be retrieved from the central file, cutter
geometry and motion sequences, and coordinate system relation-
ships. Figure 29 illustrates use of this system for plotter
output. In this instance, Phantom F4 Duct Sections are plotted
and nested about the centroid.

Figure 25 - LOFT Typical RULED Surface Figure 26 - LOFT Typical CUBIC Surface

Figure 27 - SURFACE INPUT (Coding Form Figure 28 - SURFACE ACCESS (Coding Form
for Batch Mode) for Batch Mode)

The LOFT operation has not been restricted to the

above-mentioned batch mode. Since late 1967, MDC has had
successfully in operation ICG programs that augment the LOFT
function. Those who now desire access to central LOFT stored

207
 geometry have a choice of user modes; namely, graphics or
conversational batch. Among other significant benefits, the
LOFT graphics program has served as an excellent educational
tool to train and familiarize various MDC personnel with the
complexities and capabilities of our lofting techniques.
Figures 30-34 describe various production surfaces under devel-
opment at the graphics console. As an illustration of the
generality of surface definition and flexibility of transforma-
tion relationships, Figure 35 describes various patches defin-
ing a common bottle.

Figure 29 - PHANTOM F-4 DUCT Sections Figure 30 - LOFT Surfaces (Phantom F-4
(Nested About Centroid) Center Fuselage Section)

Fi.!i,ure 31 - LOFT Surfaces (DC-10 Wing Tip Section) Figure 32 - LOFT Surfaces (F-4 Internal Fuel Cell

3.6 Design/Drafting
One of the most controversial rCG applications with
respect to payoff is the development of a generalized DESIGN/

208
DRAFTING (DD) system. Many people believe that the straight-
forward speeding up of the drafting process is not adequate to
justify the large software investment and hardware costs of a
computer graphics system. Others feel that computer-aided
systems for engineering drawing are justified in the light of
drawing generation costs, turn-around time, centralized digital
data, and drawing maintenance considerations. Since most draft-
ing work tends to be repetitive and rather tedious, a computer
based system seems very applicable. Once the data is available
in digital form, analysis programs can be more readily employed.

Figure 33 - LOFT Surfaces (DC-lO Wing Plan View) Figure 34 - LOFT Surfaces (Phantom F-4
Forward Fuselage Section)

Figure 35 - LOFT Surfaces (Bottle Shape) Figure 36 - LOFT/DESIGN Comparative Analysis Chart

Figure 36 is an illustration chart summarizing a

study comparing the time history involved in generating an en-
gineering drawing at MDC using either the conventional or the

209
computer graphics approach. In the conventional mode it takes
(a) design personnel an average of one elapsed day (one actual
manhour) to define and formally prepare his requirements, (b)
10ft personnel four days (12 actual manhours) to react in
terms of computer programs, digital plots, etc., and then
(c) design another three days (9 actual manhours) at the draft-
ing boards to complete the task (such as layout internal non-
lofted structure). This totals seven elapsed days or 22 actual
manhours of effort. In the ICG mode turnaround time is almost
minimal (one and one-half day or two actual manhours). Con-
tour lines can be extracted directly by the designer from
on-line central files and 10ft personnel need not be involved.
Elapse time in the 10ft area is for drafting machine support
only. At MDC it is felt that the 7:1-1/2 elapsed time savings
is probably realistic. The 11:1 manhour savings is questiona-
ble, especially because of the experience level of personnel
involved in our study. We do, however, feel that an 8:1 man-
hour savings is possible and this is one of the major reasons
of continuing our interest and developments in the area of
DESIGN/DRAFTING.
The DD package, by the nature of the task which must
be performed, is necessarily an extremely complex, inter-
related fusion of a great number of program modules. Each
module must perform a specific function which is, in turn,
related in one or more (perhaps many) ways to the total pack-
age. Figure 37 summarizes the basic functions available in

C""HWC","'. L" t.rdl ,.,..

.. c:.. Cok AMi ...
..... . ff 1 ••• f4h hit ',J11'.t ... 111

Figure 37 - DESIGN /DRAFTING System Overview Figure 38 - OVERLAY Structure of

DESIGN/DRAFTING System

-the DD package and separates them in a general category of

DRAFTING or DESIGN activity. Specifically, the package con-
sists of the software routines which enable a user to
communicate in real time with an IBM 360 computer system, the
objective of which is the dynamic creation of a mathematical
model of a design problem. The user may, and indeed will, at
any point test and modify specifications of the model until the

210
design goal is achieved. The advantages of this man-computer
relationship are obvious; the speed and accuracy of the compu-
ter are utilized to perform the menial and repetitive tasks
normally occupying a large amount of the designer's time, thus
freeing him for the more creative aspects of the design func-
tion. Every aspect of the design process is, therefore,
enhanced.
The DD package enables the user to create a mathema-
tical model commensurate with initially available design
criteria, and to view the image of that model via the 2250
display console. As the design process progresses, the cri-
teria changes as the results of testing become available and
interfaces become more clearly defined. The user may manipu-
late and change the model correspondingly until the design goal
is achieved. Once the design goal is achieved, hfl may file
the model (drawing) for subsequent retrieval and massage. The
capability stated above requires in excess of 400K bytes of
total software which indicates the complexity and interaction
of the system structure. Figure 38 is a graphic representation
of the manner in which data and program modules are dynamically
used with computer memory. Various overlay and data paging
techniques are employed.
The remainder of this section describes some of the
application features of the DD system. Figures 39, 40, 43, and
50 illustrate basic layout facilities. Figure 40 also exempli-
fies generation of orthographic and auxiliary view projections
of an ejection rack forging after it had been machined.
Figure 41 illustrates the concept of configuration evaluation

Figure 39 _ DD Drawing (Ejection Rack Forging) Figure 40 - DD Drawing (Ejection Rack Forging
after Machining)
as various members of a support rib can be merged into the
initial drawing. Figure 42 demonstrates volume and weight
calculations on the previous shape. Figure 44 illustrates ex-
ternal cross section contour lines that were retrieved from
the on-line LOFT surface files. Figure 45 illustrates nested

211
 Figure 42 - DD Structure (Volume and Weight
Figure 41 - DD Drawing (Structural Support Rib) Calculations)

Figure 43 - DD Drawing (DC-lO Wing Section)

Figure 44 - External Contour Lines for Preliminary
Aircraft Shape

Figure 45 - Nested Section Cuts (Volume/Weigh t Figure 46 - Shape Macro (STRINGER)

Analysis)

212
 section cuts and utilization of volume/weight/wetted area cal-
culations for a given aircraft section. Figures (46-48) de-
monstrate the shape macro capability. These macros consist of
software routines which will, based upon input parameters,
generate such standard drawing elements as stringers, stiffners,
shear ties, joggles, flanges, etc. Figure 49 is a partial.

Figure 47 - Shape Macro (STIFFENbR) Figure 48 - Shape Macro (SHEAR TIE)

Figure 49 - DD Drawing (Partial Section with Stringers) Figure 50 - DD Drawing (DC-lO Inboard Rib Section)

section of the drawing with various stringers added. Figure 50

is a completed version of the DC-lO drawing (rotated 70 CCW)
with all shape macros and auxiliary sections merged. Figures
(51-54) are isolated section views on the overall drawing with
(a) Figure 51 being a typical stringer tie detail, (b) Figure
52 being a shear clip scaled-up view, (c) Figure 53 being a
shear clip end view, and (d) Figure 54 denoting three ortho-
graphic views of the shear tie. Figure 55 illustrates the use
of the DD system to solve general geometric-oriented problems.
This is a great assist to the designer who wishes to describe

213
Figure 51 - Section View (Typical Stringer Tie Detail) Figure 52 - Section View (Shear Clip Scaled Up)

Figure 53 - Section View (Shear Clip End) Figure 54 - Three Views (Shear Tie)

Figure 55 - DD Package (Geometry Layout Problem) Figure 56 - DD Package (DIMENSIONING Facilities)

214
his problem graphically as well as mathematically. Figures 56
and 57 illustrate the use of DIMENSIONING facilities within the
DD environment.

3.7 Numerical Control

MDC has done considerable work toward integrating ICG
activities with N/C tape preparation for either milling or engi-
neering layout purposes. The graphics console can become a new,
more efficient interface between engineering and manufacturing
with the computer translating a designers specifications i~to

Figure 58 - NUMERICAL CONTROL

Figure 57 - DD Package (Coordinate DIMENSIONING) (Basic 2D plus DEPTH)

Figure 59 - NUMERICAL CONTROL Figure 60 - NC GRAPPLE SYSTEM

(Pocketing Facility) (Edit Part Program)

215
 Figure 61 - NC GRAPPLE SYSTEM Figure 62 - NC GRAPPLE SYSTEM
(Error Di agnostic) (Cutter Path Display)

Figure 63 - NC GRAPPLE SYSTEM Figure 64 - NC GRAPPLE SYSTEM

(Cutter Path with Tool Axis) (3D Trimetric View of Part)

Figure 65 - NC GRAPPLE SYSTEM

(Part with Full Tool Display) Figure 66 - NC GRAPPLE SYSTEM
(x-y View of Part)

216
a form or language compatible with machine control (e.g., APT).
Our first approach was to develop a Numerical Control Graphics
(NCG) program, based on a "2D plus depth" philosophy, Figures
58 and 59 illustrate basic aspects of the package which has

Figure 67 - NC GRAPPLE SYSTEM Figure 68 - NC GRAPPLE SYSTEM

(Three Views of Part) (Blow -Up of Corner Part)

been used to develop over 60 tapes. NCG was not considered

cost effective and currently has very limited use at MDC. This
is chiefly because "2D plus depth" parts are easily programmed
on the (Conversational/Batch) APT system, and results to date
indicate that the NCG capability does not offer a simpler, or
less expensive, procedure for producing these kinds of parts.
Figures (60-68) denote our current activities in this area.
The system, called GRAPPLE (Graphic Representation of APT Part
Programming Language Execution), represents a full 3D NC
capability fully integrated with the MDC FLAG/APT system. The
GRAPPLE capability is greater than or equal to the present
symbolic APT system with full interface to MDC's LOFT Surface
Central Files. As can be seen in the illustrations, some of
the features of GRAPPLE include: (a) Interactive Graphic
Communication, (b) Symbolic Card Input, Cc) Data Inquiry and
Edit, Cd) Alphanumeric Data Display and Print, and Ce) Part
and Cutter Location Display and Plot.
4. SUMMARY
This paper makes no attempt at completeness. No firm
statistics, with respect to console utilization, cost savings,
etc., of which all of industry is seeking, are giveil. This
paper was simply an essay that tries to capture and communi-
cate some of the atmosphere surrounding the DESIGN process,
the CAD evolution, and development of ICG techniques at MDC.

217
 GRAPHICS ORIENTED FRACTIONATOR
ANALYSIS AND SIMULATION TOOL (GOFAST)

D. S. Sewell

Computer Communications Department, Mobil Oil

Corporation, 150 East 42nd Street, New York, 10017,
U.S.A.

ABSTRACT

This paper describes a development project intended to evaluate the

suitability of using computer graphics for the real time solution of tech-
nical problems arising during the normal conduct of business. One of the
areas selected for computer graphics development was the area of engineer-
ing design and simulation programs, where man-machine interaction can be
very fruitful. These programs could incorporate the fast response and
visual capabilities of the graphics Emviromnent to form more effective de-
cision making tools for the engineer. In particular, the fractionation
model was selected for erarhics adaptation because of the opportunity for
significant savings in capital cost and operating expenses, which should
result from improved fractionator design.
The Graphics Oriented Fractionator Analysis and Simulation Tool (GOFAST)
is a computer program that combines a multifeed, multidraw fractionation
tower program with user oriented graphic panels for immediate input and
editing of data, control of program execution, and meaningful output of
plots and tabulations. The graphics panels displayed throughout the execu-
tion of the program follow a consistent format enabling the user to find
information readily. Display messages explain the actions he is allowed
to take at the graphics device. Whenever the user performs a~ action at
the console, the program alters the display on the screen to inform the
user that his action has been received by the program. Parametric studies
of design variables are provided by a case study mechanism. The program
will develop upon request a number of cross plots of case results which
allow the process engineer to rapidly select the preferred combination of
variables.

INTRODUCTION

Fractionation is a widely used petrochemical process by which the com-

ponents of feed mixtures are separated into product streams with specified

219
purity requirements. Thus fractionation is an essential process in the
operation of a petrochemical plant. In addition, fractionation equipment
represents a large portion of the total capital cost of a refinery or
chemical plant. This portion can be as much as 25 percent of the total
capital cost. The purpose of this paper is to describe the Graphics
Oriented Fractionator Analysis and Simulation Tool (GOFAST), a computer
program that utilizes graphic capabilities in conjunction with fractiona-
tion computations. It is assumed that the reader is familiar with the
fractionation algorithms, and only the graphic portions of the program will
be described here. The goal of this program is to provide the user, in
this case a process engineer, with a modeling tool having fast response
capabilities to make the engineering analysis a smoothly operating process.
The fractionation program was selected as one of the areas of computer
graphic development work because of its complexity, which lends itself to
user manipulation of many variables in a real time mode; its frequency of
use, which implies that any incremental savings in run time will sum to a
significant total savings in computer usage; and its potential for savings
in the capital cost area.

Program Goals

The program was designed to meet the following goals:

a. To be a flexible problem solving tool which will give a user
great freedom in obtaining an effective design; to allow a user
at the graphics console wide variation in handling input/output
data and in controlling the execution of the program.
b. To give the user the ability to obtain a better analysis from one
or more sessions at the graphics device than that obtained from
batch job submittals.
c. To give the user the ability to shorten calendar time required for
a fractionation solution by providing a fast response capability
that allows maximum work accomplishment from one session at the
console.
d. To give the user the ability to shorten total computer run time
needed to solve a problem by allowing decisions to be made after
each computation, thus minimizing the total number of cases that
need be calculated.
e. To give the user the ability to shorten computer run time by pro-
viding him with procedures that allow immediate correction of any
errors during one session at the console, thus minimizing the
total number of jobs that need be run.
f. To present information to the user in the most meaningful visual
format (plots, tabulations, diagrams, and messages); and to make
maximum use of the graphics unit as a display device for graphic
information as well as alphameric information.
g. To minimize user wait time by taking advantage of the graphics de-
vice ability to transmit information to the screen much more
rapidly than a serial printing device such as the teletype; to pre-
format the panels in such a way that user typing time is minimized.

220
 h. To minimize total user time at the console by using the fast re-
sponse quality of the light pen and function key features of the
graphics device.

~abilities

The following features of the GOFAST program are available to the user
at the graphics console:
a. Input and error checking of component properties, vapor-liquid
equilibrium constants, enthalpy values, tower specifications,
and feed stream data.
b. The ability to change any input item previously entered, to
delete selected options, and to select a new set of options.
c. Generation of technical data values for equilibrium constants
and enthalpies for each component over the entire temperature
range of the fractionator.
d. Solution of a multifeed, multidraw fractionation tower by means
of rigorous stage-to-stage calculations with heat and material
balances for a steady state operation.
e. Displays of tower parameter stage-to-stage profiles for a cal-
culated base case; displays of componential product streams for
overhead, bottoms and sidedraws.
f. Input and display of tower crossplots that allow the user to
observe the functional relationship between tower variables.
g. Hardcopy printout, as a user option, of input summary panels,
stage-to-stage componential flows, and crossplot summaries.
h. An alternate source of data input for the base case so that
the user need use the graphics keyboard only for entering
changes in data.

GRAPHICS PANEL FORMAT

Panel Definition

The graphics panel as used in the GO FAST Program shall be defined as a

group of display areas appearing concurrently on the graphics screen and
remaining on the screen until changed either by program action or by user
action. The user may alter the appearance of a panel by typing in data
from the alphameric keyboard causing the data to appear on the screen im-
mediately, or the user may perform a light pen detect on an item displayed
causing other items to appear. Furthermore, he may delete the display of
the current panel and cause display of a new panel by performing a light
pen detect on a word that functions as a panel switching control.

Panels displayed in the GOFAST Program are of two main types:

User Action Panels and Program Action Panels. The User Action Panel, as
the name implies, allows the user to alter the appearance of a panel or to
switch to another panel. The Program Action Panel is a one line message
informing the user that the program is engaged in computation, reading, or
printing activities.

221
User Action Panels

All panels that require user activity have been designed to conform to
the same format. The format consists of the following display areas:
Title and Panel Number, Hessage Area, Data Display Area, and Control Word
Area. These areas always appear in the same relative position within the
panel and thus give the user a consistent format to observe throughout his
use of the many panels that make up the GOFAST Program. By having the same
type of information located in the same area on all panels, the user's re-
sponse and decision making should be more efficient and more automatic,
thus leaving him free to concentrate on the problem itself rather than on
the tools of problem solving. Examples of User Action Panels may be found
on Figures 4 through 16. The format is composed of the following areas
(see Figure 1):
a. Title and Panel Number.
This area is always the top line of each panel, with the panel
number appearing on the right hand corner.
b. Message Area.
The Hessage Area appears immediately below the Title and Panel
Number and contains several messages that inform the user what
actions he may take during the display of the panel and how he
may switch panels. Because the messages are selected from a stan-
dard set of user action messages, terminology and directions are
consistent for all panels. The message area may also contain warn-
ing messages which will inform the user to take immediate corrective
action.
c. Panel Data Area.
The Data Area is located in the center portion of each panel and
makes up the main body of the panel. The information in this area
may be any of three types: a menu, a data display, or an input dis-
play. The menu is a display of user options in which the user may
select one or more of these options to control further action of the
GOFAST Program. An example of a menu may be found in the Component
Property Panel Cl (Figure 6), in which the user may select any com-
ponents required from the menu of standard components. The second
type of data, the data display, may be in plot form or in tabulated
form. The user is given the opportunity of preserving this computed
information in hardcopy form at selected points during the program.
The third type of data, the input display, allows the user to type
input data or to change previously entered data. The user always ha
the opportunity to correct any typing errors before sending the data
to the program via the END key attention.
d. Control Word Area.
The Control Word Area is located at the bottom line of each
panel. The one line display may consist of one to three con-
trol words, each word separated by a slash:

/PROCEED/ /PAGE BACK/

The functions of control words are panel switching, computa-

tion control, and program logic control.

222
 PANEL TITLE TOWER DESIQN PANEL NO

MESSAGE
AREA

PANEL
DATA
AREA

CONTROL WORD AREA

Figure 1

Layout of User Action Panel

Program Action Panels

Program Action Panels are panels composed of a one line message dis-
played for information purposes only. The user is required to wait and
may not perform any activity at the graphics console while this type of
panel is being displayed. Program Action Panels are displayed to elim-
inate confusion by notifying the user that the program is operating cor-
rectly during noticeable pauses in graphic activity.
Examples of the special one line wait messages are:

"TWR READ IN PROGRESS"

"TWR CALC IN PROGRESS ,.
"TWR PRNT IN PROGRESS"
"TOWER COMPUTATION IN PROGRESS"

PROGRAM LOGIC

Overall Program Logic

The GOFAST Program is composed of several groups of subroutines that

perform the following functions:
a. Display and image control of job title, Al Panel.
b. Display and image control of component property input, C Panels.

223
 c. Display and image control of data table input, D Panels.
d. Display and image control of tower input T Panels.
e. Display and image control of feed stream input, F Panels.
f. Editing of input data for all input panels.
g. Computation of component properties and technical data tables.
h. Computation of the tower base case.
i. Display and image control of base case output, U Panels.
j. Conversion, editing, and hardcopy printout of the base case.
k. Display and image control of crossplot input, P Panels.
1. Computation of crossplot data.
m. Display and image control of crossplot data, P Panels.
n. Display and image control of the job control menu, A2 Panel.
Figures 2 and 3 show the interaction between program activity and user
activity. After the user has typed in all input data or changed pre-
viously typed data, the editing routines display warning or error messages
allowing the user to take immediate corrective action. When the user with
the aid of editing routines has produced acceptable input, the program
computes a base case. The user can then request the display of base case
output panels.
After studying the base case results, the user has the option of re-
turning to the input panels to change any input item and then recoTIlputing
a new base case; or he may elect to perform a tower cross plot. If he
chooses the crossplot option, the program displays menus from which he
selects appropriate independent and dependent variables for plotting pur-
poses. Note that the original input specifications are scanned and edited
carefully so that allowable variables only are displayed on the option
menus. After the user types in a plot increment (or decrement) and the
number of points to be plotted, the program enters a computation loop that
increments input, computes a tower, converts and stores the selected out-
put until all cases are computed and stored. The program then displays
the crossplots as directed by the user who has the option of switching
back and forth from one plot to another until he has made a decision.
The user at this time may elect to keep the same base and return to the
input panels for yet another alteration in base case input data, or he may
elect to choose a new base case on the basis of observed crossplots with a
new set of independent and dependent variables. On the other hand, he may
want to display and print out detailed output of his new base case and then
end the program, having found an optimum solution for his particular
fractionation problem.

A Panels - Job Title and Control

The Job Title Panel, Al, allows the user to type in the job title and
two switch settings, the input switch and the debug switch. The input
switch sets the source of base case input data as data cards or the alpha-
meric keyboard at the graphics console. Note that input changes to the
base case input are always typed in from the alphameric keyboard. The
debug switch determines the extent of intermediate output to be produced
as an aid in correcting any computational or convergence problems. This

224
output is normally used only if the user elects to analyze the problem
away from the graphics console.
The Job Control Panel, A2, presents a menu of control options that
allow the user to direct the sequence of execution of the main components
of the GOFAST Program. The user may select an input option to change any
data previously entered, or he may select the base case computation option,
or he may select the crossplot display option. In addition, the user may
elect to end one tower computation and start a second tower. Finally, the
user may use this panel to stop job execution and return to the graphics
job processor.

C Panels - Component Property Input

The Component Property Input Panels allow the user to select the com-
ponents to be used during the tower calculation. The components may be
selected from a menu of standard components whose properties are stored
within the program. Special components may also be selected and proper-
ties typed in for any components not shown in the standard component menu.
After the components have been selected, a summary of these components
together with the associated properties is displayed with an option of
obtaining a hardcopy output. The user decides to correct and change his
selections by restarting the series of property panels, deleting previous
selections, and making new selections.

D Panels - Data Table Input

The Data Table Input Panels give the user the ability to describe
the parameters needed to generate technical data tables of vapor-liquid
equilibrium values, vapor enthalpies, and liquid enthalpies. In addition
to typing in table parameters such as pressure and temperature, the user
may elect to overlay individual values in the generated data tables through
the use of special overlay panels. A summary panel is then displayed with
the option of obtaining a hardcopy printout of the data table parameters
and all data points. During the display of the summary panel, the user may
elect to change any input selection or overlay value.

T Panels - Tower Input

The Tower Input Panels allow the user to enter tower parameters and to
describe the tower configuration e.g. number of stages, number and location
of feeds, sidedraws and exchangers, condenser, and reboiler. Most tower
input panels display a diagram of the tower showing the selected tower
geometry; any user input resulting in changes to the tower geometry will be
displayed in an updated diagram. After the user has described a configura-
tion for a tower, the program determines which specification panels are to
be displayed by inspecting the configuration input. Specification panels
are as follows: Overhead Product Data Panels, Bottoms Product Data Panels,
Sidedraw Data Panels, Heat Exchange Data Panels, and Base Component Panel.
A summary panel and the tower configuration diagram is then displayed with
the option of obtaining a hardcopy printout. The user may change any in-
put by electing to display an input change and restart panel. An editing

225
 MENU =0; LINK = 0; SET INPUTLIST

ENTER TITLE & INPUT CODE

SELECT NEW BASE CASE

....- - - - - - \ : - - - 1 RESTART PROCEED

Note: User Activities are shown in bolcl face print.

FIGURE 2 OVERALL LOGIC DIAGRAM

226
 NOTE:
CPANL=COMPONENT PROPERTIES
DPANL= DATA TABLES
TPANL = TOWER SPECS
FPANL = FEED STREAM

= 1 OLD INP T

NEW INPUT

DISPLAY INPUT PANEL "I"

DISPLAY INVALID OMIT

ERROR ERROR
MESSAGE MESSAGE

NO

SET "I" YES

FOR NEXT
PANEL DISPLAY SUMMARY PANEL "N" I-------!~

END OF LIST

Note: User A ctivities ore shown in bold face print

FIGURE 3 INPUT PANEL LOGIC DIAGRAM

227
program checks all tower input for validity and consistency and displays a
panel showing relevant error messages. The user may then start the pro-
cedure for making tower input corrections.

F Panels - Feed Stream Input

The user may type in all the componential flows and enthalpy level for
each feed to the tower. As the user types in the feed data, a configura-
tion diagram is displayed together with the name and location of the feed
currently being displayed for input. If there is more than one feed for
the tower, the program will continue to display feed stream panels until
all feeds have been entered.

U Panels - Tower Output

The first output panel displays the heat balance summary for the base
case currently displayed, e.g. feeds, reboiler, sidedraws, condenser, heat
exchangers, bottoms product, and overhead product. At this time, the user
may elect to obtain a hardcopy printout of a stage-to-stage tabulation of
the tower performance. In addition, the user may elect to display selected
tower output variables. A menu is displayed from which the user selects
output options to be displayed; examples of such options are temperature
profiles, L/V ratio profiles, product data tabulations, profiles of com-
ponential flows at each stage, and profiles of total flows at each stage.
While the tower output profiles and tabulations are being displayed, the
user has the option of paging forward to a new display or paging back to
review the previous display. The user may at any time elect to terminate
the display of the output panels and proceed to another section of the pro-
gram. He may also elect to terminate the current output options and select
a new set of output panels to be displayed for the current base case.

P Panels - Tower Crossplot Data

The user selects one independent variable and up to three dependent

variables from tower parameter menus. The parameters displayed are only
those that are compatible with the input specifications. For example, if
the user entered as input a condenser having an overhead product specifica-
tion of total flow, mols/hr, the ind~pendent variable menus will display
only the total flow parameter for the the overhead option, but the depen-
dent variable menu will show all possible overhead parameters except total
flow. Having selected the plot variables, the user types in the increment
or decrement value for the independent variable along with the number of
points that he wishes computed and plotted. The program then begins the
crossplot computation loop. During computation, a program action panel is
generated with the message
"TOWER COMPUTATION IN PROGRESS"
displayed on the screen. After computation is complete, the crossplots
selected are then displayed, and the user may page forward and back between
crossplots. At any time during the viewing of the crossplots, the user may
elect to display a summary of crossplot data and to select a new base case

228
as well as obtain hardcopy printout of the summary. He may then restart the
crossplot selection and select an entirely new set of plots to be displayed
either for the same base case or a new base case. He may alternately de-
cide to terminate the crossplot activity and return to the main control
panel, A2, to execute a different portion of the GOFAST Program.
If the user elects to continue crossplot activity, he may do so by the
process of selecting variables, displaying crossplots, and selecting new
base cases until he is satisfied with the results of the tower design or
performance of the tower variables. The interaction of the user, the tower
computation routines, and crossplot panels can allow a tower design to be
optimized in a minimum amount of user and computer time because the results
of the user's selection are made available to him as soon as the tower com-
putation is ended. The user can then proceed to make further selections
based on the information from the previous calculations rather than arbi-
trarily submitting a number of cases in an area of uncertain results.

EXANPLES OF GRAPHICS PANELS

The panel diagrams shown in Figures 4 through 16 represent only a por-

tion of the entire set of panels. The diagrams shown are samples of dis-
plays from actual computer runs. The data displayed on anyone panel is
not necessarily related to data displayed on other panels because samples
were taken from a number of different runs.

HINIHUH SYSTEH REQUIREHENTS

The following requirements are considered to be minimum for execution

of the GOFAST Program:
1. Hachine speed must be equivalent to IBH/360 HOD 50 or faster.
2. Core size is 360K bytes.
3. IBH 2250 Graphics device Hodel 1 equipped with the character gen-
erator, alphameric keyboard, light pen, and programmed function
keyboard.
4. IBH System/360 OS Graphic Programming Services for FORTRAN IV.
5. Alternate input device such as card reader or tape.
6. Alternate output device: the printer.

CONCLUSIONS

Experience gained from sample runs with the GOFAST program and other
engineering applications show that computer graphics furnishes an excel-
lent environment for the on-line solution of technical problems. When
compared to serial printing devices such as the teletype, the fast re-
sponse characteristics of the graphics device together with the visual

229
impact of user oriented diagrams and plots are clearly superior for a
conversational mode of problem solving. Naximum effectiveness has been
achieved from the graphics device by using a tutorial approach. User
orient~d messages, nomenclature, and diagrams are continuously displayed
to obvi~~the use of reference materials such as an instruction manual.
Thus, the user is free to concentrate his energies on the solution of the
given fractionation problem. The above conclusions were based on graphics
runs executed in a limited use, experimental environment. Thus, it is
anticipated that an even greater impact of graphic capabilities will be
realized when GO FAST and other graphics applications are made available
in a full production mode.

ACKNOWLEDGEHENT

The author desires to express gratitude to colleagues in the computer

and engineering departments of Mobil Oil Corporation for their help in
the preparation of this paper.
Permission of Mobil Oil Corporation to publish this paper is grate-
fully acknowledged.

230
 JOB INPUT DATA TOWER DESIGN PANEL Al

TYPE DATA ONLY WHERE CURSOR (UNDERLINE) APP!,=ARS.

PRESS JUMP, ADVANCE, AND BACKSPACE KEYS TO POSITION CURSOR.

PRESS THE END KEY AFTER ALL DATA HAS BEEN TYPED.

INVALID DATA WAS ENTERED AT THE BLOCK LOCATED BY THE CURSOR.

PLEASE RETYPE THE DATA BLOCK, THEN PRESS THE END KEY.

JOB TITLE = SAMPLE FRACTIONATION RUN Nd. 14A 3/5/69

INPUT SWITCH = AA
TYPE IN
AA FOR NEW JOB, INPUT FROM 2250 CONSOLE.
CC FOR OLD JOB, INPUT FROM PEDLAN DATA CARDS.

DEBUG SWITCH = AA
TYPE IN
AA FOR FULL DEBUGGING
BB FOR PART DEBUGGING

FIGURE 4

SAMPLE LAYOUT OF PANEL A1

231
 JOB CONTROL PANEL TOWER DESIGN PANEL A2

SELECT AN ITEM BY LIGHT PEN DETECT ON ITEM NAME.

DELETE AN ITEM BY LIGHT PEN DETECT ON XXX NE:XT TO ITEM.

STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

XXX COMPONENT PROPERTIES

EQUILIBRIUM K & ENTHALPY DATA

TOWER INPUT DATA

FEED STREAM DATA

TOWER CALCULATION AND OUTPUT

PARAMETER CROSSPLOT

END A JOB, START NEW JOB

RETURN TO GRAPHICS MONITOR

/ PROCEED /

FIGURE 5
SAMPLE LAYOUT OF PANEL A2

232
 \

COMPONENT PROPERTIES TOWER DESIGN PANEL C1

SELECT ITEM BY LIGHT PEN DETECT ON ITEM NAME.

DELETE ITEM BY LIGHT PEN DETECT ON XXX NEXT TO ITEM.

DISPLAY MORE ITEMS BY LIGHT PEN DETECT ON /NEXT PAGE/.

STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

XXX HYDROGEN IN NAPHTHA TRANS·2 BUTENE

HYDROGEN IN BENZENE CIS·2, BUTENE
HYDROGEN IN TOLUENE ME MERCAPTAN
HYDROGEN IN REFORMATE NEO·PENTANE
HYDROGEN (SPECIAL) 1, 2·BUT ADI EN E
NITROGEN IN N/G T.GT.40F 3·METHYL·1·BUT ENE
NITROGEN IN N/G T.L T.4CF XXX ISO PENTANE
XXX METHANE IN L/HC T.GT.40F l·PENTENE
METHANE IN MID CONT OIL 2·METHYL·1·BUT ENE
METHANE IN L/HC T.LT.40F XXX N.PENTANE
METHANE IN GASOLINE TRANS·2·PENTENE
METHANE IN CY HEXANE CIS·2·PENTENE
METHANE IN BENZENE 2·METHYL·2·BUTENE
METHANE IN TOLUENE CYCLOPENTANE
METHANE IN REFORMATE ISO HEXANE
METHANE IN C02 l·HEXENE
OXYGEN N·HEXAN E
WATER/STEAM METHYL CYCLOPENTANE
CARBON MONOXIDE BENZENE
C02 IN NAT GAS OR DIST CYCLOHEXANE
C02 IN CH4 TO C3H8 ISO HEPTANE
ETHENE (ETHYLENE) l·HEPTENE
ACETYLENE (ETHYNE) N.HEPTANE
XXX ETHANE ISO OCTANE
H2S IN NAPHTHA METHYLCYCLOHEXANE
H2S I N GAS 01 L ETHYL CYCLOPENTANE
H2S IN PEGASUS CRUDE TOLUENE
PROPENE (PROPYLENE) 1,1·DIMETHYL CYCLOHEXANE
XXX PROPANE 1·0CTENE
PROPANE IN BENZENE N·OCTANE
PROPADI ENE ETHYL CYCLOHEXANE
XXX ISO BUTANE ETHYL BENZENE
ISO BUTENE P·XYLENE
l·BUTENE M·XYLENE
1,3.BUTADIENE O·XYLENE
XXX N·BUTANE I·NONENE
/ PROCEED I INEXT PAGE I
FIGURE 6

SAMPLE LAYOUT OF PANEL CI

233
 COMPONENT PROPERTI ES TOWER DESIGN PANEL C6

PRESS FUNCTION KEY NO.1 TO OBTAIN HARD COpy OUTPUT.

DISPLAY LAST PANEL BY LIGHT PEN DETECT ON IPAGE BACK/.

CHANGE INPUT DATA BY LIGHT PEN DETECT ON IRESTART/.

STOP SELECTIONS BY LIGHT PEN DETECT ON IPROCEED/.

NO. COMPONENT NAME PPB AT PPB AT CRIT T CRIT P

60 F NBP DEGR F PSIA

01 HYDROGEN IN NAPHTHA 24.53 24.53 -400.00 188.00

02 METHANE IN L/HC T.GT.40F 87.62 148.61 - 115.77 673.09
03 ETHANE 148.96 191.51 90.31 709.79
04 PROPANE 177.95 203.57 206.25 617.39
05 ISO BUTANE 197.37 208.37 274.95 529.09
06 N·BUTANE 204.83 210.86 305.61 550.69
07 ISO PENTANE 218.99 215.98 370.09 483.00
08 N·PENTANE 221.24 213.63 385.91 489.50

/ PROCEED / /PAGE BACK / / RESTART /

FIGURE 7

SAMPLE LAYOUT OF PANEL C6

234
 DATA TABLE PANEL TOWER DESIGN PANEL D5

PRESS FUNCTION KEY NO. 1 TO OBTAIN HARD COPY OUTPUT.

CHANGE INPUT DATA BY LIGHT PEN DETECT ON /RESTART/.

DISPLAY LAST PANEL BY LIGHT PEN DETECT ON /PAGE BACK/.

DISPLAY NEXT PANEL BY LIGHT PEN DETECT ON /PROCEED/.

DATA TABLE NUMBER

SUMMARY

PRESSURE = 475,000 PSIA

RANGE OF TEMPERATURE = -120.00 ·F 330.00 F

BOTTOM 4 POINTS = 5000.00 PSIA

MIDDLE 3 POINTS = 5000.00 PSIA
TOP 4 POINTS = 650.00 PSIA

COMPONENT EQ H H
K LlQ VAP
HYDROGEN IN NAPHTHA 0 0 0
METHANE IN LiHC T.GT .40F 1 1 0
ETHANE 0 0 0
PROPANE 0 0 0
ISO BUTANE 0 0 0
N·BUTANE 0 0 0
ISO PENTANE 0 0 0
N·PENTANE 0 0 0

o = ORIGINAL DATA

1 = DATA HAS BEEN OVERLAID

/ PROCEED / /PAGE BACK / / RESTART /

FIGURE 8
SAMPLE LAYOUT OF PANEL 05

235
 FEED STREAM DA,A TOWER DESIGN PANEL Fl

TYPE DATA ONLY WHERE CURSOR (UNDERLINE) APPEARS.

TYPE DECIMAL POINT IN DATA BLOCKS.

PRESS JUMP, ADVANCE, AND BACKSPACE KEYS TO POSITION CURSOR.

PRESS THE END KEY AFTER ALL DATA HAS BEEN TYPED.

INVALID DATA WAS ENTERED AT THE BLOCK LOCATED BY THE CURSOR.

PLEASE RETYPE THE DATA BLOCK, THEN PRESS THE END KEY.

FEED Fl AT STAGE 13 MOLS/HR.

HYDROGEN IN NAPHTHA 0.001

METHANE IN L/HC T .GT .40F 27.3
ETHANE 118.3
PROPANE 159.2 -"1+----"---.. DL
ISO BUTANE 144.7
N-BUT ANE 367.2
ISO PENTANE 5.0
N-PENTANE 0.6 F1 ~t--13

17 Ql

25 SDI
F2

FIGURE 9

SAMPLE LAYOUT OF PANEL Fl

236
 TOWER INPUT DATA TOWER DESIGN PANEL T1

TYPE DATA ONLY WHERE CURSOR (UNDERLINE) APPEARS.

TYPE DECIMAL POINT IN DATA BLOCKS.

PRESS JUMP, ADVANCE, AND BACKSPACE KEYS TO POSITION CURSOR.

PRESS THE END KEY AFTER ALL DATA HAS BEEN TYPED.

INVALID DATA WAS ENTERED AT THE BLOCK LOCATED BY THE CURSOR.

PLEASE RETYPE THE DATA BLOCK, THEN PRESS THE END KEY.

NO. OF STAGES (MAX = 50.) 30.

2 DL
INCLUDES REBOILER AND
CONDENSER, IF REQ'D.

PRESSURE OF OVERHEAD 475.0

PRODUCT, PSIA. F1 13

PRESSURE DROP ACROSS 0.0

EACH STAGE, PSI. 17 Q1

ESTIMATED TEMPERATURE OF 100.0

TOP STAGE, DEG. F.

ESTIMATED TEMPERATURE OF 250.0

BTM. STAGE, DEG. F. 25 SDI
F2
TRAY SPACING, INCHES 24.0

TRAY TYPE
TYPE IN l.
l.SIEVE-VALVE TRAY
2.BUBBLECAP

FIGURE 10
SAMPLE LAYOUT OF PANEL Tl

237
 TOWER INPUT DATA TOWER DESIGN PANEL T3

TYPE DATA ONLY WHERE CURSOR (UNDERLINE) APPEARS.

TYPE DECIMAL POINT IN DATA BLOCKS.

PRESS JUMP, ADVANCE, AND BACKSPACE KEYS TO POSITION CURSOR.

PRESS THE END KEY AFTER ALL DATA HAS BEEN TYPED.

INVALID DATA WAS ENTERED AT THE BLOCK LOCATED BY THE CURSOR.

PLEASE RETYPE THE DATA BLOCK, THEN PRESS THE END KEY.

** TOWER OPTIONS **

XXX CONDENSER

XXX REBOI LER -++_---1._--+ DL

XXX FEED F1 STAGE 13.

XXX FEED F2 STAGE 27.

F1 13

17 Q1

XXX HEAT EXCH Q1 STAGE 17.

25 SOl
F2

XXX SIDEDRAW 01 STAGE 25.

FIGURE 11

SAMPLE LAYOUT OF PANEL T3 (PART 2)

238
 TOWER INPUT SUMMARY TOWER DESIGN PANEL T10

PRESS FUNCTION KEY NO. 1 TO OBTAIN HARD COPY OUTPUT.

CHANGE INPUT DATA BY LIGHT PEN DETECT ON /RESTART/.

STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

NUMBER OF STAGES = 18.0

OVHD. PROD .• PRESS. PSIA = 47S.il
STAGE PRESSURE DROP, PSI = 0.0
ESTIMA TED TEMP. TOP STAGE = 100.0
ESTIMATED TEMP. BTM STAGE
BASE COMPo = ISO BUTANE
= 250.0

OVHD PRODUCT PHASE = VAP+LlQ

TRAY TYPE 0=SIEVE/1=BUBCP = 1.
TRA Y SPACING, INCHES = 24.0 DL
DATA TABLE NO. = 01

CONDENSER PRES.DRP,PSI = 0.0

REBOILER PRES.DRP,PSI = 0.0 F1 13

OVHD.
N1
PROD.
COMPo =
MOLS/HOUR
ISO BUTANE
= 7.690 17 Q1
N2 COMPo = ISO PENTANE
01 COMPo = (NOT GIVEN)
02 COMPo = (NOT GIVEN)

BTMS. PROD. MMBTU/HR = 5.8381

N1 COMPo = (NOT GIVEN) 2S SOl
N2 COMPo = (NOT GIVEN) F2
D1 COMPo = (NOT GIVEN)
D2 COMPo = (NOT GIVEN)

HEAT EXCH Q1 MMBTU/HR = -2.6

HEAT EXCH Q2 (NOT GIVEN)
HEAT EXCH Q3 (NOT GIVEN)
HEAT EXCH Q4 (NOT GIVEN)
SIDEDRAW SDI LlQ. FRACT. = 0.05
SIDEDRAW 5D2 (NOT GIVEN)
STEAM COMPo = (NOT GIVEN)

/ PROCEED / / RESTART /

FIGURE 12
SAMPLE LAYOUT OF PANEL Tl0

239
 TOWER OUTPUT DATA TOWER DESIGN PANEL U1

PRESS FUNCTION KEY NO. 1 TO OBTAIN HARD COPY OUTPUT.

DISPLAY MORE ITEMS BY LIGHT PEN DETECT ON /NEXT PAGE/.

STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

***** TOWER DID NOT CONVERGE ERRORS IN OUTPUT DATA *****

HEAT BALANCE SUMMARY MMBTU/HR

HEAT IN HEAT OUT

REBOILER DUTY 5.8381

FEED F1 TO STAGE ~ 8.2100
CONDENSER DUTY 3.8624
BOTTOMS PRODUCT 9.1356
OVERHEAD PRODUCT, LIQUID 1.0501

TOT AL = 14.0481 14.0481

I PROCEED I INEXT PAGE I

•
FIGURE 13

SAMPLE LAYOUT OF PANEL U1

240
 TOWER OUTPUT PROFILE TOWER DESIGN PANEL U4

DISPLAY NEXT PANEL BY LIGHT PEN DETECT ON /NEXT PAGE/.

DISPLAY LAST PANEL BY LIGHT PEN DETECT ON /PAGE, BACK/.
STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

STAGE NO. EQUILIBRIUM TEMPERATURE OF EACH STAGE.

01 COND
02
--.....
"""',
03
04
05 -F1

'",
06
07
08 \
09
10
11
12
13
14
15
16
17
18
19
20 ,
\

,
21
22
~
23 \.
24
25 -RBLR ~
0.0 30.0 60.0 90.0 120.0 150.0 180.0 210.0 240.0 270.0 300.0
DEGREES FAHRENHEIT
I PROCEED I INEXT PAGE I IPAGE BACK I

FIGURE 14

SAMPLE LAYOUT OF PANEL U4

241
 TOWER CROSSPLOT DISPLAY TOWER DESIGN PANEL PS

DISPLAY NEXT PANEL BY LIGHT PEN DETECT ON INEXT PAGEl

DISPLAY LAST PANEL BY LIGHT PEN DETECT ON IPAGE BACKI
DISPLAY SUMMARY BY LIGHT PEN DETECT ON ISUMMARY I.

CONDENSER OR TOP STAGE TEMPERATURE, DEG.F

A
X - 23.7 A
I :/
S
23.6 /
V.
~

/
~
I- 23.S

I- 23.4

~ 23.3
V
/>
I- 23.2
/
./~

V
- 23.1

- 23.0

- 22.9 ,/ ,
- 22.8
/
La
47S.0 476.0 477.0 478.0 479.0 480.0 481.0 482.0
X-AXIS OVERHEAD PRESSURE, PSIA
/ SUMMARY /NEXT PAGE / /PAGE BACK /

FIGURE 15

SAMPLE LAYOUT OF PANEL P5

242
 TOWER CROSSPLOT SUMMARY TOWER DESIGN PANEL P6

PRESS FUNCTION KEY NO. 1 TO OBTAIN HARD COpy OUTPUT.

SELECT AN ITEM BY LIGHT PEN DETECT ON ITEM NAME.

DELETE AN ITEM BY LIGHT PEN DETECT ON XXX NEXT TO ITEM.

DISPLA Y LAST PANEL BY LIGHT PEN DETECT ON /PAGE BACK/.

CHANGE INPUT DATA BY LIGHT PEN DETECT ON /RESTART /.

STOP SELECTIONS BY LIGHT PEN DETECT ON /PROCEED/.

CASE INDEPENDENT DEPENDENT VARIABLES

NAME VARIABLE 2 3

BASE 475.0000 22.73675 -3.86242 0.23758

476.6000 22.92419 -3.84551 0.23740

2 478.2000 23.09863 -3.82833 0.23723

XXX 3 479.8000 23.34277 -3.81113 0.23705

4 481.4000 23.55641 -3.79392 0.23688

5 483.0000 23.76768 -3.77668 0.23671

INDEPENDENT VARIABLE IS
OVERHEAD PRESSURE, PSIA

DEPENDENT VARIABLES ARE

1 CONDENSER OR TOP STAGE TEMPERATURE,DEG.F
2 CONDENSER DUTY, MMBTU/HR
3 BOTTOMS COMPONENT MOL. FRACTION
COMPONENT IS ISO BUTANE

/ PROCEED / / RESTART / /PAGE BACK /

FIGURE 16

SAMPLE LAYOUT OF PANEL P6

243
 A DISPLAY SYSTEM FOR PROCESSING
ENGINEERING DRAWINGS
'THREAD' - Three-dimensional Editing and Drawing
D. K. Ewing and D. W. Tedd

Computer-aided Design Division, Ministry o/Technology,

East Kilbride, Glasgow, Scotland.

INTRODUCTION

The application of computer displays for processing engineering drawings

has often been considered but practical systems have been difficult to
achieve because of the limited resolution of the display screen and its
associated device - the light pen. However, these disadvantages can be off-
set to some extent by data structure techniques which link the displayed
points and lines with their exact dimensional values instead of their trun-
cated screen coordinate values. The essential properties of these struc-
tures make it possible to break away from rigid sequential lists of coordi-
nates and devise more natural computer structures to represent the geometry
of the drawn part. Again the intrinsic flexibility of these systems is such
that, at a slight increase in complexity, it is possible to keep track of a
full three-dimensional description of the drawn part and this in turn could
form the basis of a comprehensive data bank for design analysis problems con-
cerned with 3D geometry.

However, the main purpose of this paper is not to delve into the design
analysis aspects of data structures but rather to point out the possible
advantages such structures have in the graphic processing of engineering
drawings. Of these possibly the most significant is the way powerful edit-
ing algorithms can be generated which automatically update dependant data
items that otherwise would have to be handled individually - normally a time-
consuming procedure with interactive graphics. Another important attribute
is the way structures can be used to overcome to some extent the difficulties
of working in 3D when the display screen itself is 2D. The technique used
to solve this complex problem consists of performing rotation, shift and
scaling operations on the 3D data base until the region under consideration
by the user is projected so that it lies in the plane of the screen. In
this situation, knowing the new set of axes, the usual light pen construc-
tions can be reconverted automatically into the 3D reference axes of the data
base.

245
 Again, in a drawing processing system of this kind, the characteristics
of computer displays must be taken into consideration. Even at their best,
interactive methods of drawing shapes on the display screen are time-
consuming and often include complex sequences of combinations of light pen
and keyboard operations. Generating drawings from scratch is therefore not
a realistic proposition, particularly since there are more suitable devices
for digitizing drawings(1,2). Similarly, a computer plotter is a more
appropriate output device for regenerating detailed drawings. However, the
speedy response of the interactive features of the CRT display makes it ideal
for the role of editing drawings. After all, one of the main objectives of
computer processing in the first place is to get the computer to update and
regenerate drawings - normally a laborious and uncreative design office
~-I'

I' 1\,

I
I 'J
----,.-
I
I
-,
h
I
'\
,
I
I
: r----'
I ,
-A __ ~
II
I I
1 ' ,
,
. 1I I I
L____ .J
I I I _~
I
I L-J.. I I
I " I I
I \ \ I I
1I
t I
- ___"~, I
, 1 1 I r-.---,
\1 ~--~I
), L ____ -II
I' I
_~I

1I
c:lrxi~
~~C,)
~oo A
«....:l
p:;~jl:l
o::r:

FIG. 1 - OUTLINE OF ASP

chore. With this application in mind, the THREAD system has been
deliberately contrived to suit the designer by making light pen and keyboard
functions simulate (where possible) drawing board constructions with T-square
and set square.

GEOMETRY DATA BASE

The heart of the system is an ASP-type structure(3). Although ASP

structures are not the neatest structures for representing geometry proper-
ties, they form nevertheless a convenient generalized framework and have the
advantage that they can be embedded in high-level languages, such as FORTRAN,
to augment its facilities with the necessary list processing operations for

~
I I
I
......Q---
~ -0
I I

,
I
I I
1
,
I
t-"9-C(
C!;ll
Zl I
, T o -~

~;t

I ~I
I
~--
~I
I I
,
rill
ZI II
~
~
~
0
-I=Q
~ I
~
I
~ I ril -
~

~
ril
. I zo
~I=Q
~ -
~
E-4~

0
Z8-
<: o~~
~
~I=Q
~
~
00
ril8-I=Q
Z ~
ril ~_ I ~~<:
H I=Q -
.l °8~
<: 0
,
: I C!;ll
Z'
,
T
,
~HI=Q
~I=Q~
00
,
I
~I
~I
I

: ,.----., +-
I ~,
I

4--,
I ,~I'
~ I_A
A I I
L_':._
-< J'

GEOMETRY DATA STRUCTURE

247
working with data structures. The particular structure for representing the
geometry of a solid object consists broadly of the hierarchy of data items
outlined in Fig. 1. In this representation the object is defined in terms
of its surrounding surfaces. Again these surfaces are defined by their
boundary lines which in turn have end points. Such a framework can equally
well describe curved surfaces and their curvilinear intersections although
of course a different set of data values would be needed. From the mathe-
matical point of view, the properties of the object can be entirely deter-
mined from the canonical parameters of the bounding surfaces, but, since
graphic editing in this system is expressed mainly in terms of lines and
points, it is more convenient to omit the parametric form and represent the
shape explicitly by expanding the canonical form for its surfaces entirely in

ASP STRUCTURE

OBJEtT
WORD-
COUNT
RANGE
~. ~_ ---J-------- _..s~~~C_E_~ING
,
I

.
-0- -0-
DISPLAY LIST
--- ---RING

LINE LINE
AB BC
WORD- WORD-
COUNT COUNT
W AB Woc

l·
y

POINT
C

Xc
Yc
Zc

FIG. 2 - LINKAGE BETWEEN

248
terms of the end points of lines. Thus, the bulk of the structure repre-
sents the topology of the object including the relationship and inter-
dependancies between surfaces, lines and points in a form amenable to subse-
quent editing operations.

In contrast, a more conventional approach would be needed to handle

arbitrary curved surfaces. For these it would be better to revert to the
parametric representation and solve the surface intersections as required.
In any case, language statements - or at least mixed verbal-graphic input -
are more convenient editing techniques for curved surfaces compared with
pOint/line editing procedures described in the later sections of this paper.
These are only applicable to plane surfaces which are really the only con-
structions that T-square and set square can achieve.

3D-INTERMEDIATE FILE DISPLAY FILE

IT.
EOF END OF FRAME

1 7corOL WORn
~

W W
AB BC
WORD
COUNT
POINT U
~ODE
A \A
- - LINE UB VB

LINE U Vc
C

~-""""""~
--

DATA STRUCTURE AND DISPLAY

249
PROCESSING DATA STRUCTURE TO GENERATE DISPLAY DATA

The hardware of the display for which this system was designed is
relatively unsophisticated and requires a sequential file of display commands
to be repeatedly transmitted to refresh and maintain the displayed picture.
Essentially, therefore, the display sequence is different from the hierar-
chical geometry data structure described in the preceding section. So that
the dimensional data may be systematically converted into suitable display
coordinates, a display list is maintained within the structure, Fig. 2, to
link together in the correct sequence blocks of line data with their corres-
ponding display commands. Because such a display list is itself a type of
data structure, it can be readily updated (say by splicing in the line blocks
when lines are added or removed; however, no such insertions are possible in
the sequential display command file which has to be regenerated by a display
algorithm. The basic mechanism consists of stepping through the display
list checking to see if adjacent line segments can be strung together - a mor
compact display command - otherwise each line needs an extra command to
specify its start point.

Ultimately the 3D point/line data are projected into a set of 2D screen

coordinates but because the whole power and flexibility of this 3D package
depends on repeatedly transforming (rotating and shifting) the 2D view of the
displayed object, it is convenient to form an intermediate file of 3D data in
display sequence, Fig. 2. When required this can be processed into a pro-
jected set of display coordinates - without scanning through the entire data
structure repeatedly. During any transformation operation the 3D data file
is unchanged. Normally such graphic operations would have to be written in
machine language but because ASP can provide a high-level language with list
processing functions it is easier to write the transformation procedures in
the same high-level language. On the other hand, if THREAD were implementec
on a satellite graphics processor, then the transformations could be more
efficiently performed locally.

PROCESSING LIGHT PEN INPUT DATA

Ideally in this graphics system, the light pen should explicitly identify
the data structure block corresponding to the item the pen has detected.
Again the display hardware does not possess these advanced features; instead
the data item that accompanies the light pen interrupt merely identifies the
display command that the light pen has detected by its relative position
(word-count) to a control word (end-of-frame) within the display file,
Fig. 2. In this graphics system, the display command is of little value
since its screen coordinates are truncated projected values of the 3D data
they represent. What is needed is a linkage to interrelate the screen data
with the data in the geometry structure. One possibility is to include in
each data block its corresponding word-count (or range of word-counts) and
then search the whole structure to find the item that matches the light pen
word-count. Since lines are the only detectable screen items, a faster and
more direct technique consists of searching the display list since this con-
sists of line blocks linked together in the same order (word-count sequence)

250
as their corresponding display commands, Fig. 2. The increasing order of
word-count of such a list virtually halves the search time. On a larger
drawing, consisting of many objects, the search time can be significantly
reduced by first checking each object to determine which object has a word-
count range which includes the item the light pen has detected. Ultimately,
since lines are the only light pen sensitive items on the screen, the light
pen interrupt is converted into a pointer to a line block within the data
structure. However, in many instances, the user may wish to refer to one
of the end-points of the lines or perhaps the surfaces intersecting at the
line. Because there is a certain ambiguity in stepping up or down through
the structure hierarchy, the processing algorithm may need supplementary
information which the user in this system supplies through the auxiliary
light buttons.

AUXILIARY LIGHT BUTTONS

Normally a panel of function buttons would be an appropriate method of

qualifying light pen actions to the graphic system. However, the NEL
graphics terminal does not have this facility so as a substitute certain
auxiliary light buttons have been set up to behave in a similar fashion.
For convenience, since they qualify the light pen actions, these buttons
appear in the vicinity of whatever screen item has been detected by the light
pen to provide the user with features not otherwise available in the hard-
ware. These are the option when the pen detects a line on the screen of
selecting one of three possibilities - the end-points of the line, a point on
the line seen by the pen, or generating a tracking pattern to locate some
other point near the line. In this way the light pen can identify point
blocks even though these do not exist as detectable screen items.

LIGHT BUTTON MENUS

The main purpose of the light buttons is to transfer ~rogram control to a

particular part of the graphic system to perform specific tasks in which the
light pen data may have quite different meanings. Again working in 3D makes
the whole problem more complex, so in an attempt to simplify matters and
spare the user the burden of remembering elaborate 3D construction sequences,
the THREAD system guides the user by means of commands and messages which
prompt him to perform certain actions. The main sequences are outlined in
Fig. 3. To further reduce the possibility of error, only light buttons
valid for a particular operation are displayed. Normally the choice, as
outlined by the system commands, is at the most limited to three options but
these buttons in turn may call for a series of subsidiary interactions.
While these interim actions are taking place, the user is guided by auxiliary
messages. When a particular light button is fully processed, it generates
the next combination of light buttons with their particular commands and
messages and so on until the user has performed in a logical sequence all the
details needed for a particular 3D operation.

Because of this logical structure, list processing techniques can be use-

fully applied. In place of the usual technique where each light button does

251
 n ~ S n ~ ~.
~ O::S(l)::T::Srt
Q. 00 ~ 00
~·~ool1~
::S11~rtl--'l1
OQI1OQ OQ(I)
~(I)HlOI--'
~ ::s 00 0 11 ~
Q. OQ 11~·
rt
Q.(I)~ rt(l)
~. S rt::TQ.
::s
rt(l)Q.::TS
~. ::s (I) 0
Ortl--' O~
::s ~ ~ (I)
....
~ ~. OQ I--' (I) 11
Command 'SELECT NEXT OBJECT' I--' 00 ::T OQ >1 ~
rtO~rt
Q.S I1rt~·
Button DRAW EDIT NEW VIEW ~ 0 C"~·~·o
rtQ.C::rt::S::S
~ c:: rt po"OQ 00
I--'rt8
C"~o .. 0C::
/ 1--'11::S ::S::S
o >'%j Q.
Command 'SELECT SHAPE'
\
Command 'CHANGE VIEW' n~·I--'~·rt(l)
~::s ~·OQ::T11
00 oo' (I)
Button CUBE RECT POLY- SHIFT ROTATE SCALE rtrt ~
~::Too ~1--'11
BOX FACE ::s~ .. ~. 0
~ Q.!'"I~ OQOQ
1st Message
•
'SELECT ORIGIN'
,
1st Message
'TYPE X
,
'SELECT
TYPE
SCALE
(I)
~ ~
(I)
11
(I)
Q.
rt rt OQ ~. C"
8
::s~. ::T 11
rt ~

LINE' (I) 11 (I) n c:: n

SHIFT' FACTOR ::s III ~ rt 0
::s
J Q. (l)rtrt::S
~·I--'I1(1)Ort
2nd Message l ::s .... ~ 00 11 ::s
+ 'TYPE OQOQrt 0
'TYPE LENGTH' 2nd Message ::T(I)::TQ.I--'
ANGLE rtrtQ.O~ ..
OR SELECT 'TYPE Y ::T ~ rt
OR (I) C"~. ~ I--'
POINT SHIFT' c:: rt
::s ~.
SELECT I--' rt ::T C" OQ
~. rt rt (I) I--'::T
OQOC:: Ort
::T::Sl1oon
rtoo::S(l)~c"
00 c::
..c
c"n C:: .. rt
c:: ~ (I) rt
rt::S >'%j 0
::s
I'%j rt t-3n ~.::s
I-t o C"O (l)0Q 00
o ::s (I)
00 0 ~
Q.~OHl~11
~ ~ Q. S • (I)
rtQ.(I)n
I ~ (I) 0 n
til
Command 'DEFINE RECT SURFACE' Q. (I) 0 a
I-t C" ~St-3::S
~C"rt~::Trt
~ LINE AND NEW 00 0....:: (I) (I) 11
"d COMPLETE 3 POINTS (I) Q.
::s ::s 0
t-t POINT VIEW SrtOOHlI--'
1-1 I (I) .. 1--'1--'
t 11 00 0 (I)
::l 1st Message 'SELECT
- - t--l (I) c:: ~ Q.
M • ~ as I I--'n
tj 0....:: ::T C"
'SELECT POINT' LINE' 'above: 0....::
~-- ---
 rt n ......
t-t
t-I f (:: ~ CI>
+ rt ~ III
2nd Message 'TYPE o "d <:
~ t; ...... 1-'-
t-3 'TYPE WIDTH OR LENGTH 1-'- CI> ::s
III ~ OQ
td SELECT HORIZ SELECT ......
OQ rt
c::: III t; :::r
t-3 POINT' POINT' "d III CI>
"d"d
t-3 t; :::r III
0 o 1-'- ......
Z
(J)
,
3rd Message
'TYPE HEIGHT OR
III
n
:::r
n
(Jl
OQ
0
t;
t%j til 1-'-
"< rt
~ SELECT VERT
c::: ~i
t%j POINT' CI>
51 (::
til ::s
~ n
t%j g.g-
1-'- ::s
nOQ

~
:::rCl>
(:l.
Command 'DEFINE SURFACE' a:4 ...
......
COMPLETE COpy POLYGON NEW 1-'-
RECT ;0:;"
CI> H
VIEW ::s
t-3
e:l s
Gj~
~"<
Las
above ~ ~

o..~
CI> (Jl
,-----, "d
Command 'SELEC T' , as I 'DEFINE SIDE' CI> til
, I ::s (::
'above' o..n
PARALLEL ROTATE 2 POINTS LINE COM- :::r
'--- -..) o
::s III
POINT PLETE
~ ~ t III til
1st Message SELECT FmST (Jl
"<
(Jl
rtrt
SELECT POINT l ~I m
cT 1-'-
~
2nd Message
MATCHING POINT
,
TYPE
ANGLE
"<
(Jl
I
(Jl

1-'-
rt(:l.
CI> CI>
"d III
L.. '- '- , , ......
H\
o
t;
~
 DISPLAY SCREEN CURRENT L-B NEXT L-B
COMMAND DISPLAY FILE DISPLAY
MESSAGE
L-Bl 1 L-B12

i
WC3
L-B2 L-B13

I~~~J,
L-Bl
L-B14
L-B2 L-B3
L. _____ ....... L-B3 --L
COMMAND

L-Bl L-B2 L-B3

7
~~--IC~-D-~~1~J-TI-r--8~______- ' I
E F
G H :~~ L~~!L
J J
K L
~===:===:: COMMAND
BUF

A -
LIGHT BUTTON INDEX MESSAGE LIST
B -
WORD-COUNT r---:=+,--t-lst Message
C -
LENGTH OF BLOCK --+___ 2nd Message
~----
D -
POINTER TO NEXT L-B
E -
LENGTH OF LABEL L-B LIST
F -
POINTER TO LABEL BUF ......---4_L-B12
G -
LENGTH OF COMMAND t------1 L-B13
H POINTER TO COMMAND BUF
- L __~j--- L-B14
I -
NUMBER OF MESSAGES
J - POINTER TO MESSAGE LIST
K - NUMBER OF NEXT L-B
L - POINTER TO NEXT L-B LIST

CALL BUTTON (WDCT, INDEX)

ALGORITHM 1. Search CHAIN L-B1, L-B2, L-B3, to find WDCT

2. Set up NEXT L-B DISPLAY from L-B LIST
3. Set up light button command
4. Set up 1st message etc.
5. Return button index number

FIG. 4 - OUTLINE OF LIGHT BUTTON DATA BLOCK

254
CONSTRUCTION AND EDITING ROUTINES

Mathematically a solid object is completely described by the parameters

defining its boundary surfaces. From these the lines of intersection and
end-points can be evaluated. In the THREAD system, this approach has been
rejected as unwieldy. A simpler more natural technique has been adopted
partly because in many ways it resembles conventional drafting practice.
The technique consists of defining a surface by drawing out its edge lines
and then joining these surfaces together to form a solid shape, so
building up a composite object by simple line constructions. However, the
THREAD geometry structure is hierarchical - from top downwards. To make the
construction routines fit into this underlying structure before pOint/line
items are construct~d, the system asks the user to define the general topo-
logy of the object without necessarily being explicit about the coordinate
values. The light button sequence, shown diagrammatically in Fig. 3, auto-
matically leads the user through the correct selection sequence, such as
DRAW-POLYFACE-RECTANGLE-LINE-POINT. In this way the THREAD system steps
through the structure until it reaches the correct level where dimensional
values can be meaningfully inserted into data blocks. Initially, the user
would sketch out the shape in which the system automatically inserts the
appropriate 3D coordinates derived by reconverting the light pen screen
coordinates back in terms of the 3D data structure axes. Once the object
has been roughed out, the precise data values can be inserted by typing in
accurate data values and because the geometry of the shape is embodied in the
structural links between the data blocks, even single values can, in conjunc-
tion with the editing routines, have far-reaching effects throughout the
structure - so minimizing repeated manual corrections. After all, one of
the main features of the structure in the first place is essentially to allow
powerful constraint algorithms to operate and perform radical retrieval and
updating procedures automatically. For example, instead of specifying a
rectangular box, Fig. 5(a), by constructing its eight corner points (each
having three coordinates, making twenty-four data values altogether), the
shape may be defined by selecting the light button 'RECT BOX' and then
defining the height and width of the first face by '3 POINTS'. The 'ROTATE'
light button is then activated to bring an orthogonal plane into the plane of
the screen so that the 'LINE' and 'POINT' constructions can be made to define
the depth of the box. The THREAD system then completes the object by
defining the remaining four sides so as to satisfy the underlying constraint -
that the faces of the box should be parallel to the current set of projected
axes. The 'CUBE' light button is an example of a more powerful constraint
since only the origin and one other corner point need be specified. More
complicated shapes, Fig. 5(b), can be developed by the 'POLYFACE' construc-
tion facility and its related surface definition light buttons. For each
case, interactive point/line constructions can be added to a surface only if
it lies in the plane of the screen. Adjacent surfaces must first be
rotated into the plane of the screen before they can be accessed. Again,
because the shape shown in Fig. 5(c) has a certain symmetry, the 'PARALLEL'
and 'ROTATE' constructions can considerably reduce the interactive sequence.

255
 ....... 1---- ----:.-;.,
2nd point .... ' I ,.... I
........ I, ........... I
r-------- + (height)
C ------t---~
I I
I
I
I I
AI___ -1I ______I1
,
I
I
I ......
I ,,""
AI B IIIII:;;...._ _ _ _ _.L- ... ....
-------+
Origin
1st point
+
(width)
3rd point
(depth)

Fig. 5(a) - Construction of 'RECT BOX'

Conventional Existing /1 ,.. .... ~ Copied

Isometric SUrfacey" ~ " I Surface
I I
View
. I I 1

./ ).
/ I

k// L//'
I I
I ,,'
I "

Fig. 5(b) - 'POLYFACE' Construction Fig. 5(c) - 'PARALLEL' Construction

Isometric View Screen Representation

Fig. 5(d) - VISUALIZATION 1

FIG. 5 - CONSTRUCTION SEQUENCES AND VISUALIZATION

256
VISUALIZATION

Although an isometric projection does give some indication of depth,

there are still ambiguous views which can only be solved by perspective and
brightness modulation. One immediate improvement to the visualization can
be achieved by making the working plane brighter whilst the attached lines in
the background are made less bright as well as insensitive to the light pen.
Knowing the active plane, it is possible to show only the edges/lines
attached to the plane (eliminating non-attached rear surfaces as in Fig. 5(d);
so that the problem of hidden lines does not really arise. Again the objec-
tive is to display only a representation of the part of the drawing to be
modified. Unwanted details, such as annotations or dimension lines, may as
well be suppressed since they would not normally contribute to the editing
process.

Nonetheless, the drawing data structure should make prov~s~on for these
data items since they would be required during the drawing regeneration stage.
This is essentially a post-processing operation, preparing data for an output
device such as a plotter. To be realistic a full description complete with
dimensions, labels and parts lists may be required together with an ortho-
graphic projection system to suit the plotter - instead of the isometric
system which suits the CRT display. In principle this can be achieved by
computer methods but in the THREAD system this type of graphic processing is
not considered part of the main drawing-editing phase.

If THREAD were extended to handle cylindrical surfaces, these surfaces

would probably be represented implicitly by their canonical parameters. In
many instances the actual boundary curvilinear lines of such surfaces are not
so important, as the user is mainly interested in their corresponding radius
and centre. Thus, there is really no need to devise surface generating
contours and silhouette line to show the curvature of the surface. The
representation might consist simply of the axis of the cylindrical surface
together with radius vectors to certain tangent points.

CONCLUDING REMARKS

Even though the facilities described in this paper are virtually only a
skeleton of what would be needed in a practical working system, nevertheless
they provide a realistic framework that is sufficiently versatile and can be
extended (with sufficient programming effort) to cover the essential require-
ments for handling the editing of engineering drawings. Of course, in an
exploratory scheme of this sort, because of the amount of programming
required to process graphic detail, the basic approach has been to concen-
trate on trying to assess the overall architecture needed for a drawing
system of this kind without implementing too much graphic processing detail ..
Essentially, therefore, this paper tries to identify a realistic mode in
which a computer display can be harnessed to the problem of processing draw-
ings. The following remarks summarize some of the more significant findings
of the investigation.

257
 (1) Since data preparation - drawing digitizing - is likely to be an
expensive overhead, computer processing of drawings can only be justified
in drawings that are widely used and subjected to frequent minor modifi-
cations such that computer processing could usefully and economically
relieve design offices of time-consuming routine tasks.

(2) Because of its interactive features, the CRT display can perform a
more useful role in the intermediate modifying/editing stage rather than
the input/output stages which are more efficiently performed by other
less interactive or off-line devices.

(3) It is essential that dimensional drawing data should be structured

to permit the computer display to overcome its inherent limited resolu-
tion and allow dimensional information to be retrieved and updated with
full precision. Among other advantages to be gained from structured
data (rather than sequential drawing files) are: the facility to
represent geometry constraints, rapid random access instead of sequential
search, and a flexible data base for CAD.

(4) Compared with orthographic 2D drawings, a display can give an

excellent visualization of the shape of the part by displaying an iso-
metric projection. When slowly rotated such a view can be a useful aid
in checking data for consistency.

(5) The limited field of view of the CRT display need not restrict its
usefulness in drawing-editing, provided there are facilities for
suppressing unwanted data, so displaying only an uncluttered view of
the surfates to be modified. This assumes that, even though full draw-
ing detail may not be required during the editing phase, nevertheless the
data file for the drawing should contain all the information needed for a
working drawing such that this information can be included during drawing
regeneration via the plotter.

ACKNOWLEDGEMENTS

This paper is published by permission of the Director, National

Engineering Laboratory, Ministry of Technology. It is Crown copyright and
is reproduced with the permission of the Controller, H.M. Stationery Office.

REFERENCES

1. TURNER, B. T. The graphic transmission of information. Chart. mech.

Engr, 1969, ~(7), 291-296.

2. BAKER, B., JENKINS, R. and STEVENS, D. R. A system for producing

general engineering drawings by computer - and its on-line development.
Int. Conf. on Computer-aided Design, lEE Conference, Publ. No 51, 1969,
pp 352-359, London: Institution of Electrical Engineers, 1969.

258
3. LANG, C. A. and GRAY, J. C. ASP - a ring implemented associative
structure package. Communs ACM, 1969, ~(8), 550-555.

4. TEDD, D. W. A user's guide to ASP. NEL Report (in preparation).

259
 PART 3

Computer Aided Design

of Electrical Circuits
 A GRAPHIC LANGUAGE FOR DESCRIBING
AND MANIPULATING TWO - DIMENSIONAL
PATTERNS a

G. Bracchi and D. Ferrari 00

Instituto di Elettrotecnica ed Elettronica, Politecnico

di Milano, Piazza L. da Vinci, 32, 20133 Milano, Italy.

ABSTRACT
In this paper CADEP, a problem-oriented language for positi£
ning geometric patterns in a two-dimensional space, is presented
Although the language has been specifically designed for au-
tomatic generation of integrated circuit masks, it turns out to
be well suited also for other placement problems as architectu-
re design, urban planning, logical and block diagram representa
tion. -
The design criteria, the structure and the specific features
of CADEP are illustrated.
I. INTRODUCTION
In many fields of engineering and technology the designer is
faced with the problem of positioning geometric patterns in a
two-dimensional space. This problem arises, for instance, in
architecture design, in urban planning, in logical and block die
gram representation, in integrated circuit mask generation, in -
printed circuit layout design.
As the complexity of the system under study increases, the
placement time and the likelihood of errors increase at a very
high rate; thus, it becomes important to use a computer with gr5

(0) - This work was partially supported by Consiglio Nazionale

delle Ricerche, Italy.

(00)_ Present address: Department of Electrical Engineering an(

Computer Sciences, University of California, Berkeley.

263
phic input-output capabilities to assist in the tedious, expen-
sive and time-consuming task of pattern layout. The success of
such computer - aided operation, which can greatly enhance the
speed, the reliability and the cost of the design process, is de
pendent on the efficiency of communication across the man-machi=
ne boundary. In particular, the potential of data processing sy
stems equipped with graphic display consoles may be fully explo
ited in computer-assisted design only if graphics programming Is
made easier by means of high-level, user-oriented languages.
In this paper,a graphic language, designed to be employed as
the interface between the user and a system of computer pro-
grams for integrated circuit mask layout, is described. Although
the language, which has been named CADEP (Computer Assisted DE-
scription of Patterns)~ has been s£ecificall~ designed for auto
matic mask generation LIJ [2J [3J L4J [5J [6J [7J , it turns o~
to be well suited also for the other placement problems mentio-
ned above. It must be noted that graphical aspects of integra-
ted circuit mask layout are more complex than the ones of the
other problems, since a number of different masks is needed to
fabricate a single integrated circuit, and the mask patterns for
the different layers are intimately interrelated; thus, descriE
tion and manipulation for these masks must be coordinated.
In the following sections, the design criteria, the structu
re and the specific features of CADEP will be described. -
II. GENERAL REQUIREMENTS AND DESIGN CRITERIA FOR THE LANGUAGE
In designing CADEP it has been considered that the language
should be easy to learn and natural to use by inexperienced per
sonnel. Thus, being FORTRAN the most widely employed language -
in engineering applications, it ought to be possible for a user
being familiar with FORTRAN to describe his placement problem
in this programming language, without need of learning a new
original language.
On the other hand, CADEP should include all the facilities
needed to describe in a flexible and concise way the patterns
for the layout of the complex masks required by the introduction
of large-scale integration.
In using the FORTRAN language for these graphic applications
the problem arises that FORTRAN does not contain the facilities
needed for graphic functions. To circumvent this limitation,the
solutions of constituting a package of graphic FORTRAN subrou-
tines [8J and of introducing graphic additions to FORTRAN [9J
[lOJ have been considered.
It has been noted that subroutine packages are difficult to
use for the non-programmer, since he must write an executive
program composed of a FORTRAN calling sequence with long argu-
ment lists ordered with a strict syntax; hence, coding, diagn£

264
sis and debugging result in heavy and cumbersome tasks.
Thus, CADEP has been designed as an extension of FORTRAN by
means of graphic-oriented, FORTRAN compatible statements.
The feature of being embedded in FORTRAN provides CADEP with
the additional advantage that facilities are available for al-
gebraic and logic calculations, branching, looping, hierarchi-
cal subroutine and function calls.
The capability of FORTRAN to make hierarchical calls permits
any pattern or group of patterns on the masks to be defined by
means of subpatterns: thus, a library of patterns can be gradu~
ly accumulated, by storing information under a function name
for later use (see Section III).
Any function may be employed in other functions, as a new
word of the CADEP vocabulary, and the user is enabled to build
up a sort of specialized language for his own needs.
When a function is recalled from the library, the computer
can calculate variable parameters from data supplied with the
function call statement.
In placement problems, we often recognize the repetition of
a subpattern at a fixed interval. The language can take account
of this characteristic by constructing row and column vectors
or matrix arrays of subpatterns. This replication feature is
oQtained by exploiting the computational capability of the
language, which allows adding multiples of a preassigned
increment to the variable coordinates specified for the cons ide
red subpattern; FORTRAN IF and DO statements may be used to con
trol branch and loop calculations. In this replication opera- -
tion, the computational capabilities of FORTRAN may be used to
change progressively subpatterns in constructing the array by
changing variable parameters which determine the dimensions or
the shape of the subpattern.
Moreover, CADEP is intended to be independent of the particu
lar automatic mask-making machine employed to generate the mas~
themselves: in fact, the statements of the language can be tran
slated by a specialized computer procedure into the control in~
formation able to activate a particular mask making equipment
[3J [6=1·
CADEP is designed to be utilized in both batch-processing
and interactive on-line operation with display facilities. In
the former mode, statements are introduced in coded form; in the
latter mode, a sequence of commands is selected by pointing wi1h
the light pen to light buttons on the screen. Both the written
mode and the pointing mode are necessary in the different stag$
of the mask layout task. On the other hand, a correspondence can
be established between the commands of the two modes, so that

265
N
OJ IX1.Yli~
OJ

L NC (X1, Y1, X2, Y2, W )

'IX2.Y2i

L NP (X1, Y 1, RHO, THETA, W )

~(X1'Y1) (Terminal points of the arc

are assigned in a counter-
ARC ( X1, Y1, X2,Y2,R, W)
clockwise order on the circle
(X2,~ ~ to which the arc be longs)

CRCL (X1, Y1, R )

~
SECT (X1, Y1,R, ALFA1, ALFA2 )
ALFA1
(X1.Y1~ ::::> p-=

~(X2JY2)
RECT (X1, Y1, X2, Y2)
(X1,Y1)~
 I" 51 ~I
(51 and 52 are
REC5 (X1, Y1, 51,52) S2Jg signed numbers)

( X1,Y1J

(vertices should be listed

in a counterclOCKwise order
POLY (X1, Y1,X2, Y2, ... ,XN, YN) starting from an
(X1,n) arbitrary vertex)
(X 2 Y2)

FPLANE The entire geometric plane

HPL ANE (XA, YA ,ALFA )

EMPTY The complement of FPLANE

Fig. 1 Geometric primitives.

~
they can be considered as two forms of the same language [llJ •
Thus, only the written form of CADEP will be illustrated in the
rest of the paper.
The data structure containing the representation of an objett
or of an assembly of objects will be said image. In studying the
layout problem, two different types of entities, and thus two
different types of variables for CADEP (see Section III), have
been recognized.
The former type is the geometric type, to which belong ab-
stract entities that do not correspond to real objects, and th~
do not correspond to an image. Geometric entities are employed
to build up auxiliary patterns and thus auxiliary data structu-
res that are useful for constructing the images. In the langua-
ge, geometric variables correspond to geometric entities.
The latter type is the graphic type, to which belong entitie
that designate two-dimensional objects, and thus correspond to
an image. In CADEP, graphic variables correspond to graphic en-
tities. While geometric entities are not subjected to any con-
straints of physical nature, a graphic entity must not overlap
any other graphic entity, because two objects may not be assi-
gned to the same zone of the plane. Thus, CADEP has been given
the facility of performing interference tests on graphic varia-
bles.
Spacing objects correctly is another critical problem in de-
termining a satisfactory layout; thus, CADEP allows the user
performing tests on the distance be-tween the obj ects representEd
by graphic variables.
As pointed out in Section I, in integrated circuit technolo-
gy several masks correspond to a single device, and the descriE
tions of these masks are interrelated. In order to allow the
user describing simultaneously the masks, graphic entities may
be subdivided into two subtypes. The former is the unilevel sub
type, to which belong entities corresponding to a single object
(or assembly of objects) on a certain mask; an n-level variable
corresponds to a unilevel entity on the n-level mask. The lat-
ter is the mutilevel subtype, to which belong entities corresp<!!,
ding each to a set of objects (or assemblies of objects) having
the following properties: (1) two objects may not be on the sa-
me mask- (2) all the objects are related to the same device. A
multile~el variable corresponds to a multilevel entity, and it
is defined by means of a set of n-level variables having diffe-
rent n from each other. Operations on multilevel variables cor-
respond to similar operations on the unilevel variables included
in the set.
In the following sections, the specific features of CADEP win
be illustrated.

268
III. LANGUAGE DESCRIPTION: GEOMETRIC VARIABLES
As pointed out in Section II, there are three basically dif-
ferent types of variables in CADEP:
(a) the conventional FORTRAN variables (Boolean, integer, real,
complex) ;
(b) the geometric variables ;
(c) the graphic variables.
Variables of types (b) and (c) correspond to two-dimensional
patterns and their value is the whole data structure represen-
ting the pattern in the computer memory. Also one-and two-di-
mensional arrays of these variables may be defined, to be em-
ployed, for example, within program loops.
Geometric variables and the manner in which they have to be
handled will be discussed in this section. The next section is
concerned with graphic variables. Finally, Sectio~ V deals with
CADEP commands.
All geometric variables defined in a CADEP program must ap-
pear in a declaration statement having the form
GEOMETRIC A, B, ••••
They represent geometric entities lying in the same plane, cal-
led the geometric plane. This plane is unbounded, and the coor
dinates of its points are specified with respect to two fixed -
orthogonal axes, x and y.
Patterns defined in the geometric plane may overlap as well
as be disjoint. To create these patterns, the user is given the
possibility of defining geometric primitives (which are the sim
plest geometric variables), and of combining and manipulating
geometric variables by geometric expressions and manipulation
functions respectively.
The geometric primitives available in CADEP are listed in
Fig. 1. They are built-in FORTRAN functions which set up the da
ta structure suitable for the geometric element they represent;
their value is a pointer to the table containing this data struc
ture. Note that no geometric primitive is one-dimensional , since-
LNC, LNP and ARC have a "width" W that must be specified. The
primitives FPLANE, HPLANE and EMPTY are defined in order to ma-
ke the construction of complex patterns easier, as will be seen
below.
The operations which can be performed on geometric variables
are the fOllowing:
(a) intersection (operation symbol / )
(b) union (operation symbol + )
(c) difference (operation symbol - )

269
 The intersection and the union keep in CADEP their set-theo-
retic meaning; the difference between two geometric variables
A and B is a geometric variable representing the portion of pat
tern A that does not belong to pattern B. -
A geometric expression is an expression containing only geo-
metric variables connected by the operators defined above C I,
+, - ) • The precedences among these operators are the same as
in FORTRAN Ci.e., the intersection is executed first, the union
and the difference have equal precedence levels); like in
FORTRAN, these rules can be altered by employing parentheses.
Assignment statements do exist also for geometric variables
and allow a complex pattern, defined by geometric expressions,
to be represented by a geometric variable. For instance, the pat
tern P in Fig. 2 can be described by the following geometric as=
signments :
GEOMETRIC A,B,C,D,E,P
A = RECS (1. ,1. ,1. ,1. )
B = LNPC1.7,1.7,1.8,45. ,0.5)
C = RECTC2.5,3.,3.5,4.)/HPLANEC3.,3.,225.0)
D = LNC(3.7,3.8,4.3,3.8,0.3)+ARC(4.7,3.3,4.3,3.8,O.5,O.3) +
+LNPC4.7,3.3,1.2,270.0,O.3)
E = RECS(4.3,2.l,O.7,-O.4)
P = A+B+C+D+E
To increase the flexibility of CADEP in describing pictures,
the following manipulation functions have been introduced :
COpy (G,S)
TRANS (G,Xl,Yl,S)
ROT (G,Xl,Yl,ALFA,S)
In the arguments of these functions, G is a geometric varia-
ble or a geometric expression, and S is the scale factor with
which the manipulation specified by the function must be accom-
plished.
The COpy function duplicates the data structure representing
the variable or the expression G and generates an internal name
for this copy, which becomes a completely distinct and separa-
tely modifiable geometric entity having only the initial shape
of G (and the same size, if S = 1.).
The TRANS function, besides the operations performed by COpy,
transfers the new geometric entity generated from G by incremen
ting the coordinates of its points by Xl and Yl in the horizon=
tal and vertical directions respectively.

270
 The ROT function, besides the operations performed by COPY,
rotates the geometric entity generated from G by an angle ALFA
with respect to point (XI,YI), which can be internal as well as
external to G. Positive angles correspond to counterclockwise ro
tations. If a manipulation function is intended to operate a-
transformation on a given pattern, not to generate a new pattern,
the old geometric entity can be deleted by a geometric assign-
ment such as A = TRANS(A,Xl,Yl,S) .
Every geometric entity has a conventional reference point
which is considered to be invariant in scale transformations.
Thus, the size of the pattern generated from G by means of func-
tions COPY, TRANS and ROT, is changed by the factor S keeping
the reference point fixed. The reference point is the one whose
coordinates are stored first in the corresponding data structu-
re; in all geometric primitives listed in Fig. 1 this point is
(Xl,Yl); for more complex patterns, very simple rules allow the
user to derive it by fnspection of the geometric expression wh~h
defines the pattern; for instance, the reference point for pat-
tern P in Fig. 2 is the same as for pattern A, i.e., (1. ,1.).

, L
C ~
/
Vi
"-
3

2 ~ r ;..
<. '1 L.::W

, A'

o 7 2 3 , 5 6
..

Fig. 2 A sample pattern.

Note that manipulation fUnctions create new geometric varia-

bles, whose names are not known to the user unless he assigns
them an external name, for instance A = COpy (B,S); obviously

271
these variables can be inserted in geometric expressions. This
allows also one to perform roto-translations by writing
A = TRANS (ROT(B,Xl,Yl,ALFA,Sl)X2,Y2,S2) .
IV. LANGUAGE DESCRIPTION: GRAPHIC VARIABLES
As said in Section II, in CADEP there are two types of gra-
phic variables: unilevel variables, which represent physical
two-dimensional entities. lying on a particular fraPhic plane,
and multilevel variables , which are composed 0 several unile-
vel patterns lying on different planes and belonging to the sa-
me physical object (for instance, in integrated circuit masks,
to the same component part). Graphic planes are totally distinct
from the geometric plane defined above , and are bounded by the
edges of a rectangle whose opposite vertices are (0,0) and
(XMAX,YMAX), where XMAX and YMAX should be assigned by the user
by means of two FORTRAN assignment statements.
Any graphic variable must appear in an appropriate declara-
tion statement. The form of this statement for unilevel varia-
bles is :
LEVEL (i) A,B,C, ••• ,
where i = 1,2, ••• is the identifier of the graphic plane on
which the unilevel variables A,B,C, .•• are defined. Multilevel
variables are declared by writing the statement
GRAPHIC E,F,G, •.• ,
where E,F,G, ••• are multilevel variables.
Unilevel variables having the same level can be combined to-
gether to form unilevel expressions , by means of the union ope
rator (+). The manipulation functions defined in Section III -
can be applied with the same result to unilevel variables; each
function generates on the same plane a new pattern, which is
dealt with as a new unilevel variable with an internally-produ-
ced name, and may appear in a unilevel expression.
A unilevel variable is defined by means of a unilevel assi-
gnment , whose left-hand side is the name of the unilevel varia
bie to be defined, and right-hand side is either a geometric
expression or a unilevel expression. In the latter case, the Ie
vel of variables in the unilevel expression may differ from the
one of the variable defined by the assignment, and this is the
procedure to be followed when the level of a graphic entity is
to be changed.
For instance :
LEVEL (1) A,B,C
LEVEL (2) D,E (10)
A = B/(C-ROT(A,1.,2.,90.,1.»
D = TRANS (A,S.,-2. ,0.5)
E (10) = D+TRANS(D,l.,O.,l.)

272
 When a unilevel variable has been made equal to a geometric
expression, the geometric variables contained in this expres-
sion can be manipulated arbitrarily without affecting the uni-
level variable. This is not true in the other case, since a uni
level variable defined as the union of other unilevel variables
is modified by any change in these variables (that is, its ima-
ge is built up by linking together the images of other unilevel
objects, and therefore is a compound image, whereas in the for-
mer case the image is simple).
Multilevel variables can be defined by means of a multilevel
assignment , which is a statement whose left-hand side is the n~
me of the multilevel variable to be defined, and right-hand side
is an expression containing only unilevel variables having dif-
ferent levels, linked together by the concatenation operator _.
For example, if we have :
LEVEL (2) A
LEVEL (3) B
LEVEL (5) C
GRAPHIC M
M =A• B
- C ,
the last statement defines a multilevel variable M composed of
variables A,B,C, whose levels are 2,3 and 5 respectively. As
for unilevel variables, the only operations that can be perfor-
med upon multilevel variables are the union and the application
of manipulation functions defined in Section III. Multilevel
expressions are built up by using these operations,whose result
can be made equal to a new multilevel variable; the unilevel
components of this variable are obtained by performing the same
operations on each graphic plane separately.
For instance, if
LEVEL (1) Al,Cl
LEVEL (2) A2,B2,C2
LEVEL (3) A3,B3
GRAPHIC A,B,C
A = Al _ A2 _ A3
B = B2 • B3
C = Cl • C2 ,
the assignment A =B + C is equivalent to the following assi-
gnments :

273
 Al = CI
A2 = B2 + C2
A3 = B3
As already said in Section II, CADEP provides also some in-
structions for testing the existence of certain conditions
among graphic variables. The general form of these conditional
instructions is the following :
SYM (arguments) statement,
where SYMisa basic CADEP symbol, the arguments are CADEP varia
bles, and the statement is any executable CADEP statement e~­
cept a DO statement or a conditional statement. The statement
is executed before the next sequential statement only when the
test specified by SYM is successful.
TAB LEI

TEST STATEMENTS

SYM Arguments Meaning

BLG (XI,YI,A) Does point (XI,YI) belong to uni-
level pattern A ?
INT (A/B,C/(D+E), •. ) Are intersections between patterns
A and B, or C and (D+E), or ....•
non-empty ?
(A and B may be unilevel expres-
sions having the same level or mul
tilevel expressions)
INC (A/B,C/(D+E), .. ) Is pattern A included in B, or C
in (D+E), or ••••• ?
(A and Bare unilevel expressions
having different levels; A is in-
cluded in B if its projection on
the plane of B is internal to B)
DIS (A/B,DIST) Is the minimal distance between
patterns A and B less than or equa:
to DIST ?
(A and Bare unilevel expressions
having the same level).

274
 Table I gives the list of the available statements in this
class.

TAB L E II

COMMAND STATEMENTS

Command Meaning

DRAW list Builds up the ultimate image of the

graphic variables specified in the
list.
(a) STORE name, list Stores in file "name" of the auxilia-
(b) STORE name, (K) ry storage the images of : (a) the uni
level and multilevel graphic variables
(c) STORE name specified in the list, or : (b) all
the level-K graphic variables, or :(c)
all the graphic variables.
(a) SHOW list Extracts the display file from the ima
(b) SHOW (K) ges of : (a) the graphic variables in-
the list, or : (b) all the level-K gra
(c) SHOW phic variables, or : (c) all the uni--
level graphic variables, and shows the
corresponding picture on the display
screen.
RECALL name Transfers file "name" into main stora-
ge.
ERASE list Erases all the instances of geometric
or graphic variables specified in the
list.
DELETE list Erases the last instance of geometric
or graphic variables specified in the
list.
v. LANGUAGE DESCRIPTION: COMMANDS
Some command statements have been introduced in CADEP in or-
der to obtain some special action to be executed. These state-
ments are listed in Table II.
It has to be noted that, after appearing in a DRAW statement,
a graphic variable A is not affected by any change in graphic
variables on the right-hand side of the expression defining A.

275
 Other commands similar to the SHOW statement can be added to
the list in Table II for outputting patterns on a digital plot-
ter or on a paper tape punch.
VI. CONCLUDING REMARKS
CADEP, a language for describing and manipulating geometric
patterns in a two-dimensional space, has been described.
The goal of language design has been to enhance the speed,
the reliability and the cost of computer-aided design operatiom
involving placement problems.
The main advantage of the language with respect to other so-
lutions seems to be that, being CADEP an extension of FORTRAN
obtained by means of a small number of simple new statements,
the user being familiar with FORTRAN need not learn a new ori
gina1 language, and cumbersome sequences of CALL statements
with long argument lists, ordered with a strict syntax, are
avoided in the executive program. On the other hand, CADEP in-
cludes all the facilities needed to describe, manipulate and
test in a flexible and concise way the patterns encountered in
the layout of today complex systems.
Geometric and physical aspects of the placement problem are
kept distinct by using two different types of variables, the
geometric and the graphic variables. The introduction of multi-
level graphic variables enables the user to relate patterns ly-
ing on different planes but representing the same physical ob-
ject, so providing CADEP with a sort of tridimensional capabi1i
ty.
REFERENCES

[lJ - H.FREITAG and W.E.DONATH - "Automatic mask and wiring pat

tern generation" - NASA-ERC Computer Aided Cir--
cuit Design Symposium - April 1967.
[2J - A.SPITALNY and M.J.GOLDBERG - "On-line graphics applied
to layout design of integrated circuits" - Proc.
IEEE, vol. 55, n. 11, pp.1982-1988 - November
1967.
[3J - P.W.COOK et ale - "Automatic network generation for large
scale integration" - IEEE Journal of Solid-Sta-
te Circuits, vol. SC-2, n. 4, pp. 190-196 -
December 1967.
[4J - J.ATIYAH - "The use of graphic display as an aid to inte-
grated circuit mask generation" - Proc. Computer
Aided Design Conf. - University of Southampton,
pp. 1-10 - April 1969.

276
 [5 J - J. WOOD et ale "Computer aided production of masks for sili
con integrated circuits" - Proc. Computer-Aided-
Design Conf. - University of Southampton, pp.122-
-129 - April 1969.
[6J - R.L.ROSENFELD - "Computer assisted mask production" -
Proc. of the IEEE, vol. 57, n. 9, pp.1629-1634 -
September 1969.
[7J - D.FERRARI and L.MEZZALIRA - "A computer-aided approach to
integrated circuit layout design" - Proc. of the
Conference on Computerized Electronics - Carnell
University - Ithaca - New York - August 1969.
[8J - A.D.RULLY - "A subroutine package for FORTRAN" - IBM Syst.
J., n. 3 and 4, pp. 248-256, 1968.
[9J - A.HURWITZ , J.R.CITRON and J.B.YEATON - "GRAF : graphic
additions to FORTRAN" - AFIPS Conf. Proceedings
of the Spring Joint Computer Conf., vol. 30,
Thompson Books, Washington, D.C., pp.553-557,
1967.
[lOJ - G.BRACCHI and M.SOMALVICO - "An interactive graphics
system for computer-aided circuit design" -
IEEE Conf. Record of the IEEE-GMMS ERS Int'l
Symp. on Man-Machine Systems, vol. 1, Cambridge,
September 1969.
[llJ - P.G.COMBA - "A language for three dimensional geometry" -
IBM Syst. J., n. 3 and 4, pp. 292-307, 1968.

277
 INTERACTIVE GRAPHICAL INPUT FOR
CIRCUIT ANALYSIS

M. A. Maclean and H. G. Bown

Department of Communications, Shirley Bay, P.O. Box 490, Terminal 'A', Ottawa 2,
Ontario, Canada.

ABSTRACT

A method is described for the interactiv~ drawing of electrical

circuit schematics with a computer-driven display. The aim is to create a
very clear and unambiguous display and to simplify the interaction technique
so that graphical input can become a working tool for the circuit engineer.
The drawing and labelling of schematics in preparation for circuit analysis
are illustrated by examples and the design of the programs and data structure
are described.

1. INTRODUCTION

This paper will describe a method for the drawing of labelled circuit
schematics through the medium of an interactive computer-driven display.
It was developed as a component in a modular system which will provide a
variety of facilities:

(a) interactive input of circuit schematics

(b) storage, retrieval and editing of schematics
(c) storage and retrieval of component da~a
(d) submission of circuits for analysis by a variety of
analytical programs
(e) storage and retrieval of the results of analysis
(f) interactive display of results
(g) hard-copy output of schematics, component data and results.

The system is intended to be used as a regular working tool by engineers

engaged in circuit research and development. Because of this it was
considered very important to provide a display of high quality and to develop
interaction techniques which involve the least possible amount of effort and
frustration on the user's part.

279
 The display of the schematic has been made as clear and unambiguous
as possible (see Figure 1). All lines and components are drawn either
horizontally or vertically, and crossovers are distinguished from junctions
by marking the latter with a dot so that topologically complex diagrams can
be drawn without difficulty. The component symbols are small and each one,
except the current source, carries a discreet direction indicator to mark the
direction of positive current flow which will be assumed by the analysis
program. This direction can be chosen by the user at the time of component
placement.

Despite the seeming lack of freedom implied by the directional

constraints, the positions of all elements in the drawing can be freely

The light-butto~s at the right of the display are those used by the drawing program.
Both ends of the component symbol light-buttons are active,and serve to select the
correct direction for' the symbol when it is placed in the schematic. The assumed
direction of positive current flow is indicated by the dot beside each symbol, except
for the current source (bottom). When a current source is dependent on the current
flowing in another branch, as it is for the three in this figure, the arrow inside the
symbol is replaced by the name which has been assigned to the controlling branch.
The 'ESCAPE' light-button causes an exit from the drawing program and allows the
user to select another function such as labelling or output specifications. The
width of this schematic is about 9~ inches.
Figure 1 Schematic of a Three-Stage Feedback Amplifier.

280
chosen by the user to give the greatest clarity or most pleasing appearance.
None of them are restricted in position except for the limits imposed by the
discrete nature of the CRT deflection system. This positional freedom is
achieved, together with an appreciable simplification of the effort required
from the user compared to what has appeared necessary in the past, by the
interaction technique employed during the drawing process. The essence of
this technique is the abandonment of the concept of positioning nodes and
components in isolation, and then connecting them together, and its replace-
ment by the concept of drawing a set of connected line-segments and
compon:nt~ ~n sequence. It ~s in this ~~e~ that the present techniqu: dif~ers
most s~gn~f~cantly from earl~er work[l] L5J, though the methods descr~bed ~n
references [3] and [4] appear to embody certain features of this approach.

The design of the data structure which contains the pictorial and
electrical description of the schematic is a most important consideration
in meeting the objectives of the system. To achieve the high quality of
display which is required, it must store a large amount of positional
information so that the user is free to arrange 'the elements of the schematic
with the minimum of restriction. To allow the greatest flexibility, the
drawing process must be regarded as an editing operation, instead of just the
incremental addition of new material, so that the user is free to go back
and modify his earlier work. A data structure with good cross-referencing
capabilities is needed, such as the ring-structure used in the 'Sketchpad'
system[6J, and this type of structure is also a very good source for the
input to a circuit analysis program.

2. THE GRAPHICS SYSTEM HARDWARE

The display hardware consists of a DEC PDP-9 computer driving a

13" x 14" magnetic-deflection CRT via a magnetic .dr~m buffer. Similar
display systems have been described previously[7] [8 . The magnetic drum
refreshes the display off-line and there is complete flexibility of style
for characters and symbols since the display code for them is generated by
software. Only a portion of the drum capacity is needed by the display and
the remainder can be used for the storage of program overlays and data.

The CRT deflections are controlled by a combination of absolute

position commands and incrementing commands. There are also commands to
control the beam on/off status and intensity. The basic unit of display code
is the 6-bit byte which can be decoded as a command or, in another mode, as
either one or two unit increments. The CRT beam can be jumped from corner
to corner in 15 ]Jsec or incremented in steps of 0.01" at 2 MHz and the bytes
are supplied by the drum at a 1 MHz rate, obtained by recording 6 tracks in
parallel. Each channel of the drum contains 15,360 6-bit bytes which can
display about 300 inches of vector or about 750 alphanumeric characters
(size 7x9) at 60 frames per second. Two channels of the drum can be used
alternately to refresh the display at 30 frames per second.

A solid-state light-pen controls a tracking-cross which is generated

by transmitting display code directly from the computer to the display

281
controller during a 780 ~sec gap that occurs once per drum revolution. To
identify displayed objects that the operator points to with the light-pen,
a special 6-bit byte called a 'tag' is recorded on the drum following the
display code for each entity. When this byte is read from the drum it
interrupts the computer which then looks for the occurrence of a light-pen
strike.

The picture is usually redrawn completely for each addition of new

material or each deletion. The redrawing time is proportional to the ampunt
of material displayed and is a minimum of 270 msec (16 drum revolutions) when
a whole drum channel is being rewritten. About 80% of this time is available
to the CPU for generating the display code, though the computing time is
frequently longer than this. The display shown in Figure 1, which used
slightly more than one complete drum channel, took about a second to redraw.
Small pictures appear to be redrawn almost instantaneously, the momentary
flicker of the display serving as an acknowledgement of the user's latest
request. It is possible to add new material to the end of the display file
without regenerating the entire file. For example, when a multi-digit number
is being generated by picking successive digits with the light-pen, a very
short response time is helpful. The component labelling program (Section 7)
uses this mode while the label is being built up and then redraws the entire
picture when the label is assigned to a component.
The display controller can drive other forms of display device which
require analog voltage inputs, for example a direct-view storage tube or an
X-Y~ecorder. For this purpose the controller receives display code directly
from the CPU with the appropriate timing.

3. OVERALL PROGRAM STRUCTURE

The PDP-9 will be connected by a 1200 bit/sec communication link to an

XDS SIGMA 7 time-sharing system to implement the complete system. It is
intended to use the PDP-9 for all the graphical display functions and the
interaction with the operator while the SIGMA.7 will be used for the circuit
analysis. At a later stage, however, it is planned to place more of the load
on the SIGMA 7. This will enable cheaper display terminals to be used.

Three distinct programs are used for the drawing of schematics, for the
labelling of components and nodes, and for specifying the frequency range
and the points from which outputs are required (Sections 4, 7 and 8 respect-
ively). A simple overlay system has been developed for the PDP-9 so that
these programs and their associated library routines (Section 6) can be
brought into core in a fraction of a second by a master. control program which
itself interacts with the user.

The data structure (Section 5) is resident in core during the execution

of all three programs and while circuit information is being extracted for
analysis.

All the programs are written in MACRO-9 assembly language and have the
following approximate sizes:

282
 WORDS WORDS WORDS

Drawing program 1070

Labelling program 750
Output specification program 730
Group (i) library routines 2050 2050 2050
(includes 320-word drum buffer area)
(ii) library routines 370 370 370
(iii)" " 360
(iv) " " 810 510 510
(v)" " 430
Overlay program 70 70 70

The data structure is not included in these figures and its size
depends on how large a schematic is to be drawn. Figure 1 required 1454
l8-bit words.

4. THE DRAWING PROGRAM

In its present state the
edit schematics with linear R,
sources and both dependent and
symbol can be used to simplify
voltage reference point to the
drawing program permits the user to create an~
Land C components, independent voltage
independent current sources. The ground
the drawing and it serves to indicate the
analysis program.

The basic entities in the data structure, which are also basic to the
drawing program, are the nodes, located at junctions, corners, line end-points
arid component terminals, and the branches which link the nodes. For the
purpose of dealing with electrical schematics the nodes are differentiated
into two types, ordinary nodes (O-nodes) and ground nodes (G-nodes), and the
branches into six types (R, L, and C components, voltage and current sources
and line segments). A new type of entity is introduced, the electrical node
(E-node), which exists in the data structure but has no graphical manifesta-
tion unless it is labelled by the user. In the following description, 'node'
means O-node.

The user builds up the schematic by using the light-pen to guide the
tracking-cross much as if he were using a pencil. The network grows
progressively as he interacts with the drawing program, moving the cross
along the branches of the network, around corners where necessary, and
placing component symbols where he wishes. Each light-button action causes
the data structure to be updated and the display to be redrawn. A simple
drawing sequence is shown in Figure 2. The light-buttons at the right-hand
side of the display include two directional arrow symbols for specifying the
direction in which the tracking-cross will be permitted to move, a selection
of component symbols (see also Figure 1) and the 'END' and ground symbol
light-buttons which terminate a drawing sequence. The 'CONNECT' light-button
is used to start a drawing sequence from an established node and to terminate
a line by forming a junction to a line at right-angles to the drawing path.

283
 Initially the user is free to move the tracking-cross to any part of
the screen where he wishes to start drawing. Alternatively, he can position
the cross near an existing node and point to 'CONNECT'. This causes the
cross to move to the nearest node and to be locked in place. In either case,
to start drawing, he points to one or other of the directional arrows in the
light-button area. This action causes a small marker circle to appear at the
tracking-cross position (Figure 2) and the cross to be constrained to move
only in the horizontal or vertical direction. The user positions the cross
at the point where he wishes to change direction and points to the other
directional arrow. The picture is now re-displayed with the marker circle
moved to the new tracking-cross position and a line drawn to it from the
previous position. In terms of the basic graphical elements a new node is
created when the user starts drawing, unless he used the 'CONNECT' function
which causes drawing to start from an established node. Each change of
direction causes another node to be generated and a line-segment to be linked
between it and the previous node. The marker circle moves from node to node
as the drawing progresses, as a reminder to the user of the position of the
tracking-cross at the last light-button action.

During a drawing sequence, if the user points to one end or other of

one of the component symbols displayed in the 'light-button area, a copy of
that symbol appears at the tracking-cross location and is joined by a line
to the earlier part of the drawing. The tracking-cross and the marker circle
move to the far end of the symbol ready for further drawing to take place.
The ~ymbol is automatically drawn in the direction currently selected and its
polarity is determined by which end of the symbol light-button was pointed to
by the operator. This method of component placement requires only two
movements of the light-pen for each component and it can be generalized for
use with multi-terminal components. Again, in terms of the basic graphical
elements, the placement of a component involves the creation of two new
nodes with the first one linked by a line-segment to the earlier part of the
drawing and the component placed between them.

The drawing sequence terminates when the user points to 'END' but he
has two other options as ~ell. If he positions the cross near a line which
is at right angles to the direction in which he is drawing, and points to
'CONNECT', the program creates a junction to that line. Alternatively he
may place a ground at the end of a line by pointing to the ground symbol
light-button. In the data structure the ground symbol is greated as a node,
but one having special properties. It can have only one branch incident
upon it and that must be a line-segment. The user cannot use the 'CONNECT'
light-button to start a drawing sequence from a ground node.

Nothing happens if the user points to a light-button whose function is

meaningless in the particular state the system happens to be in. In some
cases, also, the use of a particular light-button is illegal in the sense
that the program cannot respond in a meaningful way to the user's request
(for example, a request to change direction in the middle of a component).
In these cases, as before, no action is taken. The decision to take no action,
rather than display a diagnostic message, was an arbitrary one but has been
 (a) the user has just
created a corner by
pointing to the vertical
arrow and has moved the
tracking-cross down to
its present position.
The small marker circle
shows the tracking-cross
location when the
corner was created.

(b) by pointing to the

left-hand end of the
resistor symbol light-
button he has created
a component and
linked it to the
network. The tracking-
cross and marker circle
move to the free end
of the component. The
user now moves the
tracking-cross down in
readiness for drawing
a ground symbol.

(c) he points to the ground

symbol light-button and
the drawing sequence
is now terminated.
The marker circle
disappears and the
tracking-cross is
bumped slightly to
one side.

Figure 2 Steps ~n a SimpZe Drawing Sequence

justified by experience with the drawing program. The majority of these
incidents occur when the operator is trying to 'beat the system' and with a
little practice a serious user can work very rapidly without error.

We can distinguish three states of the program during the drawing

process :(Figure 3):

STATE 2 .. t STATE 3
DRAWING MODE ~----------~TC LOCKED
AT NODE

Rigupe J State Diagpam fop the Dpawing Progpam

State 1 - The tracking cros~is free to move anywhere on the screen.

State 2 - A drawing sequence has been initiated and the cross is

constrained to move only horizontally or vertically. The,
position of the cross after the last light-button action is
marked by a small circle. The user can now move the cross
(or not) and then change direction or place a component by
pointing at the apllropriate light-button. Each such action,
if accepted as valid by the program, causes the updating of
the data structure by the additi~n or deletion of any necessary
lines and nodes and the possible addition of a component,
followed by the re-display of the picture. The marker circle
moves to the new position of the cross. When the user
terminates the drawing sequence by pointing at 'END', 'CONNECT',
or at the ground sY,ffibol, the marker circle disappears and the
tracking-cross is bumped slightly to one side of its last
position. The program now reverts to state 1.

State 3 - This is entered from state 1 when the user points to 'CONNECT'.
The program searches the data structure for the node which is
closest to the position of the tracking-cross and moves the
cross there, fixing. it in place. The user can st.art drawing
from this point or can cancel the action and return to state 1
by pointing at 'END'.

The biggest problem to solve in the design of the drawing program was
to make it react in a reasonable way when the user moves the tracking-cross
back along a path already drawn. Rather than prohibiting this type of

286
movement, it was decided to attempt to have the program respond in the
majority of cases in a manner that the user would regard as reasonable, and
to ignore only the most outrageous requests. In fact, the solution of this
problem has given the program a great deal of flexibility and power that can
be exploited by a skilled operator.
Suppose that a horizontal row of lines and components has been created,
such as that shown in Figure 4, and that the marker circle is at one of the
hodes. The tracking-cross is assumed to be constrained to move horizontally
and the user can place it anywhere in the row, or beyond the ends, and ask
for a change of direction. The program responds in all cases except when the
cross is in the middle of a component symbol. If the cross is in the middle
of a line-segment, at point D for example, the segment is split in two and
a junction is created. I f it is beyond either end, the row is simply
extended as necessary.
I
I

I
I

'~
'10'
A B

4 ~

DRAWING I
DIRECTION I
I
Figure 4 Various Node positions in ReZation to
a Row of Line-Segments and Components
A component can only be created when the tracking-cross is beyond
either end of the row or, in the limiting case, at an end such as A where
there is a node with only one line incident on. it. The placing of a ground
symbol is subject to the same conditions - it is legal when the cross is at
A but illegal when it is at E. If the row consists of just a single node
and both the marker and the cross are located there, the placement of a
component or ground symbol is illegal because no direction has been defined.
If the marker and the cross are both at point A·of Figure 4, the direction
is implied by the row EA.

When the marker circle is at A and the tracking-cross is to the right

of A, the program assumes that the user intends to 'undraw' part or all of
the line-segment AB. This 'un-drawing' is not permitted to go past B,
because of the vertical line incident on B, and components cannot be removed
in this manner. If the user starts to create a junction at D, ,and then
changes his mind and continues to draw in the horizontal direction, the
program reacts by deleting the node D and replacing the segments CD and DE
by one segment CEo

It will be noted that a node such as D can exist during a drawing

sequence because it has been created in preparation for the drawing of a

287
junction. If, instead, the user terminates the drawing sequence at this
point by using the 'END' light-button, the node D must be deleted and the
segments CD and DE replaced by one segment CEo

To meet these requirements, the general structure of the routines which

respond to operator requests in state 2 is as follows:

(1) Investigate the legality of the request and proceed only if it is

a valid one.

(2) Examine the position of the marker in relation to the row it is in

and reposition it if necessary, deleting certain entities if required.
If the marker is at A of Figure 4, the segment AB and node A are
deleted and the marker is moved to B. If the marker is at D, then
node D is deleted and segments CD and DE are replaced by CE while the
marker is moved to C or E.

(3) Create a node at the position of the tracking-cross and join it to the
modified row either by joining it to an end node with a new line, or by
splitting an existing line into two segments, or by replacing one of th,
nodes which are presently part of the row. If a component or ground
symbol is to be added this is done now.

(4) If the drawing sequence is being ended here, the node which has just
been created must be examined to see whether it should remain as a
permanent part of the structure.

Figure 5 illustrates how the user can take advantage of the flexibility
of the program to go back and add a capacitor in parallel with an inductor he
has previously drawn. When he moves the tracking-cross to the left he does
not delete the right-hand resistor because components can only be removed by
the 'DELETE' light-button. Note that two new junctions are created in order
to add the capacitor. The left-hand junction is formed by simply changing
the direction of drawing from horizontal to vertical while the right-hand one
is created by the use of the 'CONNECT' light-button. After adding the
capacitor, the user can resume drawing to the right by linking to any node in
the row with the 'CONNECT' light-button.

The user is pausing in a drawing

sequence to go back and add a
capacitor in parallel with the
inductor~

Figure 5
The user can remove line-segments or components from the schematic by
pointing at the 'DELETE' light-button and then at the entity he wishes to
delete. In the case of a component symbol, the connecting leads also are

288
 He forms a junction by changing
the drawing direction to vertical.

He now draws horizontally and

positions the tracking-cross for
the capacitor.

The capacitor is placed and a

second corner is created.

The tracking-cross is positioned

ready for the 'CONNECT' operation.

When the second junction is formed

the drawing sequence is terminated.

However, the user has now pointed

to the 'CONNECT' light-button again
to resume drawing along the
original path.

A More Complex Drawing Sequence

~9
deleted as far as the nearest corner or junction or to the terminal of a
neighbouring component. A clean-up operation similar to step (4) above is
carried out on both sides of a deleted entity to ensure that the data structurl
is left in a valid state.

A dependency relationship between a current source and a passive

component can be created by pointing first at the 'DEP SRCE' light-button and
then to the two components, in either order. When the data structure has
been updated and the picture redrawn, the arrow inside the current source
symbol disappears and is replaced by the name of the controlling element, if
one has been assigned by the user. If the current source was aiready dependent
on another branch, the relationship is transferred to the new branch. The
user can destroy a dependency relationship in two ways - by removing a single
current source \rom its dependency on a branch or by eliminating the depend-
ency of a number of current sources on a single branch. To carry out these
operations he first points to the 'DELETE' and 'DEP SRCE' light-buttons, in
either order, and then to the dependent source or to the controlling branch
respectively.

5. DATA STRUCTURE DESIG:J

The topological description of the displayed schematic and the names and
values of the electrical components are stored in a ring-structure. The
structure which is now used has evolved from a simpler form which contained
only nodes and line-segments and could be used for the creation of line
drawings. Each entity is allotted a block of consecutive l8-bit words
containing a header word, which describes the type and size of the entity,
a number of ring elements to associate it with others, and data words which
characterize it. The housekeeping facilities have been kept as simple as
possible to minimize storage space. Ring elements contain forward pointers onI
and are of two types, ring-start elements with 1 in the most-significant digit
position and ring-member elements with O. There is a simple dynamic storage
allocation system which maintains a stock of returned blocks, sorted by
length, and satisfies requests for new blocks from this stock or from the
contiguous free space at the end of the ring-structure area.

The entity types are as follows:

(1) E-node (electrical node). This has the usual circuit connotation
and can be assigned a unique name by the operator to identify the
results of analysis. The only visual evidence of an E-node on
the display is its name, if one has been assigned, though every
electrical node in the schematic is represented in the data
structure by an E-node block. The make-up of the bloc~ is as
follQws;
header
member of E-node generic ring
head of O-nodes ring
X coordinate of name
Y coordinate of name
3-character name

290
 The X and Y coordinates permit the name to be displayed at an
arbitrary position. As shown in Figure 6, each E-node heads a
ring of one or more O-nodes or G-nodes which are, in turn,
linked by lines.
E-NODE
HEADER
E-NODES
0\ 0\
RING -r------.,
1\ II
x
y
NAME

O-OR G-NODE
HEADER
01 01 01 J--'
II - II II --
x
y

LINE RLC
HEADER HEADER
LINES
0 0
RING
0

r
O~
0 J O~
I
X TO
RLC DEPEND ENT
RING
Y SRCE
NAME

r- VALUE-
SRCE
RING
•
Figure 6 Organization of the Data Structw'e

(2) O-node (graphical node). Each junction and corner, the free
ends of line-segments and the ends of all component symbols are
represented in the data structure as O-nodes. Each belongs to
a ring headed by an E-node and is itself the head of a ring of
incident lines or components. An O-node is displayed explicitly
as a dot if it has 3 or 4 lines or components incident on it.
The block structure is

header
member of O-node ring
head of incident branch ring
X coordinate
Y coordinate

(3) G-node (ground symbol). This is structurally the same as an

O-node but the type number of the block, recorded in the header,
is different. The drawing program permits it to be placEd only
at the end of a single line-segment and not at a junction or
corner. This enables the display routine to draw a ground symbol
whose orientation is uniquely determined by the single line
incident on it.

291
 (4) Line. Each of these links two 0- or G-nodes and the block for
the line has two ring-member elements which belong to rings
headed by the start and end nodes. The block structure is

header
member of Line generic ring
member of branches ring from start node
member of branches ring from end node

(5) RLC (R, L or C component). Each of these joins two O-nodes and
the first part of the block is structurally the same as the Line
block. There is also a ring-start element which can head a ring
of dependent current sources. An RLC can be assigned a label
having a 3-character name and a 6-character value, located at
arbitrary X, Y coordinates on the display. The block structure
is

header
member of RLC generic ring
member of branches ring from start node
member of branches ring from 'end node
head of dependent sources ring
X coordinate of label
Y coordinate of label
3-character name
6-character value (2 words)

(6) SRCE (voltage or current source). These are similar to RLC

entities except that they have a ring-member element which may
be a member of a ring of dependent sources headed by a particular
RLC. The block structure is

header
member of generic SRCE ring
member of branches ring from start node
member of branches ring from end node
member of dependent sources ring
X coordinate of label
Y coordinate of label
3-character name
6-character value (2 words)

When a current source is made dependent, .its value is

interpreted to mean its strength relative to the current
in the controlling branch.

The overall hierarchical structure is shown in Figure 6. There are

four rings which group together all generically similar entities for the
entire picture, RLC's, SRCE's, Lines and E-nodes. These rings are traversed
for drawing the schematic on the display and when extracting data for

292
analysis. All O-nodes and G-nodes which are linked by line-segments are
grouped together in a ring headed by a single E-node (note that an RLC or
SRCE may link two O~nodes which either belong to the same or different
E-nodes - in the latter case its terminals are electrically short-circuited).

When the schematic is to be displayed, the generic rings are traversed

and their contents dealt with one by one. The two-terminal components and
lines are displayed by determining their end-points and drawing the appropriat
symbol with the computed orientation. If a SRCE entity is encountered, its
fourth ring element is examined to see if it is dependent, in which case
the name of the controlling branch is obtained and written inside the current
source symbol. When the E-nodes ring is traversed, each E-node is examined
to see if it has a name to be displayed. Following the display of the name,
its dependent 0- and G-nodes are displayed. The display code for each
entity (component plus label, E-node name, O-node etc.) is tagged so that
the origin of a light-pen strike can be determined by counting around the
generic rings. Note that a component can be picked by pointing either at
its symbol or at its label. An E-node is picked by pointing at its name or
at one of its associated lines, O-nodes or G..,nod'es. In the latter case the
E-node is identified by referring upwards in the hierarchy from the entity
directly responsible for the light-pen strike.

It has been found in a typical case that about 2/3 of the ring-
structure is occupied by 0- and G-node and Line blocks. Future expansion of
the component blocks to permit more elaborate characterization will therefore
not enlarge the structure unduly.

A small package of standard routines, not unique to this application,

is responsible for administering the storage allocation system and for the
basic operations of creating and modifying rings and moving pointers around
the structure. Its size is about 370 words.

6. LIBRARY ROUTINES

A number of library routines are called by the drawing program to build

and modify the data structure and to handle the display hardware. These
fall into several categories:

(i) The routines which control the, display hardware by generating the
display code for vectors, characters and symbols, generating and
controlling the tracking-cross and by looking for light-pen
strikes. The writing and reading of the magnetic drum buffer
are also the responsibility of this group.

(ii) The primitive ring-structure operators (Section 5).

(iii) Routines for creating and deleting the basic entities of

the schematic.

(iv) Routines for moving a pointer around the data structure and
for extracting information from the structure.

293
 (v) Routines for implementing various phases of the strategy of
the drawing program, described in Section 4.

The routines of group (i) are responsible for generating display code
in response to instructions of the form SETXY(X,Y) to position the CRT beam,
VECTOR (delta X, delta Y) to draw a vector, and UTEXT(N,string) to display
a string of N upper-case alphanumeric characters. The instruction SYMBOL(S,D)
draws the symbol S in one of the four possible directions specified by D.

Group (iii) consists of routines for the creation and deletion of the
basic elements of the schematic, the nodes, lines and components. They can
be regarded as the executive routines for a simple language which could be
used to describe a schematic in terms of its constituent parts and which, if
executed as a program, would build a valid data structure representing the
schematic. A block representing an O-node or a G-node is created by the
instruction NODE(X,Y) where X and Yare the display coordinates of the node.
A new E-node is automatically created at the same time and both blocks are
linked together and placed in the data structure. A line-segment is created
by the instruction LINE(NI,N2) where NI and N2 ate pointers to the nodes to
which the line will be linked. The E-nodes are automatically taken care of
by this operation - if the two nodes being linked belong to different E-nodes,
one of the E-nodes is deleted. Components are created by instructions of
the form RLC(NI,N2,T) or SRCE(NI,N2,T) where NI and N2 are node pointers and
T is the component type number. In these cases no deletion of E-nodes takes
place. Entities are deleted by single instructions. In the case of nodes,
the routine deletes the E-node as well if the latter has no other O-nodes
linked to it. There are two instructions for deleting a two-terminal entity.
The first simply deletes the entity after disconnecting it from its terminal
nodes. The other, used for line-segments only, splits the existing electrica]
node in two by creating a new E-node block and linking to it all the 0- and
G-nodes which are electrically connected to one end of the deleted line-
segment.

The group (iv) routines include three pointer-moving operations.

Starting with a pointer to the header of any node in the structure, the
pointer can be moved to anyone of the possible four nearest neighbour nodes
by the instruction NNODE(N) where N is between I and 4, or to the adjacent
node in the plus or minus direction by the instructions NPLUS(D) and NMIN(D).
The choice of X or Y directions is specified by D. 'Other routines compute
the X or Y distance between two nodes, find the number of line-segments or
components incident, on a node, find the type of bran,ch joining two nodes,
find the node which is closest to a given node or the line which is closest
to a given node in a specified direction. Also in this group is the routine
which traverses the entire data structure for the purpose of identifying a
light-pen strike or of displaying a schematic. When it is traversing the
structure for display purposes, it extracts the coordinates, type, and
orientation of "each entity it encounters, together with any text that has
to be displayed, and issues calls to the routines of group (i).

The routines of group (iv) include two tests for deciding the legality

294
of certain drawing actions, and three routines which carry out modifications
of the data structure.

TESTI(NI,N2,D) indicates the legality or otherwise of placing a

component or a ground symbol at the location of a test node NI
when the marker circle is at node N2 and the drawing direction,
X or Y, is specified by D. The placement is legal if NI is beyond
either end of the row containing N2 or if NI is located exactly
at an end such as A of Figure 4. A change of direction is legal
for all positions of NI except when it is in the middle of an RLC
or SRCE symbol.

TEST2(NI,N2,D) predicts what network branches will be incident on the

node NI if it is joined to the row in direction D which contains
the node N2. Its output is a 4-bit Boolean variable which
indicates whether NI will have branches in the +X, -X, +Y and -Y
directions. This routine is used preparatory to ending a drawing
sequence by the 'CONNECT' function to ensure that the junction
thus created will not have more than one branch incident on it in
any of the four directions. A test nod~ NI is created and the
TEST2 routine executed twice, once with respect to the node where
the marker circle is located and once with respect to a node at
one end of the line in which a junction is to be created. The
routine also returns with a pointer to the E-node to which NI
would be linked if the operation were carried out. This informa-
tion is used to prohibit a response to the 'CONNECT' light-button
if an electrical connection already exists. This restriction
ensures that the nodes and line-segments linked to any E-node in
the data structure always form a tree having no loops so that a
new E-node must always be created when a line is deleted.

RTRACE(NI,D) examines the node NI, which is the location of the marker
circle for a drawing direction D, and if its situation is like
point A or point D in Figure 4 it is deleted and the marker circle
is moved to an adjacent node. This accomplishes the 'un-drawing'
of the previous action in the drawing sequence, should this be
necessary, preparatory to carrying out the next step. RTRACE is
also used for deleting the connecting leads when a component symbol
has been removed by the 'DELETE' function.

JOIN(NI,N2,D) incorporates the node NI in the row, whose direction is

specified by D, which contains the node N2. NI may be beyond the
ends of the,row, in the middle of a line-segment or component, or
coincident with an existing node in the row. The only illegal
case, for which no action is taken, is when Nl is in the middle
of a component symbol. JOIN is invoked for all additions of new
lin~s or components to the data structure by the drawing program.

END(NI) causes the node NI to be deleted i f it either has no branches

incident on it or has two collinear line-segments and no other

295
 branches. In the latter case the two segments are replaced by
one. This routine is executed after terminating a drawing
sequence by means of the 'END' light-button or after deleting a
component with the 'DELETE' light-button in order to leave the
data structure in a valid configuration.

7. COMPONENT AND NODE LABELLING

Before analysis can begin, all components and sources must have values
assigned to them. In addition, any component to be selected for output must
be assigned a unique name. The blocks representing these entities in the
data structure have provision for names and values and when these have been
assigned by interaction between the user and the labelling program they are
displayed automatically each time the picture is redrawn.

The labelling program has been designed for flexibility in use, to

allow the user to position the labels on the display for the best clarity and
appearance, and to prevent certain types of error.

The operator uses the light-pen to compose tbe name and value in two
buffers which are displayed at the right-hand side of the screen (Figure 7).
The buffer contents are assigned to a component or electrical node by
pointing to the 'ASSIGN' light-button. A later version of the program will
permit the name and value to be assigned separately or together. The use
of a buffer makes it easy for the user to assign identical values to several
components in succession and also makes it possible for the program to check
errors before assignment takes place. In the case of the name buffer,
assignment is prohibited i f there is another entity in the data structure
having the same name. The value is checked for correct syntax, digit by
digit, as it is entered in the buffer and the whole buffer is checked for
completeness before assignment can take place.

Pigure? Display Format for Labelling

296
 Either buffer can be cleared and readied for input by pointing at the
'NAME' or 'VALUE' light-button. An empty box is drawn beside the light-
button to signify that the buffer is ready. Characters are then picked one
at a time from the selection below the buffers. In the case of the name
buffer there are no syntactical restrictions and any of the decimal digits
and multipliers can be used as well as any of the characters B,C,E,I,L,N,R
or V. In the case of the value buffer, the user can only insert decimal
digits, a single decimal point and one of the multipliers M, k, m, ~, nand
p. No provision is made to specify the electrical units because these are
implied by the type of component to which the value is assigned.

When the user is satisfied with the buffer contents he may assign them
to a component or electrical node. Note that either buffer may be empty and,
in the case of an electrical node, the contents of the value buffer are
irrelevant. The tracking-cross is used to help in the selection of a compo-
nent or node and to determine where the label is to be positioned. It is
locked in place beside the 'SELECT' light-button until the user points the
light-pen at part of the schematic. If he points at a component, the cross
jumps to the centre of the component and if he points to an electrical node
it jumps to the centre of one of the lines comprising that node or to a
component terminal. Usually it jumps right underneath the light-pen and can
be immediately moved to where the label is to be placed. When the light-pen
is pointed at the 'ASSIGN' light-button, the name and value are recorded in
the ring-structure block together with the coordinates of the tracking-cross.
The 3-character name and the 6-character value are displayed in the 1st. and
4th. quadrants of the tracking-cross. After a successful assignment the
tracking-cross is automatically returneq to the light-button area and locked
in place. If the entity previously had a label, the contents of the label
are replaced by the new ones but the old X,Y coordinates are used.

If the user is not satisfied with the position of a label he can move
it by selecting the entity with the light-pen, positioning the tracking-cross
to a more suitable place, and then pointing at the 'MOVE' light-button.

Since the label belonging to a component is displayed at the same time

as its symbol, they are one entity as far as the light-pen is concerned.
Thus the user can always verify that a label has been assigned to the correct
entity by pointing at the label. This should cause the tracking-cross to
jump to the centre of the component or to some part of the stru~ture of lines
and nodes that comprises an electrical node.

The 'SELECT' light-button cancels a component selection and returns

the tracking-cross to the light-button area. It is useful if the wrong
component has been selected.

8. OUTPUT SPECIFICATION

A maximum of ten named components or electrical nodes can be specified

for current or voltage output respectively. The program maintains a table
of these names and displays it on the CRT (see Figure 8). A new name is

297
appended to the table by pointing the light-pen to the component or electric&l
node and it is automatically displayed on the current or voltage side of the
table. Existing entries are deleted by pointing to them with the light pen.
The table is an up to date list of the selected outputs and can be changed
at any time prior to analysis. Since the user is free to change the schematic
or to alter the component labels, the drawing and labelling programs have
the capability to alter or delete names that have been previously placed in
the table.

Figure 8 DispZay Format for Output Specification

The first version of this system is for use with a small-signal Ac/nc
analysis program and provision is made for the operator to specify the initial
and final frequencies, and a mUltiplying factor: or linear frequency increment.
This is done by the entry of digits one at a time into four buffers which are
displayed on the CRT. As with the component labelling program, there is a
syntax check of the characters as they are entered. For initial and final
frequency and the linear increment the user can only enter decimal digits,
a single decimal point and one of the multipliers G, M or k. The Hertz is
the assumed unit of frequency. For the multiplying factor, the first
character must be a decimal digit other than O.

9. CONCLUSIONS

The reactions of users to the interaction techniques employed here have

been very good. The functions and use of the light-buttons seem to be easily
grasped and users soon learn to take advantage of the way in which the
drawing program reacts when they move the tracking-cross back along a path
they have already drawn. The use of the tracking-cross position as the
means of indicating the intended location of a component symbol, and the
automatic orientation of the symbol, lead to a minimum amount of movement of
the light-pen and reduce user fatigue. The reaction time of the drum-

298
refreshed display has proved quite satisfactory. It is completely negligible
for small pictures and for a picture the size of Figure 1, which required
about a second to redraw, the time is not excessive because it is no longer
than the time needed by the user to bring the light-pen back to the tracking-
cross to resume drawing. While the display is being redrawn, also, the
tracking-cross is still capable of being moved by the light-pen.

Several additional capabilities are planned - the extension of the

drawing program to handle multi-terminal components (such as digital logic
symbols, operational amplifiers, semiconductor device models), the ability
to draw a device model in the form of a sub-network which can then be used
in the main schematic as a single component[3][4], and more elaborate types
of component characterization. Our experience has been that the use of a
good data structure is essential for evolutionary development of this type
of system, a fact which has been noted previously[6], and that the data
structure itself is a candidate for evolutionary development.

We feel that the use of interactive graphics as a means of problem-

solving is so attractive that means will have to be found to implement it
more cheaply so that it can be more widespread and can be used freely and
without excessive concern for efficiency. With the increasing availability
of time-shared central computers, the question becomes one of how to reduce
the cost of the graphics terminal while maintaining an adequate standard of
service to the user. As a display device, the direct-view storage tube is
attractive because it needs no refreshing. It is also worth noting that
several storage-tube displays can be handled by one terminal with very
little extra complication. The traditional engineer is likely to have several
books or pieces of paper in front of him as he works and his interactive
counterpart will probably feel the same need.

If the terminal is made responsible for a1l the administration of the

data structure, it will probably need its own mass storage for the necessary
programs or else these will have to be transmitted from the central computer.
On the other hand, programs of the size required (Section 3) should not result
in excessive swapping overhead if they are executed in the central computer,
particularly since the sizes should be reduced by the longer word length and
more efficient instruction set. So it seems attractive, for a cheaper
terminal, to make it responsible for display maintenance and for simple
interaction (movement of a cursor, identification of which entity in a
display list is closest to the cursor position), and to reserve for the
central computer the tasks of data structure maintenance and the implementa-
tion of higher-level interaction strategies. It is intended to investigate
ways of achieving good interaction characteristics in this type of environment.

ACKNOWLEDGEMENTS

We would like to thank D.A. Brown for his work on the design of the
display hardware and R.E. Warburton for his contributions to the software
and the magnetic-drum buffer system.

200
 REFERENCES

1. H. C. So "OLeA: An On-Line Circuit Analysis System", Proc. IEEE Vol. 55,

No. 11, pp. 1954-1961, November 1967.

2. G.R. Hogsett, D.A. Nisewanger and A.C. O'Hara Jr. "An Application
Experiment with On-Line Graphics-Aided ECAP", 1967 International Solid-
State Circuits Conference Digest of Technical Papers, pp. 72-73,
Lewis Wi~ner, New York, 1967.

3. M.L. Dertouzos "CIRCAL: On-Line Circuit Design", Proc. IEEE Vol. 55,
No.5, pp. 637.654, May 1967.

4. D.S. Evans and J. Katzenelson "Data Structure and Man-Machine

Communication for Network Problems", Proc. IEEE Vol. 55, No.7,
pp. 1135-1144, July 1967.

5. F.F. Kuo, W.G. Magnuson Jr. and W.J. Walsh "Computer Graphics in
Electronic Design", Datamation Vol. 15, No.3, pp. 71-79, March 1969
(see also IEEE Transactions on Circuit Theory, Vol. CT-16 No.3,
pp. 389-391, August 1969).

6. I.E. Sutherland "Sketchpad: A Man-Machine Graphical Communication

System", M.I.T. Lincoln Laboratory Technical Report No. 296, January
1963 (see also Proceedings Spring Joint Computer Conference, 1963,
V~l. 23, pp. 329-346, Spartan Books Inc., Baltimore, 1963).

7. Control Data Corporation "Digigraphic System 270 System Information

Manual" Control Data Corp. Burlington, 1965.

8. H.S. McDonald, W.H. Ninke and D.R. Weller "A Direct-View CRT Console
for Remote Computing" 1967 International Solid-State Circuits Conference
Digest of Technical Papers, pp. 68-69, Lewis Winner, New York, 1967.

300
PRACTICAL LAYOUT OF PRINTED CIRCUIT
BOARDS USING INTER-ACTIVE GRAPHICS

1. Atiyah and P. K. Wall

Racal Research Limited, Newtovm, Tewkeshury, Glos.,
England.

Introduction

Circuit layout is the area that separates the design

and the production of electronic systems and equipment.
This presentation is concerned with the use of computer
facilities associated with Automatic Draughting Machines
to produce the artwork and documentation for the manufacture
of Printed Circuit Boards direct from the circuit diagram
and component data.

The presentation is based on a fully tested program

now in constant use providinG a rapid service to industrial
users on a competitive basis.

In general terms, layout consists of deciding the

relative positions of interconnected electronic components,
defining the physical paths of the connections and then
documenting the information in the required form.

The process carried out manually by a draughtsman

consists of attempts by trial and error, to minimize total
circuit area, total interconnection length and interconnect-
ion cross-overs. There are many constraints that may be
applied to different types of layout certain connections
may have a maximum length defined, or a minimum spacing;
components may have to be on fixed positions, or have fixed
orientations.

Finally a drawing of the finished layout is taped with

masking tape, then photographed to create artwork masters
necessary for the production of the Printed Circuit Boards,
Parts lists, drilling and assembly drawings.

~301
 The presentation reviews the facilities within the
Computer Printed Circuit Board Layout Program and how they
are used, and concludes with examination of some examples
and advantages over the manual methods.

Advantages of Using Computer Aids to Layout

Layout of Printed Circuit Boards, particularly complex

ones, is a lengthy process which can occupy many days and
even weeks of skilled effort and can greatly exceed the
time for testing the circuit once the boards are available.
Furthermore, modifications required as a result of these
tests can take an uncomfortably long time. The result is
that Printed Circuit Board Layouts using manual methods are
a bottleneck in the development cycle of new products.

In the manual method, it is easy for errors to occur

in the layout stage because interconnections have no signif-
icance without reference to the original circuit diagram;
hence if they are missed or added incorrectly to any of the
drawings, errors may not be noticed until prototypes are
produced. After layout the necessary drawings, artwork
and documentation have to be prepared.

All these factors lead to the need for improvement in

speed and reliability which computer aided layout gives.
This reduces the layout and documentation time from days or
weeks to hours, and incorporates protection against errors
and omissions.

The use of Interactive Graphic Displays

Circuit layout is a visual problem that computers

cannot cope with very effectively. To be sure, there
exist computer programs both for component placement, and
for the tracking of connections.

However the tracking programs, in particular, are only

100% successful in carefully chosen conditions and do not
take kindly to having varied constraints applied to them.
Even when they are fairly successful they may be relatively
slow.

Using a graphic display in an interactive layout system

enables the operator to combine with any automatic facilit-
ies and maintain the flexibility of the system. If the
automatic routines get stuck, or fail to meet the con-
straints, the operator can intervene and manually modify
the layout in such a way as to enable the automatic routine
to proceed further.

002
Printed Circuit Board Layout

If the Printed Circuit Board contains integrated

circuits placed on a fixed grid, then completely automatic
techniques can be used with considerable success, although
some manual intervention will probably be necessary at the
tracking stage.

A board containing discrete components, with a high

packing density, will need some manual intervention in the
placement phase, and maybe also in the tracking.

At REDAC SOFTWARE LIMITED, we have developed an inter-

active system using an I.C.L. 4130 with graphical display
to produce the necessary artwork and documentation for the
production of double-sided printed circuit boards.

This system is suitable for boards containing discrete

components, for boards containing integrated circuit
packages or a mixture of the two. Accordingly, manual and
automatic facilities are both provided to enable all types
of boards to be tackled.

To use the system, data describing the circuit compon-

ents and their connections is punched on paper tape. A
library of component types describing the dimensions and
connecting pads of each type to be used is being continuously
extended. It is intended to put this library on disc back-
ing store so that it may be accessed as required.

Each component is given a name of up to 4 characters

for identification purposes.

Operator facilities

The operator has a choice of "light button" commands

displayed on the screen in the right hand margin. A
message is displayed at the top of the screen indicating
what options are available to the operator at any stage and
indicating which side of the Printed Circuit Board is the
current operating one. Data describing the circuit may be
read in by selecting the command I/O.

The outline of the Printed Circuit Board is displayed,

component outlines are shown as rectangles, pads as small
crosses, and connections as point-to-point lines. Each
component has its name displayed above it.

By using the WINDOW command, the operator can cause any

portion of the board to be displayed at various levels of

303
magnification. A basic board increment of 0.025" can be
displayed as between 0.010" and 0.200" on the screen.

All of the various displayed items: components, pads,

names, connections and routes can be displayed at any of
three brightness levels, or made invisible. This is
achieved by using the command BRITUP.

Modification

The command MODIFY enables the user to alter the cir-

cuit data that has been read in. Components and connect-
ions can be added or deleted using the light pen, to select
the required items. Deleting is a two part operation, to
protect against inadvertently deleting the wrong item.

Placement

Components may be placed manually by using command

MOVE. A component is picked up with the light pen and
moved or rotated to the required position. Movement is on
a grid which is a multiple of 0.025", and which may be
altered at any time to suit the operation.

Automatic placement routines under PLACE, attempt to

optimise the layout with respect to total interconnection
length. A centre of gravity routine moves components to
the position and orientation which approximates nearest to
the equilibrium position, defined by considering its conn-
ections as elastic. A gridding routine places the compon-
ents on to a uniform grid, the size of the board, while
maintaining their relative positions.

Operation of these two routines achi.eves a reasonable

placement which may be improved by using a swopping routine
which attempts to swop pairs of components.

Another routine RECONN, replaces connection 'trees'

by equivalent minimum length trees, thus again reducing the
total connection length.

Routing

The operator has facilities for manually directing

connection paths on either side of the board. A route is
drawn as an elastic band from pad to the light pen and the
operator can turn corners by pressing a console button.
The route is finished automatically to the correct pad and a
route cannot be inserted where there is no connection in the
data. If a component has pads on one side of the board

304
only, then a route to that pad can only be started or fin-
ished on the correct side. Routes on the two sides of the
board are drawn with different brightness levels and if the
route is made to go through the board, the brightness levels
of the two sides are interchanged. Routes may be deleted
when they are replaced by point-to-point connections or
modified by moving any segment.

There are two facilities for automatic routing, which

may be used separately or together.

The first method is a completely automatic routine

which routes the board in an X-Y fashion, with orthogonal
segments of track on different sides of the boards. The
scheme is intended for integrated circuit boards, using
0.050" pads and plated through holes, 0.020" tracks and
0.015" minimum spacing. With these dimensions, dual-in-
line boards have been routed with a success rate of 90% -
100%. As the packing density of the boards increases, the
success may fall below 90% as i t also does if 0.075" pads
are demanded for the components. Remaining connections
may be routed manually, or by using the other routine
process.

The alternative routing process, which is more of an

interactive method, and a very flexible one that may be
applied to any type of Board with different sized tracks
and pads, is as follows.

The routing is carried out as a two-phase operation,

giving the operator a chance to interact between the two
phases. In the first phase, the routes are modified so as
to reduce the number of crossovers, by bending routes round
each other, and by placing route segments on each side of
the board. At this stage, the tracks are considered merely
as lines with no width. The operator can manually bend
round and allocate route segments to either side of the
board where the automatic tracking has still left cross-
overs.

In the second phase, tracks are automatically converted

into a series of right angled segments, and the spacing
between tracks and pads is checked.

Any tracks which are not completed, can be put in

manually using the facilities already described.

Output

A paper tape or magnetic tape describing the layout and

connections may be output at any stage. This tape can be

305
read back in at a later date to continue or modify the lay-
out.

The output contains all data concerning the circuit

and may be used to provide a variety of documentation. The
master photographs for producing the board are produced on
an automatic draughting machine, with an optical head, which
directly exposes a photographic film. The tape to drive
this machine is produced from the output tape of the layout
program, via another program. The draughting machine tape
contains instructions to expose various width of tracking,
various pad shapes and edge connectors for each side of the
board.

A tape can also be produced so that a numerically con-

trolled drilling machine can produce all necessary holes in
the board. An assembly drawing is also produced consist-
ing of component outlines and identifications using the
draughting machine, with a drawing unit in place of the
photographic head.

Future developments may include the production of

parts components lists, with descriptions of the components
being accessed from a data bank held on disc.

Application to Practical Problems

The facilities described have been put to practical

use. In fact they are now receiving regularly the most
severe test of all which is to provide a Layout Service
which is providing a service to industry not only in this
country but abroad. This gives a much greater variety
of printed circuit boards than would be provided from one
manufacturer alone.

The scope of the program providing this service is as

follows:-

1. Maximum number of components 500

2. Maximum number of connections 1000
3. Maximum board size 22.5" square
4. Maximum number of pads on a 63
component
5. Maximum number of connections 255
to a component
6. Maximum number of segments in 14
a route

306
7. Single and Double sided boards
can be handled, with or with-
out plated through holes
8. Track widths 6 values up to a
maximum of 0.100"
9. Pad sizes 4 values up to a
maximum of 0.100"

The program can be arranged to produce:-

(1) 1:1 Photographic masters for tracks and pads.

(2) 1:1 Drilling Master.
(3) 1:1 Component Outline Master.
(4) 2:1 Photographic Master for Handbook Printing.
(5) 2:1 Component Outline Drawing.
(6) 2:1 Component Ident Drawing. (no outlines)

To demonstrate the program facilities, masters from

two different Printed Circuit Board Layouts are attached.

It~will be noted that a mixture of discrete components

and Integrated Circuit packages can be handled.

A typical time between acceptance of a project and

completion of the artwork for circuits of this complexity
is 4 days, but much shorter times can be achieved where
delivery is of prime importance.

The advantages of this method of layout lie in the

speed of turnround, the accuracy of the resultant artwork,
the in-built checking routines for clearances between items
on the Layout, and the rapid modification which can be
achieved where alteration in the component number or conn-
ections is required by the circuit designer. Furthermore
storage of the master in Paper Tape Form in more than one
location is excellent security against accidental loss or
damage to the masters.

Conclusions

The techniques described are an excellent demonstration

of the creative partnership which is possible between a
designer who knows what he wants to achieve but has limited
capability to work out the consequences of his design dec-
isions and the computer which has superior speed, accuracy
and memory.

307
 The use of Interactive Graphics provides a means of
providing a rapid competitive service for complex Printed
Circuit Boards containing discrete components as well as
those containing integrated circuits.

In the Printed Circuit Board area in particular there

are many advantages in having the designer in close control
of the computerized design rather than leaving all process-
ing decisions to the computer. Further refinements in
this area and developments in other fields can be expected
using Interactive Graphics in the next year or two.

Acknowledgements

The authors gratefully acknowledge the assistance of their

colleagues in the preparation of this contribution and the
permission of the Directors of REDAC SOFTWARE LTD to publish it.

308
 +
1 1 'I ,11111111111"1 11 ,1111,111111111 " 1
1111 ,11,,111
, · · Z1 O O0 '

iI:
00. • 0 0

1000000 0 0

6~
: ~II ~: : P ;:
J r; 0 0 1 1
o . 000
0 0 0 0 0
0 0
! ~o
0
0
:
0
0
0
0

FIG 1 Artwork Side 1 + for Integrated Circuit Board

 +
••
•• •
- --;L ..
.•
D'
•a D
-
.
ru
• •
• D
--0 0 --'
....-
~o
ru • ••o ••
0-- --0
00000 0----0 0..-
0

-
0
0-----0 0 0

-
o 0 ~ 0

II
D a
•
DD--O~ ~
a •
•
~
o 0 o o:
••
--0 0 0 --0 0
o a o 0-- 0 0 0 --0

~ hIt
o 0 o 000 0 0 0
a
:--
--0 I
a
.....
--0 0 --0 0-- --0 0
--0 0 00000 o 00000 •• --0
o • L
T
..... 0 0
II I

--=:=1 0 0 OoD- - - -

~
1f1
:u ---l~
.
-
00----00

D··

-=:-UU :.r:
ru
Do

(1)--0 r:: 0

~~D~;:::::::::::;::::::::::::;~----~~::;;::::......................!;::::;

FIG ? Artwork Side 2 + for Inte~rated Circuit Board

 FIG 3 Artwork Side 1 for Discrete Component Board

IIIIIIII I

o
o
o

•o

311
 o

••
:B
o
o
T 0,
•
o 00
T •
oJ
o
••
o •
o
o
o
o
o o
o o o
000 0 o

o 00 0
I o
o
o o
o o
o 0
o o o o
o 0

•
o
00
0 o 0 o •
o
o 0
o •
o

o 0

o o
o

o
•• 1 •••••• • ••
FIG 4 Artwork Side 2 for Discrete Component Board
 COMPUTER GRAPHICS FOR INTEGRATED
CIRCUIT DESIGN

Lester Hazlett
Motorola Semiconductor Division, 5005 East McDowell
Road, Phoenix, Arizona 85008, U.S.A.

Introduction

State-of-the-art integrated circuits (ICs) are becoming extremely com-

plex. Because of this complexity, each new design will not see the wide-
spread use characteristic of simpler ICs. Thus, it is required that a great
deal of custom IC design be done quickly and at low cost. This is the role
of Computer Graphics in IC design.

Fig. 1
Many circuits are
processed together
in one wafer.

Fabrication of integrated circuits involves selectively diffusing im-

purities into a semiconductor wafer and selectively etching metal on the sur-
face of the wafer. Each processing step is controlled by lithographic tech-
niques using a different photographic mask. A mask is a high resolution

313
glass photographic plate used for direct contact exposure on a semiconductor
wafer. This determines the size and location of patterns diffused into or
etched on the wafer. As illustrated in Fig. 1, many integrated circuit die
are fabricated in each semiconductor wafer. Each wafer mask is a matrix of
identical chip size patterns. There is a set of masks for each integrated
circuit die; a mask set consists of a different mask for each process step.
To prepare each mask, master artwork is generated for a single die, reduced
in size, and stepped across the wafer mask. Mask stepping is commonly
handled by automatic stepping equipment, but until recently, the generation
of artwork masters has been a manual procedure.

This paper describes the computer graphics system for artwork generation
at Motorola Semiconductor Products Division. A brief history of artwork
generation is reviewed and the motivation for automating the procedure is
discussed. The capabilities of the overall computer graphics system are
described. This system is functional and in regular use, but continues to
grow, change and improve.

History of Artwork Generation

The classical method of preparing Ie artwork masters was completely

manual. The layout was done by a highly skilled draftsman who started with
a set of layout rules and a circuit schematic. From the draftsman's drawing,
artwork was cut on ruby material using a manual coordinatograph and then the
cut sections of ruby were removed in yet another manual step. This manual
layout procedure is illustrated by the sequence shown in Fig. 2. From the
circuit schematic to a complete artwork master set took from two weeks to two
months, depending on the complexity of the circuit. Because most of the man-
ual steps were sequential, a parallel effort did not appreciably speed the
preparation of a particular mask set.

Fig. 2a

314
 Fig. 2b
The manual method for
making integrated
circuit artwork masters.

Fig. 2c

This manual approach worked tolerably well in the past, however, three
problems rendered it unsatisfactory. The time required was too long, the
process was very subject to human error, and the master had to be prepared at
a very large scale factor.

A more up to date and better method of mask preparation is to use an

automatic drafting machine, such as the machine shown in Fig. 3, to generate
artwork masters directly by exposing photo-sensitive material with a moving
light source. The improvements from using this type of equipment are highly
significant. Not only is it more error free, it is inherently more accurate
-- and produces highly satisfactory work at smaller scale factors. The

315
 smaller artwork requires substantially less drafting time and eliminates the
first camera reduction step. Motorola's Computer-Aided Mask Preparation
system (CAMP) provides an output compatible with the automatic drafting mach-
ine, eliminating the need for manual ruby cutting and stripping. Now, com-
plex artwork takes a few hours instead of many days to prepare.

Fig. 3
Automatic
Drafting
Machine

CAMP

The CAMP system can operate in either the on-line or off-line mode.
While the two techniques have much in common, there is a fundamental differ-
ence.

In the off-line mode, the designer must do his own sketching on paper,
and then reduce his design to a dimensioned drawing on a work sheet. This
information is then fed into the computer in terms of component identifica-
tion and location. Although there can be much data to prepare, it is rela-
tively quick and straight forward to describe a complex integrated circuit
for drafting.

In the on-line system, the deSigner is using the computer extensively.

A computer-controlled cathode ray tube display is used as an interactive
sketch pad to try various geometric configurations. When an acceptable lay-
out and metal routing has been deSigned, the designer instructs the computer
to prepare drafting instructions.

The basic distinction then is whether nearly all of the work is done
with continuous computer assistance or whether a substantially larger portion
of the design is done by the man alone and only the detailed layer-by-layer

316
instructions are done by the computer. Fig. 4 shows the components of the
CAMP system. The off-line portion of the system uses card input. Cards may
be either keypunched or prepared on the digitizer. Visual feedback for the
off-line system is supplied by the ink plotter. The ink plot is examined for
correctness and accuracy. If the layout is satisfactory, the artwork is

,
drafted; otherwise the errors are corrected and the layout is replotted.

~ CARDS ~ - POLYCELL
AND
DEVICE INK
LIBRARY PLOTTER

CIRCUIT + "+- Fig. 4

SCHEMATIC

.... CAMP System

DIGITIZER COMPUTER
OR LOGIC
DIAGRAM Flmv Chart
GERBER

....
8
DRAFTING
- MACHINE

t
REDUCTION

At the present time, it appears that neither system is the complete

answer and that both methods of operation will be used for years. The off-
line system seems advantageous for any regular arrays and for extremely
large arrays, such as memories and shift registers. The on-line system
excells for moderate sized arrays of highly irregular configurations.

Po1yce11 and Device Library

The descriptions of circuit elements are stored in the disk resident

library and are available for either off-line or on-line reference. Active
devices, such as transistors and diodes are basic to the library. These
devices are often arranged into more complex structures, or polycells, such
as gates or flip-flops. Those commonly used can be stored in the library
giving the designer a more comprehensive set of building blocks.

Library data consists of electrical parameters, process data, graphical

data and history of usage. The graphical description consists of X-Y coord-
inates defining the boundaries of the various shapes. All shapes of a device
regardless of layer are defined relative to the same base point. When a
device is included in a design, all shapes are included automatically on the
appropriate layers. When a po1yce11 is included, all constituent parts are
defined with one placement and need not be individually handled.

Off-Line CAMP

The off-line system is a card input graphics language analogous to a

programming language. The off-line CAMP program is essentially a graphical

317
compiler which reads CAMP cards containing commands and graphical data.
There are eight main CAMP commands: Store, Place, Route, Array, Group,
Draft, and Halt. With these commands and the appropriate sub-commands, any
mask set can be specified and thus automatically drafted.

More efficient use of a graphics language can be made if the cards can
be prepared using a coordinate digitizer. With a digitizer, coordinate
locations are much more quickly and accurately generated than by encoding
and keypunching. The power of the library is still utilized for element
detail and only the positions of elements and metal paths are thus recorded.

On-Line CAMP

On-line layout is done through a CRT display console with light pen,
typewriter and functional keyboard. While on-line, the designer has all the
features of CAMP at his fingertips. To design a complex IC, he needs only
a circuit or logic schematic and a list of suitable elements. The CRT
display station is shown in Fig. 5.

With the light pen, he selects devices from the element menu, moves
them about the CRT screen and places them in any position and orientation he
wishes. A routing procedure is used to design metal patterns that inter-
connect the various elements on the IC design. Accuracy and operator con-
venience are facilitated with features for scale factor changes, zoom, grid
paper backgroud, direction constraints, invisible grid, and dynamic coordi-
nate readout in chip size units of measure. The designer can specify changes
in the mask layers displayed at any time to enhance his visibility.

Fig. 5
CRT Design
Terminal

318
 Through the dynamics of graphical interaction, several on-line pro-
cedures are made possible which have no off-line equivalent. Some of these
new procedures are Process Selection, Resistor Design, Device Design,
Element Design, Polycell Design, and Computer-Coached Placement and Routing.

Process Selection is a procedure for specifying the production process-

ing schedule to be used in the fabrication of the circuit. Processing para-
meters can be displayed on the CRT as shown in Fig. 6. Once the process is
selected, the computer can make element compatability checks to assure that
any library device or cell selected is process compatible. The process
constants are used to regulate element selection, and the standard spacing
rules constrain minimum layout spacing. Material resistivities, diffusion
profiles and junction depths are used in the calculations for design of new
resistors and active devices.

Fig. 6
Display of Process
Parameters

There are many resistor values and configurations used in the layout
design of integrated circuits. Because of this fact, it is impractical to
try to catalog resistors in the same manner as other components. Therefore,
a program has been written to create resistors as they are needed and store
them in the temporary section of the device library. Each layout uses this
temporary section for the resistors in its mask set. When a new design is
started, the previously defined resistors are wiped out and a new set is
specified. Inputs to the program are such variables as junction depth, end
effect constant, and preohmic width and length. From the process parameters
and total resistance, the computer calculates the overall length of the
resistor and displays it at the current scale factor. At this point, the
designer can modify the resistor by bending or folding it to achieve a de-
sired shape. As he does so, the computer recomputes segment lengths to main-
tain desired resistance. When the deSigner is visually satisfied with the

319
design, he accepts it for use in the layout.

On-line design of bipolar transistors is capable of using the Device

Design procedure. The designer chooses the basic device structure from a
list of six basic configurations. The computer then displays the selected
transistor in its smallest allowable form, along with a calculated value for
collector current (IC) limits and saturation resistance (RSAT). There are
three modes for modifying this minimal device. The size of the device can be
increased by expanding the collector. Horizontal increases make the collec-
tor moat get larger, and collector preohmics grow proportionally to fill the
expanded area. Vertical increases make all diffusions increase equally, so
shape-to-shape spacings remain unchanged. Any change in size on the part of
the device is accompanied by a change of the displayed values IC and RSAT.
The second mode of device alteration is to enlarge the collector base spac-
ing. This allows metal paths to be run through a device if otherwise allow-
ed. The third device alteration mode is called folding. Through folding, a
large current transistor can be created with interdigitated contacts.

Element design is a simple procedure for designing passive elements

such as bonding pads or other multiple layer shapes. It is a simple proce-
dure in which the designer specifies shapes, sizes and layers, and the com-
puter creates and names an element and puts it in the menu for future use.

The Po1yce11 Design procedure allows the designer to create or modify

cell structures while on-line to the computer. The actual operator manipu-
lations to do this are simple. Cell boundaries are defined by outlining and
constituent elements and metal segments are selected with the light pen.
The designer specifies a po1yce11 name and he is through. He can then mani-
pulate the po1yce11 as a single unit as shown in Fig. 7, and create multiple
versions of it by selecting its name in the element menu. During po1yce11
modification, all unassociated graphics are not displayed and the elements
in the cell can be individually altered. When modification is complete, the
polycel1 structure again assumes the form of a single unit. The modified
cell is renamed if unmodified versions of it are to remain in the design.

Some of the newest features of the on-line system involve the use of the
computer to coach the designer. To accomplish this, the computer must have
in its data base the structural information for the complete design. While
the designer is selecting and arranging elements, the computer keeps count
and can at any time list for him the number and type of elements which must
be added. The computer not only assures that all cells are present but will,
upon request, do a placement evaluation. This allows the designer to com-
pare the merits of one arrangement against another for total wire length
required. The coaching function continues during wire routing. When the
designer selects any cell output, the gates which it drives are blinked on
the CRT screen to help him interconnect them correctly. The computer main-
tains and can, upon request, display a list of output nets not yet completed.
An automatic wire routing procedure is incorporated which can find inter-
connecting paths one at a time. This procedure can be used either in free
running sequence or one wire at a time under supervision of the designer.

320
The success in using the automatic router is dependant upon the nature of the
design to such an extent that its utility is only realized because of its
coexistence with an interactive graphics system.

Fig. 7
A One-Gate
Polycell

When a design is complete, such as the one in Fig. 8., a magnetic tape
is generated for the ink plotter or the drafting machine. At this time, a
magnetic tape record of the results of the design session is created and
filed. If, at a later time, the designer needs to update or modify the
previously created circuit, he can do so by reading in the tape and starting
where he left off.

CAMP Drafting

The graphical output from the CAMP system is in the form of both docu-
mentation drawings from an ink plotter and solid image artwork masters from
an automatic drafting machine. The ink plotter is used because it can gene-
rate drawings which are multicolored and also because it costs less to op-
erate than the drafting machine.

The drafting machine is used for generating artwork masters. One of

the greatest disadvantages in using ruby on a coordinatograph is that a very
large scale factor is needed to be able to accurately strip and check the
ruby masters (typically 500 to 1). With component size decreasing and chip
size increasing, the trend is toward increasing rather than decreasing the
scale factor of ruby artwork. In fact, as complexity continues to increase,
it is quite likely that the required ruby artwork would be of such excessive
size that it would be completely unmanagable.

321
 The scale factor at which most of our mask masters are prepared on the
drafting machine is 100x. This minimizes drafting time and eliminates the
previously required first reduction. Masks of reasonable complexity take

Fig. 8
Completed IC
Design on CRT

about 30 to 50 minutes drafting time as opposed to two to five days ruby

cutting and stripping time.

All masters that are generated by the drafting machine are complete;
all shapes are opaque and require no further manual operations. The techni-
que used to direct the drafting machine to create solid images is called
"Painting." The ability to paint shapes is shown in Fig. 9. The painting
program in CAMP allows for any shape at any orientation and at any scale
factor.

CAMP Hardware

The CAMP system is a system used to generate complicated integrated

circuit mask masters. There are two hardware systems used in this process;
the first is a computer and CRT design console and the second is an automatic
drafting facility.

The Control Data 1700 is a small general purpose digital computer.

Some of its features are sixteen thousand 16-bit words of memory, 1.1 ]lsec.
memory cycle time, 16 external interrupt lines, mass memory with 1,536,000
words of interchangeable disk storage, teletype, paper tape reader, and paper
tape punch.

The CRT design console is a Control Data 274 display system. Its cath-
ode ray tube is 22" in diameter and has magnetic deflection. The entire

322
surface of the CRT is available as a working surface and positions are
addressed on a 4096 x 4096 matrix. It is a graphic display whose principle
of operation is based upon incremental vectors. Maximum line drawing speed
is 1.2" per 1.67 ps. Beam size is .015" and when moved, yields unifonn lines

Fig. 9
Time Exposure of
Gerber While
Painting Shapes.

of this width. The controller for the display system has a 8192 word core
memory buffer. It has a subroutining capability which makes possible repeat-
ed drawing of shapes without using a lot of additional storage. In other
words, the amount of picture that can be displayed depends on the unique-
ness of shapes in the design rather than the number of shapes. The refresh
cycle of the controller is set at 25 millisecond intervals for flicker free
operation. The display system has a light pen for use by the designer in
selecting and pointing to elements displayed on the screen. This light pen
consists of a tube which channels light into a fiber optics bundle, where it
is transmitted to a photo multiplier. A signal from the photo multiplier
causes a program interrupt in the computer so that the program can interro-
gate the display system to detennine to what element or position the designer
is pointing.

The Gerber 2032 Automatic Drafting Machine is a high resolution plotting

table with a DDP 116 computer as a controller. The computer reads numerical
control (NC) tapes and steps the optical head in the X and Y directions. The
step size is .0001 inches in either X or Y. The optical head or light source
has 24 program selectable apertures which range in diameter from .002" to
.187". There is also a variable density filter which changes light filtra-
tion proportionally with the speed of the head. This allows for unifonn
exposure of the film during drafting. The resident program in the DDP 116
computer controls the velocity, acceleration, aperture selection and light

323
filtration of the drafting head. The machine is capable of linear, circular,
and parabolic interpolation. Other features include symbol generation and
independent axis scaling. The ink plotter is a Computer Industries MTD
345-7 with magnetic tape input. It plots with different color ink or ball-
point pens on continuous roll paper 31 inches wide by any length. If it is
advantageous for the document to be larger than maximum width, CAMP can
generate tapes for side by side sections to be taped together. This feature
is called plot windowing.

Summary

Computer graphics for IC design is a young field and the techniques

used in the future may bear little resemblance to these now being pioneered.
As additional features make the system easier to use, it is anticipated that
designers will layout integrated circuits using the on-line system and have
their mask masters available the same day.

The application of computer graphics for IC design is a major undertak-

ing. The hardware requirements are impressive, but the major cost of a
computer graphics capability is in software, not hardware.

For the producer of ICs, computer graphics is not a luxury. Today it is

a highly useful tool and tomorrow it will be an absolute necessity.

324
 PART 4

Civil Engineering Applications

of Computer Graphics
 PERSPECTIVE VIEWS AND COMPUTER
ANIMATION IN HIGHWAY ENGINEERING
Larry J. Feeser and John D. Cutrell
Department of Civil Engineering, University of Colorado,
Boulder, Colorado, U.S.A.
Automatic Data Processing Branch, Region Nine,
Federal Highway Administration, Department of Trans-
portation, Denver, Colorado, U.S.A.

ABSTRACT
The paper describes a joint development project of the Office of Re-
search and Development, Federal Highway Administration (FHWA), the Federal
Projects Division, FHWA Region Nine in Denver, Colorado, and the University
of Colorado.
The project has concentrated on the development of an implementable
software package for producing perspective views of the design highway
system for inclusion as a subsystem of TIES (Total Integrated Engineering
~stem), a software package concept of the Bureau oT Public Roads.
The generation of perspective views of a design highway shows great
promise for use by the highway design engineer, the landscape architect
and the general public. Perspective views generated from design data can
be used by designers to aid in eliminating unsafe features and to visualize
the final view which will be seen by the driver.
An animation movie, simulating a driver's experience for an actual
design project is described The movie was made by photographinq the Cathode
Ray Tube (CRT) of the interactive graphics terminal at the University
of Colorado.
Results of the study point to increasing use of computer animation and
perspective plots in the highway design field.

327
INTRODUCTION
The evolutionary development of highway engineering computer graphics
follows a pattern quite similar to other areas of computer application.
In general, the advent of computers was followed by implementation of auto-
mated systems which were a duplication of formerly used manual methods.
This was followed by the second generation of hardware and consequent im-
provement in the degree of automation of data handling. By the end of the
second generation there emerged some changes in application methodology
which realized in a more full measure the potential of the computer. The
so-called third generation of computers produced a plateau in application
development where major efforts were directed at maintaining the continuity
of processes already computerized. It is only in the recent past that we
have been able to direct our attention to an emerging generation of appli-
cations which in concept are deserving of the adjective "advanced."
Prior to the introduction of the computer as a highway design tool,
graphic techniques were used in lieu of numerical methods in several steps
of the design process. It was believed that the computer would displace
the need for graphics; however, it was soon recognized that graphical data
representation was a very expedient means of evaluation. Since approxi-
mately eighty percent of the data for the design of a highway is available
in a computer processed data media, the use of computer graphics is enjoy-
ing a great amount of developmental effort currently. [1, 2, 3, 4]
In the design of a highway alignment, the interrelationship between
the horizontal and vertical spatial characteristics is sometimes difficult
to visualize. This is due, in part, to the classical approach to the
graphical representation. In much the same fashion as the architectural
profession uses the floor plan and the elevation drawing to depict a build-
ing, the highway is visualized by means of the "plan" (looking vertically
downward upon the facility) and the "profile" (viewing the highway trans-
versely in a horizontal direction) drawings. A typical "pl an and profile"
is shown in Figure 1. It takes the trained eye of a highly experienced
highway engineer to visualize the design highway and its impact upon the
topography with this approach to graphics.
Today's trend is away from the use of specialists who have this visual-
ization faculty, and towards interdisciplinary evaluation of highways and
their effect upon the environment. The eyes of the ecologist do not cor-
relate the plan and the profile into a composite view. The burden of pro-
viding a meaningful communications tool is placed upon the highway engineer-
ing computer specialist.
The response to this need is a very exciting application of computer
graphics and the subject of this paper, automated perspective plots. The
application of both computer technology and photographic techniques promises
to allow, not only the visualization of a design highway, but to permit an
evaluator to experience in animated simulation the feeling of driving on the
faci 1i ty.
The United States is experiencing an acute awareness of the impact of
major public work facilities upon the total esthetic environment. [5J Con-
servation of natural beauty has become a major decision factor in placement

328
 FIGURE 1 - Typical Plan and Profile Sheet
of highways. [6] Also, the road users in the United States are turning the
use of highways into an opportunity for an esthetic experience. Therefore,
added to the criteria of both safety and rapid travel is the requirement for
a highway facility to allow the user to see the beauty of the
country side and have a pleasant experience. Therefore, the technology
described herein has been received with enthusiasm by the highway industry
in the United States.
Another research objective has been to produce perspective plots of
highways at the lowest possible cost. This criteria is a difficult one to
meet because of the rather large amount of computation which is required.
In order to create smooth animation, the frequency of views must be kept
high enough to result in gradual advancement of the viewer. In addition
to this, the use of animation media for design comparison creates the need
for plots of several alternate alignment configurations. If our resultant
software is to meet these criteria, it has to be highly efficient and data
structure oriented rather than general in concept. Contributions to the
economy of the method were realized through:
1. Use of pre-existent data bases.
2. Efficient algorithms for coordinate transformation and for view-
ability of lines.
3. Photographing the Cathode Ray Tube (CRT) display device directly.
4. Use of a computationally efficient computer such as the Control
Data Corporation 6400.

329
 The methodology set forth is the result of sponsored research. It is
part of the U. S. Federal Highway Administration program of highway engin-
eering research for a Total lntegrated Engineering ~stem (TIES). TIES is
a major software development effort intended to provide an integrated
approach to computerized highway related computer science. [7,8] This
covers application areas such as route location, soils investigation, road
geometry, bridge design, and construction engineering and administration.
This program of research and implementation is administered by the Federal
Highway Administration's Office of Research and Development, under the
direction of the Engineering Systems Division. The analysis and programming
is contracted to state highway agencies, universities, and commercial soft-
ware developers.
METHODOLOGY
In the work which has been done by highway engineers to have computer
graphics provide visualization information, [4,9,10,11,12] the techniques
have been very specialized in nature and have been used in very limited
situations.
One of the major objectives of this project was to produce perspective
views of design highways at the lowest possible cost. The satisfaction of
this objective is critical if one hopes to find acceptance of computer
generated animation as a simulation tool in the design and evaluation process.
To effect efficiency, an established data base from the location and
earthwork automation is used as an input file for the developed program.
Data structured algorithms are used for the perspective coordinate trans-
formations and for the hidden line removal routine.
Basically, the methodology follows the process macro as shown in
Figure 2. There are seven basic steps which take place in the process.
They are:

FLOW DIAGRAM - HIGHWAY DESIGN PERSPECTIVE VIEW PLOT

EARTHWORK
COMPUTATIONS

COMPUTE
TRIORDINATES

330
 VIEWER
TRIORDINATE f---~ SCISSOR DATA POSITION
CODED ESTABLISH LINE OF SIGHT AND LINE
TEMPLATES OF SIGHT
DATA

PERSPECTIVE
TRANSFORMATION

HIDDEN
PLOT LINE
COMMAND DETERMINATION
LANGUAGE

PLOT COMMAND
TRANSLATOR

I
I
I

6 STATIC

~
PLOT
I

~
L?

FIGURE 2 - Process Macro Diagram

331
1. Input of data concerning location and direction of sight of the
observer's eye.
2. Set up and positioning of the window plane on which the perspective
view is projected.
3. Identification and retrieval of the basic cross section data from
the location and earthwork programs.
4. Perspective coordinate transformation for all points of a cross-
section.
5. Removal of hidden lines.
6. Output of final completed view to intermediate data base (PCl)
7. Display of perspective views on anyone of a number of devices such
as the CRT, 35 mm microfilm, hard copy from the microfilm or in
16 mm motion picture film shot from the CRT.

The program has been designed to allow certain f1exibi1ities in the

input information. In order to position the observer, the station, distance
left or right of the design centerline and the elevation above or below the
roadway surface must be provided. The line of sight of the observer may
be designated by providing information for calculating the x, y and z co-
ordinates of the point being looked at or by indicating that the line of
sight should be tangent to the design alignment. After being provided with
observer location and line of sight, the program generates a window plane
on which the perspective view is projected. Additional input at this stage
controls the scissoring process by limiting the size of the window.
Identification and retrieval of the basic cross-section data from the
location and earthwork programs yield x, y and z triordinates after merging.
This information is the primary data which must undergo perspective
transformation. These triordinate points are tagged with a positional code
so that the longitudinal connectivity information of lines may be retained.
Perspective Transformation
The technique used is basically the one described by Kubert, Szabo and
Giu1ieri [12J. The problem can be illustrated by points in three-space
(Figure 3) in which we know the coordinate locations of both the observer
and the point which must be represented in perspective coordinates along
with the direction of the line of sight of the observer, all ~ith respect
to a rectangular coordinate system, x, y, and z.
The observer is located at point 0 (ox' 0y' &oz) and the line OR
is the line of sight. A window plane is constructed perpendicular to the
line of sight. It is the projected coordinates of point P as they inter-
sect the window plane on a line connecting P to 0 which are the perspective
coordinates of point P. This projected point is designated S(X,Y) = S(~,n,s)
where X and V are the perspective coordinates and E.n and, are the x, y and
z coordinates of the point.
 Window plane

x p(x,y,z)

FIGURE 3 - Coordinate System for Perspective Transformation

Points 0 and P are described in terms of the overall coordinate system

x, y, z. The line of sight, OR, makes angles a, sand y with the x, y and
z axes respectively. The control parameter of the perspective projection
is the distance OR, which we will call d.
If we choose the X-axis such that it is parallel to the x-y plane,
then the transformation equations as given in Reference 13 are
X = [(~ - rx) cos S - (n - ry) cos a] / sin y

Where

~ = Ox + K(x - ox)
n = 0y + K(y - Oy}

S = Oz + K(z - oz)
and

r
X
= 0
X
+ d cos a

333
 r z = oz + d cos y

These transformations are general except for the case of the line of sight
being vertical (sin y = 0). In this case, one can use an alternate
definition of the X-axis and avoid the problem. In our problem, we are
not interested in looking vertically and therefore have omitted this
possibility.
The perspective transformation package of the program takes the input
information concerning location of the observer and the line of sight and
sets up the window plane by making use of the input distance, d. By read-
ing cross-sectional information in a serial fashion, the perspective co-
ordinates of each point are calculated and saved for later plotting.
Hidden Line Removal
Because of the large volume of data which must be handled to plot views
and because of constraints on the availability of core storage in most
design agency shops, an efficient hidden line algorithm which does not need
a large data base resident in core is used. While there is a rather general
hidden line algorithm [13], it requires that data on all points to be
plotted be available for checking during the entire procedure.
However, the data available from highway design information is highly
structured. The cross-section information occurs in a serial fashion with
each successive cross-section being farther from the observer than the
previous one, provided that tile roadway alignment does not have switchbacks
within the sight distance being plotted.
The Pennsylvania State Highway Department [14,15] has used a hidden line
technique which makes use of the structuring of the data to cut down on the
amount of data which needs to be retained when moving on to the next cross-
section. We have adapted this technique to our program.
In dealing with the first cross-section, perspective coordinates of
all the points of the cross-section are generated. Then plotting informa-
tion is generated for this cross-section. Now, since any successive point
whose perspective coordinates fall below the curve described by the first
cross-section are invisible, we can use this curve for checking visibility.
The curve used for checking visibility is called the blackout array and is
a collection of X and Y coordinates of points on the curve.
As additional cross-sections are looked at, the points are checked for
visibility and if visible, the blackout array is updated to include the new
visible points so that when the next section is encountered, its visibility
is checked against all previous data. This technique has proved to be quite
effective. One needs only to save the information in the blackout array as
far as data previous to the cross-section under consideration is concerned.
This saves considerable storage space. In addition, the checking for visi-
bility is simplified and shortened.

334
 Additional features of the hidden line routine include interpolation
capability, to handle visibility problems of line segments, and longitudinal
line generation and plotting.
The blackout array concept is shown in Fig. 4.
Updated Blackout Array

Old Blackout Array

~---
FIGURE 4 - Blackout Array Concept
Plot Command Data Base
~..;.;.:.;..;;,;..;,.;..;;..----

Early in the development of the program, it was decided to allow maxi-

mum flexibility in use of hardware and plotting devices. An intermediate
data base, called Plot Command language (PCl) was designed so that the in-
formation on a view could be used by a variety of devices by supplying
translator programs for the particular hardware and plotting device to be
used. PCl has the ability to handle annotation, rotation and scaling of
information. The main portion of the data base which deals with the point
and line plots has been kept as simple as possible. Each point of the plot
is represented by three items of information; 1) a draw or no draw command
2) an X coordinate to which the drawing device should move and 3) a Y co-
ordinate which corresponds to the X.
ANIMATION TECHNIQUE
Animation requires that a sequence of views be created in the correct
time lapse so that the viewer perceives motion. In order to make smooth
animation, the sequence must be spaced closely enough in the direction of
advancement to complement the visual acuity of the human eye. The rate at
which the sequence is viewed determines the rate of motion achieved. Con-
sequently, the smoother animation requires the generation of more views.
In the creation of animation which is useful to the stated purpose of this
technique, the number of views becomes very high. To simulate 60 miles per
hour of travel smoothly requires 520 views per minute of travel animation.
After the views are created, the filming process is brought into play.
The various methods of plotting which are available were evaluated for
ease of filming. These alternatives are:
1. Pen and ink plotting, such as the incremental drum plotter.
2. Plotting on microfilm directly.
3. Photographing a large CRT Display Device directly.

335
The first method is too slow and costly for this application. The second
is a very good method, possibly the best, especially if a 16 mm microfilm
camera is utilized.
The user of this program has the option of microfilm output (See flow
diagram in Figure 2); and the plots in Figures 5, 6, and 7 were output on
this media. The available microfilm plotter for our work is 35 mm and
the expense is $0.05 per frame. A 35 mm motion picture projector is
difficult to obtain; and $0.05 per frame makes the animation sequence quite
costly. This predicated the decision to photograph the CRT directly.

FIGURE 5 - Typical Perspective View - McClure Pass, Colorado

The photographic equipment used consists of a Bolex Rex 5 motion pic-

ture camera with 10mm lens, electric driven mechanism, single frame device,
and a remote release device. This camera is a reflex type; therefore, it is
a simple matter to achieve a properly aligned camera position. For these
initial stages of development, the camera is mounted on a tripod directly in
front of the CRT Display Device. Plans are to make a camera mount which
attaches to the CRT and includes a light shroud to eliminate external light
sources.
Filming for most non-sound projection equipment is done at the rate of
16 frames per second. Sound films generally may increase this to 24 frames

336
 FIGURE 6 - Typical Perspective View - McClure Pass, Colorado

FIGURE 7 - Typical Perspective View .. McClure Pass, Colorado

337
per second. Since our film has no sound, the 16 frames per second rate is
used. The demonstration film contains 3 duplicate images of each view in
the sequence. The distance between each viewer position is 10 feet. This
information is input to the plot program along with the viewer position
relative to the center of the highway. The viewpoint for this demonstra-
tion animation is 4 feet to the right and 4 feet above the centerline of
the roadway.
The demonstration animation is taken from actual data for a project in
the mountains of Colorado. The highway was designed by Region 9 of the
U. S. Federal Highway Administration and traverses McClure Pass which has a
maximum altitude of 9500 ft. above sea level. An oblique photograph of a
roadway typical to that of the animation is shown in Figure 8. Viewing of
the demonstration film never fails to spark a great deal of enthusiasm for
this technique.
IMPLEMENTATION
The implementation of all software systems with the TIES concept is
geared to the needs of the various State Highway Departments. This criteria
creates a divergence from the pre-stated goal of using a computationally

FIGURE 8 - Oblique Photograph of Typical Roadway

338
efficient computer for economical production of animation. The reason for
this divergence is that the typical State highway department is using a
computer which is not computationally oriented. Because of the non-tech-
nical processing involved in the administration of a highway department,
the computational efficiency of a computer is preempted by requirements
which are based on data processing needs. This situation does not, however,
preclude the economic preparation of perspectives on these machines.
An even bigger constraint on the implementation of this technique is
the lack of proper graphic display devices in individual State agencies.
Some 35 of the 50 States have digital plotters; but currently none of these
highway design agencies has CRT graphic display equipment with vector
capabilities. This situation is changing, as the usefulness of these de-
vices is increased through application development. Certainly the design
methodology for highways is a fertile area for interactive graphics tech-
niques. As research and development funds are made available the potential
in improvement of automation aided design will be realized.
The highway design perspective plotting technique was developed on two
computer hardware configurations simultaneously. One of these, the IBM 360
model 40 with l28k bytes of core memory does not have interactive graphics
capability. A Calcomp 663/770 incremental drum plotter is available at this
installation. This configuration is used to test the basic system archi-
tecture. Resultant PCl output may be plotted on the incremental drum
plotter for quick verification. The other configuration is a Control Data
Corporation 6400 with 64k words of fast core memory and 125k words of ex-
tended core storage. Figure 9 shows the operator console of this equipment,
which is located at the University of Colorado. The graphics I/O at this
installation include the CDC 280 Microfilm Plotter using a 35 mm camera, a
Calcomp 763/770 Incremental Drum Plotter, and a CDC 282 Interactive Graphics
Terminal.
Use of the PCl allows any specific perspective view to be plotted on
one of four media:
1. Paper and Ink Drawing
2. 35mm Microfilm
3. Microfilm Hardcopy
4. The CRT Display Device
The latter is pictured in Figure 10 and serves two purposes; first, to give
the highway engineer a quick way of viewing a design plot; second, it is
the image source for l6mm animation motion picture filming.
The useful application of this technology is divided into static and
dynamic uses. Examples of the single static view of the design highway are
shown in Figures 5, 6, and 7. These serve as a very useful evaluation to
allow the design engineer to examine a particularly complex combination of
vertical and horizontal geometry. This type of plot is also useful as a
communication of the design features to the public. Figure 11 is a plot
which has been used by the Federal Highway Administration, in Denver, Colo-
rado, as information for property owners of contiguous land to the design

339
 FIGURE 9 - Operator Console of CDC 6400
project. The cultural features were added by a landscape architect with
very little effort to enhance the realism. Prior to the creation of this
perspective representation of engineering data, it was necessary to use
graphics similar to those shown in Figure 1 to satisfy this requirement.
The resultant improvement is obvious in comparing Figure 1 with Figure 11.
The dynamic plot, highway design animation, is the subject of a great
deal of interest. It allows the designer, safety expert, aesthete, or
behavioral scientist to experience a simulated drive along the design high-
way. Similar animations have been made in other engineering disciplines
during the last few years. [16, 17, 18, 19] In 1968, at the Highway Research
Board Meeting in Washington, D. C., the engineers from the Service d1etudes
Techniques des Routes et Autoroutes of France [4] presented an early ani-
mation effort as viewed from the driver1s eye. This motion picture was
made from a sequence of static plots which were retouched prior to filming.
This was a very impressive piece of work. The process of animation with
this technique was quite costly by U. S. standards. The methods represented
herein are designed to be more realistic from a cost standpoint, without a
significant sacrifice in quality.
Input to our technique is derived from the design calculations system
of computer programs known to the highway engineer as Earthwork Computation
(See Figure 2). The Coded Template File is a normal output of Earthwork

340
 FIGURE 10 - Interactive Graphics Terminal
Computation. This data is referenced to some line in the horizontal plane.
The data is not related to three dimensional space until it is correlated
with the Horizontal Alignment Data. The resultant data, given as x, y, and
z triordinates, is also tagged with a positional code so that the longitu-
dinal lines of the plot may be determined. The Horizontal Alignment Data
is standard data to the Highway Location Calculation computer system. The
only input parameters which the user must submit to obtain a view are the
location of the viewer and the direction of sight. The former is given as a
position above or below and left or right of a roadway "station." The
latter is given as a vector in three dimensional space or else the system
defaults to the direction of travel at the indicated roadway IIstation.
1I

CONCLUSIONS
Highway design animation is presented as a working tool to the highway
design discipline. The merits of a dynamic simulation method for IIdriving"
upon the design facility prior to actual construction are nearly self-
evident.

341
 ENGINEERING SYSTEMS DIVISION U. S. DEPRRTtENT OF TRANSPORTRTION
VIEW 100 FEET LEFT OF STRTION 372+50
FEDERAL HIGllWRY RIlI1INISTRllTION
PROJECT 271'1-023 <TIES)
BlRERU OF PUBLIC ROROS
ST. VRRIN CANYON RORO
oe/0ll/69
REGION 9 - OENVER. COLORRCO

FIGURE 11 - Retouched Perspective View

The importance of well-engineered highways for our environment has in-
creased sharply during the past decade. A higher degree of attention is now
paid to the adequacy of highways to transport persons safely, comfortably
and swiftly across the reaches of the land. Highway design warrants the
extensive consideration of various disciplines in order to achieve these
community values. A focal point for interdisciplinary consideration and
evaluation is needed. Highway design animation serves this need, to a
large measure.
At the suggestion of the U. S. Federal Highway Administrator, Mr.
Francis C. Turner, a new emphasis has been placed on applied highway
research and development in the United States. [20J Highway design anima-
tion is being installed as a working software system by functioning highway
design agencies.
New criteria for highway location and design which are based upon
visual and kinesthetic sensation are being developed. [21, 22J Highway
design animation offers an effective tool for the evaluation of data related
to these aspects also. It is apparent that this technique is a mere
beginning to the application of animation graphics and computer driven
display devices to highway design.

342
ACKNOWLEDGEMENTS
The work on this project is supported by The Federal Highway Administra-
tion Office of Research and Development as Study No. 2712-413, TIES Project.
This Study is under the direction of Mr. L. R. Schureman, Chief, Engineer-
ing Systems Division and supervised by Mr. J. D. Cutrell.
We would like to express our acknowledgement to Mr. Carl Izzard,
Director of the Office of Research and Development, FHWA, Mr. Charles D.
Beach, Region Nine Federal Highway Administrator and to Mr. Daniel C.
Harrington, Chief, Federal Projects Division, FHWA, Region 9, for their
encouragement and support of the work in this area.
The cooperation and advice of Dr. E. Rex Krueger, Director of the
Computing Center, University of Colorado and Dr. Robert L. Schiffman,
Research Associate, Computing Center, University of Colorado, is
appreciated.
REFERENCES
1. Maxwell, Donald A., "Computer Graphics as a Design Tool, II Proceedings/
National Conference, Committee on Electronics, American Association of
State Highway Officials, May 1969, Seattle, Washington.
2. Cutrell, John D., "Computer Graphics," Presentation at the 11th Annual
Highway Engineering Exchange Program, September 1969, Washington, D. C.
3. "IBM 1130 Highway Design Presentation System at Lochner Computer Service,
Inc.,11 IBM Application Brief, K20-0316-0, White Plains, N.Y.
4. Godin, P., et~, "Visual Quality Studies in Highway Design," Highway
Research Record No. 232, 1968, pp. 46-57.
5. Bridwell, L. K. and Turner, F. C., "Joint Development of Highway
Corridors and Multiple Use of Roadway Properties,1I Memorandum Issued
17 January 1969.
6. Federal-Aid Highway Act of 1968, United States Code.
7. Schureman, L. R., Collins, W. H., and Tennent, R. C., "TIES," Proceed-
~, Conference on Improved Highway Engineering Productivity, May 1968,
Boston, Mass.
8. Co 11 ins, W. H., Progress on TI ES, Proceedings, Conference on Improved
II II

Highway Engineering Productivity, May 1966, Columbus, Ohio.

9. Smith, B. L., and Fogo, R. D., "Some Visual Aspects of Highway Design,"
Highway Research Record No. 172, 1967, pp. 1-20.
10. Smith, B. L., and Yotter, E. E., "Visual Aspects of Highway Design,"
Special Report No. 80, Engineering Experiment Station, Kansas State
University, June 1968, Manhattan, Kansas.
11. Geissler, E. H., "A Three-Dimensional Approach to Highway Al ignment
Design,.' Highway Research Record No. 232, 1968, pp. 16-28.
12. Park, R. A., Rowan, N. J., and Walton, N. E., "A Computer Technique for

343
 Perspective Plotting of Roadways," Highway Research Record No. 232,
1968, pp. 29-45.
13. Kubert, B., Szabo, J., and Giulieri, S., liThe Perspective Representation
of Functions in Two Variables," Journal of the Association for Comput-
.il!9. Machi nery, v. 15, n. 2, April 1968, pp. 193-204.
14. Smith, J. S., "Pennsy1vania Department of Highways Perspective Plot
Program," Presented at the Highway Engineering Exchange Program Area I
Subgroup Meeting, May 1969, Albany, N. Y.
15. Schwartz, C., "Computer Graphics," Presentation at the 11th Annual
Highway Engineering Exchange Program, September 1969, Washington, D. C.
16. Knowlton, K. C., "A Computer Technique for Production of Animated
Movies," Bell Telephone Laboratories (16 mm film, 17 min., silent).
17. Zajac, E. E., "Simu1ation of a Two-Gyro, Gravity Gradient Attitude
Control System," Bell Telephone Laboratories (16 mm film, 4 min. sound).
18. Group T-3, "Computer Studies of Fluid Dynamics," Los Alamos Scientific
Laboratories (16 mm film, 7 min., silent).
19. Sinder, F. W., "Force, Mass and Motion," Bell Telephone Laboratories
(16 mm film, 10 min., sound).
20. Turner, F. C., Keynote address, Highway Research Board Meeting, January
1968, Washington, D. C.
21. Hornbeck, P. L., et a1., Highway Esthetics, Interim Report on Contract
No. FH-1l-6620, B.P.~ Landscape Architecture Research Office,
Harvard University, 1968.
22. Hornbeck, P. L., et~, Comprehensive Highway Planning, a report to the
U. S. Department of Transportation on aesthetic and behavioral
criteria for highway design research, Harvard University, 1969.

344
 THE USE OF INTERACTIVE COMPUTER
GRAPHICS IN SOIL ENGINEERING
ANALYSIS AND DESIGN
J. R. Stein
E. R. Krueger
R. L. Schiffman

Computing Center, University of Colorado, Boulder,

Colorado, U.S.A.

SYNOPSIS

This paper describes the use of the CUG (Colorado University

Graphics) interactive graphics system for the development of
command structured application systems in soil engineering. The
following application systems are described: RING, for analyzing
the progress of settlement of multi-layered soil profiles; ELASTING,
for analyzing the stresses and displacements in a multi-layered
elastic profile; and FEMALE, for analyzing the stability of earth
and rock slopes.

INTRODUCTION

The nature of soil engineering as a civil engineering discipline

is, in a very special way, uniquely related to the need and use-
fulness of interactive computer graphics in a design mode. In the
early years of the development of soil mechanics the traditional
engineering approach was used. That is, material behavior was
characterized within the bounds of engineering mechanics. Consequently,
all analyses of real problems were forced into the framework of the
state of knowledge of engineering mechanics, as it existed at that
particular moment in history. This early thinking reflected the
prevailing philosophy of the structural engineer. It was severely
deficient on two counts. First of all, material characterizations
could not fit into the pattern of normal, man-made structural
materials. By its nature, soil and rock exhibited complex behaviors

345
that required material characterizations beyond the capability of
early conceptions of mechanics. On the second count, the design
requirements were of a highly sophisticated nature. While the
design of structural elements could use, if necessary, the most
rudi-mentary procedures, soil engineering design requires highly
sophisticated mechanics to provide an adequate analysis of the
earth's response.
Because of these deficiencies in the mechanics approach, soil
engineering, in its genesis, moved toward a descriptive approach
based upon the geological sciences (Terzaghi, 1936). Analytical
techniques were largely replaced by descr·iptive and observational
analysis. This empirical approach was accelerated and strengthened
by the requirements of military construction during World War II.
Empirical soil engineering flourished until the mid 1950's.
Then, structural requirements for the newer types of structures
generated a need for a higher precision of soil engineering than
could be achieved by a straight empirical approach. There was, as
a result, an increasing emphasis on relatively precise laboratory
measurements and on accompanying theoretical studies of laboratory
and field behavior. The latter phase has been made practical only
by the use of the digital computer.
About the time that the need for theoretical analyses in soil
engineering was becoming apparent, the relatively large scale digital
computer was coming into general use. Two factors contributed to
this result. First, mass production made standard hardware readily
available. Secondly, the development of procedure-oriented languages
such as FORTRAN (Backus, 1957) and ALGOL (Naur, 1963) enabled
computers to be used by individuals not specifically trained in
the computer sciences. Because of these languages, computational
systems lost their machine dependent uniqueness. Thus, the computer
could be used as a tool in a wide variety of disciplines.
Early computer usage in civil engineering was confined to
analytical problems, specifically formulated. The first direct
applications were, interestingly, in the area of soil mechanics.
These were problems concerned with pile driving (Smith, 1951) and
layered elastic foundation systems (Schiffman, 1957). These early
problems were highly specific applications which were machine
dependent (on plug board machines) and required considerable amounts
of card handling and off-line operation. With the development of
the stored program machine, computations of surveying traverses,
highway slope analyses, cut and fill studies, and specific structural
analysis problems become available.
In the early 1960's it became apparent that the use of the
computer and computational techniques had great potential for civil
engineering practice. It was also apparent that the civil engineer,

346
because of his training and outlook, was not going to exploit fully
the computer's potential if programs had to be written in a relatively
restricted procedure-oriented language. This need stimulated the
development of the problem-oriented languages such as COGO (Miller,
1961) for highway traverses, STRESS (Fenves et al, 1965) for
structural analysis, SEPOl (Jordan and Schiffman, 1967; Schiffman,
Whitman and Jordan, 1970) for settlement calculations and lEASE
(Bailey and Christian, 1969) for slope stability analysis. These
languages, within the I/O constraints of the batch process mode,
permit the civil engineer to perform calculations on a "what if"
basis without the constraints of a rigid language structure. As
far as the soil engineer is concerned, this type of computer usage
permits a mechanism for sophisticated theoretical analysis to be
integrated with empirical data.
The potential for developing a computational system providing
a high degree of theoretical and empirical integration is dependent
upon the type and degree of interaction which can be established
between the engineer, laboratory or field instrumentation, and the
computer. In the batch process mode, the problem-oriented language
provides useful access to the power of the computer, but does not
provide an efficient interaction. Graphics output devices such as
microfilm or pen plotters are useful in providing a visual mode of
output in which alphanumeric batch output need not be plotted by
hand. These devices, hO\,Jever, lack interactive capability.
Interactive graphics, coupled with a problem-oriented language,
provi des many of the characteri sti cs needed by the soil engi neer:
a graphical display, full man-machine interaction and simplicity of
I/O in terms of language structure.
This paper descr-ibes a study in the development of an interactive
computer graphics system with specific applications to problems
concerned \'Jith soil engineering. The systems described herein have
been implemented on a CDC 6400 using a CDC 280/282 interactive display
system.
Three soil engineering application systems are described. They
are: RING (Rate INteractive Graphics), a system for predicting the
progress of consolldation of multi-layered soil deposits; ELASTING,
(~Jastic !:&yer STress - l..!lteractive §..raphics), a system for determin-
ing the stresses and displacements in layered elastic media; and
FEMALE, (FEllenius - tlay Analysis - Limiting Equilibrium), a system
for analYZlng the stability of earth-structures using the Fellenius -
tlay technique (Esmiol and tlelson, 1963).

I NTERACTI VE GRAPHI CS SYSTEtlS AND LANGUAGES

There are two basic components to the implwentation of a graphics

347
 system on any computer. First are the basic software drivers for the
interactive graphics system. Using these drivers a variety of applica-
tion programs can be developed for a given problem. The second com-
ponent of the interactive graphics system is the user language.

The CUGSystem
All the interactive graphics applications programs at the University
of Colorado operate under the CUG (Colorado University Graphics) system.
This system provides the basic drivers which-the application programs
described here, and others (Feeser and Cutrell, 1970) utilize.
The CUG (Dohrmann, 1969) system consists of a series of Central
t1er.lOry and Peri phera 1 Processor programs written in COMPASS for the
CDC 6000 Seri es machi ne. They a re FORTRAN call ab 1e.
The display equipment consists of a CDC 280 Display Controller,
a CDC 284 Microfilm Recorder, and a CDC 282 Display Console.
At this time, the CUG soft\'/are consists of three entities:
1) A series of plot code generation routines which enable a
batch process program to generate a plot file. In turn, the
plot may be viewed on the CDC 282 console or on the CRT
associated with the CDC 284, or both.
2) A microfilm production driver which records alphanumeric and
vector plots on 35 mm microfilm.
3) The interactive system which permits interaction to take place
between the CDC 282 and the CDC 6400.
There are three basic modes of interaction:
1) The alphanumeric keyboard with 44 keys.
2) The function keyboard which permits the use of 12 switch
indicators with overlays.
3) A light pen with a three position switch.

The application systems described here use the alphanumeric key-

board exclusively. The choice of a single mode of interaction was
dictated solely by the user requirements for a given problem.
The CUG system was developed with the needs and limitations of the
application programmer in mind. It was assumed that the development
of applications programs would be accomplished on the FORTRAN level.
Furthermore, it was assumed that the applications programmer would
have a reasonable proficiency in FORTRAN, but would generally not have
a proficiency in lower order languages. Professionally trained in a

348
particular application area, his concern would be with the appropriate
man-machine interactions required for the particular system being
programmed for that area. Thus, the CUG system would, by necessity,
be re.quired to have the same simplicity as the standard FORTRAN used
in the batch process mode. As an example, the mapping routines set
up scale factors for converting the user's coordinate system to the
CDC 280 coordinate system and to draw grids. The call,
MAPG(XMIN,XMAX,YMIN,YMAX,XMI,XMA,YMI,YMA)
establishes a mapping, draws a grid system, and marks the (X) and (Y)
axes with scale numbers. In this call the first four arguments
establish the minimum and maximum user coordinates. The last four
arguments are the minimum and maximum coordinates desired in the CDC
280 plane. Some other mapping calls are: MAPGLL, which establishes
a log-log mapping, MAPGSL, which establishes a semi-log mapping with
a linear (X) axis and, MAPGLS, which establishes a semi-log mapping
with a linear (Y) axis.
The interactive system is called by the subroutine,
INITIA(TEXT)
where TEXT is an array of up to 162 words which contain the display
code text to be displayed on the CDC 282 console. A basic call in the
interactive mode is,
IAM(MESSAGE,PLOTCOD,NP,RESULTS,TYPE,BUFFER,SIZE)

where MESSAGE is a message, 60 characters or less, that will be

displayed on the screen in the message area. The other arguments are
data necessary for the display.
The CDC 282 screen is a 19 inch cathode ray tube with an 11.5
inch by 11.5 inch usable raster area. This usable area is divided
into a set of 1024 raster points in each direction. The (Y) or vertical
direction is reduced by 54 raster points at the bottom. This area is
devoted to messages. Thus, the working display area is 969 by 1024
raster points.
The message area consists of four parts, and ;s 54 by 1024 raster
points. It is used as follows:

User Messages Central Processor Messages

Keyboard Messages Peripheral Processor Messages

Both the user and keyboard messages permit 60 characters. The Central
Processor (CP) and Peripheral Processor (pp) messages each permit 24

349
characters. As far as the user is concerned, the CP and PP messages
are system diagnostics. The user messages are programmed as part of
the application program. They are used to direct the calculation.
The keyboard messages are programmed entries and are input by the user.
As a matter of convention for this paper, the user messages will
be shown in ITALICS. The keyboard messages will be shown in MANIFOLD
type. Decimal data will be designated by (V.V) while integer data will
be designated as (N).
The CUG system permits the user to call for a microfilm image of
the current display. This is accomplished by use of the interrupt
feature in the system. The same interrupt feature permits the sup-
pression of printed output and the recording of the print file on micro-
film.
Recent activities concerned with the CUG system have been directed
toward the development of a compatibility package between various
graphics devices and the CDC 6000 series machines. At this time, the
CUG system is compatible with the CDC 250/252 and the CDC 274 systems.
That is, an application program and the CUG drivers can be used
alternately on any of the three interactive graphics display systems
without change.

Languages
A user oriented interactive graphics application system should have
three major attributes:
1) The system must make efficient use of machine resources.
2) The system must be relatively easy to program and its documen-
tation readily intelligible.
3) The system must be easy to use in the mode for which it is
designed.
Given the present state of programming technology, the use of CUG
in a FORTRAN mode tends to satisfy these requirements. The relative
efficiencies of the assembly languages are more than offset by the
ease and general knowledge of the procedure-oriented languages such as
FORTRAN. The use of higher order language executives such as ICES
(Roos, 1966) are not suitable from these accounts. First, these
higher order executives invariably degrade the machine operation beyond
tolerable limits. In addition, their use requires knowledge of machine
organization which is beyond that of the usual applications programmer.
The availability of a message-response mode in CUG permits the develop-
ment of a command structured language without overly degrading the in-
formation processing capabilities of the operating system.
Systems such as ICES have, as one of their stated objectives, an

350
inherent capability of integrating various civil engineering application
sUbsystems. Their purpose is to provide a single civil engineering
package which crosses disciplines, such as highways, structures, soil
engineering, etc. The philosophical differences between these disciplines
is so great that it is questionable whether this form of integration is
possible or even desirable. Integration of computed results on a
problem by problem basis is, however, certainly desirable. This can be
accomplished within the CUG system by using its ability to create files
and call control cards from the console.
Problem-oriented languages in the batch mode (Jordan and Schiffman,
1967) tend to be quite sophisticated, a quality necessary because of
the lack of interactive capabilities. In an interactive system, however,
and especially in an interactive graphics system, a complex command
structuring is neither necessary nor desirable. The psychology of the
user at an interactive graphics console and the physical environment is
such that the choice of commands which are directly input should be
limited to less than about twenty key words. Beyond this, the user's
program is directed by a message-response sequence.
The interactive programs described here use a command block
heuristic language system with default options. Each program is divided
into a number of functions which are called by key words, each with
generic meaning as to the soil engineering or the computational function.
For example, the command PROFILE calls a function which defines the
soil profile. Once a function is called, the program proceeds heuristi-
cally in a message-response mode. The heuristic string may be broken
by default entries which can be used to exit a function or to change
data already entered within a function.
The application systems, RING and ELASTING, operate exclusively in
the manner described above. All the data for these systems are input
from the keyboard.
FEMALE operates substantially as described above, with one modifi-
cation. Because of the large volume of data often required for slope
stability analyses, there is an option in FEMALE to enter the data
either by card or from the keyboard. If data are entered by cards
the program permits the data to be edited either line-by-line or by
records. This relieves the user of the tedious job of typing a large
volume of data.

SOIL ENGINEERING INTERACTIVE GRAPHICS SYSTEMS

The three soil engineering interactive graphics systems illustrated

below are each designed to develop an analysis of a defined subset of
soil engineering. RING is designed to analyze the progress of settle-
ment of a structure. ELASTING is designed to calculate the stresses
and displacements in a lyaered elastic soil profile due to an arbitrary

351
surface load. FEMALE is designed to analyze the stability of earth
structures.
Each of these application systems is fundamentally designed for
conventional stand alone use. They are, however, capable of integration.
In this latter mode, data from one system can be dumped to a file and
held until another system is called via the control card calls from
the console. All systems residing in Central Memory have full access
to the files developed by the current and all previous residents of
Central Memory.
The requirement that the systems be uniquely resident in Central
Memory is a function only of the capacity of the machine. The CDC
6400 used in this work has 64K of Central Memory and l25K of ECS.
As such, only one interactive system could be resident in Central
Memory at a time. With a larger Central Memory, two or more interactive
systems could be CM resident.

The Progress of Settlement

.
RING-I is a system for analyzing the progress of settlement of
foundations. This system is based upon one-dimensional consolidation
theory (Terzaghi, 1923; Terzaghi and Frohlich, 1936). The actual
calculations are performed by a finite difference using a Crank-
Nicholson (Crank and Nicholson, 1947) method. The interactive graphics
system uses the algorithms developed for PROGRS (PRogr~ss Of GRound
~ettlement) a batch process system (Schiffman and-Stein, 1969~

There are a total of twelve functions to RING-I:

1) PROFILE - The function which defines the soil profile.
2) BOUNDARY - The function which defines the boundary conditions.
3) HISTORY - The function which defines the load history.
4) INITIAL - The function which defines the initial excess
pore pressure.
5) RESIDUAL - The function which defines the residual excess
pore pressure.
6) ALGORITHM - The function which defines a special fast
algorithm for this system.
7) START - The function which defines the starting time.
8) ISOCHRONE - The function which calls for the calculation
and display of up to nine excess pore pressure
isochrones.
9) PROGRESS, - The function which calls for the
DEGREE calculation and display of the history
of the degree of consolidation for as
many as five separate problems.

352
 10) PROGRESS, SETTLEMENT - The function which calls for the
calculation and display of the settle-
ment history for as many as five separate
problems.
11) PROGRESS,UAV - The function which calls for the
calculation and display of as many as
five average excess pore pressure
histories.
12) PROGRESS, PRESSURE The function which calls for the
calculation and display of up to five
excess pore pressure histories.
As an example, consider the message response sequence to display
a set of excess pore pressure isochrones for a six layer soil profile.
The functions, PROFILE, BOUNDARY, and HISTORY have already provided the
basic input data required to solve this consolidation problem (specified
as Problem 1). The screen message is,
ENTER -- FUNCTION

The message-response system follows as,

ISOCHRONE

ENTER PROBLEM NUMBER

ENTER -- NUMBER OF ISOCHRONES

4

ENTER -- 4 TIME VALUES

1.7E3,b.3E3,1.5E4,3.5E4

The display which follows is the excess pore pressure isochrone display
shown in Figure 1. The message,
IS SCALED PLOT DESIRED

permits a windowing procedure. A,

NO
response produces the message,
ENTER -- NUMBER OF ISOCHRONES
o

353
 PRO£UH N..t&R 1
EXCESS PORE PRfSStR£ lSOC~
I.T· 1.7"[+15 U •• 25

2. T • '.SlI£+'5 U •• 51

5. T • I.SOI£+'. U •• 75 te.
~:- I

•• T • 5.511£+'. U •• 85
Ie•
Z4.

ze. II
51
/
/ 1
; J L
~ :.;: L
1.
I ./ L
:::~: / ./ /
i.~- ., /
/' L
..., I L L
/ V
......
51
, I / /'
/ V L
~

..,
lUI
1/ L ~

-
u /' V-
I:, ." / ./ b---:':
/:!Ii / /____
' i"'" ~
, 0:, 1L
~
-
i
co:

EXCESS PORE PR£.SS\R:

Figure 1
EXCESS PORE PRESSURE ISOCHRONE DISPLAY
This response exits this function and triggers the message,

ENTER -- FUNCTION

As another example, consider the comparison of the degree of con-

solidation for a series of impeded boundary conditions. The data for
five problems have been input and the user message is,

ENTER -- FUNCTION

The message response sequence is,

354
 PROGRESS, DEGREE

ENTER -- NUMBER OF PROGRESS OF CONSOLIDATION CURVES

5

ENTER 1 -- PROBLEM~TERMINATION CODE~TERMINATION

1,DEGREE,.99

A progress of consolidation display will appear showing the plot for

Problem 1.

ENTER 2 -- PROBLEM~ TERMINATION CODE ~ TERMINATION

2,DEGREE,.99

The display will show Problems 1 and 2.

ENTER :3 -- PROBLEM~TERMINATION CODE~TERMINATION

3,DEGREE,.99

The display will show Problems 1, 2, and 3.

ENTER 4 -- PROBLEM~TERMINATION CODE~TERMINATION

4,DEGREE,.99

The display will show Problems 1 through 4.

ENTER 5 -- PROBLEM~TERMINATION CODE~TERMINATION

5,DEGREE,.99

The display, as shown in Figure 2, will contain the progress of

consolidation plots for all five problems.

IS SCALED PLOT DESIRED

NO.

355
 PROGRESS OF CONSOLIDATION
o.

i
t• , - t
t--::t----.
F::t-.... I:
r-t-

III
'"
..... r-.
""
~t"I
I •, - 2

I ij
~
r-. •, - J

"~~
8."4[-1 2
'\ ! 1]
~ 4• , - 4

r\, I 1
'II' '
~ I i i ; 5• , - 5
"- Ii: iii

\
1.887£-0 I
" I
i j:
r 1 :"

" I Ii i:
! i i

2.885£-0 I
I~
1\ I I !i ' "
!I I
"
,;!
i
, i

1\ ~Il
i 1;.
~
j :
I !i
1\ I I
' I';:
i ! i I;

\ \i ~i !'I ~I
I

,I
~ I
I 1 :
I I
! !;:
,I
I I i
I
, I
I I
i l ,: '

II
\J Ill!: I:
I
i I ; ; I;

~
I

~ !!
I I I i 1i ! '
\ \! i i
i I
'\
: I!:,:
I
;I i" ~:;; i
..
I I, II
'

~ ! 1 j : ; i ::.
~ 'I i
I

I I~I 1 ;
t i
j i : ; i:
I I ' I'
i
1\
, 1\
I

;
7.887£-01

\1 ~I !I I I : ' ,; i

11\ I i d; '::
i~ \: : ; I,

, : l

!m
'.885[-01

~ I, L'ii
-""
I I I i
-
i
8.884£-01 II)

i• i i.
T!:i: (Tl
-
"':

Figure 2
PROGRESS OF CONSOLIDATION DISPLAY

ENTER -- FUNCTION

Stresses in Layered Systems

ELASTING-O is a system for the analysis of stresses and dis-
placements in layered elastic systems. This system is based on the
analysis of an n-layer elastic system (Schiffman, 1962; Michelow, 1963).
For a specified soil profile and surface loading, the ELASTING
system is capable of producing profiles of the stresses and displace-
ments along a given line. In addition, it can produce the state of

356
stress at any point at any orientation.
The command structuring of ELASTING is identical, in principle,
to RING with a series of function entries, each one containing a
heuristic string.
Figure 3 presents the vertical stress display for a circular load
applied to the surface of a four layer system.

VERT 1CAL STRESS (SZZ) VS. DEPTH (Z)

5lZ
... ...
j ~

..
J:
I. _ . . . . .
, ~ ,

1.50".00
\
~
'.00"."
I'-... r-..
c.,.O[ •• o
...........
~
' ••• 0[.00

7.50".00
~
r---..
.... 0[.00 "-
•• 05'[.0' ~
I.lO"." '\
I\.
z
" \
\
1.100[."

1\
\
2.250[00'
\

• \
•
•
1\
• \
\
•

Figure 3
VERTICAL STRESS DISPLAY

357
 RADIAL STRESS (SRR) VS. DEPTH (Z)
SRR
<>
•
<>
<>
•
<>
<>
•
<>
<>
•
<>
<>
• <>•
<>
<> <; <; <;
.
<>
<>
<>
...;;;•
<>
.
<>

..
<>

... . ..
I
I" ~ II! \!I
r ,.~ rn~ ~ ~<> ';J I" II!

-r-r-
11\
,N ~
<>
.,; '" 11\
,,;
~
a.
~
'"
,,;
CD
,,;
'. I I . 0.00 O.
I I I I I I
CD
I
'"
!--
r-- ~
r-- b-
5.000hOO
r- t--r--...,
i""'-
1"'---1'--
............
l"- I'--

'.lOOhO'

z , .500[+01

I.i50[.Ol
}

1.'00[+01

I.II!IO[.Ol
II
l.IOO[+Ol

2.250[+01 1
2.400[+01

2.550[.01

l. ~OO[.O ,
2.'50[.0 ,
'.000[.0 ,
Figure 4
RADIAL STRESS DISPLAY

Figure 4 presents the radial stress display for this four layer
system.
Figure 5 presents the display of the vertical displacement at
the surface of this four layer system.
Figure 6 presents an example of the display of a stress element at
a given orientation.

358
 VERTICAL DISPLACEMENT (UZ) VS. RADIAL DISTANCE (R)

t. l . 0.00 t'.5

n.o
t2.5 r-- ~-
- i'---- r---.,
t2.0
~['-.,
~
tt.O ~
to.5
~
to.O l~
~.5 ~
\
~. 0

8.5 \
\
8. 0

5 li
\
0

6. 5 li
6. 0 l'\
5. 5 ~

5. 0
"I'"
c. 5 ~

[ -I.
0
~_
o
~ 0 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ I! ~ ~ ~•
WI
R

Figure 5
VERTICAL DISPLACEMENT DISPLAY

The user can alter the angle of orientation of the stress element
by successively typing angles. Thus, the state of stress at any and
all orientations can be determined at a single sitting at the console.

Slope Stabil i ty
FEMALE-I is an interactive graphics system based upon a batch
process program developed by the U. S. Bureau of Reclamation (Esmiol
and Nelson, 1963). This program calculates the stability of earth and

359
 STRESS STATE AT N = 45.0 DEGREES

, 3.0, 11.0)

« spw· "'111[.00

,/ ~SPP -'.'~C[.oo
•

Figure 6
STRESS ELEMENT DISPLAY

rock slopes using the Fellenius - May method of analysis (Fellenius,

1936; May and Brahtz, 1936).
Due to the large amount of data required for this analysis, the
operation of FEMALE is somewhat different than the operation of RING
or ELASTING. In this system it is assumed that an initial data file
will be input on cards. Thus, there is an alternative of card reader
or graphics console control of the data input. Even if the data are

360
input by cards, the user has the option of seeing all the input data
as card images on the screen. Figure 7 is a typical example of a data
record display where the data have been read in on cards.

ft. MATERIAL CCf11At{lS ft.

1.EI'SANai:NT MATERIAL ORYWT1 - 100.3 PCF • SGt - 2.705 • WC1 - 5. •

2.EI'SANai:NT MATERIAL ORYW2· 105.9 per • SPECIFlCGRAVlTY2 • 2.68 • w:2 - 16.7 •

3.F H 01 • 100.3 PCF • SG1 • 2.705 • WCt • 5 ••

4.F H 02· 100.3 PCF • SG2· 2.705 • WC2· 5 ••

ft. 00 RECORD ft.

Figure 7
CARD IMAGE DISPLAY

Once the data have been read in, the user can display the geometry
of the earth structure and a tabulation of the data. The user, at any
point, can edit the input data even if they are read in on cards. The
editing function permits the editing of a line, the replacement of a
line or record and the addition or the deletion of data.
In the course of data input, either from the card reader or the
console, the initial failure surface and a search technique is input.
On this basis, a search is made for the minimum factor of safety and
the results are displayed as shown in Figure 8. It is noted that by
use of the CP clock the search is displayed dynamically so that the
user can see the search progressing.

At the end of a given search, the user has the option of editing
any or all of the data base of the problem and determining a new
factor of safety. This process can be continued indefinitely until
the user is satisfied with the analysis. At this terminal point,
the card reader can be given control and a new problem can be read in.
Thus, the user can perform interactive design on a number of problems
at a single sitting.

CONCLUSIONS
To date, the use of the CUG system to provide the capability of
interactive design for soil engineering has been shown to be efficient

361
 Sl..OPE GEctETRY
WITH FAILURE SURFACE
SAFETY FACTOR· 1.84792

2482.561

CI , 4".00,1"1.50)
RI· 120.00
C5 , 525.00,1811.50)
R5. liO.SO
2254.785

2175.557

2086.210

2017.024

1857.761

1151.512 f..:::::==--~~-------~"':::====t;;t=~-"'::::::::::.....-

1778.256

.. ..
1700.000 ' - - - - - -_ _ _ _ _ _ _ _ _._ _ _ _ _ __
• ..'"
.. • fl
N ",
g
0
~
iii I! ~
N ell

.
0 N
II! r- ",
,.: .;
Ii ",
N
r-
Wi :i
",
~
m ~
",
;; IX
r-

Figure 8
SLOPE STABILITY DISPLAY

and viable. It has several advantages over conventional methods of

computer use. First of all ~ it is more efficient in terms of design
turn-around time. The engineer can perform one or more complete
designs at a single sitting at the interactive console, compared to
the days and weeks spent in running and analyzing batch process pro-
grams. This efficiency of operation extends also to cost. By using
the interactive mode, the iterative process of analysis and design is

362
accelerated. Thus, the actual computation costs are substantially
less in the interactive mode than in a comparable batch process operation.
A third efficiency is the use of microfilm as a hard copy device.
Microfilm can, of course, effect a large saving in storage space com-
pared to conventional print output. Furthermore, the quality of the
microfilm, as shown by the figures presented in this paper, is suitable
for professional use.
There is a deficiency in the data input used with interactive
graphics. This is most evident in FEMALE where a large amount of
geometric data must be input by cards or keyboard. Use of the light
pen would provide partial relief to this awkwardness. A light pen,
however, may not be well adapted to providing the geometric detail
required to define an earth structure. On the other hand, the use of
a pattern recognition device to trace the geometry would be of major
assistance in the development of a simplified input scheme.
The examples given above were exclusively concerned with analysis
and design. Another major soil engineering function convers the
analysis of laboratory tests and field monitoring. In this application,
interactive computer graphics is used in conjunction with real-time
control systems.

ACKNOWLEDGEMENTS

The work for this study was supported in part by BUILD (a joint
program between the University of Colorado and the University of
Illinois), the Control Data Corporation under a grant for research
in computer graphics at the University of Colorado, the National
Science Foundation under grant GK-1287 with the University of Illinois
at Chicago Circle, and Contract 14-06-0-6762 between the U. S. Bureau
of Reclamation and the Computing Center of the University of Colorado.
Acknowledgement is made to Messrs. E. W. Klapahake and R. N.
Lachenmaier who assisted in the programming of the systems described
in this paper.

REFERENCES

Backus, J. W., et al, (1957), "The FORTRAN Automatic Coding System,"

Proceedings, Western Joint Computer Conference, 11, pp 188-198.
Bailey, A., and Christian, J. T., (1969), "ICES LEASE-I, A Problem
Oriented Language for Slope Stability Analysis, User1s Manual,"
Massachusetts Institute of Technology, Department of Civil

363
 Engineering, Research Report R69-22, Soil Mechanics Publication
No. 235.
Crank, J., and Nicholson, P., (1947), IIA Practical Method for Numerical
Evaluation and Solutions of Partial Differential Equations of
the Heat-Conduction Type,1I Proceedings, Cambridge Philosophical
Society, 43, pp. 50-67.
Dohrmann, R. C., (1969), IIProgram No. J5-CU-PLT280, CDCj280j282,
Interactive Graphics and Microfilm System,1I University of
Colorado, Computing Center, Report No. 69-6.
Esmiol, A. E., and Nelson, C. A., (1963), IIElectronic Computer
Evaluation of Earth Dam Stability,1I U. S. Bureau of Reclamation
Report.
Feeser, L. J., and Cutrell, J. D., (1970), IIPerspective Views and
Computer Animation in Highway Engineering, Computer Graphics
70, Brunel University, Uxbridge, Middlesex, England, (See chapter
in this volume)

Fenves, S. J., Logcher, R. D., Mauch, S. P., (1965), Stress: A

Reference Manual, The M.I.T. Press, Cambridge, Massachusetts.
Fellenius, W., (1936), IICalculation of the Stability of Earth Dams,1I
Proceedings, Second Congress on Large Dams, pp. 445-462.
Jordan, J. C., and Schiffman, R. L., (1967), IIICES SEPOL-I, A
Settlement Problem Oriented Language, User's Manual ,II
Massachusetts Institute of Technology, Department of Civil
Engineering, Research Report R~7-6l, Soils Publication No. 204.
May, D. R., and Brahtz, J. H. A., (1936), IIProposed Methods of
Calculating the Stability of Earth Dams,1I Proceedings, Second
Congress on Large Dams, pp. 539-574.
Miche10w, J., (1963), IIAnalysis of Stresses and Displacements in an
n-Layered Elastic System Under a Load Uniformly Distributed on
a Circular Area,1I California Research Corporation.
Mi 11 er, C. L., (1961), IICOGO - A Ci vi 1 Engi neeri ng Problem Ori ented
Language,1I Massachusetts Institute of Technology, Department of
Civil Engineering, Research Report.
Naur, P., (ed), (1963), IIRevised Report on The Algorithmic Language,
ALGOL 60, II The cOl11T1uni ca ti ons of the ACM, .§..' No.1, pp. 1-17.
Roos, D., (1966), ICES System Design, The M.I.T. Press, Cambridge,
Massachusetts.
Schiffman, R. L., (1957), liThe Numerical Solution for Stresses and

364
 Displacements in a Three-Layer Soil System,1I Proceedings,
Fourth International Conference on Soil Mechanics and
.
Foundation Engineering, -2, pp. 169-173.
Schiffman, R. L., (1962), IIGenera1 Analysis of Stresses and Displace-
ments in Layered Elastic Systems;' Proceedings, International
Conference on the Structural Design of Asphalt Pavements,
pp. 365-375.
Schiffman, R. L., and Stein, J. R., (1969), IIPROGRS-!, A Computer
Program to Calculate the Progress of Ground Settlement,1I
University of Colorado, Computing Center, Report No. 69-9.
Schiffman, R. L., Whitman, R. V., and Jordan, J. C., (1970),
IISett1ement Problem Oriented Computer Language,1I Journal of
the Soil Mechanics and Foundations Division, ASCE, (In Press).
Smith, E. A., (1951), IIPile Driving Impact,1I Proceedings, Industrial
Computation Seminar, September, 1950, International Business
Machine Corporation, New York, New York, pp. 44-51.
Terzaghi, K., (1923), IIDie Berechnung der Durchlassigkeitsziffer des
Tones aus dem Verlauf der Hydrodynamischen Spannungerscheinungen,1I
Akademie der Wissenschaften in Wein. Sitzungsberichte, Mathematisch-
Naturwissenschaftliche K1asse, Part IIa, 132, No. 3/4, pp. 125-138.
Terzaghi, K., (1936), IIRelation Between Soil Mechanics and Foundation
Engineering,1I Proceedings, First International Conference on
Soil Mechanics and Foundation Engineering, 1, pp. 13-18.
Terzaghi, K., and Frohlich, O. K., (1936), Theorie de Setzung
Von Tonschiten, F. Deuticke, Leipzig.

365
STRUCTURAL DESIGN USING INTERACTIVE
GRAPHICS

A. G. Young
University of Leicester, Department of Engineering,
The University, Leicester LEI 7RH, England.

Introduction Full use of the computer's capacity to store large

quantities of information and process it according to the user's
instructions cannot be made by the designer until means of communication
exist which enable him to both address the computer and obtain a reply
rapidly and in terms which are natural and convenient to him. The
prospect of a major advance on this front is. offered by the graphical
display unit linked to a time-sharing computer installation. An
investigation of the potentialities of such an arrangement in the field
of structural design has been undertaken by a group within the Department
of Engineering at Leicester University with the support of the Science
Research Council. One outcome of this work has been the system of
programs called LUISA l the object of which is to provide the user,
operating at an interactive graphics terminal, with the means he requires
to design a structure. The finite element method forms the basis of the
analysis routines used in LUISA.

This paper states the requirements of an interactive structural

design system and puts forward the advantages of the finite element method
in this context. A description of LUISA and its application to a problem
in foundation design follows.

System Requirements
The designer at his terminal wants to be able to simply and
directly generate a model of his structure in the computer store which he
can analyse <either wholly or in part), interrogate, change, add to or
delete at will, the problem remaining throughout within the confines of
the computer system. There should be as little restriction as possible
on the type and configuration of structure which he can tackle. Different
levels of sophistication in analysis should be available for use at
different stages in the design.

The system must therefore contain a wide selection of procedures

367
and provide a mechanism whereby the user can specify,on-line,the data and
the operations he wishes to be performed on it. It should arrange the
storage of information in the way it can most readily be accessed for the
purpose it is intended; additions and modifications to the information
should be easily accomplished.

The system itself should be capable of change, in particular to

incorporate new or improved procedures as they are developed.

Finite Element Method

In the finite element method the structure is represented by a

model made up of basic elements of known characteristics which are
interconnected at specific points on the element boundaries generally
referred to as "nodes". Two alternative approaches are possible - the
displacement method, where displacements are taken as the primary
unknowns, and the force method, where forces are the primary unknowns.
The decision as to which of these to use is to some extent influenced by
the problem but in the majority of cases the displacement method is
adopted, mainly because of the greater simplieity of the mathematical
operations involved.

Discussion in this section is confined to the displacement method;

the force method follows similar but complementary lines.

With the displacement approach, the individual element 1

characteristics are derived assuming a relatively simple displacement

field over the element defined in terms of the degrees of freedom,
i.e. sets of independent displacement parameters, at the nodes. The
displacement field defines the strains within the element which in turn,
gi ven the stress/strain relation for the material, define the sitresses.
It is then possible, by applying the principle of minimum potential energy
(or an equivalent principle) to obtain the best set of nodal forces to
maintain equilibrium for the chosen set of displacement parameters. The
nodal force/displacement relations may be written as a matrix of stiffness
coefficients and are completely specified by the element geometry and
material properties.

The requirement of continuity of displacements between adjacent

elements at common nodes enables a complete set of stiffness coefficients
to be assembled for the entire structure. The specification of boundary
conditions, i.e. the values of the forces (or displacements) imposed at
the nodes, will then yield a set of simultaneous equations which can be
solved by computer to give the displacements and hence the stresses
throughout the structure.

Providing the elemental displacement fields are chosen so that

compatibility between elements is maintained across common boundaries,
the above approach ensures that for the permitted degrees of freedom
the best solution to the problem is obtained. In general, insufficient

368
degrees of freedom to fully represent the true situation will be employed
However, as more degrees of freedom are given their independence, by
incorporating either more nodes or more displacement parameters at the
nodes, the true solution will be consistently approached. Moreover, a
guide to the nature of the approximate results is provided. For instance
the displacement approach generally results in an underestimate of the
true deflected shape of a structure. An example occurs in simple bending
theory where the assumption that plane sections remain plane implies the
neglect of shear deformation and consequently leads to an underestimate
of the true deflection.

The particular advantages of the finite element method in the

context of the system requirements can therefore be summarised in the
following way:
1) It provides the ability to build up a structure of arbitrary
configuration from parts with known characteristics; this
ability is limited only by the element types available.
2) It allows a systematic refinement of the model of the structure
to be made as the design proceeds.

The advantages are not all one way. A major obstacle to the use
of the finite element method is the tremendous amount of data preparation
required for all but the most elementary problems. The data to be input
includes:
- the co-ordinates of all nodes and their relation
one to another
- a description of the elements, e.g. type ,geometry,
material properties
- the applied loading and constraints
This work is both time-consuming and tedious; consequently it is
expensive and gives rise to errors which are difficult to find. It
cannot be fully automated since human judgement is essential in the
setting up and subsequent modification of the mathematical model to ensur
that the true situation is adequately described. An interactive system
equipped with a graphical display unit supplies the means to eliminate
most of the human effort associated with this phase and yet retain the
power to control the process in the hands of the designer. The display
of the structure on the screen offers a direct means to detect errors
in input.

The LUISA System

The development of this system could be regarded as part of a
feasibility study into ways and means of satisfying the designer's needs
listed under "System Requirements".It has been designed to provide the
generality and flexibility required of an interactive system and to
permit the growth needed for it to evolve. This has been accomplished
by writing the programs in modular form and by arranging the data to
be stored in individual blocks linked together by chains of pointers.
This ring-type structuring of the data is important in speeding up the

369
process of accessing information and in easing problems of modification
and extension.

LUISA therefore contains a large number of independent program

modules, each performing a unit operation in the problem area. The
mechanism which the designer needs to order and control these operations
is provided by a package of routines called "the interaction processor"~
This enables the user to construct his personal set of instructions to
the machine. He accomplishes this by making selections, using the
light pen, from menus of options which are presented successively on
the screen. The options are displayed as words which can be identified
by a light pen Il see". By following through the menus, which are
arranged in a logical hierarchical order, making his selections, the
user prepares a command which consists of a string of words corresponding
to a sentence in English. For example, the command
"HOVE ELEHNT BDY 75 MOVEX NOT MVY TO CROS"
means "move the element, which has the boundary identifiedt , in the
x-direction only,to the position of the tracking cross". When the
command is complete the user can cause it to be executed by pointing
with the light pen to the word "EXECUTE" on the screen. The main
program of the processor provides the link between the unit operations
and it has been written in such a way that new options can be readily
co-opted as they become available. In addition, it arranges for the
display of messages to either inform or tutor the user. An up-to-date
record of computer-time spent by the user is also displayed. It is
hoped that the latter will help the designer to develop a feel for the
costs incurred by different sets of operations.

Also incorporated within the interaction processor are a number

of control devices which assist in the specification of program
variables such as values, scales, orientations, co-ordinates, from the
screen. One of these, termed a "quadrilateral", establishes whether an
item is within a quadrilateral drawn on the screen. This has proved
valuable in selecting nodes on which the user wants to operate.

A schematic of the data structure chosen for the storage of a

model of a triangular structural element is shown in Fig. 1. The main
element block or bead, as it is generally called, contains basic
information about the element, e.g. its mechanical properties, the total
number of nodes belonging to it, the degrees of freedom (or redundancy)
it is given. It also contains registers in which are stored pointers
to other blocks, notably boundary and node beads, making up the model.
A pointer supplies the location of the first word in the bead it refers
to; in this way pointers can be used to interconnect beads. For instance
in Fig. 1 there is one pointer chain connecting all element boundaries
together and another connecting all the nodes. Pointers providing

t normally by the light pen

370
associations between boundaries and nodes and between nodes and the
parent element are also shown. These associations supply amongst others
the means by which an element can be identified by a light pen "see"
on one of its boundaries. The format of a bead is pre-defined, and for
anyone type the components are arranged in a common order relative to
the first word. It will be seen that this considerably facilitates the
accessing of components of the same type. The pointers shown at the
foot of the element bead in Fig. I are used simply as links to arrays
of additional data which it is convenient to store in separate beads.

Program modules are available which enable the user to generate

copies of the elements, including their data structure, and join them
together at nodes to build up the configuration he demands. The form
of the data structure for individual elements and for assemblages of
elements is similar and this allows the various algorithms which process
the information to be used regardless of the complexity of the
configuration they are operating on. The data structure has also been
designed to cater for different types of element with different degrees
of freedom. At the present time, however, only the "constant strain"
triangular element is implemented; it is intended to add quadrilateral,
beam, plate and shell elements to the system after the computer
installation at Leicester University is upgraded and rapid access backing
store becomes available. This is expected to be in April 1970. The use
of the program modules which perform the analytical operations on the
data structure is demonstrated in the next section.

The display unit at the University is an ICL 4280 linked to a

4130 computer which has 64K words of store. The LUISA programs are
written in Fortran IV but are not completely machine-independent as they
utilise several sub-programs provided by ICL.

Illustrative example
This section describes how the LUISA system may be used in a
design situation. The aim is to illustrate the scope of the operations
available to the user and to highlight some of the advantages offered
by interactive graphics. A comprehensive treatment of a problem is
not attempted.

The problem studied is the design of the base of a concrete tower

so that forces produced by a combination of dead load and wind load on
the tower are transmitted to the sub-soil without exceeding either
(a) the maximum bearing pressure the sub-soil can safely withstand
or (b) the permissible angle of tilt for the tower.
This problem is depicted in Fig. 2. No constraints other than those
imposed by construction requirements apply. Criteria to be used in
measuring the effectiveness of the design include degree of reliability
of completed structure, ease of construction and cost. Costs of design
and computer time will have to be considered in the final reckoning.

371
 r_!ler!le!}trj~g-1

---V /'
I , ELEMENT
---Lr
i /' r----------/---
beadl~
I ...---4 _____ _ _ ;;...... LI

----------
I
I
I
---')
I
I I
I I
I
I I
components r----T-------
I I
I I
I I
I I
l ____ l ,..
...- - -.._--.... ,'-----------r"/' -
--, "
...---of " , \
- .... ,'
..... , \
\
\
\
~

..... , ' " , I

\. __________ e.0inters_to____ ~--- _____ _
additional I
data \. _________ _

FIG.1. DIAGRAM OF DATA

A heuristic approach is adopted. That is to say, a trial design

is proposed and examined in order to develop an understanding of the
problem. The model used is shown in Fig. 3. The choice has been governed
by the need at this stage in design to represent the real situation with
the minimum of complexity. The problem has therefore been reduced to one
of plane strain, viz. a unit width of slab supported on an elastic
foundation. Reinforced concrete has been chosen as the most suitable
material for the slab.
The model was generated from the display console using the
interactive facilities offered by the system. The procedure is first to

372
 BOUNDARIES

boundary ring
--- - - - ---------- -- - --I
...
I
.....-
-----~
I
-- -- ----" "
1 -- --------, :~------,
I
I-

I I I :
I I I I I
I I I I I

·r---- ---t-- - - - - II- - - - -

I I I I
---t- - - ___ J
I I I I
I I I I
I I I I
I I I I
I I I I
,------- -?- \._-------~
----- -----/ ---------,.",. " -
I
I
.") ~
JI I-
I I
I I
I I : I
I
....JI __ _ _______~--.l---- _________ ) !
____ ~ ___________________ J
node ring
NODES
STRUCTURE FOR TRIANGULAR ELEMENT

make a copy of the basic element, a plane trianglet,using a set of options

headed by COpy and then join the two together along selected boundaries
using another set headed COMPOS. Continuing in this fashion, alternately
copying elements or groups of elements and joining them together the
requisite number of elements is quickly assembled. Few elements are used
in this instance as only a coarse representation is wanted. Positioning
of the nodes to obtain the requisite shape and internal arrangement is
effected using MOVE, the nodes to be moved being selected by the tracking
cross or the quadrilateral device and their new co-ordinates specified
either by means of the tracking cross or by using one of the control

t
Beam or plate elements would have been preferred for the slab
if they had been available

373
 Con crete tower
- modulus Ec

Resultant
wind load

Dead load

FIG.2.
""
MAIN FEATURES OF PROBLEM
Sub - grade
- modulus E c / 10

r-l
I
I
I
I
I Tower
I~
I mposed loads I
I

~: Concrete slab

~~~~~~t~~~~Ec
Ground level
W!&ffm
Spring sub- grade
E c/ 10

FIG.3. RUDIMENTARY MODEL OF TOWER BASE

374
devices if a more precise specification is required. A single row of
"constant strain" elements has been used to represent the foundation;
with the horizontal forces at the nodes set to zero this will simulate
a simple spring support. The relevant elastic moduli are entered using
an option headed SETPTS which enables these values to be set in the
correct place in the data structure.
An analysis of the response of the structure to applied load is
now wanted. This requires the following sequence of operations ( l)and 2)
are performed using a set of options headed ASEMBL).
1) A new data structure for the model is set up which consists of a
super-element bead with nodes (duplicates eliminated) and boundaries
linked in a similar manner to that shown in Fig. 1. Up to this point
the data structure consisted of individual element beads with their
nodes and boundaries plus pointers linking the connected boundaries.
The transformation to a higher-level element ensures the consistency
of data structure needed to facilitate further operations. The
linked element structure is stored to enable a return to the
lower-level basic elements when required. Concurrently, a connection
list is produced which relates the individual element nodes to their
counterpart in the super-element structure.
2) The stiffness matrix for the super-element is formed. This is
accomplished in two stages. First, using the sub-routine supplied
for the particular element type, the stiffness matrices for the basic
elements are calculated and the values put in application data
vectors pointed to from the individual element beads as indicated in
Fig. 1. These values, together with the connection list referred to
above, are then used to assemble a stiffness matrix for the super-
element. This is stored in a corresponding application data vector
in the data structure for the super-element. All stiffness matrices
are expressed at present in terms of absolute screen co-ordinates.
3) The boundary conditions are specified using SETPTS. This
option enables values of forces or displacements at nodes to be set
in parameter vectors pointed to from the main element bead. The
nodes are selected, as before, using either the tracking cross or the
quadrilateral device, and the values supplied either by means of one
of the display control devices (a digit-changer) or via the keyboard.
For each degree of freedom possessed by the structure, the value of
either a force or a displacement parameter must be specified before
a solution is possible. For the model of Fig. 3, the requirements
for the bottom row of nodes of the "spring" elements is that both
vertical and horizontal displacements are zero whilst for the top row
of the springs the vertical displacements and horizontal forces are
zero. Elsewhere all forces are set to zero except at the two nodes
where the loads from the tower are deemed to apply.
4) Using the above information, a constrained form of stiffness
matrix for the super-element is obtained which, upon inversion, yields
the solution for the displacements at the nodes. Displacement profiles

375
 can be viewed using a set of options which offer alternative ways of
displaying the results and means by which the scale may be adjusted.
Fig. 4 illustrates a typical display.

Angle of tilt for tower

FIG. 4. DEFLECTED PROFILE OF SLAB TOP

5) It is possible, via a back-substitution matrix set up during the

assembly of the super-element, to calculate the stress in each basic
element from the values obtained for nodal displacement. These results
can also be presented graphically on the screen; the facility to
obtain a dynamic picture by rotating the stress profiles is provided.
This step may not be required if the most critical design criteria
is deflection as in (b) above.

In all probability, the results for the first attempt will be

unsatisfactory. In any event, it is important to investigate the
sensitivity of the results to variations in the main parameters. For
example it is unlikely that firm information on loading and sub-grade
properties will be available at the early stages of design. An alteration
in the applied load is the simplest modification to accommodate. This
requires a re-specification of force parameters in operation 3) followed
by operations 4) and 5) as before. A change in shape requires a
return to the level of the linked element structure, i.e. a return to
operation 1). A change in topology or element composition is
accomplished by re-defining the linked structure. Various options are
open to the designer in this case and the information displayed on the
costs of various operations should prove valuable in assisting him to
decide the best way to proceed.

When the approximate proportions of the base have been obtained

and a feel for the significant factors has been developed, the next stage
is to examine the design in more detail. This can be done either by
building up a more detailed model of the problem and analysing it or
by separating the structure into individual components and studying their
response to appropriate free body forces. The choice depends to some
extent on the problem and on the capacity of the computer. It is possible
to treat the present problem as an entity if it is assumed that the
stiffening of the base by the tmler is negligible. This effect could be
examined at a later stage if it were felt l.-Torthwhile. Suppose the

376
representation of the foundation is improved by the addition of further
elements using options COPY and COMPOS to give the model shown in Fig.S.

Ground level
~~
~sub-grade

FIG.5 IMPROVEDMODEL OF FOUNDATION

Operations 1) to 5) above may then be invoked to yield a better

description of the displacements and/or stresses in the structure (see
Fig. 6). The process can be repeated until the designer is satisfied
with the result. In practice his approval will depend upon the
effectiveness of the design measured against the chosen criteria as well
as on the adequacy of the final model. This will necessitate an
interrogation of the data to provide quantities of materials used~ etc.
The design of data structure and processing algorithm to facilitate
such an interrogation will be influenced by the costing system adopted
in the design office but it is a relatively straightforward task to
provide a materials listing with the present data structure.

Maxbearing
pressure

FIG.6. GRAPH OF BEARING PRESSURE AT INTERFACE

OBTAINED BY ROTATING PICTURE.

377
 The design now enters the detailing phase where individual
components, such as the base slab, are processed to supply the precise
information needed for construction purposes. A large portion of this
phase can be delegated completely to the computer and is not relevant
to this discussion. It is worth pointing out however, that the
introduction of the computer into the preliminary design phase means
that a major part of the input data needed for the detail design to be
carried out is already available in the computer store.

Further Remarks

The technique of sub-structuring is commonly used to bring large

problems within the capacity of the computer. This consists of dividing
a structure into parts or sub-structures and allowing certain of the
unknowns to be eliminated before proceeding with the solution. The
equivalent operation in the LUISA system is to specify certain of the
nodal parameters using SETPTS (i.e. operation 3) ) at an intermediate
stage before the super-elements are assembled into a complete structure.
This makes it possible to reduce the size of the effective stiffness
matrix for a super-element and, at the same time, retain the required
degree of refinement. The nodal parameters which can be eliminated in
this way are those for which the boundary conditions are independent of
the methods of assembly of the super-elements or the imposed loading.

Another technique which may reduce the demand on the computer

store is to store only the non-zero components of a matrix. A package
of routines which facilitates sparse matrix operations is incorporated
in the system.

A study of the problems involved in tackling three-dimensional

problems is also being made. 3

A feasibility study of an interactive system would not be complete

without some attempt at evaluating its use in a real design situation.
This is one of the aims of a workshop scheme organised at the University
of Leicester in which members of industry are using the Engineering
Department's computer-aided design facilities to tackle problems of
particular interest to their firms.

Acknowledgements

The LUISA system is largely the result of the efforts of

Dr. G.A. Butlin, Research Fellow in the Engineering Department of
Leicester University. Other notable contributors are Mr. R.J. Hubbold
and, more recently, Mrs. C. Grafton.

378
References

1. BUTLIN G.A., HUBBOLD R.J., A scheme for man-machine interactive

structural analysis, I.E.E. Conference Publication No. 51,
Southampton, April 1969.
2. BUTLIN G.A., A Fortran package for interactive graphics,
Computer Graphics 70 International Symposium, Brunel University,
April 1970. (See chapter in the volume)
3. HUBBOLD R.J., An interactive graphics program for three-
dimensional drawing, Computer Graphics 70 International
Symposium, Brunel University, April 1970. (See chapter in this volume)

379
COMPUTER REPRESENTATION, DISPLAY AND
INTERROGATION OF STRUCTURAL
BUILDING DATA

R. F. D. Porter Goff
University of Leicester, Department of Engineering,
The University, Leicester LEI 7RH, England.

SUMMARY

The paper describes the first phase of an investigation

into the computer-aided design of reinforced concrete
buildings. The objective is to explore the way in which
the geometrical data file might be defined and to suggest
means for handling the data, using computer display and
lightpen equipment. The facilities offered by an experi-
mental program are described. The design of the data
structure is related to what the data represents and how
it is used. A brief description of the stages in program
development is included: and an assessment is made of some
features that may be common to different CAD systems.

1. INTRODUCTION

Structural engineers have for some years been interested in

the use of computers to aid the design of reinforced concrete building
structures. One emphasis has been on reducing both the time and manual
effort involved in the detailed preparation of schedules and working
drawings rather than on carrying out sophisticated structural analyses.
For example, the KLP system (reference 1) completes the structural
design once the designer has drawn up his general arrangement framing
plans and typical sections through the building.

An assumption about the type of computer facility available

must precede any discussion of the point at which the computer may
usefully be introduced into the design process. The program described in
this paper was written for an ICL 1+130 (64K word) computer with 4280

381
graphical display and lightpen. Thus the possibility of data input via
the display screen is envisaged. It is recognised, however, that the next
stage in the general development of multi-access facilities will probably
be the addition of a display screen only (e.g. a direct vision storage
tube) to the current teletype console. The work described here is
relevant but not directly applicable to these more limited facilities.
It was carried out on equipment procured under a Science Research Council
grant (B/SR/3383) for an investigation into engineering uses of computer
graphical displays.

The basic element in an architect's design is the geometry of

the building. From the point of view of the structural engineer, the
architect's scheme drawings must be reduced to a set of consistent
geometrical data from which the load paths in the structure can be defined
and analysed. Detail design is then based on this analysis. However,
designers of the services of the building are also concerned with
geometrical data defined by the architect and the structural engineer.
Thus there is a prima facie case for opening in the earliest stages of
the design a computer file for geometrical data which may be dynamically
amended as the design proceeds.

There are intrinsic relationships within any geometrical

definition of a building. For example we may speak of a 'row of columns'
or a 'third-floor slab'. This implies that there may be a property
cornmon to two or more structural elements which associates them and
therefore that a modification to one element may result in corresponding
changes to another. These relationships and associations are expressed
within the computer by defining a 'data structure' which reflects the
organic links that exist physically between different elements in the
design, i.e. the data is 'structured'.

Computer-aided design is a process in which data is both

generated and manipulated. It is insufficient merely to store data in a
computer: it must be possible to use this data more effectively in the
CAD environment than by traditional methods if the new techniques are to
be viable. The objectives of the present project, therefore, are to
explore the way in which a geometrical data file for a building might be
defined and to suggest means by which the data might be handled. The
first phase is described in this paper: it is concerned with devising the
data structure and with providing display and interrogation facilities.
The second phase, at present under development, concerns the provision
of a graphical mode of data input and modification.

The first phase was deliberately restricted in order to obtain

a working program for preliminary assessment in as short a time as possible.
The type of building represented is of reinforced concrete, comprising
floors, slabs and columns. The plane is taken as the basic geometrical
element and the basic lines of the structural components are defined in
terms of planes. Beam and wall elements are not specifically included
although in plan views they may be pictorially represented as quasi-slabs.

382
In principle of representation, the excluded elements are not
significantly different from those considered. A more important
restriction is that the data input is by punched card and, although
additional elements may be defined, no modification procedure is currently
available.

The facilities offered by the program are described in section 2

of this paper. Section 3 comprises a description of the data structure in
some detail since this is an unfamiliar concept to many engineers: yet it
is fundamental to any interactive design system. In section 4 a brief
account is given of the writing of the program; and finally the project
is assessed in section 5.

2. PROGRAM FACILITIES

2.1 Selection of options

When the program is loaded, the display screen remains blank apart
from a list of options (a 'menu') displayed across the bottom of the
screen. The first level of option is:

CARDS DISPLAY PLOT PRINT DUMP GO

Each word is a light button: when anyone of the first five words is
seen by the lightpen an asterisk appears beneath it to indicate that a
selection has been made. However, the option is not executed until GO
is seen by the lightpen. This allows the operator to change his mind
and prevents inadvertent execution of undesired options. Since on
execution of an option a further menu of options may replace the original
one, the two-stage select/execute process precludes the undesired
automatic selection of options which appear on the screen at a common
location but which belong to successive levels in the hierarchy of options.

2.2 Input

At present the input of basic data is solely by card. In general,

data defining the basic planes is input first since the shape and location
of the structural elements are defined by reference to these planes and
not directly by coordinates or dimensions. These latter quantities are
derived from the plane equations, which are of the form ax + by + cz = d.
The coefficients a,b,c,d constitute the data for each plane and are
related to screen coordinates. This restriction arises from the lack of
windowing facilities in the FRED graphical subroutine package; the
program does not include a transformation routine to achieve the same
result.

The selection CARDS/GO causes the input of all cards in the

reader up to a termination card and the storage of the data in the

383
appropriate data structure. Further data may be input by subsequent
selections of the option. During this process, the word CARDS appears
below the menu line and is deleted when the process is complete.

2.3 Display

The selection DISPLAY/GO results in a new menu of options replacing

the first one - unless there is insufficient data to permit the
construction of a view, in which case a transitory warning message is
displayed.

The options are:

Y-ELEV X-ELEV PLAN RETURN GO

If there is no view already displayed then the selection

Y-ELEV/GO causes the display of the sectional view in the plane
through the column (or line of columns) nearest to and parallel to
the plane y = O. The location of the section is stated in a message
below the line (figure 1).

If an X-elevation or plan view already exists, then the

selection Y-ELEV causes a cursor (corresponding to a plane
y = constant) to appear on the display. The cursor may be relocated
by means of the lightpen and on selection of GO the new view will be
a section taken through the column nearest to the position of the
cursor. Again the location of the section is stated in a message
below the line.

If Y-ELEV is selected with a Y-elevation already displayed,

then no action results. The operation on selection of X-ELEV or PLAN
(as in figure 1) is similar in principle to that of Y-ELEV.

The option RETURN/GO returns the program to the first level

menu: the displayed view remains on the screen together with the
message describing its location.

2.4 Plotter output

The selection PLOT/GO results in a hard copy of the whole display

screen being plotted on the graphical plotter. In the present program
this operation is carried out on line.

2.5 Interrogation

When a view of the building is displayed the selection of option

PRINT permits interrogation of the display. If a floor level
indicator is seen by the lightpen, a message appears at the top of the
screen giving the identification number of the floor and the number of
associated slabs. If a slab is seen, the data returned is its

384
identification number, the associated floor, its thickness and its
plan area (see figure 2). If a column is interrogated, the identificatio
number, its base dimensions and the number of segments (i.e. different
sections) are displayed. The subsequent selection of GO is intended to
provide a lineprinter output of more detailed information about the
identified element.

Fi 9 .1. Y - ELEVATION WITH PLAN VIEW CURSOR

If no view is displayed or if no element is specifically

identified, then PRINT/GO returns summary information about the total
building. (At present the program contains a dummy routine replacing
the lineprinter output operations.)

2.6 Dump

The selection DUMP/GO clears the computer of the current building

data and returns the program to its initial condition, i.e. ready to
receive a new set of input data.

385
 The facilities offered by this program are intended to
demonstrate the type of operations that are possible with a display
screen and lightpen. Essentially, given a set of basic data, a
variety of ways of interrogating the data is available. The
construction of views or. the output of alphanumeric information about
individual elements can be understood as the retrieval of that data in
explicit or implicit form.

Fig.2. PLAN VIEW WITH SLAB INTERROGATED

3. DATA STRUCTURE

3.1 The requirement

The design of the data structure for an interactive program must

satisfy at least two conditions:
(i) It must permit the storage of data which is of several
different defined types but varying both in total quantity and
in distribution between types.

386
 (ii) It must contain not only raw input data but also derived
information. A balance has to be struck between storing too
much derived data and storing too little, such that the processing
time is unacceptedly long during interaction (as, for example,
when a sectional view is required).

The technique used in this program is that of a ring

structure, set up using the ICL Fortran-callable subroutines
OPEN, IALLOC and RETURN. These routines enable the programmer to set
aside a free storage zone in which addressable sections of the store
may be allocated as required to the data structure and returned for
further use when they are no longer needed.

It may be noted that the data structure was modified as the

program developed and the need for certain information on demand
became apparent.

3.2 Assembly of the data structure

The data structure comprises an assembly of linked 'beads', each

bead containing a predefined set of data. In this case there are eight
types of bead, defined. in figure 3(a) and 3(b). The contents of these
beads and the nature of the data structure will be explained by
describing the way in which the latter develops as data is input.

Assembly of the data structure begins by allocating space

in the computer store for the assembled building bead. As indicated
in figure 3(a), this bead contains summary information about the number
of elements which define the building - planes, floors, slabs and
columns - together with pointers (as yet unspecified) to the locations
in the computer of further information about these elements.

The input data for a plane comprises an identification number

and the equation coefficients a,b,c,d. When the first plane is input,
the algorithm reserves an area of store for the plane bead and inserts
the given data in the appropriate part of the bead. The algorithm then
inspects the assembled building bead and finding at this stage from the
'number of planes' counter that there is no other plane defined, it
inserts the address of this first plane bead into the assembled building
bead and adds one to the counter. Finally it places the address of the
plane bead into its own 'next' location, thus forming a closed ring of
one bead. When a second set of plane data is input, store area for
another plane bead-is allocated, the basic data is inserted and the
algorithm again inspects the assembled building bead to check whether
there are any other planes: the counter is then increased by one.
Since there is already a ring of plane beads (albeit comprising only
one bead so far), the new plane bead is inserted in the ring: the
process is to change the pointer in the 'next' location of plane bead 1
to refer to the address of plane bead 2; and to insert the address of
bead 1 in the 'next' location of bead 2. Note that the pointer in the

387
 __ -ring 01 planes - - - __
.""..... .......,

no of lanes -next - next

C, planes ident.no
no. of floors a
C, floors b
no of slabs c
Q slabs d
.... ring of assoc iators .......
no. of columns no of assoc 11. ,
C, columns C, assoc. f I. -next
nO. of ossoc. 51. -assoc. fl.
G assoc. 51.
ASSEMBLED
no of assoc.col. ASSOCIATOR
BUILDING
BEAD Q assoc.col. BEAD

PLANE BEAD

-next
ident. no.
-datu m plane
no.ofassoc.sL
C, assoc. 51.
floor datum
hel ht

FLOOR BEAD

NOTE:
( ,
- Means pointer to ....
Go Means 'pointer to first bead in a ring of .... '

Fig 3a DEFINITION OF DATA BEADS

388
 - next
ident no
-assoc. floor - next
-datum plane -side plane l
no of sides XL
Q sides
thickness Z i.

SLAB BEAD SLAB SIDE BEAD

- next
ident. no.
- plane.1.
plane.2.
-base plane
no of segments - next
Q segments - upper pi one
X CL di mension .1.
Y CL dimensiOn.2.
Z base Z upper

COLUMN BEAD SEGMENT BEAD

Fig. 3 b DEFINITION OF DATA BEADS

389
'next' location of the last bead added is the same as the pointer to the
ring of plane beads found in the assembled building bead. Thus it is
always possible to check whether the last bead on the ring has been
reached. Additional plane data is assembled into the data structure in
the same manner.

So far the data structure contains either data as input,

pointers or blank space within the beads allocated for data which has
not yet been generated. Suppose now a floor is defined. The relevant
input is an identification number together with the identification
number of 1;he (horizontal) datum plane defining the floor level. The
algorithm allocates store area for the floor bead (figure 3(a) ) and
associates it with the assembled building bead in a similar manner to
that described for plane beads, i.e. by beginning or extending a ring
of floor beads. The identification-number of the floor is inserted in
the bead but the data to be stored about the datum plane. is obtained
by searching the plane bead ring for the bead with the appropriate
identification number. Then the address of the datum plane bead and
the level of the plane are entered at the appropriate locations in
the floor bead.

During the input of floor data, one further relationship

which is implied in it is stored explicitly in the data structure -
the fact that the datum plane has that particular floor associated with
it. This relationship is specified by setting up a ring of associator
beads (figure 3(a». The mechanism of starting or extending the ring
is again similar to that described above. The bead, however, contains
only two items of data - the address of the next associator bead in the
ring and the address of the floor bead which is to be associated with
the plane bead.

Data defining a slab comprises an iqentification number, the

identification numbers of the associated floor, the slab datum plane
(not necessarily the same as the floor datum plane) and the planes which
intersect the slab datum plane to form its boundaries. The thickness
of the slab is also input. This data is stored in a slab bead (figure 3(b»
and a ring of slab side beads. The same technique of data structure
assembly is used as before. The main additional feature is that the
coordinates (x., y., z.) of the corners of the slab datum surface are
computed and siorea ex~licitly as part of the input data processing. This
dat~is used when generating a sectional view of the slab and its ready
availability in the data structure therefore reduces the picture
construction time during interaction. Note that each slab is associated
through associator bead rings with its defining planes and datum floor.

Finally, columns are defined by an identification number, by

two planes whose intersection defines the column centr.e-line
(assumed vertical), a plane to define the column base (not necessarily
horizontal) together with data on the segments of the column. Each
segment represents a different rectangular cross-section and the data

390
comprises two dimensions and the plane at the top of the segment. Again
the input data for a plane is an identification number but the stored
data is a plane bead address. Column data is stored in a column bead
with a corresponding ring of segment beads, together with associator
beads relating the column to its associated planes.

3.3 Consideration of the stored data

Figure 4 illustrates the basic data which defines the elements of

the building and serves to summarise the 'natural' dat.a that the
engineer is communicating to the computer. From the point of view of
the computer, however, terms like 'plane' or 'slab' need definition in
themselves. The definition is found partly in the composition of the
data beads, partly in the inter-relation of beads implied by the pointer
data within them and partly, too, in the operations performed on the
data. Thus a slab, for example, is an identifiable entity which is
related to other entities called planes and flo~rs •. rt is represented
graphically by a polygon and has certain other properties which are
used in the evaluation of functions such as 'area' and 'volume'.

The representation of data in the computer, therefore, is

designed in terms of the computer's operations as well as being merely
a filing system for the engineer's explicit input together with his
(often subconscious) interpretation of this data. When Ross (reference 2)
speaks of his 'modelling plex' concept in terms of 'data + structure +
algorithm'. he appears to have this total view of data representation
in mind.

Finally it should be emphasized that the major geometry of

the building is dimensioned by the plane definitions. Thus, for example,
if a line of columns is moved by re-dimensioning the common vertical
plane which contains their centre-lines, the associated slabs bounded
by that same plane are automatically adjusted in shape.

4. PROGRAM DEVELOPMENT

The experience of developing the program for this project

underlined the value, indeed the necessity, of an extensive use of
subroutines. Although the Author, in fact, wrote the complete program
singlehanded, the independent nature of the subroutines would have
permitted a group of programmers to write and de-bug individual routines
in parallel, once the definitions had been made. Even so there was
considerable advantage in being able to Vlrite small sections of the
program and to complete them before breaking fresh ground.

The total program VIas developed in three major stages. First

the data structure VIas planned as described in section 3 above and
implemented by writing nine subroutines (using reL Fortran-callable

391
free-storage basic routines}. Extension of the program to permit
amendment of the data will require additional subroutines with further
use of some of the above facilities.

The second stage involved developing routines to transform data

in the data structure into data in the display file. This stage
logically includes the inverse process, that is the interrogation
routines to abstract further data from the data structure on
recognition of a display file item. These developments involved the

z Datum plane

x ax+ by+cz-d
FLOOR
PLANE

Slab side
planes

Thickness

Slab datum
plane
Fig 4 DEFINITION OF

392
writing of a further thirteen subroutines, using the facilities of
the ICL FRED graphical subroutine package.

The third stage concerned the writing of the main program,

which is the framework within which the above subroutines operate. Apart
from the initial declaration of variables, the opening of the
free-storage zone and the display file and the setting up of the
lightbutton word buffers, the main program comprises a scheme of
operations consequent upon the previous history of the iriteraction~ Thus
there are a number of book-keeping variables which record', for example,
what view is displayed, how many floors, slabs or colUmns 'are displ,a,yed,
whether the cursor is on the screen and so on. The logic of the
lightbutton operations is the major element of the main program.

The whole program was written in Fortran IV extended by some

free-storage and graphics subroutines.

SLAB

I~
I• ~
I

Column

---" ~ Plane.1.

COLUMN
Column base plane

BUILDING ELEMENTS

393
5. CONCLUSIONS

5.1 Selection of options

The principle of 'contextual response' is relevant to the planning

of lightbutton menus. The designer's inclination is to set up an
hierarchy of decision levels without particular regard to whether some
of the options may have been explicitly or implicitly~elected by the
earlier history of the interaction. As a trivial example of the
avoidance of this danger, the PLOT option in the present program results
in the computer plotting out the currently displayed view: it does not
set up a menu to determine which view is required - the appropriate view
has already been implicitly chosen. One objective, therefore, in the
design of an interactive system must be to eliminate the necessity to
input superfluous commands to achieve the appropriate machine response:
the computer should be programmed to take account of the context.

5.2 Input

The preparation of data for card input is tedious. In phase 2 the

input mode will be graphical: this should make input easier and be
some visual check of the gross accuracy of the data.
In general the aim of any input scheme should be to reduce
the quantity of necessary data and to leave the computer to interpret
(say) a 'ditto' statement as requiri.g the copying of data already
specified. .

5.3 Plotter output

It is not envisaged that the architect or engineer would complete

his phase of the design in one session at the graphic terminal.
Thinking time is essential and the provision of hard copy, recording
aspects of the uncompleted design, is seen as a necessary element of
the design facility.

5.4 Interrogation

Encyclopaedic output is a noticeable feature of many batch programs,

although a careful analysis of how the output will be used may result
in its being presented in an easily assimilated form-. However, during an
interactive design process there should be freedom to select only the
information that is currently required. The interrogation facility
must be a compromise between rigidity in output format and extreme
flexibility involving continuous (and tiresome) definition by the user.

The DISPLAY options are, of course, part of the interrogation

facility in this program. As implemented they give information about
the structure at a single arbitrary section. It seems that the ability

394
to superimpose data from different cross-sections or from different parts
of the data file (e.g. electrical and air-conditioning services) would
be a desirable feature.

5.5. Dump

There is a need in an interactive program to be able to return to

an earlier accepted stage in the evolution of the design. The DUMP option
could be used to put the current design on to backing store: then if
subsequent development and modification proved unacceptable~ a reversion
to the dumped design could be made as an alternative to an item-by-item
change back to the same departure point.

This paper is intended not only ~o describe an experimental

program but to present for discussion some of the features that might form
part of a computer-based design system. It is recognised that new.
techniques must stand the criticism and reflect the suggestions of the
professions that will eventually use them. At the same time, the principles
underlying the CAD process must be determined so that development proceeds
in a coherent fashion, not merely in the provision of extravagant
packages.

REFERENCES

1. The KLP Computer-aided Design System, Associated British

Consultants Ltd., Harrow. 1969
2. Ross D.T., Plex, Lecture at MIT, Cambridge, Mass., May 1968.

395
 INTERACTIVE USE OF THE LIGHT-PEN IN
FINITE ELEMENT LIMIT LOAD ANALYSIS

M. P. Ranaweera
F. A. Leckie

Department of Engineering, University of Leicester,

Leicester, England.

Upper and lower bounds of the collapse load of complex structures

can be obtained by using the finite element method in conjunction with
optimization procedures. It has been found that following this course
can suffer from two disadvantages, viz. the optimization procedures
can be expensive in time and can on occasions find a local rather than
a global optimum. It has been found in one study, which will be reported,
that these difficulties can be overcome by interacting with the computer
by means of a light-pen.

1. THE LIMIT LOAD OF A STRUCTURE AND FINITE ELEMENTS

For structures which are made from material which can suffer both
elastic and plastic strains the limit load concept plays an important
role in design. If such a structure is subjected to an increasing load,
it is found that the structure cannot sustain a load greater than a
certain value (Fig. 1). This load is referred to as the collapse or
limit load, and the design value of the working load is taken as some
suitable proportion of the limit load.

Because of the complexity of the structure it is not always easy

to calculate the magnitude of the limit load. One method of determining
the limit load is to use the finite element method. In this method the
structure is divided into a number of small elements, and it is assumed
that the stress or strain fields have a simple form within each of the
elements (Fig. 2). When the stress fields method is used, they must
satisfy equilibrium and lie within the yield condition f(a . . )~O for the
material. The free parameters of the stress field are cho~~n to maximise
the load subject to the constraint f(aij)~O, i.e. it is a non-linear
optimization subj ect to constraints. The optimum obtained is a lower
bound of the true limit load. The finite element using strain fields
consists of selecting the free parameters to minimise the limit load.

397
 Load
Limit Load

Displacement

Fig. 1. Load displacement diagram Fig. 2. Finite element

for elastic plastic structure. representation.

~is again is a problem in non-linear optimization but this time without

constraints, and the solution this time gives an upper bound to the
cor~ect value. Consequently by using the stress field and the strain
field methods it is possible to bracket the true value of the limit or
collapse load.

A major difficulty with optimization procedures is that one cannot

be certain if the true optimum or merely a local one has been obtained.
In this paper it is shown that the knowledge and experience of the
engineer can play a large part in obtaining a rapid convergence to a
satisfactory solution. The importance of the starting point in non-
linear programming problems in limit analysis cannot be overstressed.
With the help of the graphical display, which provides instantaneous
access to the computed results in an easily apprehensible form and his
knowledge of the structural behaviour, the engineer can arrive at a
reasonable solution. During this process, the engineer himself will be
doing the optimization by changing various parameters on the screen,
and the computer will be merely calculating and presenting the bounds
for the load factor corresponding to the stress or velocity fields
presented to it. With an initial solution thus arrived at, an optimization
routine can be entered and the results are continuously displayed for the
assessment of the engineer. At any stage of this process, he can step in
to make any adjustments necessary, perhaps maybe to avoid reaching a local
optimum.

398
2. LIMIT LOADS FOR SQUARE CANTILEVER

As an example for interactive limit analysis, the limit .load for a

square cantilever (Fig. 3) is determined. Lower and upper bounds are
found using the Mises yield condition.

For the interactive analysis, the free parameters are displayed as

pointed arrows at relevant positions (Figs. 4 and 6). These are varied
by changing the length of the arrows on the screen by using the light-pen.
Options (chosen by using the buttons provided) are incorporated in the
program~

(a) to vary parameters without performing bound calculations,

(b) to calculate and display the bound for a selected set of parameters,
(c) to vary the parameters with continuous calculation and display of the
bound,
(d) to enter into an optimization subroutine (Rosenbrock's) with a selected
set of values for the parameters and display the results or,
(e) to obtain a print out or a plot of the current results.

Fig. 3. Display of Cantilever

399
 Throughout the analysis, the bound corresponding to the present
set of parameters on the screen and the best bound found so far are
displayed. The latter and the associated parameter set are continuously
updated and stored and may be called on at any moment. The present value
of the bound is represented by a broad arrow (referred hereafter as the
bound arrow) resting on the cantilever at the loaded end - the length of
the bound arrow being proportional to the value of the bound (Figs. 4 and
6). The best value so far found is indicated by a short horizontal line
at the level of the bound arrow corresponding to the best bound (Figs. 4
and 6). Thus as the solution is being improved, this line segment is
pushed up (lower bound analysis) or down (upper bound analysis) by the
end of the bound arrow. This way of comparison is easier than by means
of the numerical values displayed.

2.1 Lower Bounds

A lower bound calculation was done using the element division

shown 1n Fig. 4. This has 10 free parameters out of which 2 are shear
stresses and the rest are direct stresses, at the nodes. In displaying
the parameters, those corresponding to direct stresses are displayed by
arrows pointing in the proper directions but displaced slightly from the
nodes in order to avoid confusion at the nodes and to separate them from
the edges. The shear stress parameters are represented by arrows inclined
at 45 0 to the centre line of the cantilever.

Fig. 4. Display of Stress Fields

400
 Starting from a zero stress field (L.B. = 0.00), the lower bound
was maximized by varying the lengths of the arrows on the screen. In
this process, the relative magnitudes of the parameters as can be guessed
by their nature and position on the structure were taken into account.

After 6.5 minutes of maximization on .the scre.en, most of which

time the parameters were changed with continuous calculation of the bound,
a value of 0.874 was reached (Fig. 4). At this stage the optimization
subroutine was entered into and the outcome is shown in Fig. 5. Table 1
gives the results of interactive analysis and direct optimization. The
direct optimization took 2.6 mins. to attain a bound of 0.742 starting
from zero but the progress was very slow after that and for a further
14.5 mins. the bound was improved by only 2.3%.

Fig. 5. Display of St.ress Fields

2.2 Upper Bounds

For an upper bound analysis, the triangular element division

shown in Fig. 6 was used. The arrows at nodes represent the velocities
in magnitude and direction. At nodes along the centre line of the
cantilever, the arrows are restricted to move vertically whereas the
arrows at the fixed end cannot be moved. The deformed shape of the
elements are shown dotted (Fig. 6). This dotted form of the displaced
structure brings out the stretching of the edges of elements.

401
 Bound for
2WL fMo Time in mins
Ul
.r-!
Ul
:>. Maximization on the screen.
~
~ Starting from zero field. 0.874 6.5
Q)
>
.r-!
+'
c.> Using Rosenbrock's method
al
H

~
Q)
Starting L.B. = 0.874. 0.947 2.5
H

Direct maximi zation using

Rosenbrock's method. 0.742 2.6

Starting from zero field. 0.759 17.1

TABLE 1 LOWER BOUND .ANALYSIS RESULTS

Ul
.r-! Bound for
2WL fMc Time in mJ.ns
Ul
:>.
r-l
al
~ Minimization on the screen
Q)
1.979 10.0
.r-! >
+'
c.>
al
H
Using Rosenbrockts method 1. 531 1.3
Q)
+'
s:1
H
starting H.B. = 1.979

Direct
Optimization Starting from 109.277 0.8
uSJ.ng
Rosenbrock's zero fiel-d 109.073 3.8
method.

TABLE 2 UPPER BOUND .ANALYSIS RESULTS

In calculating energy dissipation rates and displaying the

deformed .form, advantage is taken of the fact that the change in velocity
at a node affects only the elements containing it and the boundaries
passing through it. Throughout the minimization, the bottom leftmost

402
 Fig. 6. Display of Displacement Fields

node was kept under a fixed downward velocity. This is permissible

because the velocity field can be found only to within a positive
multiplier. The downward velocity of this node also maintains the
kinematical admissibility (as xegards the positivity of the external
energy dissipation rate) of the velocity field. Fig. 6 shows the deformed
shape and the upper bound corresponding to this fixed velocity component.

Attempts at minimization on the screen yields the field shown in

Fig. 7 with an upper bound of 1.979. Fig. 6 shows an intermediate stage
where a movement of the middle node of the loaded edge in a physically
inadmissible direction shows an increase in the current value of the upper
bound. Using the Rosenbrock optimization procedure, with the initial
field as in Fig. 7, an improved bound of 1.531 was obtained. These
results are given in Table 2. When a field where all the velocity
components were zero was used as a starting point for direct optimization,
a bound of 109.277 after 0.8 mins. was obtained and a further 3 mins.
caused only a negligible improvement.

3. DISCUSSION OF RESULTS AND CONCLUSIONS

As indicated earlier, this investigation was made merely as an

experiment and more work has to be done in order to utilize fully, the

403
 Fig. 7. Display of Displacement Fields

capabilities of this new field in computer technology. No general

conclusi0ns may be drawn without analysing more general and complicated
structures.

The particular example considered clearly shows the importance of

knowing the physical nature.of the variables concerned in limit analysis,
and the usefulness of the graphical display in utilizing this knowledge.
Table 1 shows a considerable improvement in the results obtained by
interactive analysis over the results from direct optimization. The
latter solution probably has reached a local maximum which is much below
the global value.

The dependancy of the stationary point attainable, on the initial

starting point, is clearly shown by the results in Table 2. The direct
optimization starting from the origin gave a result which is highly
unacceptable whereas very considerable improvement was obtained by using
a more realistic starting solution. Although, in terms of computer time,
the direct optimization seems to have overtaken the interactive analysis
when both methods were used with the same initial field, the use of a
time-sharing system will considerably cut down the actual central
processor time used in the interactive analysis. It may be noted here
that some display users have quoted a figure of 10% as the actual central
processor time used in their graphical display work.

In the present analysis, optimization on the screen was done more

404
or less as a sectional search (in the upper bound analysis, two parameters
at a time could be varied continuouslY), and means have to be found to
vary several parameters at a time in a specified way determined by previous
experience. With the availability of three dimensional modelling
facilities, the user can make better choices of the parameters under his
disposal. Thus the man and the machine can work as a team to arrive at
a solution better than that can be arrived at by either one alone.

405
 COMPUTERGRAPHICAL DESCRIPTION OF
THE DYNAMICS OF A TURBULENCE MODEL

Aldo Giorgini

School of Civil Engineering, Purdue University, West

Lafayette, Indiana 47907, U.S.A.

1. INTRODUCTION

In the recent years, the numerical simulation of fluid flows has been
extensively undertaken by several investigators. The limited number of exact
solutions to the Navier-Stokes equations, which describe the motion of a
viscous incompressible fluid, can be readily expanded by means of numerical
experiments. The major difficulties inherent in the numerical simulation of
highly intricate unsteady flows are constituted by facility problems. A
full-fledged numerical study of the three-dimensional turbulent field des-
cribed by the Navier-Stokes equations, while simple in principle, would
require computers with speeds and memories of some orders of magnitude larger
than those of presently available computers.

Still, the interest in computation of non-steady solutions of the

Navier-Stokes equations at moderate Reynolds numbers or of unsteady solutions
of "model" equations, is far from academical. In the first place the numer-
ical rxperiments on simple flows or on model equations present the same
numerical difficulties that a study of larger scope would require. Secondly,
when the results of the analysis are displayed by the use of computographical
techniques, they may reveal some physical features of the phenomenon under
consideration which might not be apparent otherwise. This is especially true
in the case of certain phenomena, such as turbulence, in which spectral re-
presentations are at least as often used as physical representations.

The study presented in this paper concerns itself with one of the model
equations for the Navier-Stokes equation. The model of turbulence under con-
sideration is the one described by Burgers l equation. It is a one-dimensionti
model which has a per ~ importance in gasdynamics, i t being an approximate
model for the behavior of shock waves.

The importance of Burgers equation

(1 ) a a
~+u~='J a2u
at ax ax2

407
in the study of turbulence stems from the similarity that it has with the
Navier-Stokes equations: it is strongly nonlinear and the coefficient of the
highest order derivative can be made arbitrarily small. The smallness of v~
known to be the cause of high gradients of the field variable u in small
regions of the physical field and to be thus responsible for the onset of
turbulence in a viscous fluid. For these reasons Burgers equation has been
the object of the present study.

Equation I has been Fourier-analyzed and the numerical simUlation has

been performed with the resulting equations on the Fourier-coefficients. In
order to obtain some statistical information on the decay of an originally
random velocity field, an ensemble of sixty different realizations has been
numerically integrated. Both the dynamics of some of the single realizations
and the dynamics of their statistics are presented and describe~ in the pape~

2. BURGERS' EQUATION IN THE FOURIER SPACE

Tpe function u(x,t) appearing in equation I represents the velocity

field at time t in a one-dimensional physical space spanned by the abscissa
x. v is the viscosity of the fluid.

If a length scale L and a velocity scale U are chosen and the following
variables and parameters are defined,
adimensional abscissa E; = x/L
adimensional velocity v = u/U
adimensional time t = Ut/L
Reynolds number R = UL/v ,
equation 1 can be rewritten as
dV + dV 1 d2V
dt v at = R 2dE; .
By considering the phenomenon periodical in ~ with a period 2~, the adimen-
sional velocity field v can be expanded in Fourier sine series

L
00

v(~,t) = v(K,t)sin K E;
,K=l
where K is the wave-number and V(K,t) is the K-th Fourier sine coefficient.
If the expression 3 is inserted into equation 2 the following is obtained:

dV(~~t) + i 2 V(K,t) = ~
00

(4) { L v( K' ,t )v( K+K' ,t)

K=l,oo K'=l

K'=l
-* K-l
L
V(K',t)V(K-K',t),

where the bracket has been used in order to emphasize the fact that 4 is a
system of nonlinearly coupled ordinary differential equations in the Fourier-
coefficients.

408
 The numerical integration of the system 4 and the computographical dis-
play of the results are the objectives of the present paper.

3. THE PROBLEM OF THE WAVE-NUMBER CUTOFF

Tvo problems of approximation are involved in the numerical solution of

the system of nonlinear ordinary differential equations presented above.
These approximations are constituted by
1) the finite increments of the time variable,
2) the wave-number cutoff N, to replace the symbol 00, in the system 4.
If we use standard techniques to approach the first problem and assume that
the errors introduced by this approximation can be confined to arbitrarily
small figures, the second approximation substitutes to the system 4 the
following system of equations:

where the time dependence of the Fourier coefficients is implied.

In order to check the influence of the wave-number cutoff N on the solu-

tion of the system 5, one could solve it numerically with various values of N
and choose the value of N that renders the error with respect to an arbi-
trarily large value of N (assumed to coincide with the exact solution) within
prefixed limits. This procedure can be avoided because there exists an exact
solution of equation 4 against which the numerical solution of the system 5,
with variable N, can be compared.

This solution,

(6) -
v(K,T) =- R
2
csch K(a + R)'
T

where the parameter a determines the initial conditions, was found by

Benton. 2 The solution enjoys the property of representing the decay of one
shock wave in a period and, therefore, of having an energy spectrum that
decays monotonically with time and wave-numbers. Because of the dissipative
nature of the system modelled by Burgers equation, this qualitative mono-
tonical behavior of the energy spectrum would be expected, in the long run,
regardless of the initial conditions.

Therefore the solution 6 will be used as a reference solution

1) for the determination of the influence of the wave-number cutoff N,
2) for the determination of the statistical ensemble of the numerical exper-
iment on the statistics of a shock-wave field.

The parameter a in the reference solution 6, which determines the ini-

tial conditions
2
- R csch Ka

409
may be interpreted as th~ virtual orlg~n (T = - aR), measured in Reynolds
numbers, of an infinite velocity field which, because of viscosity, decays
according to the law given by the' expression 6. The parameter a can be re-
lated to the Reynolds number R if the velocity scale U is interpreted as the
mean square velocity at T = 0. In this case the relationship between Rand
a is the following:
2
(8) csch Ka

4. THE INFLUENCE OF THE WAVE-NUMBER CUTOFF

If the reference solution 6 is accepted as representative of the be-

havior of the decay of shock-waves, it is possible to use it in the formula-
tion of a criterion for the determination of the wave-number cutoff.

In fact, the criterion may require that the dissipation taking place at
the wavenumbers larger than N be negligible with respect to the total dissi-
pation. More formally, the expressions

1:N 2-2
K v (K,O) and
K=l
~ 2-2
L. K v (K,O) ,
K=N=l
respectively proportional to the dissipation taking place in the wave-
numbers regions 1 < x < N and x > N at time T = 0, may be used to define the
ratio
2 2
K csch Ka

In the present study a value £ = .01 has been chosen, with the belief that
the discard of 1% of the total dissipation would not sensibly affect the
behavior of the phenomenon. In the expression 9 a is related to R by means
of equation 8. Therefore, once the value of £ is selected, a relationship
will result between R and N. This relationship, for £ = .01, is given
ap~roximately by

(10) N :: 2.2 R •

This relationship between wave-number cutoff N and Reynolds number R has

proved to be quite adequate in all the numerical experiments performed with
random initial conditions. None of the sixty realizations studied has shown
a marked effect of the cutoff.

The influence of the wave-number cutoff on the solution of equation 5,

410
according to the relationship 10, is presented in Figure 1, for R = 17 and
N = 49.
Figure 1 shows the behavior in time of the relative error
V(K,T) - V(K,T)
V(K,T)
(where V(K,T) stands for the numerical experiment and V(K,T) for the refer-
ence solution) starting from the initial conditions

(ll ) V(K,O) = v(K,0) = - R2 csch Ka ,

a and R being still related through the equation 8.

Frame A in Figure 1 shows the error after one time increment and frame
L shows the error approximately at T =
77, by which time the energy has
decayed to a value several orders of magnitude smaller than the original
energy. It is interesting to notice that all the other frames show curves
with an initial part of the L-type (say) and a final part of the A-type,
connected by a quasi-vertical line which moves toward the right as time
passes. In reality the high slope of the connection between the two branches
is due to the particular ordinate scale used, which has been selected in
order to give emphasis to the small relative errors.

If we accept the approximations of the so-called "cascade model" in

Fourier space, according to which the energy cascades from smaller to larger
wave numbers, where it is dissipated, then the effect of the wave-number
cutoff can be explained in the following way. As soon as the number cutoff
is applied, there will be an energy buildup within the wave-number range that
is considered, because of the impossibility of the energy to cascade to
higher wave-numbers (where it would be dissipated). This accumulation of
energy is more pronounced near the cutoff and tries to increase in time,
because of the cascading of energy, and will cause an increase of the dissi-
pation at the high wave numbers. Consequently the smaller wave-numbers,
which are not appreciably effected by dissipation, will be required to pro-
vide more energy than needed for the cascade. As time progresses the in-
creased dissipation due to the original energy buildup will have had the
effect of having accelerated the process of decay and the energy spectrum
(see frame L, figure 1) of the numerical solution will correspond to the
energy spectrQ~ of the exact solution for a later time.

In the overall, if the relationship :1 = 2.2 R is respected, the influ-

ence of the wave-number cutoff will be minimal and relegated to much less
than 1% for the first 80% of the wave-numbers considered. Large errors will
occur at large wave numbers, where the energy contribution is, howeve~ small.

5. THE EXPERIHENT HITH RANDOlv! INITIAL CONDITIONS

The choice of the initial statistics for the turbulence-model experiment

411
 ,.
eo I. 0
«-I
eo I. 0
«-I '" eo I. 0
<t-I
,.;
-;;
/' "7
«-Z «-z
70
«-3
70
«-, 70 «-2
«-3
60 :f~ 60 :E~ 60 :£~ -----
50
~
50
( 50

,j() O. ,j() o. ,j() o.

30 30 30
I. . . .
ZO :E~ ZO H 2D :E~
«-3 «-3 «-3
10 <t-Z 10 «-2 10 «-2
«-I «-I «-I
-1.0 -1.0

A B c
80 I. 0 '" eo I. 0
,.;
eo I. 0 '"
<t-I "7 «- I /' «-I /7
10 <t-2 70 «-2 711 «-2
<t-3 «-5 «-3
60 t:t 60 H 60 :£~
(
50 50 50

,j() a. ,j() o. ,j() o.

I---J.
30
'-- 1--
2D :E~ 2D :E~
«-3 <£-3
fa 10 <t-z 10 «-2
«-I «-I
-1.0 -t.O

D E f
' .. -0'

'" '"
,.;
80 I. a eo I. 0 eo I. 0 T
<£-1 «-I «-I
10 <£-2 711 <t-2 L 70 «-2
<£-3 <t-3 «-3
60 :E:t 60 :E~
7'
60 :£~
7
f
50 50 50

,j() o. ,j() o. ,j() o.

---.J 1-
2D :E~ 2D H ZO :E~
«-3
<£-5 <t-3
to <£-2 10 «-2 10 «-2
<£-1 <£-1 «-I
-f.O -1.0 -1.0

G H

80 I. 0
<£- f
'" eo I. 0
<£-1
,.;
eo 1.0
«-I
'"
711 <£-2 711 «-z 711 «-2
<£-3 «-5 <£-3
60 :E~ 60 :E~ 60 :£~
50 50 50

,j() O. ,j() O. ,j() O.

ZO :E:i
«-3
- 2D
1-
30

2D :E:i
«-3
1-

10 «-2 10 10 «-2
«-I «-I
-1.0 -1.0

J K l
Figure I - The influence of the wave-number cutoff_ Abscissa.: wave-number
Ordinate: ~tive error. The time 'l' corresponding to each frame
is represented in the "thermometer" at its left.

412
should be dictated by some specific criterion. In the case under examinatio~
it has been considered opportune to choose initial conditions for the Fourier
amplitudes which be statistically independent and Gaussianly distributed.
This initial condition on the statistics of the Fourier amplitudes, that is
called by Kraichnan3 the "maximal randomness" initial condition, needs the
further specification of the variance to be assigned to each Fourier coeffi-
cient (assuming that its mean is zero). As the dissipative nature of the
system would rapidly reduce the amplitude of the coefficients of higher wave
numbers, it has been considered appropriate to choose a standard deviation,
for the initially normal density of each Fourier coefficient, equal to
2
(12) a(K) =R csch Ka

which coincides with the initial value of the reference solution.

The Reynolds number for the statistical experiment has been chosen as
R = 90 and the resulting wave-number cutoff has been rounded off to N = 200.
The sixty realizations integrated have been considered sufficient for the
study of the first order statistics in the Fourier-space.
In order t9 exhibit the Fourier-amplitudes in the graphical display,
their ratio to the initial standard deviation
V(K,T)
a(K)
has been plotted.

The evolution of the reference solution V(K,T) relative to its initial

conditions IV(K,O)I = a(K),

(14)

is shown in figure 2 in order to provide an element of comparison between

the reference solution and the statistical realizations.

The study of the evolution of the sixty realization leads to the recog-
nition of four main patterns of behavior. The four patterns lead to four
different final configurations of the Fourier coefficients (and therefore of
the physical field), and these final configurations have been chosen for the
labelling of the evolution patterns:
1M - the final configuration in physical space presents a shock-wave in
the center of the period;
IF - the final configuration in physical space presents a shock-wave at
the beginning of the period.
2M - the final configuration in physical space presents two shock-waves
located at 1/4 and 3/4 of the period.
2F - the final configuration in physical space presents two shock-waves
located at the beginning and at the center of the period.

It is evident that ll~ and IF constitute the same pattern translated by

413
 o. '" 100 150
O. O.

-.3 -.3 -.3

-.5 -.5 -.5

-.8 -.8 -.8

-1.0 -1.0 -1.0

A B C

~. o. O.

-.3 -.3 -.3

-.5 -.5 -.5

-.8 -.8 -.8

-1.0 -t.O -1.0

0 E F

o. o. O.

-.3 -.3 -.3

-.5 -.5 -.5

-.8 -.8 -.8

-1.0 -1.0 -1.0

G H

o. O.

-.3 -.3 -.3

-.5 -.5 -.5

-.8 -.8 -.8

-1.0 1 - _ - L_ _""'--_--'~_~ -t.O -1.0

J K L

Figure 2. The decay of the reference solution. Abscissa: wave-numbers.

Ordinate: relative amplitude = v(k;r;)!d (r.). The time"C"
corresponding to each frame is the reading of the "thermometer"
at its left.'

414
one half of a period and 2M and 2F constitute the same pattern translated by
one fourth of a period.

The Fourier-space and physical space evolutions of the pattern 2F are

presented in figures 3 and 4 respectively. Another slightly different reali-
zation of the 2F-type in Fourier space is presented in figure 5. The pat-
terns 1M and IF are shown in the figures 6 and 7 respectively.

The figures 3, 4, 5, 6, 7, contain in frame A the initial conditions and

in frame B the evolution after one time-step of integration. In the figures
3, 5, 6, 7 it is clearly observable that the high wave numbers have been
sharply reduced by the effects of viscous dissipation, while in figure 4 such
effect is portrayed by the "smoother" curve in frame B with respect to the
curve in frame A.

The number of frames in the figures 4, 5, 6, 7 do not make justice to

the complexity of the evolution of the realizations in Fourier-space. In
this sense the viewing of the film that accompanies the presentation of this
paper is essential for a full grasp of the complexity, and yet the order, of
the dynamics of the Fourier-coefficients in wave number space. While an
explanation of such behavior is far from clear, it is nevertheless evident
that the "cascade" process is too naive a model for the exchange of energy
among the Fourier modes.

In all the realizations studied the "equilibrium" configuration 1M, 2M,

IF, 2F was reached between the time L = 2 and the time L = 4. The integra-
tion process had been ~ priori stopped at time L = 4 because the reference
exact solution had, at L = 4, an energy content that was 1/10 of the initial
energy. It had been considered plausible that by that time all energy ex-
changes among the initially randomly "charged" modes might have taken place.

The factors in the initial conditions that determine the type of evolu-
tion of any single realization can be seen in the "phase-space" spanned by
the Fourier coefficients. Each realization will describe in this space a
trajectory whose projection on the plane spanned by v(l,.) and V(2,L) is
shown in figure 8. There is a clear tendency for each trajectory to remain

that the relative magnitude of the first two Fourier modes at L = °

in the same quadrant in which the initial station is located. This means
deter-
mines (with a large probability) the course of evolution of each realization.
Specifically the evolution types 1M, IF, 2M, 2F are observed when v(l,O) and

°
v(2,O) are related as follows:
and v(2,0) < Iv(l,O) I
°
IF when v(l,O) <
and v(2,O) < v(l,O)
1M
2F
2M
when
when
when
v(I,O) >
v(2,O) >
v(2,O) <
°
°
and
and
v(l,O) < v(2,0)
v(l,O) < Iv(2,0) I

After considerable time has elapsed the configuration to be expected

~{hen v(l,O) ~°
should present one shock in the period, unless v(l,O) is very close to zero.
then the second wave-number becomes the leading one and
(because of the higher dissipation of the higher wave-numbers) the Fourier

415
 1.0 '.0 ~-:

.S .S

o. o. o.

-.S -.S

-1.0 -I,D

B C

.:.-- .. "~ '.0 l.~

'3 .S

O. O. O.

-1.0 -1.0 -1.0

0 E F

. -- .. ,-:

,
" '.: i 4- '1' '~; -
~.
j
50
j Ii' '~; l, ~

I
.5 .5 .S

UA.
O. o.
' ~
O.

-.5 -.5 -.S

-1.0 -1.0 -1.0

G H

.: - .
::
.. .! 1 '.J t----'""f--~'I"_--__"f"---,-

.5 .5 .S

o. ~~~~----------~ O.

-.S -.5

-1.0

K
Figure 3 - Evolution of a realization of the 2F -type in Fourier space.
Abscissa: wave -numbers. Ordinate: relative amplitude =
v(~.T)/O(~. The time T corresponding to each frame is the
reading of the "thermometer" at its left.
416
 O.
"n

O.
' ',-
.,

.5

O.
..;

'.5

-, .0

A B C

.,

.5

O. O.

-.5 -.5

-',0 -t.O

D E F

-~
"- "
~

':'1
.5 .5 .5

o. ~+------r-------h~ O. O.

'.5 -.5 '.5

'1.0 L -_ _'-------'_ _--'-_ _- L_ _---" -1.0 '1.0

G H

..:.-;
_ n
·:'1 ~
-4- -+--+--+
':'1 "~r
" I
ilI
I
.5 .5 .5

o. 0, O.

'.5 '.5 '.5

-1.0 L----'_ _---'-_ _- L_ _--L_ _- ' -1.0 -, .0

J K
Figure 4 - Evolution of a realization of the 2F -type in physical space.
Abscissa: fractions of period (only half period is represented).
Ordinate: adimensional velocity. The time ~ corresponding to
each frame is the reading of the "thermometer" at its left.

417
 -~ .. ilHHHhI'/'t;--+'If"--~---'" .! l '.J

i'

.5 .5

O.

-.5 -.5

-1.0 'If!f-HH-l-f-t'-f-f-'--- -1.0 H---L---'---"----

A B c
" ~ '.0 lII-H--lI-'5,!,--0_1'1""_ _.1:f"15'"'------"~•• .. !-I+H-I"Pi'r-'---'t",,--~l~f'-;-~
',I
!'
.5 .5

o. I~HnhA
IHIHIII+IIIIJlfII+ftttItj-l/\i\it/tl\f'rfW~""I
11111 1111111 II II 11M II Ur i~ VVYV'

-.5 -.5

-1.0 H+l1--"---~-~-~ I-tItti+HI-'-...L..--'----.J H-If-tt..L:...-...L..--"-----.J

o
-1.0 -1.0

E F

"j' l.'
1 "

.5 .5 .5

O. II+H+H+l+++fttt-tttttt-ttr~'
JiJJJvw
VV V
~Ittt\i ,ttl1
V
O. II-HtttHtttt+++'~tttAtt
flrttflfl4;:f.£!..\t'q.Ll.
~VVVVV 0·1HtW_~
-.5 -.5 -.5

-1.0 I+I-+-"----'---'----.J -1.0 H-+--L-_...L.._-"--_--.J -1.0 H-+-L---...L..--"-----.J

G H

l.,1---¥--!.JjJL.--"I"---""1·

.5 .5

o.

-.5 -.5

-1_0 f-IJ--"-----'---'--~ -1.0 ,......_.1....-_-'--_-'--_-' -'.0 L:......_-'---_~ - - - - ' - - - '

J K L
Figure 5 - Evolution of a realization of the 2F -type in Fourier space.
Abscissa: wave -numbers. Ordinate: relative amplitude =
v(":l')/o(,q. The time T corresponding to each frame is the
reading of the "thermometer" at its left.

418
 .. :: ' . 0 HH--+i"i'Hrtt-T-I'--
'I'
:i
!

.5
,Ii
D.

,I !.0

B c

.. ' "
)' .,
I
.5 3 :-j
'i

'I

o. 2 fj
II
II
'.5 -,:,

~
11.1

·1.0 'W'---'---L...,--'-.----' ·1,0 'tH1tt-1l-'---'----'--_J 0 '

D E tF

1.0 -.. , [I " 5f--- f-" -'+ -.' "

,5 , j

3 II
0, 0,
2 f

',5 ',5

-1.0 -l.O

G H

1,01----"/----'-1'---1'--- ".- .;.- '.:1 C'

--j-

,5 ,5

0, II~~~----------- 0,

',5 ',5

'1.0 ' - - _ - ' -_ _' - - _ . . L . . _ - - ' -1.0

J K L
Figure 6 - Evolution of a realization of the 1M-type in Fourier-space.
Abscissa: wave -numbers. Ordinate: relative amplitude
v(~'Y)/o(r.1. The timet' corresponding to each frame is the
reading of the "thermometer" at its left.
 1.0

.5

O. O. O.

-.5

-t.O

A B C

~ .~ 1.0

.5 .5

O. O.

-.5 -.5

·1.0 -1.0

D E F

.,..:
u 1.0 '"' toO ISO

.5 .5 .5

O. o. \A ~ A1\ 1\ ,A

~VVVVV

-.5 -.5 -.5

-1.0 WL--'---"----'----.-J -1.0 -1.0

G H

1.0 i-_-!'"'ip-_-11~"_-1"¥-'''_-4 1.0' '.J

.5 .5

o. H-+++++++-
Al-\-,flfll+i"c"o...._--i
VV v O.

V
-.5 -.5

-1.0 -1.0 L-_-'-_ _"--_-'-_---..J -1.0

J K L

Figure 7 - Evolution of a realization of the IF -type in Fourier-space.

Abscissa: wave-numbers. Ordinate: relative amplitude =
v(~;r)/cf(,q. The time corresponding to each frame is the
reading of the "thermometer" at its left.
420
1.

~2 . .
. ~O.
.....A
\
'2
.'

"
.'

' ..
'.:,. :....
'0. ' ••

.0 ...

-1.'

v(l,-r)

Figure 8 - The trajectories of the 60 realizations in

the v(l;'&:"), v(2;r) "phase" subspace.

421
 coefficients corresponding to odd wave-numbers will decay to zero very
rapidly. By similar reasoning, a final configuration with three shocks is to
be expected when both v(l,O) and v(2,O) are very close to zero and v(3,O) is
not. This explains the fact that in sixty realizations only one had a final
configuration with three shocks and none had a larger number of shocks. The
fact that two-shock configurations (see figure 8) are less frequent than one-
shock configurations is explained instead by the fact that the joint prob-
ability density distribution function of v(l,O) and v(2,O) is the product of
the marginal probability density distribution functions of v(l,O) and of
v(2,0), and v(2,O) has a smaller variance than v(l,O) because of the cri-
terion used in the statistics of the initial conditions.

6. THE STATISTICAL EXPERIMENT

The ensemble of the sixty realizations integrated does not constitute a
"homogeneous" ensemble. In fact all realizations in physical space are zero
at the ends of the period because of the sine-Fourier analysis performed on
the period. In order to create a homogeneous ensemble, each realization can
be translated of a certain amount n which is considered a random variable
uniformly distributed between °and 2n. To be sure the ensemble so created
will not be the most general homogeneous ensemble for the phenomenon. In
fact the phases of the Fourier amplitudes are "frozen" at their initial valuE
and, therefore, they are not allowed to change in time. While this will
affect the values of the skewness and flatness factors of each Fourier ampli·
tude, in general it will not affect the energy spectrum.

For convenience from now on the ensemble of the sixty realizations will
be called the sub-ensemble and the larger ensemble the homogeneous ensemble.
It is recalled that a translation of a configuration in physical space cor-
responds to rotations of the Fourier amplitudes in their complex plane. The
K-th mode rotates of an angle Kn if n is the amount of the translation in
physical space.

The Mean of the Sub-Ensemble

The initial mean is by choice zero for all wave-numbers. It is never-

theless evident that a sample of 60 random variables will not, in general,
yield a zero mean. This fact is reflected in figure 9, when the sub-ensembl~
mean amplitudes of the Fourier modes are shown at , = 4. The form of the
mean amplitude spectrum can be explained in terms of the final configuration:
1M, 2M, IF, 2F by knowing that their relative occurrence is roughly 1/6, 1/3
1/6, 1/3.
The Mean of the Homogeneous Ensemble

By averaging the amplitude spectrum in figure 9 over the angle 2n in thl

complex plane of each Fourier amplitude, the mean' of the homogeneous ensembl
is found to be identically zero.

422
 WAVE NUMBER
o•

- .02

3:
-.04 t%j

:t:-
z

-.06 :t:-
3:
'1j

t""i
-.08 H
1-3
c::
0
t%j
- • 10

-. t 2

20 40 60 80 100 120 140 160 180 200 220

Figure 9 - The sub -ensemble mean amplitude of the
Fourier coefficients at "l: = 4.
The Energy Spectrum of the Sub-Ensemble and of the Homogeneous Ensemble

Figure 10 shows the evolution of the energy spectrum for the sub-
ensemble (and for the homogeneous ensemble). The continuous line is the
spectrum of the reference solution. It is clearly seen that for the first 30
wave numbers the energy spectrum of the statistical experiment and of the
reference solution coincide at any time and follow a K- 2 law. Higher modes
follow a much faster decaying law. It is to be pointed out that the K-? law
does not rule against the Kolmogoroff's law that would require a K-5/3 be-
havior in the "inertial sub-range". In fact no inertial sub-ranp;e exists in
the experiment that is presently introduced.

423
 lE'tO~
.. .. 1E+00 lE+OO I ,'1::
I[ ~~l 1[~01 I[ ~Ol
1[~02 1[-()2 1[-02
,3 1[-03 1[-03 1[-03
I[-OJ 1[-04 1[-04
1[-05 1[-05 I[-OS
1[-06
1[~07
'[" 1[-06

'[-07 1[-07
1[-08 1[-08 1[-08
1[-09 1[-09 1[-09
1[-10 1[-10 1[-10
1[-11 1[-11 1[-11
1[-12 '[-'2 1[-12

A B C

,~~: ,~~:
1[...00 1[+00
1[-01 1[-01 1[-01
'[-02 '[-02
1[-03 1[-03 1[-03
'[-OJ '[-OJ fE-04
'(-OS 1[-05 I(-OS
'[·06 1(-06 1[-06
1[-07 lE-07 1[-07
1[-08 '(-08 1[-08
1[-09 '(-09 1[-09
1[-10 1[-10 1[-10
1[-11 IE-II '['11
'[·.2 1[-'2 '[,'2

D E F

. . - .

'[·OJ
I[-OS
'[-06
1[-07
'[-08
1[-09
'[-'0 '[-'0
fE-II 1£-11 I[-It

'[-'Z 1[-12 1[-12

G H

1[>00 .. 1[>00 ,.. ~:

1[-01 1[-01 1[-01

1[-02 1£-02
1[-03 1[-03

'[-OJ 1[-Q.4

'[-OS I[-OS 1[-05

1[-06 '[-06 1(-06
1[~7 '[-07 '[-07
'[-08 '[-08 '[-08
'(-09 '[-09 '[-09
'[-'0 '[-'0 .[-10
1[-11 1[-" 1[-11
'[-IZ '[-'2 1[-12

J K L

Figure 10- The energy spectrum. Abscissa: wave -numbers. Ordinate:

energy. The time 't" corresponding to each frame coincides
with the reading of the "thermometer" at its left.

424
The Correlation Function

In figure 11 the final stage of the correlation function

V(F,)v(C;+n)
2
v (~)

is presented. It has been calculated for the homogeneo11s ensemble and has
been compared with the correlation that could be obtained from the spectrum
of the reference solution at the same time. The correlation function is
obviously periodical in n.
CORRELATION DISTANCE

~
c::
z
(")

t-3
H
o
Z

RS
-.6~~~~~~~~~~~~~~~~~~~~-L~~-L~~

o. .5 1.0 1.5 z.o Z.5 3.0 3.5

Figure 11 - Correlation function of the reference

solution (RS) and correlation function
of the numerical experiment (NE) at
r = 4.

425
 WAVE NUMBER
Z.O

1.5

-1. S

-2'°0L~--2~Q~--4~O~--6LO~--8LO~--,LOO~--12LO~--14LO~--16LO~--18LO~--2~OO~~220

Figure 12 - Skewness factors at time 7:' = 4

The Skewness and Flatness Factors for the Sub-Ensemble

The figures 12 and 13 present respectively the skewness and flatness

factors of the probability density distribution functions of the Fourier
amplitudes of all wave-numbers. The figures show that even and odd wave-
numbers present different trends for these factors. In the homogeneous
ensemble the two trends would be unified.

The Probability Density Distribution Functions for the First Two Fourier
Coefficients

The probability density distribution functions for the first two Fourier

426
 WAVE NUMBER

~
4.S
L'
»
8
4.0 Z
tt1
en
en
3.S
~
»
n
3.0 8
0
::0

2.S

Figure 13 - Flatness factors at"t' = 4

coefficients are shown in figure 14 and 15 respectively. There, the stepwise

diagrams represent the histograms for the probability densities and the con-
tinuous lines the approximation to the density by Hermite expansions trun-
cated after the fourth term. The price for the approximation is portrayed by
some negative values of the densities. The different behavior of the prob-
ability densities for even and odd wave-numbers is evident.

7. CONCLUSION

The numerical experiment on Burgers' equation presented in this paper,

is (to the knowledge of the author) the only experiment in which the Fourier
space representation is directly used for numerical integration, and creates
an ensemble of realizations for the study of its statistics. Hhile the dis-

427
1.0 .6-4~--=f---f---+-~ 1.0 1.0

.5 .5 .5

.. .. ..
.9 .9 .9

.6 .6 .6

.. .3

.2
.. .3

.2
.'
.3

.2

.2 .2 .1
.2 .1
.1

A B c
1.0 .6;~-~--+---+---f f .~ .6;~-~~-~-~-- 1.0

.5 .5 .5

..
.9 .9

..
.9

.'

.
.6 .6 .6

.. .3

•2
.. .3

.2
.
.3

.2

.2 .2 .2
.1 .1 .1

o E F

1.0 .6;1--~----+----+----4 1.0 .6;~-~---+----+---f 1.0 .6.~--.:f.--.!I----+---f

..
.
.5 .5 .5

..
•9 .8

.' .

.
.6 •6 .6

.. •2
.3

.2
.
.3

.2

.2 .2 .2
.1 .1 .1

G H

1.0 t.) .6;1--~~-~--~---~ 1.0 .6'~-~---+---+-~

.5 .5 .5
.9 .8 .8

.' .' .'

.
.6 .6 .6

.. ..
.3 .3 .3
.
.2 .2 .2

.2 .2 .2
.1 .1 .1

J K L

Figure 14 - Histogram and probability density for the first Fourier coef-
ficient. The reading on the "thermometer" at the left of
each frame is the standard deviation. The time corresponding
to each frame is the same as in Figure 10.

428
 f.O .6"j'--+---+--~_-'I f.O .6';'-"-----'/'---+---+---'i f.O

.5 .5 .5
.8 .8 .8

.4 .4 .4

.
.6 .6 .6

..
.3 .3 .3
.
.2 .2 .2

.2 .2 .2
.f .f .f

A B c

f.O .6-;,-4-----'/'----'/--+----4 .5-;'-"-----'/'---+---+---; '.0 .6-1'-4-----'/'----'/--+---4

.5 .5 .5
.8 .8 .8

.4 .4 .4
.6 .6 .6
.3 .3 .3
.4
.2
.' .2
.4
.2

.2 .2 .2
.f .f .f

o E F

f.O .6]'---=f---'/--+---'i f.D .6-j'--+---+--~--'I f.D

.5 .5 .5

..
.8 .8 .8

.4

.
.6 .6 .6

.. .3

•2
.. .3

.2
.
.3

.2

.2 .2 .2
.f .f .f

G H

f.O .6]'---ffi---'/---t----i f.D .6;r--~+-~~-+_-~ f.J .6-;'-"--tl'I------¥---+---'i

.5 .5 .5

..
.8 .8 .8

.
.4
.6 .6 .6

.. .. .3

.2
.

.2 .2 .2
.f .f .f

J K L
Figure 15 - Histogram and probability density for the second Fourier
coefficient. The reading on the "thermometer" at the
left of each frame is the standard deviation. The time
corresponding to each frame is the same as in Fogure 10.

429
cussion of the numerical techniques has been presented in another paper,4 the
present paper has as its aim the description of the numerical results.

The problems of cutoff are approached and solved according to the same
criteria which are put forth in the paper itself and the influence of the
wave-number cutoff is briefly discussed.

The dynamics of the shock-waves described by Burgers' equation is pre-

sented in its evolution both in the physical and the Fourier space. Its
several patterns are better understood by seeing the computer generated movie
that accompanies the presentation of the paper.

Several characteristics of the statistics of Burgers' equations are

presented and discussed.
8. ACKNm1LEDGEMENTS

Acknowledgement is made to the National Center for Atmospheric Research

(NCAR), which is sponsored by the National Science Foundation, for use of its
Control Data 6600 computer.

The author wishes to thank in particular Mr. David Robertson for his
generous help in programming the movie and Mr. Fred Walden for expediting in
countless ways the preparation of the movie itself.

To the Advanced Study Prograrn of NCAR is due the deepest gratitude of

the author for providing scientific "asylum".

9. REFERENCES

1. Burgers, J. M.: Advances in Applied Mechanics (Academic Press Inc.,

New York, 1948), Vol. 1, p. 171.
Burgers, J. M.: Proc. Roy. Netherl. Acad. Sci. (Amsterdam), 43, 2
(1940); 53, 247 (1950); B57, 403 (1954.
Burgers,-Y. M.: Nonlinear-Problems in Engineering (Academic Press
Inc., New York, 1964), p. 123.
2. Benton, E. R.: Phys. Fluids, 9, 5,1247(1966).
3. Kraichnan, R. H.: Phys. Fluid;, 5,497(1959).
4. Giorgini, Aldo: Developments in Mechanics, Proc. Tenth Midwestern
Mechanics Conference (Fort Collins, Colorado), Vol. 4, p. 1379-1408
(1968).

430
 PART 5

Architectural Applications
COMPUTER AIDED ARCHITECTURAL DESIGN

A BijJ

Architecture Research Unit, University of Edinburgh,

55 George Square, Edinburgh 8, Scotland.

INTRODUC TION

This paper sets out to describe the Architecture Research Unit's

development of a computer graphics application to architectural
practice. It will concentrate on the context for computer applications
existing in architecture, and will not cover detail aspects of computer
science.

Most work done so far on computer appplications to architecture has

concentrated on narrowly defined distinct aspects of architectural
activity, without sufficient attention to solving the problems of
assimilation into general practice. Thus the profession has been slow
to adopt computer applications as a normal part of professional activity.

Work to date on interactive computer graphics, using a cathode ray tube,

has largely been concerned with constructing and manipulating graphic
images on a screen, without attaching significant information content to
the image. This is particularly true of America, developing rapid
animation and three dimensional representation with tone and colour.
Thus intended applications to architecture have largely remained at a
theoretical level.

At the ARU we are trying to develop a computer application which will

handle information of general relevance to architecture, providing a
means of acces s which will facilitate as similation of computer facilities
into general practice. Our use of graphics, purposely restricted to
a limited number of rectilinear forms, will be to convey information of
specific significance. The graphics will convey the geometric topology

433
relevant to other non- graphic information, which may be required to
work towards a problem solution.

We intend to get a system operating, within a short period of time, in

a limited context, within an organisation that already builds large
numbers of houses. The system will be capable of expansion, as it
gets accepted into existing practice, so that gradually a more general
and comprehensive application will be achieved.

THE CONTEXT OF COMMUNICATIONS

The success of any interactive computer graphics application must

depend on how much sense can be got out of the system, and how this
relates to other information already held by the user. We fuerefore
have to look at the sense, or logic, operating in architectural practice,
to see to what extent this corresponds to the information handling
techniques which are possible with computers; in order to establish
some relevance between the two in our application.

Increasing interest by architects in the possible application of

computers, and the purpose of our project, give rise to a number of
issues which require consideration.

The possibly obvious and basic generalisations which follow may be

valid, and consideration of their validity will be relevant to any
development of information handling techniques in the context of
architectural design. These are first considered in a general context
of information passing between people, followed by particular
characteristics arising in architectural practice, which are then
related to the use of computers.

COMMUNICATION BETWEEN PEOPLE

Presentation of information:

Pre sentation is the means by which ideas, intentions or instructions are

held in a form, and are carried by a vehicle, which enables information

434
to pass from one person to another. The form may consist of an
arrangement of points, holes, lines, tones, colour or soundwaves. The
vehicle may consist of ink on paper, holes in paper tape, magnetic tape,
transparent film, or air bearing sound. The presentation may vary
widely, directed at the different perceptual senses, to invoke responses
ranging from those which are cool and calculated to re sponse s of mood
and emotion. The pre sentation could be peaceful, or violent.

It is the conventions associated with particular activities which

commonly restrict the means of presentation, thus architects present
information in written and graphic form by an arrangement of ink lines
on paper. It would be possible to present the same information in any
other form, but this may not be convenient.

Familiarity of information:

Information generated by one person will refer to data available to that

person, which may be in the form of information on paper stored on
library shelves, or information stored in personal memory built up of
previous expe rience.

The same information received by another person, if it is to make any

sense, must refer to data already available to that person; and again
this may be in the forrn of a library or personal experience.

The precise form in which the information should be presented, for

sensible transmission from one person to another, must relate to the
degree to which both persons are familiar with each others store of
information. This relationship is necessary at all levels of
communication, whether the form of information or its content
appears simple or complex.

e. g. Instructions on the detail construction of a wooden

window will assume a degree of common knowledge abcu t
the availability and workability of timber, and the
performance characteristics of windows.

A critical path network analysis, for the control of

production on a building site, will assume a degree
of common knowledge about the relation of time to
resources, the need for a sequence of events, and
the relationship between a diagramatic repre sentation

435
 and actual activities on site. Lack of this common
knowledge has led to a reluctance to accept network
analysis, in favour of the more familiar bar chart.

Precision:

This is a measure of the degree to which the information read by the

person receiving it corresponds with the information put out by the
one who generates it, with relevance to the context of their respective
stores of experience.

Precision does not necessarily increase in direct proportion to the

amount of information supplied, nor need it refer to dimensional
accuracy down to very small dimensions:

e. g. On a building site, the implied precision in specifying a

dimension to the nearest half millimeter becomes
meaningless, and achieves no precision, if the dimension
has to be applied in a context which can not respond to
anything less than five millimeters. The specification
will be particularly confusing if it does not provide a
clue as to whether the dimension should be rounded up
or down to the nearest useful dimension. This commonly
occurs where the level of detail possible on drawings is
greater than that which can be executed on a building
and could cause the finished product to differ from the
original intentions.

Complexity, or simplicity:

Complexity can be regarded as a measure of familiarity, where the

comprehension of one person receiving information is ready to
accommodate the information generated by another. Thus the person
generating information should never find his output complicated. If
the person who receives the information can not understand it, then
he will regard it is complex.

e. g. A diagram of electronic circuitry may be simple

to the person who designed it, and also to the
electronics engineer -who has to construct it; but
it will be incomprehensible to an architect.

436
 A typical architect's working drawing should be
simple to a builder, and may be complex to the
client. In current attempts to simplify drawings
the object must be to make them more comprehen-
sible, and this is not neces sarily achieved by
reducing the number of lines or text.

Parts and Linkage s :

Any presentation of information may be seen to consist of a number of

lesser parts, or bits, of recognisable information, together with a
specification of the linkages, or relationships, between one part and
another. Each part could itself form a separate presentation, further
subdivided into its constituent parts and linkages. This may
correspond to the concepts, in computer terms, of data and data
structure s.

e. g. A wall may consist of familiar units, such as bricks

and mortar, assembled in such a way as to produce a
particular length, height and thickness.

A room may consist of a number of familiar

components, such as pre specified assemblies of
brickwork, combined to enclose a space of particular
shape and size.

New Information :

The concept of new information is commonly associated with

originality and creativity, a precious domain of architects.

If we can accept that information has no inherent substance of its own,

and is brought into existence by the understanding of a person who
either generates or receives it, then the newness of information will be
determined by its relationship to the familiar experience of people who
perceive it. Thus if it is unfamiliar it is new.

Further, if recognition of information is dependent on the association

of its constituent parts with familiar experience of the person who
perceives it, then the recognisable parts of a presentation of
information can not be new (c. f. parts and linkages). This means

437
that it is the varied association of familiar parts which must produce
new information; it is the linkages, or relationships, of one part of
information to another which is able to convey the characteristic of
newness.

The identification of what is new in information is necessary, as it is

the newness contained in any transmission of information which needs
to be explicit, and it is the newness which must provide the reason for
transmitting it at all.
If newness is contained in the linkages between the constituent parts of
a presentation of information, then it is these linkages which need to
be precisely explicit in the form of presentation; to convey geometric
or other topology.

Levels of information:

This may be used as a measure of consistency with which information

relates to a particular context in which the receiver of information
operates {c. f. complexity}. Thus information which is aimed at an
overall major objective, such as a new building, may be organised
into different levels which recognise the kind of comprehension
available to each person who receives it :

e. g. design drawings, architect to client

general arrangement, " " " and consultants
detail working drawings, " " builder
working details, " "joiner, or plumber
etc.

Where levels of information are used to achieve an overall major

objective, directed at a variety of people with different capacities,
then these levels must be precisely structured into a sequence ~ich
anticipates linkages between one level and another, in order to arrive
at a required concerted effort.

Information categories:

Categories identify different kinds of information, according to the

different ways in which each might appropriately be presented. At
anyone level of operation, within a known context, a number of
useful categories are evident:

438
e. g. Bits, or parts, of information already known to
the person generating and the person receiving
information; requires identifiers or addresses to
establish which particular bit is being referred to.

Linkages, or topology, which describes the

relationship of one bit of information to anothe r;
requires a description which will fit into a common
logic structure.

Geometric topology, which describes the location

in space of one object, or activity, in relation to
a nother; conveniently represented in graphic form.

Familiar and stable information, which may refe r to

both bits and linkages, is easily recognisable to the
people involved, and may produce abreviated
descriptive conventions; requires simple identifiers.

New and changing information, will refer to new

arrangements of linkages between familiar bits of
information; requires precise description within a
common logic structure.

ARCHITECTURAL PRACTICE

In architectural practice a number of particular circumstances exist

which influence the way in which information can be conveniently
handled.

Architect's presentation of information:

An architect's presentation of information usually consists of an

assembly of previously known bits of information, which make up a
proposal, or instructions, for a new building. The newness and
relevance of a particular pre sentation exists in the relationship of one
bit of information to another; its presence, location, and physical
fit. In detail considerations, this may include shape; a new
relationship of one surface to another which encloses a specified

439
ITlaterial. This aITlounts to the geoITletric topology of or between
objects, or activities.

The different bits of known inforITlation contained in the asseITlblage

are identified by the use of conventions which are faITliliar to all the
people involved. The convention enables each person to recall the
particular inforITlation which is being referred to.

Relationships other than geoITletric topology are recognised, such as

those relating to the cost of construction and ITlaintenance, affects on
the therITlal environITlent, or the achieveITlent of structural stability;
but these are usually subordinate and dependent on SOITle prior
definition of geoITletric topology. Detail work on these other
relationships is often carried out by people other than architeCts, such
as quantity surveyors, and services and structural engineers, who
should work in close association.

The general predoITlinance of geoITletric topology, as the ITleaningful

content in an architect's pre sentation of inforITlation, is the basis for
all architects' dependence on graphics. This is true of the past, and
is likely to continue in the future. Thus if cOITlputer applications are
to becoITle generally assiITlilated into architectural practice, the
developITlent of suitable computer graphic facilities is essential.

Storage and recall of information:

Architects are professionally involved with a large variety of people,

each with diverse ITlotives and ability.

Client bodies are often unfaITliliar with the process of putting up new
buildings, but ITlay have detailed knowledge about their own specialised
activity, probably conditioned by their experience of ope rating in an
unsatisfactory old building. They will want to acquire the "best" new
building, but may be in a poor position to visualise what they are going
to get.

Specialist consultants will know a lot about their own particular

speciality, but little about the interaction of their work with other
aspects of building. They will wish to give effect to their own
profe s sional competence.

440
Production organisations may have general knowledge covering the
construction of whole buildings, i. e. contractors, or they may have
specific knowledge associated with various trades, i. e. subcontractors
or suppliers. In every case they must be primarily concerned with
staying in business.

Over all this, government departrrlents set standards and exercise

control over local or national economy; In response to politically
motivated directives.

This re sults in a great variety of information Wl ich needs to be

available to architects, with a wide range of coverage rather than a
concentration on any specialised knowledge. The store of information
is required to be large, with any parts of the store accessible
simultaneously in many permutations, to meet the requirements of a
particular problem.

Interdependence and interaction:

Because of the large variety of people involved in building, each with

their own opportunity to influence the decisions affecting the design of
a new building, it is very difficult to isolate specific problems within a
defined and restricted context. Problems are not readily capable of
separate solution.

Consequently, it is difficult to divide up the whole activity of building

into a predetermined sequence of separate steps, by which one might
progress in orderly stages towards a new building. Early decisions
are often reversed by later ones. Information which should reasonably
form the basis for decisions may not be known to exist until after these
decisions have had to be taken.

It is difficult to establish a predetermined sequence of dependence for

gene ral application, and which can be practiced with a sufficient degree
of confidence. The dependence of one piece ci information on another
may be upset by the unexpected existence of a third, requiring
subsequent looping back through any information handling system.

Thus in any methodical approach to handling information, an architect

needs to be able to enter at any point, at any time, to revise the data
and manipulate the data structure. The architect must be able to
interact with the system.

441
 Sortations :

Again, because of the large number of people who are associated with
architects during a building project, with varying capabilities and
desires, information has to be provided at various leva. s of specificacy.
The intentions of an architect's communications may have to range from
persuasive impressions to precise instructions.
Thus related information put out by architects may take the form of:

e. g. Outline sketch proposals, perhaps highlighting

particular points of interest to the client.

Written specifications, bills of quantities, or

schedules sorted under building elements,
activities, etc.; which may be used for price
comparison, ordering, or measurement of
progres s on a building site.

Working drawings and details, providing precise

instructions for assembling a new building.

Information content, referring to the same basic data, varies

with each pres entation. An architect's ability for handling
information must include the facility for ordering the various
appropriate sortations.

REQUIREMENTS OF A COMPUTING SYSTEM

If the foregoing characteristics associated with handling information

in architectural practice is related to an anticipation of computer
applications, a number of consequences should now be evident.

Computer facilities must provide graphic input and output to a central

processor, with large information storage capacity. The whole
system must respond to rapid interaction by the user.

For graphics input and output to convey useful information through a

computing system it must conform to the data recognition capability
of a computer, as well as be recognisable to the user. Computers
must receive information in bits, each with pre specified relevance,
which can be compiled within a system to represent a whole assembly

442
of data. In current architectural practice, architects present
information by drawing lines; each bit of line on its own conveying
little information to anybody other than the person doing the drawing.
It is only as the drawing develops that its information content becomes
more meaningful. The hand drawn information does not have to make
sense until the drawing is complete.

The conventions by which architects use graphics to refer to

information need to be modified, in order to provide suitable input and
output to a computing system. A comparison might be made with
alphanumeric conventions, where the individual characters can be
assembled selectively to convey specific information. Graphic
conventions can be made to consist of separate elements of pre-
specified significance which could similarly be assembled to convey
new and complex data. In this way a useful "grammar" for graphics
should be devised.

The general data handling capability of computers is usually

dependent on a precise and predetermined logic structure, so that it
will make sense of any data it receives. In architectural practice
a similar methodical approach to handling information is sometime s
attempted; but rules are often broken. Where information passes
between understanding people the method may appear to survive, but
where information passes to a computer any violated rules will cause
a failure of the system. In applying computers to architectural
practice, it is necessary to reassess our use of familiar information
structures, so that these may be modified to fit a computer's data
structure; specifying those areas of architectural activity which can
best be handled by user interaction with a computing system.

AN APPLICATION OF COMPUTER GRAPHICS

At the Architecture Research Unit, we are now engaged on a research

project, to develop the application of computers as a comprehensive
aid to architectural practice. A general description of context and
objectives is included in this paper.

The context of our computer application is provided by the Scottish

Special Housing Association (SSHA). Producing approximately 5000

443
houses per year, this is the largest house building organisation in
Scotland. It designs, builds, manages and maintains houses;
usually on behalf of local authorities. Most of this housing consists
of two-storey terraces, built of "No-fines" concrete, though the total
output includes single and multi-storey houses and flats, and includee
brick construction.

For the initial two years of our work we have decided to restrict our
concern to SSHA two-storey terrace houses. A computer
application suited to this form of building should be capable of later
expansion to cover the remaining building forms.

The SSHA foresee probable areas of benefit which should follow their
application of computers. At present changing conditions and
requirements associated with new projects results in approximately
half of their architectural staff's design time being occupied with
modifying and updating existing ranges of house plans, for re-use on
new contracts. Checking for compliance with design standards, and
regulations, could be facilitated by easy access to predetermined
computer routines. Design alterations could be fed into a program
to check for consequences on construction, thermal environment,
daylighting and other design properties. Cost information should be
accessible at all stages during design, and could be continually
updated by new information received from building operations.
Computer output in the form of printed bills of quantities, ordering
schedules, and intelligible working drawings, should further reduce
the workload on professional staff and will provide practical benefit
towards costing and organisation of house production.
We have a range of computer equipment available within other
University departments, and are using a Digital Equipment
Corporation PDP 7 and 340 display with light pen belonging to
Dr. Oldfield's CAD Project Unit, linked to an Elliott 4130 with disc
backing of the Department of Machine Intelligence and Perception.
Hard copy output is obtained from a Calcomp 563 incremental plotter.
Probable links with the Edinburgh Regional Computing Centre's
System 4/75, and the use of an ARDs direct view storage tube are beir
explored. We are at present testing the use of an on-line Teletype
terminal within our Unit, linked to Systemshare, as a cheap form of
computer access for interactive program development.

Our first task has been to consider current use of graphics by

architects, and more particularly by the SSHA, in order to devise new
and acceptable conventions which would be suitable as computer

444
graphics input and output. This task has been complicated by the
hesitant change from imperial to me tric measures taking place in
architectural practice, which is accompanied by attempts at
introducing dimensional coordination. We have tried to discove r some
useful logic behind these new developments, in order to formulate a
discipline on which to base our own proposals.

We have arrived at a re stricted range of graphic elements which can

be used to show the location of building fabric. These can be placed
in 300 mm or 100 mm grid zones, on the CRT screen, and can be
stretched to represent different lengths of walling, doors or windows.
The inse rtion of material components within graphic elements is
input to the computer by the user selecting options which appear as
menus on the screen. The precise relationship of material
specification, its form and location, to the graphic element, has still
to be resolved; and is hampered by indecision on the same issue
involved in the change to dimensionally coordinated but uncomputerised
practice.

A second and major task is to organise all non-graphic information

into some structure which can be held, and processed, by a computer.
This is necessary if any useful computer applications are to be
carried out on the graphics input.

Our approach to data structures has been to distinguish between

different principal computer functions. These differences are used
to distinguish between the requirements of different data structures.
Each separate structure is developed to interrelate with the others
but each is suited to its own particular function. So far we have been
working on distinctions between a graphics data structure (GDS),
an applications data structure (ADS), and a file handling system
(LIBRARY).

The GDS notes the way in which points and lines come together on the
screen, to represent meaningful information to the user. It stores
the relationships between the points and lines, and the relationships
between walls, windows, doors, rooms and surfaces which these
represent; to which the user may want to attach other non-graphic
information.
The ADS holds the computer's pool of information which is received
from the user, and is interpreted by reference to a permanent file
of information stored on magnetic tape or disc. This pool of
information, which grows as the user builds up a design, is

445
structured in terms of accommodation zones (floors), spaces (rooms),
components (walls, windows, doors), surfaces and junctions. The
ADS has to note the relationships which exist between these items, and
has to relate incoming information from the user to a corresponding
stored item or group of items.

The computer has constantly to compare information received from

the user with that already stored in its LIBRARY, e. g. comparing
component junctions with known working detail specifications. It
also sends information taken from the LIBRARY and qualified by the
ADS, to the user, e. g. ranges of options for material specification
displayed on the c. r. t. sc reen.

A request by the user to give or receive information is usually

initiated by the user indicating a point on the display. The computer
uses the GDS to identify which item, or group of items, in the ADS is
being referred to. The computer then uses its immediate experience
(the ADS) and its LIBRARY to interpret the request, and supply or
store the information relevant to the request.

When fully developed we expect to have a system of using computer

facilities which will save architects' time on working out routine and
complex computational aspects of design. allow rapid interactive
access to information, with facilities for updating, and the system
should prove useful in costing and organisation of house production.

446
447
~

~
6500 J::~:=J A
}400 } /800 J 800 oJ 900 ..,k 800~} 1300 I J 600,.,k

--, r--

o
11 - 'TO 900 '10
, 9.30
~

~---. t-
J L--
~ STORE
KITCHEN / DINING ~I I
~
{ii.
~---&:'. .- f2
Ui -.,..

~
1...11 HEATER: PRAM
~ STORE 2130 STORE /500'15 ,CUPB'D~/3Llfl3'£ 1'100 STORE

~
.~ Jj-{;-
I ~; ~ i
S7AJI!.
i I .~/
~~
SE~re
I NOI
I i
architectural graphics produced by hand
 A GENERALISED PROGRAM FOR
TRANSFORMING RELATIONSHIP VALUES
INTO PLAN LAYOUTS

A. Bernholtz and S. Fosburg

Laboratory for Computer Graphics and Spatial Analysis,

Graduate School of Design, Harvard University,
Camhridge, Mass. 02138, U.S.A.

Expansion of the original IWMOR* program was made

possible by a grant from Perkins and Hill, Architects,
\,/hi te Plains, New York. Mr. Howard Jus ter and Lv1r.
David Ginsberg represented Perkins and Will on the
Project.
Some of the basic features of LOKAT are listed below:
Built-in constraints. Zoning codes and physical site features
may be considered as built-in constraints by the program.
Predetermined solutions such as doubly-loaded corridors, and
layout constraints which occur on subsequent levels as soon
as, say, an elevator is located on anyone level also come
under this heading.
Lv1anipulation of units. A unit is basically considered an
abstract quantity of a certain size. It may signify a room,
house, factory, courtyard or even areas defined generically
as sleeping, dining, circulation etc. etc. These units are
moved about in an attempt to satisfy the relationships which
exist between units. These relationships exist on a scale of
say, one to nine with nine being a forced relationship. The
degree of being compelled to be together diminishes with the
numerical values assigned.
Kinds of units. There are two types of units; those which aJ:
assigned fixed positions in all plans produced by LOKAT, and
those whose position may change from plan to plan. On a give
site these fixed conditions may be area set backs. These
fixed conditions may alternatively be elevator shafts or duct
spaces.

*RULv10R - developed at the Harvard Graduate School of

Design, Laboratory for Computer Graphics and Spatial
Analysis and Department of Architecture by Allen
Bernholtz.

449
Shape of units. units may be square, rectangular, circular,
elliptical etc. At the moment the program uses the two former
shapes.
Maximum Number of units. Currently on the IBM 7094 the program
can manipulate forty different units using internal memory only.
However if say we have thirty patient bedrooms and we do not
consider each bedroom a different unit the program can manipu-
late 400 units each having its unique symbolism. This means
that although the thirty bedrooms counted as only one unit
toward the total of forty units, in the plans produced all of
the several patient rooms would be produced.
There are problems of scale at various stages of th.e design
which allow the effective flexibility of the program to be
increased. Using a hospital as example initially in the early
gross stages of the program the overall hospital could be
broken down into departments. As the job continues and more
information becomes available departments can be broken down
into sub-departments, then into rooms, then into furniture
units even as required.

Quantitative assessment of relevant criteria

To select the "good" plans the LOKAT program requires some
quantitative assessment of the relevant criteria. Sometimes
the data base is already in this form in terms of say staff
and patient movement between departments. If this data is
not available we can set up procedures for recording these
values.
In terms of aesthetics it is more difficult to set up measure-
ment procedures. However, it is possible to bring experience
factors and critical judgment into the picture. Thus we can
ask the involved personnel to assign numerical values to the
qualitative responses.
In a geometrical sense a limiting factor is that there are
only so many units that can be close to another specified unit.
Thus we tend to place those units with higher values in the
matrix closer together than those units with lower values.
The basic philosophy underlying the development of the LOKAT
program is that the designer alone cannot effectively deal with
the complexity of the problems currently facing him. As has
happened many times before in history the evolution of the
extensions of man coincide with the need for them. In the
current context the development of the computer is seen as that
extension of man.

In the first stage of development the computer was viewed basic-

ally as an evaluative tool. Based on certain criteria such as

450
proximity or circulation a given plan solution could be scored.
However, the plans that were being scored were generated random-
ly by the computer. 'l'hus it might be possible to generate,
say, a million plans, none of which a designer might describe
as "good". This method was quickly discarded. It did prove
useful in showing that solutions, albeit not necessarily satis-
factory ones, could be readily machine generated even on the
basis of little or no data.

'l'he next phase was to produce only "good" plans or at least

those better than average. That is, at least fifty percent of
the plans were to be rejected by the computer as not even worth
printing out. 'rhe problems then becomes to set up "measures
of goodness". Traditionally architectural design relies
heavily on the intuitive process as does any creative pro-
fession. But the intuitive scheme in design is accepted as
being also rationally and analytically correct. In addition
little, if any, systematic work has been undertaken to codify
the results of previous intuitive design decisions. No
design data banks exist upon which to build.

The program called "LOKAT" attempts simultaneously to exploit

the results of intuitive and empirical experience and make them
available in an explicit fashion. At the same time it permits
designers, clients, contractors, and administrators to build
up decision tables of the trade-offs they are willing to accept
in a planning situation. These tables or matrices in turn
functicn as the measure of goodness or desirability which the
computer uses to generate "good" solutions. The machine is
then able to evaluate solutions based not only on criteria of
proximity, weighted averages and the like, but also on their
ability to satisfy the input values which generated the sol-
utions. 'l'hus LOKA'f can be saio to generate "good" arrangements
based on both qualitative and quantitative measures. The
program is completely general in that it can be applied on the
scale, say, of a house, a hospital complex, a neighbourhood
or a region. It is also general in the sense that "rooms" may
be located in a completely random fashion as in the earliest
version, in a completely constrained (deterministic) fashion
or any mix of the above two extremes.
\vhile the completely constrained format adds little to the
value of using the computer for solution generation it is of
great use as an assessment technique for 1) previous solutions
and 2)completely intuitive solutions.
'llhe program, in effect, allows you to score finished solutions
if one knows the relationships which determined its evolution.
'l'hese can then be compared with the computer solutions to assess
the relative qualities of each.

451
Preciseness of Judgments. Our ability to define a precise
numerical relationship between units varies with the stage of
the job, the quality of data and information, and even with the
actual degree of precision which is useful. We choose a scale
of values to reflect the degree of preciseness. This may
range from one to three, one to ten or in some exceptional
cases even one to 100. Ideally one should use the most precise
scale possible since the more precise the distinctions are in
scale the better LOKAT will be in producing "good" plans.
The program as presently devised then standardizes all matrix
values on a scale of one to ten.

Outlines. Initially a rectangular border is set up for each

plan. However, it often occurs that we must deal with a)
an irregularly shaped site, b) zoning restrictions, c) bodies
of water crossing the property, d)internal courts and, e) corr-
idors, f) elevators etc.
If this occurs certain constraints may be placed on the LOKAT
output. This involves reserving certain areas to reflect the
above limitations. If then a portion of the site is blocked
out as river, this constraint prevents the locating of building
on the river. If the nature of the problem permits building
over the river then of course the constraints can be wholly or
partially removed.

Disposition of units. The size and shape of the border or

outline (which corresponds to, 1) site extremities or 2) build-
ing extremities or departmental extremities all in a physical
sense) the number and size of units and the input matrices
of relationships are used to generate plans. The relationships
described in the input matrices may be functional, proximal,
circulation or even aesthetic relationships.

General Program Procedure. After the outline is determined

the constraints of irregularity, natural features and predeter-
mined location are fixed.

units that are NOT fixed are entered into the plan depending on
their relationship to each other and with the areas already
fixed.

If N signifies the Nth unit entered into the plan, then the
N+l unit will be placed next to the Nth. As a function of
this LOKAT checks the input matrices and chooses the N + 1st
room so that there is a high degree of relationship to the Nth.
If this did not occur LOKAT would, in effect, operate entirely
at random. Thus half the plans that would be generated would
be worse than average resulting in a great waste of time and
money. By using the input matrices which represent our best

452
knowledge of a job at any given moment we are able to produce
better plans in fewer trials.
The N+lst unit is generally placed next to the Nth at a random
location around the perimeter of the Nth. This placement is
constrained if another unit already occupies some of this space.
It may also be constrained if its location has the restriction
of adhering to a northern boundary, for example, or to a
corridor or courtyard.
If no empty space is available around the Nth unit, LOKAT
begins to back up looking for space around the N - 1st, the
N - 2nd etc. When a space is found, if indeed it is, the
space available must permit placement to satisfy the best
matrix relationship available, If this possibility does not
exist or if sufficient empty space does not exist for the size
of room being consiuered, the unit is then ignored, and noted
in the printout. '1'he program then moves to the next uni t which
may be located by virtue of its mnaller size.

The option exists for the user to state what the first unit to
be entered is or in what specific order units are to be added.
In this case the plans generated do not depend upon the input
matrices and the values in these matrices are reflected only
in the subsequent plan evaluations.
If a group of units are to remain adjacent to each other for
some reason they can be entered intact throughout the procedure.

LOKAT Evaluation Procedures

Since LOKAT doesn't produce a "best" plan we need some relative-
ly simple means of deciding upon which plans to save for print-
ing out. Basically the procedure for accomplishing this is
a set of scores which measure the success of a plan in satis-
fying its input criteria. Several scores are necessary in that
in general the set of criteria are complex and no single
score can represent, except in a superficial way, the success
of a plan.

For each criterion there is an input matrix. Thus to see how

well a plan has satisfied that criterion there should be at
least one score corresponding to each matrix. If any criterion
is not satisfied then the plan can be discarded. On the other
hand, if every condition is at least minimally satisfied then
in comparing two plans the two sets of scores must be compared.
It is important to decide which criteria are more important
and which less important. If we weighted each score by the
importance of the criterion it measured and added up these
weighted scores then there would be one summary score for the
plan. This would make choosing the better plan simpler but
it means sacrificing some of the available information.

453
 The scores are computed so that the best value of the score is
one. Any higher value is worse. The user however, must have
some experience using the program to see how close to one the
scores are likely to get. Since the scores are standardized
a difference of .1 may be significant. (On a scale of 100 a
difference of 10 miqht be the equivalent.)
Implicit in the scoring mechanism is the notion that the better
plans are those in which the units are less spread out, i.e.,
the sum of the distances of all the units from a central point
in the plan is relatively small. 'l'here is an option in LOKAT
which computes a similar score without regard to how diffuse
the total plan is.
Another set of optional scores are available. These are used
when the input matrix is derived from a ranking scheme. The
idea of the score is to demonstrate how well or how poorly
a plan succeeds in satisfying each of the possible rankings.

For example assume the values in the input matrix are one
through five, in which one signifies that the rooms should
be close, five far apart. The scoring system records how
many of the pairs having a II one II ranking were adjacent in the
plan. It records how many of the pairs having one through five
relations were very close but not adjacent. It records how
many of the pairs having one through five relations were at
a middle distance from each other, etc. One would expect that
in a good plan the pairs having a one and two relationship
Would tend to be adjacent or close and that the pairs having
a four and five relation would tend to be further apart.

with respect to all of the above scores it must be remembered

that the scoring can never be more accurate than the input
matrices. If these were in themselves gross assessments then
the scores will reflect this. with this in mind it may be
necessary after reviewing the scores to revise the input
matrices as better data and criteria become available. It is
only after seeing the plans that are produced by different sets
of criteria that one can get any appreciation for the effect
a change in the input matrices makes on the output.

APPENDIX A: A discussion of the program algorithm

LOKAT manipulates abstract units which are defined in so far as
concerns the program by a symmetric matrix (or a series of
symmetric matrices). Each element in the matrix defines the
relationship between a pair of units. The diagonal
theoretically would define the relation of a unit to itself. In
actuality the program uses this to deal with the case in which
several identical units are to be located. The numbers in the
matrix give the strengths of the relations between the units.

454
For twenty-five different units a twenty-five by twenty-five
matrix is used.
If the final position of the units were completely determined
by the input matrix and if there were a single mathematical
measure to be optimized mathematical methods could be used to
obtain the single "best" solution or plan. However, this is
not the case. In practice as has been indicated above in the
text additional constraints are used, as for example giving
units a fixed location, having an outline of fixed shape etc.
In addition even the numbers in the matrix are not always
used consistently. Ordinarily the larger the value in the
matrix the stronger the unit to unit relation should be. It
has been mentioned, however, that a nine value can be used as
a forced relation. That is, if a pair of units have this
relationship they must be located adjacent to one another
in the final plan.-~is requires special handling in the
algorithm as it is very different from, say, a relationship
value of 8.99.

Given these constraints the simplest computer solution to the

problem is to generate within a given outline completely
random arrangements of units. These units may then be moved
and shifted in subsequent "solutions". Aside from the fact
that this is like waiting for a group of chimpanzees to type
"HamIel" somewhere in the midst of their gibberish it is
expecting too much of the computer. VIi th a large number of
units the number of possible arrangements becomes too large
even for a computer to handle economically. It is the object
of LOKAT to bring the number of plans generated within
reasonable bounds. Among the few "chosen" plans we can use
LOKA'r's evaluative procedures to determine the "best" plan or
plans.

The way in which LOKAT reduces the amount of randomness is by

taking account of the matrix values. It does so in the
following manner. A unit is chosen with which to begin. This
can be completely at random or be a unit of choice. It is
sometimes advantageous if one unit is much bigger than all of
the others to begin with this one. The chosen unit is located
at random in the outline. It may not overlap any portion
of the outline but it may overlap on its edges some previously
fixed units. (The previously fixed units may be corridors,
elevators, shafts, stair wells etc.)

Once this unit is placed the next unit is chosen from among
those units that have favorable relations with the unit just
placed. The more favorable the relation the more likely
the unit is to be chosen. An element of randomness is used
here in that the element with the strongest relation is not
invariably chosen. However, if there is a nine relation to

455
the unit just placed the unit is invariably chosen.
Having chosen the next unit it remains to place the unit in the
plan. The procedure followed is to draw an imaginary line
around the previous unit at a distance chosen so that if the
centroid of the new room is placed on it the two rooms will
be adjacent. This path is checked to see if some of the
path is already occupied by previously located units.
Positions along the path are not available for location of
the next unit if the placement of the new unit overlaps the
previous units. (In practice a small amount of overlap is
allowed. Note that the program is not set up simply to
fill space. It is assumed that there will be final
incremental adjustments to the computer plans allowing for
corridors if they have not been included and final adjustments
to the shapes of rooms, etc.) All the positions along the
path that remain after the computer search can then be
chosen with equal probability as the location of the
centroid of the new unit. If there is no space available the
computer backs up and looks for space around the previously
located unit. The computer goes on in this manner until
some room is found and a unit is located or no room is found
and the computer types a message to that effect.
After this unit is located the next unit is chosen and located
just as the present one was. Hhen a unit has no good
relations left among the units yet to be located a less
good relationship is used.
This method yields a series of random plans but random within
the far more restricted sphere of reasonable unit to unit
relations. ~Vi thin this framework far fewer plans must be
generated and examined to find the excellent ones. In
practice, as a current rule of thumb using twenty-five
units and generating ten plans from the relationships we are
able to find one or two excellent solutions. Computer time
expenditures for the generation of ten alternatives is about
twenty dollars.

456
 ".
J .)l-" , RUlI"
~?t~
~ J~ ~ C). IR,J1"'f~ IrIU"6f~

"
S'''6:JL RfPlllfl'lNS

,., .,., 'A

'" .,.,
·to
."
'/0 f~ TI ~I'fl IU.JI( A
'Afluff ",XlI( II
'"
"
lOJ ., .J
'10
l~
,... " .... ,
P""Il:...,
I'Ult~'
"cJu~
',JlLtr;
kJ)" ,
L

-;r,
t~ ,
pAtI ~NT IU_"

,~
!:

.,.,
·10
.,
'All:: ... , ~ "n.J" ~

<u"- '''''llH'
IIIU"IT~
IcJIU
lU",rRLJl
r~

j~ .,
"

.,
" "0
U'M·

i'ou'"
(.H4 ... 11""
"'€illl.._'IL'')
~t~~~'~"~~rA~
.,.,
,,~

~l ,,~
M~~, I~~ '~lt~o"'''
, .,., ., ~tC, .,lTllIll,\ .ulltU

.,
" Hell ~ IN" • ~J [I'~~f~r

.,.,
i1ulJI"C. hhlIP£i'tt~r

.,.,
Hut )1;.... ') , .. ETl..l1b~)
", f"-t T" I1E~

;11
"hJl"l~ ~ ~

"~ I .,., .,'

t"',J1<
l-"U.J
LUoC"EII.)
lu(.o(tll, ~~nG~~
., ,"
I" L''''t lLi"lf ~R<
~~l

"
'!C
~~ Ib~
'1
T~t.H!o.t"T
fhh"'NLr

"
~ J J'" '> Il, ~

"Room" Specifications

-------_._----_._--
",>1 ,1"" lFiLH [h'>

.. 'I, , 1 L $1
"
~J ~

~J<lb _.j.._~,~
I'l"''''~

,lA""
'" ~U!tH 1JH~"'T .,1,<.1)( ,

'.' , ..
,., II
•• 0
.~ l:g
'"' ,,' 1.0 '.J
t:8 t:g
l.O
I.' 1.0
1.0
1.0 1;3
5,0

~J
5.'
5.',.,
f~~ t:g ,., ~: 3 ,.,
,,,
,,0
~:g ,., ;.,
l:~
l.O
,.0 1.'
3.' (:a
1.0 1.0
1.0
1.0
'.0
'.0
3.0
3.0
>.0
;.0
1.0
1:8
I.'
1.0
1.0
}:8
1.0 E3 l:g
~~! 1: }.) t~ ,.,
~: g
:.0
~: g
1.' 1.' 1.0 1.0 1.0 1.0 I . ' I.' I.' 1.0 1.0 1.0 1.0 1.0 1.0 1.0 I.u

..,.,
I.'
1.0
, t~~
,.,
I
~ ~i
l.O
5.0 ,.0 '"'
'.0
,.0 II.U '.0 1.0 1.0
11.0 1.0 1.0
1.0 1.0 '.0
~ S.,
1.' ~:1
,,' "J
'.0
'.0 ..,
~; ~ l:g
.0
"0
1.' 1.0
1.) 1.0 i:g '" .,
3.0
'.0
1.0
1.0
\.0
1 .. 0
1.0
\:8
1.0
1.0
1.0
~:
3.J
g !:8
,,, ,.J
.. ,
•• 0 1.0 1.0 l.O 1.0 1.0 1.0 1.0 I.) 3.0 \.J 1.0 1.0 1.0 1.0 1.0

1.
\.0
1.J 1.') 1.0
?:~ 5.0
1.0 1.0 1.0 .J 5.)
l:g 1.0 1.0 .J '.0
i:3
1.0 1.0 •• 0

,., 1:8 ~~~

'.0 I.' .0 1.0 1.0
~:g ~:~ \:g t: I.' 1.0
1.0 .. 0 1.0 11.0 1.0 1.0 1.0 1.0

r
~ I.' '.J
t:~ ;.)
1.0 1.0
\., ;.0 1.0 1.0

H",',.J
.00
~: 8
,.0 1 1.0 11.U 1.0 I.J 1.0
1:8
I.' 1.0 3.' 1.0
,.,
<;.0 I.)
,.,
I.' 1.0 '.0 Ll.) I.J 1.0 /.0 1.0 /.0 .0 .0 1.0 1.0 1.0
t:3
L: 4:>0'~ ,.,
'.J • .J ~ 1.0 S.O 5.0 1.0 I.' 1.0 1.0 I.J ll.) 1.' .J .0 1.0 1.0 1.0 S.O 1.0

1:8 !:g
I.'
~:8 '.0 '.0 1.0 1.0 I.' 1.0 loJ I.)
,.,
S., 5.:! 1.0
I·.0J
'>0) I.' I.' '.0 1.0
lt~~
I.'
I" t:1
'.0 '.0 •• 0 I.' loJ l l . l 0.0 1.0 I . ' 1.0 1.0 .0 1.0 '.0 1.0

i!
l.'
'.J
l.O 3.0 3.0 .0 1.0 I.J
~ t: '.J 11.0 I.' 1.0 1.0 1.0 .0 1. 0 1.0 '.0 1.0
1.0 1.0 1.0 1.0 1.' 1.0 '.0 1.0 I.J
'.J t: 11.) 1.0 1.0
\:8 :2
~ ~ ~ f~ gi
1.0 .0 .0 1.0
~ 1.0

i
3.' I.'
j:8 l:g
t:~ t:I')
1.0
1.0 ,.,
1.0 1.0 1.0 t.;; I.) 11.0 1.0
i.J
I".0 3.0 1.0
~
!.o
1.0 3.0 /.0
1.0 1.0 1.0 I.' I.J ,.J I.' I.J I.' ll.O 1.0 .0 '.0
3.0 ~ :g
"t~" t:3
,.0 l.O J.o 1.0 I.) 1.0 1.0
~. a
I.J 1.0 I., 1.0 1.0 11.0
11:8 1.0
1.0 1.0 1.0 I.J 1.' 1.J
,., .. 0 1."
1.0 1 :8
1.0 I.J 1.0 1.0 1.0 I.' ;.0 1.0 1.0

\:! ,., f:& I:l l.u

" ,., 1:8
;.0

'.:8
l.'J ~ • 0 1.0 1.0 I.' 1.0 1.0 I.J I.J I.J 1.0 1.0 1.0 3.0 1.0 1.0

., ,.,
l.O 1.0 1.0 1.0 '.0 I.J 10> 1.0 1.0 1.0 1.0 ;.0
~ :~ ~: E ~: ~ '.0 '.0 1.0 I.' 1.0
\:8 \.,
I.' 1.0 '.J
1.0 I.J 'oJ
'"'
,.J -;.) ~. 1..,
0 3.0 ;.0
J.'
11.0 l.O
"
• d .. I1'I~~ tAI..TH
~J J,",~
"J
~()'I>l ,
1.0 :..0 '.0 l.O 1.0
JdTotlX Nu • I IS o.h~') 1.0 1.0 1.0 I.' I.J I., 1.0 1.0 '.0 5.0 .0 '.0 11.0

i't~Vl ~~~ T ",,~RU:

" "
I I

":.J
I.J
1.0
,., t:g
11:3 II.()
i.O .. ') 1.0
I.'
1.0
I.'1:8 1.0 I.' 1.0
1.0 1.0 1.0 ~:e
s.n ,., >0' 5.0
~: ~ 5.'
,.)
3.'
'"0
3.0
1.0
1.0 I.'
1.0 5.0
l.O 1..00 1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
I.'

.... , ~:~
,.1 s.o
I.' 1.0
1.0 1.0 1.0
I.' 1.0 I.'
1.0 1.0 1.0 '.J
1.0 1.0 1.0 I.J loJ
,.J S.J '.0 1.0 1.0 '.0 3.0
1:8 \.0 1.0 1.0 I.J

,., ~:~
I.J ;.0
~: 8
..i:5,
I.J I.J 1.0
I.' I.' 1.0 .0
I" l.O 1.0
,
•• J 1.0 l,G 1.0 1.0 1.0 1.0 5.J >oJ S., ).J 1.J 1.0 l.O
i:~ ;.0 1.0 1.0
1..,
.0 1.0 1.0
~:g
,, ••,.,
1.0 H.O :.0 1.0 1.0 ,.0
1 I.J 1.0 1.0 1.0 1.0 11.0
•• 0
1.0 1.0 I.' '.J 5.'
'.0
'.J I.J
3.0
).0
1.'
1,)
1.0
1.0
'"0
).0 3.0
\.0
.0
1.0
1.0 I·
.0J
I.'
1.0
0

.. J,
I.)
\.0 1.
t~ ::3 ~i~ ;:2
.. 0 •• 0 1.0 1.0
1.0 1.0
1.0 1.0 1.0 1.0 I.J I.J I.' 1.0 \.J I.' 1.0
1:8 1.0 1.0 0 1.0

.,
1.0 11.0 1.0 I.J I.' I.J 1.0 1.0 .J
"" 1.0 10> 1.0 1.<J11.0 I.J l:~
I.J 1.0
I"I.'
1.0
\.,
1.0 .0 1.0 1.0 .0 1.0

,.,
I.' I.J 1.0 1.0 1.0 1.0

1. !.o
1.0
r,.)

~:3
,.0 I.' ,.0
1.0 ,.0 1.0 I t . ) 1.0
1.0 1.0 It,)
loJ
!:~
I.)
'.J
I.J
1.0
1.0
1.0
\.0
.0
1.0
.0 1.0 1.0
1.
I.'
0 1.0 l.O 5.0

\ji
1.0
t{
" 5.'
", t:g n.} I.' 1. .0 1.0 1.0 '.0

..
" . ,
'.0 5.0 1.0 1.0 10> I.) I.)
I":g 1..,
'.0 I.)
,.,
I.J 1.0 0 .0 1.0 1.0 5.0
t:g
'.0
:2 ~: g I.' 11.J s.o 0
,., ,.,
1.0 I.J I.J I.J
~
loJ 1.0 1.0.0
~:
.0 .0
g 1.0 1.0 0 'oJ '.0
'"'
1.0 1.0 1.0 5.' I.) 5.' 11.3 1.0

1: 8 t:8
I.' I.' .0 1.0 1.0

tf
l.O '.0 '.0
1.' 1:8
) l.O 1.0

!"'
I.' I.' '.J 11.0 1.0 1.0 1.0
1. ~
1. '.J t:~
1.0 1.0 1.0 1.' 1.0 I.' I.'
I.' I.'
I.J 1.0 Ll.J 1.0 1.0
1.0 5.' 5.0
1.
.,
I.' .0 3.0

!: ~ ~:,.,~ }:g l:~ '" '.0 ,., l:3 t:3

0
,.0 J.O 1.0 1.u 1.0 I.J .0 1.1 I.J I.)
I" t· :g P
0

t:
I.J 11.0 .0

H 1. .JJ
.0
., !.o.0
).J .0

f: ~ m
'.0 1.0 1.0 I.' .0
~ 11:&
0 I.' \.0 I[:! [.0
'.0 .J
l:g ~:g
g~
I.' I.' I.' .0 .0
~ :~
IH~ It;g d:8 I:S
~. )
'.0 I.J 1.0 1.0 I.) 1.0 1.0
n 1.0 1.0 1.0 1.0
., t:g t: 1.0
.,
1.0 1.0 1.0 I.J I.)
i:g ~:g I"'.0 1..,
, l:g o.hgz
t:~ I.'
g~ ~ }:~
g~
,.0 0
,.,
I.' 1.0
H
~S
1.1
I. )
I.J I.'
I.'
1.0 1.0 1.0 ,.0
[.0
I.J I.'
<.J
!.J
~:~ .0 ~:g
::~
I"
,., .0
1.0 11.3 I.'
~lt?H >0" ~.i.~,q~'~u. ~.O
I.' 1.0 '.0 '.0 '.0 I.' 1.0 I.' 1.0 11.)
"
HI(.IHP'"
P~IV ACT
'"
I
CO .. UDl
2 , Vll='I>IG,

typical input matrices

figure no. 1

457
 -typical scheme
generated by matrix
input illustrated on
fig. no. 1
-no corridors have been
included in an effort to
reduce form biases
i
~ ____ • ____ X____ +____ • ___ +-___ lI ____ • ___ X___ • ___ J. _ _ " ' __ II __ -t---x--_ ...___ x__ • __..... x____ -~_J~

r ~T 'i.:lll< . . . '" ", r, IX l<G.

, ~t >... H.~ ,," IMl,.!). "",,.
1 ,,1 _;:; Ie ~ ', ... ~ f'.'::w;. iii.....
I. >1 ,_ ~ .. Il",,-,~ ,,,, "'''t." .. L.~f\oG "'HI(.;;!>
1101'oC~l"G lC.UT ."PUT MATIIU "'LUU,
IG,.UlfriG LU.rSl INPUT IIIATtlJJ. VALUeS

l ; r ".;,,,. JGh~lfrlt. L'IoEST 1,,'U1 MATRlll VAlUtS

, _T ~,_.,,~ dL;'I-G ~" .. v~~ .. GlflG i'I"l~IC s

.... nu .....

. ".
f,~ ~

,OJ''''' _~h", u Hi rHi: FOllUHhG ()~OLJ;, AU .. '''If. CHU.NU-Sllt &AnO

.. .."
'" IIhl
l.e-... , 4.5-6.0 .." o. ,.Olll
"""f ROO" (.UH"uHI$ !.G-l.S I.t-3.e
•
::."
~OC ..
"
!:I-!iI
U

.."" "
.2 ~JU"
,
.. .. ..
~ :~~~I ~Alt\5 IT U
U ~~l.P([)'II5"1"

" '"
H h

. II" II
"
.-2
• "
it i,
~~ ~
" II 12
",. Ii
I>
" .,"
..
:'
\,
21
t~~& 91 .". M"'lICUlfriU.
aDCM 'AIF. lustANU-SIli: ..... uv

..
~~
g "
·,:.· 1
T l.O-I.S 1.$-3.(1 1.0-4.5 4 ...... 0 6.0 O' lION:

:~
":.!"
.
I"UfoI'
,~,
t: 6 II

.."
J'
'l

I!
\lhS Plio;,,;:.

,1.
~I.o .. ,"

".
.'. 1I
II
11.:0
.6
=~~:HON:'"lP "
.,"'
t!~J .,
~ .6
J'
17
.~ ~
""
0"
"

1 .... -1.5
flCU .AI;I. DU"""'t-Sl1c lIint.:

,
'.5-,J.e
,
'.0-"" ... ~.o
.
•• \1
0
Ck "'....

..
U U U

figure no. 2 " 10

458
 This example illustrates
an actual architectural
example (excluding
corridors) which has been
fed back through the
system for evaluation.
The scores and tables
below illustrate the
scoring systems .

..>, ~ T~ .,l. -- ~ rl ,. r '"

' .... ~ I.',

". L .... ,T ... uT " . ' ,., A V ~ LV .;

" ,,'U r ;--~. ~ •\ W~ L..> ..

. ~

lOt _!
• L.,
....
~

figure no. 3

459
-.-. .··.-------'111'

: ••• -t ____ ..........
-"plan" or "bubble-diagram"
layout including 'reserved'
area indicated by plus (+)
---l----t----J----+----I----.----. -.-- t-- --C ---- .----~ ___ a. ----X---- t- ••• " •••.••• " , . , ;
signs.

tQ$;PnAli ~TUtn - IHU/IIISIVE tAU, UHf

TUT " - u. ... U. y.uUf 1 IS f JA;tD
I'l"H "Jotll:"

fbT St.J\t J j ''''''IX MU.

nH ... Hf ...... 4U~U. N.J.
'Eif "Cuit, .N ""lUI ",u.
TtSf ".H~ oASEC "III AYI:",,,,,ING ""kIClS
f )T iCjC<' h ~.nll NO. 'liHL;MINIio lOItfSr lI'If'UT MATlIn ""LJlS, -
fdf i:.lh IN 'uHUI 'u. 1,.,1Ot1 .... hllltST ' .... UT M"'"'' VALiolU
"MMI"(o LOI«:SI thI'UT MA"t.IX VALUES .0011 ••• " OISTANU-SlI.c .... no
e..0 uk ...."':

~~l~ :Aloh
HU.JI)"~til'
,,,~ R.JJ'I~ .tol.E E.'Ulli IN Hk FOLLOIIlr«; t;ItUItA

.. ...
S".tiJL II.W" NAME IhJull (,.~"'Il ... IO~
tOll" ",J.

,
··
"''J'" "
..."."",. n""
"'I,
i:
f
\I
~ ,,,no

..,
11, I.U-I.'
AOO .. ".,liII DIUlHt.f-'Ut
1.5-)'U 3.0-_.' _.'-•• U
;
I < l\
" "
Ii." .,,.""
,N'
II n
" ~J
1."'I ,.
It "'im
,." II". ..."" ,.." ..
II lJ II

..,....
II
II \ilf
,I••
H
"
~~
"11
II
t ... "
12 .,
I~

~"lJII' ' ' 1< DI st"frfCf-!o1l1 t"lL

~.J Jil. "JAt

I'-J 1" ~ 'I t '>

~UU;~~"I"
figure no. 4

460
 .-.... ., .................. ,
.................. ····1
...................
. '0
,,'
'.
~.,_-
", 10 - •• , -".,. -~ ••

· •• L-".I·"",·· ..... -I
,_...
................... ,,
, ................... .
................... "
....................
• ................... L
.................... ,
,

~~1;~~~1 ~j~~~~~i,
• .l' .. ,~I .......~.· ....... -..~._... •.................... ,

: c''. "...... ~!.,_"_,~. . [.·• ·• •.•.•.•·1 !i~~~~ll

:'", '.:'", '~-". ·E:~~~~~~~~~~~~fh~~~~ :~ ::: ' :.:.:.:: ~~~~~~~~~mm~~~~!
•• , • , • • • • • • • • ~ ...... ~~.,,~...... .~ l l , ~ ....................... ,

rJ~.··,·:·<.'c"~··i~m~~~~~~~~~~: : i~~<"<~<~<~ ~m~~m~m~m~i

, r\::2~::=~m~;~~~~g2=~ "!: ~,: :~ <: <: <: i ~~~mm~mmm
~:::::~::~::::::~:::::!::::::::::::::::::'~ . ~·:\:·<\:~<i ~~~~mmm~~m
[:~::::::~::::::::::~~~~;~~~;~~~;~~~;~~,/ /'lk:~ <, <. <. <: ~mmmm~~mm
,. ,. I. 1M I .... I .... ~I"'~. f • t t ..................... ,

~~<~~~~~<~~ f;~:::~;~~:\~\];L~~~'· .:" .:. .:',1 ~~~mmm~m~!

r' f:
t .:"

~~:~:~:!~::~~:::gg§;;::;;~;~;ili~~ 't t, 'f" ,.f·i ~~m~m~~~~~~;~~~

, ~:~~~~~:::~!:~~~~~~E?l~~~i~~ i'·~:' ..··I.\.·f! ~~~~~~m~mm~
f

I .~ .....u ......... a.;, ... ~ .... _ , _ " .... ~"... ""lillie Ill........................ ,
......... _~.lIIu.t." ........ V6lO~ .. ~U.... ~ .... ~ ........ ~ ... _ . . • "HI "til AlII.................... ,
I ••• _..............a. ..................................... ~,_~... .. .. 0 ...Il .......... n . . . . . . . . . . . .
• .......... _ d ...U .......................... _ . . . . . . . . . . . . . . . . . .

,I .......................... "'"'.,1...............
......... _"".u ....................
I ..............................u .. _""'''Il4IAlIII
•• , .. ....................,
• ... Mw 11&1,. _ . . _ .............. ~
l0iii.................... ,
"",._.1.o.AAl<......
_"'"'"""W'UO~

1 ..... _ . " ..... _
......._ ....................................
_'.11 .". .......................
_ .................. ,
. . .-.;..... I.u..................... _~
~ !
-example illustrating how

l~!~!l!~l~~!m~~g~~~jg~~m~mmjj~j~~~~~!~~;;;;;IIII!i!!!!!!!!~l
the program is able to
modify the site in
.....................................................................................................
,........................................................................................................ ,,,
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

.................................................................................................... response to physical or

,,....................................................................................................
................................................................... _ ................................. .,
.----. ---. ---.----.----.----.----.----.----0----.----0---.--.----. ________ .____ .____•. zoning conditions.

..,_.
.. u., ....... t
............ -

. "... , .......
,r"ln, .
~' •• I ...... ~

.....
...... .
t .. , . . . , ....... ..

, , .... ..,..
\I. . . . . . . . , ....

. . . . . _.h
"'h.'
....... u
,.u.JI ...
'"'..~ .
•• 11 •• ' ........ '
I .... ~

.....

..... ..
~,

.. 1I~1I1o~ - $~"H
.1I~i1 .. ~ - .U'"
,~
l~t
.,~&.. -
.-.,1..,
.. I.U.1
Ht ....
'~h.l •

.... .. ..
~~~~,~ _ ,"1~.I~h.~"

f,,"U' -'Uh"
H~ ..... .v...
..... - ..... " ..... ,
.".. -- ..... Ito" ... '
~"
,I.~

,.~
~ ,~

figure no. 5

461
 AN ASSOCIATIVE DATA STRUCTURE TO
DESCRIBE BUILDING COMPONENT
ASSEMBLIES

A. L. Britch

Department of Building Science, University of Liverpool,

Liverpool, England.

INTRODUCTION

This paper describes the further work carried out in the Depart-
ment of Building Science, Liverpool into the use of list connected
models for use in the design of buildings using computer9. This was
first reported at the CIB Symposium in Oslo in June 1958 t1 ) and is the
result of the efforts of a multi disciplinary group consisting of myself,
an architect/engineer, a building scientist, a physicist/acoustician
and a systems analyst. The group has recently been broadened to
include a structural engineer, a social scientist and another architect,
together with three research students having recently graduated in
Civil Engineering, Building Science and Architecture.

The Oslo paper described the various approaches made to the

problem leading to the adoption of the principle of using high level
languages (typically ALGOL and FORTRAN) to implement the techniques of
associative listing for handling the information concerned with the
design process. This paper describes the extension of the principle to
the use of interactive devices such as a keyboard or visual display
uni t.

One of the main intentions of the present study is to apply these

principles to the well established graphic assembly system currently in
operation in ';Jest Sussex. rl'he '.vest Sussex system is fully described
elsewhere(2)(3) but it will perhaps be useful at this point to
summarise its development to date.

The basic system evolved, under the direction of Mr. B. Peters,

County Architect to the West Sussex County Council, from the applica-
tion of graphical input techniques using an IBM 2250 Visual Display
Unit connected to an existing IBH 360/40 Computer.

The system is concerned with the selection of pre-defined compon-

ents or elements to form a building assembly. The components of

463
elements known as 'blobs' are held under file and are capable of being
called for selection usually by family, displayed as a 'menu' on the
Visual Display Unit (VDU) and then after applying various operators,
locating them on a predetermined planning grid. It must be emphasised
here that we are dealing with the 'tactical' design stage and is
concerned with the production/end of the architectural design process.
Because West Sussex have been able to employ serial tendering and
therefore rates are known at the point of design, it is possible to
generate the cost of each assembly as a blob is located on the grid.
Thus the designer is able to make a decision, based upon cost, of the
suitability of component types etc., at a relatively early stage in
the design process.

When the designer is satisfied that he has chosen the correct

components and that they are correctly positioned on the planning grid,
that section of the building is filed away and the process repeated
until the building assembly is complete.

At this stage full documentation in the form of Bills of

Quantities, Schedules, Drawings etc., are available on demand.

The current limitations of the system are fairly obvious.

a) The suitability of the building component can only be

judged in terms of cost.

b) The design of the building, from a strategic point of

view, is complete and its suitability to fulfill its
function cannot be tested.

c) The building assembly is stored as a series of files

corresponding to the 'graphic data sets' associated
with the Visual Display Unit.

We see our main task as providing a means of associating this

information in such a way as to allow the free manipulation of data
concerned with the design of the building at any level of the design
process, thus providing a framework for overcoming the weaknesses (b)
and (c) and allowing for systematic selection to deal with (a). (The
ordering of the necessary information into 'Data Banks' and its
retrieval is being dealt with separately on an extensive and broad
front by others.)

IMPLEMEN~ATION

So far our work has been at a fairly specific level, attempting

to solve the problems associated with handling information and
techniques of graphical display. This has been done without losing
sight of the overall objective of providing a general framework for a
design system.

4M
 The general approach consisted of considering a building as a
collection of areas associated in some way or other. Whitehead's work
in the Department((4)(5) and others) suggests a possible starting point,
by considering the relationship of spaces by considering the movement
of people between them.

It has shown that it is possible to form a crude associative

arrangement of areas within a plan by means of a computer. This is
done by defining the connectivity of one area to another in some order
of priority depending on the number and relative importance of journeys
between areas. Thus a building may be defined as a series of areas,
described by name only, connected one to another in a manner defined by
the movement of people or things between them. Figure 1 shows this
connectivity in diagrammatic form and corresponds to the house plan
shown in Figure 2(a).

fig1
L
6 P10 Pl
P2

0 L 6 P3

7 B B B
5 8 9
P9
P4
10
4 (a) -= ")5 ( b )
P8 P7 P6
fig 2
465
 In computer terms we have chosen to define this connectivity by
reference to the 'addresses' of the 'named' areas and assembling them
into 'ring structures'. This technique is known as associative list-
ing and is adequately described elsewhere.(6)

The rings are made hierarchical, indicating a predetermined

design level. The first, we have called the PRIMARY RING, describes
the connection of areas one with another and thus will describe the
building complex; the second, SECONDARY RING, describes the components
forming the enclosure of the areas and corresponds to the rooms of the
building complex; subsequent rings provide information relating to
these components. Each ring is composed of lists of information having
a standard format defined by the user in the specification part of a
'Job File'. Each ring has a 'heading' part providing a summary of the
attributes of the lists forming the ring. Thus the heading to the
secondary ring will summarise the main characteristics of the room
described by the list of the components held within the ring.

The dynamic element of the system is provided by a series of

programs designed to operate on the information contained within the
lists. The action of these programs may be either controlled by the
system or interactively by the designer. It follows that providing
the depth of the analysis may be altered the designer is in a position
to obtain information relative to the level of design being considered
at any given time and to make a decision before moving to the next
level. Figure 3 shows this in diagrammatic form.

CONCEPT

z
o
~
(Jj
...J
•
«w
a:

fig a
The circumference af the circles represent time, the diameter the
depth of study and their point of contact the interactive element of the

466
system. The designer is shalom at this point and is generally the only
part of the system where the route may be changed. The designer moves
from the conceptual level through various stages and levels of analysis
to the 'realisation' stage when the design is finalised by a single
pass through the system. The latter corresponds to an enriched version
of the West Sussex production scheme.
P RIl1ARY RING
Taking the association shown in Figure 1 as the starting point,
each numbered circle indicates an enclosed activity and the proximity
of one to another their connectivity.

In this example the Primary Ring is composed of ten lists

connected together as shown in Figure 4.

8
Heading .
--VV
r-"4
- :i
1
10
3
9
2
1
7
0
8 9 10 0

~V 9 10 1 8 0
...•V
-: 2 1 3 4 5 7 0
V
...-V
r 4 5 3 2 0

--
6 5 7 ()

., VV 8 9 1 7 0

...., V 7
5
5
2
6
4
2
1
1
0
0

/ 3 4 2 7 6 0

fig 4
Primary Ring

In this instance the ring structure has not the significance

discussed later in connection with the Secondary Ring. However the
ring structure may be useful to allow the designer a means of SCann-
ing the enclosures of a building complex in a predetermined manner.

Taking enclosure 1 as an example the list describing its

association or connectivity with other areas in the building complex
is given as
[/11 I3 I2 I7 I8 1 9 110 I0I
\vhere the elements have the following significance.

467
position 1 the address of the next list,
position 2 the label or name of the current enclosure,
posi tion 3-n labels or names of adjoining areas associated
with area 1,
position n+1 zero plant acting as list terminator.
The labels referred to in positions 2-n are addresses or names of
files containing the Secondary lungs used to describe the properties
of the enclosure.

Note that the order of entry of labels or names after the

position 2 in the list is unimportant. They will be planted as and
when it is decided to fix the position of one enclosure of the
building complex relative to another.

It can readily be seen that no matter where the point of

entry into the Primary Ring, all information required to move from
one enclosure to another in the complex is contained within the
specified list. At this stage a series of files have been created
(Secondary Rings) named (their address noted) and the association
one with another has been defined as described. Further properties
will be generated as the various attributes of the enclosures are
defined. Thus the heading part of the Primary Ring, summarizing
the attributes of the building complex as a \olhole, will be initially
empty apart from its name (8 in the example shown) and possibly a
note of the number of enclosures currently making up the described
complex.

SECONDARY RING

The Secondary Ring is the most important element of the system,

containing information relating to individual enclosures and defin-
ing the connectivity of components forming the enclosure. It also
controls the dynamic elements of the system and is the general area
of designer/system interaction. As already stated the ring is
composed of two parts.
a) A heading containing information summarising the
properties of the total enclosure.
b) The ring proper made up of lists of information
relating to the properties and performance of the
components making up the enclosure.
The position in the list, unlike the Primary Ring, is of
considerable importance, defining the connectivity of one component
to another.

Assuming the dimensions and component parts of enclosure 6

(Room 'L') to be as indicated on Figure 2(b) a typical list might be
as follows:-

468
p4
k1 4 window panel

posi tion 1 contains the addresses of the next list,

position 2 component type. 'l'his usually takes the form of an
address or name of file containine information
relating to standard components,
posi tion 3 integer code: ¢ if external panel
1 if internal panel
posi tion 4 direction of movement of component defined as
movement from current position. +y
The following convention -
has been applied and I 2 \
corresponds to the 1
\4=----+---1 +X
- Xl---:
principle directions of
movement of an incre- 8
mental plotter. -
-y
position 5 horizontal dimension (length) of component.
There are of course many other attributes and parameters to be
included in the list. The ones given above are used as an example
and represent the minimum requirement to allow the generation of
plan shape and to define some physical properties of the enclosure.
The type value in position 2 refers to a subsidiary list containing
properties of the component under consideration which in turn refers
to a 'Graphic Data Set' to allow the generation of the component
referred to by type.

The ten components required to describe the enclosure 6 (Room

'LI) have been assembled into a ring and shown in Figure 5. Note
the connectivity defined by reference in one list to the address of
the next list and shown by arrays in Figure 5.

It must be stressed at this point that the geometry of the enclosure

is a function of this connectivity together with its attribute of
dimension. An image is therefore generated by reference to the infor-
mation contained within the list describing the component and then
moving on to the next component defined by the address in the first
position of the current list. It can be seen that entry at any
position and progressive reference by address to the next component
will allow the generation of the complete enclosure. 'rhe process of
scanning is normally terminated by memorizing the start address; the
scan being complete when this address appears as the next current
address. Alterations to the geometry may be effected in two ways.
a) By amending the attributes of the list (principally
dimension and direction).
b) By manipulation of address system.

469
 An example of the latter is shown in Figure 6(a) where two
components have been inserted in place of the original one. Note
that one component list is placed in the same position in the ring but

6 5 7 0
heading 17.0 11.0 7.75

~
----j

P1 2 1 16.5
I~
P2
C / 0 0 0
P3 .,;/ 2 8 3.0
Y
p4 L 4 8 7.5
P5
~
y 0 0 0
~
p6
G 7' 1 4 4.0
P7
~
~ 2 4 12.5
fig 5
p8 r-
p/ 0 0 0
P9 ~ 2 2 10.5 Secondary Ring
~
P10 K 0 0 0 Room '1'

P1(a )
% 10.5
,
r-
......, A 2 1 0

t:; ~ 0 0 0

G / 2 8 3.0

r--
'-;
/ 4 8 7.5

q~
0 0 0

q~ 1 4 4.0

~ 2 4 12.5
~ fig 6(a)
r.: ~ 0 0 0
~ 2 2 10.5
P1( ,/ 2 1 6.0
'"
the addition one is added to the end of the ring and the addresses
adjusted. It would seem at first glance that the more logical way
would have been to insert the new components within the body of the

470
ring, however in terms of computer operations it is more effecient to
add to the ring and adjust the addresses rather than move large amounts
of information. As an example of a geometric operation of the first
type take column 4 of the ring matrix illustrated in Figure 5. To
rotate the whole assembly through 90 0 it is simply necessary to
multiply each entry in that column x 2 and to inspect and make the
necessary adjustment if the result is greater than 8.
Heading
Assuming the entries in the Secondary Ring as Figure 5 and its
association with other enclosures as defined by the Primary Ring the
heading part might take the following form.
Row 1
11~.oI1q 71 0

Row 1: contains a copy of information relating to the association of

this enclosure with others as defined in the Primary Ring.
How 2: contains in the first two positions the principle dimensions
of the room abstracted from the information contained in
columns 4 and 5 of the ring.
These entries are Given as a possible example of the use of the
heading part of a ring. The user would be free to specify any format
by an appropriate entry into the 'Job File'. ('rhe Job File contains
the Primary and Secondary Rings together with a specification part
containing information such as format, design status, available
facilities, etc.)

Normally the heading part of each ring will be up-dated at the

end of each pass through the model or as a result of an interaction
on the part of the designer.

GRAPHIC DATA SET

Graphic data sets are used to generate the graphic elements of

the components and are usually controlled through the subsidiary ring
containing the performance specification of the component.

Figure 7 shows a typical graphic data set to generate the

window component, p4. It consists of a heading part followed by a ring.
Ring
The ring consists of a series of data lists providing basic
graphic elements as follows:-
12]15 11 11 1
position 1 the address of the next element of the graphic data set,
position 2 the TIl.mber of increments making up the vector (one
increment = O.1mm),

471
position 3 the direction of movement assuming the
following convention,

position 4 pen position: ¢ up, 1 down.

How No. 1 10 100 4 15

2 8 3
3 11 15
4 13 17
5 14 19
6 15 20
7 16
8 18
9 19
10 20
11 12 15 4 1
=.f" --.:::-- - - t - - -.........
12 13 30 2 1
t; -L - - - - -t--------.....sp
13 14 15 1 1
14 15 15 4 0
15 16 15 4 1
16 17 7 8 0
17 18 15 1 1
18 19 23 8 0
19 20 15 4 1
20 21 15 1 0 fig 7
21 11 15 1 0

Scanning the ring and interpretation of the data enables the

graphic element to be generated.

The data set is made dynamic by reference to the heading and the
use of operator type programs to manipulate the data. The following
functions are currently being used.
SCALE This procedure enables the size of the displ~yed element to be
altered. At each entry the current scale is compared with the
required one, if necessary the data is operated upon and the
new scale noted.
ROTATE This procedure alters the direction of movement of the graphic
element specified as the direction from the start point (sp) to

472
 the finish point (fp). At entry the required direction is
compared with the stored direction, the data operated upon
accordingly and the new direction noted.
LENGTH This procedure allows specific elements of the graphic data set
to be scaled. Again the data is changed if necessary and the
new length component noted.
The parameters of these functions are stored in the first row of
the headings as follows:-
Row 1 10 \100\ 4\ 151

posi tion 1 number of elements making up the ring proper,

position 2 the scale of the graphic element so stored. (In the
example above the element is stored to a scale of 1100),
position 3 the current direction of movement of the graphic element
from the starting point (sp) to the finishing point (fp),
position 4 the current size, in increments, of the variable length
element.

Graphic data sets have some intrinsic functions aimed at

reducing the amount of data needed to generate graphic elements. The
most important of these is the function to automatically produce a
mirror image, thus making it possible to specify a symmetrical graphic
element by storing data concerned with one half only. The example of
p4 illustrated in Figure 7 shows this facility.

The first position in Row 2 contains an integer whose value indi-

cates the number of elements required to be amended. If the value is
zero the mirror facility is not required. A list follows containing
the addresses (row position) of the elements concerned. It can be
seen that by operating on the direction indicator of the specified
element, i.e. rotating them through 1800 , it is possible to produce
the mirror image. The data is left in its amended state and the direc-
tion indicator in the heading part amended. Further intrinsic
functions have been developed to deal with repetitive elements. A
more detailed description and specification is given in Appendix I.

Following the addresses concerned with producing the mirror image

is the information relating to the procedure LENGTH. In the example
shown this starts in row 2, column 2. The first element contains a
positive integer indicating the number of elements required to be
scaled, followed by the addresses (row positions) of the elements
concerned. Thus in the example on entry to the procedure LENGTH, one
of the parameters would be its length of 7.5 ft., extracted from the
Secondary Ring. To the scale of ~OO this is equivalent to 230
increments, 30 of which are taken up by standard jamb details leaving
200 and because this is a mirrored component the length parameter
would be 20 92 = 100. The length scale would therefore be 100~5 = 6.7.

This scalar is then applied to the increment values of the lists

addressed as 15, 17, 19, 20.
473
15 16 15 4 1 and becomes 15 16 4 1
16 17 7 8 0 16 17 8 0
17 18 15 1 1 17 18 1 1
18 19 23 8 0 18 19 8 0
19 20 15 4 1 19 20 4 1
20 21 35 1 0 20 21 1 0
21 11 15 1 0 21 11 15 1 0

CONCLUSION

The work in the department has concentrated on two aspects of the

modelling work described. First the development of techniques to
specify plan shapes to allow their easy manipulation and analysis in an
interactive mode. Feasibility studies have been completed on the
manipulation techniques in conjunction with the Secondary Rings. Some
of the analytical routines have been developed and are working
satisfactorily.

Much of the recent work has been in connection with the develop-
ment of the graphic data sets as an essential means of producing the
graphic images of real components. This work is currently being
extended to develop, in conjunction with Alex Gordon & Partners,
Architects of Cardiff, an automatic draughting system concerned with
the production of door details and schedules. The system is being
implemented on an ICL System 4/50 with an on-line Calcomp 30" wide
drum plotter.

A library of graphic data sets describing standard door and

joinery details are stored on a disc file. A program interprets the
door code, (already existing as part of the current drawing office
practice), accesses the correct data set operates upon it to modify
its shape etc., to meet the specification, assembles and generates the
drawing, abstracts the information for the schedule and upon comple-
tion outputs the collected door schedules.

If successful the scheme will be extended to include most of the

production drawings. The drawing file will be output on a magnetic
tape at the computer for off line printing in the architects office
by means of a magnetic tape driven plotter.

The main area of study still requ1~ng attention is the estab-

lishment of the subsidiary rings concerned with the performance
specification of components. At the moment this information is
introduced into the system as specific data. Work is in hand to
attempt to draw up a scheme based upon the West Sussex concept of
Data Banks to provide this essential link in the system.

474
 Although our work is in a very early stage we at Liverpool are
confident that given the right encouragement and facilities we would
have the embryo of a working building design system in operation
within a very short period.

REFERENCES

(1) BHITCII A. L. 'Use of Computer Stored List Connected Models as

a Design Tool' Paper No. 5.12 !!££ Information Flow in the
Building Process - Classification and Coding for Computer Use.
CIB Symposium, June 1968, Oslo Norway.
(2) PATERSON J. W. 'The Use of Computers by Architects' Proc
Conference on Computers in the Construction Industry, Manchester
England. 26th October 1967. Ministry of Public Building & Works
London, England.

(3) PETERS B. 'Architect - Computer System.' October 1968, West

Sussex County Council. (Private publication)
(4) AGRAA o. M., WHI'l'EHEAD B. 'A Study of Movement in a School
Building. Build.Sci. Vol.2
(5) HAFEZ E., AGRAA O. H., WHITEHEAD B. 'Automation of Data
Preparation in Computer Program for the Planning of Single Storey
Layouts. Build.Sci. Vol.2
(6) BOBROW D. G. and RAPHAEL B. 'A comparison of List-Processing
Computer Languages' 1964 Comm ACM Vol.7 p.4

475
 THE COMPUTER AS AN AID FOR THE
ARCHITECT

P. E. Walter

County Architect's Department, West Sussex County

Council, Sussex, England.

In my paper* presented at the Symposium held at BruneI University in

July, 1968, I described the computer techniques developed and used
by the Architect's Department of the West Sussex County Council.
Research and Development work is continuing in all areas of the
total process of achieving the creation of an environment and this
paper records some thoughts on the total problem some of the
conclusions that have been drawn and the objectives which we are
now endeavouring to achieve.

To achieve an objective it is necessary:-

(a) To clearly define the objective.

(b) To decide upon the activities which it will be
necessary to perform and the order in which they
are to be performed.
(c) Perform the activities decided upon in (b).

In achieving our objective, that is the creation of an environment

and maintaining it, four major activities need to be performed in
the following order:-

(i) Design.
(ii) Connnunication.
(iii) Construction.
(iv) Maintenance.

Each of these activity areas in themselves have objectives to reach

and within each of these areas there are smaller areas which must
also achieve a particular objective.

The provision of Information required by the Organisation is provided

by a fifth major area.
* Published in Computer Graphics, Plenum Press, London, (1969)
pp 125-133·
477
 The Organisation appears as shown in diagram 1.

DIAGRAM 1

It is a discipline of the system that the preceding major act~v~ty

should be completed before the succeeding activity commences.

This requirement demands that information must pass from one activity
area to another and this means that the information generated must
be:-

(a) Complete.
(b) Readily accessible.
(c) Easily identified.
(d) Always up-to-date.

It has been found that because there are so many professions and trades
involved in the total processing of a project, communication between them
is poor; the order in which things are done is inadequately controlled
and decisions are made at the wrong time and sometimes by the wrong
people.

Consequently the process becomes inefficient, expensive and with an

end result which is of a much lower quality than it could and, indeed,
should be.

The system which we have evolved therefore provides:-

(i) Aids to the management and control of activities

and resource allocation.
(ii) Structure for holding Information.
(iii) Means of communicating and manipulating Information.

478
Aid to Management. Management in all activity areas is provided
with a network of activities required to be performed within its
area.

To each actLvLty is applied the estimated time and resources in

terms of Materials, Manpower and Plant required for that activity.

The network is monitored regularly, actual expenditure of resources

and time recorded and compared with estimates.

Discrepancies between estimated and actual expenditure are displayed

and corrective action is taken, the network and estimates being up-
dated as necessary.

The ordering of the activities ensures that decisions are made at

the correct time by the correct person and the monitoring of the
activities and checking that they have been satisfactorily completed
removes the likelihood of abortive work being carried out on succeeding
activities and ensures that correct action has been taken.

Structure for Holding Information. The objective of one activity

is almost certainly set by a preceding activity. For example the
result of decisions made by clients provide the objective for the
project team. Similarly, the decisions made at the design stage set
the objective for the construction team. To allow these objectives
to be clearly defined and correct decisions to be made it LS necessary
that adequate information of high quality is available as it is
required.

The problem here is to hold the information so that all users can
easily identify what it is they require or have generated and can
find the information easily. If these requirements are not fulfilled
then the information will almost certainly be misunderstood and
insufficient information will be used for decision making.

The identifiers of information within this system derive from things

which are fundamentally related and relevant to man's needs, abilities,
physical structure and his location in time and space. Things, in
fact, which have changed very little in the passage of time. Some
examples would be man's need for shelter, air, cleansing, health,
energy intake, rest, his ability to stand, push and pull, hold, hear,
see, speak and feel, his age and geographical location and the fact
that he has eyes, ears, skin, blood and bones, etc.

When man performs a particular activity his physical structure

makes necessary the provision of certain environmental conditions
and physical aids and how adequately these requirements are fulfilled
(setting aside social and economic arguments) depend upon the quantity
and quality of data upon which judgment and decisions are made.

479
The identifiers, some of which I have mentioned, describe these
requirements, but. the way in which these requirements are fulfilled
change and the data relating to them is constantly being up-dated
by researchers working in their various fields. The fulfilment of
a requirement, however, is a solution to a problem and these solutions
can be identified by selecting significant functional criteria and
placing the appropriate values against them as I will demonstrate later.

Knowing the physical abilities and the age of man it is possible to

set down a list of activities which he may wish to perform and record
against these activities the requirements (using research data) and
the product of the activity. Diagram 2 explains this.

~A.tJ v,
£.tJ to I.J ~1.t3 ~ • "V.~OtJOM' c:. ~RP>oc:.-rC ot:=
• "N'W.~roM'-\l..lC:. b.lQu,qMt.tJ,s A,e.-n" ''T Y

-.-
~ t:.\. 2.0
Olf- ~(!.,'T ,\I lTV •
Ae,. I v 1\ 'I A.\it,
~,
iUwl,~ u ....t sex...,. ~ca. ~ t1AcAl ~, KOISI
Alft A,e.
~ 't.rtaia
t SUI t.J1i
2. \O\U It. , t.) c:
3 UTIt.J4
ct SI'''T "ole
5 C.LU~SIUI

ACTl\ltTY
" " L...U l:..S

"c..T' V I T Y " A. 1..1) 't..S

.... ,t.
~
~\-., RAltol'f4l.L SUt.)-
.W,''''L
SOuN~ .".-. ""'NO ~"''''4
~ "foaIa. !......."u.
p.~, I t.l c;.

S?t:4K'M~

W~~CI4''''''Q
-nJ...." lSI OM

S~~l""~

.--r1nc ce. QC.-l-i",~es ewe,.

CD~q U,l"\OlfQ.-\et ~ ~
~,e ac.~,,;~ ... ~".,.
,. IfC.,h 0".1 ~ar\v lX) o-cI _4.

dee,dcd UfCM ~ us...,. e-f ~'I~ •

480
Similarly, it is possible to set against identified locations in
space the prevailing geophysical and micro-climatic conditions as
diagram 3 shows.

--
LOeA.:t lOW VA. L..U"-S

LOCA..iIOlJ V 6. L u LS'

AIr. \lIJ",,'~ bit.)· 5:1.) tJ- sou~ PMWno.J "" ,..,1> 5~t.1.aQ
"TU4~ ~l...L ~"It.)l. L.llIu. 'fOt.Ct.. ~CUCll

t-l1a."T10t.)" L
~t..\1> R,*,

I ~st. I '2."!4-ak

It is also possible in the same way to describe a physical aid (a

solution to a problem) by recording its significant functional
criteria and the criteria values as the diagram 4 shows.

1
\
~~$l ~"l ~\,H..\.C."t \0 t-lA.L C~\T~2..IA.
SOLU,IO ~s
flU SOUNP SOUI./J) \.'5~T
~" ~-=''Y st~ ~ ""'"T
.t.«M ""'~
u.sl~ ~. YSOCl .t.UCIQ S1'u'c ~I.ST

~INC:S Volt
~l1.i..:l" \lW.O I

""~e.)as ~It
LL"TTlt.la
LA ~"'T ~ £,.D ,

Communicating and Manipulating Information. The information now

has to be used manipulated and communicated within and amongst the
various activity areas.

481
Having decided upon the activities to be performed and the
geographical location of their performance, it is possible to
compare data as given in diagram 2 with data as given in diagram
3. This comparison would identify:-
(a) The adjustment necessary to bring prevailing
environmental conditions to required conditions
and maintain them.
(b) Functional criteria and values by which physical
requirements can be assessed.

\.OCA'T, ow r----~

.~'\""I~
-t---"" ~"'ofl.
,'"
la.C!T'''' "C'V A.

~"'"TR
oe.~u
J,.vA,U..
\'l"'\t,.

482
Matching values of functional criteria of existing solutions are thus
identified and brought forward for examination and selection.

Similar results are obtained by comparing activity with activity,

that is, comparison of matrices as at Diagram 2 with each other.

The arranging and re-arranging of activity areas can be made based on

the weight of importance given to, say, first circulation patterns,
and then sound insulation values and so on.

So~T Ae.TIVI~U 0"" $'l:..L~\ It..c..Tlv,~y

e..,! $OU...u
~'"t'ofoJ~~\\>
. ~~DI\"1..
~\u.

.'''l.''~ "'t'OTa.lo ~~s\Ca,) $OI..U"t1O,", 1:)~"'~1 loS 0,. ""A.I,.,,.IL ..... W~

....eT~"'T''''S ,q .... o 1o.\>"l..Y
0If- l>LL'fC"M"a.J~ 'C'T.. tJ1) ... t.~$
,,61ot.. ~LSO u Lc:.Ir.S ~ .1.oJ)"c.\.
s,eA"-U ,.,..~ IIJ',,~ """'''''of s~.,.,~ ~LLA..~U tv bLSIG."-l
01:.e \ S ICI\.LS

'f'l13>1!ok.K up ~"''Tt.S
1:>~S ,.a.1ol ~ "-U~ 10 "'oS

483
 The Designer, seeing the resuJtB of these applied weightings, decides
the best balance.

Diagram 5 shows the situation so far.

Having decided upon the arrangement of activity areas, the plan shape
can now be determined.

Using modelling techniques such as Mr. Britch has described ~n his

paper, tests can be applied which will reveal the reactions of the
building to the manipulation of the plan shape.

For example, one plan shape will expOSe a greater superficial area
of envelope to wind pressure, than another. Another shape will
enclose a greater area or volume of space. Daylight factors may
or may not be achieved if another arrangement is used, and so on.

Again, the Designer ~s left to make judgment on the information

produced for him.

During this process, of course, the Designer may wish to go back to

the previous stage and re-examine his activity area arrangement.

Assuming, however, that he has now produced a satisfactory form, he

has now reached the situation described in Diagram 6 that is, the
selection of materials and physical aids can now take place.
Selections having been made, re-testing may be carried out to check
that the performance of the building remains satisfdctory.

The enve10pers and dividers of activity areas and the physical aids
to be provided within the areas ~re described by the function they
perform.

We identify 11 such major elements of a building project. They

are called functional groups and are named:-

Site
Structural Support
Vertical Envelope
Space Divider
Base Platform
Intermediate Platform
Horizontal Envelope
Vertical Circulation
Environmental Control
Servicing
External Environment

484
The products to be used in these situations are selected from
alternative solutions identified by the values of the functional
criteria produced by comparing activity area requirements with either
the surrounding natural environmental conditions or conditions
produced by neighbouring activity area as previously explained.

Each functional group is disciplined to occupy its own zone, and is

not allowed to trespass into any other zone. It is a conglomerate of
a series of 'blobs' and a 'blob' is a dimensionally co-ordinated
volume of space.

The shape of the 'blob' is determined by the use of the system, but
a series taken from our system covering space dividers is shown at
Diagram 7.

Ot=l ~ 1 1 / ,~ / ~
,'-0" 11-4" II-~II 2,'-0" Sl~<;'-'S... .s 1104C: L'l. 'OOU'1!.L~ 'Poo'R.
'J)CX)~ booll.

'D \ b. Co 'R A. tv'.

7·
My previous paper covered this part of the system fully, and I will
not go into great detail here, except to say that quantities of
materials, activities, manpower and plant are measured to fill the
'blobs' and form the design solutions which are identified by the
functional criteria values as I have described.

The selection of the design solutions having been made, it remains

for the location to be identified. Again, referring to my previous
paper, it will be seen that this is achieved by using a graphics
display unit with light pen assembly to associate the selected
solution with its appropriate 'blob' shape and appropriate functional
group with the position that it is to occupy in the building. 1.

In doing this, details of the activities to be performed and their

activity network codes, together with the quantities of materials,
manpower and plant, have been registered (and as we employ serial
tendering techniques, the cost as well), which are then produced
for the construction team, who apply to it the order of the activities
and the resources available.

The product of this is a time-scaled and costed network of activities,

showing estimated resources at each stage.

I'The modelling techniques when implemented will replace this part

of the system which is currently in use.

485
Amendments, valuations and final accounting are relatively simple
matters.

Weare,by using a digital plotting device, able to reproduce for the

construction team the plans that have been described at the screen
face of the display unit.

A large part of the system I have described, is already computer

based, and has been in use for some time. Other parts are
manually operated and the remainder is conceptual. To turn
concept into actuality is our objective and we are applying our
resources to this end. When we have achieved this we shall have
given to the computer a great many of the chores that are currently
undertaken by the various professions involved in the complex business
of creating and controlling an environment.

The computer will also be giving up-to-date and accurate information

and advice upon which decisions and judgments can be made.

This will give the Architect and his colleagues a much better
opportunity to practice their arts and skills.
 COMPUTER GRAPHICS SYSTEM FOR
SCHOOL DESIGN
Patrick Purcell, Andrew Garnett, Christopher Jones,
Brian Pendry, Michael Sender, John Wood.

Industrial Design (Engineering) Research Unit,

Royal College of Art, Kensington Gore,
London SW7, England.

Abstract

The aim of the COMDAC project is to develop programs

that use a graphic display unit and an existing data structure
aid to enable an architect to interactively generate a three
dimensional model of a proposed building in memory store.
Routines are also being developed that will enable the user
to evaluate and develop the model so generated and to output
hard copy drawings and schedules when required.

The emphasis of the project has been placed on the external

vertical envelope of school building systems and a significant
part of the project has been devoted to the analysis of
current design procedures in local authority architectural

487
offices. Information generated by this analysis has been used
to decide the point in the design process at which the computer
should be introduced and to allocate functions in the resulting
man/machine partnership.

488
Ergonomic techniques have been brought to bear on the
problems of graphic input, display design and other aspects
of the man/machine interface.

1 Introduction

1. 1 The COMDAC project is a computer-aided design

study being undertaken by the Industrial Design
(Engineering) R.esearch Unit of the Royal College
of Art and sponsored by the National R.esearch and
Development Corporation. A number of other
organisations are collaborating with the project.
These include the Central Development Group of
the Second Con:'iortium of Local Authorities (SCOLA),
the Hertfordshire County Architect's Department,
Crittall-Hope Limited and International Computers
Limited. The Computer Science Division of the
National Physics Laboratory has provided the
project with machine time on its ICL 4120 computer
with graphical display and has also made available
the DISGOL data structure aid and display
programming package which has been developed at
the laboratory.

1. 2 The aim of the project has been to develop an

interactive computer-aided design package for the
SCOLA and SEAC school building system that will
allow the user to input the broad geometrical
attributes of a proposed building to the computer by
means of a CR.T screen and light pen. Once this
description has been achieved the user will be able
to develop certain aspects of the internal computer
model so formed by interactively accessing
catalogued information: he will also be able to test
the performance of the design by calling up a number
of evaluative routines. The aspect of the SCOLA and
SEAC systems that has been chosen as most suitable
for this process of interactive development is the

489
 design of the external vertical envelope and, in
particular, the window walling. This feature of the
system was chosen for particular consideration as it
is currently the most advanced from the point of view
of integrated design, production and assembly
management. The use of this management system at
present requires that the designer first code his
drawings of the window walling in considerable detail.
This coding is then checked and re-coded on to data
sheets, the contents of which are then punched on to
paper tape. All these processes can be undertaken
within the local authority office, or alternatively, the
last two stages may be completed by the wirrl ow
manufacturer. The punched tape is finally input to
the Crittall-Hope ICL 4120 computer to generate
costing, production and site assembly information for
the contract. This method of interfacing a design with
a production and assembly service represents a
considerable advance in the building industry but the
process can usefully be improved both in time and
accuracy.
1. 3 The COMDAC software system will provide
facilities that will obviate the need for the present
manual coding procedures. That is to say, once
the architect has achieved a satisfactory design,
with the aid of a computer a tape description of
the window walling, similar to the one currently
produced by the present three stage process, will
be output as part of the hardcopy generated by the
system.

1. 4 The development of the COMDAC project can be

broadly divided into the three stages of systems
analysis, systems design and systems evaluation.
A diagram illustrating the contents of these three
Diagram 1 categories in the context of the project is shown
overleaf and the remainder of the paper will be
devoted to describing these activities.

490
 Analysis of architectural design task

1
Specification of architectural
design operations

1
Allocation of operations
to man and machine

1
Synthesis of computer-aided
Software specification
architectural design task

I
+ ~
Support software COMDAC software
development development

I 1
I interface design
!
~y
S stem in tegrationl

Architectural
task description
!
Job specification
System evaluation
I
.. '"
Job-aids Training
for task scheme

DIAGRAM 1 SYSTEM DESIGN PROCESS

491
2 Systems Analysis

2. 1 The purpose of the architectural task analysis has

been to establish the processes by which a typical
local authority architectural team arrives at a
satisfactory design for a school building, whilst
working within the constraints of a school building
system.

It has involved a study of the design development

of 6 SCOLA and 4 SEAC schools and school
extensions, of which one of he latter was
experimental and involved a non-standard roof
structure. Two buildings were studied in particular
detail, one a primary and the other a junior school,
and in these cases a member of the team attended
briefing meetings, interviewed the job architects
concerne.d and examined documentation such as
briefs and cost estimates together with the drawings
and job diaries which the designers concerned were
asked to keep for the duration of their project.

2. 2 Whilst these two projects provided the most

comprehensive range of information about the
school design process, the 8 background studies
also generated much useful information about
specific points, particularly those concerned with
the use of the window/wall system. Nevertheless,
the major effort was devoted to the analysis of the
two 'in depth' studies and a comprehensive set of
documentation was collected for each of these.
Neither of the two schools achieved a trouble free
run through the traditional design stage s of brief ing,
bubble diagrams, thumbnail sketches, sketch
design, scheme design and design realisation. In
the one case a misinterpretation of the brief
resulted in a significant planning fault that was only
discovered at the completion of the sketch design
stage and which forced the architect to return to his
thumbnail sketches and reassess the design within
the affected regions. In the other case, the project
was rejected at the end of the scheme design stage
because the daylight factor in some parts of the
building failed to achieve the statutory 2% minimum.

492
 Subsequent attempts at local revision failed to solve
this problem and the client began to have second
thoughts about the brief. Eventually the scheme
was aborted and the design started again.

2. 3 For each of the two main studies, single thread

flow analysis charts were drawn up that give a
blow by blow account of the history of each
project. The goals and sub-goals of both client
organisation and architectural team were then
scrutinised and the information from the study
used to construct goal resolution diagrams that
serve to demonstrate the hierarchical nature of
the relationship between goals and sub- goals in
such decision making situations.

2. 4 During the next stage the information from the

task analysis was used to form a generalised
Diagram 2 functional diagram for a typical local authority
architectural team. This diagram is shown
overleaf and indicates the stages by which the
design team attempts to satisfy the requirements
of a brief; the points at which their attempts are
subject to evaluation by outside bodies such as
client committees and the points at which they
may themselves evaluate the viability of their
proposals.

2. 5 The final part of the analysis was concerned with

expanding the section of the functional diagram
relating to scheme design and design realisation,
both in the form of functional resolution diagrams
and of operational sequence charts. The first of
Diagram 3 these forms, illustrated overleaf, clearly shows
the hierarchical manner in which a building is
both conceptualised and developed during these
stages of the design process. The operational
seq~ence charts, on the other hand, although
carrying the analysis down to the same level of
detail, serve to illustrate the temporal order of
the design process rather than the conceptual
order of the designed object.

493
~ KEY Project brief
Return to any previous
® non-decision stage

InDout Function Interpretation loIkr-------....,

of brief

Function
in . .
~ out mcorporatmg
decision Bubble
1 it dlagram
Externally
applied decision

Selected bubble
diagram
-"""--a

Detail design

Thumbnail sketches
I

RJ 1
'''/1
Selected thumbnail
sketch
Approved scheme .1----..
plan and
elevation
First layout
 ®
Approved first layout
Scheme plan and
elevations

Exploratory I elevations

RJ fR' I~I
Selected Ielevation

Sketch plan

Evaluated
sketch design
Detailed Approved
elevations sketch plan

FUNCTIONAL DIAGRAM FOR ARCHITECTURAL TEAM DIAGRAM 2

~
 PLAN LEVEL RESOLUTION

Building 1

Plans 2

External wall thickness 3a

Internal wall thickness 3b

Openings 4a
Beams over 4b
Openings 4c
Roof lights 4d

DIAGRAM 3 FUNCTIONAL RESOLUTION

496
 DIAGRAM LEVEL ELEVATION

1 Building

2 Faces

3a Fascia construction
3b Non-fascia construction
3c Mixed construction

4 Sub-faces

5a Window-wall
5b Hole-in-wall
5c Solid

6a Horizontials
6b Verticals
7a Head
7b Mullion
7c Lamb
7d Cill
7e Jamb
7f Transom
7g Spacers
7h Kick rail
7i Corners
7" Chair rail

LEVELS OF SCHEME DESIGN

497
 2.6 The results of the task analysis suggested the
point in the design process at which the architect
could most usefully be gin to use the computer as a
design aid, granted the constraints of the bref and
the level of sophistication of the currently
available hardware and software. The results
further enabled the team to establish the sequence
of the various stages or modes through which the
COMDAC user would pass, the overall structure
and the internal logic of these modes and the
allocations of functions between man and machine
in the resulting man/machine partnership.

The methodology for allocating functions in a

CAD system is by no means fully developed at
the present time but the consensus of opinion in
the team suggested that the designer should input
a description of a proposed building to the computer
at the 'scheme design' stage. At this point his
design is largely conceptualised but it still
requires considerable functional and aesthetic
development before a final solution is achieved.
This development process is best undertaken by
cycling through a sequence of design modifications
and evaluations and both these stages make full
use of the computer's information retrieval and
processing capabilities. In addition, it is at this
stage that large quantities of detailed information
are added to a design and this can be stored and
handled by the computer and readily modified if
necessary without incurring the prohibitive time
penalties that arise from significant design changes
at a late stage in the conventional design process.

3 Software design

3. 1 The systems analysis stage of the project

described above resulted, therefore, in a
general performance specification for the final
COMDAC software system. It was recognised

498
 that in order to describe a building design to the
system by means of a graphic display, it would
be necessary to provide symbolic representation
of component catalogues both in plan and elevation
and at a number of different scales. The
manipulation of these symbols should allow a 3
dimensional model of the proposed building to be
developed in memory and the user should be able
to evaluate and modify this model once it had
been sufficiently established. Finally, once a
satisfactory design is achieved the user should
have the facility available to output drawings and
coded specifications of the design on punched tape.
Diagram 4 The latter should meet the input requirements of
the Crittall-Hope computer system.

3.2 As a preliminary step, a number of development

programs were written and tested. These have
been assembled together under the generic title
of ASPECT. This ad-hoc software package
demonstrates the majority of the features that it
is intended to make available for the user of the
final COMDAC software system. The facilities
that it incorporates include the ability to change
scale, to 'window! to move from plan to elevation
and back again at will and to modify the design
displayed on the screen by interacting with the
internal 3 dimensional model. In addition, the
ASPECT user may initiate a catalogue searching
routine which inserts a window where requested
if there is one of the right size available. In a
similar manner the user may call a routine that
automatically sizes and inserts mullions in a
section of window /walling, takbg into account both
the bearing area of the mullion and the prevailing
wind conditions on the site. Finally the user may
access a daylighting and a costing routine to
evaluate the performance of his design.

499
 MAN INTERFACE

manual
graph
\ II plotter
~
"
J

type-
it writer
1\
\

~ ~
~.
graphic
" : display It
~ 1\

.~
brief .~
pit
reader
\

" ..JI
('

.~
design J pit
drwgs punch
I.-

COMDAC output
systems tapes to
tapes Crittall-
Hope Ltd

DIAGRAM 4 COMDAC SYSTEM

500
 COMPUTER

component component
J
catalogue costs

-
r"
I
'v iv
2-D 3-D
, I; ,
~ MODEL I' ) MODEL II

-
}
I"

" /i" ~,
.... r-.

==
-
display
software
scola/seac
constraints
evaluative
routines
'l'1~
~7'

DATA FLOW DIAGRAM

501
 3.3 Experience with the ASPECT package raised a
number of important problems, particularly in
the field of human factors. The earliest version
used the CHT display much like a traditional
drawing board and this made it both time consuming
and difficult for the operator to input a design
accurately. Later versions have overcome this
problem somewhat by adopting the principle of
gravity fields and by automatically setting up
certain key components, such as transomes and
fascias, in their correct positions. These
'techniques are a considerable improvement, but
inputting the design of a large and complicated
building is still a lengthy and tedious process,
that may require several hours of computer time
to complete. This is clearly an extravagent use of
the computer and it can also be very tiring for the
operator. The project team has, therefore,
s1£ nt some time developing techniques that stream-
line the process of graphic input and these are
currently being incorporated in the final COMDAC
software system. Ergonomic consideration to
such factors as light button layout, generation of
accurate line lengths and the use of gravity fields.
In addition, a facility is being introduced that will
allow the user to assemble window /wall components
into storey-height panels that can be called at will
for the duration of the job.

3.4 The final version of the COMDAC software system

will allow thE(user to input a building in several
Diagram 5 discrete stages or 'modes'. To begin with, he will
specify the overall dimensions of his design. This
will set up the computer so that a block plan of the
described building will be at such a scale that it
fits entirely into the 10 inch by 8 inch area of the
screen that is reserved for displaying the design.
The user will the n describe the perimeters of all
the building units within the building complex. This
data will include the shape, size! and relative
positions of the units with respept to an arbitrarily
chosen reference point on 'the silte. During the next
mode the user will delineate all those areas that
are at some particular height above a specified
datum line - for instance, all floors and roofs that
502
are at 36 modules above datum. Once this stage is
complete, the system will enable the user to define
the positions all internal partitions will take and,
foIbwing this, the layout of the stanchions. A
differentiat:ion of the external wall into areas of
solid and glazed cladding will be made during the
next mode and the system will then automatically
calculate the minimunlevels of daylighting in each
glazed room, to check that it is not below the
statutory 2% minimum. In addition to this, the
system will also generate an elemental cost
check. The purpose of these preliminary
evaluations is to provide the user with a
warning of potentially serious design faults
before a fuller definition of the model is
achieved, for at the later stages, such faults
would require considerably more time and effort
to correct. If the results of the evaluations are
satisfactory the user is free to continue with the
next mode. This is divided into two phases.
During the first phase, the type of solid cladding
is specified and the previously defined external
openings are further differentiated into infill
panels, fixed and opening lights, doors and fascias.
Before proceeding to the second phase, the user
may call on the daylighting routines to provide him
with a set of daylight contours for an individual
room and he may also call for a more accurate cost
check. He may then modify his design in the light
of these evaluations, cycling through the stages of
evaluation and modification as often as he wishes.
Once he has achieved a satisfactory design
solution, he will move on to the final phase of the
final mode and generate detailed design information
about the exact type of opening lights, the type,
weight and thickness of the glass, the type of glass
fixing and the type of fascias. This last stage is
almost directly equivalent to the manual coding of
the architect's drawings that is the current
practice. Armed with this very detailed informa-
tion. the system can make a very accurate assess-
ment of the cost of the window walling and in the
light of this information, the user may further
modify his design should he consider it necessary.

503
 COSTPLAN

PERIM DRAW BLOCKDEF STAND RAW SPAC

_" t'
, , .
'r" ~ J

input peri- describe input the input

meters of areas of the stanchion positi
building building com- layout intern
complex plex of the partit
same height
)~

HEAT-LOSS STEELWORK
PREDICTOR

DIAGRAM 5 COMDAC SYSTEM

504
 COSTCHEK (1) COSTCHE CK (2)

, ~ , ~

EDEF EXTOPE FACEDEV (1) FACEDEV (2)

,
1 ,'" '" ~
preliminary
delineate full definition
description of
on of external component of vertical
al openings in types in envelope
ions vertical vertical components
envelope envelope
, I"
" "I' ~ ~

HEAT LOSS MULGRAF

DAYLIGHT CHECK DAYLIGHT

CONTOURS

MODE DIAGRAM

505
 3. 5 When the operator is fully satisfied with his design
it may be retrieved from the computer in two
formats: as a series of fully coded and annotated
drawings from the graph-plotter, or as a paper-
tape containing all the information concerning the
vertical envelope, in the form required by
Crittall-Hope Limited. A further facility will be
provided, whereby the operator may 'dump' his
design on paper-tape, irrespective of which stage
he is at. This tape may be fed back into the
machine at a later date and the design process
continued. A permanent record of the costing
routine s will be available from the typewriter.
The evaluative routines themselves may be
considered as software packages which can be
used in isolation from the main bulk of the
program. It will be perfectly feasible for just
an isolated room to be described to the system
and, say, a daylight check to be made on it.

3. 6 Daylighting.
A minimum of a 2% daylight factor is a
statutory requirement for specified rooms within
a school. During the task analysis, it was found
from interviews and drawings that the calculations
involved in determining whether this minimum had
been achieved, were both long and tedious. The
importance of this requirement in the design process
was further emphasised when it was found that one
scheme required extensive redesign when just a
single room was found to be too dark. It was for
these reasons, together with the fact that these
calculations were intimately bound up with the
design of the vertical envelope, that it was decided
to incorporate a routine that would determine the
daylight factors in rooms.

The daylight routine works, at present, for

vertical glazing only but is currently being
developed to allow for rooflights and for external
obstruction such as adjacent buildings.

506
3. 7 Mulgraf routine
Mullion sizes are fully specified,for a given
situation, by the building system. This specifica-
tion is based purely on structural factors although
the architect has the freedom to use other available
mullions for aesthetic reasons provided these are
structurally satisfactory.

The Mulgraf routine examines the type and area of

cladding to each side of an unspecified mullion as
well as the storey height and ambient wind condition.
With this information, the system automatically
determines the appropriate mullion for that situation
and incorporates this into the model.

The operator may overide this automatic routine

and stipulate the types of mullions he wishes to use.
Provided these produce a structurally sound con-
figuration, they will be incorporated into the model.
A wrongly chosen mullion will result in the system
rejecting the component and informing the operator
to this effect.

3. 8 Costing routines
The COMDAC costing routines have been con-
ceived as a two part package based on the
recently developed Building Industry Code (BIC)
and designed to assist the architect throughout
the development of his designs. The first part
of the package is a costplanning aid, entitled
COSTPLAN. This program is intended 10 be
run much earlier than the rest of COMDAC, at
the initial stage of the design process and before
the form of the building has even been conceptua-
lised. Its purpose is to provide the architect
with data on the cost or area impfuations of a wide
variety of possible combinations of storey height,
perimeter length and partition length. It is
anticipated that the use of COSTPLAN will also
enable the designer to make on-going cost checks
of his design during its development which should
result in a reduction in the number of schemes

507
 that are rejected or that require to be significantly
modified at a late stage in their development. For
the same reasons, COSTPLAN is intended to make
the use of the remainder of the COMDAC package
more efficient by reducing the amount of computer
time wasted in lengthy attempts to bring a design
down to a cost-target that, given the form and
size of the building, is unachievable.

Current output from COSTPLAN is a printed

hardcopy but it is anticiptated that lat er versions
will incorporate a graphical representation. of the
same information which will be much easier to use.

3. 9 An embryonic version of the second part of the

costing package is also running using non- graphic
data. A developed version will directly evaluate
the internal computer model of a building which is
currently being written under the name of
COSTCHECK. This program will be used in two
forms. The first form will print out an area and
unit rate based elemental breakdown of the building
cost on the same lines as COSTPLAN for which it
acts as a check. The second form of the program
will present the user with a Feature breakdown that
will operate not only by computing costs from areas
and unit rates as in the first section, but also by
searching internal component catalogues.

3. 10 The development of all these costing programs

has involved an on-going liaison with local
authority quantity surveyors and it is anticipated
that the scope of this relationship will increase
as the programs enter the development stage.
With this factor in mind the logic of the programs
has been designed 10 make the addition of detailed
modifications an easy task.

3. 11 Heatloss
A simple evaluative routine has been written
which computes the heatloss through the fabric
of a building as part of the costing routines, thus
enabling the computer to arrive at a figure for
the cost of the required heating plant.

508
3.12 Steelwork
Some progress has been made towards developing
a steelframe design facility as an addition to the
COMDAC package. An initial analysis has been
made of the syntactical rules governing the
assembly of the steelwork system and a possible
approach to the problem of automating the process
of steelframe design is being investigated.

3.13 The programs that enable the above activities to be

carried out can be regarded as being at four levels.
with the higher level programs depending on those
at the lower levels. The four levels are as follows:
Level (1) Primitive and hardware oriented.
Level (2) Complex information handling.
Level (3) General purpose. user oriented.
Level (4) Application oriented.
Of these levels. 1. 2 and part of 3 can be classified
as ' Support Software' whilst the remainder of
Level (3) and Level (4) can be thought of as 'Surface
Software'. Sufficient Support Software must be
available to provide the facilities required before
the Surface Software can be implemented. Support
Software routines are as follows:
1 ICL 4100 Executive and associated routines
2 NPL DISGOL defined as 'A Macro system with
a Data-Structure aid for Graphical Display
programming. '. which contains facilities at
Levels 1, 2 and 3.

3 COMDAC modular programming scheme,

which provides facilities for using separately
compiled Algol programs as modules, which
contain sub-routines called from an Interactive
Control Program. This enables an overall
control of all interaction and also allows for
program modules to be interchanges. This is
a Level (2) facility and is described in more
detail below.
4 Stack Handling facilities exist within the
modular programming scheme and enable
parameters to be passed from the ALGOL
509
 sub-routines to the Interactive Control and to
other ALGOL sub-routines. The stacks may
also be used for other purposes within the
y
particular sub-routines. This is also a Level
(2) facility.
5 Name Table and Association Hing facilities
also within the modular programming scheme.
These are Level (2) extensions to DISGOL. The
N arne Table will be used for the following
purposes:
a) to name DISGOL data structure elements
b) to name items in a catalogue (e. g. building
components and design units)
Association Hings are an extension to the data
structure enabling greater connectivity than is
at present provided. It will be used, for
example, to ring all similar components,
enabling them to be easily counted.
6 Display File Compiler. John Sexton of the
Computer Science Division of the National
Physics Laboratory has designed this facility.
which will enable a structured two dimensional
group of symbols, (for example, a schematic
representation of a building) to be represented
on a large drawing board area in pseudo display
code. A group of these symbols can be scaled,
scissored and converted into display rode to
appear within a 'window' on the display. The
display user will be able to transform symbols
shown on the display and this will be achieved
by transforming the pseudo code and recom-
piling a new display code. The transformations
available will include expansion, contraction,
rotation, mirroring and moving. The Display
File Compiler is part of the Level (3) support
software required .

.7 Background Data Structure for the three

dimensional model of the building with its
constituent associated properties. This data
structure is completely internal to the machine
and must provide:

510
 a) no restrictions on the type of connectivity
i. e. a graph structure
b) associative capability - to enable objects
to be found from their properties.
Due to its large potential size, this structure
should ideally be on backing store. Because
of the current lack of backing store at NPL
a cut down version of the three dimensional
model with limited associated properties is
used. The background data structure will
consist of an extended DISGOL structure which
was originally intended for structuring graphics
and is, therefore, not ideal for this purpose.
The three dimensional model will be constructed
from information in the structured pseudo
display file by means of an 'up' compiler.
Conversely, a structured pseudo display file
will be set up from the three dimensional model
by means of a 'down' compiler. This will
enable the two dimensional pseudo display file
to contain code for a plan or elevation of a
particular aspect of a building at a particular
scale. The display file compiler is a Level (3)
facility.
8 Comppnent Catalogue: this is in the process of
being designed. As with (7) it should ideally
be on backing store because of its very large
size. Because of the lack of backing store our
approach is only to provide information about
components which are critical to the design or
evaluation process at any particular stage.
This policy means that the catalogue will be on
many paper tapes. Internal to the machine
there will be a one dimensional dynamic
associated data element reserved for the
catalogue which will be partitioned into
separate files. Each file will contain data
about a particular component, for example,
permissable sizes, permissable connections
to other components, properties, pointers to
pseudo display file subpictures representing
the graphical symbols for a particular com-
ponent at the different scales, and a pointer

511
 to the name of the component in a name table.
Having a name table and a dynamic associated
data element means that the catalogue can
be updated in an on-line fashion. This enables
design units made up out of componets, to be
themselves made into a component with a
particular chosen name. This will allow, for
example, 'standard' storey height panels to
be designed by the user and repeated when-
ever required within a particular scheme.

3.14 The COMDAC Modular Programming Scheme,

mentioned above, consists of an Interactive
Control Program that has functions of setting up,
deleting and modifying the data structure. Once
a data structure element is set up, a sub-routine
irian ALGOL Program Module can be called which
initializes that data structure element, providing
for example, a light button on the screen. A
program or operator action putting attention on a
data structure element causes a program jump to
a reaction initiating piece of program in the Inter-
active Controller. This reaction initiator calls
the reaction sub-routine in an ALGOL Program
Module. The Support Program provides NEAT
sub-routines that either the Interactive Control
Program or ALGOL Program Modules require.
Each ALGOL Program Module consists of several
labelled sub-routines. Each of these sub-routines
returns after completion to the Interactive Controller.
There is a necessity for passing parameters from
the ALGOL sub-routines to the Interactive Control
and to the other ALGOL sub-routines. An Integer
and an Integer Array Stack are provided for this
and other purposes. The scheme provides for an
overall control of all inter-action and for inter-
changeable program modules that may be pre-
tested separately.

512
 COMPUTER GRAPHICS IN ARCHITECTURE

J. H. Williams

I.e.G. Systems, Interactive Computer Graphics,

6 St. James Avenue, Boston, Massachusetts 02116,
U.S.A.

In using the computer to assist in scientific or

semi-scientific endeavors, there has been a tendency
to mold the problem to be solved to the techniques,
rather than to mold the techniques to the problem. For
example, it is possihle to draw high precIsion
perspective views of a building using a very expensive
mechanical plotter. However, an architect does not
have a high demand for perspectives in his design
process, so the architect's need for mechanical
perspectives does not offset their hi~h costs. Using
the computer to assist architects has often taken this
kind of direct, straight-forward approach, which in
many cases has been disastrous. Another instance of
fitting the problem to the technique is in using
interactive computer graphics of the CRT variety. The
tendancy here has been to translate verbatim the
activity of the drafting board to the face of the CRT;
for example, using the interactive computer device to
draw an orthographic projection the same way the
designer is doing it manually on the drafting board.
This was a mistake because really what the computer is
best suited for is drawing and manipulating volumes.
In any case, we have found through our own experience
that the need for using computer graphics cannot be
predicted. Rather, a well substantiated requirement
for computer graphics occured to us indirectly while
using non-graphic computer techniques. The evolution
of this requirement will be discussed by this paper.
Generally speaking, there appears to be a scarcity of
viable computer appl ications in architecture,
particularly in the area of computer graphics. The
architectural profession appears to have been over-
513
 looked by the computer industry. This probably arises
from computer people not understanding the architect's
problems, and the architect either being not
interested or unable to understand the potential of
using computer technology. The Architect has had his
hang-ups in entering the field of computers. Probably
a combination of temperament and training has resulted
In his being non-numerically and non-mechanically
oriented. In addition, anyone who has practiced
architecture soon becomes involved in the day to day
problems of following a project through the office,
leaving little time to sit down and learn rather
compl icated new techniques. Then of course, there is
the age-old and rather trite fear that the computer
will invade the architect's involatile, intuitive
domain. His usual reply to computer specialists has
been; "I can do a better job intuitively than your
computer can do." When the Architect finally does
come to terms with the computer, he may find that
some new problems arise. One problem is his
difficulty in conforming to a systematic and sl ightly
scientific procedure in hammering out a design,
particularly in the early Programming and Schematic
stages. Perhaps the architect has difficulty in
really sitting down and analyzing the building
program, considering each space , relationship and
requirement and juggl ing all of these things in his
own mind while laying out a partie
AUTOMATED SPACE ALLOCATION TECHNIQUES
As a response to this dilemma, the architectural firM
of Rich, Phinney, Lang & Cote', Inc., in Boston,
Massachusetts has been experimenting with a new
computerized technique for automated space allocation.
The bulk of this paper will deal with this firm's
experience in using computer techniques and the
conclusions that. were reached which seem to indicate a
strong need for using computer graphics.
THE USER'S ENVIRONMENT
First the environment in which we did our study. The
architectural firm of Rich, Phinney, Lang & Cote, Inc.
Is a moderately sized fir~ of about 40 people which
special izes in school s. The fi rm was intrigued with
the computer technology they saw developing around
them. Boston is recognized as one of the centers of
advancing computer technolo~y in the United States.
514
After a period of research and experimentation, they
took a new path which most architectural firms had
either overlooked or not known about. They were
reluctant to install an in-house computer with all its
companion problems of staffing and providing space;
rather they took advantage of the technology available
in the field of time sharing. They installed a
terminal to a highly sophisticated and powerful time
sharing system.
Prior to this, the firm had developed batch oriented
computer programs including cost estimating, office
management and pupil population projection programs.
These programs and projects addressed themselves to
the later phases of design. The earl ier phases,
Programming and Schematic, had been overlooked due to
their esoteric nature. To shorten these finite time
periods would be equally important in compressing the
time span of designing a building. This firm thus
decided to concentrate its efforts upon applying
automated space allocation techniques to the early
stages of design.
Fortunately a computer program was available which
allowed the firm to avoid getting involved in a period
of R&D. The original computer program which RPlC
used in the space allocation study was called CRAFT
and was obtained from the IBM share program library.
The program was written as an academic exercise in
1965 by G. C. Armour and P. A. Cramer(ref.l). As the
program was written in Fortran, implementation on the
RPlC time sharing system was no problem. However, we
soon found in using the program that the original
input scheme was very inadequate. Due to the
laboriousness of preparing the input, (the
relationship matrices and the site plan) a
preprocessor program was written by our staff. The
preprocessor allows the Architect to compress his
matrix by requiring only one half of the matrix and
the program then mirrors the matrix. Several other
features of the preprocessor will be discussed later
in the paper.
THE COMPUTER PROGRAM
What exactly is CRAFT? The acronym CRAFT, standing
for Computerized Relative Allocation of Facil ities
Techniques, is a computerized approach to automated
space allocation. As described by the program
documentation, .. This program embodies a new

515
methodology for determining sub-optimum relative
location patterns for physical facilities. It is
governed by an algorithm which determines how relative
location patterns should be altered to obtain
sequentially the most improved pattern with each
change, commands an alteration, evaluates the result
of alterations, and identifies the sub-optimum
relative location patterns. The computer output
yields a scale block diagramatrc layout of the
fac i 1 it y a reas and the a reas need not be equa 1 ."
(ref.!) As it employs a two dimensional approach,
CRAFT was originally used for studying the allocation
of factory space. However, the program Is a
general ized tool and the application of this tool to a
variety of planning problems is only limited by the
imagination of the user. The program produces only an
abstract diagram of the building spaces. The program
does not produce anything resembling a building plan.
In using the CRAFT program, the greatest challenge to
our staff has been to translate thls crude diagram
into a reasonable building partie
The program utilizes two matrices and an origInal
layout as the initial input. The layout Is a plan of
the building using groupIngs of the department numbers
to indicate areas. The manner in which the building
and/or site may be described in the InHlal layout Is
quite arbitrary. The matrices are used to indicate
relationships between departments. The relationships
Indicated by the matrices can be defIned by the user.
The effectiveness of the fInal layout is highly
determinate upon how well the destgner can quantify
the values assigned to the relationship matrices.
A complete methodology for using CRAFT was developed
around the experience of using the program In three
actual building design projects. We worked very
closely with the architects in developing our
methodology on these projects: The Avon High School
project; the Bridgewater State Teacher's College
project and the Canton Junior High School project. We
developed the methodology from the Avon and
Bridgewater experiences and stuck very closely to it
in coming up with a design for Canton. On the first
two projects we came In late, in that CRAFT was used
in conjunction with the straight, intuitive design
process. However, on Canton we used CRAFT throughout
the preparation of the preliminary scheme.

516
relationship matrix with the other being filled with
l's or unity; (2) being able to use 2 matrices that
were identical and (3) being able to use 2 separate
and distinct matrices. These alternatives could be
chosen while working on-l ine at the typewriter
console. With alternatives number 2 the two identical
matrices were multipl ied together. This allowed a
logarithmic bias to be given to the higher numbers
causing those areas that required strong adjacency to
be strongly drawn together. Assigning a relationship
value of 5 would actually mean 25, 4 would be 16, 3
would be 9, and so on. It is important to real ize
that CRAFT works in a positive way to draw two
departments together and does not negatively repel
those departments that should not be together.
THE INITIAL LAYOUT
The matrices were filled out during interviews held
with cl ient, architect, and consultant. Various
techniques were tried, such as having School
Principals and Department heads fill out individual
matrices and having the architect combine them into
one. It was necessary for the ground rules to be
clearly understood. _It was decided that in
determining relationships, the criteria of (a) flow of
people, (b) flow of goods, and (c) flow of information
should be used.
In preparing the plan or original layout input to the
computer several rules had to be followed. The
program was limited to handling 40 separate
departments. The shape of the building had to be
represented in a rectangle. To accomodate irregularly
shaped sides of bui1dings, dummies were used which
were unassigned activity areas. These dummies were
used to fill in irregularities in the plan of the
building. The dummies were given zero (0)
relationships in the matrix. There were also several
illegal activity area configurations: Activity areas
or department~ could not have multiple indentations
along both axes x and y, no departments could be
disjointed, and no departments could touch at only one
corner (figure 1). The maximum number of units per
department was 75. tn other words, a department of 9
units by 8 units was maximum. These units could be
assigned any scale value. For example, one unit could
be used to represent 10 square feet.

517
figure 1: Illegal Area Configurations

D I

multiple
Ddisjointed touching corners
indentations
In preparing the input several iterations were gone
through in modifying the original input sheets. The
following forms (figure 2) resulted, which made it
quite easy for the architects to fill out a
relationship matrix. In addition, several different
size grid sheets were developed upon which the
architect could draw the building or site plan prior
to translation into computer readable form.
THE METHODOLOGY
In actually running CRAFT a three step methodology was
developed. Several optional steps were available but
were not used in the Canton study. The ~anton project
was considered as a prototype in that the 3 steps were
rigidly adhered to. The same relationship matrix was
used for the three runoffs. The output from one
runoff was used with some desk top translation for the
following runoff.
Run-off number 1; This run produces the most optimal
solution as all areas are free to position themselves
anywhere within the grid. In run-off number 1 all
areas were made equal. No area was fixed and site
features were included with the activity or department
areas. In addition a certain percentage of dummy
areas were interspersed in the grid so as to allow
free movement of the known departments. In making UP
the input plan, the architect attempted to guess at
what he thought the optimum plan should be. (figure 3)
This procedure resulted in a more optimal solution.
The running time for this iteration came to
approximately 90 seconds of computer timp..

518
THE RELATIONSHIP MATRIX
In preparing the relationship matrix we originally
thought that a hierarchical scale of one to five
should be used in stating the relationship between the
spaces. The relationship matrix indic~tes the re-
lationships between activity areas. These values may
assume any value the designer wishes to apply.
Several architects felt that a scale of 0 - 9 was
easier to understand both for cl ient and for
themselves. Using the 0 - 9 scale we felt that it
would allow greater distinction to be made between
activity areas. A lengthly discussion centered on
whether 0 - 9 or the 1 - 5 scale should be used. The
actual choice is really probably up to the individual
preferences of the architect or the user. We felt to
be consistent in our office that we should make a
decision and stick to one. Using the 0 - 9 scale we
felt that it would allow greater distinction to be
made between activity areas.
In using the 0 - 9 hierarchy, the architects worked
out a meaning to be assigned to these numbers. The
value nine (9) was used when considering Same Spaces
(such as a gymnasium divided into two sub-areas) and
was abbreviated SSe Seven (7) and Six (6) were
assigned the meaning Imperative Positive adjacency and
abbreviated IP+ and IP- respectively. Five (5) and
Four (4) were Desirable Positive adjacency and
abbreviated DP+, DP-. Three(3) was Neither/Nor (or
Neutral) abbreviated NN, Two (2) Desirable Negative
(DN), One{!) imperative Negative (IN) and zeroeO) was
NO Idea. Eight(S) was not used. They felt that in
having a cl ient fill in a matrix it was sometimes
difficult to remember the meaning of the numbers.
Therefore, a further sophistication to avoid unfair
bias was to assign symbols to the numbers, such as the
abreviations mentioned above or even a, e, i, 0, u.
lengthly discussions were held in the office on the
subject of the relationship matrix, often with
opposing view points. The 0 - 9 scale was finally
used for the Canton study.
As I mentioned earl ier, the difficulty of preparing
the input files for the computer program led us to
develop our own preprocessor which allows the user to
work interactively with the program and prepare his
computer run. The preprocessor allowed the user to
choose between an alternative of using; (1) a defined

519
 figure 2: Relationship Matrix Forms
(departments/activities)
fine arts A-Ol

commercial educa~ion 8-02

homemaking C-03
industrial arts 0-04
physical education E-05
physical sciences F-06
dept. resource center G-07
interchange. classrooms H-08
cafeteria - kitchen 1-09
library J-I0
remedial instruction K-ll

student activity L-12

jr. high administration M-13
guidance N-14
health unit 0-15
teachers rooms P-16
custodial service Q-17
special classrooms R-18
study hall $-19
playfields T-20
scale: IN
ON parking lJ-21
NN
OP- vehicular service V-22
OP+
I,p_ central administration W-23
IP+
(matrix prepared by L. Brown of RPLC, Inc.)

520
figure 3: Run-off Number 1 I INPUT
o
3
33
525
2233
33332
132113
2521167
33422333
132113572
2321233435
53333323522
143113333332
1331133523337
33333434333363
333333353333333
2323211141112133
35333636443545432
232226364422343312
5233733232234233132
54555332533355331223
424522225222243371222
11111111111113331111334
one-half of Relationship Matrix

0101020203030404050506060707
0101020203030404050506060707
0808090910101111121213131414
0808090910101111121213131414
1515161617171818191920202121
1515161617171818191920202121
2222232324242525262627272828
2222232324242525262627272828
2929303031313232333334343535
2929303031313232333334343535
initial department(activity) layout

Runoff number 2; The output plan diagram produced by

Runoff number 1 was inspected by the architect.(figure
4) Referring to the matrix, he determined abutting
departments that had low adjacency requirements. These
groupings of related departments were then broken into
sub-systems; i.e. classrooms, physical education, and
service.(figure 5)

521
figure 4: Run-off Number 1 /OUTPUT /System Diagram
1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 CC CC X X F F S S
K K Y Y Z Z
2 CC CC X X F F S S
K K Y Y Z Z
3 DO DO B B R R H H J J G G GG GG
4 DO DO B B R R H H J J G G GG GG
5 Q Q V V I I 0 0 M M N N AA AA
6 Q Q V V I I 0 0 M M N N AA AA
7 EE EE 0 0 C C P P U U W W HH HH
8 EE EE. 0 0 C C P P U U W W HH HH
9
10
FF FF
FF FF
A A L
A A L
L
L
T
T
T
T
E
E ""
E BB BB "
E BB BB "

figure 5: Run-off Number 1/ OUTPUT/ Sub-Systems

1 2 3 4 5 6 7 8 9 10 11 12 13 14
1
2
3
"5
6
7
8
9
10

Translation of CRAFT output

CRAFT runs of these sub-systems were made producing

relationship diagrams for each sub-system.(figure 6)
The architect then proceded to design the building.
The total system and sub-system diagrams were used by
the architect as "critical yardsticks" against which
he could check his design.
figure 6 : Sub-System Diagrams
1 2 3 4

1 C B 0 K
2 F A G H ~
3 I J E l

CRAFT output for physical education Translated Diagram

522
When a building parti was designed, CRAFT was used to
check (or critique) his design. The input plan was
produced with areas made to approximate the designed
areas in their shape. The original matrix was used. A
CRAFT Run-off was made to determine if the parti plan
could be improved upon by checking against the
original relationship matrix.(figure 7)

figure 7: Checking the Parti

AA SS CC SS GG HH
- - - . . ,._ DO EE FF - ___
~- AA CCOD _______
GG HH II EE FF II

Pa r t I CRAFT Input CRAFT output Translated

The technique described above became the standard

office procedure for using CRAFT.(figure 8) Several
optional permutations on CRAFT were developed and are
described below.
figure 8: CRAFT Methodology

• • --
•
(1) no areas fixed
equal areas
include % of dummies
•
(2) break into sub-systems,i .e.
classrooms, physical ed.,
1111111111 industrial

(3) TRANSLATION: break into

sub-systems. Produce diagrams of
sub-systems.

(4) "DESIGN" against these diagrams.

(5) Test Parti: use original matrix.
use actual areas.

523
OPTIONAL CRAFT PERMUTATIONS
Run-off number 3; The layout output from run-off 2
was used, with translation as the input for Runoff 3.
We used a somewhat contrived technique for studying
vertical relationships for a multi floor building.
Somewhat arbitrarily, but nonetheless recognizing
groupings of activity areas which had been indicated
by Runoff 2, we divided the building into three
floors. We then separated these floor areas with
large fixed dummy areas. What CRAFT did was attempt
to satisfy relationships by shifting departments or
activity areas from floor to floor across this zone of
fixed dummy areas. If a shift was made from the number
one floor to the number three floor the reason had to
be very strong.(figure 9) Running time for this
iteration was approximately 20 seconds.

figure 9: Multi-floor study/ OUTPUT(Bridgewater)

TRANSLATED TO

fixed dummy areas

Run-off numbe r 4; I n run-off numbe r 4 we s tudi ed the

building and the site together. Here we fixed
permanent features such as the unbuildable areas, the
tree line to be maintained, the playground and
accesses. We floated the building and included dummy
areas within the site. In fact, dummy areas were used
to approximate the shape of the site, and were then
fixed.(figure 10) The run-off time for this iteration
was approximately 40 seconds. This completed the
number of run-offs that could be done with the
original matrices.

figure 10: Site Study/ OUTPUT(Bridgewater)

TRANSLATED TO
BD
CJCJ
DO

524
Run-off number 5; This Run-off was a variation on
Run-off number 2. It required a new matrix which
described the relationships between sub-areas or
sub-systems of the building. In this case we
attempted to study the results of identifying
relationships between the sub-systems and
incorporating circulation. Circulation was fixed and
such things as 1 ight wells, stairways, etc. were
related to sub-systems and allowed to float.(figure
11) Running time for this iteration was 30 seconds.

figure 11: Sub-System Study

AA B CCC
AA B CCC
BBBBBBBB TRANSLATED TO
DDDDDDDD
DDDDDDDD

Run-off 6 studied the intradepartmental relationships

where we fixed both circulation and access and allowed
the sub-systems to position themselves.
People doing research in computer-aided design have
indicated that the use of computers for studying
layouts of buildings was in its infancy. They felt
that the use of these techniques was held back by the
unsophisticated and mathematically simplistic computer
software that was available. Surprisingly enough,
however, we found that the computer application
program was more than adequate. The difficulty in
using the computer program was not in the
sophistication of the program itself, but in
incorporating this new tool into the design process in
a meaningful way. Again, the need to develop a
methodology where the computer is adapted to the
problem rather than the problem to the computer. The
program itself proved to be simple enough for the
architect to comprehend and incorporate into his way
of thinking about putting a design together. The
difficulties as mentioned earl ier were in quantifying
his decisions and documenting them in an historical
and orderly manner.
PROBLEMS ENCOUNTERED
As the science of computers is actually many miles
away from the practice of architecture, the major

525
problem was in understanding the language of computers
and translating the language from one form to another.
Specifically the problems that we ran into were that
it was difficult to assign meanings to the values
which we used in the relationship matrix. For the
output to be valid one had to apply the same criteria
to all departments. For example, one could not relate
department 1 to department 3 with criteria toward flow
of goods and then relate department 1 to 5 with
criteria being flow of people. To be able to properly
fill out a matrix required a period of education for
both architect and client.
The negative results in our office was a tendency to
overemphasize the computer solution both in what it
could produce and what it threatened to the architect.
It is wrong to consider that the satisfaction of
adjacencies is the only problem to be solved in
designing a building. It actually occupies a very
small percentage of the problems to be considered;
others being light, space, etc.
POSITIVE RESULTS
There were some positive results from our study.
Although we had to go through a prolonged and painful
process in developing our methodology, we nontheless
developed a technique that drastically reduced the
time spent in designing a building. The essence of
the technique, of course, was that the computer was
used to solve a numerical problem of relationships and
freed the architect for more creative work. Prior to
applying this technique our architects often spent a
great deal of time going through the prel iminary stage
of designing a building. Working in an unsystematic
manner often forces one to repeat decisions and steps.
Forcing oneself to organize and work through the
design of a building in a systematic manner moves
things along much faster. The computer cost of
running CRAFT came to approximately $200. This was
considered insignificant in terms of the $10,000 or
more that might be spent in the preliminary design
phase.
A side benefit of working with the matrices was that
once the definition or the hierarchy of assigned
values was understood and could be related to the way
people thought about a building, a vehicle was
provided by which the architect and cl ient could

526
communicate on common ground with an absence of
jargon. The result in considering each department's
relationship to each other department was that the
architect and client were forced to think about all
the elements of the building in an orderly and
systematic way. In addition, when the client was made
to understand why he was filling out the matrix (i.e.
to produce a rudimentary layout) he felt as though he
had participated in the design of the building. As a
result, the architect found that he had to make fewer
iterations in designing the building so as to please
the cl ient.

Translating lines to charactors and numbers and then

re-translating the output from numbers to lines was
laborious. A page full of characters tells nothing
about the building and does nothing to stimulate the
creativity of the architect.(figure 10) What the
architect needs is aline drawing. Obviously computer
graphics could have sped the process up considerably.
Computer graphics would have allowed us to interact
with the layout drawing, modify it sl ightly and then
re-run CRAFT. What we were after was a technique
which would cause the architect to think of new
possibil ities that he might not have otherwise thought
of because of his own inbred subjectivity. The
important thing, however, is not to see how many
permutations one can do in using CRAFT. The in-put
can be modified or juggled in a variety of ways. The
importance is in progressing from generalities and
randomness to greater specificity.
A further sophistication of CRAFT might have been, in
addition to having the plan described as lines rather
than numbers and charactors, to have related the
building to the topography of the site. Also, it would
have been useful to have produced a volume study out
of the 1 ine plan drawing. The greatest problem in
using this computerized technique actually boils down
to the inadequacy of the input and output produced and
the difficulty of preparing and interacting with the
input and output.
THE NEED FOR COMPUTER GRAPHICS IN ARCHITECTURE
This finally gets us to the final point of recognizing
a strong need for some kind of interactive computer
graphics. As stated earl ier the intention in using

527
CRAFT was to shorten the time in doing a preliminary
design and as a result allow more time for design
development. In a process where each phase takes a
finite amount of time, architects tend to get hung up
in the programming phases of design and those
decisions immediately thereafter. Although CRAFT
shortened our design time we nonetheless spent a great
deal of time converting and preparing layouts and
relationship matrices. In general, what was needed
was the ability to input data in an architectonic
form, in this case lines. The abil ity to
interactively and easily modify that data and the
final producation of output in a form understandable
and famil iar to the architect a definite requirement.
The actual production of a 20 plan drawing of a
building appears to the computer special ist as a
fairly mundane appl ication. However, the impact and
the importance of providing this kind of output is
incredibly dramatic when used in conjunction with a
tool such as CRAFT.
From our experience with CRAFT we gradually evolved a
need for computer graphics techniques. This need
occured to us indirectly. Although it is easy to see
that there will eventually be a requirement for
sophisticated interactive computing with dynamic CRT's
and multiple-pen high-speed mechanical plotters, the
interim requirement for a rapidly changeable
inexpensive graphic device is clearly evident. It
appears then that the techniques of storage tubes and
thermal or electrostatic plotters would offer a great
deal of flexibil ity which would be within economic
reach of most architects. The step that we have taken
therefore is to begin to specify the type of
configuration that we feel is necessary for the
architect to effectively util ize computer graphics
techniques.

REFERENCES
(1) Armour, Gordon C. and P.A. Cramer, "Computerized
Relative Allocation of Facil ities Technique (CRAFT)",
Share Program Library, September 1965.
(2) Armour, Gordon C. and Elwood s. Buffa, "A
Heuristic Algorithm and Simulative Approach to

528
Relative Location of Facil ities", Management Science,
Vol. 9, No.2, January 1963.
(3) Martin, T.,D. Miles, and G. Oommen, "Craft
Technique: Constraints and Capabil ities",
Unpublished Report, Harvard School of Design, January
1970.
( 4) Brow n , Le s 1 i e I.," Can ton Craft, A Report on a Real
Architectural Project Using Computerized
Design",Unpublished Paper, Boston Architectural
Center, January 1970.

529
 THE CRAFT PROGRAM
IMPROVEMENTS AND PROPOSED
IMPROVEMENTS

1. Rohn

Sussex Research Associates Ltd., 25 Duncan Street,

Toronto, 2B Canada.

I NT RO DUCT! ON

CRAFT is a program which optimizes a given building floor plan according

to numerically defined proximity criteria. The basic program was developed
at the Graduate School of Business Administration, University of California
Los Angeles, by P.A. Cramer and G.C. Armour, for the layout of machinery
in factories. Since then, it has had few commercial applications, but has
been reasonably well known in academic architectural circles. It has been
distributed in Canada and the United States mainly by I.B.M. as part of
the SHARE library of programs.

OUR INTENT

We \'Janted to make addi ti ons and changes to the CRAFT program that waul d:
1. produce graphic output which more closely resembles the
conventional drawing format with which designers are familiar;
2. reduce the complex input so that a person unfamiliar with
computer programming could easily learn to use the program; and
3. by accomplishing 1 and 2, make the program more useful as an
easily understood introduction into computer techniques for
architects, interior designers, and related professionals. After
a minimum initial period for familiarization, it was hoped that
a client could use the program without further assistance from
consultants.

531
THE STATE OF THE CRAFT PROGRAM ( as distributed by I.B.M. )

1. Internal Manipulation

The program takes an initial input plan, calculates the right-angled

distance betvJeen the centroids of two department * areas, and multiplies
this distance by the value of the interrelationship between these areas,
as defined by a department interrelationship matrix. This is repeated in
sequence for pair combination of departments, and the results are summed.
This sum is a prox'imity measure " of hm'l well the departments are
II

located, relative to the desired proximities tabulated in the inter-

relationship matrix.
To improve this initial plan, the program goes through a series of
department exchanges, reevaluating the plan layout after each exchange.
Exchanges whi ch improve the proximi ty measure are retai ned; those whi ch
make no improvements are rejected.
Exchanging departments of unequal size is done by a set of carving
II II

routines which, although very complex, impose severe limitations on the

ability to exchange departments. Therefore, before the program tries
exchanges, it first establishes which exchanges are possible.
There are three classes of exchange possibility:
l. Department pai rs having a common border;
2. Department pai rs of equal area;
3. Department pai rs bordering on a common third department. ( This
so call ed three department exchange is really a two
II II

department exchange across a third department ).

No exchange is possible for:
1. Department pairs having one department or both departments
defined as fixed;
2. all other department pairs.
Before making an actual trial exchange of two departments using the
carving routines, the program makes a provisional exchange by just re-
defining the centroid of one department area as the centroid of the other
* ',' Department means an area of the bui 1di ng whi eh operates as a di s ti net
functional unit. It can consist of one or more rooms, or just part of a
room.

532
department area, and vice versa. The proximity measure of the plan is then
recalculated and checked for any improvement. If none has occurred, this
exchange is rejected and the program tries the next exchange possibility.
If an improvement does occur, the exchange is recorded. The program
continues to try all the other exchange possibilities until it has selected
the provisional department pair exchange which gives the greatest estimated
improvement. The exchange at this point is still only a provisional
exchange because the shift of centroid locations resulting from the
difference in department areas has not been considered.
The program now creates a new partial plan of the two departments being
considered. On this plan, the carving routines try the actual exchanges of
area. The new centroids are calculated and the total plan is reevaluated.
If there is still an improvement, the partial plan is dumped into the total
plan and the complete process described up to now is repeated. If an actual
area exchange results in no improvement, the partial plan is discarded, and
the program tries the provisional department exchange which gave the second
highest estimated improvement. Exchanges continue to be made until no
further improvement can be found.

2. Summary of Input and Output

Input: 1. two interrelationship matrices:
a) movement between departments
b) unit cost of movement between departments
The two matrices are multiplied in the input routines to
derive the department interrelationship matrix which is used
in subsequent manipulations.
2. an initial plan
3. a list of all fixed departments
4. parameters controlling:
a) post mortem routines if the program should bomb;
b) intermediate printouts of successful exchanges;
c) intermediate printouts of unsuccessful exchanges;
d) intermediate printouts of estimated improvement of the
proximity measure;
e) the restrictions on the categories of exchange
possibilities to be tried.

Output: 1. plans of a semi-graphical nature ( alphabetic characters );

2. input listings;
3. parameters and values of all the inputs.

533
Critigue of the CRAFT Program

When we first experimented with the program, we noticed three main

limitations:
1. The input was unnecessarily cumbersome. There were too many
irrelevant variables, which made it difficult for a person
unfamiliar with computer programming to use the program.
2. The output, although semi-graphical, was not a useful graphical
representation of floor plans. Representation of areas by blocks
of alphabetic characters hindered quick recognition of the
changes in the plans, and thus prevented ready evaluation of the
plan improvements. It also made it difficult to recognize the
building outline, since dummy departments were coded in the same
way as all other departments.
3. The plan size and the number of departments allowed was
unnecessarily limited by non-variable programming. Although this
restriction was less serious, it did res~lt in over-simplifica-
tion of some building plans.
A further limitation of the program is the hill-climbing algorithm, which
does not guarantee an absolute optimum plan. This can be partially offset
by more careful consideration of the initial plan, running the program
several times, or making all departments equal in area.

Changes and Additions to the Program by Sussex Research

Basically, our changes to the program were a simplification of the input

and changes in the graphic output. Our goal was to make as few changes as
possible and not to increase the running time. To meet these constraints,
the printer had to be retained as the graphic output device, rather than
using a CRT or plotter. Since the printer has serious output limitations
for graphics, the plan output had to be very carefully defined. It
requi red:
- reasonable proportions
- clear identification of departments
- clear identification of building outline
- clear identification of an exchange of departments at each iteration.
We met these requirements by:
- using "+", "_", and "1" as the delineators of the areas ("+" was
used for the corners of areas )

534
 - proportioni.ng two "IllIs vertically to three "_IllS horizontally in
outlining areas
- printing the identification number of the departments in the top
left hand corner of its area
- supressing the printout of all dummy departments
- starring the border of exchange departments at each iteration
- listing the names of the departments with their associated numbers
after the final plan printout ( optional).
With some other minor changes, such as the removal of superfluous program-
ming messages and the calculation of percentage improvements from the
initial plan, we achieved our intent of making the program output easily
usable by the non-computer oriented user. Three changes then had to be
reflected in the input. The changes were made as follows:
1. all control parameters were put inside the program and a
standard input-output relationship was adopted
2. provisions were made for the identification of the dummy
departments
3. all values and numbers in the input were reduced to integers.
Although our intent was mainly centred in the input-output routines, we
realized in our appraisal of the program that the array sizes determining
the maximum size of layout had to be enlarged. As we enlarged these arrays
we made all size parameters within the program variable. The size of plan
and the number of departments in the revised program are limited only by
machine configuration. Since we wanted to enlarge the program without
being penalized by large core-requirements, we cut down all integer arrays
into half words.
Some changes were also made necessary to implement the program on a time
sharing system. Altoqether the changes took one man month, most of which
was spent removing the limitations on array sizes.

CONCLUSION

In terms of making the CRAFT program more useful as an easily understood

introduction into the computer techniques for architects, interior
designers, and related professionals, the changes and additions to the
program have been reasonably successful. However, the experience which we
acquired in making these changes has made us aware of more basic
limitations in the program. These, we feel, can be overcome by further
changes in the basic structure of the program.

535
FURTHER CHANGES PROPOSED

1. The need for an input plan can be eliminated. The program should have
the capability of creating an initial plan from a space inventory list
interrelationship matrix, and building constraints. Other iaYGut
programs have been investigated for this task ( ego ALDEP ), but they
have some very undesirable limitations concerning perimeter
configurations and have the same hill-climbing properties. New input
routines will have to be created, but these will have to be examined
carefully for their affect on the carving routines.
II II

2. A better optimization of the proximity measure could be achieved by

varying the department areas between limits and randomly choosing
among the exchanges giving an improvement rather than taking the
exchanges giving the highest improvement.
3. The complexity resulting from a large number of departments increases
the program's difficulty in optimizing the plan. The results are
unsatisfactory and running time is long. Large plans containing a
great number of departments could.be better handled by adding a very
rough cluster program. This program would identify all the meaningful
clusters of departments which have formed, redefining each cluster
as a new department, and would calculate the interrelationships
between these new departments. The plan layout could then be optimized
on the bas is of the reduced number of departments. After thi s Ilrough
tuning II the clusters would be decomposed again into the original
departments, and the program woul d make a more fi ne ly tuned
II II

1ayout.
4. The program should be able to handle more criteria than just proximity
relationships. For example, a binary matrix would be introduced to
reflect desirable perimeter contact but indifference to distance
when that perimeter contact is not made ( ego proximity to windows ).
There are many sets of data similar to these which need definition.
The program would handle these data matrices according to priorities
unless it could reduce them to a common data base.

At present these improvements to the CRAFT program are in various stages

of programming. Sussex is continuing its work on space allocation as one
component of a program package for architects and design professionals.

536
 APPENDIX
An Example

537
DEPARTMENT INTERRELATIONSHIP MATRIX
1 2 3 4 5 6 7 8 9 10111213141516171819202122
1
2 5
3 7
4 3 3
5 3 5 9
6 3 7 7 7 5
7 5 5 3 5 7 5
8 example: department 11
9 3 3 rel ates to
10 5 3 3 3 3
11 7 3 3 3 7 3 5 3 3 7 department 7
12 3 3 3 7 5 5 5 by a value of
13 5 3 5 3 3 3 3 7 5
14 3 3 7
15 3 3 3 3 5 3 3
16 3 3 5 3 3 3 3
17 3 9 9 9
18 3 3 9 5 5 5 9 9 9 7
19 5 7 7 3 7 3 7 7 7 9
20 9 9
21 5 5 5 5 7 5 9 3 5 5 5
22 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
o
50
070
0330
30590
377750 INPUT MATRI X
5535750
00000000
300030000
5303303800
73337353370
330375500050
5003533003370
00300000307000
303000303053030
0030000030533330
00000000000309990
003390000055599970
5007007003703777090
00000000000000009900
555575900355500000000
0000333333333333333300
00000000000000000000000
000000000000000000000000
0000000000000000000000000

538
 15 22 12 13 11

4
14 16 7

5 6

18 9

~ ~
17
19 21

3 10
~
8
2
1
PLAN OF BUILDING (with preliminary
1ayout)
In this example the building outline was
glven. The layout was dlrectly derlved
from a preliminary study of the plan

2 '4
d mnv rli mmy
f x d -c;x ed

3
(ur m
i e(

ADAPTED PLAN

Departments 23, 24, 25, have been added to fit the plan
into a rectangular matrix

539
15151515152525252522222222222222121212121313131311111124
15151515152525252522222222222222121212121313131311111124
15151515152525252522222222222222121212121313131311111124
1515151515252525252222222222222212121212 4 4 4 411111124
15151515151414141414141616161616 7 7 7 7 4 4 4 411111124
15151515151414141414141616161616 7 7 7 7 4 4 4 411111124
15151515151414141414141616161616 7 7 7 7 4 4 4 411111124
15151515151414141414141616161616 7 7 7 7 5 5 5 5 6 6 624
15151515151414141414141616161616 7 7 7 7 5 5 5 5 6 6 624
15151515151414141414141616161616 7 7 7 7 5 5 5 5 6 6 624
2323232020181818181818181818 7 7 7 7 7 7 5 5 5 5 9 9 924
232323202018181818181818181819191919192121212121 9 9 924
232323232017171818181818181819191919192121212121 9242424
23232323231717181818181818182323232323 3 3 310101010 8 8
23232323231717181818181818182323232323 3 3 310101010 8 8 z
23232323231717181818181818182323232323 2 2 210101010 8 8 c::(
-l
23232323232323232323232323232323232323 2 2 2 1 1 1 1 1 1 0...

23232323232323232323232323232323232323 2 2 2 1 1 1 1 1 1 f-
:::>
2323232323232323232323232323232323232323232323232323 1 1 0...
z
2323232323232323232323232323232323232323232323232323 1 1 .......

COST OF RUNNING THE PROGRAM

One run of the program costs between $0.50 and $27.00. The highest cost
has been incurred by the largest plan tried: 50x30 modules and 54
departments, the program going through 30 improvements. Running time
increases proportionally ( approximately) with the area of the layout.
A normal run of an average project can be expected to cost between
$1.00 and $5.00 ( commercial Data Centre rates, PDP-I0 time-sharing).
The example ran for 1.2 minutes at a cost of about $4.00 including
printout.

540
BUILDING DESIGN BY COMPUTER GRAPHICS

s. W. Crawley
Professor of Architecture, Department of Architecture,
The University of Utah, Salt Lake City 84112, U.S.A.

The views and comments expressed here are not from a computer
scientist but rather from a user of computer graphics who has
only a very limited understanding of the machine and the proc-
esses that instruct these machines to perform certain functions
However, I am involved in developing some systems and programs
that will assist the architect or engineer in the practice of
his profession, namely that of creating buildings or physical
structures, from their early planning stage to their final
occupancy.

To prepare this program requires a team effort between the

building designer and the computer scientist. No matter how
capable the computer scientist, he doesn't think and solve
problems like a building designer, and no matter how broad-
minded the building designer, he is terribly resistant to
change. Also the designer is reluctant to learn a new foreign
language in order to direct the machine. Consequently a com-
promise is required by both. Through mutual effort an inter-
active process can be developed that assigns to man and machine
those tasks each can do best, most efficient and most desirable.
To meet all these pre-requisites requires the use of computer
graphics.

I will present to you my crude overview of computer graphics

followed by a breakdown of traditional architectural and engi-
neering services. Then I will describe one program that is
currently operating and receiving some attention. This will be
followed by criticism of the operating program and some sugg-
ested proposals for removing these criticisms.

541
fl~URE I

computer graphics has a wide range of meaning and of interpre-

tation. My overly simple interpretation of computer graphics
is that it is commuQication with the computer that is essen-
tially pictorial in 'form rather than the usual alpha-numeric
form. It can be either input or output or both. It can be
essentially static (dealing with one specific picture or form)
or dynamic whereby there can be changing pictures or images.
A dynamic I/O is one that allows interaction with the program
while it is running. And finally there can be hand copy prints,
real objects having real dimensions or simply simulated ~n the
mind of the computer. Figure 1 summarizes this overall I/O
concept.
Familiar examples of I/O are as follows: (some are graphic)

a) Static input: punched cards, tapes, keyboard

touch phone, etc.
b) Dynamic input: teletype, light pen, stylus and
tablet, mouse, toggle switch,
track ball (all usually related
to a CRT)
c) Static output: tapes, cards, printed alpha-numeric
answers, printed graphic image from
a line printer, storage tube display
(photography), graphic image from
a plotter
d) Dynamic output: interactive CRT, teletype
This obviously doesn't cover the entire field and there are
bound to be some overlapping categories. However, for the

542
purposes of the comparison to building designer needs it is
sufficient.

FI4UP)[ 2

A
DPFlllE... .f
'8U~If..UW)
OPE~A. Tlol-J

o
t!OIi~"ffiUC.TIOW
~OIST!2.DL. ~'{
(~TA\Il!.1jQ)

In order to suggest in what manner computer services could be

of some aid to the architect-engineer in their professional
services, I have placed these services into four basic aspects
shown in Figure 2. They are: A) Business; B) Research or Data
Collection; C) Building Design and D) Construction Control.
static computer programs graphic and non-graphic systems seems

543
best to serve all aspects shown here except for Building Design.
It is in the design stage where the dynamic or interactive
computer graphics appears not only to be most useful, but in
my opinion, most promising for improved design. The design
process is very difficult to describe since it is a personal
type of activity. It could be said that design cannot be de-
fined, only described, and each will have his own description.
Perhaps my description along with Figure 3 will help explain
the process to those unfamiliar with design.

Usually the designer has only a vague idea of what is required

for a solution. He will not even be sure of the degree of im-
portance to be placed on the many aspects which must be exam-
ined on the way to the finished design. There is a long period
of digesting the ingredients of the problem, i.e., time climate,
money, use or function, etc. During this process the designer
usually discards many schemes and ideas that he might have
associated with the project initially. Eventually he places
degrees of importance on each and all the factors effecting his
design solution. The computer scientist would call these con-
straints. He then begins to assemble the pieces of a design
solution that attempts to meet all of the constraining condi-
tions, until there is a conflict requiring a compromise (or a
re-evaluation) of the constraints. He adjusts the parts and
reassembles until a whole solution or scheme is reached.

The important factor to emphasize here is that in all probabil-

ity there is more than one possible scheme. Indeed, a prolific
designer may have a hundred possibilities that need further
study and evaluation, or the stubborn designer may end up with
only one acceptable scheme (with perhaps a hundred minor
variations).
The parts of the design wheel (Figure 3) will be different for
each job as well as their degree of importance. The design
process could be started by entering at any point but must pro-
gress through each part at least once and frequently crossing
them many times before reaching the final synthesis (path shown
by the dotted line).
It should be apparent that the design procedure is a learning
process. As each part is considered, the designer relates it to
other parts and the assembled whole. To be very conscientious
in examining every part thoroughly could become long and tedious
and might become so dominate that it distorts all other aspects
thereby receiving more emphasis than originally intended. This
then is where computer graphics could be most helpful if the
precess were interactive and the turn around time reduced to
seconds.

544
Following the initial conceptual stage of a design is the devel-
opment or refinement stage. As has been implied, there may be
a variety of solutions that would seem to meet most of the orig-
inal constraints. As the design goes into the refinement step

F1~U~E. 3
f3~lkl A1
~fOlt-.l.T

it is entirely possible that the initial concept be altered com~

pletely without recognition. It is also equally possible that
the best refinement is never reached because of lack of time,
money, or the ability of the designer and his consultants. This
is another place where the computer could have a great impact.
One could evaluate an almost endless number of ideas with re-
spect to cost, structure, function, appearance, etc., all of
which could be used to reach the right synthesis if the infor-
mation were immediately available. Time is of essence and
computer graphics could display the needed information almost
instantly. If the turn around time is much longer than an in-
stant, the complex plot could be lost and the value of the in-
formation without meaning. The interactive cathode ray tube
seems to be the best assistant for the design process.

545
The program I have developed is a very simple one and it per-
tains to only one small aspect of the building design process.
However, it is interactive and allows the designer to explore
an almost limitless variety of conditions and have immediate
answers for each. The objective of the program is to determine
the degree of protection against radiation the building would
provide if the building were to be used as a fallout shelter in
addition to other daily functions. This quality is considered
to be one of the many attributes a building could provide.
All buildings offer some protection in this respect, but to as-
certain the exact amount requires a detailed analysis which is
time consuming and often a dull activity. If considered at all,
it usually occurs after the building design is complete and too
late for really influencing the design. The need for a design
aid is clearly apparent and the Office of Civil Defense request-
ed a computer-graphic method be prepared to meet this need. The
process should be easy and interesting for the architect to use
during his design development stage and provide immediate
answers.

FI ~ UR'c 4-

ID\ DI~1't.AY PDP-8 W.ltVMlloe

I I
I I I
'>YLVAUIA ltLf."NPmlIER ~~
Ul-llvMPlEA
t!A'fI..P
T~ t--~"'NI.U~ ~\~ .

The hardware used was that available in the Graphics Laboratory

at the University of utah at the beginning of this project.
Figure 4 shows the equipment used and was found to work quite
satisfactorily. The PDP 8 is necessary to maintain the display
on the CRT independent of the 1108, and a swapping system per-
mitted intermittent access to the 1108.
For expediency it was decided not to draw on the CRT by the
tracking process, but to begin the program by generating a stan-
dard image (START). Then, through a signal sequence, one could
alter, add, adjust, and manipulate the image in a variety of
ways in order to display the image of a proposed design solution.

Figure 5 shows the display on the CRT at the beginning of the

program. The left side of the display shows the plan and section
of a building. The right side contains a list of key signals

546
that are activated when the curser is brought in line with it
and the stylus tip switch is depressed. The value of the build-
ing, if used as a fallout shelter, is measured by the protection
factor which is calculated and continuously displayed. As the
building design is altered the prot-ection factor will change as
well. Also the value will change for different locations in a
building. The plan and section shows a cross mark (+) to iden-
tify the location of a detector which represents the point to
which the calculated protection factor is referenced. This
detector can be moved to any location within the building.

f1C.URE. 5
Wf...75
01A.RT
~TOP
ALn:R A..Ml~
W1.~
m~e
- ~
+
MOIC.~TOR
ItiT. PA~ITI~
r:::eu::n=..
w' R.COF 'NT.
'NT: 130
~'IIr,
WAll.. WT.
L~ F 13'

1'51
50'
A.~
MOlE-
~
,bpe:pqUfZ.e. 1d .?,
1.1
.~
MUlUAl- -61-tIELD
f'PtJTrLr1O\4. ~T~
efl
lt5'

wr..I~
WT•.r~

547
FI4U~E ~

WT.• IOD
51MT
IX-a" !STOP
+ WT.7S
ALTEPl PLANb
- t--- "!i-o"
B.iLAfZl4-e-
~'_QtI
ffOUtE.
MOVE- r::e:n:LlVP1
JUT. PA/'ZlTlTIOIJh
50' ~n=-
a (p' ?)tl:)F 'NT.
WT·\t~
I, FtLOPl.Wy.

" 'HAw.... WT.

(,' 1Ii-tf

1D'-<t+
g
'tJ 40
I 5
L 'Fl F 13 I ~'SQ

APCPffilFE. ~
10Gl
2
ALT'E-R 7
120' Mt}/E ~
MUTUAl6~1El..D

I
8'
+ WI. l~
(J

(.,.'
-1
""

Figure 6 shows one of the variety of displays that can be

created by the designer. The following film will be used to
illustrate the interactive process.

(Display the film)

Fallout Shelter Analysis by Computer Graphics

One observation and criticism of the program is that only sim-

ple buildings can be studied. However, even so, the value of
that instant feedback is enormous. Anyone could learn from
operating the program and this includes experienced persons in
fallout shelter analysis.

548
The system also offers the possibility of calculating the dis-
playing other attributes besides protection fact~r .. For exam-
ple, the graphic scale could be changed from asslgnlng roof,
floor, and wall weights to assigning roof, floor, and wall U-
factors and the total heat transmission loss for a given tem-
perature differential could be calculated and displayed. All
graphical routines could be maintained. A similar comparison
might be made for accoustical attributes.

While in the process of preparing this program we were of the

opinion that it could be expanded to include more complex
buildings. We no longer hold this view. An entirely new
system with a more universal basis must be used. This conclu-
sion is based upon the following reasoning.
We learned that there is an obvious limit on the quantity of
information that can be displayed on the CRT at anyone time.
This is not only from the point of view of limitations of the
hardware but also from the limitation of the human mind in
comprehending what it sees at anyone time. Therefore, it
seems necessary to have a system that would allow the manipulat-
ing of a limited amount of information, and the storing,
retrieving, and assembling of this data.
One reason the current fallout shelter analysis program is so
limited is because only one plan and one section is shown which
is incomplete and misleading. This is because we are using two
dimensional displays to represent three dimensional objects.
In order to have a more universal program it is necessary to
have the display represent views of three dimensional objects.
This means that even though one is viewing an object head on
(two dimensional view), the computer must have the total picture
in storage so that when the view is changed (rotated image),
the object is viewed in perspective.
It then becomes a task of not only generating a three dimension-
al view of an object, but being able to rotate it, modify it,
and to assign it physical properties. The program must also
allow the objects to be assembled (attached to one another), to
interpenetrate, and to store and retrieve objects and assemblies,
and finally make the necessary calculations to display those
attributes necessary in making design decisions. The formation
of the data structure for such a program is a rather formidable
task. However, progress is being made.

The problem of generating objects, their manipulation and as-

semblies has been solved in one way by a Dr. C. Stephen Carr at
the University of Utah. His program has been published as a
Ph.D. dissertation entitled Geometric Modeling. Through use of
a call signal a geometric primitive is displayed on the CRT,

549
 ~BDID ml~ITlve

Q
~~L..

~ ......
.....
"""
~----~
Q
"'- -'"

..-
""'"
.. .......
--'
,------
r- .. ~
Q I
I
I
I
--'

550
i.e., a cube, cylinder, etc. Subsequent signals would alter
the primitive shape to any desired shape. TWo such examples
are shown in Figures 7 and 8.
Scales can be assigned and the shapes assembled, rotated,
stored, called back, etc. This is an excellent start, and it
appears to have the universal basis necessary to be used in
building design. Research is continuing in this direction at
the University of utah under the broad supervision of Dr. David
C. Evans, Director of the Computer Science Department. It is
hoped that ultimately a program will be available such that a
designer will be able to work at an interactive computer
graphic console and complete the entire design process without
the use of pencil, paper, or printed reference manuals.

551
 PART 6

Nuclear and Space

Science Applications
 THE APPLICATION OF COMPUTER
GENERATED GRAPHS AND DIAGRAMS TO
THE DEVELOPMENT OF ADVANCED NUCLEAR
REACTORS·
D. W. Cardwell
Oak Ridge National Laboratory, Oak Ridge,
Tennessee 37830, U.S.A.

Introduction

The rapid emergence, during recent years, of computer generated graph-

ics as a practical medium for efficiently handling wide ranges of technical
information is causing many sizeable research establishments and universi-
ties to assess the value of their resources and activities in that area as
a guide to further future commitments. The difficulty of conducting such
assessments from which intelligent conclusions can be deduced should not be
underestimated, for the options are many and provable experience is limited
and scattered.

A review of our experience with certain practical applications of com-

puter graphics at the Oak Ridge National Laboratory can be of value to other
large technical institutions. As the most extensive research establishment
of the United States Atomic Energy Camnission, for the past twenty-seven
years we have been engaged in the collection and dissemination of findings
from wide ranging experiments and analytical studies that range from. basic
research in the physical sciences to most branches of application engineer-
ing. Much of our effort has been directed toward providing a sound tech-
nological base for what bas now become a vast worldwi.de nuclear power indus-
try. Our programs for research and developnent leading to adrcW.Ced nuclear
reactors have became increasingly dependent upon intelligent utilization of
automatic electronic processing of wide varieties of data flowing from
analytical studies and from experiments conducted on dynamic engineering
systems.

Practical minded engineers who design and build large nuclear power
stations require the latest, most reliable information that can be obtained
regarding the dynamic Characteristics of reactor internals and their asso-
ciated energy transfer systems. Some of our most important investigations
are directed toward determining relative efficiencies and safety margins
achievable from contrasting reactor core assemblies of contrasting design

*Research sponsored by the U.S. Atomic Energy Coo:mi.ssion under contract

wi tb the Union Carbide Corporation.

555
that utilize various heat conveying media flowing within heavily stressed
containment structures. Such determinations require detailed quantitative
assessments of thermodynamic, hydrodynamic, and structural response charac-
teristics of multiple interlocking systems under both steady state and
transient conditions. Engineers are accustomed to visualizing data most
applicable to such situations as families of curves or geometric diagrams
that graphically show parametric interrelationships of temperatures, pres-
sures, flows, neutron flux densities, etc., as they change with respect to
each other and with respect to the passage of time, in various spatial
configurations.

Digital computers have become increasingly proficient in the extremely

rapid processing of large volumes of data with high degrees of precision,
provided such data are chopped into small bits and pieces, contrary to any
genuine continuum. As a consequence of that inherent nature of digital com-
puters, we have seen for many years, primary concentration on output format
from these machines as voluminous incremental numerical tabulations. Such
tabulations take full advantage of the ability of modern computers to report
each number to many digits conveying presumed high orders of accuracy. But,
our engineers and scientists investigating dynamic nuclear reactor systems
are usually more concerned with pressing needs for rapid recognition of
trends, peaks, valleys and mutual time dependencies among families of re-
lated data. To satisfy such needs we have been attempting to take advantage
of progressive innovations in computer related hardware and software that
provide opportunities for generating information in graphic form. Our ex-
perience encompasses both on-line and off-line processing of experimental
data, wide ranges of analytical studies for design optimizations, and opera-
tion of computer augmented information storage and retrieval systems for
specialized technologies. From each of these activities I have selected for
use in this paper some practical examples of computer graphics. These ex-
amples are mainly intended to call attention to implementation methods that
satisfy utilitarian needs of members of a large research organization rather
than to show high orders of specialized sophistication.

Facilities for Computer Graphics

Experience at the Oak Ridge National Laboratory with graphic output

from digital computers began in the mid-1950's. At that early date, in
response to keyboard commands, bQth x-y data plots and alphanumeric charac-
ters were displayed directly on the screen of a conventional Cathode Ray
Tube (CRT) connected by means of digital/analogue circuitry to one of the
earliest first generation (vacuum tube) electronic digital computers, the
ORACLE. 1 Figure 1 is a photograph of such a display revealing striking
similarity to modern CRT computer terminals having point plot capability.
The lower left block of this illustration is a graphic representation of com-
puter calculated neutron flux densities (two energy levels) varying in value
from the center to the outer periphery of a spherically shaped nuclear reac-

5~
tor that was developed for the purpose of investigating the feasibility of
atomic powered aircraft. This example of computer data plotting may appear
rather primitive today. The significant observation to make here, however,
is that as much as fifteen years ago, members of our technical staff engaged
in extensive direct interaction with a digital computer through the medium
of automated graphic display. Later, as computer users increased in number,
it became no longer practical to provide individuals with such intimate
access.

When the larger second and third generation machines came in, there be-
gan a gradual implementation of mechanical pen moving plotters. More re-
cently, there has been added to our central computing facilities a CRT 35 mm
film plotter that is driven off line from computer produced magnetic tape.
This equipment operates in a high volume batch processing environment where
turnaround time varies according to competing demands and personalized
programming service must be limited in order to accommodate the varied needs
Of many users efficiently. For several extensive experimental complexes,
relatively small independent computers having some graphic capability are
used for on-line data processing. Telecommunication linkages are available
for some special situations and commercial timeshare terminals are widely
employed by our staff members for low volume interactive numerical
computations.

Automatic Data Collection for Computer Graphing

Reactor development experiments generate large quantities of data from

on-line measuring sensors amenable to computer processing for reduction and
analysis. To minimize costly and time consuming manual handling between
experiments and computer centers, several different techniques have been em-
ployed to automate the steps involved to yield computer produced graphs from
which parametric relationships can clearly and rapidly be deduced. We now
have systems operating where measurements from a number of independent ex-
perimental installations are automatically digitized and stored with identi-
fications on incremental magnetic tape for overnight central computer
processing. It has been our experience with such systems that experimenters
gradually develop confidence in computer generated graphs of resultant para-
metric relationships and abandon previous tedious manual plotting from volu-
minous line printer numerical tabulations. It can be extremely important in
directing the course of experimental investigations to have in hand com-
pletely processed sets of curves that represent a previous day's operation.

Figure 2 provides an example of experimental data automatically col-

lected and plotted where variations in the characteristics of a simulated
nuclear reactor fuel element are shown as time dependent variables. This
illustration shows computer graphing options available to experimenters that
range from bare point plots to smoothed curve fitting. In studies of struc-
tural integrity of reactor containment vessels, data automatically collected

557
from hundreds of strain gages fixed to the shells of such vessels are sub-
jected to analytical computations to yield stress pattern diagrams.
Figure 3 is representative of a series of computer generated diagrams Where
lines of equal stress concentration are plotted to show response to various
loadings imposed on experimental models of prestressed concrete pressure
vessels under test. These diagrams have demonstrated that reactor vessels

Fig. 1. Interactive eRr Displays from First Generation Digital Computer

558
11001 1()1 2OP-20-1S, (!).~-I·h
.-
.-20-20, +'"20-22
~
1.
V\
l~ 91 • ., PLOT 11
16001 81 tS . .- .- - tI) t"f'tiH. TI&ftf!. te....w.u.
.. • •
15501 11 til
I
•
•
I.
-
•
•
-• - r
•
,• • -
15001 61 12
• • • •
•
- •
1IIUf·
\. :
~ AMP.S It. F: •
~::l
•
• • • •
- •
\10m
...
1'l501 51 10 • 1 I•
• • •
.- ......- .....-..-
I •
••
+4+'.. ~ __ _
1'l001 'll 8
+ .+\ • -
• •••••••
•
: •
++ A.C• • •UHO C,VItRCH7 • • • • • • • • • • • • • • II • ••• • • • ••
13501 31 6 • •
TI'tf~ ~ ,.,. .~ ~'U\ VOf.TS
•
13001 21 'l
12501 11 2
12001 01 0 'l'lbo Isba 1660 17bo lebo Isba 2Obo
TIME OF DAY OAl 110
Fig. 2. MuJ.tiparameter Computer Plot from Automatic Data System
Simulated Reactor Fuel Element Under Test.
of this type will not fail from brittle fracture. 2 Figure 4 is an example
of computer plotting along the surface of a nozzle intersecting a stainless
steel hemispherical shell as measured under internal pressure loading. The
computer program employed here can plot the complete curves, for any angle
nozzle subjected to various types of loadings plus all alphanumeric nota-
tion, including figure and page numbers ready for inclusion in published
reports.

ORNL DWG. 68-13534

Midplane

Fig. 3. stress Patterns in Shell of Prestressed Concrete Reactor Vessel

Model Under Load.

560
 01. 0

()
..,.

CONFIGURATION NO. 1
o DEGREE PLANE
-1.0 INTERNAl PRESSURE LORD
XXXXXXXXX TRIAL RUN. TEST I XXXXXXXXXXXX
0.0 TCJTAL STRESS
(NCJRMALIZEO) VS. PRCJFILE
1.0
STlllll.S.
flGlllE 4 o IIEJIIDICINAL
2.0 • TANGENTIAL
fill TAaLATED IIITA sa IIEPCIIT 31'. TIafS 1-10.
NlllllALIIEII STllESS • S'IIIESSIN. N· "" NT!
3.0 l"oIWSSUIIf. IJoIIIK DlllETEII. T~ IIU THICIICSS

Fig. 4. Measured stress Variations Through Section of Reactor Vessel

Nozzle.

CI1
O":l
 Computer Graphing for Analytical Studies

To evaluate the feasibility of concepts proposed for advanced reactors,

large volumes of iterative computations are conducted. Optimization codes
are applied to select reactor core configurations and materials for fabrica-
tion that will most efficiently generate heat from nuclear fission within
acceptable standards for safety and reliability. Computer generated graph-
ics have been found to materially aid these analytical studies by consoli-
dating large volumes of line printer tabulated numerical data into geometric
diagrams. Figure 5 is representative of a series of diagrams obtained
during studies of the hydrodynamic characteristics of coolant flow through
a proposed vortex reactor.3 Here is shown how linear stream flow can be
altered to form a vortex pattern by introducing a radial flow component to
improve the potential heat generation efficiency of the reactor. Figure 6
is representative of a series of isotherm plots computer generated from
radial heat conduction code calculations that show temperature profiles
through mockup fuel elements that are to be tested under conditions of in-
creasingly restricted liquid metal coolant flow. In analyzing the distri-
bution of stresEes within structural components of nuclear reactors, it
becomes necessary to subdivide the geometry of irregular shapes into a large
number of discrete finite subelements. To eliminate a tedious and e~cting
manual task, computer programs have been developed that perform such
functions automatically. Figure 7 illustrates such a finite element mesh in
the subregion of a fillet weld drawn by a CRT film plotter.

Data Processing from Operating Nuclear Reactors

As forerunners to the design and construction of full-scale plants,

prototype nuclear reactors are built and operated for exhaustive determina-
tions of their functioning characteristics. Such a prototype is the eight
megawatt Molten Salt Reactor Experiment (MSRE) where large volumes of useful
data have been collected during the past five years. Continuous on-line
processing of data from this reactor prototype experiment is handled by a
medium size digital computer (Bunker-Ramo 340) equipped with several readout
devices that include a Moseley pen moving plotter. This local mechanical
plotter produces graphs of significant operating conditions, such as histo-
grams of spectral flux density, illustra,ted by Fig. 8. To create these
histograms, the computer periodically runs a Fourier analysis of cyclic
fluctuations in neutron flux level over brief time periods. By comparing
the pattern of histograms from successive scans, changes can be detected in
factors 'that influence power production efficiency, such as the formation of
entrained fission product gases in the circulating reactor fuel. Figure 9
provides an example of data collected by local computer and stored on mag-
netic tape for off-line graphing by manual input to a larger computer (IBM
360/75).4 Here are shown control rod position/flux level correspondences as
determined from dynamic tests performed on the reactor prototype.

562
 Interactive CRT Graphics for On Line
Experimental Data Analysis

Fundamental to determining the fuel economy of advanced nuclear reactors

are accurate experimental measurements of the extent to which various ele-
ments will absorb, reflect, or fission when exposed to neutrons of discrete
energy levels. Small computers, such as the DEC PDP-8 or the SEL 810B having
CRT display units with light pen attachment have been used for several years
at the Oak Ridge National Laboratory's high voltage accelerators and at
nuclear reactor beam holes to handle such data collected on line from neutron
spectrometers. Figure 10 illustrates how an experimenter can manipulate
background scale, range, etc. of CRT plots to focus on areas of scan having
greatest interest for detailed analysis, calling upon stored programming
routines. In order to overcome inherent capacity limitations of sm~ll com-
puters employed in this fashion, steps are being taken to provide telecom-
munications linkage from clusters of CRT data processors now installed at
our high voltage accelerators into a display-oriented timesharing system for
access to more versatile hardware. 5 Figure 11 is a layout diagram of this
system which will enable a number of independent CRT terminals to interact
with a large computer center (IBM 360/75-91). With such an arrangement,
users can make rapid graphic comparisons between real time neutron spectra
measurements and those that have been collected from previous experiments
and stored on disk.

Information Systems

Our center for Nllclear Safety Information (NSIC) employs telecommunica-

tions linkage to an IBM 360/50-65 computer combination that provides storage
and retrieval capability via remote CRT alphanumeric terminals. In addition
to large volume processing of bibliographic references, this equipment has
been used for highly selective retrieval of hierarchically organized factual
data pertaining to the design characteristics of nuclear power generating
stations throughout the United States. 6 Figure 12 is a diagrammatic repre-
sentation of the system employed for that purpose. Here, rapid responses to
keyed queries may be displayed on CRT screens as an efficient means for
probing massive files stored on a central computer data cell device as pre-
liminary to selective hard copy readout. Software developed for this system
encourages CRT man-machine dialogue where the computer quickly leads inex-
perienced users into details of file structure. Techniques for "readout by
exception" can then be called upon to display only those nuclear reactor de-
sign features that differ beyond limits selectively prescribed by terminal
users.

Assessments made of potential improvements to this information system

included a market survey of CRT terminals available in 1968, comparing cost
and capabilities ranging from a simple alphanumeric to full vector.? We con-

563
 .c
VI
......
:::t:
(.)
Z
::::
8 8 ......
(.)
c Z
...l
N '"
I
:5
-'
• CD •... "" VI
0
0> t»- -'
Z
IX
Z
IX <
0
<
IX

c c c c c d

'"
-'
0: .c
(S3H:>NII 3:>NVlSI () lVIXV "" d

c
.c
Vi
......
:::t:
(.)
Z
::::
8 ......
Ed
0
(.)
c Z

•CD •... "" :5

VI

Ii ~.
0
-'
z z <
0

...... -------------------------------------------------------_#"
<
"
"~

, ... -----------------------------------------------------------,
a:::
c
c c d
.c d
(S3H:lNIl 3:lNV1SI () lVIXV

cluded from this survey that graphic plotting features offer significant ad-
vantages for technical information exchange; but practical economics demand
that incompatibilities in competing hardware and software be resolved, and
measures for interfacing to public communications media be improved.

Concluding Observations

Applications of computer graphics to the development of advanced nuclea

reactors at the Oak Ridge Nation~l Laboratory are varied in nature and emplc
wide ranges of hardware and software, mostly directed toward specialized ob-
jectives. Small, dedicated computers with graphic capability offer advan-
tages of rapid personalized data processing, particularly when they possess
-interactive features; but, the developmen~ of programming to support such

564
 QO
0 >=1
.0 'M
Ul
ro
GJ
III /-;
~ ()
:z::
u >=1
H
~
8 :>:,

-
~
u
~
....; 0: .0
N I 0 Z
, t<'\ ~ 'd
GJ
CD "- !!! t)
OJ" OJ" e >=1
a=: a=: -' GJ
Z Z 4( ;::!
r-l
~ '+-i
a=: >=1
H
0

-
Ul
0 0 0 0 0
d ro
N 0: -d t<'\ d Ll\ Ul
>=1
(S3HJNIl 3JNV1SIO WIXV /-;
QO GJ
'M -I-'
~ -I-'
0 ctl
.0 P-t
~-I-'
o >=1
Vi r-l GJ
!t! ~ >=1
u 0
-I-'
§ ~
~
8 8
-
~
0
....; otI uZ r-l 0
N I 0 0
, t<'\ ~ 0 :>,
III 0 -I-'
CD "-
e 'M
OJ" OJ" /-; ()
a=: a=: -' 0 0
z z 4(
-I-'r-l
() GJ
~ ctl:>
a=: GJ
P::r-l
0 ctl
'M

-
~
0 0 0 0 0
d GJ'"d
N 0: -d t<'\ d t&l
0
(S3HJNIl 3JNV1SIO WIXV :>

installations is difficult for individual investigators to obtain except for

highly repetitive functions. Computer centers have much greater capacity and
versatility for graphics, but lack of easy efficient accessibility can be a
serious handicap here. Perhaps, future advances in the art of linking re-
mote CRT terminals to central computers via telecommunications will gradually
allow satisfactory compromises to be worked out that will assure local inde-
pendence, yet include versatile capabilities for computer graphics.

For large research establishments, interactive CRT terminals will

realize their full potential as economically attractive video windows to com-
puters only when they can be employed as multipurpose terminals - terminals
that can be called upon to perform the interrelated functions of information
storage and retrieval, experimental data processing and analytical
computation.

565
~ FFM HERTER ROD l= 5
10 KW/FT---' -

RCiD NCI. 1
SCALE: 1 INCH= .023 INCHES
I I
o
6
Fig. 6. Computed Isotherm Plots Through Section of Simulated Reactor Fuel
Element.
CONFIGURATION 5 NUMBER ~1 STEP CYLINDER PROBLEM FILLET STUDY ~
11:)
1l.0 l r-T-ril---r---r-.--.,---r--T---.----
10.8~--~--r---~--~~~~4-~~~~~~--~---+----
10.6 --t--t----1~__t-;-_+-+::~~:Wr;;t::.-~---L-~-.....I..-­
t-I
I
10.1& I---- -- f-··-·-·----- f - I- - - -
II
10.2 I---+----+---f~__I~~~~
10.0 I J I •
2.6 2.8 3.0 3.2 3.1& 3.6
Fig. 7. Finite Element Mesh Plotted to Analyze Stress in Region of Fillet
Weld Joint.
 __ ~IIVW'W

la, a,VY

~ ~if~
! .~ I •. I '! • " I
1--".

' il
-
It 't· . • ~I"
H- ~t l ,Ji!-'- , : 1•. 1 .;.• ; !t: h Iti! If-O.'" I'"
, it
• t . !
i .
.
:' t:ti til! Uti H,. HH ffli Ffft rtrt "iH ~tH"t IRP itt1 !OH' 1'. . '"1
oao • • • • •
~::1:t.;
..... ... i lli100 ...00 im ~;
~.. IE ~'Ffffi :-~;
.., tm
.'. lli! .......:.:;:_.. : " .::.....~HE l~ '1

Li I I 'I ',0"
!! II ...
' I'

!II
• i· I ~j" II r-tl ,II 'Ii, .•• , 'I." H· I ., .
, 'I:. ,"
~lllll .' .:t i ::' :! aU. nit 4!~ U:l-! Hf.!. : 1 :!. n:. ;:!i :: r; ,t % -n .,. i : Ii:
,~ ,
~, '
" ~.
.
. .-.~ ~i: ful f:Y: gg Hn itH Ig: ii:.: . ..... ..
II .. !•
:=$ - . -- ..
,,, , .. ". ,
., . ."
It :1: i pt l J ' f 1., ~,. I I ! .... t I I • t 111 I~'" -, ..
",I il ' HI
·1 !'!'I : .& ,~:~ i!'- i, =~ .. I; itt:. ~·ttttr:t
HI tii i ~! -
. :.i!! 1 * ·~h Ht .1.rt t·t 1 ~ 'H= HH
::r.; , I.
[lli HlJ Uti :::: :~;"'~.f.irf I; ; ; li::" _.. ............-
... >- • , ~ ..., a"" ... t .- .f'" "'~ ,.
!~

" ~ I., •
' 1'1 . . ..
~ I .
~ I' ...... !UI n II'" !U!
f ' ... ; I
::.1 ~~ .... tr; ":t ..
.... , ~;
..;...

L L!. t! !
II
"
I ..
'" II l~' t
! . H+f tit ... ~ flir'-
1+H: :.'::H tL:'~
- -- H

Fig. 8. Spectral Flux Density Histogram from Molten Salt Reactor Proto-
type Operation.
 ORNL- DWG 68-9668

PRBS ROD - JOG

ROD POSITION
:'\\,
:
...............
-.

..
,
."
....
• <

(f)
t-
Z
:::J
>-
a::

/ ...._'\
oCt
a::
t-
iD
a::
oCt

V \}
PRBS FLUX- DEMAND

ROD POSITION

: l-
."- .h.
: \, Wo'o'"
V\
• 0. . . .

\... ..,......
....".," i
-,<
.;
I
'
......
i/

\.J
,r-\LUX ;--...
i '--' \
V
r--\.\J
::

PRTS FLUX - DEMAND

o 0.5 1.0 1.5 2.0

TIME (min)

Fig. 9. Control Rod Position/Flux Level Dynamics from Molten Salt

Reactor Prototype Tests.
569
 14

PH OTO 88547

512 CHANNELS WITH MARKERS FOREGROUND, 64 CHANNELS

SCALE CHANGE, 128 CHANNELS

Fig. 10. P.flotographic Sequence of CRT Display Manipulations for Neutron

Spectroscopy Data Analysis.
570
 ORNL-OWG 68-93OQA

ORIC FACILITY
EDIATE ANALYSIS 1t " '_ : _ _. . . . .
BUILDING 6000
AND
I CooRQINATING
I
I COMPUTER
I
I
----------------------------1
ORELA FACILITY I
BUILDING 6010 0/70»777. 1 I

I
,,
: CENTRAL COMPUTING
_________ -! BUILDING 4500
CRT I
-10 in.1I10 In, ,, ___ ______ , _'" I
I ~-----------
I ---------------------
LIGHT PEN I Y-t2 PLANT
I
I
I
I
I

CI1
'-l
.....
Fig. 11. Diagram of an Immediate Analysis Graphic Display Telecommuni-
cations System.
 - AEC Regulatory EftluaUons
-ORNL Nuel.. , s.tety Stud
-ORNL NSIC Reterencu
-ORN L Reaclo, S....a.rds

~
(3) Data Formatting
tor Computer

I-'
-...::J

(eS) Additional Telecommunlcallon Stations

(a)AfC DRL-Bethe$da. Md (June '58)
(b) AEC DRDT - Germantown, Md
(dAfC ACRS-Wastungton. o.C
(d)AfC NRTS-Arco. ldaho
(e)AEC ANL-Ch lcago. 11I

Fig. 12. Diagram of A Telecommunications System for Interactive Storage

and Retrieval of Design Data on U.S. Nuclear Power Stations.
 Acknowledgements

Assistance in obtaining illustrations for use with this paper was re-
ceived from the following individuals: W. G. Dodge, J. R. Engle, A. J.
Frankel and J. W. Woody of the Oak Ridge National Laboratory; G. J. Farris
of the UCCND Computing Technology Center, and Prof. R. W. Maxwell of the
University of Tennessee.

References

1. R. J. Klein and C. H. Schalbe, ORACLE Photographic Curve Plotter and

Digital-Output Device, USAEC Report ORNL-2290, Oak Ridge National
Laboratory, November 1957.

2. J. M. Corum and D. W. Goodpasture, Design and Feasibility Study of a

Large-Scale Test Simulating the Time-Dependent Behavior of a Prestressed
Concrete Reactor Vessel, USAEC Report ORNL-TM-2390, Oak Ridge National
Laboratory, February 1969.

3. G. J. Farris, G. J. Kidd, Jr., D. W. Lick and R. E. Textor, A Study of

Vortex Flow, USAEC Report CTC-7, March 1969.

4. W. L. McMullen, Jr., The Molten Salt Reactor Experiment Data Processing

System, Math Division, Oak Ridge National Laboratory (unpublished).

5. J. W. Reynolds, Application Notes on the Immediate Analysis Computer

Display System for ORELA Data Acquisition and Handling, USAEC Report
ORNL-TM-2ll6, Oak Ridge National Laboratory, Jan. 30, 1968.

6. D. W. Cardwell, Interactive Telecommunications Access by Computer to

Design Characteristics of the Nation's Nuclear Power Stations, AFIPS
Conference Proceedings Vol. 33, Part One, 1968 Fall Joint Computer
Conference, December 9-11, 1968, San Francisco, California.

7. Paul Rubel, Survey of Cathode Ray Tube (CRT) Terminals for Remote
Output of CHORD-S Information, USAEC Report ORNL-TM-3456, Oak Ridge
National Laboratory, December 1968.

573
 A LABORATORY FOR INTERACTIVE
PROGRAMMING, PROCESSING, AND
DISPLAY IN SPACE SCIENCE

John J. Quann, Elijah J. Poole,

Ronald W. Durachka, and Christopher J. Daly
National Aeronautics & Space Administration, Goddard
Space Flight Center, Greenbelt, Maryland 20771, U.S.A.

INTRODUCTION

The launch of an unmanned scientific spacecraft marks the culmination of approx-

imately three years of effort for each scientist having an experiment on-board. But
it is only a transition, or, to paraphrase Sir Winston Churchill, the end of the beginning.
There looms in front of the average experimenter five years (1) during which he will
be confronted by the formidable task of analyzing the data he will receive. He has spent
the majority of his time prior to launch in the design and fabrication of his experiment
and in the integration and testing of it within the environment of the spacecraft. This
phase was terminated at launch. He must now devote his time to the completion of pre-
liminary computer programs, and to the presentation of preliminary results. Eventu-
ally he will complete his final analysis programs and present his conclusions to the
scientific community.

The transition begins the moment the vehicle leaves the launch pad. To that point
equipment malfunctions could have been fixed and the unexpected coped with by modifi-
cations to the hardware. Beyond that point any anomalous behavior must be handled by
software, and change will necessitate change. In order to aid the experimenter in this
transition, NASA, Goddard Space Flight Center developed the Data Reduction Laboratory.

The best functional description of the Laboratory is that it is a facility in which the
user, through interaction with a computer/cathode ray tube terminal system, can, in a
minimum of time and with a minimum of effort, develop unique programs, process, and
display data. There are many key words in this description, but the one that is most
important is 'user'. The Laboratory, in hardware, software, and operation was designed
around the user. He is normally a scientist, not a programmer, and this distinction
connotes both assets and liabilities. He, better than anyone else, knows and understands
the operation of his experiment, the method in which it handles the data, and the phenom-
ena under observation; he usually has some definite ideas on how the data should be

577
processed and displayed for analysis. On the other hand, he often has little or no know
ledge of the mode or format of the data. The output from his experiment has been
multiplexed with information from other experiments on board, as well as with space-
craft engineering data, and telemetered to ground receiving stations. This telemetry
as seen by the Laboratory, could be in a variety of modes: possibly a continuous bit
stream arriving in 'real time', or it could reside on analog or digital magnetic tape;
the experimenter does not know, does not want to know, and, as will be seen later, does
not need to know. In addition, although he may have a general idea of the form in which
he would like to see his data presented, he normally would not know how to go about
doing it.

Another factor in the design of the Laboratory was that the average experimenter is no
directly associated with NASA. When he arrives at Goddard Space Flight Center for hi
first look at the post launch data from his experiment, it may well be the first time he
has seen the Laboratory. Yet, he must be able to use what is available to him for his
analysis, and use it easily, with a minimum of instruction.

THE LABORATORY

The Data Reduction Laboratory encompasses a variety of hardware linked to-

gether through a Univac 1108 Multiprocessor (Figure 1) and some extraordinary
software. The hardware mainly consists of three Sanders 720 alphanumeric cathode
ray tube (CRT) displays and three IDIIOM CRTs interconnected to a single dry hard-
copy processor. Each IDIIOM has associated with it 32 function keys, a light pen, a
Varian 620i computer, a teletype, and has vector, circle and alphanumeric capabili-
ties. The combination of one Sanders 720 and one IDIIOM forms a 'user station'
(Figure 2). It should be noted here that the Multiprocessor is not a dedicated machine,
i.e. to be used solely by the Laboratory. Rather it performs the bulk of the production
telemetry data processing at Goddard and, while the Laboratory is in use, other,
independent, programs are being processed Simultaneously.

The heart of the system lies in the software. It was designed so that the Labora-
tory would be looked upon and used as a tool rather than as some programmable com-
plex of machines that might tend to repel the scientist instead of attract him. To be
sure, individual programs are developed, compiled, and executed; but the entire proces
can be accomplished through one interactive, conversational session at the CRTs.

Any computer program can be separated into two main phases: development and
execution. Each of these, in turn, can usually be further subdivided into three com-
ponents: input, processing, and output. This holds true as well in the Data Reduction
Laboratory. Programs are compiled after a conversational DIALOG and SYNTAX
between the 1108 and the user (2). This activity is performed utilizing only the alpha-
numeric CRTs. The software has been designed so that the user is required to respOI
only in those areas in which he possesses some knowledge. Any processing or compu-

578
tation performed on the data is normally unique to an experiment and must be accomp-
lished through SYNTAX. Here, the user has the initiative and the computer responds.

TELEMETRY DATA HANDLING EQUIPMENT

,--------- - -----------,
I
I
5 FH 432 I
DRUMS
I 1108 CPU - INPUT OUTPUT - 1108 CPU I
I CONTROLLER
I
I I
2 FH 1782 I I
DRUMS I I
I
64 K CORE f----- 64 K CORE I
64 K CORE ~
2 FASTRAND I
DRUMS I

! UNIVAC 1108 MULTIPROCESSOR

~------ ---------
______ .J
I

2 CARD READER/
PUNCH UN1TS

2 ASR 33 HARD COpy

TTYS PROCESSOR

Figure 1

In DIALOG the situation is reversed: the computer has the initiative and the user
responds. The type and format of the output be it graphical or printed is completely
defined by the user through DIALOG. The input, on the other hand, is common to all
experiments aboard a spacecraft; it is the area least understood by the scientist and,
as far as he is concerned, is handled automatically.

After a program has been developed by a user and stored on the library (tape),
it can be accessed, updated, modified, or executed at any time from the alphanumeric
eRTs. It is during execution that the IDIIOMs are brought into play. The user, throug
the use of the light pen and the function keys, selects the data to be displayed as well

579
as the time period over which to display it. He can at any time receive a hardcopy of
the display on the IDIIOM by simply pressing a button. When he leaves his station he
has the option of not only carrying away with him the data he has processed, but a
listing of the processor as well.

us STATION

.- .......__ ....
.... ......

Figure 2

PROGRAM DEVELOPMENT

As mentioned, there are three areas that must be defined to create a program or
process: the input, the processing and computation to be performed upon the data, and
the output. The input is defined through SYNTAX by an individual other than the scien·
tific user, but for common use by all users. The processing phase is designed by eacl
scientific user through SYNTAX; the output is specified by each user through DIALOG.
Before proceeding further, there are two items that should be defined.

THE DATA. Although the input can be completely general, there are two main
types of data commonly merged and processed in the LaBoratory: telemetry and

580
orbit. Telemetry, or the information received from the spacecraft, can be thought
of as being digital, fixed point, and having a heirarchy: 'bits', 'channels', 'frames', and
·sequences'. Each experiment is assigned a number of channels for it's information.

Each channel contains a fixed number of bits; there is some specified number of chan-
nels to a frame and a specified number of frames to a sequence. Data appearing once
per frame is referred to as being 'commutated'. Data appearing more than once a
frame is called 'super-commutated'; data appearing less than once a frame is re-
ferred to as being 'sub-commutated'. Orbital data contains information as to the posi-
tion and velocity of the spacecraft, and is expressed in geodetic, geocentric, and geo-
magnetic coordinates. Latitude, longitude, and height are three parameters of constant
interest. This data is in floating point and is necessary in correlating and analyzing
the telemetry. The one parameter contained in both data sets and essential for any
correlation is Greenwich Mean Time.

SYNTAX. The general format of any statement is:

Keyword (Label): Specification:

Where 'Keyword' identifies the type of statement; 'Label' is simply a user

designated tag; 'Specification' is the computation or logic to be performed. For those
keywords (statements) where it is required, the specifications are in an operand-
operator-operand sequence. As an example, let us assume that in channel 44 bits 9-5
an experiment contains a value M, and in bits 4-1 a value N to be used in the compu-
tation of range, R, as follows: R = ( M + 32 ) 2N - 32. Using the keyword 'HOLD', a
user could compute the range and save it for output as follows:

HOLD (RANGE): (44(9-5)+'32')* '2'**44(4-1)-'32':

There exists a total of twenty possible keywords carefully chosen for the scientific
user. One keyword, USE, can perform quite different functions depending upon the
manner in which it is applied. It can be used to define input data or it can cause
separate programs to be linked together. An example of this will be gi ven later.

Four keywords are reserved for input; the remaining fifteen are:

GROUP: name - always first statement

PARAM: parameter - may be modified during execution
DA TA: defines an array - may be multi -dimensional
HOLD: compute and store data frame by frame
ITEM: compute and store data over an interval of time
TEST: examine data conditon true/false

581
ELSE: where to go if TEST fails
THEN: the point at which all statements resume after TEST
SELECT: addresses data words from some input source
SIZE: resultant block of words
SYNC: synchronizes data blocks
START: beginning of a loop
CYCLE: end of a loop
OUTPUT: specify mode of output
FIN!: always last statement

INPUT. The first image a user sees and must respond to whenever he activates
one of the Sanders CRTs is as follows:

0101. START DIALOG

FOR LISTING PURPOSES, GIVE YOUR NAME _____________ _

PICK, BY NUMBER FROM THE FOLLOWING LIST, THE
DRL CAPABILITY THAT YOU WISH TO USE
NOTE •••.. ENTER INPUT DIALOG (5) BEFORE ENTERING (3) OR (4)
WITH THE INTENT OF EXECUTING A DATA REDUCTION PROCESS.

1. UPDATE DIALOG NETWORK (SYSTEM PROGRAMMER ONLY).

2. CHANNEL DUMP FROM AN EDIT TAPE.
3. CREATE A DATA REDUCTION PROCESS.
4. MODIFY AN EXISTING DATA REDUCTION PROCESS.
5. ENTER INPUT DIALOG.
6. TERMINATE USE OF THIS STATION.

IF SELECTION (1) WAS MADE GIVE PASSWORD _____ _

In the case of input definition, someone, other than the experimenter, who has a
w0rking knowledge of the input data would type a '3': CREATE A DATA REDUCTION

582
PROCESS. The 1108 would acknowledge this request and start an activity calledCLC
(Conversational Language Control). The CRT would be placed into the SYNTAX mode
and the format of the scope image would change from a fill-in-the-blank type as in the
START DIALOG node to a sketchpad for type-in and display of 'free form' statements.

In the definition of input any keyword can be used; five, however, are unique:
ASSIGN: used by DIALOG for tape assignments at execution time.
INPUT: reads the data and blocks it in memory.
USE: describes the spacecraft telemetry as it exists within the computer.
DEFINE: gives global tags to data so that it can be referenced by other users.
SUB COM : indicates which telemetry channels are subcommutated.

The first statement in any process is a GROUP statement, which tags the process
so that it can be singularly referenced. The last statement in a process is FINI, to
which the computer responds by compiling all previous statements and returning to
the DIALOG mode. An input process so defined would be placed in the library for
future reference.

PROCESSING. When a user-scientist desires to define his data reduction process

he begins with the START DIALOG node, gives the same response, and receives the
same result as in INPUT. He then enters the SYNTAX mode. Here, however, he is
not concerned with input, simply with his data. The processing phase is perhaps best
explained by being demonstrated.

SAMPLE PROBLEM. An experiment occupies three words on the main com-

mutator: 42, 43, and 44. Each word is 9 bits in length, where bit 1 is the least
significant bit.

Channel 42, bits 9-2 = LlE

bit 1 = Gain
Channel 43, bits 9-2 = ELl E
bit 1 = Error
Channel 44, bits 9-5 = M
bits 4-1 = N

When Error = 1, the data from channels 42 and 43 is to be ignored. When Gain = 1,
the data in channels 42 and 43 is be multiplied by 8. Channel 44 is used in the compu-

583
tation of range, R, as follows: R = (M+32) 2N - 32. Let us further assume that the input
process has been previously defined by a GROUP called READ (i.e. GROUP: READ:)
in which Greenwich Mean Time was defined to be the global variable GMT by a DEFINE
statement. READ had, in turn, referenced ORBIT, another input process for orbital
data in which latitude had been defined to be the global variable LAT.

SAMPLE SOLUTION:

GROUP: EXP06:
USE (READ)::
TEST (ERROR): 43(1-1).EQ.'O':
HOLD (DELTAE): (42(1-1)*'7'+'1')*42(9-2):
HOLD (EDELE): (42(1-1)*'7'+'1')*43(9-2):
THEN (ERROR)::
HOLD (R): (44(9-5)+'32')*'2' **44(4-1)-'32':
OUTPUT: P:
OUTPUT: CRT:
FINI::

In the preceding example DELTAE, EDELE, and R are variables available for
output as are the global variables LAT and GMT. The keyword USE, followed immedi-
ately by two colons, causes the process defined by READ to be linked with that of
EXP06. If during the SYNTAX mode the computer detects an error, the user is
presented with a diagnostic and an arrow indicating where in the statement it occurred.
He then has the opportunity to correct the error immediately and continue. After FIN!
is sent to, and acknowledged by, the computer, the user is returned to DIALOG to
select and define the type of output he desires (both printed listings and plots in this
case).

OUTPUT. The first node the user must respond to after the completion of his
SYNTAX asks whether the output is to be on the printer, on an IDIIOM CRT, or on a
combination of both. If the data is to be printed (OUTPUT: P:), the user enters a
series of DIALOG nodes in which his responses will determine what information is to
be printed, and how it is to be printed: format, spacing, titling, etc .. Depending upon
the information content and format desired, considerable time (in the order of half an
hour) could be spent by the user answering the questions posed to him. To produce
plots on the IDIIOMs (OUTPUT: CRT:), however, the DIALOG the user must respond
to is quite short.

584
 .P02
SELECT THE TYPE OF PLOT YOU DESIRE •
1. LINEAR
2. SEMI-LOGARITHMIC
3. 3-DIMENSIONAL
4. POLAR

DURING EXECUTION YOU WILL BE NOTIFIED BY A MESSAGE ON THE

IDIIOM WHEN AND HOW YOU MAY BEGIN THE SELECTION OF YOUR
PLOTS. SELECTION MAY BE PERFORMED BY DEPRESSING A FUNC-
TION KEY WHICH IS ASSOCIATED WITH DATA YOU ARE ABOUT TO
DESCRIBE IN THE ENSUING DIALOG. NOTE ••. ANY FUNCTION KEY
CAN BE ASSOCIATED WITH ONLY ONE DATA SET.

Assume the user selected 1, a linear plot; the next image he would respond
to would be:

.LINP01
A. WHICH FUNCTION KEY DO YOU WISH TO ASSOCIATE WITH THIS
PLOT (1 - 32)?
B. DOES THE X AXIS (ABSCISSA) REPRESENT TIME?
IF YOUR RESPONSE IS YES, ANSWER C AND SKIP D;
OTHERWISE ANSWER BOTH C AND D.
C. IF YOU HAVE DEFINED TIME, INDICATE THE VARIABLE NAME
CONTAINING THE VALUES OF TIME AND ALSO THE TIME SPAN
(IN SECONDS)
VARIABLE NAME
TIME SPAN
D. IF THE X AXIS REPRESENTS SOME ARBITRARY VARIABLE,
COMPLETE THE FOLLOWING:
VARIABLE NAME
X MIN (FIXED PT.) _____ _

585
 X MAX (FIXED PT.) _____ _

NOTE: IF YOU DO NOT WISH TO SPECIFY ANY MINIMUM OR MAXIMUM

VALUES, SCALING WILL BE DETERMINED FROM THE DATA.

Assume that the user keyed in the following responses:

A. 1
B. Yes
C. GMT, 600

The next image (and responses) would be:

.LIN02

A. UP TO TWO CURVES MAY BE PLOTTED SIMULTANEOUSLY. IF

THERE ARE TWO CURVES, BOTH SETS OF ORDINATES WILL BE
PLOTTED VERSUS THE ONE ABSCISSA YOU HAVE JUST DEFINED.
FOR ONE CURVE COMPLETE ONLY I BELOW.

I. Yl VARIABLE NAME DEL T A E

Yl MIN (FIXED PT.) Q. ___ ~_

Yl MAX (FIXED PT.) 1:. §. Q. __ _

II. Y2 VARIABLE NAME L A T

Y2 MIN (FIXED PT.) =- ~ Q. __ _
Y2 MAX (FIXED PT.) l Q.. ___ _

NOTE: IF YOU DO NOT WISH TO SPECIFY ANY MINIMUM OR MAXIMUM

VALUES, SCALING WILL BE DETERMINED FROM THE DATA.

Continuing, the next image and responses are:

.LINP03

A. IF YOU WISH A TITLE AT THE TOP OF THE PLOT, TYPE IN BELOW

EXPERIMENT 06

586
 B. TYPE IN A LABEL FOR THE X AXIS (ABSCISSA)
____________ IL~~_LQ~IL ____________ _

C. ON LINE 1. TYPE IN A LABEL FOR Y1. IF YOU HAVE SPECIFIED

A SECOND CURVE FOR THIS PLOT, TYPE IN THAT LABEL ON
LINE 2.

1. DE LTA E
2. LATITUDE

D. DO YOU WISH TO DEFINE ADDITONAL PLOTS YES

The response YES to part D would return the user to the image where he may again
select the type of plot. When he has completed the output DIALOG, the user is given
the option of storing his program on the library for future reference or defining his
program as temporary and executing immediately.

PROGRAM EXECUTION

Assuming a user has a program residing in the library and he wishes to use it
to process and display his data he must perform only two basic actions. First, prior
to execution, he must enter into and complete an input DIALOG; second, during
execution, he must select the data he wishes to view on the CRT.

INPUT. Again, as whenever a user begins any activity in the laboratory, the first
image on the Sanders 720 that must be completed is the START DIALOG node. A re-
sponse of '5', ENTER INPUT DIALOG, will enable the user to specify the data he would
like processed. The user first selects from the library those processors that are to
operate on the data. In the example that has been given, the user has defined his pro-
gram with the label EXP06. This program used a GROUP called READ which in turn,
used another called ORBIT. He, therefore, would select all three from the library.
Since READ and ORBIT reference two separate input data sources, the user would
be asked to specify each by responding to a fill-in-the blanks type question. The re-
sponse would, in the case of tape, cause tapes to be mounted, channels assigned,
parity and density selected. When execution has actually begun, the user is informed
by a message on the alphanumeric CRT. This message, which is updated on a regular
time basis specified by the user performs two functions: (a) it keeps the user informed
as to how his input processing is progressing on the 1108; (b) it enables the user to
initiate requests to the 1108. When sufficient data is available for display, the user is

587
notified by a message on the IDIIOM that he may begin plot selection. He is also re-
minded at this time as to the type of plot each function key represents.
OUTPUT. The depression of function key #1 on the IDIIOM would produce the pl(
as defined in our example of output DIALOG and shown in Figure 3. This figure also
portrays some of the hardware features of the display: the Y axis labeling has been
rotated 90 degrees; three (of the four) character sizes are shown; the intensity used
to display the two curves is not the same as that used to display the characters.
If the user were to depress function key #1 a second time he would receive a
similar plot, but covering the time period (in day, hour, minute, and second) from
104 19 23 03 to 104 19 33 03. Depression of another key would produce a different
plot if one had been so defined through DIALOG. The limiting factor in the number
of types of displays that can be produced is the number of function keys per IDIIOM .
thirty two. A dry, permanent 8 1/2 by 11 inch hardcopy of the display is available to

588
the user at any time by depression of a 'copy' switch which activates the hardcopy
processor. Since three IDIIOMs can be in use simultaneously and since there is only
one hardcopy processor, a user may have to wait between eight and sixteen seconds
before being serviced.

The processing of the data, the conversion for display on the IDIIOM, and the display
program itself are activities performed within the 1108. Both the program to display
the data and the data to be displayed are sent from there through the interface to the
individual user station. This is not to say that everything is done within the Multi-
processor. The Varian 620i s, although they must store each program and data set
(1500 to 2500 words of the 4000 word core) perform such functions as:

(a) handling the user generated requests for data and the 1108/IDIIOM
input-output requests;
(b) manipulating the data set as presented on the IDIIOM.

This latter function consists of light pen initiated activities which enable the user
to do such things as:
(a) obtain exact coordinate values for any data point;
(b) rotate, in the case of the 3-dimensional plot, the display about the Z
axis until the data presented is in the best viewing aspect for analysis.

Although it may seem contradictory, the Laboratory is not limited to use by three
users even though three users may be viewing their data on the IDIIOMs at the same
time. The reason for this is that program execution can be initiated from only one
Sanders CRT at a time, although the output may be going to all three IDIIOMs. This
leaves two stations available for some combination of either program development
or execution if the printer should happen to be the output medium.

Therefore, although the Laboratory has but three User Stations, it is possible
to accommodate far more than three users at the same time. This is done by time
sharing the system, the one restriction be.ing that no more than three independent
activities can be operating concurrently.

OTHER DEVELOPMENTS
As more experience is gained with different types of experiments, presentations,
and analyses of data, the library of functions available to the user will continue to
expand. Refinements are being made to the DIALOG, SYNTAX, and display capabili-

589
ties to more closely approximate the needs of the experimenters as they, in turn,
become more familiar with the system.

Program generation, execution, and data transmission to and from remote sites
is an area that is being investigated with the cooperation of the University of Chicago.
Here, an SDS 930 computer located at the University can be connected over a telephone
circuit to a User Station (Le. the Varian 620i). The 620i in this case acts as a buffer
between the 1108 and the 930 and handles all I/O between them. The only difference
between a remote user and one physically located in the Laboratory is that in the
latter case the data is formatted within the 1108 for plotting on the IDIIOM CRT;
whereas in the former case the data is simply sent directly to the 620i which, in
turn, outputs it over a telephone circuit. Future expansion in this direction will
allow scientists to have direct and rapid access to the Laboratory (and their data)
without ever having to leave their own laboratories.

590
SUMMARY

Through interaction with CRT displays, both conversational and graphic,

relatively complicated processors can be written, debugged, and operating in terms
of hours rather than weeks. Data can be observed and analyzed; anomalies can be
noted and compensated for. Correlation of data among scientists is facilitated. The
time lag between launch and final analysis has been considerably shortened.

ACKNOWLEDGMENT

We wish to thank R. Cardwell, G. Chapman, H. Darling, D. Taylor and

other members of the staff of Computer Sciences Corporation for their excellent
assistance in the development of the software for the Data Reduction Laboratory.

REFERENCES

1. G.H. Ludwig "Space Sciences Data Processing' IEEE Transactions

on Nuclear Science Vol. NS-14 No.1 February 1967

2. B. A. Walton, J. J. Quann, F. A. Keipert "The Data Reduction Laboratory

Reference Manual" NASA/GSFC X-565-69-56 January 1969.

591
 PART 7

Pattern Recognition
Developments
DESIGN OF AN EXPERIMENTAL LABORATORY
FOR PATTERN RECOGNITION AND SIGNAL
PROCESSING

N. M. Herbst and P. M. Will

IBM Thomas J. Watson Research Center,

Yorktown Heights, New York 10598, U.S.A.

ABSTRACT: An interactive computer-controlled scanning and display

system has been in operation at the IBM T. J. Watson Research Center
for two years. The system includes two flying-spot scanners,
specially interfaced to a process control digital computer, dot-mode
and vector displays, analog input and output facilities, and a
variety of other experimental equipment. The system design and
programming support are described and typical applications in
scanner control, optical character recognition and image processing
are presented.

I INTRODUCTION

The application of computers to various types of non~numeric data, such

as images or time varying analog signals, for analysis and data reduction
is of growing importance. Early experience with character recognition and
adaptive learning techniques showed that large realistic data sets are a
prerequisite for meaningful experiments. Gathering such data is frequently
a formidable obstacle. The system to be described here is a flexible data
acquisition and processing facility required to serve the interests of a
research group working on diverse aspects of pattern recognition, image and
signal processing.

The precursor to this system, described by Potter (1), consisted of

two cathode-ray tube (CRT) flying-spot scanners: one for 35 rom film, and the
other for 8 1/2" x 11" opaque documents. The scanners, originally stand-
alone devices, later were interfaced to an IBM 1401 computer to aid in data
collection, formatting and output. The system was used principally for
binary scanning of typewritten material and experiments in multi-font
character recognition. (2-9) Although it served its intended purpose,
operating experience revealed several disadvantages, such as difficulty in
maintaining a given performance level in the many complex analog circuits
and the mismatch of the character oriented 1401 system to the requirements

595
of real-time computer control. Other drawbacks were a lack of convenient
control of the scanning format, and imprecision in the analog video signal.
When, for example, the system was used to scan organic chemical formulae or
gray-tone photographs elaborate trickery was needed to subvert the normal
character-oriented scanning format.

The availability of process control computers of sufficient power pre-

sented an opportunity to redesign the system described above by expanding
its capabilities and flexibility in scanning and display. Further aims
were to allow easy expansion and maintenance by using standard hardware
components, and giving the central machine extensive access to all periph-
erals under program control.

In the many sQanning systems described in the ,literature the underlying

technology ranges from mechanical devices, such as the Nipkow disc, through
drum, CRT and tv image tube systems. The greatest prograrruning flexibility
is obtained from the CRT system and the least from the rotating disc or drum
systems. The state of the art in hardware and software is well illustrated
in the proceedings of the Munich symposium on flying spot scanning devices
held in 1967.

The system described in this paper differs in philosophy from those

described at the Munich symposium mostly in the scanner control and data
flow aspects of the system design and in the variety of system peripherals.
Three general principles underlie the system design:
A) Man/Machine Interaction
B) Direct Program Control, and
C) Satellite Operation.

A. Man/Machine Interaction

Man/machine interaction is required on several conceptual levels and

is a part of every problem treated by our system. On line recognition of
hand printing and on line graphics manipulation via CRT-light-pen combina-
tions are obvious examples of this philosophy. But every problem in pattern
recognition demands ultimately that a man examine the input and output more
or less interactively. Intervention is also necessary in many problems to
restrict the amount of data presented to an algorithm or to assist in those
cases where automatic data reduction may never be realized due to economic
or technical impracticality.

B. Direct Program Control

'l'he direct digital control of scanners has in the past presented

problems of cost and bandwidth and for this reason indirect methods in-
volving intermediate analog controllers have been used e.g., saw tooth
generators for line deflection. The improving cost/performance ratio of
modern computers allows point by point control of flying spot scanners to
be an economic and technical proposition. No digital machine can yet match

596
the bandwidth of the fastest image input systems but reasonable throughput
combined with good measuring accuracy in the video channel can be attained
in CRT systems with direct computer control of spot location. In addition,
the logical power of the on-line digital computer may be put to good use in
controlling the input format. For example, only those points required by
the program may be scanned and not the entire input field. A heavy emphasis
on programmability and the concomitant flexibility can be used to offset the
large initial investment.

C. Satellite Computing

This concept which is important in general is especially useful in the

case where exceptions occur to the rule of "The larger the machine - the
cheaper the computation." One conspicuous exception occurs in graphics I/O
where the repetitive nature of the display and scanning calculation allow
the profitable use of a small peripheral machine. Bulk random access
storage and large floating point calculations are more efficiently carried
out on larger machines. In our case the close physical proximity to the
Research Computing Center's large scientific machines 360/67 and 360/91 led
naturally to the design of a system where scanning, display, and fixed point
calculations are performed locally and complex computations, bulk storage
and retrieval are performed on the large scientific machines. The necessary
high speed data links were thus included early in the planning.

II SYSTEM ORGANIZATION

A fundamental technical goal of the system is that all parameters

(analog as well as binary) in the extensive input/output peripherals should
be under program control, that the data format should be as free of con-
straints as possible, and that all units in the system should be optionally
under the programmer's control. As a result, there are no hidden knobs on
the apparatus, and the system is in principle diagnosable by program.

Figure 1 shows two possible organizations of a scanning/processing/

display facility. The first is that followed by a production facility and
the second by our system. The first is more desirable economically in terms
of maximizing the possible usage of any parti~ular unit - the second is more
generally applicable, more effectively under program control and more flex-
ible. The central most important part of the system shown in Figure lb is
the central digital computer. The machine must have analog and digital I/O
data paths of sufficient speed and accuracy to control scanners directly and
a flexible interrupt structure in view of the real time aspects of control-
ling a variety of peripherals.

The particular machine chosen here was the IBM 1800 Process Controller,
with the features shown in Figure 2, the main points being the 32K 2~s
memory, 64 channels of analog input via a multiplexer and an A/D converter
with sample and hold, 16 channels of analog output, extensive digital I/O
and 12 priority interrupt levels.

597
 scanner
Processor display
or other input

taoe or disc

hard copy

(0)

Display
Light pen
...
.: .... Input
Scanner

j~

•
~ Input
,r Tablet

~
~
COMPUTER

Storage ,Ir Input

I-
hierarchy TV
+t
j~ L
r

-
I/o
j~
"
•• I...- Dataphone
Hard copy

"-- I/O
Satellite Analog Tapes
computer

( b)
Figure 1 Two possible organizations: (a) a production system
with all units off-line, (b) an on-line research
oriented facility

598
III HARDWARE DESCRIPTION

The special peripherals in the system consist of an 8 1/2" x 11" opaque

document scanner, a 35mm transparency scanner (both inherited from (1», a
Rand Tablet, various displays including an IBM 2250, an auxiliary core
memory, a digital correlator and an analog tape unit. A brief description
of each device is given below.

(35KC WORD RATE) 1442- 6 300 CPM READ

1810 CARD 80 COLUMNS/SEC PUNCH
DISK READER

9 TRACK
60KC
BYTE RATE
800 BPI '---+----'

ONLY

2-1816
TYPE- '----y----' ANALOG
WRITER INPUT
KEYBOARDS CPU MEMORY
64
(ADD- 32K PTS.
PROCESS TIME
INTERRUPT 41/2f./.SEC)
12 LEVELS

48 BITS

26GROUPS
(416 BITS)

LIGHT
PEN
DISPLAY BUFFER
STORE

8 PTS.
-10 TO + 10 VOLTS

KEYBOARD

Figure 2 The 1800 configuration emphasizing the arrangement

of the twelve data channels

599
Figure 3 OVerall view of the opaque document .canner. The
CRT is IDOWlted horizontally. The houaing. of the
document PMTS can be aeen.

600
Figure 4 Film path in 35 mm film scanner; the video channel
PMT and condensing lens are visible.

601
1. Scanners

The opaque scanner (Figure 3) requires high stability and accuracy in

terms of rigidity of construction, in stability of the deflection signals,
and in the signal-to-noise ratio in the measured video. A Thomas 5" CRT with
1 mil spot diameter and magnetic deflection is used. (The high voltage is
25 kv and the deflection angle is 42 .) The deflection amplifier matches
0

the 1800 digital to analog converter speed of 10~s for full scale deflection
change (corner to corner of the raster). Each deflection amplifier is
driven from two 1800 digital to analog converters (DACs) allowing relative
addressing in a 10 : I ratio and giving 16000 addressable but not resolvable)
points in each direction. Litton Industries' deflection amplifier and
dynamic focus units were employed to drive the Celco deflection coils.
Hardware pincushion correction with commercial units is now being installed.
The CRT spot is imaged at 3.5:1 magnification on to the opaque document
and the video measuring circuits comprise three reference photomultiplier
tubes and eight document reflectivity tubes. The match between CRT and PMT
spectral responses is .86. The photon count is sufficient for 100 gray
levels (15).

The transparency scanner, Figure 4, has an identical CRT and coil

assembly, and shares the deflection and focus circuits and CRT high voltage
and bias supplies, but has one reference and one txansmission-measuring PMT.
The spot is imaged at 3 : 1 reduction. This scanner is also used for writing
on Polaroid 5" x 4" plates, by means of a camera assembly which replaces one
PMT (see Figure 15).

2. Displays

'I'he main display in the system was constructed around a 23" domestic
tv tube coated with a P37 phosphor which has a single exponential lag
response. This phosphor was chosen to match a particular display technique
to be described subsequently. The display may be driven from a video signal
derived from either scanner or from signals derived from the 1800 computer,
in analog or in binary form at the option of the programmer (Figure 5). Gray
level is controlled by means of brightness and contrast control signals
derived from DACs. The display unit itself contains no memory, and must be
refreshed from either main core storage, the scanners, or an auxiliary
buffer store. The economies inherent in the use of the image itself
(document or film) as a store cannot be over emphasized.

The IBM 2250, a vector display with light pen, function keys and key-
board, is a commercial product, and has been. described. extensively.

3. Input Tablet

The input tablet is 10" square with 1024 x 1024 resolution and is
transluscent allowing rear screen projection by means of a 35 rom slide
projector built into the console base. The pen coordinates are presented
to the 1800 via two words of digital input. The deflection sensitivity of

602
 CONTROL

DOCUMENT VIDEO
(!) NEGATIVE
0 DOCUMENT VIDEO
...J
«
z FILM VIDEO ANALOG
« NEGATIVE MULTI- UNBLANK
FILM VIDEO PLEXER

BRIGHTNESS
FROM 1800
CONTRAST
FROM 1800

Figure 5 Multiplexing of video signals to CRT display

the scanners was scaled to bring the scanner and tablet coordinates into
correspondence.

4. Binary Correlator

A binary correlator containing a 768 bit shift register and forty

counters has been constructed, (see Figure 6). The binary correlation
function is evaluated at 40 points in 768 ~sec; the peak location and its
value are also detected. The shift register recirculates, being reset only
on command, so that a sequence of vectors can be correlated against the
register contents.

5. Buffer Storage

A magnetic core storage unit (see Reference (10)) with 16K words of
36 bits each is connected to the auxiliary data channel, and is used as
an extension of regular core for data (no programs). A 15 me A/D converter
is multiplexed directly into the buffer for experiments on high frequency
signals. Provision was also made to use the buffer to refresh a television
display system with flicker free gray scale images. This display system has
been designed and is under construction.

6. Auxiliary Channel

An auxiliary data channel, containing a 16 bit shift register provides

serial I/O under channel control. It is used to drive the correlator and
the 23" display above as well as the buffer store.

IV SCANNER CONTROL

1. Scanning Mode

The central decision to be made in designing a scanner system is in the

choice of the scanning mode. Among other things, this choice dictates the

603
interface design, deflection driver, frequency response, the video signal
amplitude and the effective scanning aperture. The scanning mode chosen may
be described as a "defle(:t and dwell" scan. In this mode, the deflection
fields necessary for reading a specified location in the image field are
established while the beam is blanked. The beam is unblanked when the deflec-
tion field has stabilized. The unblanked beam then illuminates the document,
measuring reflectivity with the spot stationary. The scanner is then
blanked and a new point is measured. The beam thus "deflects" and "dwells"
for the measuring cycle.

BINARY CORRELATOR

76B BIT SHIFT REGISTER

LOAD
COMMAND
40 TAPS
SERIAL
DATA

8 BIT COUNTERS
Figure 6 Block diagram of the binary correlator. The counters
are read by the channel at the end of all shifts.
The 40 taps are selected by wiring on interchangeable
cards_

Operation in a random access manner is complicated by the fact that the

necessary deflection settling time is a function of the change in deflection
current or distance from the last stationary spot, and by the additional
fact that the dwell time must be controlled on a point to point basis to
take into account the quasi-random spatial variation in emission of any
phosphor. The deflection settling time may conveniently be set by the
programmer but the phosphor variation demands closed loop control. The
control may be achieved by establishing a predetermined light intensity or
flux in the beam or by measuring the integrated light flux. In either case
a reference and a measuring channel are required.

The deflect and dwell philosophy allows selection of the signal-to-

noise ratio by specifying the integration time, as well as balancing short
deflection time (and consequently a moving spot measurement and high speed
scanning) against slow measurement with a stationary spot. These choices
were deemed to be the prerogative of the investigator and are programmable.

604
The system was thus designed to allow scanning in any mode from high
quality gray scale to lower quality fast binary scanning.

2. Phosphor Correction

An important advantage of the integrated light flux method of phosphor

correction, which amounts to counting the number of photons delivered to the
document, is that the bandwidth requirement on the intensity control loop
is less severe. The operation of this loop may be explained as follows (Fig. 7).
When the beam is unblanked, CRT light emission is integrated in each of the
two channels, reference and measurement. When the integrated reference
light flux exceeds a programmable level (called desired exposure), then a

TABLE 1

Speed Limitations

Deflection Speed 1% Settling Time (Corner to Corner) 10~s

(overall)
1800 Analog output (deflections)
1% Settling Time (Full Scale) 10~s

Programmable Bounds on
Deflection Time min 11Js max 5ll~s

Programmable Bounds on
Exposure Time min l~s max 511~s

Programmable Bounds on
Display Time min l~s max l5~s

Digital Input Speed 1800 16 bits/wd 2~s/word

Analog Input Speed 1800 22 KHz

Time to Obtain 100 Gray

Levels in Scanner Ref.
Beam 10~s/pt

Max. Binary Scanning

Speed With Data Channel
Overlap 10~s/pt

predetermined number of photons will have been used in the measurement and
the integrators are put into a "hold" mode: the video integrator then
contains an integrated signal proportional to the reflected photons, thus

605
 TABLE 2

Scan Parameters

Typical Value

DE Desired Exposure (desired value from 1 volt

reference PMT integrators)

TH Threshold if binary video is required 0,5 V

SB Spot size programmable from 1-25 mils 1 mil

DC Display contract: background level of

display 5 V
o volts = white background
10 Volts=black background

DB Brightness of display
OV = black 10 V
10V = white

NDAO Number of output points/scan cycle

NDI Number of 16 bit packed binary inputs Program Dependant

NAI Number of Analog inputs per scan point

ET Exposure Time in ~s: maximum exposure

time on any cycle (used to guard against 30
hanging up at a locally burnt area of
the CRT) i variable from 2 to 511

DT Deflection time in ~Si variable from 2 to 511 30

Scan Control Word

Bit No.

o Rand Tablet Active

1 DAO Active

2 AI Active

3 DI Active

4 Display Active

606
 5 Slave Display

6 Analog Display

7 Complement Display

8 Select Transparency Scanner

9 Blank Scanner

10 Inhibit Hold

11 Complement Binary Input

12- 15 Display Time (4 bits ~s)

measuring reflectivity. A variation in the desired exposure level allows a

variation in the number of photons used at each point and thus (since the
photon beam follows a shot noise model) a variation in the signal to noise
ratio of the measurement.

After video measurements have been made, a scan cycle is completed by

transmitting the data to the computer driving the display with a video value
(analog or binary) from the appropriate source.

NON UNIFORM
PHOSPHOR DOCUMENT
EMISSION
GRID

UNBLANKI
BLANK
BEAM --- PHOTO-
MULTIPLIERS
VIDEO

ANALOG
INPUT
EXPOSURE 1800
COMPLETE '---------' COMPUTER

Figure 7 Phosphor control loop

The interface, Figure 8, which controls the I/O, consists of two parts
(a) an analog portion containing integrators and signal conditioning circuits

607
 TABLE 3

MAJOR SUPPORT SUBROUTINES AND PROGRAMS

System Programs

SCADS scanning and display monitor; described in text

ZIO binary raster scan to tape, disc, or printer

SCWTP analog scan to tape

SCAN character scan to disc or tape

PHOTO photo output from tape via film scanner

TAP DC tape utility package

DEBUG keyboard manipulation of all process I/O

Data Channel Control Subroutines

BLAST reset channels

DPDI direct program-controlled digital input

DPAI direct program-controlled analog input

DPDAO direct program-controlled digital and analog output

DCA! initiate a data channel analog input operation

DCDI initiate a data channel digital input operation

DCDAO initiate a data channel output operation

TEST test channels for busy

Scanner Subroutines

SRCH searches for black

CENTR acquires a line of characters

THRSH sets the threshold automatically

608
 TABLE 3

(continued)

BSCAN scan a line in X or Y direction and read binary video

AS CAN scan a line in X or Y direction and read analog video

Display Subroutines

tHPRT generates BCD characters on CRT monitor

DPICT set of subroutines for curve plotting on CRT

02250 program for initiating 2250 displays

Utility Subroutines

GRAPH reads tablet at selected intervals for curve digitization

MARGE provides margin setting function of tablet

CA360 communicates with S360 machine via channel adaptor

PARAM provides keyboard control of all parameters by mnemonic

IADDR finds the core address of a program variable

PSCAN prints binary word as row of *'s and blanks

for scanners and displays, communicating with (b) a digital portion which
synchronizes the 1800 data channels with the scanners, displays and other
I/O. The analog portion of the interface uses IGFET technology for the
high speed analog switching and integration circuits; the digital interface
is constructed of. 30 ns logic circuit card~ and operates asynchronously.

Table 1 shows some critical speeds in the laOO/scanner system. The

timing of a representative scan cycle is shown schematically in Figure 9.
The worst case for the integrators in the analog portion of the interface
occurs when analog scanning with a good signal-to-noise ratio is desired
with computer photometric compensation. As many as 11 photomultiplier tube
signals may be multiplexed into the machine, requiring long hold times and
several memory cycles per processed point.

609
 In scanning, the digital interface is loaded with a set of control para-
meters which specify the scanning mode and with a set of data words which
specify quality and speed. The control parameters are incorporated into a
scan control word which is shown in Table 2. The transition from a Zero to a
One in the DAO 9~tive bit resets the interface and starts the scan process.

The maximum bandwidth of the video channel as indicated in Table 1 is

100 kc. Although this is adequate for scanning, it is clearly not sufficient
to give a high resolution tv display. Achieving a flicker-free display from
flying spot scanners, which are limited in speed by the number of photons
available, is a general problem which must be solved by a separate high band-
width video channel or by some sort of storage device for refreshing.
Alternatively, one may attempt to optimize the use of the available bandwidth
by programming techniques.

V. PROGRAMMING

The typical investigator seems to attack his problem by gathering some

data, raster scanned, on magnetic tape and by processing it iteratively
until he has refined his method sufficiently to warrant a special program
for on-line scanning or large scale data gathering. Many begin by only
looking at the printout of the scanned data in order to form impressions
concerning the necessary resolution, adequacy of a binary representation,
noise problems, and possible shading and thresholding problems. These
individuals are greatly aided by a set of programs listed in Table 3 which
allow raster scanning in both binary and analog modes and emphasize con-
venient operator interaction. In particular, the threshold (in binary
mode), the desired exposure (which influences the scanning signal to noise
ratio), and the boundaries of the area to be scanned need careful and
sometimes frequent adjustment.

These principal interactive functions are contained in a monitor

program called SCADS (Scanning and Display System). SCADS provides the
operator with a continuous display from the scanners using a scanning
technique that minimizes flicker. The operator can control all scanner
parameters and manipulate the display in a convenient manner. The pro-
vision for complete interaction with the scanners in SCADS simplifies
the preparation of all other scanning programs since they can begin with
the system properly adjusted on the field of interest.

After adjustment of the scanners with SCADS, the operator can transfer
control to raster scanning programs which record on tapes or disk; or to
his own program, which he can write in Fortran. All special devices are
accessible to the Fortran programmer by a set of subroutines, (see Table
3). Where data channel operations are involved (explained below) the
device subroutines assume that the data tables have already been prepared .
by the main program. In addition to performing the desired I/O operation,
these routines must service all interrupts and error conditions that may
arise. The resulting set of subroutines have convenient calling sequences

610
and do not take excessive execution time (e.g. less than 500 ~sec to
establish an analog output data channel operation).

1. Data Channel Operation

The most important aspect of the system from a programming point of

view is undoubtedly the operation of the data channels.
The interface controls
the synchronization of the data channels and the blanking and unblanking
of the beam. Non-data channel operations ("direct-program control") are
used to set conditions into the output registers or to deflect the beam,
but only a data channel operation with external synchronization can un-
blank the beam. During scanning, the analog output data channel drives
the deflections, binary video is packed (sixteen bits per word) to be
read by the digital input data channel, and analog video may be read
from any combination of the PMT's by the analog input data channels.
These channel operations take very little CPU time; with a typical scan
cycle of 50 ~s per point, interference is about four to six per cent.
The main program can use this time to monitor the video, create and main-
tain displays, and to pack records for output to disc, tape, or trans-
mission to a larger computer.

The programmer must be concerned principally with constructing the

data channel tables and updating them appropriately. These tables may be
viewed profitably as lists with several special formats; scanning is then
an operation which transforms a list of deflections into a list of video
values. Although it would be useful to have a language containing these
lists as primitive data elements, Fortran is adequate for most applications.

The problems of scanning and display are very closely related, the
difference being in the functioning of the video channel and in require-
ments for display refreshing. The same deflection voltage drives the
chosen scanner and display; thus deflecting successively through a list of
coordinates automatically gives a dot display. The list may be chained
to itself to sustain the display under channel control. These displays can
have gray-tone values by manipulating the Display Brightness appropriately
(see Fig. 6).

2. Scanning and Display Monitor

A good flicker-free display is needed for convenient interaction in

the scanning and display of the results of computations on images. Although
hardware constraints such as deflection bandwidth, phosphor decay and the
channel bandwidth available for refreshing the display are the ultimate
limitations on flicker rate (for a given number of points), previous
investigations aimed at developing slow scan tv systems (12) have shown
that a "pseudorandom" scanning sequence can lead to effective reductions
in flicker. This method takes advantage of the reduced sensitivity of
the eye to flicker when the data is presented in a non-systematic manner
rather than one in which bars or stripes are evident.

611
 PARAMETER
REGISTERS
I. EXPOSURE
TIME
2. NUMBER OF I IBOO COMPUTER
J
DAO WORDS
3.NUMBER OF
AI WORDS
,.... BINARY
VIDEO
I SPOT SIZE
DESIRED EXPOSURE
4. NUMBER OF THRESHOLD
01 WORDS
5. SCAN CONTROL
WORD
6. DEFLECTION CONTROL
SETTLING TIME EXPOSURE COMP.
BINARY VIDEO
DIGITAL ANALOG
ANALOG VIDEO
INTERFACE INTERFACE
REF. VIDEO
DISPLAY VIDEO
SIGNAL
DOCUMENT 4 - -:
REF. VIDEO
I VIDEO SIGNAL
UNBLANK UNBLANK
--:SPOT SIZE
1
DISPLAY SCANNER

DEFLECTIONS

Figure 8 Summary diagram of the interface which synchronizes

the data channels, and controls the video signals
for the scanners and displays.

A convenient implementation of this technique was possible in SCADS

because each deflection is the sum of two DAC outputs. The main deflec-
tion list with a square wave sequence, Fig. 10, is sent out over one set
of DAC's. Its size must be chosen so that it can be displayed without
flicker. This table consists of deflections for 4032 points arrayed in a
64 x 63 grid. When scanning, this cycle (which we call a frame) takes
about 35ms. The second set of DAC's are used in response to the end-of-
table interrupt from the first table to provide a suitable pseudorandom
offset to the main grid (known as wobble). The wobble is variable over
a 20 x 20 grid. A full field using the entire resolution of the scanner
consists of 400 pseudorandomly interlaced frames and takes 14 seconds.
Because the phosphor persistence is about .75 second, the perceived reso-
lution is in the vicinity of 20 frames amounting to 100,000 points. ExamplE
of SCADS in operation are shown in the time exposures of Figure 11. The
effect to the observer interested in control of scanning format is quite
acceptable on pictorial material, where sufficient spatial correlation
exists between offset frames to maintain the image. Text and fine detail
is only dimly perceived when viewing the full field, so a variety of featurE
were added to allow the operator to inspect the fine detail.

First, the entire resolution of the deflection table (4,032 points)

can be concentrated in the desired subregion by recalculating the table

612
 BLANK BEAM
UNBLANK BEAM & HOLD UNBLANK DISPLAY RESET

) lH'JBLAN~:

integrate until hold until AID reset integrators

I BE AIl"

DT times oui
either enough sample and hold establish deflectior's
video signal or am'1lifier has for next 01. \
guard timer settled I
times out
~_ _ _- - l -_ _ _ _ _ _- , - - _ - - - , -_ _ _ _"_ _ _ 1~,~
'
___--+
VIDEO SIGNAL
hold establish
new deflec tions I
I
w:::..._ _ _ _ _.....L..._ _ _ _ _ _ _ _ _.....I.._ _ _ _ _ _ _ ._~~_+
I //
ET

'"'¥
or enough video

DEFlECTION AMPLIFIERS ,lew;",

_p_o_st_io_n_I_ _ _ _ _ _ _ _ _ _ _ _._ _ _ _o.-_ _ _ _ _.___ l_._._. . .

-----.-, - - DT-------
Figure 9 Schematic representation of the relationships between
blanking, video integration and deflection in
scanning one point.
in response to signals from the tablet. The table is recalculated while
scanning giving a pleasant merging of the new and old displays, but the
operation takes several second. A second method was to construct a SIna,U
table of 1024 points arrayed in a fine grid centered on the pen coordina~es
given by the tablet. This grid can then track the tablet stylus. The
fine grid is interleaved with the main display so that they are merged
by the eye. A choice of four aspect ratios was conveniently implemented .
This method is useful, but somewhat contradictory in that the overall
display required that the observer be sufficiently distant to avoid being
disturbed by the wobble, while he must be considerably closer to see the
finest detail given by the auxiliary grid.

To resolve this, the video from the fine grid can be read into the
computer and sent out on the auxiliary data channel with deflec:tions gi,,·jmj
a selected magnification (1 to 10 times). This requires careful mode
switching; one frame is a normal scan showing the entire field, while
simultaneously the tablet pen coordinates are read and smoothed. The
next frame is a scan of the fine grid, acquiring the binary Video, and
also showing it, one-to-one on the monitor ("slave-mode" video). 'The
third frame consists of the same video sent out from the 18rjO with a
magnified deflection table ("1800-generated" video). The scanner must
be blanked to avoid interference. The sequence is then repeated to give
a continuous effect. Each frame uses a completely different data flow
as shown in Figure 12, illustrating how the system can be dynamically
reconfigured. A time exposure, Figure 13, approximates the effect.

613
 A keyboard routine allows setting of parameters through a set of
mnemonics (PARAM, Table 3). This is convenient for repeating a precise
set of conditions, however, keyboard use is rather slow. Continuous

4 63 •
(II I I I I I I
_l
: - -J
: 64

SCADS' SCAN PATTERN

Figure 10 Square wave deflections used in main SCADS raster.

control is achieved by a set of ten potentiometers attached to the analog-

input multiplexer to be read under program control. A set of switches
connected to a digital input group serve as auxiliary sense switches, and
are used to inhibit readings of the knobs to prevent drift or accidental
changes to the settings.

Margin adjustment is perhaps the most common interaction required

in scanning. A joy-stick (13), the typewriter, and the tablet input have
variously been used in our experiments. The tablet is easiest to use as
it gives simple one-to-one control with operator feedback via the display.
Pen movements are easily associated with events on the display, which
may be augmented if necessary by putting a copy of the document on the
tablet.

VI. APPLICATIONS

1. Text Reading

One principal application of this system is in the development of

technique for character recognition and page reading (2-9,13). The experi-

614
615
 ments and methods will be described elsewhere in detail; our motive here
is to show how the system organization facilitat~ experimentation and
allows entire applications systems to be "breadboarded".

Tablet Scanner

READ TABLET
COARSE SCAN

Monitor
(0 )

Scanner

Deflections
DAO r----t'L-,-.--J

FINE SCAN AT PEN COORDINATES

1800 READS VIDEO

(b)

Deflections
1800 DAO~---~I

MAGNIFIED REDISPLAY

(c)
Figure 12 In the scan/redisplay mode, (a) the tablet coordinates
are read while the monitor shows a coarse scan of
the document; (b) the video is acquired by the 1800
from a fine scan at the pen coordinates; (c) with
the scanner blanked, the video is fed-back to the
display with a different set of deflections.

Some of the peripheral problems of character recognition involve

appropriate strategies for line finding, centering, character segmentation
and threshold adjustment (for binary systems). Accordingly, these functions

616
have been modularized in our character scanning program. The investigator
can use the prepackaged routines (which are conventional in approach) or
substitute any of his own algorithms for experimentation.

This character scanning program communicates with the display and

monitoring program described in the previous section so that the tablet
can be used to define regions for scanning and to specify their margins.
Values are passed through the Common regioni programs may be called into
execution through either the typewriter or the console buttons.

The video of the scanned and isolated characters can be redisplayed

on the 2250 for inspection and labelling and may be written on disk or
tape for subsequent experimentation. The recognition is accomplished
by program, or by means of the external hardware correlator. The auxi-
liary storage buffer is also available for storage of prototype characters
or other reference data. Results can also be displayed on the 2250 to-
gether with the original video (see Fig. 14). Recognition and decision
techniques requiring long calculations can be carried out on the larger
remote machines using the communications adaptor for transmission. Having
all parts of the scanning and recognition system together and on-line
in this way opens many new possibilities to experimentationi in particular,
feedback of the decision result to the scanning program allows self
adaptation at almost every step.

2. Image Processing

Proces:>ing of two dimensional gray.,-scale images interactively requires

adequate means of data input and storage, a large high speed machine (or
a special purpose processor) for the actual processing, and a high quality
output (either photographic or flicker free display). A general analog
scanning program communicates with the scanning monitor to find the region
to be scanned, and raster scans on to magnetic tape at the desired reso-
lution. A header record records scanner parameters and a label for each
image. A histogram of video values is also written for use in later
processing.

Tapes of the same format can be used to generate photographs by a

Polaroid attachment to the 35 mm film scanner. Birghtness values are
transformed by table look-up and interpolation to equalize the non~linear­
ities of the Polaroid process. The system is calibrated by writing out
a test chart of known values, using the opaque scanner to measure the
reflectances, and then computing and storing an equalization table on disc.

Fourier domain processing of the images (e.g. Fig. 15) is currently

carried out off-line, however, an on-line system to the Model 91 is being
implemented. Under the MVT (multiprogramming with variable number of
tasks) operating system, a small nucleus task will be permanently resident
in the Model 91, waiting for the 1800 to initiate a transaction. If an
image is to be transferred, then the nucleus will request sufficient
storage from the MVT monitor. When the request is fulfilled, video will

617
Figure 13 A fingerprint being scanned in the scan/redisplay
mode. The contents of the bright subraster, which
tracks the pen position, are magnified and redis-
played to the upper left.

618
en
~
Figure 14 Character recognition pre-editing using the 2250.
-
Upper line is scanned video analyzed into vectors.
Lower line contains operator entered identification.
Recognition results can also be displayed.
~
I.
I • ••
I I
,

I I
••~.
•
,

•
~. .. I•
'~.~
••
•• •
=.
.. .
I
I '

I.
I
• I

• I ' "
• ..-=- •
ORIGINAL IMAGE AMPLITUDE
SPECTRUM

-.-.-.-~:;:-.
•
.:.:.:.~: •
.... ...'.:
:.:::.:..
1-. ......
.:.:.
;:.~~
rs,•••~
:~-~~ ..._-
R-16 R-32 R-6 R-128
IDEAL WW PASS FILTERED IMAGES
Figure 15 Ideal low pass filtered checkerboard of 256 x 256
bit resolution with 8 bit gray scale used as a test
pattern. The amplitude spectrum is a regular array
of delta functions. The parameter R is the radius
of the isotropic filter. The effects of sinusoidal
interpolation are seen in the lower pictures. The
photos were produced using the Polaroid attachment
to the film scanner.
transferred to the filtering program and the results will be transferred
back to the 1800 and held in buffer store. A portion of the image can be
observed with the pseudorandom display system, but the only method of
viewing the entire image at this time is to make a photographic print. A
flicker-free tv display refreshed directly from the core buffer is currently
under construction, and will allow direct high quality viewing of the image.
~ilter input, region selection and parameter control will be accomplished
through the tablet and the keyboard.

Timing will, of course, depend on the desired resolution and availa-

bility of space in the Model 91, but preliminary estimates give times for
transform-filter-transform, transmit, and load buffer of less than 10 sec
for 256 x 256 images. The Model 91 processing time is less that 3 seconds
using the Cooley-Tukey Fast Fourier Transform Algorithm.

Images presently are stored in the 2314 disc storage units of the
Model 91. Output to photographic prints, which is fairly time consuming,
can proceed in the background on both the Model 91 and the 1800 as only
one line at a time need be transmitted.

In this application, the system is serving as an advanced terminal

for the large machine, servicing the special I/O equipment, and dealing
with the operator. This hierarchy of processors is quite natural to this
problem, leading to a convenient segmentation of programming, as well as
allowing the investigator good control over his program without disrupting
operations on the larger machine.

3. Signal Processing

Analog signals can be conveniently buffered on the analog tape recorder

and digitized at rates up to 22 kc. This has been useful in experiments
in electrocardiagram analysis and speech recognition. The displays and
tablet have also been of use in editing data and observing results. Some
sample outputs are shown in Figure 16. High speed signal analysis is
achievable at rates up to 15 mc using the buffer store and auxiliary
A-D converter. These results are then read directly into the Model 67
under TSS (Time Sharing System). This is a convenient method of acqui~ing
data for later processing at leisure under time sharing, and is expected
to be used more widely in our laboratory.

4. Other Applications

The system has also been used extensively for many other applications
including line drawing (Figure 17) and map analysis, chromosome analysis
(Figure 18), and studies of x-ray movies. The tablet has been applied
to digitizing curves and manual entry of fingerprint characterisitics.
The displays have been used for data reduction by a solid state physicist
taking data on another 1800, for cluster display of multidimensional data
from a variety of sources, for experimental text. editing, and psychological
testing of visual perception (14). Even though flexibility was a primary
design aim, the ease with which the system has been applicable to these
many diverse problems have been gratifying.

621
Figure 16 Pairs of electrocardiagram signals. The upper trace of
each pair is the input data as recorded on analog
magnetic tape. The lower is the output of a program
to select arrythmias at eight times real time. Filter
parameters can be manipulated experimentally.

622
 I

Figure 17 (a) CRT display of scanned utility map containing

line data, multiply oriented alphanumerics, and
noise. (b) Display of above on 2250 after
processing. Line information has been replaced by
vector approximations; characters have been recognized
and regenerated artificially. The map is now ready
for contextual editing.

623
Figure 18 Chromosome analysis experiment. From the 35 rom film
scanner, the binary video is analyzed into vectors
for the 2250 display. Here the counting program
indicates 46 chromosomes, 1 cell body, and 1 noise
pattern. Scanning and analysis take 3 seconds at
256 x 256 resolution.

624
VII. CONCLUSION

A graphic I/O system has been described containing a variety of equip-

ment controlled directly by a digital computer. The combination of flying
spot scanners, CRT displays, input tablet, and analog and digital I/O with
effective programming support has given our experimenters the freedom to
attack many problems in a convenient and flexible manner. By reducing the
need for special hardware, construction as well as maintenance were reduced.
(These requirements are transformed into the writing, debugging, docu-
mentation, and maintenance of programs which is perhaps less difficult.)

Direct digital control of the scanners and displays, although it

sacrifices some speed and requires large amounts of core, leads to great
flexibility and programmability. At the same time, it combines ideally
with point-by-point scanning in the deflect and dwell mode, which gives
unusually good video quality, accurate phosphor noise correction, and a
signal-to-noise ratio controllable by program. The advantages of having
the scanner (or other data source) and experimenter on-line at the same
time, as well as access to a larger computer through a high speed communi-
cations link, have also been discussed.

The system has been proven in two years of operation on an open-shop

basis. Programmers and engineers are able to operate the special equipment
through Fortran programs by themselves, in a variety of applications. In
many cases, the applications seem to have been suggested by the availability
of the equipment.

The interaction with many different kinds of I/O equipment enriches

the computing milieu significantly. With the exception of physical size
and present cost, both of which will reduce significantly, we feel our
system may be indicative of the sort of terminals that will be needed in
the future.

ACKNOWLEDGEMENTS

Many individuals devoted their energies and talents to the design,

construction, and operation of this system. In particular, Dr. J.
McLaughlin contributed extensively to the initial system formulation and
its realization. He designed the digital interface with the assistance
of J. Duffy, E. Carey and C. Marr. A. Sebastiano, D. Fraleigh, and P. Lux
also participated in the construction. The contributions of Dr. W.
Fitzgerald especially in the debugging and performance evaluation were
important. Miss M. Miller, G. Koppelman, and R. Ascher provided the
system's programming package. We also wish to thank our colleagues, A.
Katcher, Drs. G.Nagy and R. Casey, who kindly allowed us to describe some
of their work in the applications section. The serial I/O adaptor and
the auxiliary core buffer were designed by N. Kreitzer. Dr. D. N. Streeter
gave the primary stimulus, and his enthusiastic support.

625
 REFERENCES

(1) R. J. Potter, "An Optical Character Scanner", SPIE J., vol 2, p. 75,1964.

(2) L. A. Kamentsky and C. N. Liu, "Computer-Automated Design of Multi-

font Print Recognition Logic", IBM J. Res. and Develop. vol 7, pp. 2-
13, January, 1963.

(3) c. N. Liu, "A Programmed Algorithm for Designing Multifont Character

Recognition Logics", IEEE Trans. Electronic Computers, vol EC-13
pp. 586-593, October, 1964.

(4) C. K. Chow, "A Class of Nonlinear Recognition Procedures", IEEE Internat'J

Conv. Rec., vol 14, pt 6, pp. 40-50, March, 1966.

(5) G. Nagy and G. L. Shelton, Jr., "Self-Corrective Character Recognition

System", IEEE Trans. Information Theory, vol IT-12, pp. 215-222, April,
1966.

(6) C. N. Liu and G. L. Shelton, Jr., "An Experimental Investigation of

a Mixed-Font Print Recognition System", IEEE Trans. Electronic Computers,
vol EC-15, pp. 916-925, December, 1966.

(7) R. Casey and G. Nagy, "Recognition of Printed Chinese Characters",

IEEE Trans. on Elec. Computers, vol. EC-15, No. I, pp. 91-101,
February, 1966.

(8) R. G. Casey and G. Nagy, "Autonomous Reading Machine", IEEE Trans.

on Computers, vol c-17, No.5, pp. 492-503, May, 1968.

(9) R. Bakis, N. M. Herbst, and G. Nagy, "An Experimental Study of Machine

Recognition of Hand-Printed Numerals", IEEE Trans on Systems Science
and Cybernetics, vol. SSC-4, No.2, pp. 119-132, July, 1968.

(10) N. H. Kreitzer, "Buffer Store for an 1800 Computer and Experimental

Magnetic Recording System", IBM Research Report RC-2362, February,
1969.

(11) L. Mertz, Transformations in Optics, J. Wiley (1965), New York,

p. 77.

(12) S. Deutsch, "Pseudo-Random Dot Scan Television Systems", IEEE Trans.

on Broadcasting, vol BC-ll, No.1, pp. 11-21, July, 1965.

(13) G. Nagy, "A Preliminary Investigation of Techniques for the Auto-

mated Reading of Unformatted Text", Corom. of the ACM, vol. 11, No.7,
pp. 480-487, July, 1968.

(14) A. B. Dill and J. D. Gould, "Flickerless Regeneration Rates for CRT

626
 Displays as a Function of Scan Order and Phosphor Persistence",
Human Factors, (in press).

(15) P. M. Will, "Flying Spot Scanner Control and Video Processing Circuits",
IBM Research Report (in press) •

627
 DISPLAY ASSISTED DESIGN OF
SEQUENTIAL DECISION LOGIC FOR
PATTERN RECOGNITION

D. A. Bell

Division of Computer Science, Ministry of Technology,

National Physical Laboratory, Teddington, Middlesex,
England.

I ntr od uc t io n
The des ign of a prac tical mac hine to read numerals,
handwritten in natural style, must satisfy these criteria:
a) It must be reasonably fast, an average tfi.('01Jghput
of 300 characters per second being required.
b) It must accept considerable variation in style
of writing, size and thickness of the characters.
c) It must be amenable to easy development in the
light of exper ience.

The machine currently being built uses an

extens ive hardware scanner and preprocessor system,
backed up by a small DDP-516 digital computer. This
is equipped vJith some display fac ilities, such a.s
a pOint-plotting display, graph plotter and DIDS 402
alphs.nurneric display. The scanner and preprocessors
reduce the character being scanned, first to a set of
four pictures showing the prine ipal line directions J
then to a list of the significant features, such as
line endings, corners, tr iple junct ions and crosses.
The processing of a single character is shown :1.n
Fig. 1, and the technique for extracting the features has
been descr ibed in refere nce [1]. Proce s sing of one c harac ter
takes about 3 milliseconds, and the features are fed, as
they emerge, to the on-line computer Vlhic h takes uver the
problem of interpretat ion.

629
 The Dec is ion System
Since the recognition process must be fairly rapid,
several lines of approach are ruled out from the start.
In particular, the accumulation of a large library of
styles of handwr itten characters is impractical unless a
very rapid searching technique is available, such as a
sophisticated content-addressible memory.
A sequential decision technique has been adopted,
in particular a binary tree of deciSions. It is not
strictly necessary to have a binary tree" but in the
des ign stages it reduces the number of paths to be
considered" sime there is a unique way from the root
to eac h leaf.
Each node takes a decision based on the answers to
various questions posed to the feature list. A question
might take the form: Are there any of the following
features in the lower right-hand part of the
character •••• A character J dropped in at the root of
the tree" will thus follow a path to a leaf" at which
point it will be recognized or rejected.
The design of such a deciSion tree requires the
use of a spec ial language, which may be imrementally
compiled" together with an appropriate data structure
and graphics cOrnIIentary fac ilit ies.
!he Tree Language
The definition of a binary tree structure is greatly
simplified if the nodes may be given meaningful names"
and the functions to be performed can be specified with
the minimum of fuss. A simple language for the purpose
has been developed which satisfies the following needs:
a Mnemonics for all functions and features
b User supplied node names
c Methods for defining arbitrarily complex decisions
d Means of accumulating performance details
e Completely patchable without recompilation
f Capable of complete back-compilation
Criterion a) naturally introduces the well-known
construction:
IF <condition> THEN <statement> ELSE <statement>
but criterion e) unfortunately eliminates any block
structure without great complication, and hence the
<statement> in the above must only be an implied goto
with a node name. Item c) provides for boolean procedures"

630
b) is a natural requirement, and f) provides both a
r~mning commentary and a means for retrieving a patched tree.

The feature shapes have to be given names like E7,

R1 (end in direction 7, rightangle in orientation 1).
A small sample of the languame is given below, the node
names FRED, FRANK, JIM and JOE are used.
FIELD (1,24,1,16)
IF ANY (E3, El, E2) THEN FRED
IF NONE (T7, X1, Y2, Y4) THEN JIM
RESULT 1
FRED: RESULT 3
JIM: IF NOT UP E7 THEN JOE ELSE FRANK
etc.
The Data Structure
Two forms of data structure are used, an elaborate
design-phase structure, and a fast-running structure.
The first satisfies all the language criteria, the second
eliminates d), e) and f) in the interests of speed. Only
the first structure will be discussed further.
A basic list manipulation scheme is used for all
parts of the data structure. The statements of the
language each have a block in the MAIN list, which
reflects the order of writing the tree. The body of
each statement is held in one or more blocks in a SIDE
list. All references to labels in the language generate
pointers to the actual NAME list, which therefore must be
present at run time. This eliminates the need for
backplugging labels, and in particular permits the
removal of a labelled statement at a later date. At run
time, if a label is called for and it does not exist,
a special BIN is created, bearing the name of the missing
label, into which is placed the serial number of the
character being processed. The BIN-HEAD is strung on
to the BIN list and it carries a SIDE list to accomodate
any more characters which may came that way. Bins may
also be inserted deliberately in the tree at suitable
points. In this way a stream of input characters may be
sorted by the tree into a series of bins, each of which
may be processed as a group, once a patch has been made
to the tree.
A simplified diagram of the data structure is shown
in Fig. 2. Blocks B, H, M are in the MAIN list, each
has a SIDE list of one or more blocks. Blocks A, F,
J, L form the NAME list, A is the name of statement B,
and L is the name of M, while the name s F and J are

631
 "
FIG. I

BIN NAME /"AAIN

FIG. 2

632
undefined. Since I hae referred to F, a bin-head E has
been formed, with SIDE liet G and K. When N refers to
J another bin will be set up and strung on to E on the
BIN list. C contains a pOinter to L which will cause
control to pass to main block M.
Display Commentary
The original tree is designed with reference to the
typical characteristics of feature lists. These are
drawn, by graph plotter, in the manner shown in Fig. 1,
namely as symbols in their correct position and
orientation. The designer therefore has an idea of what
to expect when the tree is in operation. This is fed
back to him at run time by reproducing on the screen
the drawing of the feature set, and by moving a symbol
showing the point of attention of the tree on the
features. Normally a search area of rectangular or
sector shape is in operation, and this also appears on
the screen. Finally a running back-compilation of the
current statement is shown, to assist analysis. These
facilities are useful when a first attempt is made to
break in a new tree on a few characters, but for larger
volumes of traffic, the bin method is better. The
alphanumeric display shows the state of the bins on
demand, and by strategic positioning of the bins, the node
requiring immediate attention is pinpointed.
System Controller
The on-line teletype has proved to be the most
convenient control peripheral for nearly all of this
work, but a joystick, operating a cursor on the display
screen, has proved useful for communicating positional
information. The control system permits the bins to
be manipulated to concentrate attention on the problem
characters, by feeding a bin-ful into the tree until it
can be recognized. Likewise, statements in the tree
can be readily unplugged, flagged, replaced, inserted or
modified without upsetting the already developed parts of
the tree.
Conclusion
Early versions of the system, written in DAP-16
assembly code, have demonstrated that the system is viable
and that it is very difficult to design a good tree
without elaborate CAD techniques. The present verSion,
written in the high-level assembly language PL-516,
develops those techniques.

633
 The work described above has been carried out at the
National Physical Laboratory.
Reference
[1J J. R. Parks: A Multilevel System of Analysis for Mixed
Font and Hand-blocked Printed Characters Recognition. in
Automatic Interpretation and Classification of Irnages:--
A. Grasselli (ed.) Academic Press (1969).
 INTERACTIVE SIGNAL PROCESSING

R. A. Freedman
Control Data Corporation, Digigraphics System Division
Northwest Industrial Park, Third Avenue, Burlington,
Mass. 01804, U.S.A.

1::1 troduc tion:

Digital Signal Processing involves the manipulation

of linear time invariant waveforms utilizing digital tech-
niques. The field of digital signal processing can encompass
the analysis or synthesis of time or spatial signals for a
wide variety of applications. These include measuring the
response of servo systems, spectral analysis of such things
as mechanical vibrations in structures, noise in electronic
equipment, and speech waveforms. Other applications include
analyzing seismic returns, simulating coherent optical
systems, and the processing of radar signal returns. Certain
aspects of pattern recognition and picture processing are
also amenable to the application of digital signal processing
techniques.
In each of these fields the data is represented by a
sequence of equally spaced quantized samples, ie. time series
or spatial series. The basic classes of operations to be
applied to this type of data are analysis, synthesis, and
filtering. Analysis is to see what you have. Synthesis is
to see if you can create it. And, filtering is to modify
it in some way.
There are three techniques used to perform linear
filtering. These are filtering in the frequency domain,
convolution, and recursive filtering. Until recently, most
research into digital filtering was dorected toward methods
involving convolution and recursion because, even with high
speed digital computers, the calculation of a Fourier
transform of any reasonable size took a prohibitively long
time. Because of this, frequency domain anal sis by computer
was impractical for many applications.
635
 In 1965, a paper was published by J.W. Cooley and
J.W. Tukey which described an algorithm for calculating
the complex Fourier series in N 10g2 N operations instead
of N2 operations. Since its introduction, the Fast Fourier
Transform ( FFT ) algorithm has caused a great surge of
activity in the field of digital signal processing.
Not only has it become practical to do large Fourier
transforms by general purpose computer, but there has been
a tendency to emphasize higher and higher speeds through the
development of special purpose hardware, the "FFT Box".
These are excellent for certain types of well defined appli-
cations where there is a lot of data coming at you at high
speed , and you know exactly what is to be done to it.
There is however, a large class of applications which are
better handled by a system with greater precision and flex-
ibility than can be economically provided with an FFT Box,
and which do not require such great speed.
One of these applications is the study of digital
signal processing itself. This requires ~ system with
great flexibility in both implementation and approach.
A general purpose computer provides flexibility of imple-
mentation. To see the effect of word size on noise in an
FFT, for example, a general purpose computer can be program-
med to exhibit any effective word size. The only cost is
time.
To ~btain flexibility in approach is more difricult.
Since the field of digital signal processing is so new, and
the number of applications is steadily growing, there is a
need for a general purpose system which can be used to
develope methods of applying digital signal processing to
new problems. What is needed is a means of allowing an
experimenter to have readily available a system embodying
the basic tools of digital signal processing which he can
apply'at will to any problem at hand. A general purpose
computer with a comprehensive set of programs is ideal from
the point of view of flexibility of implementation, but not
of approach, because generally, the response time of conven-
tional systems is too slow. Even with a teletype terminal
the response is not fast, and the method of presentation
of output data to the user is clearly not adequate. A new
approach is needed for controlling the way the computer is
applied to the signal it is going to process. Interactive
computer graphics provides the desired approach. It provides
for rapid interaction between the user and the computer and
it presents information in a way which is much more meaning-
ful to the user.
The principle idea behind "Interactive Signal Process-

636
ing" as described in this paper is to provide the user with
a completely general purpose set of tools which he can apply
to a wide range of applications in digital signal processing,
and which allow him complete flexibility in which of these
tools he will apply, and which will give him instant response
as to the result of each experiment. This is accomplished
through the use of computer graphics CRT terminals driven
by a comprehensive set of programs in a large scale digital
computer. The CRT display is the key to this approach in
that it both presents the data in a meaningful way, such
that the user can grasp the implications of what he is doing
without having to pour over complicated printouts, and it
displays before him for instant use, all of the facilities of
the system. He is then free to exploreany avenue of interest
because he is not bound by any preprogrammed restrictions
as to what the system is supposed to do. In a well designed
computer graphics system, the man programs the computer, the
computer does not program the man.
This paper describes a system of programs specifically
designed to apply the techniques of interactive computer
graphics to the problems of digital signal processing.
Multiplication in the frequency domain is the principle
method of digital filtering used in the system thus far, and
therefor, the system relies heavily on the FFT algorithm
to maintain adequate response time in many of the operations
performed.
Since the principle application to which this system
has been put in the year that it has been operational, has
been the enhancement of photographic images. This applicati-
on is used as an example of one way thalt this system may be
used to simulate coherent optical signal processing.
Examples of image enhancement in the frequency domain are
discussed, and representative photographs are included.
Those aspects of the FFT algorithm that were important in
the implementation of this system are discussed and the
relationship of the FFT to the two-dimensional Fourier
transform is shown.

Computer Configuration:
This Interactive Signal Processing system was
developed by the author using the facilities of the
Digigraphic Systems Division of Control Data Corporation
at Burlington, Massachusetts. The computer configuration
consisted of a CDC 3300 computer Which is a 24 bit word-
length machine with a 1.25 usec. cycle time. the system
included 72K of core memory, 6 tape drives 2 disk drives

637
containing 5 million characters each, high speed line printer
, card reader and punch, Calcomp plotter, CDC Digividio
display, CDC Interactive display model 274-3344 Digigraph
with 8K of display buffer memory, and a CDC modea 278
high resolution jumping spot scanner.
The model 278 scanner was used to digitize photographs
for input to the sysltem, and the Digividio was used to
display the output pictures for photographing. The Digividio
is capable of displaying a 444 x 444 raster at 32 gray levels
at a rate of 30 times per second.
The MASTER Op'3rating System under which ISP operates
is a file oriented multiprogramming system which can run
up to 8 programs simultaneously. It has proved to be
effective in supporting interactive graphics, as the inter-
rupt handlers for graphics are embedded in the operating
system and are transparent to the user. This allows the
system to provide adequate response t:Lme to the graphics
user when he needs it, while automatically freeing up core
for background jobs when he is thinking.

Program Organization:
The Interactive Signal Proeessing programs are
written primarily in Fortran with certain critical parts in
Assembly language. The system consists of a series of tasks
that are called into execution by picking light buttons on
the CRT display with a light pen. The system operates
under the CDC ~~STER operating system and may be multiprogra-
mmed with other graphics or batch jobs.
The structure of the programs is such that the graphics
system appears to the user to be an array computer which
manipUlates arrays of complex floating numbers, or which
manipUlates two-dimensional real arrays, ie. pictures.
The computer operates in two modes, the one-dimensional mode
(I-D), and the tWO-dimensional mode (2-D).
The one-dimensional mode uses eight registers of
which six may be referenced v~a the display. Each register
is an array of variable legnth, usually a multiple of 2,
ie. 8,16, ••• 128,256, floating numbers. For operations
dealing with complex numbers, the registers are used in pairs
with the odd numbered registers representing the real pa.rt
and the even ones representing the imaginary part. If it
is desired to dear only with real data, then either may be
used. These registers are the operands of the array computer
and may be loaded from or stored into the data base on the
disk. They are the source and destination of data for the
instructions of the simulated array computer.

638
 The set. of instructions for the array computer is the
list of signal processing and arithmetic functions available
to the system. For example, execution of the cross-correla-
tion function woud take the cont~nts of register 5, cross-
correlate it with the contents of register J, and deposit
the result in array register 1.
The list of functions implemented up to this time
are as follows, for the I-D mode.
NULL OP8RATCR AUTC-CORR8LATE
FAST FOURIER CROSS-CORRELATE
INVERSE FOURIER LONG CONVOLVE
TIME TO COS~SIN CONVOLVE
COS-SIN TO TIME DECONVOLVE
TIME TO POWER-PHASE TIME SHIFT
POWER-PHASE TO TIME NORMALIZE
INTEGRATE DIFFERENTIATE
LOG ANTILOG
By combinlng these and the arithmetic functions, a host of
other functions may be implemented.
The two-dimensional mode provides the means for
interactively displaying two-dimentional images. The data-
base holds several pictures, the exact number depending on
their size. Each picture is identified by its position on
the file. The operator specifies the source, modifier and
destination pictures for each instruction to be executed.
For example, one might want the product of pictures 1 and 4
and put the result into picture 2. The source would be 1,
the modifier 4, and the destination would be 2. Each
picture consists of N records of M samples each where each
sample or pell (picture cell) is a 48 bit floating number.
N is usually but not necessarily a multiple of 128 records,
and M must be a multiple of 128 floating numbers which is
the size of the block legnth of the disk file. Array legnths
which are multiples of powers of 2 are necessary because of
mechanism by which the FFT algorithm operates. A picture
then, is a rectngular array of pels which is a multiple of
128 pels on a side. A typical picture might be a 256 x 256
matrix, or a 128 x 256 matrix if disired. Local operations
may be performed on pictures by using the facilitis of the
l-D mode on individual records of a picture on thedisk.
The 2-D mode is organized to facilitate experimentation into
such topics as picture processing an image enhancement in
the frequency domain by use of the two-dimensional FFT.
Data Base:
The data base for the system cnsists of one large
file (the PIX file) on the magnitic disk memory. The file

639
consists of several thousand records normally of 102~ six
bit characters in length. This is equivalent to 128 fourty-
eight bit f~oating numbers in each record. The system allows
any number of records to be written or read consecutively
starting at any record. This is useful for being abMe to
rotate pictures on the disk. Information may be stored in
records whose length is in multiples of 128 words.
The format of the data base in this system is dictated
in part by the charact9ristics of the computer used, the
CDC 3300. When dealing with pictures, it is desirable to
manipUlate as large blocks as posib1e to minimize I/O time.
The largest core block accessab1e at one time in the 3300
is 32768 24 bit words, or 16384 48 bit words. The largest
block that can be handled conveniently at one time is
therefor 128 x 128 floating samples. If this system were
implemented on another computer, tr~ basic record size
should be chosen to be as large as can be handled, because
when rotating pictures, the I/O time is inversely propor-
tional to the square of the record size.
The first 128 records of the PIX file are used as
a save area in the I-D mode When using only that mode, and
as a save area when swapping 128 x 1~ blocks in the 2-D mode.
The 2nd 128 records are used as memory for arrays in the
l-D mode when it is desired not to write into the picture
area of the file. The rest of the file is used for storing
pictures. All references to the Pix file are made through
one subroutine. The BLDISK routine calculates the record
number for all reads or writes to thePIX file based on
the Picture number, Line number within a picture, and the
size of the picture which the user or anothersubroutine
can set. The user specifies the picture or reord of a
picture that he wants to access by entering the appropriate
parameters via the keyboard of the display. The current input
parameters and the resulting record number are always dis-
played on the CRT.
Besides the PIX file, there is a global data file which
stores on the disk data tables common to all tasks and
subprograms of the system. This file can be saved from run
to run on tape so that the sytem need not be reinitialized
each time it is used. There is also the LEARN file which
is"Used to save a record of light pen picks which can then
be replayed as a function, or printed out as a record.
As part of the global data file, the System Registers,
System Buttons, and System Bits are stored. The labels for
these are r~ad in on data cards when the system is initializ-
ed, and they can be changed as the system is expanded.

640
Figure 1. The one dimensional mode showing Convolution.

The CRT Display and Its Use:

Representation of Signals
Signals are represented on the display in two diff-
erent ways. In the one-dimensional mode each of the eight
array registers that are mantained in core can be displayed
as a horizontal trace whose envelope is the locus of points
of the amplitudes of the descrete values of theelements of
the array. It is a plot of amplitude versus time or frequ-
ency. Associated with each line is a set of line registers
displayed to the left which contain parameters pertinent to
that line. These include the display scale factor, a
position shift count, a logging factor, the address of the
line on the data base, and several others. To the right is a
tag which tells whether the line is displayed as amplitude
or log of the amplitude, and whether the line is in auto-
scale. An asterisk appears next to the last line picked to

641
show that this will be the one used in the execution of the
next operation selected.
The number of lines to be displayed at any time may
vary between one and eight as desired. The amplitude of the
traces is automatically scaled to fill the available screen
area. Lables are displayed below each base line to indicate
the size and origin of the array. A line can be shown as
it appears in core, or in mathematical notation1with the
origin in the center. 0, N/2, N or N/2, 0, (N/2)-1 •
The characters to the right of each line correspond to the
name of th~ Operand shown at the top of the screen.
When operating in the 2-dinensional mode, a picture,
an M by N array can be displayed as a family of M equally
spaced curves, each N samples long. The deviation of each
point on the curve from the center of the line is proportion-
al to the intensity value at that pOint. This type of display
is called a "Contourogram", or a "Ripple Picture".
While this method of displaying two-dimensional images
is not as aesthetically pleasing as that produced by a video
display, such as the Digivideo, the ripple picture method
has some advantages. First of all, it is about the only
practical way of displaying such large amounts of data on a
graphics display as is contained in a picture. The ripple
method has a much greater dynamic range than the video displ-
ay. The Digivideo can display only 32 levels of grey, but
a picture in the frequency domain may have intensities
ranging over several orders of magnitude. Another advantage
is that it is possible to isolate a single point in a ripple
raster with the light pen. This can not be easily done with
a video display. One useful application is to identify and
eliminate individual noise spikes from a picture with the
light pen. Thus a picture can be cleaned up without filtering
in the frequency domain which would cause an overall loss of
resolution. Sev3ral things may be done to a picture as it is
displayed. The aspect ratio may be varied between .01 and 100
where 1.0 is nominal. It may be magnified over a range of
1.0 * E600. It may be logged, or reflected, rotated, or
inverted.
Learning Program
In the operation of ISP, the degree of interaction
between the user and the computer can occur on several levels
the lowest of which is the execution of a simple function up-
on the pick of' the light pen. ( Po. light pen pick is defined
as the act of pointing the pen at an illuminated item on the
CRT and pushing the light pen button so as to cause the
computer to take some action.) The lowest level provides

642
great flexibility since all actions are at their simplest.
However, to do anything useful requires that many light pen
picks be made. When creating something new, this is satis-
factory, but it becomes tedious when a sequence of operations
is to be repeated. There are two ways to get around this.
The first is to have a single pick invoke a complex operatio~
This saves effort, but it implies that the task was well
defined, and therefor does not take advantage of the interac.
tive nature of the system. In short, spontaneity is lost.
A better method is to let the user define a whole task by
a series of simple operations from the displaY, and then
execute the whole thing whenever he wants it.

Figure 2. A "Ripple Picture" of Mona Lisa, 256 x 256 pels.

At the option of the user, the learning program can

be invoked. This will cause the system to remember all of
the light pen picks and parameters entered by the user for
a given period. When a sequence of steps has been accumulated
which leads to a useful result, the user can label this

643
sequence and enter it in the instruction list. He can then
perform the same sequence lat2r on other data, merely by
invoking the symbolic lable. The system will then play back
the system through the display while the user watches. A
permanent printer record can be made of the sequence of oper-
ations for later incorporat:on. in to a program and to clear
the LEARN file on the disk. The user may also do a form of
online programming. The contents of the LEARN file can be
displayed symbolically on the CRT, and may be edited by the
user to eliminate blind alleys.
Operation of the System
To enter a value into any of the system registers the
register is picked with the light pen. This causes a font
to appear at the bottom of the screen. The value is entered
by picking characters of the font or using the keyboard
until the desired number appears on the line above the font,
and then picking XMIT. The number is stored in the register
and then displayed.
The system registers are shown at the left of the
r.creen. There ~re currently four groups of ten registers
each. The desired group is selected by picking Rl through R4.
R5 causes them to be erased to conserve buffer space. The
system buttons are displayed at the right of the screen ~U
are in five groups of ten which may be selected by picking
Bl throur B5. Since in the course of operation, buttons may
be selected alternately from several groups, there is an
option that allows the last ten picked buttons across all
groups to be displayed in a last in last out stack. This
reduces the number of picks required for a sequence of
similar operations.
To change a waveform in any of the registers, the user
merely picks the desired trace and draws in the new curve
with the tracking cross. The computer samples the cross
coordinates, and calculates the element number and the value.
If the system bit is set to modify, the new values of the
elements between the last and the current position of the
tracking cross will be computed and stored into the array,
The position and value are displayed as feedback to the user.
The user may modify a single value, or draw anew a completely
arbitrary waveform. The computer will follow the movement of
the pen, modifying the waveform as it goes. fhe user may
thus draw freehand curves. For waveforms which must be mere
regular, the SEGMSNT mode is provided. This requires the user
to push the pen button each time he desires the computer to
sample the cross position. This allows him to position the
cross accurately so that straight line segments may be drawn.

644
An examine feature is provided to enable the user to interr-
ogate any point on a curve to see what its value is. This
feature may also be used to interrogate a point on a picture.
When a curve has been modified and an operation is to
be performed, such as TIM~ TO COS-SIN, etc, the user must
select the instruction, or pick the EXECUTE light button if
it is already selected. Thus several picks are required each
time a curve is modified. The EXECUTE ON RELEASE light button
causes execution of the instruction each time a change is
made. At the highest level of interaction, the LOOP AND EXE'"
CUTE option causes the instruction to be executed and the
results displayed each time the cross position is sampled.
This allows for example, the user to draw a curve in the
time domain while viewing the result in real time in the
frequency domain. Another example is modifying the phase
at a particular frequency and seeing what effect it has in
the time domain.

Image Enhancement by Computer

The techniques of image enhancement by computer can
be used to eliminate several types of problems in photo-
graphs. The basic technique is simulation of coherent
optical signal processing methods by computer. The goal is
to take an otherwise unusable photograph and to perform
such operations on it so as to make it usable. Since these
'basically optical techniques involve the use of lenses, they
are beset by all the problems inherent in lenses, and with
realizable systems. However, if optical image processing
were simulated mathematically, then the system would not
have to be realizable except during input and output.
Using the computer to simulate the properties of lenses and
optical filters in the enhancement of images, allows opera-
tions to be performed that would be imposible or at least
difficult with lenses. Some of these operations are removing
the blur from a defocused photograph, filtering out noise,
sharpening the edges of a subject, and increasing contrast.
The Discrete Fourier Transform (DFT):

The discrete Fourier transform is a special case of the Fourier

Integeral in which the signal f(t) is periodic, and sampled only at discrete
time intervals.
Where the Fourier Integral is:
F(w) ;;: i rD

-~
f(t)
•
e -J w
t
dt where f{t) is
contmuous
and is a special case of the bilateral Laplace transform,

645
 L(s) = [if) f(t) e
- (0- +j w )
dt where 0-' =0 .
-'-,1)

When f(t) is sampled at discrete intervals,

(.I '
c-
~_ f(nT) u (t - nT)
o
n=-cJ)
and the Fourier transform of fl(t) is :

-->
otb

F(w) =
n=- rFI
Since the transform of a periodic signal consists of impulses at integer
multiples of the fundamental periodicities of the time function. The
frequency domain can also be represented as a periodic sequence of discrete
samples.
Thus the Discrete Fourier transform can take on the form
N -1
A(n) =1.
N ~
x(k) e -j 2 pi nk/N
k=O where n=O, 1, N--l
N is the number of samples to be transformed
The inverse Discrete transform is:
N-l
x(k) = ~ A(n) exp ( j 2 pi n k / N)
k=O

These equations show that it is posible to transform mck and forth

between the time and frequency domains using finite sequences of discrete
samples. A more useful form of the OFT for this paper is as follows:
Letting e = 2 pi n k / N , and W = e j ~ = cos 9 + j sin 9.

Then,
1 N-l
A(n) = x(k) W- 1
~
k=O
N

~
.-
N--l
A(n) W
and x(k) =
n=O
The Fast Fourier Transform:

The discrete Fourier transform could be implemented directly on the

computer, but for speed considerations it is desirable to use the Fast Fourier

646
Transform. Another reason for using it is that the FFT is more accurat ethan
than the conventional method. This is because there are fewer round off
errors and truncation errors due to the smaller number of operations involved.
There are several versions of the FFT algorithm, decimation in time,
and decimation in frequency being the two major classes. The version to be
described in this paper is the decimation in frequency method, attributed to
Sande. Essentially, the FFT is a method of successively deviding an N
point DFT in to a larger number of smaller DFTs. That is, a 16 point
DFT is devided into two 8 point DFTs, the 8 point DFTs are devided in to
four 4 point DFTs, and finally, the 4 poi nt DFTs are devided into eight 2 point
DFTs. Thus as long as the sequence is divisable by two, it can be further
subdevided at a greater advantage in saving time.
As can be observed, this implies that the original sequence to be
transformed must have a length equal to 2m , where m=2, 3,4 .... 10, 11, 12. ie,
N must be a highly composite number. This means that a sequence of arbitrary
length cannot be easily transformed, but this restriction is not unacceptable,
as the economy of the FFT more than compensates.
The output sequences of the FFT differ from the input in that their indexes
appear to be scrambled. The indexes are acctually bit reversed. In orderto
rearrange the output so that it can be used, it is necessary to take the index,
express it in binary, flip it end for end, and use the result as a pointer to the
.desired sample. Fer example, for n=I6, 16=2m , m= 4 bits. So X(OOOI)
maps into X(IOOO),orX(4~)= X(2), etc.
It should be noted that the FFT operates in place. That is, in each
successive iteration, each pair of samples actually modify only themselves.
Thus if a time sequence in an array is FFTed, it is lost, and the discrete
spectrum is in its place. The process is reversible, so that one can transform
back and forth in the same space between the time and frequency domains.

These are some of the many interesting aspects of the FFT algorithm.
There are many more, but this discussion gives some of the flavor.

Implementation Of The FFT~

Although the FFT is faster than the conventional approach, there are
still considerable savings to be had. Most of these are programming
considerations, but a careful study of the algorithm shows that special cases
may be made of those points where the sine or cosine is 0 or 1, to eliminate
additional multiplies. In most computers, it takes a lot longer to multiply than
to add, so at angles of 0, 90, 180, 270 degrees, it is not necessary to mUltiply,
and considerable time can be saved.
Additional time can be saved by not having to calculate a sin or cosine,

647
or inverted address every time it is needed. Thus it is good practice to provide
two tables, each N samples long. The sine table consists of one period of a
sine wave of unit amplitude, ie, S(n) = Sin (2 pi n IN). Further space
can be saved by folding the sine table to N/8, but it costs a little more time.
The other is a table of inverted addresses.
The FFT deals with complex numbers, so both a real and an imaginary
array is needed. There are thrE!e conventional representations of the
frequency domain: exponential, cosine-sin, and power-phase. The FFT
algorithm normally produces the exponential form, but is fairly straight forward to
convert to the other forms. The cosine-sine form is particularly useful
when processing real signals. Because there is no imaginary part, two indepen-
dent real signals can be transformed at one time, one in the real array, and
one in the imaginary array. For N=8,
o 1 2 3 4 5 6 7 sample
~ 3 2 1 d 1 2 3 frequency
. c
sm cos
It should be noted that the FFT and the Inverse FFT are identical except that
the FFT is scaled by N, and the Inverse FFT has the complex conjugate taken.

Extension of the FFT To Two Dimensions:

Now that the ability to do a one dinmnsional Fast Fourier Transform has
been developed, the next step is to apply it to a two dimensional transform, •

The discrete Two-dimensional Fourier transform is':

A(u, v) =
N-"1
?
x=O
.- N-1
2:.
y=O
f(x, y) exp (j 2 pi (xu+yv) IN)

where u=O, 1 v=O, 1, N-1

This can be treated as n one dimensional FFTs in the x direction,
and m one-dimensional FFTs in the y direction. The two-dimnesional
FFT, then, reduces to doing 2 N, or 2 n m Npoint FFTs. There are several
advantages to this, and one proble m. The problem is that if the image is
large, say, a matrix of greater than 128 x 128 sample s, then it is not possible
to keep it in core. It must be stored as N records of N samples each, if the
picture is square, on a disk or tape. This means that it is very difficult to
rotate the matrix 90 0 in order to FFT in both directions.

The solution that the author uses is to invert the matrix accross the
diagonal. This is the same thing as rotating it 90 degrees and taking the mirror
image. The image may be broken up into smaller squares, each of the squares

648
inverted, and the squares themselves inverted. Virtually any size picture may
be rotated using this method. Pictures up to 2048 x 2048 have been transformed
in this way. The reason it works is that the FFT is sensitive only to frequency,
and does not care which direction the signal is going in.
The two-dimensional FFT therefor consists of 2 N FFTs and a 90 0
rotation.

Figure 3. Mona Lisa, Raw data, Time and Frequency Domains.

Figure 4. Low pass filtered

649
 Figure 5. High pass filtered

Figure 6. Contrast Enhancement.

Summary:
This paper has presented an interactive graphics
system especially designed to enable a user to explore
the properties of the frequency domain Via a CRT display.
Several suggestions were made as to what constitutes an
adequate graphics system, and wbat sort of features are

~o
desirable in a system regardless of the application.
Photographs are presented as examples of one posible
application, image enhancement by computer. Other applicatio-
ns of this system can be readily found in the university and
research environments. The teaching of signal theory to
engineering students should become a reality when the cost
of CRT displays and computer time is further reduced.

Acknowledgements
Thanks is given to Control Data for their policy
of allowing employees free use of their computers during
off hours. I would like to express my graditude to
H. Philip Peterson formerly of Control Data for the many
stimulating discussions which inspired this project, and
for his help in reviewing this paper.

Bi blioi-sraphy

Cooley, J. \Ii. and Tilkey, J. Vi., " An algorithm for the

machine calculation of comp.lex Fourier Series", Math.
Comput. Vol~ 19 pp. 297 - 301. April 1965
Ansley, David A., "Photo enhancment by Spatial Filtering".
Electro-Optical Systems Design pp 26-34 July, 1969
Andre'YTs, H.C. and Pratt, W.K. "Digital Computer Simulation
of Coherent Optical Processing Operations", Computer Group
News pp 12-19 November. 1968
Gold, B. and Rader, C.1>'1:. ttDigi tal Processing of Signals".
McGraw-Hill 1969
Brigham, E. O. and Morrow, R. E. "The Fast Fourier
Transform". pp 63-70, IEEE Spectrum, December 1967.

651
 PART 8

Text Processing with

On-Line Visual Display
 A DEMONSTRATION OF
MAGAZINE PAGE LAYOUT USING A
GRAPHIC DISPLAY TERMINAL

P. Steuber

Sun Printers, Whippendell Road, Watford, WD17QH,

Herts., England.

This paper describes an application of interactive

graphic display terminals to magazine composition. The
techniques discussed are being used in a demonstration system
designed to evaluate a proposed computer typesetting system.
The proposed system uses on-line terminals to prepare, edit,
arrange and filmset text for magazine pages. The demonstration
system utilises off-line text preparation, editing on an IBM
2250 graphic display and filmsetting on a Harris-Intertype
Fototronic-CRT. Only the editing on the graphic display is
discussed in detail. The display is used to draw diagrams
showing the text layout on the page. The paper describes in
detail the drawing techniques, data storage and the algorithm
to justify type into areas drawn on the graphic display.

655
1 Background
1.1 Problem

The system described by this paper was designed to help

the printer compose magazine pages. It is important to
realise the difference between the printer's and publisher's
responsibilities. The publisher chooses the text content and
layout. Typographic style is the responsibility of both the
printer and publisher. The discretion allowed the printer
with respect to style varies from editor to editor, but the
final say always rests with the editor.
Magazine work poses many problems. The main ones are:
a. The many small text items.
b. The requirement that text fits into specific
space.
c. The complex spacial arrangement of text and
pictures.
d. The variety of typefaces and sizes.
e. The large numGer of author's alterations.
f. Short schedules and deadlines.
Text items range from the few words of a picture caption
to thousands of words for a feature article. Single pages
may contain from one to more than fifty separate items of text.
The items are often laid out on the page in a complex pattern.
Each text item is allocated an area of specific size and shape.
A major source of author's alterations is the need to
adjust the text to fit in available space and to adjust the
relative amount of space allocated to each text item. The
publisher frequently supplies as much as fifty percent more
~ than will fit in the space provided. When the error is
small the printer can usually make acceptable adjustments,
but otherwise, it is up to the publisher to make the altera-
tions. It is not uncommon for half of the text to be altered
or for an illustration to be moved so as to require the re-
setting of half the text of a page. !

The input is presented to the printer in the form of

type-written or hand written copy and sketches of the pages
showing areas for text and pictures. Sometimes the sketches
arrive with the copy and sometimes after galley proofs have
been sent to the editor. The publisher is shown proofs as
some of the following stages of production; galleys, made up
pages, revised pages, individual advertisements, and adverti-
sements in final page position.'

656
 The chief means of interaction between publisher and
printer is through proofs. Each proof gives the publisher an
opportunity to make alterations. The proofs are returned to
the printers in almost random order. Because of the short
schedules and critical deadlines, final alterations are often
given by telephone less than an hour before composition must
be completed.

1 Printing and some computing jargon is defined in the

glossary. These terms are underlined where they first
appear.

1.2 The Proposed System

The aim of the system is to handle efficiently the
difficult areas of magazine composition identified in section
1.1. The system consists of several on-line interactive
terminals providing the functions of text input, unjustified
text editing, layout drawing, page modification and photo-
composition and a set of major operations described below.
Data reception receives all copy and layouts from the
publisher. Each page layout is assigned an identification
code (ID) related to the publication, publication date, and
page number. Text items are assigned ID's related to the page
they will appear on or, if the page is unknown, related to the
publication, publication date and article title or advertiser.
The ID's are typed in on a text entry terminal. When copy
and layout arrive together the text ID's are written on both
the copy and layout.
The keyboard department types eacb text item on a
text entry terminal. The terminal is a teleprinter equipped
with a 96 symbol print element. Each text item is preceded
by its ID. The terminal refuses an item if its ID has not
been previously entered by data reception or if the item has
already been entered. All control codes within the text are
checked for validity during input. Errors result in suitable
messages to the operator. Once an item is typed in, the
operator may request a galley proof.
Unjustified text is edited with an alphanumeric CRT
display. The item to be edited is requested by typing its ID.
Although this terminal may be used at any stage, final text
editing is normally done of the graphic terminal.
Layout drawing is done on a graphic terminal capable of
displaying a twelve by fourteen inch page. A page is selected

657
by typing its ID on the alphanumeric keyboard associated with
the display. The skeleton page is drawn automatically using
information stored in the system. The skeleton page consists
of a rectangle showing the outside edges of the page. Using
the light pen, the operator divides the page into areas.
Text is assigned to an area by typing the ID of the text in
the area. A text item can be assigned to an area as soon as
the ID of the text has been typed in by data reception.
Page modification is done on the graphic terminal. A
previously drawn layout is selected by typing its ID on the
alphanumeric keyboard. The selected layout may be modified
using the same techniques as is layout drawing. In addition,
any text which appears on the page and has been typed in may
be displayed in justified format. The text or the area shape
can be altered.
Page proofs can be requested at any time after the
layout is drawn. Proofs include all the available text
assigned to the page and the pictures. The text is justified
to fit the shape of the area to which it is assigned. Any
excess is shown at the bottom of the proof. Pictures are shown
by solid black areas equal in size and shape to the actual
pictures.
Two basic principles are implemented in this system:
interaction and separation of text and layout. The system
provides immediate feedback to the operator. Thus, errors
are reduced to a minimum. The attributes of the type are
divided into two categories. The text attributes comprise
the characters and control codes to select typeface number,
size number, and body size number. The layout attributes
comprise the positional attributes and the specific typeface
names and sizes associated with the numbers used in the
control codes. The text entry terminal is used to input the
text attributes. The graphic terminal can be used for both
sets of attributes.

2 Demonstration System
2.1 Introduction
Before the system is implemented it is necessary to
prove that it will work and to measure its performance. For
this purpose a demonstration system was designed using
equipment borrowed from the manufacturers or hired from
bureaus. The following equipment was used.
Olivetti Te 338 teleprinter used off-line to
punch paper tape.

658
 Cossor Cosprite paper tape CRT text editor
used off-line to edit unjustified paper tape.
IBM 1130 with 32K store, 3 disks, and 2250
Model 4 graphic display used for layout drawing
and justified text editing.
Harris-Intertype Fototronic-CRT filmsetter used
to set the pages drawn and edited on the 2250.
Available space prohibits a complete description of
the demonstration system. The rest of the paper is devoted
to the graphic terminal. Sections 2.2 and 2.3 describe the
layout and justified text editing from the operators point of
view. Section 2.4 discusses the data structure and the
algorithms to justify text into the areas drawn on the
display.

2.2 Layout Drawing

The graphic terminal comprises a CRT, light-pen,
function keyboard, and an alphanumeric keyboard. The usable
area of the CRT is twelve inches square. Associated with the
light pen is a tracking cross which follows the light pen
around the screen. The function keyboard has thirty-two
buttons each containing an indicator light. A button is
effective only when its indicator light is on. The
alphanumeric keyboard can be used to input upper and lower
case letters, numbers and special symbols.
One of three frames appears on the screen. It is the
page selection frame, the new page questionnaire, or the
layout frame. The page selection frame lists all the pages
currently defined and the words 'new page'. If 'new page'
is selected with the light pen the new page questionniare
is displayed. If one of the defined pages is selected, the
layout frame for the selected page is displayed.
The new page questionnaire has spaces for the page ID,
page depth, page width, and the number of areas on the page.
The information is typed on the alphanumeric keyboard. When
the questionnaire is completed the information is checked for
validity. Invalid information is indicated by the word
'illegal' displayed to the right of the invalid data. The
invalid data must be corrected. When the data is valid, the
layout frame for the new page is displayed.
The layout frame shows the layout, the ID of the page,
and a list of drawing options. The minimum layout possible is
a line drawn around the edge of the page. Figure 1 shows the

659
 OPTIONS
DRAW AREA
MOVE AREA
MOVE AREA AND CONTENTS
ADJUST VERTEX
ROTATE AREA AND CONTENTS
SCALE AREA
REDRAW PART OF AREA
CALL UP AREA
DELETE AREA
CALL UP TEXT
DELETE TEXT
DRAW RULE
END PAGE
SELECT TEXT MOVE
SCALE PAGE
DISPLAY DIMENSIONS

FIGURE 1 - Skeleton Page

660
minimum layout and option list. The layout comprises areas,
dimensions, and contents ID's. The areas are indicated by a
line drawn around the edge of each area. The lengths of the
lines making up the border may be displayed. When an area
contains text, the ID of the text is shown in the area. Some-
times the dimensions or contents ID's fall in awkward positions.
The operator has the option of moving or deleting individual
dimensions and contents ID's.
The drawing options are listed in Figure 1. Each
option is selected with the light pen. Options are terminated
by function button zero and thirty-one. Button zero cancels
the option and can be pushed any time after the option is
selected. A cancelled option has no effect on the stored
data. Button thirty-one accepts the option. The accept
button is not turned on until the last step of the option is
completed. Pushing it before it is turned on has no effect.
Once an option is selected, the option list disappears.
Many options involve selecting an item with the light
pen. Because the light pen has a low resolution, the item
selected is always marked in some way. The operator may then
alter his selection if necesaary.
When an option is accepted, the new or altered area is
added to the page. If tne area is partly off the page, either
the area is deleted or the move area option is selected
automatically. The individual options are described in the
paragraphs below.
Draw area is the basic option. An area is drawn by
moving the tracking cross around the border of the area with
the light pen. A line is drawn as the tracking cross moves.
The line is erased if the pen is moved backwards along the
line. Regardless of the setting of the dimension switch, the
lengths of all straight lines in the area being drawn are shown.
The motion of the tracking cross is constrained to eliminate
the effects of a shaky hand. One of three constraints is
selected by function buttons labelled 'fix start', 'slant'
and 'curve'. 'l'he constraint can be changed at any time.
'Fix start' constrans the line to vertical and horizontal.
If it is the first constraint, it also fixes the start of the
first line. Under this constraint, the line will remain
vertical or horizontal until the light pen is moved more than
a distance of MIN2 from the line. When the distance exceeds
MIN2, the direction of the line changes. When the light pen
is moved backwards over the line, the line becomes shorter
until its length is less than MINI. At that point the line is
deleted and the previous line and constraint are continued.
MINI and MIN2 are program constants representing about .25 and
.50 inches on the screen respectively. If all the lines are

661
deleted, the tracking cross follows the pen without drawing.
Selection of a constraint will fix the beginning of a new
line.
'Slant' causes the line to rubberband between the
position of the tracking cross when the constraint is
selected and the light pen. When the length of the line
excieeds MIN2 a switch is turned on. If the length subse quently
becomes less~than MINI, the line is deleted and the previous
line and constraint are continued. 'Slant' may be pushed
again to select a new fixed end of the line.
'Curve' selects a variation of the slant constraint.
Whenever the length of the line exceeds MIN2, a new fixed
point is automatically selected and the switch is turned on.
Backward drawing is detected when the distance from the
tracking cross to the previous fixed point is less than MIN2
qnd the previous line is curved. If the length is less than
MINI and the previous line is not curved and the switch is
turned on, the curve is deleted and the previous line and
constraint are continued.
Drawing is ended automatically when the distance from
the last line drawn to the starting point is less than MINI.
The tracking cross is automatically moved to the starting
point. The final lines of the border are adjusted to meet
three conditions: The last line ends at the starting point,
all constraints are satisfied, and no line is shorter than
MINI. The last condition is satisfied by deleting any short
lines. When the adjustments have been completed, button
thirty-one is turned on.
In subsequent descriptions the term 'origin of an
area' refers to the point where drawing started.
Move area makes all areas detectable. When an area
is selected with the light pen, the tracking cross is displayed
at the origin of the area. The cross and selected area will
follow the light pen. Cancelling the optlon returns the area
to its original position. Acceptance fixes the area in its
new position. When this option is entered automatically, the
area selection step is bypassed. The area causing the
automatic entry is preselected.
Move area and contents is the same as move area except
that all areas enclosed by the selected area are moved too.
Adjust vertex allows the shape of an area to be
changed without redrawing the whole area. A vertex is select-
ed with the light pen. The tracking cross marks the selected
vertex. The vertex will follow the light pen subject to the

662
following conditions: movement will not start until the pen
is moved a distance of MIN2, the constraints of the lines
involved are satisfied, and no line becomes shorter than MINI.
The first condition allows the operator to select a new vertex
before he moves the first one. The second condition can result
In up to four lines being altered.
Rotate area allows the operator to rotate an area
about its origin without changing its shape or size. The area
is selected with the light pen and marked with the tracking
cross at its origin. Rotation is controlled with a 'joystic~'
displayed on the right side of the screen. The joystick is a
vertical line labelled 'clockwise' at the top, 'anti-clockwise'
at the bottom, and '0' in the middle. Plac~ng the light pen on
the joystick causes the selected area to rotate continuously.
The rate and direction of rotation depend on the position of
the light pen. The farther the pen is from the '0', the
faster the rotation.
Rotate area and contents 1S analogous to the move
area and contents.
Scale area proportionally changes the lengths of all
the segments in the border of an area. When the option is
selected, all dimensions are displayed. A dimension is
selected with the light pen. A cursor marks the left digit
of the selected dimension. The dimension is changed by
typing a new value on the alphanumeric keyboard. The area is
immediately redrawn to the size indicated.
Redraw part of area allows the operator to redraw an
area without disturbing the contents of the areas. A vertex
of an area is selected with the light pen. This vertex
becomes the new origin for the area. The line before the
origin is deleted and the tracking cross appears at the end
of the line. Which line is deleted depends on the order in
which the lines were originally drawn. The area is redrawn
using the techniques described in 'draw area'.
Call up area inserts a previously drawn page on the
current page. The message 'type ID of area' is displayed on
the right side of the screen. The ID of the desired area is
typed on the alphanumeric keyboard. The ID is displayed as
it is typed. When the end of ID is indicated, the area
selected appears on the page and the move area option is
automatically selected. If the area selected is a special
character, the current page, or nonexistent, the word
'illegal' is displayed under the ID. When an area is called
on, it is called a subroutine. Only the 'move area' and
'delete area' options are allowed to afeect subroutines.

663
 · Delet~ area re~oves an area from the page. The area
1S selected w1th the 11ght pen and disappeard as soon as it is
selected. If a subroutine is deleted, it disappears from the
page, but remains defined.
Call up text assigns a text item to an area. The
text item is selected by typing the ID of the text on the
alphanumeric keyboard. If the identification is valid, the
message 'select area' appears. The border of the selected
area is brightened.
Delete text disassociates text from an area. The text
is not deleted from the text file.
Draw rule allows the operator to draw a rule of any
weight. The drawing technique is the one described under
'draw area.' An extra function button is lit to enable the
operator ~o end the ru~e ~ithout drawing a closed loop. When
t~e rule 1S acc~pted, 1t 1S converted to an area equal in
w1dth to the we1ght of the rule. Once the rule is successfully
converted to an area, it is indistinguishable from an ordinary
area. The contents of the area is set to 'picture' to make
the rule black.
End page stores the current page and displays the
layout selection frame.
Scale page displays the scale menu and joystick shown
in figure 2. A box is drawn around the current scale. The
new scale is selected with the light pen. The joystick is used
to select the portion of the page to be viewed. Moving the
tracking cross away from the center causes the page to move in
the direction indicated. The page moves continuously at a rate
proportional to the distance from the light pen to the center.
The numbers MINI and MIN2 are adjusted so that the smallest
line has the same length on the screen.

2.3 Justified Text Editing

A very simple form of text editing has been implemented
in the demonstration system. Text is displayed one area at a
time. Within an area two typefaces and two sizes of each are
allowed. The typefaces are referred to as Face I and Face 2.
and the sizes as Size I and Size 2. Face 2 is distinguished
from Face I by underlining. The 2250 character generator
provides basic and large characters. Size I is represented
by basic charaters and Size 2 by large characters.
All the text of the displayed area is put into the
display file. The screen size limits the number of visible

664
characters to 52 lines of 74 basic characters or 35 lines of
49 large characters. The hardware is such that a line of
characters will wrap around the screen and reappear on the left
when its length is twice the visible number of characters.
The same applies to the number of lines. Therefore, so long
as half the text will fit on the screen in each direction, the
hardware will provide the necessary windowing. Although this
method of showing text is wasteful of display file space, it is
very eesy to program and very fa$t to execute compared to
computing the visible text. The part of the text that is
visible is selected by moving the first character of text.
All the rest are defined relative to the first character.
The text is doubly justified. The number of characters
in each line is calculated from the true typographic measure
and character sizes. The length of the display line is a
fixed multiple of'the typographic measure. The multiple is
chosen to guarantee that all the characters will fit in the
display line. The size of the interword spaces in the display
line is calculated from the display character width of 14
raster units for basic characters and 21 raster units for
large characters. Therefore, although the displayed lines have
the same content as the typeset lines, the word spacing on the
screen does not give an accurate indication of the typeset
word spacing.
Two frames are used in text mode. The text display
frame described above and the text selection frame. The
selection frame lists all the ID's of the text items stored
in the system. Pointing to an ID with the light pen displays
the associated text display frame and activates the editing
options. The options are all selected by function buttons.
Each option is described below.
Move text selects that part of the text is to be
visible. The tracking cross appears in the middle of the
screen. When the cross is moved with the light pen, the
text moves with it.
Insert after allows the operator to add text after a
selected character. The character is selected with the light
pen. A short vertical line marks the point of the insertion.
A space is created below the selected line to display the
insertion. Up to two lines may be typed. The backspace key
can be used for correcting errors in the insertion. The jump
key spaces forward from the point of the correction to the end
of the insertion. When the insertion is accepted, the text
is rejustified and displayed in its normal form.
Insert before is analogous to insert after. The
insertion precedes the selected character.

665
 ISAfffi
SIZE I DOUBLE
SIZE
TREBLE
SIZE
QUADRUPLE
SIZE

UP

LEFT RIGHT

DOWN

FIGURE 2

,,- Delete draws a horizontal line through each character

selected with the light pen. When accept is pushed, all
marked characters are deleted and the text is rejustified.
Replace is a combination of delete and insert. Char-
acters are first marked for deletion. Then the insertion is
typed. The insertion replaces the last character marked. When
the first character is typed, the light pen is disabled and a
space is created to display the insertion. When accept is
pushed, the marked characters are deleted, the typed characters
are inserted and the text is rejustified.
Change font alters the typeface and sizes of selected
characters. The characters are selected in the way described

666
for delete. Four buttons labelled Face 1, Face 2, Size 1,
and Size 2 select the font. When accept is pushed, the font
of the marked characters is changed and the text is rejustified.
Move hyphen corrects hyphenation errors. The hyphena-
tion algorithm breaks a word after the last character that will
fit on the line. Consequently, corrections are often necessary.
The correct hyphenation point is indicated by pointing to the
character that is to follow the hyphen. The position is
marked with a short vertical line. Up to twenty hyphenations
can be corrected at once. When accept is pushed the hyphens
are moved and the text is rejustified. The rejustification
can cause more wrong hyphenations if the characters moved
cause the hyphenation of the following line to change.
End area stores the edited text on disk and displays
the text selection frame.
Select next area stores the edited text on disk and
displays the continuation of the item. If there is no
continuation the text selection frame is displayed. Continua-
tion is possible when one text item is assigned to two or more
areas or when an overflow area is created. An overflow area is
created to hold text that will not fit in the area which it has
been assigned.
Enter drawing mode stores the edited text on disk and
displays the layout selection frame.

2.4 Data Structure

The page layout is composed of areas. Figure 3 shows
a simple page layout with six areas as it appears on the.
display. An area is defined by its border. The border lS an
ordered set of two dimensional vectors. The vector sum of the
set is zero. When the vectors are connected head to tail. they
form a closed loop around the area they define. The drawlng
technique is derived from this definition.
For example, area B was drawn starting at ~he 'B~.
The light pen was moved across the top, down the rlght slde,
across the bottom and back to B. If figure 3 were actual
size , the vectors in the border of B would be:
1110,0
0,-4380
-1110,0
0,4380
The units are decipoints. The coordinates of point B

667
 PAGE IDENTIFICATION CODE
_\
...,
M T
.L ( \PAGE 1
OPl'IONS
DRAW AREA
MOVE AREA
MOVE AREA AND CONTENTS
I ADJUST VERTEX
E
ROIJ.'ATE AREA AND CONTENTS
SCALE AREA
P Crt ~
REDRAW PART OF AREA.
GALL UP AREA
I.."
I.L' DELETE AREA
CJ !PTl pN
CALL UP TEXT
DELETE TEXT
DRAW RULE
END PAGE
TEXT-l TEXT-2
SELECT TEXT MOVE
SCALE PAGE
DISPLAY DIMENSIONS

-
.
CONTENTS ID
BORDER OF AREA B
I BORDER OF PAGE
EDGE OF 2250 SCREEN

FIGURE 3 - A Simple Page Layout

668
are not stored as part of the border. Therefore, the border
would be the same for area C.

The space contained within an area is calculated from

the border. The plane of the page is ruled into squares one
decipoint on a side. The squares inside the border constitute
the space within the area. Horizontally adjacent squares are
grouped into strips. The list of squares within an area is
called the strip description of the area.
A three part algorithm converts a border into strips.
Part one generates a new border containing only vertical and
horizontal vectors. The length of each vector is an integral
multiple of a basic unit. The basic unit may be any integral
multiple of one decipoint. Generally the smaller the basic unit
the better the approximation of the original border and the
longer the execution time. Thirty decipoints is normally used
for areas containing text and one decipoint for areas containing
pictures or rules. Figure 4 shows a triangular border converted
to vertical and horizontal vectors using a basic unit of 360
decipoints.
The algorithm treats each vector separately except
that the vertical or horizontal vectors must be connected head
to tail and add up to zero. The original vectors are divided
into five classes: vertical, horizontal, high slope (greater
than one), low slope (less than or equal to one), and indeter-
minate. A vector with an Y component less than two basic units
is horizontal. One with a X component less than two basic units
is vertical. If both components are less than two basic units,
the vector is indeterminant. The remaining vectors are classi-
fied by their slope. Vertical and horizontal vectors are made
ex~ctly vertical or horizontal with a length which is an
integral number of basic units. Sloping vectors are converted
to steps. High slope vectors generate horizontal vectors of
one basic unit and variable vertical vectors. Low slope
vectors generate one unit vertical vector's and variable
horizontal vectors.

Part two discards the horizontal vectors and converts

the vertical vectors to line segments. Figure 4 shows the
line segments generated for the triangle. Each segment is
defined by two Y coordinates and one x coordinate. The first
Y coordinate is always larger than the second one. The
segments are sorted into descending order of the first Y
coordinate and ascending order of the X coordinate.
Part three converts the sorted segments into strips
in seven steps.
1. The first segment is put into a work area.

669
2. All segments with a first Y coordinate equal to
the first Y coordinate of the segments in work
are added to work. The new segments are added
so that the segments in the work area are arranged
in ascending order of the X coordinate.
3. Starting with the lowest X, adjacent segments
are paired.
4. A strip with a depth of one basic unit is output
for each pair. The left and right ends of the
strip are the X coordinates of the two segments
in the pair. Strictly speaking, a group of
decipoint strips is output.
5. The first Y coordinate of each segment in work
is reduced by one basic unit.

PART 1
ORIGINAL
BORDER
2880,.----. 0, 2880
1440,-2160
-1440,- 720
CONVERTED
HIGH SLOPE BORDER
2160
°
0, 2880
ORIGINAL 360,
/ BORDER
°
0,- 720
360,
°
0,- 720
1440 360,
0,- 360
360, °
__ GENERATED
BORDER
0,- 360
- 360, °
720
0,- 360
- 360, °
0,- 360
- 720, °
LOW SLOPE BASIC UNIT = 360

° I
° 720 1440

670
 PART 2 PART 3

UNSORTED SEGMENTS GENERATED STRIPS

Yl Y2 X START 2880
2880 0 0 720 THIES 0, 360
2880 2160 360 720 TIMES 0, 720
2160 1440 720 360 TIMES 0,1080
1440 1080 1080 360 TUlliS 0,1440
1080 720 1440 360 TIMES 0,1080
720 360 1080 360 THIES 0, 720
360 0 720
SORTED SEGMENTS
ARE IN THE SAME
ORDER AS UNSORTED
SEGMENTS.

FIGURE 4 - Border to Strip Algorithm

6. All segments whose first and second coordinates

are equal are removed from work.
7. If more segments are available, the process is
repeated from step 2. If no more segments are
available, but there are segments left in work,
the process is repeated from step- 3. Otherwise,
the conversion is complete.
Figure 4 shows the strips generated for the triangle.
Each area must contain either a picture, text, or
blank space. Although two areas are allowed to overlap
the contents of the areas must not overlap. Therefore, a
procedure is required to assign each square of space on the
page to exactly one area. In the first step of this procedure
the areas are arranged into a hierachy based on the way they
overlap. Overlap is calculated by comparing strip descrip-
tions. If all the space within B is also within A, then A
encloses B.
An area header associated with each area includes three
hierarchy pointers, a pointer to the border, a pointer to the
strip description and a vector. Figure 5 shows the hierarchy
pointers and the vectors of the areas in figure 3. Area D
will be used as an example. The first point of D points to A,

671
an area enclosing D. The vector of area D gives the coordi-
nates of the origin of D relative to the origin of A. The
second pointer points to B, another area enclosed by A. The
third points to E, an area enclosed by D.

A
3
0,5160

D B c
2
720,-1740 300,-300 1700,-300

F E
2
120,-1080 120,-120

FIGURE 5 - Hierarchy Pointers and

Vectors of the Areas in
Figure 3.

Each area that enclosed another area is linked by its

third pointer to a list of all the areas it enclosed that are
not enclosed by any other area inside it. Area D begins the
list linked to A. D, B, and C are on the list, but E and F
are not. E and F are on the list linked to D. The order on
the list is determined by what each area encloses. The order
is'areas enclosing areas, blank, pictures, then text. All
the areas in the list are linked to the enclosing area by
their first pointer. They are linked to each other by their
 t
1IIIIIIInllllllii
D

B F
A c
FIGURE 6 - Space Received by Areas on Page 1

§
 A

PAGE 1

B C

3 3

F E

TEXT TEXT TEXT

CONTENTS CONTENTS CONTENTS
HEADER HEADER HEADER

IC ION

TEXT ITEM TEXT ITEM

L------i HEADER HEADER
CAPTION TEXT

FIGURE 7 - Major Text and Area Pointers

674
second pointers. The page has only the third pointer and its
vector is relative to the lower left corner of the display
screen.
The hierarchy is built up by adding areas to the page
one at a time. The new area is successively compared with
each area on the list linked to the page. Any area enclosed
by the new area is removed from the list and added to the list
linked to the new area. After the ne-w area is compared with
each area on the list, it is added to the list. However, if
the new area is enclosed by an area on the list, no further
areas on that list are compared. Instead, the areas on the
list linked to the enclosing area are compared. If the
enclosing area is not yet linked to a list, a list is started
with the new area.
With the hierarchy established it is possible to assign
each square of space to a unique area. This space is called
usable space and is described by a strip description. For
the purposffi of explanation, usable space is considered to be
tangible squares capable of being passed from one area to
another. Initially the page is assigned all the squares.
During each step of the algorithm, squares are passed from one
area to an area it encloses. The first pointer of the
receiving area points to the sending area. The squares trans-
ferred are those still held by the sending area that are within
the receiving area.
The first receiving area is pointed to by the page.
After each step the next receiving area is pointed to by the
third pointer of the current receiving area. If the third
pointer does not point to an area, the second pointer is used.
If that does not point to an area, the second pointer of the
sending area is used. If the sending area is the page, the
proCess lS complete. The order of receiving areas in figure
5 is D, F, E, Band C. Figure 6 shows the space assigned to
each area. .
The usable space assigned to each area is occupied by
the contents of the area. The second and third hierarchy
pointers are used to point to the contents of the area. If
the area does not enclose any areas, the third pointer is
used. Otherwise, the second pointer of the last area in the
list linked to the area is used. Blank and picture areas are
indicated by a flag in the appropriate pointer. No further
description of the contents is required.
When an area contains text, the pointer points to a
'text contents header'. The text contents header points to
the first and last lines of text in the area and contains
the typefaces and sizes corresponding to Face 1, Face 2,

675
Size 1 and Size 2. Figure 7 shows the text contents header
and the pointers associated with the text in figure 3.
The text itself is stored without line endings in a
long string. Within the text are control codes to select
the typeface and size numbers and to end paragraphs. The
actual faces and sizes selected by the codes depend on the
area controlling the justification.
A 'text item header' points to the first'and last
characters of the item ~d contains the ID of the item.
When the text is assigned to an area, a justification
array is set up to point to the first and last characters of
each line. This array also stores the space size, hyphen
indicator, and coordinates of each line.
The algorithm which generates the justification array
uses the usable space strip description to determine the
coordinates and length of each line. Suppose text is to be
justified into the triangle in figure 4. Assume that each
line requires a depth of 200 decipoints and that the strips
shown in figure 4 describe usable space.
Strips are removed from the area in groups of 200
starting at the top. The ends of the strips are evened up
to make a rectangle. A group of strips is removed for each
line until the area is full or the text is used up. The
groups obtained from the triangle are shown in table 1. The
coordinates are in decipoints relative to the origin of the
area.

Baseline left end right end

2680 0 360
2480 0 360
2280 0 360
2080 0 360
1880 0 720
1680 0 720
1480 0 720
1280 0 1080
1080 0 1440
880 0 1080
680 0 1080
480 0 720
280 0 720
80 0 720
TABLE 1. Coordinates of lines justified into the triangle in
figure 4.

676
 This data structure supports the layout and text options
described in sections Band C. A set of output programs
converts the data to commands for the Harris-Intertype Foto-
tronic-CRT. From these commands the Fototronic sets a
complete page of type.

3 Conclusion

Tne demonstration simulates a new typesetting system

that uses on-line terminals for text and layout entry. The
demonstration system will be used to practice CRT page make
up techniques. By using these techniques to set real
magazine pages it should be possible to write comprehensive
specifications of the new typesetting system.
The demonstration is designed to give four main
outputs.
1. a clear description which printers can
understand of an on-line terminal system
for typesetting.
2. an estimate of the time required for a
compositor to make up a magazine page on
a graphic display.
3. a set of layout handling techniques that is
efficient for both the compositor and the
computer
4. an understanding of the graphics software
required to implement the full system.

The first output will be achieved by producing a

film which shows the steps in the production of film pages
from manuscript. The film will be supplemented by live
demonstrations of page make up on the graphic display.
The time required to set a page will be measured for
several compositors and several different kinds of pages.
Although there are many pitfalls in time trials such as these
the results will certainly be more reliable than mere guesses.
The layout and text options described in sections 2.2
and 2.3 are the initial techniques. At the time of writing
the demonstration programs had not yet reached the stage of
live trials. It is expected though, that during the trials
these techniques will be improved. After the trials it should

677
be possible to say fairly definitely what the final system
should include.
It is a long step from a one display system to a
multiple display system with a high load. However, the data
structure described in section 2.4 will support multiple
displays as well as text entry terminals. The algorithms
described for justifying text into areas drawn on the display
will not be changed by the addition of several terminals.
What will change is the operating environment. Insvead of a
single central processor executing a single program, the full
system will require a multiprocessing and multiprogramming
environment. In this environment the efficiency of access to
the data structure is of prime importance. It is this area
that requires the most development. The data structure in the
demonstration was coded for simplicity rather than efficient
access.

4 Glossary
Alphanumeric CRT terminal
A CRT and keyboard combination capable of displaying
alphanumeric symbols, but not vectors. Usually the
screen is divided into a small number of fixed
characters positions. A cursor controlled by buttons
on the keyboard is used to point to characters
displayed on the screen.
Control codes
Characters in text strings that provide format
information.
When the text is set, these codes are not visible.
control codes are used to select typefaces, size etc.

Copy
The input to the printer containing the text. The
term is often used synonymously with text.

Decipoint
One tenth of a point or approximately 1/720 inches.

Galley proof
A proof of justified type before the type has been
made up into pages.

678
Graphic terminal
A CRT, keyboard, and light pen combination capable
of displaying alphanumeric symbols and vectors. A
light pen or equivalent device for indicating items
on the screen is essential.
Justified
Text arranged into lines based on the widths of the
characters. The right margin is not necessarily
straight. Even when the right margin is ragged, the
number of characters in the line is limited by the
character widths.
Layout
The arrangement of text and pictures on a page. Layout
also refers to the diagram provided by the customer
and the drawn on the display which specify the
arrangement of text and pictures.
Light pen
Part of a graphic display used to point to items
displayed on the screen. The name is derived from the
appearance of the light pen and the fact that it
detects light from the CRT. The signal from the light
pen enables the program to determine what the operator
is pointing at.

Measure
The length of a line of type.
On-line interactive terminal
A device connected to a central processor and
controlled by an active program l~ing in the
processor. The device is capable of accepting data
from the operator and indicating to the op~rat?r what
the program has done with th~ data. ,Graphlc dlsplays,
teleprinters, and alphanumerlc CRT dlsplays can all be
used as on-line interactive terminals.

Photocomposition
Typesetting using photo-sensitive paper or film
instead of type metal. In this paper, the devices
mentioned to set type on film are controlled by
computer generated magnetic tape.

679
Proofs
DOyuments sent to publishers and authors alleged to
represent the type set by the printer. In a photo-
composition systmm proofs are usually chemical or
electrostatic copies of film or paper type. Some
computer typesetting systems actually use line printe:
output as proofs.
Raster units
The basic unit of distance on a CRT screen. Normally
the screen is divided into 1024 raster units verti-
cally and horizontally.
Unjustified
The opposite of justified. Two types of unjustified
text are common. One is text without line endings
as is produced by a non-justifying keyboard. The
second is lines of arbitrary length obtained by
counting characters without regard to their widths.

680
GRAPHIC EDITING OF STRUCTURED TEXT·

w. 1. Hansen
Applied Mathematics Division, Argonne National
Laboratory, 9700 South Cass Avenue, Argonne, Illinois
60439, U.S.A.

Abstract

Emily, the system described in this paper, is an interactive

syntax-controlled system for creation and manipulation of
program texts. This system uses the syntax of the programming
language to impose a tree structure on programs in the language.
A program begins as a single non-terminal symbol. For each
non-terminal Emily presents all the syntax rules that define
replacements for that non-terminal. In general, the replace-
ment string consists of characters and non-terminals. By
selecting appropriate rules, the user builds the program he
desires. Because the editor retains the tree structure of the
text, the text can be manipulated in terms of its structural
units. Emily can represent any structural element by a single
identifier, so that the user can view his text at any level of
complexity. As a hybrid of string and tree representations,
this display technique provides a new way of looking at and
thinking about programs.

Several planned extensions to Emily are discussed. These include

an interactive cross-reference facility, dynamic syntax-controlled
display formatting, and the ability to name pieces of text, dis-
play statuses, and syntaxes. An important goal of the Emily pro-
ject is measurement of the behavior of users using the system.
Such measurement can help describe interactive computer use, as
well as assist in optimizing the design of Emily for the user's
convenience.

Interactive computer systems promise to be effective tools because

they can provide even the least organized human with a patient and meticu-
lous scribe. Sitting at a console, a user ought to be able to examine

*Work performed under the auspices of the U.S. Atomic Energy Commission.

681
a body of information from alternate viewpoints and to modify that informa-
tion as required. With Sketchpad (Sutherland, 1963) graphic images can
be rotated, replicated, replaced, revised, and reflected upon by merely
pushing buttons and pointing a light pen. Emily is an attempt to extend
such facilities to program texts. It should be possible to manipulate
and modify text almost as easily as willing the action. The user should
not even need a paper copy of the file. Not only might a copy be lengthy
and out-of-date, but there is an orientation problem when referring back
and forth between paper and display. Facilities must be available within
the editing system for displaying quickly any portion of the file the user
wishes to see.

Emily is an interactive syntax-controlled system for creating and

modifying program texts using an IBM 2250 Graphic Display Unit. Unlike
other text editors, the text is not stored and manipulated as a linear
string of characters. Instead, operations are performed in terms of the
tree structure imposed on the program by the syntax of the programming
language. In particular, a program is created by selecting qppropriate
syntactic rules from those rules that apply at any particular point of
the program. Since all punctuation is contained in these rules, the pro-
grammer need not be concerned ~·th the details of punctuation. Moreover,
when an identifier is required, Emily displays existing identifiers. The
programmer can enter a new identifier or simply point at an old one; thus
he does not have to worry about spelling.

The growth of interactive systems has spawned many text editors, but
few that do much more than maintain a file in a manner analogous to shuf-
fling cards. Editors designed for use with slow output devices such as
teletypewriters are limited because they cannot present very much informa-
tion in the time the user is willing to spend waiting. This means that
they can only display a small portion of the contex~ of a statement. Most
early slow-device systems were designed around line numbered files. Perhaps
the most advanced such editor is the Wylbur system at Stanford University
(Stanford, 1968). More sophisticated slow-device editors eliminate line
numbers and permit editing by context. An advanced example of such an
editor is the QED editor written K. Thompson (Thompson, 1968). One of the
features of this editor is that the object of a string search may be spec-
ified to have arbitrarily complex structure.

Graphic interaction opens many possibilities for text editors. Large

blocks of text can be displayed so that the context of any statement can
be made clear. One of the simplest and yet most effective editors is TVEDIT
by B. L. Tolliver (described in McCarthy, 1967). Each command is a single
character (a special button is held down to indicate command mode); thus
the user can conceive operations he wants on the screen and have them occur
almost without conscious physical effort. Two graphic editors provide com-
plex predefined structures within which the user can organize his text.
The Hypertext system by Nelson and van Dam (Carmody, 1968) permits the user
to both annotate his text and provide links to other portions of the text.
The text appears to the user as a network of interconnected blocks. The
Stanford Research Institute's Center for the Augmentation of Human Intellect
has developed an editor that allows the text to be organized into sections,
sub-sections and sub- ... sub-sections (Enge1bart, 1968). The edited text
thus has a hierarchical appearance and the editor indents the display of
each subsidiary level.

Several text editors have been built that check syntax. All have
one or more of these disadvantages: 1) only local 1ine-by-1ine syntax is
checked; 2) the editor handles only one language; 3) a typing error means
listening to an error message and then, often, retyping the whole line;
4) the syntax checker occupies a large segment of core without doing much
more than one run of the compiler would do. Many of these problems have
been solved in a JOVIAL editor at Systems Development Corporation (Bratman,
1968). The display control in this system is table driven so any of sev-
eral inexpensive text display devices can be used. An editor that guaran-
tees syntactically correct statements is the DIALOG system (Cameron, 1967).
In this primitive one-language graphic editor, the user is constrained to
create correct programs because at any stage only a character that is legal
can be selected as the next character of the text. As in Emily, the user
of DIALOG builds his text by choosing options, although in DIALOG his
choice is limited to an alphanumeric character set.

There are two reasons for implementing Emily instead of using one of
these other editors. The first is to illustrate the advantages of a text
editor that 'understands' the structure of what it is ,editing. Such an
editor can, for example, ensure correct syntax while the program is being
entered. Emily was originally designed as a string editor with a general
purpose parser. But design of such a parser for incomplete text appeared
to be a difficult problem in itself, whereas we were interested in building
a usable tool in a reasonable time. Consequently, the current approach was
decided upon as a method of letting the user create the structure at the
same time as he creates his program. Because she understands the structure
of the text, Emily can display that structure either by formatting the text,
drawing diagrams, or representing substructures with a single identifier.
She can permit modification and reorganization by structural units. And
she can facilitate file access either down the hierarchy, or via an inter-
active cross-reference feature.

The second reason for implementing Emily is to investigate the tech-

nique of creating programs by repeated choice from a set of alternatives.
The process of writing programs as a sequential string of characters is so
ingrained that it is difficult to even conceive of any other technique.
A working system must be built and must be tried by people before it will
be possible to evaluate Emily's approach. Other human engineering questions
that must be answered include: Assuming Emily is useful, for what kind of
programmer is she best suited--neophyte, expert, language designer? What
training period is required in order to use Emily? What features contribute.
to user dissatisfaction? Which are most used? How should syntaxes be
designed for Emily? How efficient is Emily compared to traditional paper-
penci1-keypunch-shuff1e techniques~- Here efficiency is defined in terms
of cost, time, and usage of scarce resources.
 The initial version of Emily reported here is implemented in pL/I for
an IBM 2250 Graphic Display Unit attached to an IBM 360/75. The 2250 dis-
plays characters and vectors on a 12" x 12" screen. A light pen can be
used to point at an image on the screen and there is a program function
keyboard with thirty-two buttons, each of which generates a unique
interrupt. Characters can be typed in, under program control, from an
alphanumeric keyboard; the latter generates an interrupt only when the
END key is dep~essed. Two syntaxes have been hand coded for Emily's syntax
tables: a subset of PL/I, and a language for input to a syntax table gen-
erator. Future syntaxes will be designed using Emily and implemented by
processing them with this table generator.

The remainder of this paper has three parts. The first describes the
capabilities of the present Emily system, while the second outlines the
features that are planned for addition to Emily. The final section discusses
the human engineering problems and how we plan to approach them.

I. The Current Emily System

For any given language, only some strings of characters constitute pro-
grams. This set of legal strings can usually be defined by a syntax. The
characters that can appear in a program are called the terminal symbols.
For the purpose of defining the legal strings, the syntax also introduces
a set of non-terminal symbols that do not appear in a legal program.
Finally, the syntax includes a set of syntactic rules, each of which spec-
ifies a string (of terminals or non-terminals) that can replace a particular
non-terminal. A syntactic rule has a left-hand-side specifying a non-
terminal and a right-hand-side specifying a replacement string.

As an example, Fig. 1 shows a possible syntax for part of the pL/I

declaration structure. Notice that non-terminal symbols are surrounded by
'<' and '>'. Usually the name inside these brackets has some relation to
the semantic meaning of the string generated by the symbol. The simplest
declare statement that can be generated by this syntax is 'DECLARE A FIXED
BINARY;'. More complex would be 'DECLARE A FIXED BINARY, B FL0AT BINARY
STATIC INTERNAL;'. The steps in the generation of the latter string are
shown in Fig. 2.

In addition to defining a set of legal strings, a syntax imposes a

tree structure on any such string. The tree for the string in Fig. 2 is
shown in Fig. 3. Each syntactic rule used in the generation of the string
is represented as a node (a rectangle) in the tree, with one pointer to
a subnode for each non-terminal in the node. Emily uses this tree represen-
tation to store the file. Rather than place an entire nule in each node,
a code number in the node indicates which rule generated that node. Notice
that terminal symbols do not appear explicitly in this representation;
they are implicit in the code number for the rule.
To an Emily user, the 2250 screen appears divided into three parts:
the text, the menu, and the message area. The text occupies the upper

684
Terminals: DECLARE, ';', ',', FIXED BINARY, FLOAT BINARY, STATIC,
AUTOMATIC, INTERNAL, EXTERNAL

Non-Terminals: <DECL>, <IDDECL*> , <IDDECL>, <ATR> , <STORCL>,

<SCOPE>, <ID>

Rules:
<DECL> : := DECLARE <IDDECL*>;
<IDDECL*> · .= <IDDECL> , <IDDECL*>
· .= <IDDECL>
<IDDECL> · .= <ID> <ATR>
: := <ID> <ATR> <STORCL> <SCOPE>
<ATR> : := FIXED BINARY
: := FLOAT BINARY
<STORCL> : := STATIC
• •= AUTOMATIC
<SCOPE> : := INTERNAL
: := EXTERNAL j

Fig. 1. Sample Syntax for <DECL>

Omission of the left-hand-side indicates that it is the
same as in the preceding rule. <ID> is a special non-
terminal that is replaced with any identifier name.

two-thirds of the screen and shows a portion of the file being edited.
lower third of the screen is the menu and displays up to twenty options.
The message area is the bottom line of the screen and is used to request
operands and to display status and error messages.

Because the file may not be a complete program, the text area may
include non-terminal symbols.* These are underlined to make them stand
out. One of the non-terminals is designated the current non-terminal and
is shown surrounded by a rectangle. The menu normally displays all strings
that can be substituted for the current non-terminal. These strings are
simply the right-hand-sides of the syntax rules that have the current non-
terminal on the left.

The most usual mode of operation is build mode, signified by BUILD

MODE in the message area. This mode is used for constructing and viewing
the text. Pointing the light pen at an item in the menu substitutes that
item for the current non-terminal. Pointing at a non-terminal moves the
rectangle to that non-terminal so that it becomes the current non-terminal.
(The menu changes accordingly.) When the current non-terminal is an identi-
fier, the menu displays all previously entered identifiers in the required
class (some of the classes for pLII are <ID>, <LABEL>, and <ENTRYNM».

*When it is displayed, a non-terminal is the end (or terminal) of a branch

of the tree. It is called a non-terminal because it must be replaced with
a string of terminals before the program is complete.

685
The user may select one of these, or he may enter a new identifier from
the keyboard. Constants and comments are also entered from the keyboard.

DECLARE I<IDDECL*> I ;
DECLARE I<IDDECL>I, <IDDECL*>;
DECLARE ~ I <ATR>I , <IDDECL*>;
DECLARE ~ FIXED BINARY, <IDDECL*>;
DECLARE A FIXED BINARY, I<IDDECL*> I ;
DECLARE A FIXED BINARY,
~ <ATR> <STORCL> <SCOPE>;
DECLARE A FIXED BINARY,
B <ATR> I<STORCL>I <SCOPE>;
DECLARE A FIXED BINARY,
B \ <ATR> J STAT,IC <SCOPE>;
DECLARE A FIXED BINARY,
B FLOAT BINARY STATIC \ <sCOPE>1 ;
DECLARE A FIXED BINARY,
B FLOAT BINARY STATIC INTERNAL;

Fig. 2. Steps in the Generation of

DECLAR~ A FIXED BINARY, B FLOAT BINARY STATIC INTERNAL;
In each step the non-terminal in the rectangle is
replaced to generate the next step. The order is
not strictly left-to-right, but it could have been.

To facilitate creation and modification of programs, Emily recognizes

lists in the syntactic description of a language. A non-terminal represent-
ing a list has a name whose last character is '*'; for instance, <STMT*>
represents a list of <STMT>'s. If the current non-terminal is a list,
Emily displays all options for an element of that list and also two special
options. If the user selects one of the options for the element, that
option is inserted in both the file and the display. The non-terminal
for the list is displayed immediately after the inserted option, so the
user can continue the list. Thus, if the current non-terminal is <STMT*>
and the user selects the option <SIMPLE STMT>, the display would appear
as <SIMPLE STMT><STMT*>. The new current non-terminal is the first non-
terminal of the option chosen, in this case, <SIMPLE STMT>.

The first of the two special options is EMPTY. Selecting this option
for <STMT*> ends the list and removes <STMT*> from the display. If the

686
syntax requires that the list have at least one element, EMPTY is not dis-
played as an option until the list has at least one element. The second
special option is the list element itself, e.g., <STMT>. If this option
is chosen <STMT>is inserted in the display before <STMT*>, but the current
non-terminal remains <STMT*>. With this option, the user can create the
list <STMT><STMT><STMT> ... before he fills in the details of any individual
<STMT>.

<DECL> - DECLARE <IDDECL*>;

<IDDECL*> .. -

<IDDECL> ::= <ID>

<IDDECL*>

<ATR> ::= FIXED BINARY I

1
[<IDDECL> ::= <ID> <ATR> <STORCL> <SCOPE>]

I<ATR> "=
cb
FLOAT BINARY I

I<STORCL> ::= STATIC]

,
I<SCOPE> ::= INTERNAL I

Fig. 3. Tree Structure Imposed by Syntax on the string of Fig. 2.

The flexibility of Emily's display of the file is greatly enhanced by

abbreviating parts of the display with holophrasts. Each node in the
tree generates some consecutive string in the display representation of
the file. The holophrast for this string is simply the non-terminal symbol
on the left-hand-side of the syntax rule that generated the string. Holo-
phrasts are not underlined; thus they can be distinguished from non-
terminal symbols in the display. For example, the eighth line in Fig.
2 might be displayed with one holophrast as 'DECLARE <IDDECL>, BI<ATR>]
STATIC <SCOPE>;'. We emphasize that the introduction of a holophrast does
not in any way modify the file, it merely modifies the display.

Holophrasts are introduced into th~'display by switching to CONTRACT

MODE and pointing at a character in the display. That character is gen-
erated by some node of the tree. The display of the entire string generated

687
by that node is replaced by a holophrast. For example, the comma in Fig. 3
is generated by the node corresponding to ~IDDECL*> ::= <IDDECL>, <IDDECL*>.
Pointing to that comma would reduce the declaration to 'DECLARE <IDDECL*>;',
where <IDDECL*> is a holophrast representing 'A FIXED BINARY, B FL0AT BINARY
STATIC INTERNAL'. Pointing at a holophrast in the contract mode causes the
father of the indicated node to be represented by a holophrast. This new
holophrast subsumes the earlier one. Pointing at a holophrast in build
mode causes the node to be expanded with each of its immediate subnodes
represented by holophrasts. By judicious use of contraction, the user
can view his program from higher levels. He can see it as a sequence of
statements or a sequence of procedures. On a much lower level, contract
makes it possible to find the principle operation of an involved arithmetic
expression, or to count the number of arguments of a subroutine.

In addition to switching between the two modes described above, the

program function keyboard buttons activate special functions. Most function
buttons require operands in the form of light pen points or entries from
the keyboard. If the user changes his mind and wishes to perform some
other function or mode, he can press another button instead of responding
with the required operand. Emily is very forgiving; she is designed so
that most actions can easily be undone. The following provide rudimentary,
but complete, facilities for displaying and modifying a file.

GO DOWN - Instead of displaying the entire program from the beginning,

Emily can display any node of the tree and only its subnodes. The display
node is selected by pointing the light pen at a terminal symbol generated
by the node.

GO UP - The display can be moved up to any node that is a direct ances-

tor of the current display node. After pushing the GO UP button, the user
must type in the number of levels of tree he wishes to ascend.
DELETE - A holophrast can be converted to a non-terminal by pressing
DELETE and pointing at the holophrast with the light pen. Similarly, iden-
tifiers can be converted into non-terminals. The user is protected from
deleting too much because he must contract the node he wishes to delete
before he can delete it.

USE DUMP - The subtree deleted by DELETE is saved in a dump. When

USE DUMP is pressed and the current non-terminal has the same name as the
non-terminal that generated the node in the dump, the dump replaces the
current non-terminal. The dump contains only the last deleted subnode
and is empty after a successful USE DUMP.

INSERT ELEMENT - Elements can be inserted in--and deleted from--lists.

After pressing this button the user light pens the character immediately
before the location at which the element is to be inserted. If more than
one list element ends at the indicated character, Emily asks the user to
resolve the ambiguity by indicating (from the menu) the name of the non-
terminal that generates the wanted list.
 DELETE ELEMENT - An element can be deleted from a list if it is a
non-terminal, a holophrast, or an identifier. (Any other element can be
contracted to a holophrast). The user presses this button and points at
the unwanted element. The deleted element replaces the contents of the
dump and can be recalled with USE DUMP.

TERMINATE - This button saves the file on the disk and terminates
Emily's execution.

Originally, we considered Emily to be an editor for the tree structure

of a program. Indeed, the file is physically stored as a tree structure
of nodes interconnected by pointers to subnodes. But we chose to display
the file in terms of the string generated by the tree; thus Emily evolved
into hybrid of tree and string editing. This hybrid appears to be a very
flexible vehicle for viewing files. Strings are no longer of static length
Rather, they expand and contract as subtrees are converted between holo-
phrasts and strings.

Achieving even the modest system described here required substantial

development of data structures and interactive facilities. An Emily file
is list structured; each node of the tree is represented on the disk as
a block of words that contains the syntax rule number and pointers to the
subnodes (one for each non-terminal on the right-hand-side of the rule).
Each such a pointer occupies one word and can be one of the following:

DISKNODE - pointer to another node on the disk. This pointer includes

a record number and an offset to the node.

IDNODE - offset to an identifier in the identifier area. The latter

is kept in core during execution.

NTNODE - contains the non-terminal number for a non-terminal that has

not been replaced.

The subfields of the pointer word are accessed in PL/r by overlaying a

based variable on the word. The part of the file displayed is represented
in core by a set of nodes similar to those on the disk; the nodes in core
contain additional information such as a pointer to the corresponding node
on the disk and a pointer to the father of the node (in core). Since these
nodes are maintained in core, the file has to be accessed only for changes
to the display.

The heart of the interactive program structure is an attention control

block containing the attention type, a pointer to an indicated node, and
the number of a subnode of that node. The light pen location is decoded
by table lookup in an array of x-coordinates starting at the first entry
for the line identified by the y-coordinate. The node and subnode number
in the attention control block are set from parallel arrays and indicate
the location of the light pen selection in the data structure. The atten-
tion type is set to indicate the source of the attention. Light pen

~9
 attentions decode into one of seven types depending on how the detected
character was generated. Each button decodes into a separate attention
type. In addition, there is the attention type NOATTN. When a routine
processes an attention, it sets attention type to NOATTN. If the attention
interpreter finds that the attention type is not NOATTN, it simply returns
the existing attention. Thus if a routine does not wish to handle a given
interrupt, it simply executes any operations required to terminate its
own work and returns to the calling routine. The calling routine (usually
the central dispatcher) can simply ask for another attention that has not
'yet been handled.

II. Future Plans for Emily

Many changes must be made to Emily before she achieves her potential
as a dynamic and flexible tool for the creation of programs. These changes
fell into three categories: 1) what the user sees, 2) how he can change
what he sees, and 3) how he can change the file.

The display is formated by Emily. The file contains no format control

characters such as end-of-line or space. Instead, the display is based
on the structure of the text. Certain syntax rules include codes for how
much to indent (or outdent) subsequent lines and codes for starting new
lines. Thus one rule for the DO statement is

<STMT> ::= 'DO;' +6 NL <STMT*> +0 NL 'END;'

where NL is the code for a new line and +n indicates that the left margin
for subsequent lines will be indented n spaces from the current left margin.
Thus a DO statement would look like

DO;
<STMT*>
END;

This scheme has several deficiencies. First of all, the entire DO statement
might fit on a single line and would look awkward spread over several lines.
Moreover, it is difficult to put static format codes into arithmetic syntax
rules, because the same rule must apply to both long and short expressions.
A third problem is that natural groupings like /*<COMMENT>*/ and ( A )
may be broken onto two lines because the output routines put tokens on
the next line when the first line is full. The current formatter might
be called a static formatter since it depends entirely on the syntax and
does not take 'into account the actual text. A dynamic display formatter
bases its decisions on both the structure of the text and the space remain-
ing in the output area. A dynamic display formatter for LISP has been
written (Hansen, 1969), and it may be possible to generalize the techniques
developed in that effort.

The user may also be interested in seeing a graphic representation

of the structure of the text. One form of such a display is shown

690
in Fig. 3; the boxes represent nodes and the lines their interconnections.
However, we are considering an alternative in which the entire string gen-
erated by some node is surrounded by a large box which is sub-divided to
indicate the strings generated by the immediate subnodes of the node. Com-
mands would then be available to move the big box from node to node.

'What the user can do' is vitally influenced by what he can refer
to. That is, in order to operate on an object, he must have some means
of naming it or pointing at it. For this reason, Emily will include a
comprehensive name facility. A name is simply an identifier and an asso-
ciated class. The following will all be nameable with different classes
of names:
files
syntaxes
pieces of text
display statuses.

Names will be manipulated by the same subroutines as used for identifiers.

When a name in a given class is required as an operand, Emily will display
all existing names in that class. The user may either select one of these,
or enter a new name from the keyboard. For example, the button to create
a structure in another syntax will display the names of all syntaxes.

The present program must be expanded to give the user greater control
over what he sees on the screen. The GO UP and GO DOWN buttons are fairly
primitive techniques for controlling which portion of the text is displayed.
At the least, GO UP must be modified so that instead of asking how many
levels to ascend, it displays the non-terminal names of all predecessors
of the current node and asks to which of these it should ascend. The level
of the display is controlled by converting between strings and holophrasts.
It may be possible to contract a string to a holophrast simply by pointing
to the two ends of the string. Reversing the process, a hit on a holophrast
in BUILD mode should expand it as much as possible without going off the
display. This can be done in a breadth first manner, so the structure of
the program is displayed before accessing the details.

The above facilities enable the user to modify his view of the file,
but they do not allow him to randomly access completely different parts
of the file. He must ascend to a higher level node and then descend along
some other path. The name facility will permit the user to name a display
status and to return to a given display at any time. Perhaps an even more
important mechanism for accessing the text will be the interactive cross-
reference facility. For any identifier, the user will be able to look
at its declaration, or to look at each of its appearances, one at a time.
This facility is simulated in a normal string editor by the string search
capability. The user types in any string and asks the system to find all
instances of the string. While this feature is more general than that
proposed here, it does not distinguish between declarations, instances,
comments and accidental juxtapositions of characters. Nor can string search
ever hope to distinguish between identifiers with the same name, but

691
declared in different blocks. This will be possible with Emily because
she understands the structure of the text. The interactive cross-reference
facility and named display statuses will provide rapid and flexible access
to random parts of the text.

When he has found a portion of the file he wishes to modify, the user
must have equally flexible commands to modify the file. The present dele-
tion technique will be extended to allow a deleted structure to be placed
in a named cell. Each cell will contain a subtree, the name of the non-
terminal that generated the subtree, and the name of the syntax. Provision
will be made for retrieving named cells from other files. Also, it will
be possible for a file to include subtrees from named cells created in
a syntax other than the syntax for the file. Thus, for example, a user
might wish to include a lengthy comment having a syntax of his own design.
As this implies, the user will be able to create syntaxes and then use
them to create text. This facility will also be valuable when we are
designing syntaxes for others to use.

We have also considered a nearly opposite approach to file creation.

In this approach, the user would have at hand a fragment of text and the
menu would display all syntax rules of which that fragment could be a part.
For example, an expression would have the alternatives of being a sub-
expression, a subscript, an argument, or the right side of an assignment
statement. Such a build-from-the-bottom approach can be implemented in
Emily without undue difficulty. A further extension would be the ability
to specify that any named subtree is to replace the current non-terminal.
In this case, Emily might have to search through the syntax rules to find
the smallest chain of rules such that the subtree can be generated by the
current non-terminal.

The ultimate extension of Emily will be to provide a text processing

language so the user can write small programs to modify his file. Such
a language should not be difficult to implement, because the data is already
structured. The language has only to provide names for the operators that
manipulate Emily's internal structure. Thus, there would be a syntax for
the text processing language, and the user would create named structures
or named files containing statements in this language. Such a language
might be similar to COGENT (Reynolds, 1965), a language which processes
tree structures by using generalized analytic and synthetic assignment
statements.

With the features described above, a user should be able to view his
information from many perspectives and to modify as little or as much as
he desires. Most of these features are illustrations of the first reason
for implementing Emily. That is, they are possible because Emily 'under-
stands' the structure of the information being edited. This understanding
makes it possible to emphasize the structure as the text is displayed,
to move around in the structure at will, and to modify the structure in
terms of its components.

692
III. Measuring Emily's Value

The second reason for implementing Emily is to determine the value

of the proposed techniques for editing programs. Most of the questions
posed in the introduction are concerned with qualitative rather than quan-
titative judgements. Nevertheless, they are important questions and some
attempt must be made to answer them.

In order to answer such human engineering questions, Emily will gather

comprehensive statistics. The primary source of this information will
be the actions of the user; every button-push, light-pen hit, and keyboard
entry will be recorded in a special system file. This file and the initial
state of the text file will be sufficient to reconstruct the entire editing
session. A mode will be possible in which Emily reads this interaction file
and continuously modifies the display while the user (or debugger) watches.
This will be valuable for debugging and also when the user must recover
a state that existed in the middle of the session.

From this file of interactions, we expect to learn many valuable facts

concerning the utility of Emily's features. The frequency of use of the
different functions will aid in optimizing the most used parts of the pro-
gram. The ratio of file modification to file examination should yield
basic facts about what programmers do when they program. For compar:son,
the author has kept some statistics on his own activities with pencil-paper-
keypunch during the creation of this initial version of Emily. Since the
author will probably be the most extensive user of Emily, these statistics
may provide interesting comparisons. In addition to recording all inter-
actions, we intend to provide an outlet for the learner to voice his frus-
trations with Emily. There will be a file into which he can type messages.
Also, an 'I am confused' button will elict a sympathetic message from Emily
as dictated by a random number generator. This will serve as a toy and
will thus distinguish those seriously using Emily from those merely playing.
Perhaps, we will find that a certain amount of play is necessary while
learning to use a system.

An important question we hope to answer is "What is the training period

necessary to learn to 'think Emily'?" That is, how long need a programmer
work with Emily before he is sufficiently familiar that

a) he selects syntax rules from the menu without paying too much
attention to the text area;

b) he presses buttons without looking, and without translating from

a desired action to the name of a button to perform that action.

A programmer who has attained this proficiency with Emily can be said to
be using it more as a tool than as a toy. There does not seem to be any
good signal that a programmer has reached this level, but we hope to be
able to measure proficiency in terms of reaction time and the number of
mistakes and backups. Especially, we intend to look for plateaus in the

693
learning curve, since the end of a plateau signals a transition in the way
a user perceives his activities.

FI8~: P~OC PO FIllED .IIII"~'t' , . USE RECURSIVE APPROAC'" a'

IF III $ ' ... EIII RE1URIII ($),
EI..SE
!F '" I ''''EIII ~E1U~III (I):
EI..SE RE1URIII P:!I)R(~) • <lE~I'1»'
E",:) <E"lRv"I'1>:

<EIIP> \ <1..0GTERI'1> <I..DG1E~I'1> ~ <I..DGFAC>

<1..0GF"C><REI..OP><"EXP> <"EXP> • <lERI'1>
<AEXP> - <TERI'1> <lERI'1>a<F"C>
<lE~I'1>I<FAC>
<PRI>-_<FAC>
+<FAC> -<FAC>
~<FAC> <AIO>
<PTR>-><AIO> <COIIIS1>
«EXP» <Elll1RvIII",>«ARG-»

~UII..O·I'1DOE

Example 1. One step in the creation of a recursive routine for computing

Fibonacci numbers. The current non-terminal is <EXP> and Emily is
presenting sixteen possible choices. The last choice--<ENTRYNM>
«ARG*»--will be selected. (These photos are about half life-size.)

694
 To some extent, the slope of learning curves is a measure of the
'naturalness' of Emily. Clearly, this does not mean that Emily is like

F [8~: P~OC ( ~ I ~ [)(E 0 81~A~Y' IJ USE ~ECU~SlvE API>"OAC .... - I

I ~ ~ e 1 .... E~ ~E1u~~ I eI ,
ELSE
[ ~ ~ I 1 .... E~ ~E1U"~ I I ) ,

6'1:> c
E,-SE
:3",
"E1U~~ (~ !'3"I1\j - I )
• ~[8~1~ - 2 ) , ,

Example 2. Completed recursive routine for Fibonacci numbers. Note that

<ENTRYNM> was chosen to be FIBR and <ARG*> became the expression N-l.

~180"Atel': P~oc nn "1)(,"0 8["A~Y. /- FI~O ~'l .... ~I80~ACCI I'lUM8E" -/

OECLA~E <[OOECL->.
o E C L A ~ '" < I 00 E C L_. ~ ,
OECLA~E '[OO,"CL->i

C[8~EC: P~OC (~) PO["1E~' /_ MAttE L[ST OF F[80~ACCI ~UM8ERS -/

OECL'''E I FI8PL)(-8ASEO (FP)
2 F~O , [ .. EO 8[~A"Y. 2 ~E"l~ 1>01l'lT":
OECLA"E TP PO[~TE":
ALLOCATE c [ 8 P L .. SET I ~ I> I , ,
[~ ~"''' • T .. E.. 00 ., .. E II, T c ,. ~ UL L :
F~O ,. ••
£ .. 0.
ELSi: 00.11' .. ,. I 1 .. ,~ OO.~E"T~ ~18"ECI~ - II,
F~O .. I.
, .. 0.
'LSE 00 ... '11,1" .. F[8"EC(" - I).
1P ,. "')(11'.
" .. 0 ,. 1P->F,,0.
1P .. 110->"'11,11'.
",,0," " .. 0 • TI>'->F"O,
' .. 0.
' .. D.
~'lU"" (FPI.
, .. 0 FI8~'C.

<SlI1T->
e."D "180"ACCI,

Example 3. FIBREC is a recursive subroutine to create a linked list of

Fibonacci numbers. It is a subprocedure to the routine FIBONACCI.
The latter has three DECLARE statements with holophrasts for their
bodies. There are also a number of statements represented with the
holophrast <STMT*>.

any particular natural thing that the user has ever done. What naturalness
means in Emily (and, in fact, in any interactive system) is that there
should be a very few rules prescribing the behavior of either the program

695
or the user. There must be a single point of view from which all the
actions of the program appear natural. If the program is not designed
with consistent behavior requirements, the user will take that much longer

FI80~&CCI: P~OC'(~) FIII£O II"'&"Y, , - FI ... O ... ·T>1 FI80"'&CC( IIIUl1aEIt-'

OEC~&~£ ... '111£0 II"'l~Y,
O£C~&~£ ' ... FIII£O II"'&~Y. 11 '111£0 8(lIIlltV.. T2 F(>tEO a(IIIAlty:
O£CL&It£ I FIII£O 81 ... &lty,

Ft8"£C: PltOC o n POIIIIT£", ,- 11&1(£ LIST OF F(SOIliACC! !IIU>1a£"s _,.

<STI1T-,
E~O Fla"EC:

! ;, ~ ,
F", ~ ,
1 1 e,
12 1 ,

LOOP: I' ( " ... l>1EIII ItETUltlll (Fill'·

ELSE
F", 11.12,
1 1 1 2 ,
1 2 , III,
60 TO LOOP,
101110 F ISO-UCC ( :

Example 4. This example shows exactly the same file as example 3. But
all holophrasts in the outer procedure have been expanded to display
the string they generate, and the body of the inner procedure is
represented by the holophrast <STMT*>. The outer procedure computes
fibonacci (n) iteratively. A fourth declaration has been inserted,
because the outer procedure is going to be modified to check the two
procedures against each other.

to figure out what is going on. (But, if he persists, he can learn any
system. And once learned, that system will seem more natural than another,
even though the other might require far less work. This accounts for much
of the inertial persistance of non-optimal systems and languages.)

An important factor that contributes to Emily's 'naturalness' is the

design of the syntax. A given language can usually be described by many
different syntaxes. Simply a change in the order of the rules may help
the user to find the rule he wants. More complex reorganization can change
the shape of the tree without changing the string generated. For example,
if the rules below replaced the rules for <IDDECL> in Fig. 1, the syntax
would still generate the same strings.

<IDDECL> .. = <IDBASE> BINARY

::= <IDBASE> BINARY <STORCL> <SCOPE>
<IDBASE> .. = <ID> FIXED
"= <ID> FLOAT

696
Emily is designed to permit change of the syntax in a simple manner. This
will permit experimentation to find out exactly what form of syntax is
best.

"'180"l"CCI: ""QC ("I) "'IIIEO 'I"I""Y' , - "1"10 ... · f ... "IIO ..... CCI "U"1I£~-'
OEC~""E ... "IIIEO . I ..... "Y'
OEC~""E " ... "IIIEO .PU"Y. TI "IIIEO II ..... "Y. T2 "lx£O II ..... "Y'
OEC~""E I "IIIEO . I ..... "Y,
O£C~""E I ""~II 8"SEO (" .. )
2 "'''10 "IIIEO II ..... "Y. 2 "'EIIT" "IIIEO ....... "Y,

"18"EC: ""OC ( ... ) POIIIIT£", ,- 1'1&<E ~IST 0" "IIOIII"CCI ... uHaER5 -,
<5THT->
E"IO "laREC,

0,
F... 0,
T 1 0,
T 2 1 ,

~ 00": I" ... T"'E ... 00,"" = "18"EC("'),

I'" " ... = ""->""'0 T"'E ... "ETU"'" ("III),
E ~ 5 £ , - 'I '" ... E "E. T ... ERE I 5 .. III E R" 0"
) ,
-, C .. ~ L. eE... T "Y ... H 3 « .. " G - >

E"'O,
E~5E

"'" TI.T2,
TIT 2 •
T2 ,,"'.
GO TO ~OO".
E ... O '" laOIll"CC I.

"laON"CC! "18"EC

Example 5. The modification is nearly complete. <ENTRYNM> is the current

non-terminal and Emily displays all previously entered ENTRYNM IS.
But the user wants to call ERR0R and has typed in the name of that
procedure.

697
 One area in which Emily should be able to excel over traditional pro-
gram creation techniques is in examination of an existing program. At
present, we do not even know how a programmer does interact with his list-
ings. The author has about twenty listings of Emily subprograms; this
pile must be shuffled in order to find the relevant subprogram to answer
a question. It would be much faster to ask for the subprogram by name
and read it instantly. With Emily's statistics gathering machinery, we
should be able to find out how often a programmer randomly accesses parts
of his program. Perhaps with this information, we can get some idea of
how much time is saved by using Emily.

There is, indeed, some question as whether Emily will benefit more
the neophyte programmer or the programmer who is well versed in the sophis-
ticated techniques Emily makes available. The former will be saved from
remembering all the technical details of syntax, which can be extensive
for a language like PL/I. But before he can use Emily, the neophyte must
have a sufficient grasp of the language to understand the semantics of
the syntactic alternatives. Moreover, because there are often more possi-
bilities than can be displayed at once, the user has to know how to get
to the desired option. Thus the neophyte must undergo a substantial train-
ing period simply to learn his way around the syntax, without worrying
about sophisticated techniques for finding parts of his program. The design
goal of Emily is a program that offers the most advantages to the practiced
advanced programmer. We will assume that the user understands the syntax
he is working with and has practiced the manual operations necessary to
use Emily effectively.

An unexpected possibility with Emily is its potential utility in the

design of new languages. A language designer is mostly concerned with
the semantics of his new language. But in order to write examples in the
language, it must have some form of syntax. Using Emily, the designer
can build a syntax in a straightforward manner. The syntax need not even
be unambiguous. Further, by modification of the syntax he can modify his
language and write programs in it immediately. Because Emily keeps track
of the syntax, he need not refer to it constantly while he is working.

Several changes have already been made in Emily based on limited exper-
imental use. One fact that we have learned is that the basic cycle of
selecting syntax rules and modifying the display must take place very rapid-
ly. Even times as long as three-tenths of a second are likely to provoke
frustration in the programmer. After all, he knows what he wants to do and
feels that he could be working more quickly with pencil and paper, even
though this might not be true, since Emily can create many characters per
interaction. The present program displays the next set of syntax rules
before modifying the display. The programmer can select a rule before the
display is completely rebuilt, and this saves some time. But the computer
is so fast that the display is built just about the time the programmer
decides what he wants. In this case, the text flicks on and then off again.
This is very distracting, so the programmer is more likely to wait for both
the rules and the text display. Since the contract mode proved to be con-
fusing, some human engineering has already gone into its definition. The

698
menu displays options for the current non-terminal and, if the user selects
one of these, Emily automatically switches to the build mode. Emily also
switches to the build mode after any deletion. This is because a frequent
(and annoying) sequence of operations was·: go to contract mode, contract
string to be deleted, delete string, then try to change current non-
terminal without having returned to build mode.

Emily looks to the day when every programmer has a console in his
office. We hope that our results will be of some benefit in the design
of the required systems.

Acknowledgements

I am grateful for the advice and encouragement of John C. Reynolds and

William F. Miller.

References

(Bratman, 1968) Bratman, Harvey, Hiram G. Martin, and Ellen C. Perstein.

Program composition and editing with an on-line display. AFIPS
Proc. V. 33 pt. 2 (FJCC) 1968, pp. 1349-1360.

(Carmody, 1968) Carmody, Steven, Theodor H. Nelson, David Rice, and

Andries Van Dam. A Hypertext Editing System for the /360. Brown
University, October, 1968 (unpublished).

(Cameron, 1967) Cameron, Scott H., Duncan Ewing, and Michael Liveright.
DIALOG: A conversational programming system with a graphical
orientation. Comm. ACM V. 10, 6 (June, 1967), pp. 349-357.

(Engelbart, 1968) Engelbart, Douglass C., and William K. English. A

research center for augmenting human intellect. AFIPS Proc. V. 33
pt. 1 (FJCC) 1968, pp. 395-410.

(Hansen, 1969) Hansen, Wilfred J. PRETTIERPRINT for LISP360. Argonne

National Laboratory, Applied Mathematics Division Technical Memoran-
dum No. 182, May, 1969 (unpublished).

(McCarthy, 1967) McCarthy, John, Dow Brian, Gary Feldman, and John Allen.
THOR - a display based time sharing system. AFIPS Conf. Proc. V. 30
(SJCC) 1967, p. 623-633.

(Reynolds, 1965) Reynolds, J. C. Cogent Programming Manual. Argonne

National Laboratory report no. ANL-7022. Argonne, Illinois, March,
1965.

(Stanford, 1968) Stanford University Computing Center. Wy1bur Reference

Manual (Appendix E of Campus Facility Users Manual). February, 1968

(Sutherland, 1963) Sutherland, I. E. Sketchpad: A man-machine graphical

699
 communication system. T-296, Lincoln Lab., M.l.T., Lexington,
Mass., 1963.

(Thompson, 1968) Thompson, K. QED Text Editor. Bell Telephone Laborator-

ies, Murray Hill, New Jersey, March, 1968 (unpublished).

700
 ON-LINE TEXT EDITING USING
VISUAL DISPLAY

v. M. Briabrin

Computer Centre of the Academy of Sciences of the

U.S.S.R., Vavilova 40, Moscow, U.S.S.R.

INTRODUCTION
The need tor high-efficiency man-computer interactive
system would hardly be disputed. A lot ot on-line conversa-
tional systems haTe been des1gned already, and stlll many
teams are engaged in developing of the similar projects.
Graphic 4ispl~ terminals give a good basis for the s1gnlf1-
cant progress in th1s field. On-line text process1ng With the
natural and rather simple language, easy to learn and to use,
ls a problem to be solved w1th the aid of Visual Display.
The system for on-line text editing, descr~bed 1n th1s
paper, is a part of a more general System for On-line Data
processing (SOD), whioh is under design in the Computing
Centre of the Academy of SOiences of the USSR.
The SOD configurat10n 1s represented ln Figure 1.
MONITOR 1s the lead1ng program, supervis1ng the operation of
several consoles and programming systems. PROCESSOR is the maln
SOD subsystem and 1 t contains three parts: IKPtn/OUTPU~ and
FILE CONTROL, EXECurOR, EDITOR. The f1rst one ls engaged in
input/output actiVity and flle management. The second part,
IXICUfOR, ls responsible for translation, program running,
keeping the results, etc. EDITOR ls the maln instrument tor
program amendment in terms ot the souroe language. EDI!OR
funotioning i8 the maln subjeot of the followlng dlscussion.
Six programmlng lansuages are aVailable for the user:
BlSM-6 Assembly LaDguage (AftOCODE), !I,GOL 60 [1 ] , CEBI
FOB!RAI [2] , LISP 1.5 (3J , SHOBOL-A [4] , DEBUG system lang-
uage[5]. The nuaber of consoles depends on their t1Pes.
Teletype T-63, typewriter CONSUL, and a spec1al deTtce equip-
p.d with CRT and a light peD are ava1lable. Up to 24 telet7Pea
or 12 typewriters, aDd 4 devices with Tis_al dlspl~ CaD
operate 8i.ultaaeously.

701
 MONITOR PROCESSOR I/O FILE
CONTROL

-i ASSEMBLER
1 ---I EXECUTOR

1 2 --- 2'" ----t .ALGOL - EDITOR

CONSOLES

- FORTRAN

-t LISP

--i SNOBOL

'---
DEBUG

FIGURE 1. System configuration

SYSTEM FUICTIOIIII
To lnteract wlth the slstea the user sends sa lnstructi-
on to the computer. The s,ste. baDdIes the instruction text,
performs the neoessarT aot10ns &ad glTes the user soae fora of
reply_
Two aodes of input fro. the user are possible: t1P1ng
Via keyboard and point1ng with a light pen. The first parmi.-
slbl. mode ls always typlng and the user oan proceed with it
as long as he wlshes. In order to chaDg. the mode, a 8peolal
1nstructlon should be sentt PII. At thls 80ment the light
buttons with the naaes of systea instruotlons appear on the
screen (Figure 2), and the user can choose the necesaarl
1nstructlon bl pOintlng at the appropriate button. The rest
of the scree., free of light buttons, 1s the worklns spaoe,
which 1s fllled ln by the approprlatetext or picture, genera-
t_d as the cODSequeuce of the instruction perforaanoe.
If the user wishes to return from the light pen to th'
t1'Plng aode of input, he should point at the IBYBOARD button.
In order to choose the particular programa1ng slste. the
user should point at the SYSTEM button. !he result is that a

702
 WORKING SPACE

• LINK • READ • TRAN • LIST

• EXIT • WRITE • DO • EDIT
• SYSTEM • SORT • TRANDO • LOAD
• KEYBOARD • PRINT • STEP • STRUCT

FIGURE 2. The view of the screen

row of light buttons with the names of the programming systems

appears 1n the screen. Touching the appropriate button corre-
spo.ds to choosing the system.
READ, WRITE, SORT and PRINT buttons correspond to system
instructions, dealing with input/output and file management
operations.
THAN is a system instruction, controlling the compiler,
interpreter, or assembler operation. DO starts running of the
object program and stops it when a r.quired breakpoint 1s
attained. TRANDO composes the actions, performed by TRAN and
DO instruotions. STEP is an instruction for step-by-step oom-
pilation and program run control. It is a special form of
exeoution now available only in LISP.
LIST, EDIT, LOAD and STRUCT are system instructions for
on-line text editing. The following sections are devoted to
detailed discussion of these instructions.
LIST INSTRUCTION
At the beginning of the work the user allocates the copy
of his source prcgram to the memory and starts its processing.
During the compilation or interpretation process it may be
discovered that some mistakes exist in the source text. From

703
 this point the user starts editing. First of all some portion
of the souroe text should be displa.re-d om the screen. This i3
initialised by the LIST instruction with the following syntax:
LIST /<segment list).
where
(segment list)::~ (segment> I (segment list) , <segment>
(segment) ::. <bleok name) I (line segment) (b1ook name) -
<line segment)
(line segment) ::= <line name> I (line name) : <line name>
(blook name) ::= B (integer)
{line name) ::= L (integer)
Examples
LIST / L15.
LIST / B8.
LIST / BS - L15 : L19, L23.
Line name denotes some portion of the souroe text termi-
nated by a particular oharacter-terminator. Block name denotes
a speoifio point in the souroe text, from which the terminator
aocount must be started. The integer part of the blook name 1s
the number of the left block delimiter searcned from the begin-
ning of the souroe text. Block delimiters are specified when
SYSTEM is an.ounced. For example, in the BESM-ALGOL system [1]
symbols ft -- BEG IN L..I ft and " END ..... " are considered as left and
right block delimiters. -
Onoe mentioned the block name is substituted for each
segment of the segment list. If no one segment contains the
blook name, the starting point of liDe terminator acoount
coinoiies- with the beginning of the source text.
When the user is working in the KEYBOARD mode he has to
type character-by-charaoter the whole text of the instruction.
When working with a light pen it is neoessary ~. point at the
light buttons in some order. For exampl~when the user starts
editing, he has, to point at the LIST button (Figure 2). The
view of the soreen changes; it contains now three rows of
light buttons (Figure 3). In the bottom row there are buttons
with the following names:
- ALGOL (current system name);
- LIST (current instruotion name);
- EXECUTE (the buttoJl. for terminatioB of the instruction),
- KEYBOARD (the button for chang1ng the mode of input).
The next row oontains four oontrol buttons, named BLOCK, LINE,
UPTO and NEXT. The th1rd row oontains oharacters of the perm1&
sible alphabet. In the case of the LIST instruction, these

704
 WORKING SPACE

ACCUMULATOR

o 1 2 3 4 56? 8 ~

• BLOCK • LINE • UPTO • NEXT

• ALGOL • LIST • EXECUTE • KEYBOARD

FIGURE 3. The view 01 the screen for the LIST

instruction.

characters are decimal digits. In order to give a LIST ins-

truction,corresponding to segment list:
B8 - L15 :t19, L23
the user should point at the light buttons in the following
sequence:
block 8 line 1 5 upto 1 9 next line 2 3
The text of the instruction being composed appears in the bot-
tom row of the working space, called the aocumulator. The
required list of lines will appear in the working spaoe when
the user points at the EXECUTE button.
To proceed with the list it is neoessary to oompose one
more LIST instruction starting with the NEXT button, tor
example:
~ line 2 4 upto 2 7
If the NEXT button wasn't touched, the system would generate a
new list of lines, corresponding to line segment L24 : L27.
In order to "ewitoh eff" the LIST 1nstruct1oll the user has to
point at the LIST button in the bottom row of the screen. The
view of the screen becomes similar to that shown in Figure 2,
with the exception that in the working space the listed text
is preserved. Pointing at the EDIT button the user begins the
editing process 1tself.

705
 EDIT INSTRUCTION
The syntax of the EDIT instruction is the following:
EDIT / (assignment sequence) •
where
(assignment sequence) ::= (assignment) I <assignment
sequence) • (assignment>
{assignment) ::a (left part> ~ (primary list>
(left part) ::= (variable) I <variable with a pattern) I
(line segment)
(variable) ::= (letter) I (block name) I (line name)
(variable with a pattera) ::= (variable) - (pattern>
(pattern) ::a (primary) I <primary> : (primary)
(primary list) ::= (primary) I (primary Itst> , (primary)
(primary> ::= (variable) I <string) I (integer> <variable) I
(integer> (string)
Examples
Variables: L15; B9; A ; B ; X.
Strings : 'ABS'·' - ' • , '-',
'END -', '. 'STRING '-'-' f ABC' '.
Primaries: L15; 2L15; 3X; 'ABC'; 9 '~'.
Variables with a pattern: L16 - 'FCT'; B8 - L9 : L12.
Assignments: L15 :: 'ABC' , X , J' L......I', Y ;
L19 -'REAL' ='INTEGER' ;
L20 = ' ';
B9 = 'LABEL :' , B9.
The semantios of the assignment in our system is the
same as in SNOBOL-A [4·1 • The value of the string in the left
part of the ass1gnment is replaced by primary list elements
values. Note that an integer preoeed1ng a string or variable
denotat1on is co.sidered as a repetitlen faotor: for example,
.3 ,~, - 1s equivalent to'~A-I""""'.
The view ef the soreeD for the EDIT instruction is show.
tn F1gure 4. Light oontrol buttons are named: REPLACE, BY,
STRING, VARIABLE. The permissible alphabet is wid.ened compared
t. that of the LIST iastructioa. DuriBg the composition of the
lDstructloB text the user teuches alternately at the different
po1ats ell the soreea, followiag the abeve syntax. To illustrau
the sequence of pointing we shall consider aa example where
80me oonventions should be taken int. account:

706
 15. _ BEG IN _REAL A, BJ:C; _INTEGER I;
16. _FOR 1:::1_STEP 1_UNTIL N-DO
17. _BEGIN A:::2; B:::1-X; C:::2tI+A/B;
18. _END ;
19. _BEGIN _REAL M,K;
20. M:::_IF X<2.5_THEN X_ELSE 5;
21. K:= ABS(X/2);

ABCDEFGH ••• 123'+5678 ••• +-()/ ,= •••

• REPLkCE • BY • STRING • VARIABLE

• ALGOL • EDIT • EXEC UTE • KEYBOARD

]'IGUHE 4. The view of the screen for the EDIT

instruotion.

_ light buttoll names are g1vell 1n small fount w1th underliniBgj

_ charaoters from the work1ng spaoe are indexed by the approp-
riate line numbers;
- letter L followed by a number 1. 1talics oorresponds to
pointing at the appropriate line number, and th1s oonstruc-
tiCR is equivalent to the line name.
Let us oonsider the assignment sequenoe:

-
X ::' END '-' ' •
L17 :: L17, ' ....... ', X.
L19 -'R' :'L' • 'INTEGER'.
L20:: "'.
The order of pOint1ng for th1s sequence 1s:
reElaoe X ~ string END~execute
replace ltf Ez variable L 17 string L...I variable X execute
I

reJ21aoe RI,) L19& str1ng INTEGER exeoute

replace L20.!?z str1ns exeoute.

707
 It may happen that the user needs some character which
is not present in the permissible alphabet, displayed on the
screen. In this case it is possible to change the input mode,
by pointing at the KEYBOARD button. This button may be pointed
after BY,STRING, VARIABLE and EXECUTE buttons, i.e. each
element of the primary list, or the whole assignment may be
defined either by pointing or through the keyboard.
By pointing at the EDIT button, the user "switches off"
the EDIT instruction and is able to choose another necessary
instruction.
LOAD INSTRUCTION
When the user completes the editing process he has to
insert the displayed text into the appropriate place of the
source text. This is 1nitiali~ed by the LOAD instruction, which
has the same syntax as the LIST instruction. The view of the
screen for the LOAD instruction is also similar to that shown
in Figure 3 with the exception that the LIST button is repla-
ced b7 LOAD and the NEXT button is not present at all.
From the user point~view LIST, EDIT and LOAD instructions
mq be considered as "generating the rough copy ot some part
of the source text", "altering of this copy" and tt inserting
it back into the source text~
STRUCTURE DISPLAY
Programs in ALGOL, LISP and BESM-6 Assembly Language are
representative of texts in which the ttstructure" is expressed
very clearly. Special pairs of symbols are oonsidered to be
block del1m1 ters, for example, " BEGIN ........ and If END ~" 1n
ALGOL, "al tt and "E;" in AUTOCODE-"("and tt ) " 1n LISP.
To exam1ne the structure of the program the user sends
the STRUCT instruction to the system. The syntax of th1s
instruction is the following:
STRUCT / (block segment).
where
(block segment) ::: <block name) I <blook name) : <block name)
Examples
STBUCT / BB.
STRUCT / B10 : B15.
The sequence ot pointing at the light buttons for the
second example is:
block 1 0 upto 1 5 execute
The picture displayed is shown in Figure 5. Suppose that the

708
 B10 - L27 B10 - 127 B10 - L27

[[
B11 - 129
812 - L33
- L40
[[ B11 - 129
B12 - L33
- L40
[[ B11 - 129
B12 - 133
- L40

B13 - L42
[
B13 - L42 [ - L49 [
B13 - L42

- L49 - L49
- L50 - 150 - 150
B14 - L51
[ B14 - L51
- L58 - L58

B15 - L59 B14 - L59

B15 - L59 B15 - L61
[ [ [ - L63

[ [
- 168 - L68

(a) (b) (c)

FIGURE 5. BLOCK STRUCTURE DISPLAY:

(a) normal casei (b) lac~-of-ENDi (c) lack-of-
BEGIN and lack-of-END.

user is dealing with the ALGOL source program. Then, 1n order

to build the required structure, the system is looklng for the
1o-th " BEGIN 1-1" and marks it as the starting point of the
structure. To find the finish of the displayed structure the
system is looking for the" ENDI-I" corresponding to the 15-th
" BEGIN L..I". -
- Besides the normal case (Flgure 5a) three types of
disparltles may be encountered: lack-ot-END (Flgure 5b),
lack-of-BEGIN (Figure 5c), and the composition of both. For
the above example lack-of-END would be registered lf the END
corresponding to the 15-th BEGIN is encountered before the
number of END-s beoomes equal to the number of BEGIN-s 1n the
requ1red segment. In this case the vertioal l1nes, correspon-
ding to the blocks "still opened" have no hooks at the bottom
(Figure 5b). Lack-ot-BEGIN 1s the opposite type of disparity,

709
when the number of END-s in the displayed segment exceeds the
number of BEGIN-s. In this case some vertical lines on the
screen have no hooks at the top (Figure 5c).
With the aid ot the STRUC~ instruotion the user oan
examine and evaluate the block struoture ot an arbitrary part
of the souroe program. The maximum number of blooks being
displayed is 10. If the user sends, for example, the instruo-
tion:
STRUCT / B2 : B20.
and all the blooks being called are ot the same level then
blooks B2 : B11 are displared, while others are negleoted. If
the structure is multilevel then only 10 external blooks are
taken into account.
EDITOR IMPLEMENTATION
The internal organization of the EDITOR system is
developed on the basis of the SNOBOL-A compiler. The execution
of LIST, EDIT, LOAD and STRUCT instructions m81 be divided
into three stages:
1. Transformation of the instruction text to the SNOBOL-A
like form.
2. Processing of the transtorme.d instruction text with the
aid ot the SNOBOL compiler.
3,. Displq1ng ot a text whioh is the result of the instruo-
tion processing.
fhe first of these stages, the transformation of the
EDI~R instruction to the SNOBOL like form, is pertormed by-
systematic substitution of symbols of the instruction text
to the appropriate SNOBOL-A programs. The following exam,les
illustrate this process.
Examples.
1. Instruotion LIST/B8-L15:L19 is transformed to the
following SNOBOL-A statement sequenoe:
AI~ SOURCEI B:= I_BEGIN \....A' I C:= '-' I
Is. 8, Ms. 151 Ns: 19;
~ I:: 1:r !! A pattern .H., B, .T. :. T;
A:: B,T;
~ Is: 1 : M-1 ~ A pattern .H., C, .T • := T;
BUF:. " I
-
for I:: M:N do
begin A pattern .H., C,.T~TI BUF:: BUF,H,C ~J

710
 LIST:: LIST,BUF ,
where SOURCE is the identifier at the variable whose value is
the source text;' BEGIN \-l' is the string corresponding to the
left block delimiter; ._' 1s the str1ng, conta1n1ng the ALGOL
line term1nator. K,M,N - parameters prov1ded by the 1nstruc-
tion text. Intermediate str1ng variables H and T contain the
"head" and the .. tail" of the string A as a result of pattern
search. BUF seryes as a collector tor the values at the
15-th, 16-th, ••• , 19-th lines, appended one to another. The
variable LIST is oonstructed tram the previous LIST
value and the value of BUF. The LIST value is displayed on the
screen.
The process of pattern search is illustrated in Figure
6. The first for statement gives the result Ai , the second
one Ai , the third for statement aooumulates the value at the
BUF variable, 1.e. the str1ng at charaoters from the 14-th
up to 19-th line terminator.
2. Instruction EDIT/L16 - 'ABS' .'ENTlER' is transformed
to:
A:: LIST; M:=16; BUF::",
for I:: 1 : M-1 do
-
8-th BLOCK DELIMITER LINE TERMINATORS

SOURCE:
~
~-----BEGIN -
.2-?-
14 1 5 - 19
_____:004-_~_ _ _ _ _- _

A1:

A2:
13UF:

FIGURE 6. The scheme of pattern search for the instruct10n

LIST / B8 - L15 : L19.

begin A pattern .H., C, .T. :: T; BUF:. BUF, H, C end,

A pattern 'ABS' :: IENTIER'I
-
LIST:: BUF, AI

711
 3. Instruction EDIT/L18 - ~R': 'L' ; 'INTEGER', 9'~'
1s transformed to:
e- LIST; M:x18; BUF:. , ,e
Ae-
,
~

e_
Be- , e BLANK:: B;
l.- f

- e_
--
:tor Ie- 1:8 do BLANK:; BLANK, B;
.-
-
for Ie- 1: M-1 do
begin A pattern .H., C,.T. :;T; BUF:=BUF,H,C end·
A pattern 'R', .N., 'L':; 'INTEGER', BLANK;
-'
LI'S'T:; BUF, A;
4. The sta·tement sequenoe for the instruotion
LOAD/ B8 - L15 : L19 is Similar to that of the example
1, excluding that the "head" and the "tail" of the
SOURCE value should be preserved during the pattern
search, in order to embraoe the ourrent LIS T value:
A:=SOURCEJ B:='_BEGIN 4 ' ; C:= '-'f BUF:; "~I
X:= 8; M:= 15; N:: 19,
-
for 1:=1 : K-1 do
-
}egin A pattern .H., B, .T. :: T; BUl:: BUF,H,B
~;
A pattern .H., B, .T.:. B,T;
BUF:. BUF, H,
for 1:=1 : M-1 do
begin A pattern .H.,C,.T.::T; BUF:;BUF, H,C ~;
for Is: M : N S2 A ~ttern .H.,C,.T. := T;
SOURCE:: BUF, LIST, A,
It can be eeen from the given examples that program~ng
of EDITOR operations in SNOBOL-A 1s rather simple and effient.
Folt the purposes of the EDITOR system it isn't neoessary to
use the full-scale SNOBOL-A compiler. Only three of the
SNOBOL-A. possibilities are of the greatest value - assignment,
pattern search, and for statement.
FUTURE
A useful extension of the desoribed system will be,
from our point of view, the development of a more powerful
mechanism ~or structure d1spl~ and manipulation. Thus, if it
were possible to display the program structure not only on the
basis of blook delimiters but also 1n other terms, S23, with
respect t,o labelling and oontrol transfers, it would be a

712
valuable instrument for program construction, debugging, and
amendment.
Th1s approach would' g1ve also a bas1s for another useful
projeot - the displaying of dynamio program structure in
terms that are intimate to the particular user. We cons1der
this work as one that d1rectly leads to man-oomputer
symbiosis.

REFERENCES.
1. BESM-ALGOL System, Ref. manual, Mosoow, 1969.
2. CERN 6600 Computer. CERN FORTRAN, CERN pub11cation,
Geneva, 1964.
3. J. MoCarthy at a1., LISP1.5 Programmer's Manual,
MIT Press, Cambr1dge, Mass., 1966.
4. S.S. Lavrov "SNOBOL-A a Language for Str1ng Prooessing" ,
Computing Centre of the AcadeDlJ' of So1enoea of the 1lISSR,
Moscow, 1968.
5. V.M. Br1abr1n "Program Debagg1ng from the Remote Console",
Computing Centne of the Academy of SCiences of the USSR,
Moscow, 1970 ( to be published).

713
 PART 9

Computer Generated
Animation
 GENERATING COMPUTER ANIMATED MOVIES
FROM A GRAPHIC CONSOLE

S. E. Anderson

The John Hopkins University, Applied Physics

Laboratory, 3631 Georgia Avenue, Silver Spring,
Maryland, U.S.A.

INTRODUCTION

Graphical output via the computer has been available for

many years now, but generally only one device at a time has
been available to produce the display, and only one mode of out-
put or input has been considered. This paper describes the
successful integration of several components to form a graphics
system which produces plots, animated crt displays, and motion
pictures. Two similar driving programs are employed to create
either planar or 3 dimensional dynamic picture sequences from
picture language commands and/or other pictorial input.

GRAPHIC SYSTEM CONFIGURATION

An on-line computer animation system has been set up at

the Applied Physics Laboratory of The Johns Hopkins University
(see fig. 1). An IBM 360/91 is used to drive a 2250/3 cathode
ray tube in a time shared environment. A program user can type
in picture language commands from the alphanumeric keyboard,
scan and edit this code using the light pen, then call for the
dynamic sequence to be displayed. The programmed function key-
board switches are depressed to advance a selected number of
frames in a "movie editor" mode. When a picture sequence is
considered to be acceptable, a permanent record is made by one
of the following 3 devices:

1. a snapshot by a Polaroid camera, directly from the

c.r.t. screen (all the figures for this paper are
Polaroid snapshots),
2. a plot by a CalComp X-Y plotter (off-line), or
3. a 16 or 35 mm. movie by a Stromberg Datagraphix 4020
microfilm recorder (also off-line) .

717
 Two major programs were written which accept this picture
language: HICAMP (Hopkins Implementation of Computer Aided
Motion Pictures) and HICAMPER (Hopkins Implementation of Com-
puter Aided Movie Perspectives). They were adapted by the
author from his previous work for the E.E. Dept. at Syracuse
University, and are fully described in his M.S.E.E. thesis.
HICAMP produces movies of planar, 2-D objects, while HICAMPER
accepts similar commands to produce movies of 3-D objects in
perspectives (see fig. 2). Both programs utilize a novel list
processing concept to store pictures, which allows a selected
sub-group, or an entire scene to be manipulated by a single
command. Loops of instructions can generate hundreds or even
thousands of frames of film, depicting complex motion of any
sort, expressable by an equation. Simple motions (translation,
rotation, or sizing) can occur separately or compounded togeth-
er. Although the programs were written in FORTRAN for trans-
portability to other computing centers, they are stored on disc
in load module form. All instructions are read in as data
cards, so that the compiler phase is unnecessary, resulting ln
very efficient real time operation. Basic figures, such as a
circle, rectangle, or arrow are invoked by giving an easily
recalled mnemonic with the desired location and dimensions. A
full alphabet, along with special characters are also provided.
Since the letters are treated as pictorial data, they can be
manipulated in the same manner instead of being limited to
several font sizes. Any rectangular area can be masked out or
windowed in automatically. These areas can be changed dyna-
mically, creating unusual "wipes" or "dissolves" for special
effects. If the first and last views of a figure are specified,
all interstitial views can be calculated by a linear interpol-
ation when called for. This technique can even be used to
produce cartoon styled movies.

fIBMl IBM

~ 360/91

MICROF ILH

RECORDER
PLOTTER DIGITIZER

Figure 2.
Figure 1.

718
 OPERATION OF HICAMP AND HICAMPER ON THE IBM 2250

The dynamic sequence of images is displayed on the IBM

2250 crt. The viewing area of this tube is a twelve inch
square, but programming logic truncates all lines to a vertical
height of nine inches. This allows a picture rectangle with a
3 to 4 height to width ratio, which complies with the border
frame for 16 mm. film. The display thus has the advantage of
simulating a movie editor, and the convenient 9 x 12 inch view-
ing area allows co-ordinates to be measured directly from the
tube face if necessary.

The programmed function keyboard (an array of 32 push

buttons) is used to control the action of the display. Several
buttons allow a fixed number of frames to advance: 1 (single
cycle), 6, 24, 96, or 9999 (essentially free run). Two other
buttons specify the projection speed: either 10 or 20 frames
per second. Finally, the light pen can be used to abort the
program if necessary.

UPDATING THE PICTURE LANGUAGE COMMANDS

Alterations or additions to the picture language instruc-

t~ns can be readily made by the programmer without leaving the
graphics terminal. The set of cards are initially keypunched
and loaded onto a direct access device (disc). The IBM pro-
vided "Data Set Edit" program was implemented to provide inter-
active command updating. This program allows a data set to be
scrolled through and displaysc 20 card images at a time on the
crt screen. Any card may be selected by means of the light pen,
and edited in any part by means of the alphanumeric keyboard.
New commands may likewise be entered into a "key-in area", and
inserted after any existing card in the sequence. Once the
data set has been amended, it may be rerun and checked once
again for errors or additions.

THE PENCIL FOLLOWER COORDINATE DIGITIZER

To expedite the input process of complex or irregular

diagrams, a "Pencil Follower" Coordinate Digitizer is used off-
line. This unit permits an unskilled operator to trace over a
sketch or blueprint (see fig. 3) and record the x-y coordinate
pair of any point onto a magnetic tape whenever a micro switch
is activated. The pictorial figure to be copied is placed on
an 18 x 40 inch table, and the shape is traced out manually
with a free moving metal sighting ring wired to a high fre-
quency source. An automatic servo system beneath the table
surface accurately follows the inertia-less ring, and feeds
position signals to the magnetic tape drive with a resolution
of 0.1 mm. An auxiliary 16 switch keyboard permits digital

719
input to precede each pictorial group and assign it to a par-
ticular stack which may be referenced later. A processing
program punches cards from the tape in the appropriate format
for either HICAMP or HICAMPER, so that the figure can be manip-
ulated under animated control. The former method for the pro-
cedure described above was to sketch the figure on cross
hatched paper, read off the coordinates visually, and keypunch
this data onto cards. The digitizer reduces the time involved
in this process by as much as 2 orders of magnitude!

Figure 4.
Figure 3.

STEROSCOPIC ANIMATION

Steroscopic animations can be produced by creating 2

slightly divergent views of a three-dimensional object using
HICAMPER. Two viewing points are chosen at approximately the
interpupilary distance (about three inches) apart, and per-
spective views corresponding to both left and right eye images
are displayed on the crt screen (see fig. 4). When viewed
through an image splitter (the author uses a pair of weak binoc-
ulars sighted from the objective lens end), an illusion of
three-dimensional sight is perceived. The illusion seems es-
pecially real when the object is programmed to move about.
This method, of course, can be extended to movies, but the
position of the viewer is critical in the stereogram method
above, so an anaglyph technique is used. Both left and right
component images are super-imposed on the film, but each is
exposed through a separate polaroid filter. Each person in the
audience wears a pair of corrective polaroid filter glasses to
fuse the images together.

720
 COMPLETED MOVIES

Computer animations are relatively cheaper (by a factor

of 20) than movies produced in the conventional way, and many
subjects are tedious to draw regardless of the budget. Per-
spective views of an algebraic function in motion are difficult
if not impossible to draw accurately in motion; such a subject
has been programmed with ease using HICAMPER. The title of
this film is IIIntegration Over a Solid of Revolution ll (see
figs. 5 & 6).

Other subjects may involve intricate shapes with linear,

but precise motions. These scenes are laborious to redraw from
many frames, especially with varying size presentations. A
movie entitled liThe Game of Chess ll was programmed to illustrate
this facility (see fig. 7).

11'
z

Figure 5. Figure 6.

~ I~ ~ ~ ~ 11 ~ ~
~ ~ ~ ~ ~ ~ ~ ~

fJ. fJ. fj fJ. fJ. fj fJ. fJ.

L1 I~\ \!i ~ ~ \!i .(1 L1
Figure 7.

721
1. Anderson, S.E., "A Graphical Programming Language for
Computer Generation of Incremental Plots and Animated
Motion Pictures", Master's Thesis, Syracuse University,
1968.

2. Anderson, S.E., C.A.L.D. and C.A.P.E.R. Instruction

Manuals, Tech-Report TR-67-6, Syracuse University Elec-
trical Engineering Dept., Syracuse, New York, 1967.

3. Anderson, S.E., "A List Processing System for Effectively

Storing Computer Animated Pictures", UAIDE Proceedings,
Oct. 1968, pp. 205-219.

4. Weiner, D.D. and Anderson, S.E., "A Computer Animation

Movie Language for Educational Motion Pictures", Proc.
of the FJCC, AFIPS, Vol. 33, 1968, pp. 1317-1320.

722
 PRODUCTION OF COMPUTER ANIMATED
FILMS FROM A REMOTE
STORAGE TUBE TERMINAL

R. L. Phillips
The University of Michigan, College of Engineering,
Dept. of Aerospace Engineering, Gas Dynamics, Lab-
oratories, Building 422, Ann Arbor, Michigan, U.S.A.

1. INTRODUCTION

In the few years since Knowlton 1 first discussed his BEFLIX language
for .producing computer animated movies, film-making under computer dir-
ection has been employed in a variety of disciplines. Not only have high
quality films of a tutorial nature been produced 2 but many researchers have
found computer animated films to be an invaluable method for presentation
and study of new data 3. Also, several investigators have recognized the
advantages of computer animated films for educational purposes. Indeed,
Huggins 4 found that in some cases students felt it was easier to perceive
basic physical phenomena from computer generated movies than from actual
laboratory experiments.

One premise on which the present research is based is that there are
many areas in education, particularly engineering education, where subject
material that is normally presented by lecture only could be profitably sup-
plemented by computer animated films. These would not be elaborate films,
in fact they need not even be of "stand alone" quality. Rather, they would
require the presence of a lecturer in order to be meaningful. It is felt that
such films should be made by the instructor who will use them, or at least
made with his close cooperation. This would insure that the film conveys
exactly what the instructor intends instead of a close facsimile that might
be produced by a well intentioned film -maker. Unfortunately, the usual
methods of producing computer animated films militate against this arrange·
ment of close involvement. In general, a computer-output-to-microfilm
(COM) device is required, which, because of its high cost, can be acquired
by only a handful of organizations, usually not universities. Thus, a pro-
grammer must prepare a tape which contains device control commands and

723
send it to some remote location for processing. Since it is usually not pos-
sible to preview any part of the film before sending it away, it can be vex-
ing, not to say discouraging, to discover after waiting typically two weeks
that a small programming error has rendered the film useless. If a casual
programmer, e. g. typical faculty person, is to be persuaded to participate
in computer aided film -making, a far less cumbersome procedure must be
offered him. Such a procedure is the subject of this report.

In brief, a relatively readily available and inexpensive remote terminal

system has been devised that permits on-site programming, previewing,
and production of computer animated films. All ideas presented herein are
readily exportable. Most universities could afford to have one or more
systems of this type on campus, using either a local host computer or a
regional time sharing utility. Since as little time as two hours may elapse
from initial film concept (story board) to actual viewing, an instructor will
remain closely involved with the entire process. The details of this sys-
tem are described in the following sections.

2. HARDWARE REQUIREMENTS
2. 1 Computek Display Terminal
The display terminal used in the present system is made by Computek,
Inc. and is designated as their Model 400/20. A photograph ofthe terminal
is shown in Fig. 1. The feature of this terminal that makes it so suitable
for computer animation and indeed, that makes the system feasible at all,
is the bi-stable storage tube which is used for the display medium. This
tube has excellent resolution and can retain complex, flicker -free frames
for well over 15 minutes with undiminished brightness. By contrast, the
usual graphics terminal uses a display buffer to refresh an ordinary CRT at
least 30 times per second. When the picture comprises, say, a few hun-
dred vectors, flicker becomes perceptible and soon intolerable. With the
storage tube this problem is not present.

Basically, the terminal consists of a display controller and the storage

tube. The display controller recognizes code, which can be in single byte,
two byte, or four byte mode. The latter two modes are used for graphics
while the single byte mode is used for commands and character transmis-
sion. In four byte mode vectors can be drawn between any two of the
1024 x 1024 addressable points, while vectors of coarser definition can be
specified with only two bytes of information. In addition, the Model 400/20
is equipped with a stroke generator which permits a continuous curve to be

724
Figure 1. Computek Model 400-20 Terminal.

725
drawn upon receiving four bytes of data. Since a single curve can replace
many dozens of vectors the size of a display file can be considerably com-
pressed as a result of this feature.

While the Computek can accept data at the rate of 2000 characters per
second most installations would not have the data communication capability
to handle this speed. For time sharing operations, where data transmis-
sion rates above 2000 bits/second are hard to come by, low (110 baud) and
medium (1200 baud) speed serial asynchronous interfaces are usually pro-
vided. Since the Computek is Teletype -compatible and operates on ASCII
code a considerable amount of useful work can be done by using Teletype
device support routines through Bell 103-type modems. Granted, the data
rate is slow (10 characters per second), but most of the work reported
herein has been done at that speed. In order to evaluate system perform-
ance at higher data rates one can simply scale up plotting speeds in propol
tion to the modem available. For example, at 10 characters per second
about 2.5 four byte vectors or curves can be drawn each second. If a Bell
202 type of data set is available, more than 25 such vectors can be drawn
each second.

Finally, the Computek is provided with several "back panel" outputs

which can be switched between ground and 5 volts urider computer control.
This allows a camera to be actuated, a capping shutter to be triggered, or
other external devices to be synchronized to the data flow.

2.2 Host Computer Facility

The host computer at the UniverSity of Michigan Computing Center is
an IBM 360/67 operating under a time sharing executive known as the
Michigan Terminal System 5 (MTS). This is an extremely versatile systerr
which is capable of supporting well over 50 terminal users simultaneously.
The command language is easy to use and provides powerful file manipula-
tion capabilities to the user.

A Digital Equipment Corporation PDP /8 computer is interfaced to the

IBM 360 to act as a data concentrator. The data concentrator accommo-
dates a wide variety of terminal devices while presenting a fixed set of
characteristics to the IBM 360. The data concentrator, being a computer,
is programmable, and in such a way that one can dynamically alter its
treatment of individual I/O records. While such a powerful interface is nc
necessary to the successful operation of a terminal like the Computek, it
does permit the fullest usage of its capabilities.

726
2. Photographic System
As mentioned earlier, computer animated films are made by photo-
graphing static displays, a frame at a time. When a complete frame has
been drawn the last character which is transmitted (DC 2 in the ASCII
command table) causes a "back panel" voltage to go high, which in turn
actuates an Arriflex 16 mm pin-registered camera. The camera is
equipped with an animation motor which allows one to select two shutter
speeds, or the equivalent of bulb operation. After exposure, the frame is
advanced, a screen erase signal is sent to the display, and another frame
begins. This photographic system produces high quality output which is
free from any perceptible jitter.

3. SOFTWARE REQUIREMENTS
3. 1 Low-Level Computek Software
Computek supplies purchasers of a terminal with a package of about 40
rudimentary subroutines for display manipulation. They are coded in
FORTRAN IV and are perhaps not as efficient as one would like but they
exist and they work. These subroutines produce code for the drawing of
both visible and invisible vectors in four-byte absolute and incremental
modes. In addition, two byte incremental scalable vectors can be drawn,
as well as continuous curves, which are specifiable by four bytes. So far,
for film making, only four-byte absolute moves and vectors have been
utilized. Clearly, a great saving in transmission time could be effected by
using two-byte vector modes and the continuous curve feature, and in future
work these capabilities will certainly be exploited.

3.2 Post-Processor for Polygraphics

Since the usual method of producing computer animated films involves
some type of COM device, e. g. an SC-4020, most existing packages of
animation subroutines produce hardware code as the final output. Usually
this is written onto a magnetic tape and processed off-line by the COM
controller. Probably the most widely used subroutine package is SCORS,
written for the SC -4020 in the early 1960's. Recently, a much improved
4020 package was developed at the Polytechnic Institute of Brooklyn under
the direction of L. Braun. This system is called POL YGRAPHICS6 and
was designed expressly for producing computer animated films. Because
of the rich capabilities inherent in POL YGRAPHICS it was decided to adapt
this package for film making on the Computek, rather than attempt to
create a whole new package for this project. The post-processor, which
consists of about 200 lines of FORTRAN IV code, reads its input from a

727
tape or file which contains SC-4020 hardware code. The 4020, like the
Computek, has a screen with 1024 x 1024 raster points, and its plotting
commands specify the absolute coordinates of the starting point of a vector
or move in addition to the horizontal and vertical components of the vector.
This is precisely the information required by the low level Computek sub-
routines, so that translating the 4020 code into a terminal command is a
simple matter.

The flow in the post-processor is as follows: A record of 3024 bytes is

read from a tape or sequential file. This record is broken into groups of
36 bits (an SC -4020 word) and the first 6 bits are examined to see if they
denote a plotting code, or an opcode for 4020 manipulation. All commands
in the latter category, except a frame advance, are ignored while plotting
commands are converted to Computek code, as described above. The ap-
pearance of a frame advance opcode indicates a frame boundary. For the
Computek this command is translated into a camera control byte (which
results in an automatic frame advance in the camera) followed by an erase
signal. Erasing the screen, by the way, requires about 1/2 second and
imposes therefore a lower limit on the shortest possible time in which a
frame can be produced. Thus a 100 ft roll of 16 mm film, which contains
about 4000 frames, would require at least 2000 seconds or a bit more than
1/2 hour to produce.

The output of the post-processor can be sent directly to the terminal,

stored in a file, or punched on paper tape for later use. In addition, since
the post-processor is actually an interactive program there are several
user options which can be invoked. One of the most important of these is
the preview feature. This can operate in several ways. In the single
frame mode no movie making commands are given, i. e. camera control
and screen erase. This mode allows a user to view a single typical frame
to see if it is error-free and, in general, properly composed. Once the
user has passed this stage he can elect the multiple frame previewing fea-
ture. To use this mode requires that the frames to be viewed have been
written in a sequential file, on a data cell, for example. Using certain
system subroutines which note and later point to the location of selected
logical records in a sequential file, it is possible to retrieve any frame
(they are numbered consecutively by POL YGRAPHICS via the frame ad-
vance command word) and display it. The user can simultaneously display
up to 6 frames on the screen and examine them for errors in temporal
evolution. Finally, once a complete film is to be made the user can invoke
a frame replication feature which allows a single frame to be photographed
many times without having to erase the screen and redraw it. This feature

728
is useful for titling sequences or when two-for-one photographic stretching
is desired.

Currently, the POL YGRAPHICS package in use at Michigan is being

modified so that one can elect to produce Computek code directly without
having to produce 4020 code first. This will eliminate the need for a post-
processor and speed up film making (in terms of computer time) consider-
ably. In addition, it will be possible to draw full screen length vectors
with a single command (the length of a vector in the 4020 is limited to 64
raster points), and to utilize two-byte incremental vectors, thus halving
transmission time. Finally, further reworking of POL YGRAPHICS will
allow one to manipulate the Computek character generator, and to use the
curve generator for efficient production of complicated shapes.

4. PROCESSING AND VIEWING

4.1 Film Processing
While processing of 16 mm black and white film should present no spe-
cial problems anywhere, the availability of a continuous daylight developer
in our laboratories certainly speeds up the start-to-finish on-site produc-
tion of films. The developer can accommodate a 100 ft spool (or less) of
either negative or reversal film and requires about 40 minutes to produce a
roll of dry, ready-to-view film.

4.2 Film Viewing

Once the film has been developed it can, of course, be shown on a
standard 16 mm projector. One of the aims of this project, however, is to
encourage the regular use of these films in certain engineering courses.
While setting up a screen and threading a projector pre'sent no significant
mechanical problems to most instructors, the procedure is still enough of
a nuisance to discourage any regular use of these facilities. For this rea-
son, the ultimate form in which films produced on this project will be used
is in Technicolor Super -B endless loop cartridges. This final step requires
that the film be sent away for optical printing from 16 mm to Super-B, and
loading the latter in a specially lubricated cartridge. Approximately 60 ft
of Super -B can be accommodated in these cartridges (the equivalent of 100
ft of 16 mm), giving a viewing time of nearly 4 minutes. The films are
finally shown on a Technicolor 610 rear screen projector, which has a
bright 16 x 20 in. screen. Even the most phlegmatic of instructors would
find it hard to oppose using such a viewing system.

729
5. TIME AND COST FOR FILM PRODUCTION
Obviously, for films that are to be well over 100 ft in length the meth-
od of producing computer animated films discussed herein would not be
practical. For films that are of from 2000-4000 frames long, however,
the method is attractive both from a cost and time standpoint. Costs are
difficult to pin down. Assuming that the programming effort for a film is
not counted in its cost (students provide excellent programming services at
little or no cost) we can begin accounting for expenses at the time we first
sign on at the terminal. Again, costs for computing services vary; at The
University of Michigan terminal hook-up charges are $2. 50/hour, and
other than that, one is charged mainly for CPU time and virtual memory
used. Fortunately, though, the policy is to charge for memory only when
the CPU is being used. Thus, a large program can be loaded, and left in
virtual memory for long periods of time without incurring significant costs.

How long will it take to make a film and how much computer time will
be expended? A difficult question to answer indeed. Obviously, the amount
of computation required to produce a frame and the number of vectors per
frame will both be important factors in giving an answer. First of all,
serious movie making is not feasible with low speed data sets like the Bell
103 series. One should at least have a Bell 202, but the faster the better.
For the subject material with which the author has been concerned (fluid
flow, flight mechanics, heat transfer, to name a few) it has been possible
to produce a 2000 frame film using less than $20 of computer time. On-
site development is a matter of $2 more at most, so that the finished
16 mm film costs about $25. If it is to be converted to Super-8, another
$10 must be budgeted to pay for the optical printing and cartridging. Thus,
the finished film, ready for classroom viewing can be produced for less
than $40. The viewing time of a 2000 frame film is about 2 minutes, but of
course, the endless loop cartridge permits multiple reviewing. This
viewing time has been found to be quite suitable for the lecture expanding
type of film that provides the impetus for this study.

6. ACKNOWLEDGMENTS
It is a pleasure to acknowledge the support of the National Science
Foundation on this project. In addition, Mr. Clarence Martin played a
major role in writing the POL YGRAPHICS post processor and his assist-
ance is gratefully acknowledged.

REFERENCES
1. Knowlton, K. C., "A Computer Technique for Producing Animated

730
 Movies, II Amer. Fed. Inform. Processing Soc. Conf. Proc., 25,
67 (1964). -
2. "Laser Light, " a film produced by Scientific American, with animated
sequences by Joseph Kaye and Co., Cambridge, Mass.
3. Levy, M.A., Pollack, H. N., Pomeroy, P. W., "Motion Picture of the
Seismicity of the Earth, 1961.1967, ,! Bull. Seismological Society of
America, 1970, in press.
4. Huggins, W. H. and Entwisle, DoriS, '!Exploratory Studies of Films
for Engineering Education, "Dept. of Electrical Engineering, Johns
Hopkins Univ., Sept. 1968.
5. Michigan Terminal System Manual, Second Edition, University of
Michigan Computing Center, Ann Arbor, Michigan, Dec. 1967.
6. Sarno, Frank, "Polygraphics User's Manual," Polytechnic Institute of
Brooklyn, Dec. 1968.

731
 PART 10

Developments in
Display Systems
 PROJECT MERLIN
A GRAPHICS OPERATING SYSTEM

M. L. Berman, J. W. Machanik and S. Shellans

Merlin Systems Corporation, Computer Research and
Time-Sharing, 1044 Northern Blvd., Roslyn,
New York 11576, U.S.A.

Introduction

Industry statistics derived from commercial programs

indicate that about 2/3 of the effort needed to develop programs
is spent in programming and debugging. Only about 1/3 is spent
in data gathering, conceptualization, system design and docu-
mentation. A Graphics Operating System developed under PROJECT
MERLIN reduces the effort required for programming and debugging
by at least a factor of 10. Because of the bootstrap features
employed in the Graphics Operating System, it is generally re-
ferred to as the Meta System. The economics of effort associated
with the Meta System are:

• The programmer is coupled to the computer through

a graphic display console. He accomplishes all
normal programming and debugging functions on-line.
In normal circumstances he uses no cards, no list-
ings and no dumps except for backup purposes.

· Meta System embodies unique concepts which allow

the user to produce compilers for specialized
applications, modify the computer "hardware,"
and perform complex data management tasks.

• The ML language is similar in specification to

Algol but contains special constructs which
facilitate the development of graphic applica-
tions and the management of large data files.

Following is a description of the architecture of Meta

System and how the abovementioned benefits derive.

735
Meta System Components

Meta System consists of six major components:

A. The Meta Machine which processes the various

programs which comprise Meta System.

B. The Meta Syntax Compiler which is a compiler

used to write other, applications related,
compilers.

C. The ML Language, a user-oriented language

that facilitates graphic applications.

D. The Meta Putget subsystem, a file-handling

package, which provides the user with the
appearance of virtually unlimited core stor-
age and provides extensive file handling
capabilities.

E. The Meta Text Editor which provides the

user with great facility in writing and
modifying program text.
F. The Meta Operating System which ties together
the above components and provides time-shar-
ing facilities in conjunction with the Meta
Machine.

These components will now be discussed in more detail.

A. THE META MACHINE

The Meta Machine contains registers, memory and the

various appurtenances of every computer. However, the Meta
Machine is not a piece of hardware. It could become hardware
if one wishes to wire together the various hardware components
represented by the Meta Machine. Nevertheless, the Meta Machine
is real in the sense that it accepts data and primitive instruc-
tions, operates upon them according to a completely defined set
of rules, and produces answers. How and why is this done?

The Meta Machine is simulated on any large-scale com-

puter or satellite configuration (the "host" machine) by means
of software. An interpretive program both simulates and defines
the Meta Machine. This program consists of many small, self-
contained, and independent modules. The user of Meta System
interacts with the Meta Machine and not with the host machine.

The reason for this seemingly devious artifice is

threefold:

736
 · machine independence

· creation of a machine suited to Meta techniques

· ability to modify "hardware" to facilitate specific

applications.

Let us examine these features in detail.

Machine Independence

The Meta System as a whole is quite complex and repre-

sents a large development effort. Its usefulness would be
limited if it could be run on only a single type of machine7 re-
writing it for each new machine would be a prodigious burden.
Therefore, the Meta Machine provides a means of presenting the
Meta System with an invariant environment.

Each operating code of the Meta Machine is executed

in a controlled environment by a small self-contained subroutine.
Therefore, the Meta Machine can be readily implemented on any
host machine through assembly language or a high level language.
Since most of Meta System is written in terms of itself, only a
small portion would require rewriting for running on various
computers. Machine independence is thus achieved.

At this point the reader will no doubt raise the ques-

tion as to why the Meta System is not programmed directly in a
high level language achieving a measure of machine independence
and obviating the need for a Meta Machine. The answer lies in
the fact that most high-level languages (such as Fortran) are
not well suited to the requirements of the Meta System. This
will be expanded upon in the next section.

Meta Machine Facilitates Meta Technigues

There are compelling reasons for the existence of a

Meta Machine. On the one hand, the structure of the Meta
Machine interacts with the Meta Operating System to provide for
time sharing, special debugging techniques, and better all-
around program management. On the other hand, the "hardware"
of the Meta Machine facilitates re-entrant code, highly compact
syntax structure for applications languages (such as ML Language)
and the creation of small, simple compilers for these languages.

For example, in order to achieve the first set of

advantages through Fortran on an IBM 360 system, it would be
necessary to modify the Fortran compiler and OS/360. This is
not only a formidable undertaking but implies a non-standard
version of OS/360 requiring continual updating as new versions

737
are released by IBM. In contrast, the Meta System operates
under OS/360 and makes no special demands on OS/360. These con-
cepts will be gone into more fully in the section devoted to
the Meta Operating System.

The second set of advantages (re-entrant code, etc.)

could be achieved through a Fortran program but only in an
awkward and cumbersome fashion. In the remainder of this sec-
tion, this thesis will be discussed in considerable detail.

The Meta Machine is a stack-oriented computer. Op

codes, addresses and data are placed in a "stack." A processing
unit performs the indicated operations and creates new composite
entries for the stack. One property of stack-oriented computers
is that they permit recursion. l

Why is recursion important to the Meta System?

The syntax of the ML Language (described later) is

highly recursive. Statement A is defined in terms
of statement B which is defined in terms of statement
C, which is defined in terms of statement A. The
ability to state the syntax in this fashion pro-
motes a highly compact syntax structure.

Recursion facilitates re-entrant code. Re-entrant

code is essential in a time-sharing system (such as
Meta System) so that each user can, for example, use
a single system-supplied copy of a utility subroutine.
The use of recursive techniques results in smaller
and simpler compilers for applications-oriented
languages such as the ML Language.

With these explanations in mind, we can return to the

main thesis: "Why bother to create a concept such as the Meta
Machine and program it in another language such as Fortran to
achieve the above features when they could be programmed in
Fortran in the first place?" The answer can now be stated
succinctly. Standard Fortran languages do not provide recursion.
without recursion, the ML Language is impossible, re-entrant
1. Recursion is the ability to use an entity being defined as
part of its own definition. For example, subroutine A may
have within it a call to subroutine B. If subroutine B
also has within it a call to subroutine A, then the
principle of recursion is illustrated. In other words, sub-
routine A is defined by its coding and the execution of that
coding. However, within subroutine A is a statement which
relies on the existence of subroutine A (via a call through
subroutine B) for complete definition.

738
code becomes cumbersome, and compilers become larger and more
complex. Providing routines in Fortran to create stacks and
the other facilities needed to achieve recursion is nothing
more than a partial and roundabout approach to the Meta Machine
concept without the latter's simplicity and elegance.

"Hardware" Modification to Meta Machine

Another advantage of the Meta Machine is that its

"hardware" can be altered by a programmer. Hard-wired machines
are costly and difficult to modify, and usually represent a com-
promise with respect to the class of applications they can be
expected to embrace. In contrast, a systems programmer can add
new op codes to the Meta Machine and alter the method of execu-
tion of existing op codes in order to optimize the execution of
a particular application.

More important is the fact that the time-sharing hard-

ware of the Meta Machine can be modified. The Meta System pro-
vides for the polling, queueing, and supervising of many simul-
taneous users. The algorithms which specify polling intervals,
queueing disciplines, etc., attempt to maximize a combination
of resource efficiency (storage, telecommunications lines,
processor time) and user satisfaction. The success of such
algorithms in achieving optimum or near optimum operation is
strongly dependent upon the number of simultaneous users and
the nature of the application(s). It is, therefore, important
to be able to easily modify the time-sharing portions of the
Meta Machine for use in various situations.

Meta Machine can be Bypassed by Fortran Subroutines

The speed of the Meta Machine is slower than that of

the host machine, obviously, because in the final analysis all
Meta op codes go through both machines. However, during the
programming and debugging phase the additional machine time con-
sumed is far outweighed by reduced overall development cost.

When debugging is completed, the efficiency of execu-

tion of the application may not be of paramount importance. The
Meta System excells in the development of interactive, graphic-
ally oriented applications. In such systems calculation time
is relatively insignificant. The major component of time is
taken by the human being who must assimilate the information
presented to him, arrive at a decision regarding his next action
and implement that decision by the appropriate physical response
An increase of many-fold in the time for calculation will not
materially slow the problem solving process whenever there is a
human in the loop.

739
 In those cases where significant calculation is re-
quired -- the solution of a set of simultaneous equations, for
example -- the Meta System provides the ability to link to sub-
routines which have been coded directly in one of the languages
of the host machine. These languages may be high level languages
such as Fortran, or may be assembly language for the utmost in
efficiency.

Subroutines used in this fashion will generally meet

all requirements for efficiency. However, in cases where the
utmost efficiency is required for the entire application package,
it is possible to cause the Meta System to generate machine code.

In this and the preceding few sections we introduced

the concept of the Meta Machine and described its advantages:
machine independence for the Meta System, a "machine" ideally
suited to the philosophy and constructs of Meta System, and the
ability to modify the "hardware" to optimize its operation in a
particular environment.

B. THE META SYNTAX COMPILER

The Meta Syntax Compiler is the second major component

of Meta System. As mentioned earlier, the Meta Syntax Compiler
is a compiler compiler: that is, one uses it to write compilers.
For example, one could provide a computer language for a foot-
ball coach containing such terms as COMPUTE PROBABILITY THAT
HOOK PASS TO RIGHT END WILL GAIN ENOUGH YARDS FOR FIRST DOWN.
The definition of this language with its key words and variables
would be described by its syntax (in a highly structured form
similar to Backus-Naur) and fed to the Meta Syntax Compiler. The
output of the Meta Syntax Compiler is a compiler which, in turn,
will accept FOOTBALL language, viz.:
Syntax of Compilation Football
Football by Meta Syntax Language
Language Compiler Compiler

Football Executable
Language Machine Code
That Will Carry
r---~Out Coach's

/
Program

Compilation
By Football
Language
Compiler FIG. I

740
 In the above diagram, both compilations take place on
the Meta Machine. The executable machine code seen to result
in the diagram would subsequently be processed on the Meta
Machine to supply the coach with an answer.

Several user-oriented languages have been defined

using the Meta Syntax Compiler. (FOOTBALL is not one of them
and is left as an exercise for the reader). One of these is
the ML Language, a general purpose language with special
facilities to aid in the development of display-oriented systems.
ML will be described in the next section.

Those readers concerned with computer techniques, per

se, might be interested to note that the Meta Syntax Compiler
compiles itself. Another way of expressing this is that one
of the languages defined by the Meta Syntax Compiler is a
language for writing Meta Syntax Compilers. In principle this
is no different than the facility of the Meta Syntax Compiler
to accept definitions for FOOTBALL language.

Of course, one may legitimately ask what compiled the

first Meta Syntax Compiler. The first Meta Syntax Compiler
was coded by hand and only had the facility for accepting prim-
itives. The second Meta Syntax Compiler contained more com-
plex structures and was compiled by the first Meta Syntax Com-
piler. This bootstrap operation was continued through many
generations to produce the current sophisticated Meta Syntax
Compiler.

C. ML LANGUAGE

The ML Language is the third component of Meta System

and embodies concepts more familiar to many than the Meta
Machine or the Meta Syntax Compiler. ML is a user-oriented
language that is similar in specification to PL/l, but contains
elements of Fortran and Algol. The ML Language contains con-
structs for 4 types of processing:

Arithmetic and mathematical calculations are

expressed with the same power and simplicity
embodied in Fortran or PL/l.

ML contains the string-manipulative functions

of PL/l that allow alphanumeric strings to be
extracted, concatenated, truncated, rearranged,
etc. These operations are performed upon string
variables, literals and string expressions. Other
operators provide for conversion from numeric
strings to arithmetic variables and vice versa.

741
 ~TA SYNTAX
COMPILER V
OBJECT DECK I'
SYNTAX DESCRIPTION
- -
l-
OF META SYNTAX -
"" ~OMPILATION -
COMPILER
OF
SYNTAX DESCRIPTION
OF ML LANGUAGE "" --------
COMPILERS
l~YNTAX DESCRIPT ION I ON
OF FOOTBALL LANGUAGE )1-----------
'SYNTAX DESCRIPTION .... - META
.- - - - r,
OF OTHER USER- " MACHINE USER
ORIENTED LANGUAGES

\V
FOOTBALL
!IS.E.R COMPILER

SOURCE CODE
1 (OBJECT)
1
COMPILAT ION
~RITTEN IN ~ ON META I-
FOOTBALL MACHINE
LANGUAGE
OTHER
COMPILER
USER (OBJECT)
1 I I

SOURCE CODE ~OMPILA- EXECUTABLE EXECUTION

IN OTHER ~~ION ON ..." OBJECT ~ ON META ~

USER-ORIENTE:C META CODE MACHINE

LANGUAGE
. MACHINE

742
 DIAGRAM OF

META SYSTEM
,

ML
~ COMPILER
(OBJECT)

FIGURE II

'v
SOURCE CODE
WRITTEN IN
,..... COMPILAT
ON META
ION

ML LANGUAGE MACHINE
...v
EXECUTABLE
OBJECT
CODE
.1-
EXECUTION
ANSWERS & . .
ON META
RESULTS
MACHIN~

EXECUTABLE XECUTION
OBJECT + - - - - * ON META ANSWERS &
MACHINE RESULTS

ANSWERS &
RESULTS

743
 ML contains language constructs that facilitate
the manipulation of large files of data. (See
section on Meta Putget for further discussion.)

The ML Language also contains special statements

to facilitate the development of systems and pro-
grams that feature interactive computer-display
consoles. Its use for this purpose in conjunction
with a graphic display console and a text editor
will be described in a later section. Details of
the graphical constructs of the ML Language are
given in a separate appendix.

The ML Language is compiled from source statements to

object code (for the Meta Machine) by the ML Compiler. The ML
Compiler is produced by the Meta Syntax Compiler: The syntax
of ML Language is fed to the Meta Syntax Compiler which outputs
a compiler for the ML Language. ML is completely described in
terms of "syntax equations" which define the syntax and the oper-
ations to be performed. As a consequence, ML is readily modified
to meet special requirements.

Bringing Together the First Three Components

At this point we have described 3 of the 6 components

of Meta System: Meta Machine, Meta Syntax Compiler, and ML
Language. Before proceeding with a description of the remaining
3 components, let us portray in diagrammatic form the way in whic
the first 3 components interact.

(See Fig. II)

D. META PUTGET

Meta Putget, the fourth component of Meta System, is

a file-management subsystem with these highlights:

Putget provides the programmer with an easy-to-use

method of managing and accessing data files within
the Meta System.

Putget provides the programmer with the appearance

of virtually unlimited core storage for Meta System
programs.

The manner in which this is accomplished is completely transpar-

ent to the programmer. All I/O, overlaying and· updating are
done without the intervention or knowledge of the programmer or

744
user. Although files containing data and files containing pro-
gram are handled identically by Putget, they will be treated here
separately for pedagogical purposes.

Data Storage and Retrieval

Data files in the Meta System are unlimited in length.

Items may be added to a file at any time. Putget automatically
allocates additional storage as needed. consequently, the pro-
grammer is relieved of the responsibility of estimating file
sizes and allocating storage. Files are stored on any peripher-
ial device such as tape, disc, drum.

To create a data file, the programmer simply names the

file in a statement which declares it to be a data file and
assigns a type of device for storage. For example, the program
statement:

DISC ALPHA

will create a data file called ALPHA on a scratch disc(s) that

has been placed at the disposal of the Meta System. The user
need not be concerned about which disc or which tracks have been
allocated. (In fact, as the file grows, it may reside in many
noncontiguous areas of one or more discs.) The system, behind
the scenes, does all necessary housekeeping without the inter-
vention of the programmer or user. However, if necessary, the
user can control disc assignments. This is useful, for example
in situations where it is desired to dismount and save a certain
disc pack containing related information.

Following is a brief description of the behind-the-

scenes activities carried out by Putget.
Meta System allocates buffers in core for the use
of Putget. Each buffer can accommodate one track
of data.

When the user's program requires a datum from the

file, Putget in conjunction with the Meta Operating
System determine the location of the track contain-
ing that datum and bring it into core.

Since Meta System is a time-sharing system, the

number of buffers in core may not be sufficient to
accommodate each file of every user simultaneously.
Therefore, buffers are not permanently associated
with a particular file, but are swapped around de-
pending upon the needs of the moment. A carefully
designed aging algorithm determines which buffer
to overlay when all buffers are occupied and a new

745
 data file is referenced.

When the last vacant buffer is allocated, Putget

determines which buffer to overlay, should additional
space be needed. If this buffer has been written
into or modified, Putget will restore it to the disc
for subsequent use. In this way there is always a
vacant buffer available when required by any of the
applications programs.

A file may contain either numeric data or alphanumeric

string data. (ML Language provides extensive facilities for
character and string manipulation.) The user need not declare
whether the file is numeric or alphanumeric, but simply stores
or retrieves one or the other kind of data with ML commands
appropriate to each. For numeric data files, data would be
accessed in the following manner:

ACCUM = ACCUM + ALPHA (I)

where I is some index (in a DO-loop, perhaps). Successive values

of the file ALPHA would be retrieved and used in the above com-
putation depending upon the value of I. It is important to note
that the programmer treats the disc file ALPHA as if it were com-
pletely contained in core. There is no I/O or swapping apparent
to the programmer.

Files are implicitly one-dimensional whether they be

numeric or alphanumeric. In numeric files, the nth number
occupies the nth "slot,,2 of the file and in alphanumeric files,
the nth character occupies the nth "slot." Files have no pre-
determined length. As more data are added to the file, addi-
tional space is allocated.

The reader might wonder about the lack of provision

for multi-dimensional files, multi-valued files, non-ordered
files and other file structures that arise in the real world.
These must somehow be mapped into the one-dimensional, single-
valued file structure represented above. This mapping is the
responsibility of the programmer and was planned as such for
three reasons:
Providing for a multitude of file structures,would
destroy the simplicity of the system as viewd4 by
the programmer.

Having the mapping responsibility reside with the

2. A "slot" in a numeric file contains a different number of
bits than a slot in an alphanumeric file to permit efficient
use of storage.

746
 programmer permits complete flexibility to accom-
modate any kind of file structure.

Having the mapplng done in the user's program pro-

vides for greatest efficiency of execution and
greatest economy of space.

Such mapping is not difficult and once defined by the programmer

is of no concern to the user.

Virtual Memory for Programs

The term virtual memory refers to techniques whereby

the programmer is presented with the appearance of virtually un-
limited core storage. The handling of data files as presented
above is an example of such techniques. Program files are
handled in an identical manner by Putget. The programmer may
write programs of any length consisting of any number of pro-
cedures (subroutines). They will automatically be segmented
into i-track lengths by the Meta Machine and stored on disc as
part of a program file.

Of course, the programmer is not aware of this behind-

the-scences activity; he simply writes the program as if he had
unlimited core at his disposal. In line with the "transparency-
to-the-programmer" philosophy of Putget, segments of program
from the disc are automatically swapped into core as the flow
of program control dictates. This procedure, called paging,
has been carefully tailored to the Meta System for maximum
efficiency.

E. META TEXT EDITOR

Meta Text Editor, the 5th component of Meta System, is

an on-line subsystem for introducing and modifying textual
material. Although it could be used equally well for composing
business letters, its main function is the modification of pro-
grams (application or system) used with Meta System. Such pro-
grams are called forth, displayed on the face of the tube in
groups of several statements, and massaged with the Meta Text
Editor. Since text editors are fairly widely used and understood,
only a brief description of their advantages and the method of
use is given here.

The Text Editor is used to scan the program on the

screen, to jump to any location in the program and display text
starting at that point, to rearrange statements or groups of
statements in the program, to insert or delete statements,
characters or words, and to search out all occurrences of a
particular phrase or variable.

747
 The foregoing is accomplished using a light pen (or
other input device) and the alphanumeric keyboard. With practic1
the above steps are accomplished as fast as the eye can follow
and represent a dramatic improvement over card shuffling and
key punching.

Through the text editor, the programmer has access

not only to his applications program, but to the Meta System
programs as well. (Including the Text Editor). This access
to Meta System facilitates debugging in cases where it is
necessary to determine how the Meta System would handle a
particular situation.

It is interesting to note that the Text Editor is pro-

grammed in the ML Language.

F. META OPERATING SYSTEM

The last component of Meta System is the Operating

System which ties together the other components and brings them
into contact with the user. It also provides various services
such as a debugging package. (It is interesting to note that
the Meta Operating System is also programmed in the ML Language.

Four aspects of the Meta Operating System impinge upon

the user or programmer. These are:

Relationship with the operating system of the

host machine (e.g. OS/360)

Time-sharing facilities

Light-button structure

Interface with user, and other services performed

These will now be examined in more detail.

Example of the Relationship Between the Manufacturer's Operat-

ing System and Meta Operating System

Recognizing that many users might wish to use the Meta

System in conjunctionOwith other programs, Meta was designed to
be subordinate to the operating system supplied by the manu-
facturer of the hardware. The complete Meta System has been
implemented on IBM 360 equipment under OS/360 and elements of
Meta System have been implemented for the CDC 3100 by Merlin
personnel. However, the interaction with the manufacturer's
operating system is so minimal that Meta System can readily
be implemented on other hardware.

748
 This interaction consists of the following:

Initiating the job (i.e., Meta System)

Terminating the job

Use of basic I/O routines where expedient

Meta System can operate in a mUlti-programming environment such

as MFT or MVT under IBM OS/360. In this environment Meta System
has the appearance of a conventional job.

Multiple Users - Time Sharing

As mentioned earlier, Meta System is a time-sharing

system. The characteristics of the Meta Machine and the Meta
Operating System allow multiple jobs to be run simultaneously.
These jobs may be any mix of on-line applications, on-line
systems development and background jobs. On-line terminals
can range from sophisticated graphic display consoles, through
text displays, to hard copy devices such as teletypes or type-
writers. Of course, the computer must be able to electrically
interface with such devices and have sufficient capacity to
provide an acceptable level of service.

At any particular installation the mix of applications,

systems, development and production is unique. Two features of
the Meta System allow it to be molded to fit each particular
installation's mix of jobs. First, the Meta Machine and Meta
Operating System provide built-in facilities for statistics
compiled. What is the average response time as a function of
system loading? What is the distribution of processing time
for each request by a particular user?

Second, the Meta Machine is, in reality, software and

hence the time-sharing algorithm of the "machine" can be alter-
ed by a system programmer to respond most effectively to the
job mix of each installation.

Light Button Structure

One of the more important facilities provided by the

Meta Operating System is the implementation of a decision tree
through "light buttons". A light button is merely a word or
symbol that appears on the face of screen, usually as part of
a list of such symbols or words. Each word or symbol is a
choice that will cause some action to be performed if it is
selected. Selection is accomplished by pointing the light pen
(or other device) at the word. When this is done, the word
intensifies to provide feedback to the user as to which light

749
button he activated. Then, the action described by that word
is initiated.

A decision tree is simply a network of possible de-

cisions relating to some activity. Each node in such a network
is reached as the result of a decision, and points the way to
additional decisions. Nodes are connected in such a fashion
that a meaningful path results. Consider an example.

(See Fig. III)

It is seen that this method of communicating one's

desires to the computer system has 4 important advantages:

It is very fast. There is no keypunching or

typing or referencing manuals. An experienced
user can pick his way through a complex decision
tree at a rate of 2 nodes/second if the inter-
mediate calculations performed by the system are
straightforward enough to allow it to keep pace
with the user.

It is not possible to make any mistake other

than a mistaken choice. An invalid choice
cannot be made since only valid choices are
displayed. Syntax and spelling errors are
eliminated since the system takes the initiative
of presenting choices to the user.

The full potential of the user's decision-making

ability is tapped since all choices at any particular
node can be presented on the screen. All too often
Suppose that demographic information on the United States were
stored in the computer and a user wanted to have the population
of Boston in 1960. The first set of light buttons that might
be presented to him would be the names of the 50 states. He
would select Massachusetts with the light pen. Then a second
set of light buttons would appear with the names of Massachu-
setts' cities. He would select Boston and the third set of
light buttons might appear as SIZE, POPULATION, INCOME, etc.

If the number of possible choices is very large,

the light button facility allows the programmer to provide
for typed-in names from the alphanumeric keyboard. Alternative-
ly, the programmer can choose to display the light buttons in
successive frames in a manner analogous to that used for pro-
gram text.

These facilities are available to the programmer

(and hence to the user) in a high level form as part of the

750
ML Language. See Appendix on Graphical Constructs of the ML
Language.

NODE 0

ALABAMA WYOMING

NODE 1 NODE 50

BOSTON SOMERVILLE

137 3 8

SIZE POPULATION

330 331 332

FIGURE III

the user of a non-interactive system will remain

unaware of certain system capabilities because
he is not thoroughly informed as to the breadth
of choices available. On the other hand, the
user is guided through the decision path because
at any point he sees only those choices which
are pertinent; he does not view the entire
decision tree.

751
 Not only is the light button capability available to
the programmer for inclusion in his programs, the Meta System
itself offers its faciliti'es to the user through a light button
tree. The user can rapidly interact with the other components
of Meta System, his program, and data files by the appropriate
selection of light buttons. Complex data management procedures
can be faultlessly performed in seconds. An example is given
in a following section entitled "The Meta System in Action."

A scheme has been developed which allows the rapid

implementation and subsequent modification of the light button
tree structure itself. Light button constructs have been in-
cluded in the ML Language. In this way, a decision tree
structure can be radically changed without disrupting or
causing significant changes in the actions which occur at each
decision node.

Other Services Provided by Meta Operating System

The Meta Operating System ties together theML Com-

pile~ the Meta Syntax Compiler, the Text Editor, the Putget
subsystem, and presents them to the user or programmer in a
coherent fashion. It also provides a multitude of services
that range from card reading to debugging aids.

Consider card reading, for example. It is possible to

invoke the reading of cards from the graphic console by touch-
ing the light pen to a light button called "CARDS." The System
also keeps track of all source programs which have been modified
through the on-line console but not punched out (for backup
purposes). Another light button called PUNCH will automatically
produce a deck of each modified procedure. (It will be remem-
bered that all decks, source and object, are stored on disc
under control of Putget). In practice, services such as these
are of substantial benefit to the programmer.

Another significant service performed by Meta Operat-

ing System is the way in which it allows the programmer to
"look into" the machine. At any point in a program, the pro-
grammer can stop execution (by planting a trap) and examine the
current values of his variables. Unlike a dump, the variables
appear on the screen by name, in alphabetical order, along with
the current value of each variable. If the variable is a number,
it is expressed in decimal. If it is a character string, the
internal character codes are converted and shown on the screen
as the actual English character string.

Eliminating the need for obtaining and interpreting

dumps is one of the reasons that users of Meta System bring
programs to production status in one-tenth the time of con-
ventional techniques.

752
THE META SYSTEM IN ACTION

with an understanding of the components of the Meta

System and how they interact, let us see how the system impinges
on the programming and debugging process. Chronologically, a
user would employ some or all of the following facilities:

1. Construct an application language appropriate

to the task at hand.

2. Modify the Meta Machine, if necessary, to

achieve greatest efficiency.

3. Program, on-line, using the graphic display

console.

4. Use the text editor to modify, reproduce,

delete and rearrange program statements.

5. Use the interpretive features of the Meta

Machine to aid in debugging.

Let us consider these steps in greater detail.

The first step is to decide whether a new language is

needed. For most applications, the ML Language will be suitable.
The programmer may wish to modify ML Language in some respect,
however. This is easily done by changing the syntax equations
which define the ML Language. In some cases where extensive
programming is to be done using a specialized vocabulary, the
programmer may wish to define a new programming language and
compiler. As seen in figure I, this is readily done by defin-
ing the syntax of the language and passing it through the Meta
Syntax Compiler. This produces a compiler for the new language.

The second facility, if desired, is the ability of the

programmer to modify the "hardware" (i. e., the Meta Machine) to
achieve greatest processing efficiency. He might also wish to
modify the Meta Machine to add additional debugging aids.

Now the programmer is ready to begin programming, and

ready to begin realizing a time saving. As mentioned earlier,
the graphic display console is used to take full advantage of
the features of Meta System. The programmer usually enters his
program, on-line, through the keyboard of the graphic display
console. With practice, this procedure is faster than filling
out coding forms. As a line of code is typed in, it appears on
the screen, and the programmer can verify its correctness.

Debugging begins with the fourth step. Every time Meta

753
System encounters a syntax error during compilation, it displays
the offending statement on the screen along with an arrow point-
ing at the mistake or the suspicious area, and an explanation
as to the nature of the syntax error.

For example, if the programmer had inadvertently

omitted a parenthesis in a statement, he would be greeted by
the following display on the screen:

BETA = C*(l + ALPHA(I-ll;

MISSING RT PAREN
At this point, the user inserts the missing parenthe-
sis, and re-initiates the compilation process by simply touch-
ing the "COMPILE" light button. Had it been necessary, more
complex editing could have been carried out as described
earlier in the section devoted to the text editor. This is
all done with the light pen and the keyboard. With practice,
the above steps are accomplished as fast as hand and eye can
work together and represent a dramatic time saving over con-
ventional methods.

Wherever possible, the system attempts to antic~pate

the requirements of the user. For example, when a syntax error
is discovered, the system calls the text editor without waiting
for the user to initiate this action.

When the user has eliminated all syntax errors, he is

ready to begin exorcising his logic errors. Here, again, the
features of Meta System allow the programmer to be more pro-
ductive, thereby bringing programs to fruition at greatly re-
duced cost. The reasons behind this will now be presented.

The Meta Machine provides the capability of checking

out programs in a controlled mode. That is, the Meta Machine
accepts a string of input (such as the compiled object code
of an application program), determines the meaning of each
symbol in the string and performs the appropriate operations.

The controlled mode of operation has certain advan-

tages over conventional compilers for debugging. Certain types
of errors ordinarily fata1 3 , can be detected before they can
be committed. For example, an addressing error, where a user
attempts to reference an area of storage outside his range, can
be forestalled.

Another attribute of the Meta System is the ease with

which debugging aids can be (and have been) added to the system.
3. Job terminated, for example.

754
For example, the user can stop execution at any point and look
around and inspect the current values of his variables at that
point. Suppose, for example, that variable ALPHA in a program
was intended to take on values between zero and one only. Also
suppose that during execution ALPHA somehow gets set to a large
number. The user would plant a trap for ALPHA (using the Text
Editor) such that as ALPHA was about to be set to a large number
execution would stop, the offending statement would be displayed
on the screen, and the user could proceed to track down the
cause of the trouble.

Although techniques such as this are possible in con-

ventional compiled machine code, they are difficult to imple-
ment and, therefore, not abundant in contemporary compilers.
Furthermore, debugging aids that are implemented in conjunction
with compilers are done at the time the compiler is written
by a systems programmer and are not accessible to the applica-
tions programmer. In the Meta System, there exists a trans-
parency between the user and the code being executed, permitting
easy inclusion of debugging aids by the user (in addition to
those supplied with the Meta System).

At this point, let us review what our programmer has

done, and how he proceeds to track down a variable out of range.

The programmer has typed in his program from the key-

board of the graphic display console, and has removed all
syntactical errors. Debugging to remove logical errors is
about to begin. He initiates execution. As the program runs,
output appears on the face of the screen. Something is wrong.
One of the answers is far out of range. He wishes to examine
the values of several internal variables at the time the first
answer is computed. He stops the program by pressing a "panic"
key and uses the light pen to call for the source program on
the screen. using the Text Editor he scans back and forth
through the program to locate the appropriate spot to plant
a trap. With the light pen and the keyboard he plants the trap
and reinitiates execution. Execution stops as desired. Using
the debugging package he calls for a display showing the current
values of all his variables. He determines that the variable
ALPHA is the out-of-range culprit and was responsible, in turn,
for the answers being out of range. He realizes his error:
he has two distinct variables in his program but has called
them both ALPHA.

One of them will have to be changed to BETA. He

orders the Text Editor to search out every occurrence of the
word ALPHA in his program. Each time it finds one, it displays
the statement on the screen in context with the surrounding
statements. Using the light pen and the keyboard, he changes

755
the offending ALPHAs to BETAs. Finally, he uses light buttons
to recompile and execute the program.

This has been a brief description of a hypothetical

dialogue between man and machine. Its purpose is to illustrate
the ease and rapidity with which programs can be debugged.

FINALE

There are a few points in the above material which

deserve to be emphasized.

The purpose of Meta System is to reduce program

development effort by a factor of at least 10:1.

Although Meta System can profitably be used in the

development of any program or system, it contains
special constructs that facilitate the development
of display-oriented applications.

A major advantage of Meta System is that the entire

programming and debugging function can be carried
out from the graphic console. (However, this does
not eliminate the possibility of obtaining hard
copy.) This results in a reduction in development
cost and effort.

Meta System is a time-sharing system and can it-

self be run under a time-sharing monitor in the
host machine.

ACKNOWLEDGEMENT

The authors wish to acknowledge many helpful sugges-

tions from Charles Kinkley, formerly of Stanford Research In-
stitute, which contributed to the formulation of the Meta
System concepts.

APPENDIX

Graphical Constructs of the ML Language

Features are provided in the ML Language that enable

the programmer to create displays on the cathode ray tube and
enable the user to communicate with the program through the
interactive devices. The features described below are oriented
toward a graphic display console that has a vector and char-
acter generator, a light pen, an alphanumeric keyboard, a func-
tion keyboard and an audible alarm. Other features sometimes

756
found on graphical display consoles are circle generators,
wink circuits, variable intensity control, variable line tex-
tures, variable character size, and a variety of user I/O de-
vices such as mouse, joystick and trackball, etc. Language
features for these devices are not covered in this discussion.

Screen Layout

By convention, the face of the screen is divided into

three areas if full use is to be made of the graphic ML Langu-
age features. The exact size and shape of each area depends
upon the particular piece of equipment, but a typical layout
is shown here:

LIGHT
WORK AREA
BUTTON
A~A

MESSAGE AREA

~--------------------------------------------------~-------------

757
 The light button area is used to· display words indi-
cating the actions that the user may perform. By touching the
light pen to a particular word, that action will be performed.
See the full description of the light button statement on page
18 of this section.

The message area is used to communicate short messages

to the user from the program. This area is treated as a scroll:
when the area is full, the next message pushes the oldest mes-
sage off the screen. In this way the user has the several most
recent messages on display.

The work area is completely at the disposal of the

application program and is used to display charts, drawings,
graphs, pictures or text.

The discussion which follows is organized relative to

these three areas. First, the two statements relative to light
buttons are covered (LB statement and the .LBNUM construct).
Second the two constructs relative to the message area are
covered (DTEXT and .BELL). Finally, the many constructs relativi
to the work area are covered.

LB Statement

Purpose: Specify communication with the facilities of the

graphic display console. Functions are (I) dis-
play node identification and light button choices,
(2) accept information from the alphanumeric key-
board, (3) handle light pen interru~on entities
other than light buttons, (4) accept information
from the function keyboard. In the syntax shown
just below, each of these functions is shown on a
separate line identified with the above numbers.

Form: label:LB CJ
(1 ) *strexPl*(labO}
{ namel (labl), name2(lab2}, name3 (lab3) ••••
*strexpl*(labO}
J)
(2 ) [/KB (lablO)]
(3 ) [/LP (labll)]

(4 ) numl
[/FK( ( *num2, num3,
nums
[ *num6, num7,
J
num8~ •••
]
(lab12>J ;

Description and Examples:

758
 The light button (LB) statement performs any or all
of several functions:

Display l2-character light buttons in the light-

button area of the screen and transfer control to
corresponding routine (labl, lab2, lab3) when a
light pen detect occurs on any light button.

Detect light pen interrupts on any portion of the

screen other than light buttons and transfer con-
trol to a routine (labll) to handle the processing.

Accept alphanumeric strings from the keyboard and

transfer control (lablO).

Illuminate function keys, recognize when these are

depressed, and transfer control (lab12).

Light button statements must themselves be identified by a

label. This label is an identification of a node in a decision
tree, and is displayed in the upper right corner of the screen
as a landmark to aid the user.

Suppose it were desired to display the light buttons

TAXI, BUS, SHANKSMARE. The LB statement would appear

TRANSPMODE: LB(TAXI, BUS, SHANKSMARE);

The node display would contain TRANSPMODE, and below would appear
the three light buttons. If one were detected on with the light
pen, control would be transferred to a statement. within that pro-
cedure having a label of the same name. For example, if the
light pen caused a detect on the TAXI light button, control
would be transferred to a statement with the label TAXI.

In certain cases it may not be convenient to use a

light button having the same name as the statement to which
control is transferred. In such cases, the label is stated
in parentheses following the name of the light button, viz.:

TRANSPMODE: LB(TAXI(HICOST), BUS(LOWCOST), SHANKSMARE);

In this case, if TAXI were detected, control would go to HICOST.

It is also possible to obtain the text for light

buttons from any alphanumeric string. The first 12 characters
are assumed to be the text for the first light button, the
next 12 characters the text for the second light button, etc.
The use of a string as light buttons is signified by enclosing
a string expression in asterisks:

759
 STRING (36) CARRIERS:

CARRIERS = 'UNITED --- EASTERN --- AMERICAN ,

___ I .

AIRLINES: LB(*CARRIERS*(GOLABEL))i

In this case, the three buttons UNITED, EASTERN, AMERICAN

would be displayed, and if a detect occurred on any of them
control would be transferred to the statement with the label
GOLABEL. To determine which button was detected on, the cell,
.LBNUM, containing the number of the detected button, may be
interrogated. In the above example, CARRIERS in the LB state-
ment could have been replaced by the literal itself or any
valid string expression.

It is also possible to use string expression light

buttons in conjunction with the first form. Example:

ALLAIRLINES: LB(KLM(DUTCH), SABENA(BELGIAN), *CARRIERS*

(DOMEST IC) ) i

When the two forms are intermixed in this fashion, the string
expression light buttons must appear last. In this example, if
UNITED were detected on, .LBNUM would return the value 3.

It is also possible to provide for light pen detects

on entities other than light buttons. For example:

ALLAIRLINES: LB(as above) /LP(NOTCARRIER)i

In this case, any other light pen detect would transfer control
to the statement with the label NOTCARRIER. Certain cells can
then be interrogated to learn the coordinates of the detect.

The function keyboard and the alphanumeric keyboard

are handled in a similar fashion:

ALLAIRLINES: LB(as above) /LP(NOTCARRIER) / KB(NEWCARRIER) /

F K ( 1 2 3 *4, 16 , 2 *) (LAB) i

If the user chose to type in information from the alphanumeric

keyboard, the program would wait until the entire string had
been typed in (as signified by the END-OF-BLOCK signal from the
keyboard) and would then transfer control to NEWCARRIER. At
this point, the string can be returned by the built-in function
*KB.
The above statement also calls for the illumination
and activation of function keys 1, 2, 3 and 4 through 16 every

760
other one (i.e., 1, 2, 3, 4, 6, 8, 10, 12, 14, 16). Function
keys can be turned on individually (such as keys 1, 2 and 3 in
the above example) by simply specifying the key numbers in the
parentheses following "FK". Theycan also be turned on in groups
by the symbology *numl, num2, num3* in the parentheses. This
expression indicates that starting with function key numl, and
ending with key num2, turn on every num3th light. If the
above example had read FK (1 2 3 *4, 16, 3*), function keys
1, 2, 3, 4, 7, 10, 13, 16 would have been turned on. (i.e.,
every third one in the range 4-16) .

• LBNUM Construct

Purpose: Obtain the number of the light button detected on by

the user.

Form: integer expression containing .LBNUM

Description and Example:

When light buttons are put up from a string, the only

way the program can determine which particular light button was
detected on is through the function .LBNUM. Typically, this
function is used in conjunction with the CASE statement so that
a different action can be performed for each light button.
Example:

CASE .LBNUM OF BEGIN

statement 1 for light button 1
statement 2 for light button 2
statement 3 for light button 3

statement n for light button n

END7

The above statements can be compound statements.

DTEXT Construct

Purpose: Output message to message area.

Form: DTEXT (strexp) 7

Description and Example:

A string is transmitted to the message area.

761
 Example:

DTEXT (GRAPHNAME CAT '_IS ILLEGAL CHOICE');

If the variable GRAPHNAME were equal to "PROFITS", the follow-

ing message would be displayed in the message area:

PROFITS IS ILLEGAL CHOICE

If the messages are short (exact length depends on screen size)

two are displayed on a single line to conserve space. When the
message area is full, the next message will "push" the oldest
message off the screen, thereby treating the message area as
a scroll •

. BELL Construct

Purpose: Sound audible alarm.

Form: .BELL

Description and Example:

By simply issuing this one-word command, the audible
alarm is sounded. It is useful in calling the attention of the
user to messages that are of special import. For example:

DTEXT (' UNKNOWN RADAR CONTACT IN AREA 4' ) ;

DO I TO 3 .BELL;

would put up the message shown and sound the audible alarm 3
times.
This completes the discussion of the ML statements
and constructs peculiar to the light button area and message
area. Before proceeding with a discussion of the many ML
facilities pertinent to the work area, some preliminary con-
cepts are presented.

An entity is defined as a single point, straight

line, character, or text message. Every entity has two names
associated with it: a member name and a family name. A family
is composed of one or more members. This concept is useful in
referring to and manipulating collections of entities. For
example, suppose that a triangle and a square are displayed on
the screen in the work area. Each separate line is an entity.
Assume further that the four lines of the square have been
given the member name SQUARE, that the three lines of the tri-
angle have been given the member name TRIANGLE, and that both

762
of these members have been declared as belonging to the family
GEOMETRY. In this way, a light pen detect on any single line
(entity) can be readily treated (if desired) as a detect on the
entire geometric figure (member). At a higher level, it is
possible to refer to both geometric figures by the family name.
For example, if one issued the command .DELETE FAMILY, both
geometric figures would disappear from the screen.

Only a single family may be "active". The active

family is defined as that particular family upon which family-
related commands will operate, and that family to which newly
defined members will belong. A family is made active by simply
issuing a FAMILY command with the name of the desired family.
(See FAMILY command). Thereafter, all family-related commands
will pertain only to that single family. It is important to
note that the concepts "active" or "inactive" do not refer to
the material displayed on the screen; both active and inactive
families are displayed until specifically deleted by the DELETE
statement •

. DEFINE Construct

Purpose: Define a member name, set aside a portion of the

screen for this member, and equate physical screen
coordinates to data coordinates.
*
Form:
l
{nEFINE]
.DF (membname, xl, yl, x2, y2, [X3, y3 ,x4, y4 }) ;

Description and Example:

This construct has 3 distinct functions. First, it

is used to declare the existence of a new member name. Entities
such as lines, characters, etc. which must belong to a member,
may not be created until their member has been defined. If a
member is defined which is already in existence, the following
occurs. All entities belonging to that member at the time it
is redefined are expunged. In detail, they are removed from the
display and removed from all tables maintained by the system.
In the above Form, membname can be any valid string expression.

The second purpose is to define a rectangular portion

of the screen that may be used by this member. Every graphic
display console has a certain fundamental resolution or number
of raster units associated with the CRT. These are addressable
points. On the IBM 2250, for example, these run from 0 to 4095
in both the x and y direction, with the origin at the lower-
left-hand corner of the screen. In the above Form, x3 and y3
are the hardware (physical) coordinates of the lower-left-hand

763
corner of the rectangle for this member. X4 and x5 are the
physical coordinates of the upper-right-hand corner of the
rectangle. 4

The area thus defined is important in that entities

having a member name that fall outside their member's rectangle
are scissored. That is, the portion of the entity falling out-
side the member rectangle is not displayed. Optionally, the
programmer can cause special indications to appear when an
entity is scissored so that the user is alerted to the fact.
Lines and characters are scissored somewhat differently and
will be fully discussed under the .ENDPOINTS construct and the
.CHARACTER construct.

Two important notes on member rectangles:

The rectangle may intrude into the message area

and the light button area. In fact, one fre-
quently defines the rectangle to be the entire
screen. When this is desired, it is simply
necessary to define the physical limits with an
asterisk in place of x3, y3, x4 and y4 as shown
in the above Form.

Member rectangles need not be mutually exclusive.

They may overlap and, in fact, may be coincident.

The third purpose of the .DEFINE statement is to

equate the data range of the particular application with the
physical coordinates of the rectangle. For example, if one's
data runs from zero to 100, it is inconvenient to have to map
entities into a rectangle whose physical coordinates might,
for example, run from 50 to 3500. Therefore, in the .DEFINE
statement a means has been provided for specifying the coordin-
ate transformation that is to take place on all entities belong-
ing to this member. This is accomplished through xl, yl, x2 and
y2. These are the data coordinates to be associated with the
lower-left-hand corner and the upper-right-hand corner of the
rectangle. Thereafter, all statements will use data coordinates
rather than physical coordinates and the system will automatical·
ly carry out the coordinate transformation.

Example:

.DF ('GRAPH' CAT ALPHA, 0, 0, 100, 100,*);

If the string variable ALPHA contained "PROFITS", the member

name is "GRAPHPROFITS", the data coordinates of the rectangle
4. Coordinates can be expressed as any valid integer expres-
sion.

764
run from zero to 100 in both the x and y direction, and the
physical limits are the entire screen .

• LINE Construct

Purpose: Define a line to be displayed

Form:
{~LINE
.LNj
l(membname, xl,yl,x2,y2) i

Description and Example:

This construct defines a line which will subsequently

be displayed. It belongs to a member whose name is membname
and has endpoints given by xl, yl, x2 and y2. These coordinates
are data coordinates and are related to physical screen coor-
dinates by the .DEFINE statement.

It is important to note that this construct does not

display a line. (That is done by the .DISPLAY construct to be
described later.) It merely defines a line for subsequent dis-
play.

Example:

.LN('GRAPHPROFITS', 30, 35, 80, TOPLIMIT/2)i

• TEXT Construct

Purpose: Define text to be displayed

Form: \": TEXT ( (membname, xl,yl, strexp)i

l·TXj
Description and Example:

This construct defines a string of text which will

subsequently be displayed. It belongs to a member whose name
is membname and the text will be put up beginning at location
xl,yl. The text is given by strexp.

As is the case with the .LINE construct, the .TEXT

construct does not actually display the text.

Example:

.TX('GRAPHPROFITS', 0, 95, 'YEAR CAT DATA(lO/5))i

765
.CHARACTER Construct

Purpose: Define a character to be displayed.

Form: CHARACTEj
[ . CHAR (membnarne, xl, yl, strexpl [( strexp2}J ~
.CH

Description and Example:

This construct is similar to the .TEXT construct in-

asmuch as it defines text to be displayed. However, it does
so for only a single character at a time and has provision for
scissoring. First, the use of the statement without scissor-
ing will be described, followed by a description of scissoring.

In the above Form, membname is the member name to

which this entity belongs and xl and yl are the data coordinates
of the member rectangle at which the character is to appear.
The character to be displayed is the first character of a string
expression as given by strexpl. The optional strexp2 will be
desc"ribed shortly in connection with scissoring. For example,
suppose the string ALPHA contains the string "ABCD". The state-
ment:

• CHAR (TALLY, 50, 50, ALPHA)~

would define the caharacter A at data coordinates 50, 50.

Further, the statement

. CHAR (TALLY, 50, YVALUE, ALPHA(3/1}}~

would define the character C at the data coordinates indicated.

This latter example illustrates how a character may be plucked
out of the middle of a string for display.

Scissoring. In the last example, just above, it was

seen that the y coordinate was a variable. As such its value
could exceed the limits of the member rectangle through either
a programming error or through encountering some data that
were outside the limits anticipated. This situation can be
handled in a variety of ways. Experience has shown that the
most useful is to blank (i.e., not display) entities, or por-
tions of entities that fall outside the member rectangle.
This is scissoring. At the same time, it is necessary to pro-
vide some feedback to the user or programmer that scissoring
has occurred. This feedback is handled somewhat differently
for different entities.

766
 For the single character, scissoring is handled as
follows. If a character would fall outside the member rectangle
it is automatically moved by the system to the border of the
rectangle at the point closest to where it would have fallen.
In some cases this would be sufficient to inform the programmer
or user that scissoring had occurred. However, additional feed-
back can be provided by changing scissored characters to some
other, highly visible, character such as an asterisk. In this
way, any time an asterisk appeared on the screen it would be
evidence that scissoring had occurred.

This special character, called a limit character is

given by strexp2 in the above Form. Just as with strexpl, only
the first character is relevant. For example,

ALPHA = 'ABCD';

• CHAR (TALLY, 50, YVALUE, ALPHA('*'));

would cause the letter A to appear if the coordinates were

within the member rectangle, or the * to appear on the border
of the rectangle if it otherwise would have fallen outside.

Scissoring for lines is handled in a somewhat dif-

ferent fashion and will be discussed next under the .ENDPOINTS
construct •

• ENDPOINTS Construct

Purpose: Annotate the endpoints of a line and provide feedback

to user that a line has been scissored.

Form: CENDPOINTS 7.. (strexpl [strexP211

l
, strexp3
.EP .J [(strexp4i] i

Description and Example:

This construct allows the programmer to place a char-

acter at each endpoint of a line. When the ENDPOINTS construct
is used, it always pertains to the most recently defined line.
For this reason, it is not necessary to specify a member name
with this construct. In each of the string expressions shown
above, only the first character is pertinent as was the case
with the .CHARACTER construct.

Strexpl contains the character which will annotate

the first endpoint (reading from left to right in the .LINE

767
construct) of the line most recently defined. Strexp3 will
annotate the second endpoint of this line. If a portion of a
line would fall outside its member rectangle, only the portion
falling outside is scissored. In order to make this apparent
to the observer, the .ENDPOINTS construct is used; the character
marking the end of the line that was scissored is automatically
moved to the border of the member rectangle at its closest point
to where it would otherwise have fallen. Unless the scissored
line is horizontal or vertical or passes through a corner of
the rectangle, it will be apparent that the endpoint character
does not lie on the line and will serve notice that scissoring
has occurred.

This is illustrated in the following drawing showing

the member rectangle, the line (the scissored portion is shown
dotted), and where the endpoint characters would appear. Assume
that the pertinent .LINE and .ENDPOINTS constructs appear as
follows:

.LINE(MEMB, XLOW, YLOW, XHI, YHI);

• END PO INT S (' A, , 'B' ) ;

The display would appear:

B
./
,/

member
rectan-
gle
A

To provide greater visualization that a line has been scissored,

special characters can be used to substitute for the normal ones
when scissoring takes place. These special characters are the
first characters of strexp2 and strexp4 in the above Form.
Suppose that in the above illustration, the .ENDPOINTS construct
had appeared:
.ENDPOINTS ('A' ('*'), 'B' ('*'));

768
In this case, the display would be identical except for the fact
that in place of the B, an asterisk would appear. In other words,
strexpl and/or strexp3 are used when the endpoints are in bounds
and strexp2 and/or strexp4 when the endpoints are out of bounds.

If it is desired to display endpoint characters only

when a line has been scissored, the .ENDPOINTS construct could
appear:

.EP(' '('*'), , ('*'));

In the above examples, the characters to be displayed

were shown as single-character string literals in order to sim-
plify their appearance. However, it will be remembered that
fuey may be any valid string expression.

At this point the discussion of entities is complete.

It has been shown how to define members and their rectangles,
how to create lines, characters and text, and how to handle
scissoring. Repeatedly, it was emphasized that the .LINE,
.CHAR, and .TEXT constructs merely defined entities but did
not actually display them on the screen. The constructs to
follow control the actual display handling. They are .DISPLAY,
. FAMILY, and .DELETE .

. DISPLAY Construct

Purpose: Display previously defined entities.

Form:
l
(DISPLAY] •
.DP I

Description and Example:

It would have been possible to automatically display

each entity as it was defined. In many situations, however,
this automatic approach would be undesirable: each time an
entity is displayed, regeneration of the display is momentarily
suspended. Therefore, in a display containing many lines, such
as a chart or graph, the automatic method would cause the con-
sole to go blank repeatedly within a short time span. This is
disturbing to the user and requires additional elapsed time.
Therefore, the programmer was given the flexibility of display-
ing entities in groups or one at a time.

Each time an entity is defined, it is automatically

sent to a holding area. When the .DISPLAY construct is en-
countered, all entities in the holding area are sent to the

769
display and become visible to the user. A typical sequence of
instructions might appear:

DO I TO 100 BEGIN
.LINE(PROFITS, XLO(I), YLO(I), XHI(I), YHI(I))i
. CHAR (PROFITS, XLO(I), YLO(I), SALESMAN(I/l))i
EOOi
.DISPLAYi
.FAMILY Construct

Purpose: Group several members under a higher level name.

Form: . FAMILY
.FM (famname)i

Description and Example:

A family name is declared by the very simple form

shown above. Thereafter, all members defined by the .DEFINE
construct automatically belong to that family until a new
family name is declared by the .FAMILY construct. For example:

.FM(MANAGEMENT)i
.DF(PROFITS, XLO, YLO, XHI, YHI,*)i
.DF(COSTS, XLO, YLO, XHI, YHI, *);

.FM(ENGINEERING)i
.DF(STRUCTURES, Xl,Yl, X2, Y2, *)i
.DF(CIRCUITS, X3, Y3, X4, Y4, *)i

.FM(SALES)i
.DF(TERRITORIES, X5, Y5, X6, Y6, *)i
.DF(SALESMEN, X7, Y7, X8, Y8, *)i

shows that

members PROFITS and COSTS belong to family MANAGEMENT

members STRUCTURES and CIRCUITS belong to family
ENGINEERING
members TERRITORIES and SALESMEN belong to family SALES

The most recently declared family is called the active family.

All other families are inactive. An inactive family may be re-
activated by simply re-declaring its name in a .FAMILY construct

770
Inactive families are, nevertheless, displayed on the screen
until specifically deleted by the .DEFINE construct (next page).

This kind of hierarchial relationship is useful ln

display handling. For example, it permits the programmer to
quickly and conveniently blank out collections of related
entities which may have been built up one by one. This will
be more fully covered in the discussions of the .DELETE con-
struct, following .

• DELETE Construct

Purpose: Blank out families or members.

Form:
[ DELETE}
.DL
(FAMILY
[membl, memb2, ... membn
]
;

Description and Example:

The .DELETE construct can be used to blank out either

a family or several members. Only the active family (see
.FAMILY construct for definition) car. be deleted. Thus if one
wishes to delete an inactive family, it must be redeclared be-
fore the .DELETE construct is encountered. For example, suppose
that the family MANAGEMENT is active and it is desired to delete
the family SALES:

.FAMILY MANAGEMENT~

.FAMILY SALES;
.DELETE FAMILY;

Individual members or collections of members may be

deleted by specifying their names. The names deleted in a
single statement need not be active and need not belong to
the same family. Example:

.DELETE('CIRCUITS', 'TERRITORIES', 'COSTS');

The following groups of statements involve communica-

tion between the user and the program. Some of them are subsets
of the LB statement covered earlier in this section and will,
therefore, be described in a somewhat cursory fashion.

771
.SETKEYBOARD Construct

Purpose: Provide the user with an area on the screen where

typed-in information will appear.

Form: KEYBOARD} (strexp, xl, yl, intexp)

[ • SET.SK ~

Description and Example:

This construct performs two functions directed at

allowing the user to type data or commands into the system from
the alphanumeric keyboard.

First, the cursor is positioned at data coordinates

xl, yl. The cursor is a short horizontal underline that in-
dicates to the user where his typed-in characters will be dis-
played on the screen. The data coordinates are relative to
the last-defined entity.

Second, a string of text, given by strexp in the

above Form, is displayed beginning at xl, yl. These characters
will be overlayed as the user begins to enter information from
the keyboard. They will frequently be blank.

Intexp is an integer expression that specifies the

number of unprotected characters. Unprotected characters are
those that may be overlayed by information typed fram the key-
board. Characters that are protected cannot be overlayed. In
this way the programmer has control over the maximum number of
characters the user can enter from the keyboard. Of course,
fewer characters may be entered by simply signalling EOB (end
of block) from the keyboard.

Example:

DTEXT (' ENTER TIME TO COMPLET ION' ) ~

.SK('----DAYS TO COMPLETION', 50, 50, 3)~

In this example, the user is requested to type in a number. At

data coordinates 50, 50 he sees the following on the screen:

DAYS TO COMPLETION

As he types, the cursor moves along indicating the next avail-

able space, until the unprotected characters (3) have been ex-
hausted. After the user has typed 123, for example, the screen
would appear

123 DAYS TO COMPLETION

772
The cursor will not move into the protected region.
*KBWAIT construct and *KB Construct

Purpose: Retrieve information user has typed.

Form: strvar = *KBWAITj

strvar =g~YBOARD}
Description and Example:

Both of these built-in functions retrieve the informa-

tion the user has typed on the alphanumeric keyboard. The dif-
ference between them concerns timing. *KBWAIT stops the execu-
tion of the program and waits until the user has completed typ-
ing as indicated by the end-of-block signal from the keyboard.
*KB, on the other hand, simply retrieves the last complete mes-
sage regardless of when it was completed.

*KBWAIT might be used, for example, in a situation

where the path of the program was dependent upon the information
typed by the user and could not proceed without it:

BLANKS = 5Xj
DTEXT ('TYPE IN EMPLOYEE NUMBER')j
.SETKEYBOARD (BLANKS, 50, 50, 5)j
NUMB = *KBWAIT

*KB, on the other hand, is used when it is known that the

needed string has already been typed. This could occur for
example, if the string had previously been retrieved by a
*KBWAIT, or if a second action such as a function key activa-
tion were also required.

The string obtained through *KB or *KBWAIT need not

be entered into a string variable directly, as shown in the
above Form. As a function, it can undergo any valid type of
string manipulation:

ALPHA = *KB(2/2), CAT BETA(I/4)j

.LIGHTPEN Construct

Purpose: Allow user to make light pen picks.

Form: [LIGHTPEN 1
.LP .J;
773
Description and Example:

This construct allows light pen picks to be made by

the user. The program waits until a pick is made. The loca-
tion of the pick can be determined through the following con-
structs:

LPXPOS - The x coordinate in raster units

LPYPOS - The y coordinate in raster units
LPCPOS - The character position
LPLPOS - The line position
LBNUM - The light button number

It is suggested that the LB statement, earlier in this section,

be consulted for a complete description of these constructs.

774
ON THE APPLICATION OF GRAPH THEORY
TO COMPUTER DATA STRUCTURES

R. Williams

Dept. of Electrical Engineering, School of Engineering

& Science, New York University, University Heights,
Bronx, N.:Y. 10453, U.S.A.

ABSTRACT

This paper deals with computer data structures. These data struc-
tures can be represented by directed graph structures and the purpose of this
paper is to show how methods and techniques of graph theory can then be used
to process these graphs. A viewpoint is taken that a basic tree structure
exists in a general data structure. If this tree structure can be extracted,
or identified during the creation of the data structure, then it can be used
to make comparisons with other basic tree structures. An algorithm to find
the greatest cornmon structure of two trees is presented. If a cost function
is associated with the arcs of a graph structure, then a minimum cost tree
can be derived. This has application in minimizing data retrieval times and
in minimizing page swapping in data structure paging systems. Arbitrary re-
lations among data can also be represented by a graph and its matrices. It
is shown that, by means of standard operations on these matrices, operations
can be performed on these relations to derive further relations and logical
data associations. A general model builder system, with which some of the
above ideas will be investigated, is briefly mentioned.

I. INTRODUCTION

Data consists of numerical values, names, codes and symbols. Each

of these things, considered separately, is called a data item or a data
element. Data items are stored in computer memories in an organized manner
to preserve relationships and logical associations that exist among them.

*This work was supported by the Air Force Office of Scientific Research,
Directorate of Information Sciences, AFOSR Grant AF-AFOSR-68-l367 and
the National Science Foundation Grant GJ-19.

775
 This organization of data is called a data structure. One of the most im-
portant considerations in any large computer graphics application is the de-
sign of the problem data structure. In graphical applications a data struc-
ture also includes the pictorial information that is used for displaying line
drawings.

There exists little theory to which one may turn for help when de-
signing a data structure. Most data structures are based upon a few simple
calculations and some educated guesses. It is the purpose of this paper to
show how the application of graph theory can be a useful tool in some aspects
of data structure design. Although at first it may seem that this work is
not application oriented, it does have practical significance.

II. THE REPRESENTATION OF DATA STRUCTURES AS GRAPHS

A. Preliminary definitions and terms used in graph theory:

First some definitions are given l ,2

A graph consists of a non-empty set V, and a mapping ~ of V into V.

The elements of V are called vertices or nodes, and given two vertices x, y
€ V, if vertex x maps into vertex y, then y € ~ x, and the pair (x,y) is
called an~. We can represent the graph geometrically, by letting the
elements of V be points in the plane, and by drawing arcs between the ver-
tices to represent the mapping of V into V. An example of a graph is shown
in Figure 1. This kind of graph is called a directed graph because a direc-
tion is assigned to the arcs. A graph in which no direction is assigned to
the arcs is called an undirected graph or simply a graph. An undirected arc
is called an edge, and if x and yare the end points of an edge then the
mappings exist in both directions from x into y and from y into x. The num-
ber of edges meeting at a node is called the degree, 0, of the node. In the
directed graph, the mapping only exists in the direction of the arc, and the
number of arcs entering or leaving a node is called the negative degree 0-
or the positive degree 0+ of the node, respectively.

A convenient way to represent a graph is in the form of matrices.

A graph may be described by a matrix in several different ways. The inci-
dence matrix and the adjacency matrix are the most useful. The incidence
matrix for a graph G is an n x m matrix where the rows correspond to the n
vertices and columns to the m edges. The matrix element aij is 1 if the
j-th edge or arc pOints to the i-th vertex but is 0 otherwise. An example
is shown in Figure 2. The adjacency matrix is an n x n matrix in which the
rows and columns correspond to the n vertices and the element aij is 1 if
there is an arc directed from i to j, otherwise aij = O. If an edge exists
in an undirected graph between vertices i and j then both a .. = land aji= 1.
An example of this matrix is also shown in Figure 2. 1J

776
 A

Figure 1: A Directed Graph

c
B D

a) A directed graph

El E E E4 A B C D
2 3

A 0 0 0 0 A 0 1 1 0

B 1 1 0 0 B 0 0 0 0

C 0 0 1 0 C 0 1 0 ]

D 0 0 0 1 D 0 0 0 0

b) The incidence matrix. c) The adjacency, vertex or

connection matrix.
Figure 2 : A Directed Graph and Two of its Matrices

777
 B. Data structures as graphs:
The most commonly used data structures are hierarchical-ring struc-
tures and tree, list structures. A list is a collection of data or blocks
of contiguous data connected together by pointers, as shown in Figure 3a.
A pointer is a means of linking the items together and may be simply an ad-
dress or a tabulated name tag. If the data items or blocks are represented
by nodes and the pointers by arcs, then a list may be represented by the
directed graph structure sho~n in Figure 3b. If the last item of a list
points to the first then a closed list, called a ring, is formed. This is
represented by a circuit (sometimes called a cycle) in a directed graph, as
shown in Figure 4. Additional pointers may be added to the ring structure
to create a linkaging in the reverse direction or to link every element to
the head element. These pointers are then represented by additional, cor-
responding arcs in the graph.

A structure like the one illustrated together with its graph

representation in Figure 5, is called a tree. Formally, any undirected
graph structure is said to be a tree if it is connected and has no circuits.
A directed graph is a directed tree if it forms a tree in the undirected
sense and if there exists a path from the head (root) of the directed tree
to every other node. A list is, therefore, a special case of a tree.

An hierarchical structure is a similar structure with levels of

hierarchy but it is constructed from ring structures. From an initial,
highest level ring, there are links to other logically related elements.
These related elements are also arranged in a ring structure, and links
from these elements to other elements can exist. These other elements are
contained in ring structures and so on.

An hierarchical structure corresponds to a general directed graph

which does have circuits. An example of an hierarchical structure and its
graph is shown in Figures 6 and 7. A tree is seen to be a special case of
a hierarchical structure.

III. THE BASIC TREE STRUCTURE OF A GENERAL STRUCTURE

A. Explanation of viewpoint:
. /
Very few useful results can be obta1ned from a general graph to
assist in the design of data structures. Somewhat more could be obtained
from tree structures. However, in any general graph with only a few nodes
(say 20), in which every node is connected to every other node, there are a
prohibitively large number of possible trees. Typical hierarchical struc-
tures used in computer graphics applications have many nodes (hundreds or
even thousands), and the total number of possible trees is extremely large.
Clearly, to be able to make reasonable computations, the number of trees to
be considered must be limited to a small number.

778
 · .......... . - .....,-----,
N

a) A single list

.. A
..
B
.................... . ---....
N

b) The graph of the list in (a)

Figure 3: A List Structure and its Graph Representation

l .. · . .. .. .. .. .. .. .. ..
·.
j
A B N

a) A two -way ring structure

B

b) The graph of the ring in (a)

Figure 4: A Ring Structure and its Graph Representation

779
 A

r--

r .
B l- e

...
~
r-

~ .... ~

-- ,- 0 ~
E ,.. F
~
r-;::: G H
l-

a) A tree structure

b) The graph of the tree in (a)

Figure 5: A Tree Structure and its Graph Representation

780
 A B

a) A line drawing design

c. ~

- TR! 11 DF CF

-- In E S 1
~ [
-- SO 1 AB
rill

IH~
f-
~

cn
I--

nR
~

--
.. TRI
2 __

J
BE CE
-

b) A possible structure to reprcsent tho design

i n (a). b a c k war dan dot her poi n t c r S 0 mitt e d
for clarity).

Figure 6: An Hierarchial Structure

781
 A B
,.....--.......

D ft---~r DES 1

F TRI 1 2
a) A line drawing
design

CF.-____~~------~~----~~

b) A graph representation

Figure 7: The Graph of the Hierarchial Structure

®
R

Use of an element

o
c
An element definitiol

• • sc ~ Use of a previous
definition

-( T D Definition of an
image or
node.

Figure 8: Building Elements and Model Building Symbols

782
 In computer data structures, however, there are certain regularities
of structure and an implied hierarchical ordering of structures. By making
use of these things, particular tree structures can be considered.

The viewpoint is taken that inherent in a general data structure

there is one or, at most, a small number of basic tree structures. Currentl~
this is a heuristic since no rigid proof can be offered. The tree form may
be seen from the manner in which a large data structure is systematically
constructed. Consider building a data structure model for a cascaded ampli-
fier with several identical stages. In a graphical environment, a designer
could begin by defining building elements, these would be the electronic com-
ponents that can occur in his circuit; i.e. resistor R, capacitor C, tran-
sistor T, short-circuit connection SC etc. as shown in Figure 8. Next, he
could define an amplifier stage in terms of uses or transformations, of these
elements. This is shown in Figure 9. The use of an element means assigning
to it a position, an orientation, a scale factor, possibly a name, and in
this case, a value. Then having constructed one complete stage, a multistage
amplifier could be defined in terms of many uses of the amplifier stage,
Figure 10. The designer can obviously go further and embed the multistage
amplifier into a larger system, and so on. This design process may be repre-
sented by the basic tree structure shown in Figure 11.

Of course, in practice the circuit is represented by a general di-

rected structure, probably a hierarchical ring structure, in the computer
memory. Not only that, but other data relations may have been created in
the model; for example all uses of a resistor symbol or all capacitors of the
same value may be associated in a ring structure etc., so that there is a lot
of additional structure on top of the basic tree. The problem is to extract
the tree from this general structure.

B. A method to define the basic tree:

The classical method of extracting a tree from a graph is to scan
the graph marking the arcs one by one and deleting all those that complete
a circuit with previously marked arcs. A circuit is formed when a node is
visited for a second time in the forward scanning process. By definition
the retained arcs form a tree because there are no circuits in this new
graph. This process yields different trees, even when starting from the
same node, if the original graph is rearranged. Consequently, this method
is not suitable for extracting a tree from a general data structure.

The following approach is suggested. A data structure may be con-

sidered as consisting of two general forms; essential structure and addi-
tional structure. Essential structure is that structure which is used for
defining nodes in terms of uses of other previously-defined nodes and ele-
ments. Additional structure is that structure which is used to link to-
gether nodes in association groups and data sets. Appreciating this dif-
ference beforehand, a graphical structuring system could be designed so that
the pointers in the essential structure are flagged during the creation of
a data structure model.

7~
 SCI SC3

R1

SC4

-L SC 6 SC5
SC7

R2
C2

SC8 SC9 SC10 SC 11

a) An amplifier stage

Amplifier stage

C T SC

b) R ~'p res e n tat ion 0 fan amp l if i e r s tag e

Figure 9: An Amplifier Stage and its Model Structure

784
 Amplifier

t--~ •...•...

Stage I Stage N

Definition of an amplifier
stage

Figure 10: A multistage amplifier model structure

Stage 1 Stage N
• •

R T

RI R4 C I C2 SCI SC12 T

Figure ll: A Basic Tree Structure for the Multistage Amplifier

785
 The essential structure itself is made up of ring structures if
nodes are the headers of rings of other node and element uses. But each
ring has a header which is known by its header identification code, and it
can be reduced to a list by marking (flagging) all the forward pointers
around the ring except that from the last element back to the header. Thus
an essential structure can be converted to a list structure.

Of course, a node or element can be used many times in the defini-

tion of other nodes and may lie on several lists. This presents no problem
because if, instead of using one node several times, several copies of this
node and its attendant structure had been created, then one copy could have
been put on each list that used it. Also, the structure obtained by con-
sidering only the marked pointers of the essential structur~ would then be
a directed tree structure. The reason for making multiple use of a node and
its structure is to conserve memory space. This computer, structural
form may be thoughtof as a compact, directed tree structure.

There are many useful things that can be computed from the basic
trees of model structures. Comparisons can be made between two basic trees
to find their largest common structure. This has application in network
topology, for example, and in linguistic pattern recognition schemes. The
more general case of comparing two graphs, not trees, occurs in comparing
the structure of chemical molecules to find common substructures. Numerical
values derived from cost functions can be associated with the arcs of the
tree and used to control operations on the structure. For example, if these
values represent retrieval times from node to node the tree can be segmented
into pieces, depending upon these values, in such a way that the time taken
to retrieve information from the model can be minimized. This has applica-
tion in paging of a model structure. Other results, such as the number of
elements or terminal nodes in a node definition, or whether a node defini-
tion is contained in another node definition can be determined directly from
the basic tree. It would be much harder to determine these things from the
general model.

From the general model graph it is also possible to determine a

tree of the shortest paths from one node to any other, or a path of minimum
length which connects all nodes l ,2. What is actually useful in a given
situation depends of course upon the application.

There follows some more detailed discussion of some of the ideas

mentioned above.

c. A tree coding sequence:

In order to be able to process compact tree structures, it is neces-
sary to describe them in a different way. A representative code sequence
starting at the root of the tree, the top node,can be computed for the tree.
Then the following algorithm will generate a representative sequence for a
tree structure:
1. Write the name of the top node, this node becomes the current node.
 2. Write 0+ for the current node.
3. If the current node points to other nodes along an arc not yet
marked, write the name of the leftmost node pointed to, mark the
arc to indicate the new node has now been used and make the new
node the current node; otherwise go to 5.
4. If the current node points to other nodes, go to step 2, otherwise
go to 6.
5. Test i f the current node is the root node, i f so stop, otherwise
go to 6.
6. Back up one node by setting the current node to the previous node
for -which 0+ > 1 in the sequence so far generated, then go to step 3.

A typical tree structure and its code sequence is shown in Figure 12.

The tree sequence can be standardized by ordering the tree so that

the "leftmost" node means taking the node of highest positive degree, 0+,
from among those to which the current node points. If two or more nodes are
of the same order than take the node which points to nodes of the next level
whose 0+ sum is the greater. If these values are also equal consider the
nex~ level in the tree etc., but i f this process continues to the terminal
nodes of the tree and still the 0+ sums are equal, then take the nodes in
any arbitrary order.

The above process will assign a unique structural representation

code to a tree structure. As an example of the use of these sequences, con-
sider the comparison of two tree structures to find their largest common
structural parts. In the example algorithm that follows, the comparison is
made between structures only and node names and characteristics are ignored.
Therefore the code sequence can be more simply written with blanks instead
of node names as shown later in Figure 15. In a situation where the node
name or type is important, this can easily be included in the algorithm.

D. An algorithm to find the largest common structure of two trees:

A node in a tree is defined by the other nodes and tree structure to
which it points. Consequently, if two nodes in different tree structures
are to be the same, their attendant tree structures must be the same and the
two structures are said to be common. Therefore, in Figure 13, we consider
the two substructures circled as common, but in Figure 14 the substructures
circled are not common. For other applications in which a common substruc-
ture is defined differently the algorithm can be suitably modified. The
algorithm is as follows:
1. For the two tree structures to be compared, form the ordered se-
quence code as explained above. Let T1 be the longer sequence;
T2 the other.
2. Start at the beginning (leftmost end) of each sequence. If T1 is
longer than T2, go to step 4), if Tl is shorter than T2, go to

787
 A

DE FH I L M

a) A tree structure

A 2 B 4 C 3 D E F G 2 H I K 2 L M J N 2 0 P

b) The coding sequence for the tree

Fig u r e 12: A T r e e Structure and its Co ding Seq u e nee

;'

I
\
I
I
I
t I

I I

,, ..... ~
,
~
... .-
...
... - - ... " '"
LARGEST COMMON
STRUCTURE .... '"

Figure 13: Two Trees with Common Structure.

788
 B.!L't. COMMON
,. ... "
" ~-~
, "
, "
, , I ",
I
,
\

. I

"

Figure 14: Two Trees with Structure Not Considered Common.

~
 step 5). Otherwise go to step 3).
3. Compare the next code element in Tl with the next code element in
T2. If they match and this is the last element in T2 and also the
last element in Tl, got to step 8). If they match and it is not
the last element in Tl or in T2 repeat step 3). Otherwise go to
step 4).
4. Remove the leftmost node from Tl. This forms several subtrees in
Tl. Mark the first of these and call it Tl. If Tl is empty go to
step 5). Otherwise go to step 2).
5. If there are any subtrees left in the original Tl sequence, let Tl
be the next subtree not yet marked, mark it and go to step 2).
Otherwise go to step 6).
6. Reset ~l to the original full sequence. Remove the leftmost node
from T2. This forms several subtrees in T2. Mark the first of
these and call it T2. If T2 is empty go to step 7). Otherwise
go to step 2).
7. If there are any subtrees left in the original T2 sequence, let T2
be the next subtree not yet marked, mark it and go to step 2).
Otherwise stop.
8. Save this structure as a matched equal substructure.

Applying this algorithm to the two trees shown in Figure 15, it is

found that C3DEF and C3GHI are the largest common substructures.

E. Associating a cost function with the arcs of a graph:

As mentioned above another useful technique from graph theory in-
volves assigning a cost function to a directed structure to obtain a minimum
cost tree relative to its root. A numerical value is assigned to each arc
of the graph. This value may represent any kind of relation between the
nodes of the graph. We assume that the values associated with the arcs are
additive, so that if a value Cij is associated with an arc from node i to
node j, then for nodes i,j and k, Cij + Cjk ~ Cik , where Cik is the total
cost of going from node i to node k.

F. The minimum cost tree:

A minimum cost tree relative to a root a is defined as a directed
tree rooted at a, such that the unique path from node a to any other node n,
is the path of least total cost Can. It can be shown (see Appendix A) that
in a directed graph G, a tree T, rooted at a, and containing all vertices
reachable from a, is a minimum cost tree if and only if, for every arc (i,j)
in T:

where C denotes a total cost along many arcs and c denotes an arc cost.
This result yields a simple algorithm for finding a minimum cost
700
 o p

DE FHI LM

A 2 B 4 C 3 D E F G 2 H IK2L M.J N 20 P

2 - 4 - 3 - - - - 2 - - ---2 - - 2 - -

a) Tree Tl

K L

A2B3J2KLEFC3GHID2MN

- 2 - 3 - 2 - 3- ---2-

b) Tree T2

Figure i5: Example Trees to Illustrate the Common Structure

Algorithm.

791
tree in any structure. First we form any spanning tree by removing all arcs
that complete circuits in the graph. 2 ,3Then the process is to consider each
node in order from top to bottom and left to right, to see whether a lower
cost path to that node can be obtained by traversing an arc of the original
graph but which is not in the spanning tree. If such an arc is found it is
substituted for the arc that currently points to this node. This process is
made clearer by the example shown in Figure 16. This figure shows: an orig-
inal graph with numerical cost values next to the arcs, a spanning tree and
the minimum cost tree. The dotted lines added to the spanning tree indicate
arcs that should be in the minimum cost tree. First consider node AI, the
shortest route to this node is via arc Ao to Al and has a cost of 2. Now
consider node A2. In the spanning tree the cost from Ao to A2 is 2 + 2 = 4.
But the arc Ao to A2 directly, only costs 3. Therefore remove the arc from
Al to A2 and substitute the arc from Ao to A2. This process can be repeated
over the whole graph to obtain the minimum cost graph.

If the cost associated with the graph is a function of retrieval

time and probability of access, the minimum cost tree represents a structure
with a minimum average searching time given that one always starts the
searching at the root of the tree.

G. An application to a paging scheme:

A similar application using a tree with a cost function, is to
paging. This is most easily demonstrated by means of an example. Suppose
in a particular case there are six pages, and only three pages can be held
in the fast core memory at one time. Graphs can be created with page num-
bers as nodes and with cost functions (weights) assigned to the arcs. The
weights are a function of the relative number and the probability of use,
of cross references from one page to another. The weights are normalized;
a weight value of one between two pages is a constraint which means that the
page pointed to is absolutely necessary when the other page is in core.
Suppose page PI is currently in core memory as a result of a calIon it.
The problem is to determine which other pages are best put into core with
Pl. The graph for PI is shown in Figure 17.

The weights for all the other pages relative to PI are calculated
by mUltiplying together the weights along the path(s) from PI to these
pages. If two or more paths exist from PI to any other page, the condi-
tional weights are all kept. In this example wl5 = 0.57 if P2 is selected
or 0.2 if P4 is selected. Now put into core with PI the two pages with the
two highest weighting factors, taking the conditional constraints into ac-
count. This results in PI, P2 and P5 being selected.

The method outlined above could be made dynamic if the weights

were based upon statistics collected during the running of the program, and
i f they were adjusted as the statistics varied. Also the method could be
extended to a lower level of structure, to the nodes and their interconnec-
tions. Optimum clusterings of nodes can be derived and arbitrary data
structures could be segmented into pages according to the above criterion.

792
 a) A graph with a cost function

b) A spanning tree for the graph in (a)

A5
c) The minimum cost tree for the graph in (a)

Figure 16: The Construction of a Minimum Cost Tree.

793
 Result:
w 1 ;3- (0.7)(O.57)zO.4

w 12 - 0.57
w I4 =0.28
w 1S - (0.57)(1)=0.57 with P2
(0.28)(0.7) ~ 0.2
with P 4

w 16 = (0.28)(1)=0.28

Constraints:
If P 2 -fJ' P5

If P 4 -+ P6

Choose PI • P 2 , P
5
Figure 17: One of the Graphs Used in a Paging Scheme.

A B C D E F
P:
A 1 1 0 0 0 0

B 1 1 0 0 1 0

C 0 0 1 0 0 1

D 0 0 0 1 0 0
a) A simple geom etr ic figure
E 0 1 0 0 1 0

F 0 0 1 0 0 1

b) A matrix representation fo
th e parallel relation in (a)

Is A parallel to E ?

[p1>C(pAJ T = (110010J ______ (repeat u nti I. no change)

Figure L8: A Graph and its Parallel Matrix Representation

794
The problem is alleviated somewhat by the fixed constraints, since this re-
duces the number of nodes that can be placed in more than one page. Pre-
sumably this would only be done for a finished, fixed data structure or at
least for completed pieces of it. It is a frightening thought to consider
making such a low-level scheme dynamic.

IV. DATA STRUCTURE RELATIONS AND RELATIONAL OPERATIONS

A. Definition and matrix representation of a relation:

An important use of data structures is to store relations among
data, i.e. to form logical associations among data items, and also to pro-
vide a means of performing operations on these data relations to derive new
relations. Abstractly a relation is defined on a set A if for each ordered
pair of elements (a,b) of A, a ~ b is meaningful and is either true or
false.

Arbitrary relations between blocks may be defined. For example if

blocks represent picture items in a certain application, then these picture
elements may be said to be "connected", i.e. share a common line or point,
or some may be "inside" or "overlapping" other picture items. Each rela-
tion may be represented by a matrix in which the rows and columns are iden-
tified by the names of the blocks. Let a matrix M be created with elements
mij. If the relation of block i to block j is true then mij = 1. If the
relation holds for block j with respect to block i then mji = 1 also. If
mij = mji everywhere in M the relation is symmetric. If the relation does
not hold for block i with respect to block j then mij = O. Thus the rela-
tion between two blocks may hold in both directions, in one direction or it
may not hold at all.

Even though data may be stored in list or ring structures, a one to

one correspondence can be set up between data interconnections and matrix
elements, since graphs may be represented by matrices. Operations described
on a matrix can then be applied to the original graph.

B. Operations with relations:

Relation matrices can be manipulated to give answers to questions
about other relations that exist between elements of the data structure.
For example let a relation parallel be created to specify whether certain
lines in a picture are parallel to other items or not. Specifically consi-
der Figure 18 and the parallel relation matrix P, in which A is specified
as parallel to B, B to E, and C to F.

Since the parallel relation is transitive clearly A should be par-

allel to E. To see if this is so, multiply P by row A transposed (or
column A in this symmetrical case) to find what items are parallel to A.
This also finds all items one level of transitivity re~oved, which are par-
allel to other items, (B in this case) that are already specjfied as paral-

795
 P: ABC D E F
A l l 0 000
B 110 0 1 0
COO 1 001
D 0 0 0 100
E 0 100 1 0
F 0 0 100 1

leI to A. The question could be posed as

? + [pA]T x[P]

where [pA] means row A of matrix P. The result is: [110010], which means
that A is parallel to A, Band E. This operation is repeated until there
is no further change in the result which means that all items parallel to A
and any number of transition levels removed,have been determined.

By creating other relations,logical questions about many relations

may be asked. Let the second relation be the connected-to relation. Then
one may ask if a line is connected-to and parallel to another line. By
considering more lines, complicated logical questions such as, "Is line A
parallel to line C and connected-to line B and not connected-to line D?"
could be answered. Consider the example figure of a parallelogram shown in
Figure 19. The"parallel" matrix is
P: ABC D

A 1 0 1 0
B 0 1 0 1
C 1 0 1 0
DOl 0 1

The "connected-to" matrix is

ABC D
C: A 110 1
B 111 0
COllI
D 1 0 1 0

and the question may be represented logically as

796
 A

c
a) A parallelogram.

A B c D
c: A B c D
P:
A 1 o 1 o A 1 1 o 1

B o 1 o 1 B 1 1 1 o
c 1 o 1 o c o 1 1

D o 1 o 1 D 1 o 1 1

b) Matrix representations for the parallel and connected-to

relations in (a).

"Is line A parallel to line C and connected-to lineB

and not connected-to line D ?11
? ....,flp) X (p A) Tlc n(C A 1Bn{c A ] 0
? -[1010Jcfl(1101]Bn(1l:1~1]D

? -1(\1(\1'

? - 0

Figure 19: An .Example to Illustrate Relational Operations

797
 The first term is the same as in the previous example and finds all
lines parallel to A. The subscript C means take column C only; it is only
one element and indicates whether C is parallel to A or not. The second and
third terms use row A of the connected-to matrix, and determine whether B
and D are connected to A. The logical expression then determines the over-
all combined result. This gives
? + [lOlOlC l'\ [HOll B n [HOll D

?+1"1 () 1

? + 0

and the result is not true.

Relations may have one or more of the following properties:

a) reflexive a 'V a
b) symmetric a 'V b implies b 'V a
c) transitive a 'V band b 'V C implies a 'V c.

A relation having all three properties is called an equivalence relation.

Parallel (as used above) is an equivalence relation, but connected-to (as
used above) is not since property c) does not hold. Some relations may not
even be reflexive. The inside relation is an example, since a picture item
cannot be inside itself.

If relation matrices are created and stored as indicated above, it

helps to know if a relation is symmetric (because corresponding rows and
columns are identical and this makes it easier to perform some calculations~
It is necessary to know if a relation is transitive because this directly
affects the validity of relational calculations. For example consider the
parallel relation. If the following are all true, that A is parallel to B,
C and D; that B is parallel to E and F; that C is parallel to E, and that D
is parallel to G; then A is parallel to all B, C, D, E, F and G, because
parallel is a transitive relation. This fact is calculated from the paral-
lel relation matrix by multiplying the parallel matrix by its row A trans-
posed replacing row A by the result and repeating until there is no further
change in the result. This finds not only all lines already specified as
parallel to A, but also all other lines parallel to those specified; all of
which are parallel to A. Now consider that line A is connected-to lines B
and C and that B is connected to D and C to E. Connected-to in this in-
stance means that two lines have at least one common point. It does not
follow that A is connected to any lines other than Band C because this
property is not transitive. Therefore row A immediately indicates the lines
to which A is connected. The connected-to and parallel matrices therefore
must be treated differently. In general, relations having different pro-
perties must be treated in different ways.

798
V. A GENERAL MODEL BUILDER SYSTEM

The author is designing and programming a general model builder sys-

tem for creating data structure models. The basic concept is to create a
system, which can be run on any sufficiently powerful computer system, to
enable designers to create arbitrary data structures. The concept is il-
lustrated in Figure 2,0. The description of the computer will be used as an
initial input to the model builder system and the output will be a system
which the designer can then use interpretively to build data structures.
The general system will be written in a higher level language but for effi-
ciency several service routines will have to be written for the particular
machine on which the system is to be run. The most important of these is a
paging system, wnich, although controlled by the general system, must be
implemented at the assembly language level.

The system is being implemented initially on an Adage AGT30. Once

this has been completed, it is planned to tryout some of the ideas men-
tioned in the previous sections of this paper.

A specific
machine
description

The General Model

Builder System
.. A specific
model builder
system
.. A data
structure model

f
Designer's
inputs

Figure 20: The General Model Builder Concept.

799
VI. CONCLUSIONS

In this paper the application of some graph theory methods to data

structures has been described. Although little can be achieved with very
general structures, at present anyway, it was shown that if a basic tree
structure can be extracted from a general structure, several interesting
possibilities emerge. Tree structures can be represented by a coding se-
quence and the common structure contained in two structures can be computed.
If a cost function is associated with the arcs of the structure, minimum
cost trees can be derived. This has application in information retrieval,
in paging algorithms for data structures,in segmenting data structures, and
elsewhere. Relations among data may be represented by graph matrices and
operations on these relations can be performed by using standard matrix
(Boolean) algebra. Several simple examples are given throughout -the paper.

It is hoped that this paper may motivate some readers to look

further into the use of graph theory or to consider how to apply some other
theory, in the design and study of data structures.

ACKNOWLEDGMENT

I am happy to acknowledge the encouragement and guidance I have

received from Professor H. Freeman of New York University.

REFERENCES

1. Berge, C., "The Theory of Graphs", translated into English by Alison

Doig, 1962; Methuen and Co. Ltd., London; John Wiley and Sons, Inc.
New York. Original in French, 1958, Dunod; Paris.
2. Busaker, R.G., Saaty, T.L., "Finite Graphs and Networks, An Introduction
with Applications", McGraw-Hill, New York, 1965.
3. McIlroy, M.D., "Algorithm A354 - Generator of Spanning Trees", Comms.
ACM., Vol. 12, No.9, September 1969, p. 511.
4. McGee, W., "File Structures for Generalized Data Management", Proc.
IFIP, Booklet F, August 1968, pp. 68-73.
5. Childs, D.L., "Description of a Set-Theoretic Data Structure", Proc.
FJCC, Vol. 33, Part I, 1968, pp. 557-564.

800
IX. APPENDIX A

This proof is adapted from the similar one in reference 2. In a

directed graph G, a tree T, rooted at a, and containing all vertices reach-
able from a, is a minimum cost tree, if and only if, for every arc (i,j)
in T:
C • < C • + c ..
aJ - a1. 1.J

where C . denotes a total cost from a to j along many arcs and Cij denotes
cost f rom 1.. to J.
an arc al .

Proof:
a) If C . > C . + c .. then clearly C . is not a minimum cost path.
aJ a1. 1.J aJ
b) Suppose T is not a minimum cost tree; and suppose n is a node where
C is not minimal. Let Pan be the minimum cost path from a to n. Let
(r~j) be the first arc in G but not in T on path Pan. Since Pan is a mini-
mum cost path from a to n, then Pak is the minimum cost path from a to k for
and node k on the path. This is so because if there exists a lower cost
path P~k then P~k + Pkn would be a lower cost path from a to n than Pan and
by hypothesis, this is not so.
The cost along path Pai is Cai.
By assumption Caj in T > Caj in G (not in T).
But Caj in G = Cai + Cij
arc (i,j) satisfies Caj > Cai + Cij

This means that if T is not a m1.n1.mum cost tree, an arc exists that
satisfies the above relation. Therefore T is a minimum cost tree only is
there is no arc satisfying the relation

Caj > C + c ..
ai 1.J

or i f every arc (i,j) satisfies

C < C + c ..•
aj ai 1.J

801
 DESIGN OF SOFTWARE AND FORMATS
FOR INTERACTIVE GRAPHICS SUPPORT

L. J. Schaefer

Adage Inc., 1079 Commonwealth Avenue, Boston,

Massachusetts 02215, U.S.A.

INTRODUCTION

This presentation will describe an environment for a user of interactive

graphics applications. Then a set of programmatic facilities for building graphics
applications will be outlined. 1 Those facilities for representing and processing
structures pertinent to graphics will be covered in greater detail. Some of the
design criteria and considerations affecting the chosen structures and their formats
will be given. 2

SOFTWARE SUPPORT TOOLS

Effective "end-user" deployment of an interactive graphics system requires an

extensive development of the users' application software system.
These software packages incorporate extensive processing and modeling rou-
tines and their supporting programmatic data structures. These packages and their
interfaces to user models, programs or on-line behavior, must be sensitive to
any generated inputs and affect resulting outputs within controllable real-time
constraints.

1Other sections are covering graphics applications, here we will not cover any
applications but will deal with standard software supplied as tools by means of
which applications may be developed.
2 Althoughthe design effort is presented as though predicated by defined hardware
environment characteristics, there was iteration between hardware and software
design, especially in arriving at the required transformation for the final image
representation.

803
 System programs have been developed to provide standard formats and calling
sequences to interface with all display facilities and on-line peripherals. Thus,
most major application systems and supporting user procedures or data can be
developed by traditional programming methods and techniques.
Therefore, the development of all ordinary programming support facilities
was required. This included macro-assembler and compiler for specifying pro-
cedural descriptions or routines for generating data and models, operating systems
with program preparation aids, loaders, debuggers, utilities for library and file
handling, and on-line interactive user-statement monitor for overall system control.
These traditional software support facilities have been revised to support
interactive on-line user, and extended to support the graphics capabilities as will
be described later.
The extended system support for graphics has been made available to the user
or application writer through three additional system packages: the DSPLY Oper-
ator for assembly language users (Ref.4), the AFDSP Package for FORTRAN users
(Ref. 6), and the BUILD Operator (Ref. 5) for on-line interactive modification of
visual descriptions associated with the users' model or data.

INTERA CTIVE ENVIRONMENT

The most serious constraint upon software developed for interactive use is
one of performance. It is encountered when trying to effect desired responses to
on-line user actions within tolerable response times.
A software system cannot provide for interactive use if it fails either to imple-
ment the facilities desired by an on-line user or if, in using them, they incur delays
in responding which exceed the patience of the user. Both of these failings can dis-
tract the user, disrupting the train of thought which the on-line interactive dialogue
is supposed to encourage and explOit.

Therefore, implementation of an interactive graphics system will entail not

only implementing the desired facilities, but constraining their execution time to
controllable real-time limits.
In general, this implementation will preclude implementing, as interactive
tools, many facilities whose execution time increases exceSSively with data values
of structural complexity.
The primary design constraint imposed by the interactive environment is that
of having implementations of desired on-line graphics facilities affect their changes
with a minimum of processing demands.

804
HARDWARE IMAGE PROCESSING

The software design discussed in this paper was carried out for a line of
graphics terminals with local processor manufactured by Adage, Inc. of Boston,
Massachusetts, U. S. A. This system has been described more extensively in the
paper by T. Hagan, et aI, (Ref. 3). A survey of the software which resulted from
the design has also been presented by A. VanDam and R. D. Bergeron (Ref. 2).
The unique transformational facilities characterizing this terminal were first
proposed in the 1966 SJCC by T. Hagan and R. Trieber (Ref. 1).
The following sections discuss some of this material from a functional view-
point as pertinent to software.

Visual Elements
The display function of the graphics terminal is realized by processing data
in its core storage. This data, in the general case, described three-dimensional
visual images. The processing of these image descriptions displays a two-
dimensional picture on the CRT.
Visual concepts to be described as images for display processing must be
abstracted into compositions of basic visual elements which the terminal can gener-
ate. The visual elements which can be generated are points; shaded, blanked, or
dashed lines; strokes; and strings of text characters.
The character string positions, points, strokes, and lines are specified by
coordinate positions. Lines and strokes, whtch require two points for definition,
are defined from the previous coordinate position to the current one. Each position
is specified as a three-dimensional point with coordinate values x, y, and z in a
right-hand coordinate system.
The range of coordinate values in each dimension may be considered normal-
ized in the range + 1 through -1. USing "DRA W (x, y, z)" to specify a displayed line
and "MOVE (x,y, z)" to represent a blanked (not visible) line, the following list
constitutes a definition to the image in the 3D space shown in Figure 1.

MOVE (0, 0, 1)
DRAW (1, 0, 0)
{l}
" (0, 1, 0)
" (0, 0, 1)

Absolute vs. Relative Coordinates

The term relative or incremental coordinates refers to the specification of
positions in the coordinate space by the difference in their absolute coordinates.

805
 For example, the image in Figure 1 would be described by incremental draws
as follows:
MOVE ABS (0, 0, 1)
DRA W REL (+1, 0, -1)
[ 2}
" " (-1, +1, 0)

" " (0, -1,+1)

The use of incremental coordinate specification on earlier systems has been

used to realize advantages:

1. More efficient packing of data for specifying short lines. This saves core
and increases the performance by drawing more vectors with fewer
accesses to core.
2. Ability to effect translation of relatively defined image segments. By
varying the initial absolute positioning item, all immediately following
relative items may be displaced. This method of effecting desired transla-
tions increases performance by relieving the processor of the computation
load required to recompute all coordinates of the translated segment. For
example, the image in Figure 1 can be displaced in the -x direction to the
position shown in Figure 2, which is described as follows:

MOVE ABS (-1, 0, 1)

DRAW REL (+1, 0, -1)
[3}
" " (-1, +1, 0)
II
" ( 0,-1,+1)

Comparing [2} and [3}, note that the only compute load on the processor is
that of altering the one initial absolute positioning item regardless of the length of
the definition of the segment being displaced.

3. Aid subpicture calls. The facility for translation of relative image seg-
ments has been readily used to describe repeat~d instances of often-used
images.
When the display processor or channel provide for sub-image jumps and
returns, one can use relatively defined sub-images as masters from
which exact copy (scale and orientation) instances can be placed by a des-
cription which does pOSitioning to the location of each instance followed by
a call to the master relative sub-image definition.
For example, if the definition H-RES specifies the following image

806
 y

PT. 2

IN I TIAl POINT (PT. 0)

Figure 1.

+y

"-
"" Figure 2.

" "-
" 807
 +x

Figure 3.

Figure 4.

808
 +x

in relative coordinates and then return jumps to the calling image, then
the following definition will describe the image in Figure 3.

MOVE ABS (-. 15, 0, 0)

CALL H-RES
MOVE (. 1, 0, 0)

CALL H-RES
MOVE (. 1, 0, 0)

CALL H-RES

In the system being considered, the functional capability of translation is pro-

vided by transformation hardware (to be discussed later). Scaling provisions also
permit packed data formats when lower resolution is advantageous. The transfor-
mation hardware also provides a more general sub-image capability.
The use of absolute coordinate specification does not obviate any of the func-
tional capabilities normally obtained by use of relative coordinates. In addition,
use of absolute coordinates offers greater performance in effecting local changes
to an image. For example, to move the second point of Figure 1 in towards the
origin, as in Figure 4, only the item specifying that point need be altered.
Using relative coordinates, additional pOints may have to be adjusted to pre-
vent the picture from distorting, as in Figure 5. The additional decisions and
possible changes impose additional computational load on the processor.

Transformation Facilities

The hardware transformation facility can be considered a high-speed arith-

metic unit which computes output values from initial register contents. This is
Similar to the processors' divide hardware which computes quotient and remainder
values from input dividend and divisor registers (possibly buffered from core).
The transformation hardware computes three output values from sixteen
input register contents. For a functional representation and the equations speci-
fying the computation, see Figure 6.
The following examples will illustrate how this facility is used.

809
 -112 ""
""
""
"
Figure 5.

0 LrlJ 0 -
--... x
,

0 QJ [ R ..
IJ ] GJ -
,.. Y
,
FOR VISUAL
ELEMENT

U ~L-J~ 0 ..• z
, GENERATION

x:..- SRllx+SRI2y+SRI3z+dx
Y . . - SR21 x + SR22Y + SR23z + dy
z ' ' ' - SR 31 x+ SR 32 y +SR 33 z + dz

Figure 6.

810
 I-----------------f---~.I COMM·I
DISPLAY
CHANNEL
.....
R dV

... 0 0 o
0 0 o
---•...
GJ
... 0 0 o

TRANSFORMATION HDW. VISUAL ELEM. GEN.

r
MOV (x I ' Y I ' Z I )
DRW (x2'Y2 ,z2)
X '~ S ( x +0 + 0) + 0 =S x
IMAGE DESCRIPTION y. S(O+ y+O) +O=Sy

Z ~ S (0 +0 + z) + 0 ~ Sz

CORE STORAGE

Figure 7.

00
......
......
 Consider Figure 7, where a display channel is fetching items of an image
description from core and passing those which specify elementary visual ele-
ments to the display generator for processing. If the transform registers are
loaded with values illustrated by the equations underneath, as can be seen,
the sole effect is to scale the element arguments by the factor loaded in the
S (scale) register. If the S register is loaded with unity, no effect is per-
formed by the transformation and the visual elements generated are exactly
those defined by the image description.
For an arbitrary value of S, the effect on the input image definition space is
illustrated in Figure 3. As the coordinate values of elementary items in the
definitions are scaled down, the entire image segment defined by them is
scaled down. The only additional overhead incurred is the one loading of the
desired scale into register S prior to processing the description

y'

Figure 8.

812
 y
y' Figure 9.

X' = X cos e + Y sin e

Y' = - X sin e + Y cos e
z' = z

x
x
11
R = R = cos
22
e
-R = R
21 12
= sin e
R = 1
33
R 13 = R31 = R~3 = R32 = ~
Figure 9 illustrates the effect in a z-plane on a point of a rotation about the z-
axis by an angle e. The coordinates of the rotated point in terms of its ori-
ginal unrotated coordinates are given by the equations at the right. Underneath
values of Rij are given which would perform the illustrated rotation.
Similarly, varying values of dV will position the scaled rotated definition
space (and any image descriptions it contains) at any location throughout the
transformed space.

SOFTWARE FORMATS DESIDERATA

In providing a format for image descriptions, and implementing their hard-

ware/software processors, the following characteristics were sought:
1. A description format whose processor implementation would not detract
from the maximum possible hardware performance.
2. A description format whose functional characteristics would lend them-
selves to ready implementation of interactive facilities desirable for on-
line use. For example, having a rotation about an axis take as argument
the angle of rotation and not the nine coefficients of rotation matrix. The

813
 ability to rotate an image by a single rotation item (affecting many co-
ordinates) is a facility desirable for on-line use. Having a single rotation
item able to apply it to an arbitrarily long segment is a functional charac-
teristic whose performance makes it feasible for interactive use, and
choosing the user's more likely input, the angle, is the choice of
description-format-to-hardware decision being sought.
3. A description format whose usage in describing images would be "natural"
to a programmer.
4. A description format which offers the programmer effective use of the
available hardware facilities.
5. A description format flexible enough to be used under most of the prevalent
programming and/or modeling schemes which are possible.

DESIGN OF IMAGE DESCRIPTION FORMATS

The following paragraphs will discuss and present some of the data structure
selected for specifying images in a flexible dynamic and modular form. They have
been chosen to be easily worked with by the user, the system software, the user's
modeling programs, and directly by the terminal's display processor itself.

Visual Element Formats

Full use of available precision (15 bits) in the transform and display hardware
prevented packing more than two values per word (30 bits) for full resolution.
Therefore, for the majority of items, which have three data values, up to a
half-word was available for command, control, and/or addressing information with-
out degrading the data below two word fetches per item.
For low resolution use, or for natural data with less precision, various packed
table formats are available for packing control and data values into a single word.
These being homogeneous, data tables describing unstructured image segments do
not engender the addressing structuring and linking considerations of general image
descriptions.

Processing Image Formats (Implementation)

Image descriptions will be assembled from image items. Image items are one
or more consecutive words containing fields giving the item type (command) and any
arguments it requires.
Examples of items with three arguments would be MOVE and DRAW used in
previous examples. Their three arguments provide the absolute coordinate values
specifying the vector endpoint in the image definition space for the displayed or
blanked line.

814
 The item for packed formats was chosen to be a command specifying the table
type and a single argument giving a reference to the packed data table.
The display processor hardware was designed to extract command and argu-
ment information from the fields used in packed data tables and from that chosen
for the general image item representation.
A default was also implemented so that any extended use of the fields for fa-
cilities or options not implemented in the hardware would result in a priority
interrupt to a software interpreter.

This permits an efficient extension of facilities beyond those implemented in

the hardware channel and provides for compatibility of image descriptions on
terminals lacking designed options.

Transform Items
The hardware transformational facility performs any construct defined from
our elementary visual items to be arbitrarily scaled, rotated, and positioned with
no added per-vector overhead over the untransformed images. Only that time
necessary to load the transformation parameter registers is needed to affect all
subsequent coordinates processed.
One form of user control considered desirable was to permit a described
image portion to remain specified in these parametric transformational terms if
the interactive on-line use was expected to involve alteration of its parameters.
This would require that, each frame, several registers be reloaded (with
possibly changing volumes) to perform the equivalent of modifying many possible
coordinates.
For example, in Figure 10, if an expected interactive alteration is to be value
e which the link makes to the base, the image can be described by a transform
item(s) between two segments of elementary items. These would be an assemblage
of visual elements describing the base followed by a pOSitioning to the pivot and a
rotation about the pivot, followed by the segment of visual element describing the
link.
The new transform specifying image items would use their argument field to
provide values for loading the hardware transform registers. It was found more
effective for both user image gen,eration and on-line modification to have the rotation
transform items expect the angle of rotation as their argument instead of the derived
rotation matrix. One of the software extensions on the channel interrupt catches
rotation items and uses their angle arguments to compute the trigonometric ratios
to be loaded into the hardware transform registers.

Nested Use of Transforms

One very natural use of descriptive schemes by programmers is to compose
new constructs from both elementary items and previously defined constructs.

815
 e

BASE LINK

Figure 10.

In our case, if an instance of some predefined image is to be used in forming

a new image description, it can be placed by transform loading image items pre-
ceding a sub-image call to it. What is now needed is to be able to use calls to this
composite image desc:ription as elements in subsequent image definitions.
To accomplish this, the instating of transforms for sub-images must be with
respect to the "current" space, considering that it might already be transformed.
Another way in which this need for nesting transforms arises is in the use of
transform image items for altering local image segments. Within such segments it
is possible that the need for transform-alterable sub-segments may arise. For
example, in Figure 11, the image description of the base contains a segment
attaching link 1 under a transformation. Within the transformed segment describing
link 1 it may be desirable to be able to attach a link 2 segment, also under a
transformation.
The difference is that this transformation must be with respect to the trans-
formed space of link 1. If the appropriate transformation for attaching link 2 to link
1 were simply loaded into the transformation hardware, the link 2 would not "stay
attached to" or move with link 1. It would move with respect to the untransformed
space of the base.

816
 LINK LINK 2

Figure 11.

To effect the desired transformation upon a transform-nested segment, the

intended sub-transform must be composed with the existing transform, yielding a
resulting composite transform to be imposed on the segment.
To illustrate the derivation of this composition operation we will now derive
the transform we wish to effect when nesting transforms.
We will represent the elementary (ha~dware implemented) transformation by
the_operator T applicable to an input vector V to yield a transformed output vector
T (V).
So for all vectors VI of link 1, under the link 1 transform T , we really have
1
displayed the vectors:
( 41
Now some of these vectors describing link 1 will be the ~winging sub-segment
called by link 2, they are not just the describing vector items V, but have been
transformed by the link 2 transformation, T;;. and already should look like:
[5}

So when they are then further transformed by Tl ' as all other link 1 vectors
V1, they appear as
(6}

Substituting (5} in { 4} as per (6} we have:

Expanding T2 we get:
= SI Rl (S2 R2 V + ~ + d1

817
 Multiplying out and moving the scalar s 2 forward, yield the form:
=: Sl S2 R,. R 2 V+ Sl R1 d 2 + d 1

Which is the composite transform applied to the nested segment vector V,

or:
T(V) =: sRV + d

Where the composite transform parameters as collected from £7} are:

s
R [s}

Therefore when an existing transform T1 =: [Sl' Rl, d1 } is loaded, and a new

nes ted transform T2 =: [S2' ~, ~} is to be instated, the new transform parameter
to be loaded are given in [S}.
Image items were specified and implemeted not only for loading of transfor-
mation parameters but also for composing transformation parameters onto the
current local space.
Since the scales, rotations, and translations for each level can be specified
independently of each other, separate IItransform specifying items II were defined
for member of each group.

The. following table gives the implemented items, their arguments, and a
brief description.

Table 1.
Transform Specifying Items

Type Ar~ments

SCL FSCAL Scale down from current size.

ROTX AX Rotate about local X-axis by AX.
ROTY AY Rotate about local Y-axis by A Y.
ROTZ AZ Rotate about local Z-axis by A Z.
RXYZ AZ, AX, AY Rotate about local X, Y, AX, then about
resulting Y and A Y, then about final Z
axis by AZ.
DX FX Displace along local X from current
pOSition.
DY FY Displace along local Y from current
position.
DZ FZ Displace along local Z from current
position.

818
DV F Z, FX, FY Displace following image from current
position along local X, Y, Z axes by
(FX FY F Z).
LDSCL FSCAL Scale subsequent image seg. by FSCAL.
LDRX AX Instate rotation by AX about CRT-X axis.
LDRY AY Instate rotation by AY about CRT-Y axis.
LDRZ AZ Instate rotation by AZ about CRT-Z axis.
LDRV AZ, AX, AY Instate successive X, Y, Z rotations from
CRT frame.
LDX FDX Reset local X displacement to FDX from
CRT center.
LDY FDY Displace FDY from CRT center along local
Yaxis.
LDZ FDZ Displace FDZ from CRT center along local
Z axis.
LDV FDZ, FDX, FDY Displace from CRT center by FD along
local axis.
LDI Instate CRT reference frame.

Use of Transforms for Composition

Observe in {8} that, if transform Tl is loaded in the hardware and a new

translation vector ~ is sent into the input coordinate registers, the output vector
(x', y', z') will be Tl (~) or the new composite displacement. Note also if a new
rotation ~ is to be composed onto the existing transform, tliat setting d = ,0 and
s = 1, then sending columns of the new R2 into the input coordinate registers will
compute the corrseponding columns of the composite rotation matrix R.
Therefore, another design feature incorporated into the system for greater
effective use of its capabilities was the ability to re-digitize the transformation
outputs and read then out of an input register. Also, vectors can be sent through
the transformation hardware without activating any display output generation.
This use of the transformation hardware to compute its own composite para-
meters was also made more efficient by the deciSion to remove scaling information
from the array to its own separate register S.

Control Items

In addition to the Visual Element Generation and Transform Specification,

another class of items for image description was defined to perform control
functions.
They serve to invoke sub-image calls to other image definitions, to effect re-
turn from a called image, to bracket the effect of transforms within image segments

819
and perform other functions which will be covered later.
The effect of a transformation can be bracketed to range over a set of items
by a pair of items, one of which saves the current transform on a pushdown stack,
and the other which restores a transform from the stack and loads it into the
transform hardware. These are called "Save Transform" (SA VET) and the "Restore
Transform" (REST) image items. This also permits arbitrary nesting of trans-
formed image segments.
Each "sub-image call" item (IMG), performs an automatic SA VET, pre-
serving the transformation, the return address, and certain other control infor-
mation on the stack. Therefore, the "Return from Sub-Image" item, (RET), in
restoring from the stack, will also cancel the effect of any transformation changes
performed by the sub-image. This normally permits a sub-image call to be used
in image definition with the same freedom and flexibility as simple element-
generating items.

Paramertic Arguments

Another design choice was to provide for flexible addressing and referencing
of arguments to image items.
Since many of the meaningful variables of an image description have been
brought out as arguments to its items, identity constraints can be imposed by
addressing common values to one defining variable. This makes it easy to bind
visual imagery to a running program or model, or the values it generates or
maintains.
One of the addressing modes permits accessing a value located relative to the
head of a block or table which in turn is found by possible indirect addressing
through a chain of pOinters (a form of post-indexing). This permits image descrip-
tions to be imbedded in most plex or linked block modeling structures.
One field in the common half-word of each item specifies the type of addres-
sing necessary to obtain its arguments. This is called the "Data Type" field and
specifies the three characteristics of an item's argument references.
1. Location -(Immediate/Addressed)
The references to individual arguments of any item may be included in
words of the item or only an address reference to where the individual
references are assembled, may be given. Therefore, several DRAW
items may refer to one common block containing the coordinates of their
common end-point. This end-point can be moved by just altering the one
commonly used set coordinate references.

2. Contents -(Value/References)

All arguments to an item may be given as fixed constant 15-bit values or

820
 general addresses referencing the cells containing the desired values. If
the arguments to an item will not be varied, it is more efficient to give the
values immediately in an item. But, if the arguments to several different
items are to be continuously altered to one changing variable, it may be
more efficient to have them all address the variable.

3. Packing -(Full/Half-Word)

When all arguments are available as 15-bit values they may be packed two
per word, providing the most efficient display processing. They may also
be given one per machine word for more efficient internal processing and
programmatic use.

All image arguments specified by address references contain two fields: an

address mode and a 15-bit address field. The address mode specifies one of the
following four referencing schemes:

1. Immediate addressing; the value of the argument is the 15-bit address

field itself.
2. Direct addressing; the address field gives the core location of the value.
3. Indirect addressing; the address field is the first in a chain of addresses.
The first is one which does not contain an indirect addressing mode and
is used as the core location of the argument value.
4. structure addressing; the field address is taken as a post-index, the fol-
lowing word is used as an address reference to obtain a core address,
then the post-index is added to this address location to give the location
of the value.

With these addreSSing capabilities an image description can be made para-

metric, so that the visual display it generates when processed is specified by running
variables in core.

Execution Control Items

The processing of many display items will cause an interrupt activation of a

supporting program; e. g., to load transform registers. Once the computer is
activated, it was found useful to make its execution facilities available to the user
describing an image. For this purpose, a "Jump to Computer Subroutine" (JSR)
image item was implemented. This permits more elaborate constraints to be im-
posed on other parameters as part of the image definition (for example, parallelism
or equidistant speCifications). It also facilitates representation of derived para-
meters where the display depends on computed values from several problem or
input variables.

821
 The JSR items are implemented so that argument list references can be pas-
sed to the called user-written computer program. Upon return from the program,
the display processing is re-activated and processing of the image continues.
This capability together with addressing permits a very active or dynamic
class of images to be described.
Now that images can vary by addressing and modify themselves by JSRs, it
was found that many repetitive picture assemblages could be effectively defined as
repetitions of changing or self-changing segments. Thus, a pair of "loop-control"
items was implemented. They delimit the range of a segment to be repeated; the
first also takes as an argument the initial repeat count.
The running count is always pushed on the stack for sub-image calls and
popped back upon return.
To permit descriptive material to be scattered, as with the data it describes
in a linked data structure, a "Jump in Image" (JMP), image item was implemented.
The addreSSing modes permit the display to follow the links which tie the structure
together.
The last set items to complete the execution control class are the conditional
image items. They conditionally perform an image jump (JMP), or a sub-image
call (IMG) depending on the state of conditions monitored by a set of sense bits.
These include signs or zero test of monitored variables, light pen hits over enabled
segments, violation of programmed boundaries 3 and bits identifying the boundaries
crossed. A status register contains the sense bits and control bits.
Control bits enable the boundary and pen-monitoring, specify the overall ef-
fects, such as dashing and solid lines, and select which scopes are to receive the
generated display.
Image items are available to store, load, and change the contents of the statm
register.

PICTURE PROCESSING

The preceding section described how image descriptions are assembled from
image items and how subsequent processing results in describing a three-dimen-
sional construction composed of basic visual elements. The final stage in generatin:
a display consists in extracting a two-dimensional projection of the three-dimension
image and displaying it as the resulting picture on the scope.
The class of items controlling the resulting picture or view of the processed
image are called "viewing items." These affect such qualities as the overall pic-

3 Described under Picture Processing in the next section.

822
ture scale, front cut-off blanking, intensity modulation for depth cueing, and par-
titioning the display surface into bounded windows.

Picture Scale

When an untransformed two-dimensional image, such as a page of text, is

viewed, it is desirable to have the maximum coordinates in the image definition
space project onto the maximum limits of the display area of the scope.
But, if a two-dimensional picture is composed with fu1l-scale translations,
it may extend over by the range of the coordinate limits (Figure 12).
To view the entire image would require the image description space coordi-
nates to be scaled down to 2/3 of the corresponding display screen coordinates.
Similarly, rotated two-dimensional images require a 1/J2 scale factor to fit the
maximum transformed space range into the viewable projection range (Figure 13).
The most used factors are 1 for untransformed spaces, 1/(1 + J2) for general
two-dimensionally transformed spaces, and 1/(1 + .(3) for general three-dimensional
spaces.
Since these viewing effects are not part of describing the three-dimensional
construct, a separate scale register was implemented as part of the transformation
hardware. This scale factor and its register are called the "Picture Scale" and the
associated item the "Load Picture Scale" (LDPS) item.

Depth Cueing

The resulting processed image Z dimension coordinate is used as the depth of

the image into and out of the projection on the display screen. The hardware provides
the facility for shading the displayed lines along their length as a function of their
depth.
Since the eye is sensitive to energy, the rate of dimming is non-linear and
nearly exponential as shown in Figure 14. The sharp cutoff at +1/ 4 is used as the
position of the screen. So, all visual elements falling outside of the screen (towards
the viewer) would be blanked, and all elements generated into lower and negative Z
(depth) areas would be progressively dimmed.
To exploit this capability of the vector generator, additional picture transfor-
mation processing was implemented to position the viewing screen cutoff anywhere
in the generated image space, and to adjust the rate at which dimming with depth is
to be performed.
The position of the screen cutoff can be adjusted by a translation of the images'
processed Zl output. Moving the image negatively, causes portions behind the

823
 --------, r--------

_______ J
-I +1 -I +1
imgA img B

img C: DX (-1)
IMG (img A)
DX (+1)
IMG (img B)
RET

img C

Figure 12.

112 --II~f----2--~~-1/2

824
 img D: ROTZ (11/4)
IMG (img A)
IMG (img B)

imgD

~---2------~

14-----2 -{i' -------i~

Figure 13.

825
 INTENSITY

MAX

.1
-DEPTH

-I .25 +1

Figure 14

826
viewer to move into the displayed range, and moving it out towards the user causes
less of the image definition volume to be on the visible side of the screen cutoff.
This transformation applied to the final image z' to translate it and give an intensity
signal is called "Intensity Displacement" (ID) value and has an implemented register
in the transformation hardware.
Similarly, the z' value is scaled prior to generating the intensity for display
generation. This permits the entire z' image depth range to be squeezed into a nar-
row band of depth in Figure 14 causing all coordinate points to be displayed with the
same uniform intensity. The intensity for the entirely-viSible image could be ad-
justed by the ID value. As the scale is increased toward 1, the lower and more
negative z' values move further from the plane, becoming more and more attenuated
in intensity as in Figure 14, until the further reaches cease to be visible. The hard-
ware transformation register for this facility is called the "IntenSity Scale" or IS
value.
The intensity transformations performed by the hardware are:
I +- IS • z' + ID

Using this facility, complex structures may be "decluttered" by moving the

space through a narrow intensified section thereby selecting for display only the
section of the image intensified.

Window Bounds
The final viewing-space processing facility implemented is a pair of program-
matically-controlled boundary planes for each dimension of the final viewing space.
This permits an arbitrary volume in three-space or window in the 2D view plane.
to be positioned in the viewer's frame of reference. The hardware will monitor all
final visible image segments which transgress these boundaries.
The hardware will also selectively blank image segments in or out of the
boundaries.
This facility can be used for sifting or picking through an image, or for di-
viding the viewing area into independent "windows," each enabled to display por-
tions of different image spaces. Although the hardware registers use the upper and
lower boundary plane coordinates for each dimenSion, the implemented items use
their arguments to:
1. Load a rectangular window of a given height and width centered at a given
point.
2. Move the established window by translating it to a different point.
3. Scale the established window to new horizontal and vertical dimenSions.

827
ACKNOWLEDGEMENTS

The design and development of the interactive graphics system was made pos-
sible through the efforts of many people as well as the environment and policies
which fostered the cooperative attitudes necessary for such amalgamation of hard-
ware and software design efforts.
I would particularly like to mention some of the principal participants in the
design and development area. As far as hardware, the initial proposal of the
transformation hardware and subsequent hardware development projects were
directed by T. G. Hagan, the display generation system was designed by S. Max,
J. Porter, J. Holman, and P. Esrig. The system integration was coordinated by
R. Nixon. In software, I wish to express my thanks for design support and directio
to Dr. J. D. Grandine and several inspiring discussions with W. R. Sutherland. 4
The standard operating system and system software was primarily implemented by
H. D. Kerr; the graphics support software was implemented by Miss A. O'Reilly,
M. Davis, and R. Freed.
This development was moti viated by the facilities and environment made pos-
sible by Adage, Inc., of Boston, Massachusetts.

REFERENCES

1. T. G. Hagan and R. Treiber, "Hybrid Analog/Digital Techniques for

Signal ProceSSing Applications." AFIPS Conference Proceedings, 1966,
Vol. 28, pp. 378-388.
2. R. D. Bergeron and A. D. Van Dam, "Software Capabilities of the Adage
Graphics Terminals." (See following chapter, pages 831-850).
3. T. G. Hagan, R. J. Nixon, and L. J. Schaefer, "The Adage Graphics
Terminal." AFIPS Conference Proceedings, 1968, Vol. 33, pp. 747-755.
4. AGT DISPLAY OPERATOR, DSPLY/PRM, Programmer's Reference
Manual, Adage, Inc., Boston, Mass.
5. AGT BUILD OPERA TOR, BUILD/PRM, Programmer's Reference Manual
Adage, Inc., Boston, Mass.
6. AFORT DISPLAY INTERFACE, AFDSP/PRM, Programmer's Reference
Manual, Adage, Inc., Boston, Mass.,

4 Then with M. I. T. Lincoln Lab.

828
BIBLIOGRAPHY

Related Graphics Support Software

1. E. Sutherland, "Sketchpad: A Man-Machine Graphical Communication
System." Proceedings SJCC, Vol. 23, pp.329-346, 1963.
T. E. Johnson, "Sketchpad III: A Computer Program tor Drawing in Three
Dimensions." Proceedings SJCC, Vol. 23, pp. 347-353, 1963.
J. C. Gary, "Compound Data Structure for Computer Aided Design: A Survey. "
Proceedings ACM National Conference, 1967.

General Purpose Dynamic Graphics Systems

D. T. Ross, R. H. Statz, J. E. Ward, "Operating Manual for the ESL Display
Console." ESLTM9442-M-129/MAC-M-217, March 9, 1965.
R.A. Schumaker, "The G. E. Computer Color T. V. Display." Proceedings
University of Illinois 2nd Graphics Conference. "Pertinent Concepts in
Computer Graphics." (to be published. )
1. E. Sutherland, "A Head Mounted 3D Display." Proceedings AFIPS, Vol. 33,
pp. 757-764, 1968.

Hardware
L. G. Roberts, "Conic Display Generator Using Multiplying DACs." IEEE
Transactions on Electronic Computers, Vol. EC-16, No.3, p.369, June 1967.
R. F. Sproull and 1. E. Sutherland, "A Clipping Divider." Proceedings AFIPS
FJCC, Vol. 33, pp. 765-775, 1968.

829
 SOFTWARE CAPABILITIES
OF THE
ADAGE GRAPHICS TERMINALS
A. van Dam and R. D. Bergeron
Center for Computer and
Information Sciences,
Brown University,
Providence, Rhode Island 02912,
U.S.A.

ABs~rRACT

Most evaluations or descriptions of display systems

concentrate heavily on the hardware characteristics, but
offer little insight into the capabilities and facilities
offered by the software. Since hardware/software operation
is so interrelated, the true power of any system is highly
dependent upon both.

In this paper we describe the facilities of the Adage

Graphics Terminals with special emphasis on the software.
There are several ~spects of the Adage software facilities
that represent an uncommon approach to the problem of
displaying data. For instance, pictures with a hierarchical
repres~ntation may be displayed directly.

Ivan Sutherland's Sketchpad (1] marked the beginnings of

contemporary interactive computer graphics. His concept of
a hierarchical representation of a picture in terms of its
component parts has become an essential ingredient for any
truly general purpose graphics system. ~lthough Sketchpad
appeared in 1963, manufacturers have only recently begun to
recognize the importance of developing hardware and software
to facilitate implementation of such a concept. Their
emphasis should not be merely on producing better points and
lines (i.e., faster and cheaper ones), but also on providing

Publisher's note: This text is a reproduction of the computer output from the
Hypertext EdIting System.
831
tools for building better models for the data that repre-
sents the points and lines.

The Adage Graphics Systems do attempt to cope with this

problem of hierarchically defined pictures. We will
describe the primary software facilities of the Adage
systems with special emphasis on those characteristics which
aid in the hierarchical representation of pictures.

This paper is primarily concerned with the Adage soft-

ware, but we present here a brief hardware summary in order
to establish the en vironment of the software. (Par a more
complete description of the salient features of the hardware
see (2 ].)

We will use the term QiSEI~_£~Q£~2Q£ to denote the

portion of the hardware that accepts (in some fora) the
digital representation of a pictl1re and produces--ana-loC!
deflection voltages to drive a CRT. The digital input can
be as simple as that of the early DEC 30, which accepted
only a single pair of x,y coordinates in an accumulator; or
as complex as that of the DEC 338 which accepts entire
display files 1 with branches and subroutine calls, and even
contains a hardware pushdown stack. (Note, however, that
the power of the display 2Y2!~~ is not necessarily propor-
tional to the power of its display processor. The software~
hardware facilities of the host computer and the interface
with the display processor are at least as significant.)

The Adage Graphics Terminals are stroke drawing CRT

display stations consisting of a DPR2 digital processor, a
Graphics Coordinate Transformation Array, a vector genera-
tor, and a character generator. The system could be
classified as an "intelligent" terminal, rather than merely
a buffered display; in terms used by ftyer and Sutherland
[3], the Adage terminals are about one and one-quarter times

1. In strict terminology the term "display file" refers to

the data that can be passed to the display processor for a
particular system. However, it is commonly used to define
the basically unstructured list of display commands which
most display processors accept; this is the meaning that we
will use.

832
around the "wheel of reincarnation".2 In other words the
hardware display processor has enough power to free the DPR2
support processor for doing some work not connected with
generating the display. (This places it more than once
around the wheel.) However, as we will see later, the
display processor has a limited repertoire of executable
commands, and has less power, for example, than the DEC 338
which is classified as 1 and 1/2 times around the wheel.

The DPR2 is a general purpose digital computer that is

the only programmable component of the system and performs
all processing and control, including control of convention-
al input/output devices. Memory consists of from 4096 to
32,768 30-bit words and there are from 5 to 25 priority
interrupt channels. Disks, magnetic and paper tape units, a
line printer and a card reader are among the I/O devices
available for use on the DPR2.

The Graphics Coordinate Transformation Array is a hybrid

unit that transforms all vector endpoints by the current
scale, rotation and displacement factors before they are
displayed. These factors are contained as digital informa-
tion in a set of registers directly addressable by the main
processor. This unit provides fast and powerful transforma-
tional capabilities for manipulating the display. The
vector generator uses the analog output of the Transforma-
tion Array to drive the CRT beam under control of a
processor register specifying the display mode desired. All
vectors are absolute coordinate endpoints represented as
14-bits plus sign, from which ten bits can be displayed with
the origin at the center of the screen. The lack of
explicit incremental vectors is not much of a restriction in
view of the ease of implementing translations with the
available transformation facilities. The transformation
array/vector generator combination is the main component of
the Adage display processor.

The character generator is a high-speed stroke writer

with a vocabulary of 64 characters and an available expan-
sion of 32 additional characters. The characters can be
displayed in one of three sizes at one of three intensities,
and either upright or italicized. Special codes can be
--------------------
2. Their observati.ons concerned the relationshiit of the
display processor to the host computer. By making the
display proe-essor na little .ore powerful", the host comput-
er can be freed for other processing. However, after a few
iterations on that statement, the display processor itself
becomes a host computer to the display hardware and the
cycle begins again.

833
included in the character string to exercise control instead
of displaying a character. There are control codes to
position the beam, to change character size, shape, and
intensity, and to format the text with line feeds, carriage
returns, superscripts or subscripts.

The interactive devices supplied with the system include

a light pen, 16 keyboard function switches, and two foot
pedal function switches. optional devices include the Adage
Data Tablet, a joystick or bowling ball, six variable
control dials and auxiliary keyboards. Every hardware item
contains its own set of registers that are addressable from
the central processor.

An unusual characteristic of the hardware is the ability

to represent the z-coordinate by a varying intensity of the
electron beam. This permits description of graphic displays
that appear to be three-dimensional. Depth cueing by
apparent change in item size, however, must be programmed.

A three-dimensional hardware windowing operator is also

available as an optional feature. The program.er can
specify upper and lower bounds for the x,y, and z coor-
dinates, and the vector generator will blank the CRT beam
whenever it goes beyond any of the specified values. If the
beam crosses any of these bounds, flag bits (which can be
tested by the user program) will be set to indicate which
bound was exceeded. Since scissoring at the screen boun-
daries is done by the standard hardware, only information
both inside the window bounds and inside the screen bounds
will be displayed. Since there are executable instructions
to change the window bounds during the generation of a
display, it is possible to divide the screen into distinct
viewing areas which contain different pictures, or different
views of the same picture. Although this type of windowing
is very useful, it is not the most powerful available [4].

In graphics applications the real complexity usually is

not in the actual display produced, but in the relational
data structure that represents that display. A significant
feature of the Adage software (in contrast to most ~ther
manufacturer's software) is that it provides a reasonable
level of data structure support. The flexibility allowed
for the display information gives the applications programm-
er considerable freedom for interfacing with the system.
Another significant feature is the interpretive manner in
which the display is produced from the data structure. This
greatly increases the transformational capabilities of the
system. (Both the preceding statements will be amplified
below. )

Referring to Figure 1, which represents a typical organi-

zation of a graphics program, the Adage software/hardware
facilities perform the great majority of the work associated
with darkened boxes, which in most systems must be performed
entirely by the user. As described below, the Adage system
practically eliminates the need for a user written data
structure reduction program, the display file and the
correlation map.

Using a conventional graphics system, an applications

programmer typically builds a data structure to describe the
r.eLltionsld.-ps and connectivity between picture items, both
for strictly pictorial information and for applications data
[5]. The graphical coordinate information for these pic-
tures (which might be end point values of lines), would be
imbedded in individual blocks ("beads") within this struc-
ture. In addition transformation information would also be
present in separate subpicture ("instance") blocks to speci-
fy orientation, size and positioning for subpictures, which
are independently defined in other segments of the data
structure. A program must be written by the user to cO~Eilg
(flreduce") the data structure representation of the picture
into an essentially unstructured list or sequence of display
commands such as "plot a point at (x,y)" or "plot a line
from (xl,y1) to (x2,y2)." This unstructured list is often
called the display file or display list. The compilation
procedure would involve extracting each set of endpoints and
multiplying by the appropriate transformation, as well as
computing new transformations. The display file is stored
for refreshing purposes in the buffer of a buffered display
(as in the IB~ 2250/Mod 1), or in a "virtual buffer", i.e.
a dedicated portion of the shared memory of a buffer
computer (as in the IDIIO~ configuration [6].) Whenever the
picture is changed by addition or deletion of picture
elements, or even by a change in the transformation, the
reduction program must be invoked to create a new display
file or at least to alter it. Furthermore, in order to
identify light pen strikes there must be a mapping mechanism
that will relate a hardware derived (x,y) position or
display file address to the data structure item that was
"see~" by the light pen. A mapping of this type is often
called a correlation map.

835
 APPLICATION & PICTURE
DATA STRUCTURE

r - - - - - ~~------ , r
_____ t _______ , - ,'.# .....7""'11'''.-
,~
(r1~111• • • '''' ,

DATA STRUCTURE,• DATA STRUCTURE I

! PROGRAMS FOR DATA :-
,

-------
I I I , _ -
~TRUCTURE REDUCTION ;
--1----__
SCANNING ROUTINES.: BUILDING AND
, I I

r
I
~
I I' I~ "i
1.-- - - I ,MODIFICATION PROGRAMS ~ TO GRAPHIC ORDERS ~
- ! 1:,."",.... .,." .....-~~

r - - - - -
I
: APPLICATIONS
- - -,
H
I,
~ ~~~r- - - ----- -
ATTENTION HANDLING
- -T
I
rT/'##.
~
~ CORRELATION;
-rrrrITd
~ ~
~UI.SELAY~
<!l
ji'"//"", " '..........
~

I ~ 't ~ ~
i
1 I
: PROGRAM , ~ AND CORRELATION ~ MAP ~ ~ FILE.
~ - - - - - - - - -.I .... _ _,__"",._#;,~ ~(J""'"~~."

ROUTINES ~:------------------
f ------...
I

1-- - - - - - - PROMPTS & RESULTS

". .. - ....... - .. - ...

I
I I/O :
•
-------IIo.U..:I:I.:I::4&.......w~IIt.---""""It ROUTINES j•
Figure 1. A typical organization of a graphics program:-----r ---
CRT
The systems that use a buffer computer generally provide
more powerful capabilities, with respect to the display
file, than the buffered systems. The facilities of the
buffer computer might be used to manipulate the data in the
display file to produce a dynamically varying display. Por
example, if the system allows a translation to be applied to
a subpicture, the buffer computer might update this transla-
tion factor every regeneration cycle, causing the subpicture
to move across the display_ In addition the buffer computer
provides such facilities as pentracking and picture subrou-
tining, as well as to perform interrupt servicing. This

836
servicing may require the buffer computer to do error
checking on interactive requests, display appropriate pro-
mpts and even perform simple computational tasks required by
the program. (With some special hardware most of these
facilities, with the exception of interrupt handling, can
also be provided by sophisticated buffered displays, such as
the IBM 2250/Mod 3.) However most of the shared memory
systems unfortunately still retain the basic concept of a
"virtual buffer ll • In other words the pictorial information
is retained at the level of a basically unstructured display
file and there is little attempt to use the processing
capabilities of the buffer computer on a higher level of the
pictorial data structure. A typical example of this is the
IBM 1130/2250 Mod 4 [7J configuration in which there are no
facilities for interfacing the display processing with a
data structure, without first compiling a display file.

The Adage shared memory graphics systems obviate the need

for a display file stored in a virtual buffer. First, they
provide the ability to easily combine the geometrical
information and the problem oriented (applications) informa-
tion as long as the format of the ]raphical information
complies with fairly flexible requirements. (A more
detailed description of the allowable formats appears
below.) Then, the Adage hardware/software system will
automatically process this data structure i!!.!gE.£reli!~l.Y.
(once each refresh cycle), directly executing each display
command as it encounters it in the data st~ucture and not
com pi 1 i n g a se pa rat e ( red u n dan t ) dis p lay f i 1 e • ( Dis pIa y
commands may plot lines, display text, alter the transforma-
tion, cause conditional or unconditional transfers, or call
a sub-image.) Naturally, display commands must be chained
together to provide a complete path through the data
structure. Furthermore, because of the interpretation, the
display location associated with a light pen interrupt i§
the data structure address, so there is no need for a
correlation map.

A similar interpretive approach has been developed by

Ninke in GRAPHIC-2 [8] where a dedicated PDP-9 produces the
display from a graphics data structure. The Graphic-2
system is less powerful, in most respects, than the Adage
system, but the dedicated nature of the PDP-9 allows (and
also necessitates) more overlapping of hardware and software
display processing. While the hardware 1S generating a
picture element, the Q§gI._!Iit!!1!!. software of the console
computer searches the data structure for the next picture
element. The Adage processing technique, since it is
implemented in a non-dedicated processor, docs not overlap
hardwa~e and software display processing. This will be
described in detail later.

837
 The interpretation process yield~ a further advantage in
the increased flexibi1ity it provides for the Adage trans-
formation facilities. Every set of components, X=(x,y,z),
is transformed before display according to the equation:

Xt = (x' , y' , z .) = s[ R ] X + D

where X,X', and D are column vectors, s is a scale factor,

[R] is a 3x3 rotation matrix and D is a displacement vector.
The vector xt is then multiplied by another scale factor
(the picture scale) and the resulting vector is displayed
(if it does not violate th~ depth-cueing or window con-
strain ts.) The display software provides facilities for
loading a particular transformation factor (scale, transla-
tion, or rotation) and for composing (i.e., multiplying) new
factors with the current ones. The loading or composition
can be invoked at any point of the interpretation, so that
any subpart of an image can have its own transformation
applied to it. Furthermore, consecutive transformations can
be saved and restoredtfrom a pushdown stack at any time to
facilitate display of genuinely hierarchical data. For
example, since transformations can be applied to any group-
ing of points, lines, or subpictures on the top level of the
picture (by saving and restoring transformations around that
grouping), it is possible to define logical entities wit,hin
the top level. Furthermore, a subpicture ("instance") can
be processed with respect to the transformation at the point
of call, but that transform will automatically be restored
upon completion of the instance. Rence, any transformations
that are constructed while processing the instance will not
affect further processing of the higher level picture.

In the Adage system the primary software interface to the

graphics hardware is provided by the AGT Display Operator,
DSPLY. DSPLY is the actual software facility that controls
the interpretation of display commands. The facilities
provided by DSPLY can be generated through the use of three
languages - ADEPT, AFDSP, and BUILD.

ADEPT is the Adage assembler language which includes all

the display operations (which are described below) as
instructions. ADEPT is a reasonably sophisticated assembler
with good macro facilities and the ability to add coding and
new operations to the assembler.
AFDSP is a set of subroutines and functions callable from

838
the Adage Fortran language (AFORT) which allows the Fortran
programmer to use the facilities of DSPLY. AFORT in an
extension to ASA Basic Fortran. Some of the ~xtensions
provide special commands for external symbol referencing,
overlaying, and tracing.

BUILD is an on-line command language which provides

access to the DSPLY routines in an interactive environment.
The user can create and modify displays, retrieve previous
displays from tape or disk, initiate execution of previously
assembled programs, etc. The BUILD system provides a very
convenient and very powerful on-line drawing facility. The
data structures created by BUILD are less variable than
those available under DSPLY. However, this should not
seriously hinder the creation of a data structure containing
picture as well as applications information.

A fourth option is to construct the display data struc-

ture in a host computer and pass it to the AGT for
displaying. Adage provides extensive facilities for dynam-
ically relocating and linking display data structures from
various sources.

4.1 DSPLY

The AGT Display Operator, DSPLY, is a relocatable program

used to interface with the display processor in order to
graphically interpret the data structure information into a
display on the CRT. As described below, once DSPLY has been
started, it operates as a background program while proces-
sing graphically oriented data structures, called "images".
An image, typically, is a logical picture entity, i.e., a
picture "master~ which may be used as a sub picture in other
masters by use d~ a "sub-image call". The basic unit within
an image is carled an "image item", and is a single display
operation (see Sec. 4.1.1) together with its arguments.
Sequences of image items that reside in contiguous core are
called "image segments." Image segments are defined only by
their physical locations and need not be logical entities
with respect to the display. DSPLY processes the image
items and produces the appropriate display on the CRT. Data
structure formats are determined by the various data types
and addressing modes that can be interpreted by DSPLY.
These will be described later.

The applications program initially calls DSPLY via a

standard subroutine call, passing as a parameter the address
of the image to be processed. OSPLY then activates the

839
harjwar~ display processor and returns control to the
operatiny system. The display processor operates on a cycle
steal basis, but can interpret only DRAW and MOVE commands
with immediate data and some table commands. (Tables are
compact collections of consecutive coordinates without
intervening commands. It is the way to get the most data
into the least space.) When the display processor discovers
a command it cannot interpret, it interrupts the foreground
program via the operating system. Control is again passed
to DSPLY, which then performs the addressing operations to
access the data or does the non-picture producing computa-
tion or housekeeping implied by the command (such as
changing a transformation factor).

Input to DSPLY can be modified by operator interaction or

by program or subroutine processing of image inputs. One of
the valid display operations is a subroutine call so that
any machine language subroutine can be executed as part of
the display processing.

DSPLY refreshes the CRT display at a constant rate which

can be set by the program to one of eight frame rates. In
the event that DSPLY can not process the image at the
assigned rate, a timing error occurs and one of three
options is invoked. This entire image can be interpreted at
a lower rate, the rate can be permanently lowered, or as
much of the image as possible will be displayed within the
present rate.

4.1.1 IMAGE ITEM OPERATIONS

Imaye item operations (i.e., display operations), are

defined by the op code field of the item (Figure 2). There
are operations to generate picture elements, modify the
transform and viewing parameters, and exercise branching
control. The element generating operations can display
blanked or unblanked lines, interpret tables, and display
text. The transform operations allow altering of the
current transformation by loading a new origin, scale
factor, or rotation matrix or by composing any factor with
the current one. The viewing parameters specify the amount
of intensity variation produced by depth-cueing and window
bounds if the machine is equipped with the hardware window
option. Control operations can perform subroutine or subim-
age calls, can define a loop (which causes a group of image
items to be processed a specified number of times), and can

~o
perform unconditional or conditional branching based on bits
in the Status Register. The Status Register is a software
register maintained by DSPLY. Its bits are used to define
the vector drawing mode and to enable dnd record pen detects
and hardware window bound detects (which occur when the beam
crosses any of the window bounds.)

4.1.2 IMAGE DATA STRUCTURE

The image data structure consists of a two word header

followed by a list of image items. Since any image item can
be an unconditional branch, the consecutive items need not
be in contiguous core.

Image items have variable lengths depending on the

operation to be performed and the format of its arguments.
The first 30-bit word of each item has the format shown in
Figure 2.

l\ddress
Operation Data Address
Code tvne mode
bits: O\~_______~~_8~9____1~lA_2_J_____1~5_____~~____________
29~)

COHIv1AND A..tfGUIvIENT hEFEB.ENCE

Figure 2. Display operation format.

There are six different data type definitions that can be

specified for all operations. These are Immediate Half-Word
and Pull-Word Value Lists, Referenced Half-Word and Full-
Word Value Lists, and Immediate and Referenced Reference
Lists. Whenever a Reference (address reference) occurs, the
format can be further modified by the Address Mode (AM).
Figures 3 and 4 describe two of the six data types. (Note
that the addressing pointers shown in Figure 4 are not
necessarily as simple as depicted. The complexity of the
indicated pointer operation is determined by the Address
Mode field as described below.)

The Address Mode specifices how a single argument is to

be found from its Address.
IMMEDIATE indicates that the associated 15-bit. !s!dr~~§

841
 Bits: c (
2 15 29

Oneration 2 if Argument 1
i~
Argument 2
;:.
Argument 3

Figure 3. Immediate Full-Word Value List

--r
BH··s : 0r-_ _-+y.....,.:l.....2\.;,.·
'eper. 171 ~-ItI
1....5' - - - - - - -
Address ~ I .. 41-
A-H 1 Address 1
* A-M ~ Address 2 a.

*"' fA-M ~ Address :3 ,.

Figure 4. Referenced Reference Lists

fiQl!l (the last half of the word pointed to) is

the value.
DIRECT indicates that the associated Address field
contains the location of the value sought.
•
INDIRECT indicates that the associated address field is
the first of an arbitrary chain of indirect
addresses. The first non-indirect address i.n
the chain is the location of the value sought.
STRUCTURE requires 2 machine words to determine its
associated value. The Address field of the
first word is an offset from a base which is
referred to by the address field of the second
word.

The user would choose whichever formats best interface

with his particular application. If the amount of connecti-
vity or relational information he required was small (e.g.
two or three halfwords per command), he might use one of the
Full-Word Lists and would imbed his information within the
display data structure. If be required a little more space,
he could generate NULL operations and use its argument
fields for his data. If there were considerably more
applications data structure than picture data structure, his

842
strategy would probably be to imbed the graphics data
structure within his own. In that case he would have to
generate extra JMP commands to connect the various display
commands.

N
NULL ...."L ',"
NULL
MOVE "- .. Point
~AVE Transform
DRAW Eoint
irransformation
JMP <r"
Operations
& Data
* *
CALL Image
* * RESTORE TFM

Line
•
•• Block
.TMP
*
-* r
* J
*
t
Instance Block

*These fields may contain any applications data.

Figure 5. Hypothetical data structure.

To demonstrate the uses of the various options, Figure 5

defines possible block structures for a Sketchpad-type
system, using all three of these embedding techniques. The
basis for this data structure is a point block that merely
stores data; it is never executed by the DSPLY operator but
will be referenced through line block pointers in order to
pass the coordinate information to the display processor.
The line blocks are simply MOVE and DRAW operations using
the Referenced Full-Word data type with the Immediate
address mode to reference the appropriate point block. The
address field of the NULL operation is used to link the line
blocks together. The JMP operation is used to skip the
application information fields needed for each line block.
The instance block contains transformation operations, pro-
bably with immediate data, that specify the positioning of
the sub-image. The current transformation is saved before
these operations are executed, and is restored upon return
from the subimage call.

843
4.1.3 OTHER DSPLY FUNCTIONS

DSPLY performs several other useful functions by means of

special entry points. Among these are PENHT, CLOCK, and
DSPTB.
PENHT rearls the n-th previous entry in the Pen Hit
Table (a circular table with 16 entries) and
returns the address of the image item that
caused the detect and the address of the image
that contains that item. The Pen Hit Table is
updated whenever the pen enable bit in the
status register is on and the light pen detects
light. (A hardware interrupt causes the operat-
ing system to invoke the appropriate system
subroutine to update the table.) The user may
test for an interrupt via a conditional branch
(e.g., to a subroutine call), or he can ignore
the information until later. For example, a
certain user action (such as deleting text from
a character string) may require two consecutive
light pen detects. The first detect might be
ignored, or used to set a flag bit, whereas the
second would initiate the actual deleting opera-
tion using the last two entries in the Pen Hit
table as the arguments.
CLOCK will append a specified routine to the clock
chain. The clock chain is a sequence of rou-
tines that are executed once per refresh cycle.
A useful routine to have on the clock chain
might sample the setting of the bowling ball.
This value can be stored by the subroutine in
digital form in the main processor and used as
the argument of a rotation command. In this way
a portion of an image can be made to rotate
dynamically as the bowling ball is moved. Other
useful routines on the clock chain might sample
function switch settings or read the variable
control dials.
DSPTB is the name of the dispatch table used by DSPLY
to access the appropriate subroutine from its
operation code. By "assigning" an unused opera-
tion code to his own subroutine, the user is
able to "define" new operations. The assignment
is made by entering the subroutine address in
the appropriate entry of the dispatch table.

844
 The 'Jraphic cOmman(l languaq"" BtTILDf prov i(h~s an on-line
user with fdcilitl~s for creating and linking image segments
and binding them to loaded programs or images. The BUILD
functions are employed by using the tablet stylus to choose
appropriate entries from the various BUTLD menus.

4.2.1 BUILD OPERATION

The basic operation of BUILD is to construct one image

segment at a time. (An image segment is a contiguous set of
image items., The segment currently under construction by
BUILD is manipulated and stored in an in-core area called
Working storage, which is continuously processed by the
DSPLY interpreter. 8UILD 0 pera ti ons can be used to add
lines, text, subimage calls, or other display operations to
the turrent BUILD segment, which may be a concatenation of
several previously built segments. Since dny of the image
items may be a Ifsubimage call" (i.e., an instance or another
image), a traditional Sketchpad-like hierarchy can be imple-
mented. In addition, the power of the transformational
facilities allows grouping of subparts within the top level
image.

There are two ways to add image items to the current

segment. Lines can be added directly by using the SKETCHing
facilities of BUILD. In these operations the tablet an1
stylus are used with a system tracking cross to define the
arguments of the display commands (DRAW an~ MOV~) to be
added. The user may also append an entire image segment
(which may be just a single item or a collection of many
items) to the current segment. When the user wants to
construct or modify another segmeot~ he can file the current
segment to another area of core, the Temporary Library, and
enter its name in a table associated with this library. Any
segment in the Temporary Library may be copied into the
current segment. 3 Initially this library contains a one item
segment for each of the DSPLY operations with formal
("dummy") parameters for their arguments. Therefore selec-
tion of one of these includes assigning values to these
parameters, as discussed below.

--------------------
3. Note tha t this is £2.E..Y opera tion a od is not equi valen t
d.
to a subimage call which is a Igl~£g!lfg to another image.

845
 A typical procedure for using segments to build other
segments might be employed in a circuit design application.
For instance, segments could be constructed with several
line-specifying items to form a capacitor, a resistor, and
other electrical symbols, which would be saved as separate
segments. These in turn, could then be used to build
segments representing circuit diagrams.

An image located in core (i~ the Temporary Library area)

may be called (referenced) as a subimage from Work storage.
The images constructed by BUILD are ina relocatable form
with suhimage addresses as external references. Hence, a
BUILD image, which may be a collection of segments in the
Temporary Library, may be stored or retrieved from disk (or
tape) through the use of the SAVE and RETRV functions which
perform all the necessary relocation operations and any
additions to the Formal Parameter Table that may be needed.

4.2.2 FORMAL PARAMETERS

A formal parameter is defined as a data block that

relates arguments (parameters) of an image segment to the
real values of those arguments located elsewhere in memory.
By assigning "values" to the formal parameters, the desired
command can be copied from the Temporary Library into the
current segment. When an image item or segment is so added
to the Work Storage, its associated formal parameters are
added to the Formal Parameter Table.

An entry in the Formal Parameter Table consists of a set

of Argument-Value !lamg pairs along with the address of the
Value location and a list of all the arguments that refer to
the formal parameter in the segment. If a formal parameter,
FX, is assigned the variable ~ as its value, the Foraal
Parameter Table would contain the entry (FX,ft), the address
of M and an inverse list of all references to FI in the
segment. See Figure 6.

Value assignments to formal parameters can be made static

(by value) or dynamic (by name.) If" vere assigned to FI
as a static value, then each time an image item that refers
to FI is added to the segment, the value of " at the time of
the addition is stored as a constant to which the argument
of the command will point. If M is assigned to PX as a
dynamic value, the argument field of the command viII be an
indirect add~ess, through the Table entry (FX,M), to K whose
value may change between succesive references. This per.its

846
ma:o;e Se(~nent }.ilc)rmal Parameter Table 8t.f)1'.,Q O:£,!
(F1X,n)
r.... ...
FX ~

c1-
~

FX ~I"'"
~

FX

Figure 6. The Formal Parameter Table.

user defined dynamic variation of image arguments while that

image resides in the Work Storage. The user might even
assign an item argument to an on-line input device, such as
the track ball, tablet, or one of the dials.

For example, he might assign the rotation angle of a

transform item to a dial. He may then use the dial to
adjust the display by sight to a satisfactory value. He can
then HOLD the argument so that it no longer tracks the
variable. Eventually he can permanently CLOSE the formal
parameter and delete tile entry from the Table. Formal
parameters can also be renamed or two formal parameters can
be merged so that they both refer to the same value.

4.2.3 BUILD MACRO FACILITIES

A very useful and powerful facility of the BUILD language

is the ability to add new functions through the use of the
BUILD macro facilities. All operations performed by BUILD
are coded as strings of text characters which specify the
sequence of actions, either internal transformation or user
interaction, required to implement the function. Using the
Macro commands an operator can compose new action sequences
from existing ones. While in the Macro definition mode all
selections made by the operator may be recorded as either
"automatic" or "dummy" selections. When the macro is
invoked at a later time, an automatic selection will cause
the particular action to be performed without user choice or
action. A selection defined at macro time as a dummy
requires that a selection be made by the user at execution
time. If action is to be required of the user at execution
time, a prompt can be defined at macro time that will appear
on the screen automatically.

847
 For example, in the implementation of the system supplied
GET command, a menu is displayed showing the contents (by
name) of the Temporary Library. The user would choose the
element he wishes to add to the current image in the Work
Storage. The person defining the macro may wish that the
user be allowed to choose only a subset of the Temporary
Library that is kept in a separate list (e.g. a "parts"
list.) The operator might define the function GETP by
selecting MACRO, followed by the operation GET. At this
point the contents of the Temporary Library would be
displayed. The person would then choose (as an "automatic"
selection) that a new table, the Parts Table, be displayed.
Since he now wants the user to select one of the parts, he
would probably type in a prompt to be displayed and then
make a "dummy" selection from the Parts Table. When a user
invokes GETP, the Parts Table will automatically appear with
the prompt. When a choice is made from this table, the GET
operation will be activated.

III many applications, the data structure facilities

described earlier may be totally insufficient. If an
applications program required a very large data structure,
it may prove infeasible to include the graphical information
in it. The display interpreter would probably be excessive-
ly taxed if parts of the data structure (and therefore the
display) bad to be swapped to and from disk ~uring every
refresh cycle. In other applications, the 14 bit accuracy
provided by the hardware would be totally inadequate, and
the programmer would have to store his geometrical data in
floating point mode, selecting (computing) a 14 bit repre-
sentation for display. (In actual fact, Adage is no worse
in this respect than any other system; anything Aore than-'l2
bits is unusual.) In either situation the programmer would
have to compile a display file, create a correlation map and
function as a "virtual buffer" machine. However, as a
consolation, this could increase his foreground processing
capabilitles since the vec~or generator could probably
process nearly continuously through the simple formats of
the display file, which requires less service from the
interpreter (see the discussion of DSPLY above).

In some respects the Adage text facilities represent the

weakest aspect of their entire system, which is heavily
oriented towards sophisticated vector graphics. The
alphanumeric keyboard is not specifically devoted to the

848
display system, but also functions as the operator's console
for the monitoring system or main processor. Since it is a
teletype unit, each character is entered in 7-bit ASCII
format. Hence, during input, each character must be packed
before being displayed. A library subroutine must be used
to accept a single character from the teletype and to return
that character in a register. Another disadvantage of the
hardware character handling is that characters do not
automatically wrap to the next line when the beam goes off
the right hand edge of the screen. Both these characteris-
tics require additional software (and therefore processing
time) to implement bulk text inputting.

Furthermore, there is no facility, hardware or software,

for cursor manipulation. This very complex procedure is
useful for any text processing and is essential in a non
line-oriented environment. With text that is not defined by
line numbers, there must be facilities to show the user
where he currently is working. While typing a line of text,
he should be able to advance and backspace a cursor over
previously typed text without destroying it, but still be
able to replace a previous character by typing over it. One
software implementation of this requires that the cursor be
represented as just another character in the text string,
which means that the character string must be constantly
manipulated (e.g., by pushing it apart to insert the
cursor), to insure that the cursor is in the right position.
Another method would be to maintain an x,y position for the
cursor. This position would be associated with a particular
character in the string. Establishing and maintaining the
correct coordinates involves considerable progamming. (1
hardware implementation might simply use a parity bit in the
character to indicate the position of the cursor.)

1. Sutherland, I. E. "SKETCHPAD: A man-machine graphical

communication system", Proceedings SJCC, 1963.
2. Hagan, Thomas J., Nixon, Ri~hard J. and Schaefer, Luis
J. "The Adage graphics terminal." Proceedings FJCC
(1968), pp. 747-755.
3. Myer, T. H. and Sutherland, I. E. "On the design of

849
 display processors." C. ACM 11, 6 (June 1968),
410-414.
4. Sproull, Robert F. and Sutherland, I. E. "A clipping
divider." proceedings FJCC (1968), pp. 765-775.
5. Gray, J. C. "Compound data structures for computer
aided design: a survey." Proceedings 1967 ACM
National Conference, pp. 355-365.
6. Machover, Carl "G~aphic CRT te~minals - characteristics
of commercially available equipment." Proceedings
FJCC (1967), pp. 149-159.
7. Rapkin, Michael D. and Abu-Gheida, Othman M. "Stand-
alone/remote graphic system." Proceedings PJCC
(1968), pp. 731-746.
8. Ninke, W. H. "A satellite display console system for a
multi-access central computer." Proceedings IFIPS
(1968), pp. E65-E71.

850
 STORAGE TUBE GRAPHICS
A COMPARISON OF TERMINALS
A. van Dam
and
J. C. Michener
Center for Computer and
Information Sciences,
Brown University,
Providence, Rhode Island 02912,
U.S.A.

Publisher's note: This text is a reproduction of the computer output from the
Hypertext Editing System.

851
 There is a growing demand for low cost computer graphics
for the small scale computer user or for the user who would
rather have easy access to a somewhat less sophisticated
console than have very limited access (a few hours per day
or even per week) to a more powerful but far more expensive
device. The possibility of obtaining a work station with
random positioning and vector capabilities as well as
character writing speeds many times in excess of a teletype
is very attractive. Such a work station maybe used both as
a time-sharing terminal and as an I/O device for a small
mini-computer, as well as for solving conventional graphics
problems at an affordable price.

An interesting possibility for a slightly larger scale

user is to create a cluster of two to five graphics work
stations buffered from a large time-sharing multi-
programming system by means of a small but ttmicroprogramm-
able" buffering computer. This buffering computer would
reduce the load on the time-sharing system while providing
faster response to its work stations. Certain tasks such as
light pen correlation, pen tracking, cursor manipulation for
text input, and homogeneous coordinate transformations and
windowing of geometric displays occur universally in comput-
er graphics; rather than buying expensive special purpose
hardware or executing these tasks in software, it might be
better to implement them in the "firmware" (i.e. as a
microprogram) of the microprogrammable computer. Communica-
tion support should also be written in the firmware rather
than in the much slower target language to preserve speed
and a maximum of core for user's programs.

The technological developments which have resulted in the

hardware described in the body of this paper were noted a
year ago by Ruben (11J. He describes several terminal
configurations and while we disagree by several thousand
dollars (based on today's technology) with his optimistic
estimate of $10,000 as a price for a terminal with a
(prorated) small standalone computer, we do agree whole-
heartedly with his prediction of cheaper terminals to come.

1.1 THE REFRESH PROBLEM.

In order to have a flicker free picture with any

852
refreshed display, the entire picture must be displayed 30
to 40 times per second, which requires a high data rate.
With the picture stored digitally (usually in a core memory)
as point and line coordinates, fast logic is needed to
convert the digital representation to beam voltages, and a
high power, fast deflecting, random plotting CRT is needed
to draw the picture. Thus the crucial point has been to
find techniques for storing picture information in other
than digital memories. storing a picture in the analog
X-Y-Intensity form would eliminate the need for a core
memory, and, while still requiring analog storage (e.g., a
video disk), would at least reduce the requirements for
high-speed D-A logic. Even better would be to incorporate
this analog storage mechanism in the viewing screen itself,
thus eliminating both separate analog storage and the high
data rate entailed by the need for refreshing the display_

Several technologies have provided solutions to the

problems of low-cost graphics work stations. The two most
successful approaches have been to store the picture on the
face of a direct view storage tube (DVST) (where the user
can see it)# and to store it as a video signal on a disk to
be displayed on a television monitor. In this paper,
commercially available DVST terminals will be compared
extensively, while video displays will be mentioned only
briefly. The main reason for this is that DVSTs are more
suitable for a small individual installation such as we have
here at Brown Oniversity. Another reason is that commercial
video display systems are only now leaving the developmental
stages while one of the DVST terminal manufacturers has been
in production for over a year. A standard and concise
review of display hardware which explains basic considera-
tions only touched on here is found in [7].

1.2 VIDEO SYSTEMS.

Currently, video techniques are the basis for various

systems of graphics work stations. Typically, in such a
system, when the computer wishes to output a picture to a
terminal, the picture is first drawn on a high precision
CRT. This image is scan-converted (via a TV camera tube) to
a video signal which is stored on a particular section of a
video disk; each of the individual terminals is refreshed
from its own section of this disk. An advantage of video
technique is that video mixing of computer generated infor-
mation with televised images (e.g., of a person or of

853
hardcopy) is easily accomplished, as in split screen
presentation.

One of these systems is found at Doug Englebart's Center

for Augmenting Human Intelligence at the Stanford Research
Institute. Another has been developed for the BAND corpora-
tion by IBM (3]. Another system, developed at the Universi-
ty of New South Wales in Australia, is reported on by Rose
[9, 10] and Macaulay [4]. Miller and Wine at RCA are also
developing a video display system (5,6].

For these television systems the cost of expensive

control hardware is pro-rated among the 10 or more inexpen-
sive television work stations, achieving a very reasonable
cost per terminal. However, when fewer work stations are
desired the pro-rated expense is not very favorable. Also
video signals from a central, time-sharing computer can not
be transmitted any great distance, because of the data rates
involved. Thus video systems are best suited for a larger
installation commonly found in a research and development
department of a major company or perhaps for a library
information retrieval system.

1.3 SUMMARY OF DVST CHARACTERISTICS.

DVST's exhibit slower writing rates than conventionally
refreshed or TV tubes, and graphic elements which are less
bright (and of poorer contrast with respect to the glowing
background) but flicker-free; an unbeatable information
density results, allowing, for example, 4000 tiny but still
legible flicker-free characters. Because of the self-
storing characteristic of the DVST, it is entirely reason-
able to time-share driving electronics between two tubes,
allowing split screen techniques (say, one for static
ove.rview and one for dynamic local editing) at an increment-
al cost of under $3,000. The same self-storing charac-
teristic makes selective erasure impossible, and that,
coupled with long writing times, in turn makes these tubes
unsuitable for dynamic changes. Por changes to low density
pictures, however, rewriting may be accomplished in several
seconds.

2.1 DVST IMAGING MECHANISM.

As explained above, the price limitations of the small

scale user or a remote terminal user are met today more

854
successfully by a DVST type workstation than by video.
Briefly a direct view storage tube stores picture informa-
tion on a dielectric 1 material intermixed with tbe phosphor
screen. Since this material has a high secondary emission
ratio, the high power (writing) electron beam cuts a
positive template in the initially uniformly negative back-
ground. A low power (illuminating) flood beam arrives at
the positive parts (i.e., the picture template) with suffi-
cient velocity to excite the phosphor ~nd to knock out
enough electrons to maintain a net positive charge. The
flood electrons are repulsed by the negative parts (back-
ground) tbus arriving too slowly to either excite the
phosphor or knock away many electrons, and thereby maintain-
ing and even increasing the negative charge of the back-
ground. A DVST based on this bi§iab!~ principle can retain
a picture indefinitely, but viewing time should be limited
to about fifteen minutes since subsequent erasure becomes
less complete with viewing time.

2.2 DVS! ATTACHED TO A TIME-SHARING SYSTEM.

In this section we discuss considerations appropriate to

a DiST connected over a relatively low speed (synchronous)
line, and in the next section, local computer attachment.

When a DVST display is used as a time-sharing terminal,

the main consideration is what data rate to use in transmit-
ting data to the termina14 We vill assume that the user
wants to have his information plotted as rapidly as is
within his means. Z Time-sharing systems are usually
designed for synchronous data transmission, that is trans-
mission at a fixed rate, as opposed to asynchronous trans-
mission, where data is sent only when the receiving station

1. If, instead, the image were recorded on a dialectic

material, it would no doubt be some kind of commie "plot".

2. We know of one application to numerical parts program-

ming in which this was not the case. It was found that
limiting the output rate to 110 Baud gave the parts
programmer a sense of motion as he watched the path of the
tool cutting head being displayed.

855
is ready for it. 3 A DiST terminal can be used at teletype
rates, but the terminal will spend a lot of time waiting for
data. Indeed, one of the attractive features of these
terminals is that they can plot data at synchronous data
rates from 110 up to 1200 or 2400 Baud, depending on the
terminal.

The upper limit of data transmission rate for a terminal

can be determined as follows: consider the slowest single
command; typically it is a vector command to draw (say) an
eight inch line. Suppose it takes the terminal eight
milliseconds to plot this vector. With synchronous data
transmission, a character arrives every so many millise-
conds, so either the terminal must have a complex buffering
scheme, or the terminal must be ready to execute the Q~l
command (which could be a single character 10 bits long, 7
or 8 information and 3 or 2 control bits) by the time that
command has been accumulated, bit by bit, in its simple one
character buffer. Thus the maximum transmission rate can
only be ten bits in eight milliseconds, i.e. 1200 Baud.

In general, then, the synchronous data rate must be

chosen so that in the worst case (i.e. slowest plotting
command) the DVST terminal will always be ready for new data
when it arrives. Otherwise the terminal might just lose
data, or perhaps might start plotting a new line when it had
only partially finished the previous one. On some ter-
minals, data rates higher by a factor of two or more can be
used if the software in the computer checks for extreme
cases and takes special precautions, for instance sending a
no-op command, repeating the same graphic command several
times in the output data, or breaking the command into
several smaller pieces logically equivalent to the original.
Some time-sharing systems may not even be able to handle
data rates as high as 1200 Baud; one is, of course, limited
to what is available. Even at its highest synchronous data
rate, a DVST terminal waits for data after all commands
except its slowest ones, in consequence of the "worst case"
considerations.

Closely allied to the data rate consideration is the

"data compaction n , i.e., the degree to which the various

3. DVST terminals are designed to work in what should be

called "character asynchronous" mode. In this mode indivi-
dual characters can be sent at any time, but the bits within
the characters must arrive at a fixed rate. In this paper,
synchronous viII be taken to mean the transmission of a
block of data at a fixed rate. Asynchronous will mean
sending a character only when the terminal is ready for it,
as determined by a "ready" flag.
ccmmands available for representing picture data are com-
pactly encoded. This question becomes more critical at
lower transmission rates since each data bit takes longer to
transmit and the terminal is waiting for data most of the
time. The more the terminal can do per character, the less
the inconvenience to the user.

For example, drawing either vectors or characters via

pOlnt-plotting commands would be unacceptable, requiring
high transmission rates to even match teletype character
speeds. Thus all DiST terminals offer character and vector
generators. Additional incremental modes in which graphic
data are specified by one or two characters of delta-X,
delta-Y information (instead of the standard four) as well
as a curve plotting mode can lead to significant gains in
the ability to represent a picture compactly.

2.3 DVST ATTACHED TO A SMALL COMPUTER.

In addition to use as a terminal directly connected to a

time-sharing system, a DVST display can be buffered from the
time-sharing system by a small computer. Also it can be
attached to a (small) stand-alone computer in order to do
relatively complex but still cheap graphics. When a DVST
terminal is attached locally to a computer, if it is
desirable or necessary to maintain compatibility with remote
(DVST) operation, one must still use a synchronous communi-
cations link between the computer and the display, and the
above considerations apply in full force.

It is, however, possible to achieve a considerably higher

plotting rate if one uses asynchronous communications, that
is, as mentioned above, a link in which the terminal signals
the computer as soon as it is ready for more data. The
computer responds with data at a rate between SOK Baud and
1.6M Baud (depending on the terminal) until the terminal
raises its "busy" flag. Passing enough data takes on the
order of 200-600 microseconds at the slowest rate, on the
order of 8-20 microseconds for the fastest rate. The
terminal now waits for data during such a small interval
compared with 8-33 milliseconds at 1200 Baud (i.e., from 1
to 4 ten-bit characters), that a plotting rate improvement
of four to ten times is not unreasonable for a diverse
picture.

Considering the high data rates that are available with

an asynchronous link, the compaction of data is no longer as

857
significant from the point of view of transmission time as
it is from that of data storage. This latter however is
very important, especially since we are assuming the local
computer is yuite small. An emphasis on the use of short
incremental graphic modes is thus still relevant. (These
will be described in more detail below.>

So far we have described two typical installations of

DVST terminals; now let us see in some detail what is
commercially available.

3.1 AVAILABLE TERMINALS.

The three DYST Terminals being marketed today for general

use are the Advanced Remote Display Station (ARDS) manufac-
tured by Computer Displays Inc., the 400 - (10,12,15,20)
series terminals manufactured by Computek Inc., and the
T4002 terminal manufactured by Tektronix Inc. Digital
Equipment Corp. makes a "KV Graphic System Option" for
their PDP-8 series of computers which is also based ona
DVST. This is discussed independently in section 6.1 ,
since it is only available for the PDP-8 computer and not
for general use as a terminal.

3.2 THE BASIC STORAGE TOBE.

All these companies use the Type 611 Storage Display Unit
built by Tektronix, which has a 6-1/2" by 8-1/4" screen,

4. The technical details presented below are true at the

time of writing, but are subject to change without notice.
They have been gathered from manuals, specifications sheets,
visits to the manufacturers, and innumerable phone calls.
At Brown University we have hands-on experience with an
ARDS, connected to an Interdata mod 3, which will soon be,
in turn, connected to our IBM 360/67.

858
resolution of approximately 300 x 400 line palLs and an
erase time of half a second.

The 611 will hold a picture 15 minutes without visible

degLadation; although it can hold a picture longeL than
this, Tektronix recommends this limit because eraSULe of
stored information becomes more difficult for Ion geL viewing
times. In order to effectively extend this time limit, and
also extend the life of the tube in case the operator goes
away and leaves the display on, the display has an automatic
feature which reduces the current on the flood beam. Thus,
if no new information is stored on the screen for approxim-
ately one minute, the 611 drops from View mode, in which the
stored picture can be seen plainly, into Hold mode in which
it can be seen only faintly. If the operator pLesses the
View button or if new information is written (either from
the computer or from the keyboard) the 611 switches into
View mode for another minute (from the time of the button
push or after the last piece of information was written).

The 611 is available with the long axis oriented hori-

zontally or vertically; cor and Computek offer display
terminals with either of tbese orientations but Tektronix
(currently) offers only the horizontal orientation in the
T4002. Horizontal orientation would probably be preferable
for a text editing application while vertical might be
better for graph plotting.

A special (but standard) feature of the 611 is the

"write-through" ability in which the writing beam is turned
on only weakly and is kept in motion so that it neither
records new information nor erases old information. The
manufacturers have used this technique to implement a
non-storing cursor which shows the current beam position to
the user to provide him with visual feedback. The terminals
provide various controls for manipulating this cursor; these
controls are described below.

The currently quoted tube life of the 611 is 2000 hours.

859
As a tube ages it becomes harder to store information; thus
while a dot writing time of less than 20 microseconds could
be used with a new tube, an older tube will require the full
20 microseconds to store a dot. Actually there are some
indications that the 20 microsecond dot time is overly
conservative, and that Tektronix may revise their
specifications.

Another effect of aging is that the phosphor becomes less

efficient. This results in reduced light output from the
trace of the electron beam. However, at the same time, the
contrast ratio improves because less background light is
produced. Thus the overall degradation is not as severe as
might be thought. Indeed, the term "tube life" is mislead-
ing, since with the 611 this figure indicates the time at
which nc f..!!!:!.her degradation will be noticable. Thus a 611
can still be useful after its "life" has expired. For
instance an early COl terminal has been in heavy use for one
and a half years.

3.3 OUTPUT FACILITIES.

Generally, the output sections of the terminals operate

in certain modes, each mode determining how bit configura-
tions are interpreted. The main mode is character mode; in
this mode data characters received are interpreted either as
a character to be plotted or as an ASCII control character
(e.g., carraige return, line feed, ring bell) depending on
the status of the two high order bits. Because visible
characters can be intermixed with control characters, this
mode might be called character/control modee Certain con-
trol characters which have no assigned meanings for (say)
teletypes have been given special meanings for the storage
tube terminals (e.g., "erase screen" and "send X-Y coor-
dinates to computer").

It is some of these (previously unassigned) control

characters which establish different graphics output modes
for the DVST terminal. In these modes data representing X-Y
coordinates are plotted (as points or lines, etc.) until
the mode is changed back to character/control mode via one
of the following schemes.

According to ASCII conventions (which are adhered to by

860
COl and Tektronix) any control character must immediately be
recognized as such and its proper function must be executed.
Thus, by convention, all control characters reestablish
character/control mode {exiting from any graphics mode} as
well as performing their special operation. (Thus, at least
on a conceptual level, when changing from one graphics mode
to another, the terminal passes briefly through the
character/control mode.) Of course, this scheme implies
that graphics data must be distinguishable from control
characters; this is typically implemented by setting a high
order bit in all graphics data characters.

Another scheme, used by Computek, requires that a special

"escape" character be sent to cause the terminal to enter
character/control mode from any of the graphics modes.
Having an escape character, rather than setting aside a bit
in each graphics data character, gives this scheme an
advantage in representing graphic data. (See below in
section 4 .. 5.)

3.3.2 Character and Vector Generators.

As mentioned before, all the terminals come equipped with

character and vector generators, except that Computek sells
two cu t-down but f ield--upgradable terminals, the 400-10 and
400-12, which have only vectors or only characters, respec-
tively. All the character generators display the standard
96 characters of the ASCII character set which includes
upper and lower case letters, digits and special symbols.
The cor terminal can display 50 lines of 80 characters (in
vertical orientation), the Computek terminals can display 40
lines of 85 characters and the Tektronix terminal can
display 37 lines of 85 characters (the latter two in
horizontal orientation). The CDr and Tektronix characters
are drawn on a dot matrix; the Computek generator displays
characters as straight and curved segments as described in
[ 2] ..

The vector generator (and random positioning ability) of

each terminal is based upon a rectangular coordinate qrid of

861
"viewable points"; 5 in the Tektronix T4002 the grid is 1024
x 740, in the Computek terminals it is 1024 x 800, and in
the COl ARDS it is 1415 x 1081.

In the so-called "long" modes, each terminal accepts four

ASCII characters of transmitted data as one command, two
characters each for the X and Y coordinates. The terminals
can both position the beam to viewable points (for example
to position text there) and draw vectors from one point to
another. In addition to the long vector modes, each
terminal has different "short" submodes which require fewer
characters of data. See sections 4.5 and 4.8 for further
details.

3.4 TEBftINAL KEYBOARDS.

Having looked briefly at the output facilities, we turn

now to the primary means of input - the keyboard. The
keyboards used in the three terminals are electronic {rather
than electro-mechanical, and can input any of the 128 ASCII
character codes. Unfortunately (to our way of thinking),
none of them have a physical interlock to prevent a typist
from pressing two or three keys at once. Of course the
keyboard logic is designed to allow "finger rolls" (very
rapid typing), but still it is possible to depress a key
without its character being input. To a typist used to
"feeling" each character going into the machine (e.g. with
an IBft keypunch or Selectric Typewriter), errors which he
would otherwise catch immediately might easily go undetected
on the solid state keyboard.

3.5 LINE AND LOCAL MODES.

There are two operating modes commonly available which

5. In a graphics terminal, one distinguishes between

addressable, viewable and resolvable points. The number of
addressable points is determined by the number of bits in
the X-Y registers. Viewable points are those addressable
points which fallon the CRT screen. The number of
resolvable points is determined by the properties of the CRT
itself; thus for these terminals this is constant, being
approximately 400 by 300. The ARDS has an l1-bit address
space, while the others have a 10-bit address space.

862
determine whether 1) typed input is immediately displayed by
the terminal as well being sent to the computer (Local mode)
or 2) merely passed by the terminal to the computer which
must "echo" the character back to the terminal if it is to
be displayed (Line mode). In either mode the data is always
sent to the computer; the ~nlY difference is whether or not
the data must be echoed back from the computer. with a full
duplex communications line (one allowing simultaneous
bidirectional transmission), Line mode is normally used;
with a half duplex line (bidirecional but not at the same
time), Local mode is usually employed (so that line-
turnaround need not be performed for each character).
Although Line mode requires extra work by the computer, it
provides detection of transmission errors (in addition to
parity checking) and is also good for protecting passwords
(i.e., the password is not displayed as typed).

In the ARDS, the Line/Local mode is under control both of

the terminal user and the computer software; in the Computek
terminals only the operator can set this mode. In the
T4002, Line/Local mode is always determined by whether full
or half duplex is being used, except that in half duplex
mode, the computer software can force Line mode for typing
in Fasswords, etc.

In addition the T4002 has a switch for an offline mode in

which no data is sent to or received from the computer at
all; in the other terminals the same effect is achieved
merely by disconnecting the interface to the computer when
in Local mode. An offline mode is desirable for adjusting
the terminal and for testing auxilIary equipment attached to
the terminal (as well as for demonstrations when the
computer is "down").

Having established the similarities of the three general

purpose DVST terminals as a baCkground, we turn now to
features which represent the advantages and disadvantages of
the individual terminals. After reviewing these in detail,
we shall attempt to indicate in section 5 what sort of
installation each terminal is best suited for.

~3
 Major differences between the terminals are found in the
features provided for inputting information. We shall first
discuss character input, later turning to two-dimensional
graphic input.

ij.1 TEKTRONIX CHARACTER INPUT.

The operator of a Tektronix T4002 terminal has two modes

of character input available to him at all times: g1£g£!
and £Q!.E2~. (This is completely independent of the Line
and Local transmission modes.) Briefly, in the £2!1!,EQse
mode, characters are stored in the terminal in a digital
buffer memory; this is explained below. In the girect mode
characters are sent to the computer as they are typed;
remote or local echo (via Line or Local modes, respectively)
then displays the characters at the point where the non-
storing cursor (a small square) is displayed and advances
the cursor to the next character position. In general, when
the computer outputs data, the cursor is displayed after the
last character plotted or at the last point of graphic data
plotted. The cursor can be controlled by special buttons
which move the cursor up, down, left or right one space, or,
if held down for more than one third of a second, move the
cursor in the indicated direction at twelve steps per second
until the key is released. When a character is typed into
the rightmost character position, or if the cursor is
stepped to the right off the edge the cursor "wraps" to the
left margin on the same line. Thus typed and plotted
characters need to be interspersed with carriage return
line feed commands.

The other character mode, the £Q~Q2g mode, is one of the

major advantages that the T4002 has over its competitors.
In this mode an eighty-five character line of text recorded
in a digital scratch pad memory is displayed in a small,
non-storing, refreshed area across the bottom of the screen.
This area has its own cursor (an underline, not a square)
and is used to accumulate an entire message before sending
it to the computer. Since the characters are recorded
digitally and not on any part of the dielectric mesh,
editing changes can be made locally: the backspace key
deletes preceeding characters, one at a time, which can then
be retyped. Tektronix plans a better version in which
characters can be deleted and inserted by first properly
positioning the underline cursor and then operating the DEL
key (one of the standard ASCII keys) for deletion or any
normal character key for insertion. When it becomes avail-

864
able, this improvement can be field-installed in any exist-
ing T4002. This non-storing, refreshed area is obtained via
modifications to the dielectric/phosphor material of the
basic 611 cathode ray tube; these modified 611 displays are
not (currently) commercially available (except as part of a
T4002 terminal). The great advantage of this mode is that
the user can accumulate and check a whole line of typed
input before sending it to the computer.

When the SEND button is operated, the characters are sent

from the scratch pad memory to the computer exactly as if
they were ordinary typed input (being displayed at the same
place as if they were newly typed input), and the terminal
drops from the compose mode back into the direct mode. At
the same time, refreshing of the scratch pad text line is
ceased. The scratch pad memory is not erased, however; if a
transmission error occurs, compose mode can be re-entered
and the entire line sent again, immediately. The only
undesirable limitations of tbis feature we see are that the
computer can not write into the scratch pad memory and that
because of the implementation mechanism, the refreshed area
can not be positioned vertically under program control for
"in-place" editing.

4.2 CDr AND COMPUTEK CHARACTER INPUT.

The Computek and CDr terminals have no scratch pad

memories comparable to Tektronix; they have only what
Tektronix calls the direct mode. Thus software must be
involved in making corrections to typed input. An incorrect
character can be recognized by the operator only after it is
displayed (that is, after it is stored on the DVST screen),
and such characters can not be erased without clearing the
whole screen, which of course necessitates re-transmitting
and re-displaying the whole screen. To avoid a complete
re-display, a typical technique for making corrections via
software is to cross out incorrect letters and delete them
internally (in the program memory) as the user operates the
backspace key; when he starts typing new characters they are
displayed after the last crossed out character.

Having reviewed the text editing possibilities on the

Computek and CDI terminals, we now turn back to the
question--answered for the T4002--of where typed characters
are displayed. For CDI and Computek terminals, like the
Tektronix in Direct mode, characters are displayed at the
current "beam position" which is set by all the graphic
(point, vector) commands and which is incremented to the

865
right by displaying a character. Unlike Tektronix however,
COl and Computek offer optional hardware for right margin
detect, which forces a carriage return - line feed, so that
the next character plotted (or typed) is on the next line
below. These options include a bell which is rung automat-
ically when the right margin is violated; the bell can also
be rung under program control. A bell of this sort lets one
program to set the right margin anywhere. Tekt['onix pro-
vides an electronic warning tone which indicates, like on a
normal typewriter, that the typist is getting close to the
right margin; either the program or the typist has to
introduce the carriage return and line feed.

The Computek terminals provide four cursor control keys

similar to the Tektronix Keys; if one of the keys is
depressed briefly the cursor is stepped one character in the
indicated direction; if held down, the cursor slews at 3
inches per second until released. This is considerably
faster than the Tektronix rate of twelve character spaces
per second. The ARDS has only a backspace and an advance
key (space bar), and these do not repeat if they are held
down.

The current beam position on the Computek is also

manipulated via the graphic (i.e., 2 dimensional) input
devices available. This leads to complications as we shall
see below in section 4.3.1. cor makes a point of keeping
the graphic input X-Y coordinates logically (and physically)
separate from the beam position; the character plotting
position is always the beam position, and is thus solely
under computer control. Thus the ARDS is slightly more
flexible since the computer mayor may not be programmed to
identify the input X-V with the beam position.

4.3 GRAPHIC INPUT.

We turn now to the question of inputting two dimensional

information. In this area Tektronix is furthest behind
Computek and CDr: although Tektronix allows the attachment
of user-supplied auxilliary equipment (such as a graphic
input device) they currently offer no input device as either
standard or optional equipment.

There are currently three graphic input devices avail-

able: the joystick, the mouse, and the tablet. (The
joystick and mouse are comparable in price; the tablet is
$1000 to $1500 more.) A joystick digitizes the position of

866
a handle which is f~ee to move about a single fixed point.
A mouse is a small hand-held box which digitizes the
position of two o~thogonal wheels on its bottom surface.
These roll as the mouse is moved across a flat surface,
resolving vecto~ motion into X and Y components. A tablet
digitizes the position of a stylus held in the hand above o~
on the writing surface of the tablet which is usually at
least 10 inches square. Although mo~e expensive, a tablet
is much more natural to use than eithe~ a mouse or joystick
because it is like using a pencil or ball point pen on a
piece of paper.

The Computet joystick, when activated by the operator

(and also enabled by the computer), completely cont~ols the
beam position and the circular cursor. The four cursor
motion keys have no effect when the joystick is in control.
Whenever the computer is to output any data (usually
p~ompting or feedback messages in response to some user
action) it must disable the joystick xi~ certain control
characte~s (otherwise the plotted data will be splattered
together at the current beam position). It must re-enable
the joystick afte~ it is done if the ope~ator wishes to
continue to use the joystick. (These are the complications
referred to above.)

There are three buttons and tvo mode switches on the

joystick. Depending on the switch settings and the button
pushed, the joystick will send one of five special (ASCII
control) characters to the computer indicating what the
operator wants to do (create a point, d~aw a blanked or
unblanked vector or curve, etc.). The computer (usually) is
programmed to respond by reading the X-Y coordinates of the
joystick (eight significant bits) and then performing the
indicated function.

Even if no special input device is obtained with the

Computek terminal, the four cursor control keys can be used
for this purpose because these keys affect the same regis-
ters that the joystick does. However, the time required to
position the cursor accurately can be five seconds and up
(to ten or fifteen) depending on the skill and coordination
of the user; we feel this is woefully inadequate for all but
the most limited situations in interactive graphics since

867
the user will tend to lose his train of thought in this
time. Its main attraction is that it costs little extra. 6

Computek offers two versions of its tablet: one with

eight bits and one with ten bits of resolution. The tablet
can run in three modes: freerunning (data updated every 300
microseconds), strobed (data updated when the stylus is
moved) and demand (data updated upon request). Two inter-
faces are provided; one is for attaching the tablet to its
own data modem for general use, the otheL is for use with
the Computek terminal.

When the tablet is interfaced to the 400 terminal, the

input to the computer is sent in absolute vector data mode
format (with an additional bit set to indicate whether
pressure is being applied to the stylus tip) at intervals as
indicated by the freerunning, strobed, or demand mode. (In
local mode, i.e. half duplex operation, the scope can be
driven directly from the tablet; no line turnarounds are
necessary.) The tablet is treated as a separate device:
the command to read the position is not the same as the
command used to read the joystick position as mentionned
above. No buttons (comparable to those on the joystick) are
provided with the tablet; this is not any problem since the
programmed function keys (see section 4.4, below) can be
used instead.

4.3.2 CDI Graphic I~Q!~

The Computer Displays Inc. graphic input devices work

differently from the Computet joystick. The interface for
these devices contains X-Y registers which are independent
of the beam position registers of the lRDS output section.
Thus when the mouse or joystick is activated, the cursor is
locked to the input device's position, but still the
computer can output information randomly on the screen in
the normal fashion, without having to disable and enable the
input device. When the operator no longer needs the graphic
input device, be can disable it and the cursor will be
displayed at the beam position.

6. The same four cursor control keys on the Tektronix can

not be used for graphic input, since the computer can not
read the Tektronix cursor coordinates. Thus there is no way
of even simulating graphic input.
 On the cor joystick and mouse there is a set of three
buttons which enable the user to signal to the computer
whether he wants to create a point, a line, or some other
(programmed) function. The point and line buttons send the
particular ASCII control character which forces the ARDS's
output section into point or line mode (respectively). This
character is followed immediately by either the absolute
position (for the point button) or the position £elati~ to
the current beam position (for the line button) in the
proper four-character format. Thus, if the ARDS is in Local
mode, the proper point or incremental vector will actually
be plotted on the screen without any need for a response
from the computer. An option is available to let the
computer request the X-Y coordinates. While older input
devices provide nine significant bits, current models give
eleven bits (ten bits plus sign, but the lowest bit is not
accurate) for each coordinate in the four-character format.

Data on the CDI tablet is not presently available. It is

planned, ho~ever, that while the tablet will have several
new features, the user will be able to do the same things
with it that he can now do with the mouse.

Reviewing the cheaper (non-tablet) methods of graphic

input, we see that the Computek joystick requires more
support from the computer than the COl mouse or joystick in
that the computer must enable the computek joystick (and
disable it in order to write any messages), and that the
computer must issue a special command to read the cursor
position while with the ABDS none of these things are
necessary. Note that in half duplex operations, issuing the
read X-Y command, receiving the coordinates, plotting some
response, and preparing to receive more data requires four
line turnarounds in all. 7 One of the buttons on the
joystick can reduce this to two turnarounds because the
special control character it generates has been chosen to be
the "read X-yo control character. Since in local mode this
code is both sent to the computer and echoed locally, the
terminal reacts just as if it received the "read X-yo
command from the computer and immediately transmits the X-Y
coordinates.
7. The normal line situation in a half duplex connection
with the line inactive is always that the terminal is in
"ready to send" mode.

869
 Prom one point of view the Computek technique of locking
the beam position to the joystick position is a slight
advantage, in that under some conditions the computer does
not really have to read the position. It is possible, for
instance, to imagine an application where the desired
feedback message is merely the addition of an incremental
picture subroutine drawn relative to the current joystick
position. However, in most applications, a) the computer
has to remember enough information to completely redraw the
picture, on operator command; b) it must therefore remember
the current joystick coordinates, and thus c) does have to
read the coordinates.

Consider the lRDS, on the other hand. with the ARDS in

Local mode (i.e. half duple~, the computer need do nothing
in response to a "create point" or "create vector" push-
button since the local echo plots the point or vector
immediately without computer intervention. In Line mode
(i.e. full duplex or with the high speed computer inter-
face), the computer need only echo the input (a mode setting
command and data) back to the terminal. In either case,
some incremental subroutine could be drawn as additional
feedback, if desired. Note that for the lRDS in half
duplex, no line turnarounds are needed unless additional
feedback is desired, in which case two turnarounds are
required (one to output the feedback, the other to re-
establish the normal send mode). This compares favorably
with Computek which, as noted, requires four in normal half
duplex situations except when the "read X-Y" button is
operated. Indeed, note that a Computek terminal with a
joystick f~,guires support from the computer: in an offline
demonstration or testing situation an operator can not draw
vectors with it, whereas he could with an ARDS.

4.3.4 Picking_!~r.2J!s Positioninh

Most refreshed displays provide the operator with one

graphic input device: the light pen. This device is ideal
for picking an existing graphic element or keyword from the
display. It is not, however, immediately possible to
indicate a new position in the middle of a blank area. To
do this, light pen tracking must be implemented, which may
be hard or easy to do depending on the individual terminal.
Once implemented, however, pen tracking supplies not only a
single position but also a sequence or "path" of positions,
suitable for example, for "curve drawing" or for input to
character recognition schemes.

870
 On some displays, positional information (as opposed to
picked information) can be input by obtaining one of the
graphic input devices mentioned above (mouse, joystick,
tablet); on many graphics terminals, however, interfacing
such devices is very expensive, possibly on the order of ten
to twenty thousand dollars! The positioning device most
commonly obtained for a refreshed terminal is a data tablet
(partly because if one can afford the interface, one can
afford a tablet).

Usually, along with the tablet, a comparator will be

obtained which can be used to implement a picking ability.
A comparator is an analog device which compares the analog
X-Y voltages of the CRT beam with the analog X-Y voltages of
the tablet stylus; when the two agree (within a small
tolerance), the comparator causes an interrupt, thereby
acting like a light pen. Even if a light pen is available
on the terminal, a comparator enables the user to input both
positioning and picking information with the tablet stylus,
so that be does not have to change back and forth between
input d€vices~

On a DVST terminal, it is, of course, impossible to

obtain the picking function of a light pen or comparator in
the easy manner which a refreshed terminal allows, simply
because the picture is displayed very infrequently. Thus
the manufacturers have been forced to make positioning
devices the main source of graphic input. The problem of
picking graphic elements must now be solved to some extent
in the software, as explained below. (Note also that to
obtain a continuous track of position information it is
necessary that the computer be able to poll (ask) for. this
information. This is standard on the Computek terminals,
but the CDr mouse or joystick requires a special option to
do this~)

Several methods of obtaining "picking" information from a

DVST have been worked out. Either it can be done with
special hardware (a comparator, in which case the picture
must be redisplayed), or by doing a lot of work in the
software (or perhaps the firmware).

One hardware technique for use with the comparator is for

the operator to position the input device, then signal the
computer that he wants to pick something. The computer
redisplays the whole image (at least those parts which are
not supposed to be protected from "pen-sees") and the
comparator interrupts when an analog match is made. The

871
drawbacks with this technique include the time required to
recalculate, transmit, and paint the picture (especially
with slow communications lines), and the fact that the input
dev~ce might not be positioned accurately, thereby causing
no "detect" to occur and forcing the computer to redisplay
the picture a second time (after the user has re-positioned
the device).

An improvement would be to segment the display geometric-

ally, either via an arbitrary X-Y grid (probably not very
good) or logically according to subdivisions implicit in the
particular application. This might require some discipline
in building the display file (such as forcing all the
commands for a particular logical region to be grouped
contigously), but the overall processing time could be
reduced since only that part of the display file correspond-
ing to the region containing the X-Y input coordinates
(transmitted to the computer) need be redisplayed.

If a comparator is not obtained, and the recognition is

to be done in the software, the matching can be done either
by a "closest" scheme or a "first within a fixed tolerance"
scheme. (A comparator, having no memory, can vork only by
the latter scheme.) The same approach of regions can be
used, or an approach could be (and has been) developed which
involves storing an envelope ("box") for each "detectable"
graphic entity. The X-Y position is then simply checked
against the dimensions of each box, to see if it lies
inside.

In a simple-minded scheme, the first such "hit" is

accepted, leaving the operator to resolve any ambiguities
(e.g., if he was not satisfied, he rejects the action and
tries again). If it happens that one box lies within
another box, the technique will fail regularly if the larger
box is the first one checked. In a more sophisticated (but
more expensive) scheme, multiple hits might be resolved by
an additional closeness criterion on the boxes, for example,
or by comparing individual graphic elements within the boxes
for closeness to the input coordinates, using a comparator
technique.

Special techniques can be used for displays of text

because of the regular spacing which is characteristic of
such displays. Briefly, the Y coordinate could be mapped
into the line number, and then the X coordinate could be
used to indicate the character within the line. Note that a

872
positioning device allows the operator to point at non-
visible cha~acters such as blanks, a pa~ticularly useful
p~operty for text editing.

4.4 FUNCTION KEYS.

One input feature which only the Computet te~minal has,

is a set of six prog~ammed function keys. These keys send
special (ASCII control) characters to the computer; the
computer can execute a preprogrammed function in response,
thus facilitating the interaction between man and computer.
These keys are placed immediately below the screen so that
the compute~ can display information designating their
current meaning. To avoid confusion, the application
designer should be aware that five of the six codes can also
be generated by the th~ee buttons on the Computek joystick.

Indeed, a programmer could think of the three buttons on

the CDI input devices as being programmed function keys, at
least when the terminal is used in full duplex mode (so that
points and lines are not automatically plotted).

Another possible source of function keys is the alphanum-

eric keyboard: a special type-in area could be established
on the screen in which the console operator could type
single character abbreviations or codes for desired actions.

4.5 OUTPUT MODES AND DATA COMPACTION.

As mentioned briefly above, cnr and Tektronix use only

six bits per character of data to represent graphics
information, setting aside one bit for parity, and one bit
to distinguish control characters (in which this bit is
zero) from graphics data (in which this code is one). This
is done to adhere to ASCII conventions requiring parity and
the immediate recognition of control characters.

Computek, by not following these conventions, can use

eight bits per character of data to represent graphics
information, giving them significantly more powerful data
modes. On the other hand, to gain this power, they must use
an escape character (which has all zero bits) to enter

873
character/control mode from a graphics mode. A programmer
for the Computek terminal must take care to always issue
this escape character lest control characters be interpreted
as graphic commands.

Of course, to draw vectors the terminals need a "from"

point and a "to" point. With the Computek terminal, the
"to" point can be specified either relatively with respect
to the "from" point (delta-X, delta-Y) or absolutely on the
X-Y grid, depending on the mode. The cor terminal has only
the relative mode, but it can plot dashed as well as solid
vectors. The T4002 terminal has only the absolute mode.

Usually with graphics equipment (and this is the case

with CDr and Computek), the from point is assumed to have
already been set (in the internal memory of the terminal)
either by a preceeding set point command or a vector
command. The T4002, however, assumes that the first data
after entering vector mode is always merely positioning
information, and thus it does not display anything for the
first four characters of data, but does treat each succeed-
ing group of four characters as a vector to be displayed.
The CDI and Computek terminals have a beam bit in each
command to indicate whether to intensify the vector or not.
The vector generator in the ARDS generates a point approxi-
mation to a vector, while the other two terminals have
stroke type vector generators. Because of the point method
of generation, vectors drawn on an ARDS are not as smooth as
on the other terminals. However, a dashed vector cabability
is much easier to build in such a vector generator, as is
automatic windowing, described in section 4.8.

4.5.2 ~hQI! Data Modes.

All the terminals have output data modes other than the
standard character/control mode and the four-character point
and/or vector mode(s). Data represented in these other
modes have fewer significant bits in X and y than in
four-character mode, because each order has only two charac-
ters (in one case only one character). Typically, these
modes represent fine detail more efficiently than the
four-character mode.

874
 Computek has a two character vector mode which contains
six bits plus sign of incremental X and Y data. Depending
on the "scale" (which is set to either: l~fgg or ~.m~11 while
in control mode), the incremental data are added to the high
order six bits or: the low order six bits of the current beam
coordinates. A vector is plotted from the current position
to the new position, either blanked or unblanked, depending
on the "beam" bit. Thus in addition to plotting fine
detail, this two-character mode can be used for rough,
approximate, large scale plotting, something neither CDI nor
Tektronix provide.

CDr has a two character mode for small scale vectors

which encodes five bits plus sign of X and Y increments. No
intensity bit ~s provided. Tektronix has a one character
incremental mode in which the beam moves to one of the
points neighbor:ing the current beam position (in one of the
eight main compass directions) and intensifies (plots) the
point if the beam bit is set properly. This mode is
intended for use in simulating mechanical digital X-Y
plotter:s. It is a ver:y fast mode: each point takes
twenty-five microseconds to plot (if the data arrives fast
enough).

Tektronix terminals have another feature which is par:t of

the four:-character ~Q§olut~ point and vector modes. If the
X-y coordinates of the next point (endpoint) to be specified
have the same high order five bits as the current beam
position, then only the two characters containing the low
order bits need be sent. This, of course, lets fine detail
within a particular area be plotted more rapidly than
otherwise; still it is not as powerful as a two character
incremental mode.

Computek builds an optional curve generator for their

ter:minal. This generator plots curves of the form
y= aX .. (1-a) X**b
(** indicates exponentiation). In general, a curve can be
plotted through any two points with specified slopes at
those points. A Fortran curve fitting program is supplied
which translates data points specifying the curve into data
words to drive the curve generator. Having a curve genera-
tor allows the programmer to store and transmit continuous
graphs guite compactly. However: the curve fitting program
may occupy too much core or be too slow for the curve
generator's advantages to apply in a small computer; in its

875
more primitive instruction set the small computer might not
have any floating point hardware, and might even lack
hardware multiply/divide.

In general, we feel that on-line curve fitting with short

vectors will be considerably faster (and possibly smoother)
than with the curve generator. However, for a background
display (e.g. a map of the united states for repeated use
with weather map displays), a "hand-tuned" representation
using curves would be desirable in terms of compact repre-
sentation and faster and smoother plotting.

Another technique to increase compaction would be to

purchase a second set of up to 96 characters. A Greek or
Russian alphabet generated via hardware would be preferable
to drawing such characters via vector strokes. CDI and
Computek viII design such a set to meet the user's require-
ments. These characters can be plotted by entering a
special character mode and issuing single character
commands.

Computek also offers a symbol generator capable of

drawing symbols up to 1.5 by 2.0 inches. Any symbols made
up of curved and straight line segments can be requested
(e.g an integral sign, flowchart boxes, circuit symbols).

4.6 MULTIPLE SYMBOL SIZES.

It is possible to obtain variable character sizes on the

terminals. The Tektronix provides two sizes as standard
equipment, one size is twice the other, normal size being
the smaller. To plot in double size one transmits a special
character which indicates that the next character is to be
double size, then that character, then a blank (to advance
the beam position properly). computek has an option provid-
ing two symbol sizes.

The ARDS multiple symbol size option allows the program

to specify a scale for the X and Y coordinates (independent-
ly) which is to be applied to characters until the scale is
specified again. Ratios of 1.0, 1.33, 1.67, and 2.0 (to
normal) are available in X and Y thus giving 16 possible
combinations.

876
 With a character generator using a point grid (Tektronix
and CDr) characters displayed at the magnified sizes are not
as pleasing as at the smaller sizes since they are seen as
discrete dot patterns, not as continuous characters.

4.7 PLOTTING SPEEDS.

The asynchronous plotting speeds of the computek and CDr

terminals are reasonably comparable. Both can plot an
average of 800 to 1000 characters per second. Also, both
drive the storage tube's beam at one inch per millisecond
when plotting vectors. However, the CDr terminal has a
lower (SDK Baud) asynchronous maximum data rate, compared
with 1.0M Baud for Computek. This means that the CDI IRDS
waits 600 microseconds while data is coming in, as opposed
to 40 microseconds for Computek, giving Computek an edge in
vector Flatting (i.e., an overhead of 40 vs 600 microseconds
on d common vector plotting time of from 2 to 8 millise-
conds, depending on the vector length). On the other hand,
the ARDS can be up to 1000 feet away from the computer and
still use the high speed mode. To achieve this with the
others, special driver circuitry must be added.

The Tektronix T4002 has a very fast point plotting mode,

where rates up to 40,000 points per second can be plotted.
Also Tektronix is much faster for character plotting: an
average rate of 2000 characters per second can be achieved
in asynchronous plotting. Since the character generator
works by point plotting, this high character speed is
probably a reflection of the point speed. Slower, however,
is the Tektronix vector generator which is a "constant time"
generator, i.e. any vector over one inch takes the same
amount of time: ten milliseconds (vectors shorter than one
inch take proportionately less time). This type of genera-
tor is less expensive to build than those used in the ARDS
and Computek terminals, but vectors longer than one inch are
drawn more faintly the longer they are. Thus to have a
uniform plot, all vectors must be less than or equal to one
inch.

The maximum synchronous speeds that can be sustained

877
without special programming considerations are as follows:
Computek 2400 Baud, COl - 1200 Baud, Tektronix - 1800
Baud.

4.8 WINDOWING.

The Computek and Tektronix displays have 1024 by 1024

addressable points (distinguished from viewable points as
explained in section 3.3 above). This point matrix exactly
fits the long axis of the 611 storage tube, but in the short
direction the tube is 800 (Computek) or 740 (Tektronix)
points wide. If one attempts to display a picture which is
somewhat bigger than the screen, parts will be cut off which
fall outside of the visible area in the direction of the
short axis. However, parts outside in the long axis
direction (and parts which are more than about two incbes
from the edge in the short axis direction) will be wrapped
(coordinates reduced modulo 1024) so that the picture will
be quite confused (unless software edging is performed,
which is very slow).

The ARDS performs a form of windowing so that wrapping is

reduced. It has a point matrix of which the visible points
form a 1415x1081 submatrix. The ARDS has analog accumula-
tors for the beam position in which the range of linearity
permits pictures to be drawn eight inches off the screen in
any direction before any distortion occurs. 8 If a closed
incremental picture (e.g. a large circle) is drawn which
exceeds even the linear range, no wrapping will occur, but
the ending point viII not coincide with the starting point.
Also, because the IRDS generates point approximations to
vectors, the visible portion of any vector which runs from
on- to off-screen (or vice versa) will be plotted, thus
providing free clipping.

4.9 MULTIPLE TUBES.

computet and cor have optional features which make it

possible to drive more than one 611 storage tube with only

8. CDI also makes ABDSs with eleven bit digital accumula-

tors. These provide about four inches of margin in the
direction of the long axis and six inches in the short axis
before wrapping occurs.

878
one terminal controller (that lS vecto~ and cha~acte~
generator, etc.). This is done with blanking logic which
allows only one storage tube (under compute~ control) to
write at one time. It is in this sort of usage where the
flicker-free nature of DVSTs really comes to the fore. To
the best of our knowledge, no one has ever used two
high-power refI~§h~Q displays together fo~ one operato~ to
increase the amount of information available to him. In
contrast, the Science Services Division of Texas Instru-
ments, for instance, has four storage tubes clustered around
one operator displaying maps and graphs of seismological
data.

Unfortunately, these options do not currently allow

concurrent input from separate keyboards and/or graphic
input devices. Thus only one user can actively interact
with the multi-storage tube configuration at once. The
Computek option does allow separate keyboards and graphic
input devices, but only one user can be enabled at any time.
(If a two tube configuration were attached to a small
computer with a teletype in addition, a second user could
input on the teletype and the computer could respond on the
second storage tube.)

5. __ SUMM~S OF TERMINALS.

5.1 TEKTRONIX INC.

The approach Tektronix has taken is to provide a single,

powerful display terminal, rather than a package of options.
They believe that their terminal will cost less as a result
of this approach, so that they can provide more than their
competitors tor a comparable price. The current price is
$8200 plus $550 for their high-speed PDP-8 interface. Also
available is a versatile communications interface; other
high speed computer interfaces are under consideration.

The Tektronix T4002 terminal seems to be best suited for

a text handling application. The scratch-pad memory input
feature, together with the high character plotting rate,
make it best suited of the three terminals for character
input and editing. At the same time, the slow vector mode

879
but fast incremental point mode (which is good for simulat-
ing mechanical plotters) indicate that this terminal would
be good for plotting graphs and preparing reports. Finally
the lack (at least at the present time) of a graphic input
device, considered with the above, implies it can not be
used for full interaction.

As this terminal follows the ASCII conventions, there is

no prejudice against using it as a terminal in a time-
sharing system, except that synchronous communications would
severely slow down the very high point and character rates.

5.2 COMPUTEK INC.

The Computek 400 series is highly modular. It is

possible to acquire only a character scope (the 400-12) or
only a vector scope (the 400-10). In the 400-15, which has
both the character and the vector generators, it is possible
to do limited graphics input with only the cursor control
keys, or to build up with a joystick or tablet to do full
graphics. The basic 400-15 costs $8400; a joystick costs
$1000 extra; so does the high speed computer interface.
(The 400-20 is the 400-15 with the curve generator added for
an extra $2200.) The Computek -15 and -20 have the most
powerful set of graphic data modes of the three terminals.
They have both absolute and incremental vector modes (and
curves in the -20), and the scalable two-character mode.

The low pover models will probably be. used mostly as

time-sharing terminals. Higher powered configurations with
graphic input devices will probably be used in full duplex
connections (or direct computer connections, because of the
line turnarounds necessitated by the graphic input devices
when in half duplex mode. Such terminals will be capable of
full graphics interaction.

Computek terminals are slightly harder to program than

CDI terminals because of the necessity of enabling-disabling
the joystick, and because an "escape" command must be sent
to exit from all graphics modes. Special considerations may
have to be made in connecting a Computek terminal to a
time-sharing system, because the ASCII conventions are not
followed. For situations where the communications connec-
tions may be noisy, parity may be obtained as an option.
This is done by switching from their normal 8 bit format to
a 6 bit format which, of course, is not desirable from the
point of view of transmission speed. Using the curve
generator with a small computer may not be reasonable in
view of the space and execution time for the curve fitting
program.

5.3 COMPUTER DISPLAYS INC.

The IRDS console~ like the Computek terminals~ is highly

modular (although the least powerful IRDS has both character
and vector generators). It has a powerful class of data
modes~ although not as powerful~ in general~ as the computek
400-15. It can, however, hold more characters in one
display than its competitors, address points more finely on
the screen, and plot dashed lines, as well. The variable
symbol size option is also much more flexible than others
available. Important points for complex graphics applica-
tions are the presence of the eight inch margin around the
screen and the clipping of vectors provided by the vector
generator ..

Since it obeys the ASCII conventions and has parity

checking, the ARDS may find wider use as a graphics
time-sharing terminal, especially considering that the way
graphic input is done is good for use with half duplex
lines.

As mentioned in the Introduction, we feel that there is a

lot to be gained by buffering DYST consoles from a large,
time sharing, main frame with small computers. 9 If one
ammortizes a typical $15~000 "shoe box" computer, with 12K
bytes of 1.5 (or less) microsecond memory over, say, three
DVST's, the percentage increase of a workstation is only 35

--------------------
9. If one has no large main frame, such a configuration
makes a cheap "stand-alone" graphics system which cOllpetes
favorably on a price-performance basis with the far more
expensive refreshed stand-alone systems, such as the IBM
1130/2250-4~ the DEC 338, the IDIIOM, etc.

881
to 50%. For this increased expenditure, however, it is
possible to get a high data rate between the buffer and the
terminal, allowing rewriting of the screen within an accept-
able time frame (1/2 second to erase, one to three seconds
to rewrite). This rewriting speed is naturally less than
that used to rewrite (portions of) a refreshed display, but
it is orders of magnitude better psychologically than the
speed obtained over a 1200 baud line from a computer which
is not dedicated to servicing just this console or group of
consoles.

While it is far from optimal, one £~.!! learn to live with

a 2 or 3 second delay, rewriting after every local change,
in order to get the advantage of an always up-to-date
picture. The mode normally used with DVST's, of course, is
to delete by crossing out, and to rewrite only when the
picture becomes too cluttered with obsolete information to
continue working. In the rewrite-after-every-change mode of
operation, the workstation acts like a slower, but flicker-
free, refreshed intelligent terminal, available at a consid-
erable price advantage - one could not begin to purchase an
all-purpose intelligent graphics terminal for less than
three times the cost of a DVST workstation.

As with standard refreshed intelligent terminals, the

kinds of tasks one executes locally depend critically on the
amount of core available. In text editing, for instance,
one would like to be able to do minor editing (e.g.,
correcting "typos") on the currently viewed screen. These
modifications could be done "in place" in the small comput-
er, i.e., without transferring information either to or from
the main computer (which holds the master file). When a
batch of local corrections has been made, the updated
segment of the master file data structure can replace the
old segment in the main computer, thereby updating the file.
Using this local editing technique, there must, naturally,
be enough room locally to store the data structure segment,
implying that one probably could not have enough data
structure to fill the entire screen with characters (4000
characters per full screen).

Other uses to which the computer could be put would allow

the user to adjust the position of components on the screen
until he is satisfied with the layout, transmitting only
this final layout (probably via a transformation matrix) to
the main computer. Naturally, the local computer would do
first level interrupt handling for any complex (data struc-
ture) manipulations to be performed as a result of the
userls actions, minimally displaying appropriate feedback
prompts, and additionally doing as much local manipulation

882
as possible in the amount of core available. The problems
of segmenting the data structure for remote operations, as
well as making them compatible across incompatible machines,
are challenging, to say the least. One step in this
direction is reported by cotton[l].

Naturally, one can extend the capabilities of the local

computer by giving it more and faster core, and particularly
by giving it a full complement of peripheral devices. In
effect, by doing this, one makes the local computer into the
main computer and one has followed a process described by
Myer and Sutherland as traveling along the wheel of reincar-
nation [8]. The PDP 15 system explained below falls into
this category, and must be viewed more as the main frame
supporting multiple terminals than as a local cluster
connected to a bigger computer.

6.1 DIGITAL EQUIPMENT CORPORATION.

The KV Graphic System offered by DEC for their PDP-8

computers uses a Tektronix 611 storage tube in a vertical
orientation. It has hardware vector and circle generators,
but uses software for the character generator. (64 ASCII
characters are provided, no lower case; more can be pro-
grammed.) Vectors are drawn at rates up to 1.8 inches per
millisecond (about twice as fast as COl and Computet) but
characters are plotted at only 350 characters per second.
Ten bits of X and I coordinates are used to address a
thirteen inch square page containing the 8-1/4 by 6-1/2 inch
screen. Note that this provides a 13 mill separation
between adjcent points, making pictures rather course com-
pared with the other terminals (which have 5-1/2 to 8 mill
separation). A joystick is provided which controls a
write-through cursor.

A considerable body of software is included with this

system. This software, EDGRIN, consists of two parts: a
general purpose text editor for character input and manipu-
lation, and a general purpose graphics input program which
accepts input from the keyboard and the graphic input device
and builds pictures whose description is stored in an
interpretive language. These pictures can also be manipu-
lated and displayed.

Another proposed DEC configuration is the VT-15, a

cluster consisting of a PDP-15 with (up to) four refreshed

883
displays, and (up to) four storage tube displays. The
PDP-15 has an internal cycle time of 600 nanoseconds, with
from 4K to 12BK of BOO nanosecond 18 bit core.

6.2 INSTALLATION AT BaOWN UNIVERSITY.

The Brown University installation consists of an 8K byte

Interdata Mod 3 with two thousand 16 bit words of Read Only
Memory, of which a standard 360 instruction subset occupies
750 words, leaving the other 1250 free for firmware of our
design. The Interdata Mod 3 is connected (high speed) to a
CDI ARDS terminal with a mouse, and is to be connected
shortly, also over a high speed interface, to an IBM 360 mod
67. We chose the Interdata over other hardwired small
machines available because we felt that for non-standard
instructions useful to graphics, we were better off in more
primitive but faster firmware instruction set {370 nanose-
conds per 16 bit instruction) than in the more powerful but
slower hardwired instruction set (4 to 7 microsecond per 16
bit instruction). Comparing just standard instruction sets,
conventional microprogramming machines cannot compete with
hardwired machines; but the additional flexibility of being
able to redesign or custom-build instructions was felt to
make up for loss in speed for standard instructions.
Thus we plan to incorporate a number of useful instruc-
tions such as a Move Characters instruction which will
translate a arbitrary length stream of bytes from one
arbitrary core location to another. We will also have a
Translate and Test instruction which viII search for anyone
of a set of specified characters in an arbitrary length
string of characters; a variation of this search will be not
to scan contiguous core locations but to follow consecutive
address pointers in a list structure, testing at a specified
offset for one of the specified key characters or 0 (end of
list symbol). Another use for microprogramming will be to
provide standard correlation map subroutines "in the hard-
ware". Finally, most of the communications protocol between
the Interdata and the 360 will be supported by firmware
rather then by software.
It is our plan to segment the available BK bytes into a
4K program section and a 4K data structure section. The 4K
program area, while not as useful as 4K of 360 bytes, will
nonetheless be far more useful than 4K core in the typical
small machine since it used v~th the enhanced and custom~zed
firmware instruction set. In particular, unlike, say the
IBM 1130, re-entrancy can be easily implemented, thereby

884
allowing cead-only shared access to the progcam acea. In
turn, this implies that each additional display terminal on
the system would requice only an additional 4K of core (if
local manipulations were to be done; no additional core
required if all work would be processed by the main frame).

1. Cotton, lca and F. S. Greatorex, "Data structures and

techniques for remote computer graphics", I£Qcee~­
iq9s_1969 Pall Joint Com..E..!!te~_-f.Q!!fe~~, APIPS,
Volume 35, November 1969, pp.533-544.

2. Dertouzos, Michael L., "Character generation from resis-

tive storage of time derivatives", l£Qce~dings
196.2_Pall Joil!i_fQ!puter- C.Q!!ig~.!l£~, AFIPS, Volume
35, November 1969, pp.561-568.

3. Information Display, "ID Readout", Information Display,

January/February 1969, Volume 6, Number 1, pg.60.

4. Macaulay, Malcolm, "A Low Cost Computer Graphic Termin-

al", 1.£Q.£g~dillils 1968 Fall Joint Co.!!!.puttl-_£2.!!=.
fe£~.!l£gL- Par1-~.!l~, AFIPS, Volume 33, Decembec
1968, pp.777-785.

5. Miller, James C. and Charles M. Wine, "A Simple

Display for Chacacters and Graphics", IEEE Tr-an-
sactions on Computers, May 1968, Volume C-17,
Number 5, pp.470-475.

6. Miller, James C. and Charles M. Wine, "A Light Pen for

Remote Time-Shared Graphic Consoles", IEEE Tran-
sactions on Computers, August 196B, Volume C-17,
Number 8, pp.799-B02.

7. Mumma, Fced W., HAuerbach on Computer Technology:

Progress with Displays", Data Processing Magazine,
october 1969, Volume 11, Number 10, pp.32-42,ff.

B. Myer, T. H., and I. E. Sutherland, "On the Design of

Display Processors", Communications of the ACM,
June 1968, Volume 11, No.6, pp.410-414.

9. Rose, G. A., H'lntergraphic,' a Microprogrammed,

Graphical-Interface Computer-H, IEEE Tr-ansactions
on Electronic Computers, December 1967, Volume
EC-16, Number 6, pp.773-784.

885
10. Bose, G. A., "Computer Graphics Communications Sys-
tems", IF!L~.Qllg~.2~L1968_IBvited P.a.E~~, August
1968, pp.211-220.

11. Ruben, Murray A., "Low Cost Graphics", £2.!!LEY te£~£~=

Ehics Technigues_and AE£!icatiQ~§, R. D. Pars-
low, R. W. Prowse, and R. E. Green eds.,
Plenum Publishing Company Ltd., London 1969,
pp.91-97.

886
 MICROCODED MULTIPROGRAMMING
DISPLAY CONTROL UNIT

B. J. Shepherd, A. S. McAllister, P. Falk

International Business Machines Corporation,
Advanced Systems Development Division,
Los Gatos, California 95030, U.S.A.

1. INTRODUCTION

1
Althou h microcoded control of computers was suggested as early as 1951 (by
Wilkes ), microprogramming is only now coming into fairly general use. The
growing interest is evidenced in the appearance of a number of review articles
(2,3,4,5), and in detailed descriptions of specific applications. In the work re-
ported here, a microcoded control unit was used to implement an experimental
display system in the Los Gatos Laboratory of IBM's Advanced Systems Develop-
ment Division. The system presents alphanumeric and graphic images on remote
television terminals under computer control. Keyboards associated with the ter-
minals provide for user-computer interaction, and a key-activated cursor on the
display screen allows the user to point to image locations where changes are to be
made. A microcoded multiprogramming monitor which resides in the control unit
handles the overall sequencing and control of events in the display system.
In essence, microcode resembles primitive machine language for a machine
whose internal registers are all available to the microprogrammer. In some
microprogrammed machines, the organization is more parallel than in conven-
tional computers, since several operations can be performed Simultaneously in a
single microinstruction cycle. This gives the microprogrammer additional power,
of course, and at the same time it places on him a greater demand for optimization.
Microcode can be very useful as a means of simulating the operation of one
machine on another set of hardware. In the experimental Los Gatos display system,
however, microcode is employed directly to implement an operating system for the
control unit without defining a higher level (machine) instruction set.
As Fig. 1 indicates, requests from the host computer are translated by the
control unit and sent on to the character generator or the vector generator, or to
the control circuits. The generators write--or "paint"--on a vidicon tube which
serves as a scan converter. The writing is performed in directed-beam mode.
When the host computer signals completion of an entire image, the scan converter

887
~

Television
Displays
r---
Scan
Converters

Host Micro-
Programmed Graphic Video
Computer Generator Buffer
Control Unit

Fig. 1. Display System Organization

is read out in raster fashion to a rotating-disk video buffer. This buffer has
continuously reading heads which feed and refresh standard tele~sion displays.
(Since the displays are refreshed from a magnetic disk, not continually replotted,
light pen tracking and inking are not possible.) The system reproduces three
intensity levels, and has image resolution of approximately 600 by 600 points.
Operation is at 875 lines, 30 frames per second, with 2-to-1 interlace. The
experimental system resembles to some degree that proposed by Rose, 6 but the
use of the vidicon tube as a scan converter sets it apart from most other raster
or video displays. 7,8,9,10

II. CONTROL UNIT

The control unit employed has the advantages of parallel organization, and has
powerful logical capabilities. The microinstructions are obtained from 4K-word
read-only storage whose cycle time is 500 nanoseconds. Access to the 30 registers
in the control unit is at the same rate (500 nanoseconds). Five of the registers are
write-only (output buffers), three are read-only (input buffers) and the others are
general-purpose, constituting fast storage for data and parameters. Another
important characteristic of the control unit is the availability of 16K bytes of
magnetic core storage. Adjacent byte pairs are accessed with a full cycle time of
two microseconds, and core accesses are fully overlapped with the execution of
microinstructions. (A similar display system delivered to the RAND Corporation
did not have core storage in the control unit, but used an IBM 1800 computer for
many of the functions performed here. See Ref. 11.)
Because multiple concurrent operations are possible during each micro-
instruction step, the instruction format is necessarily somewhat complex. Each
microinstruction can simultaneously perform an arithmetic operation, set a status
indicator, and conditionally branch to one of four possible next instruction locations.
A four-address instruction format is employed, with instruction addressing being
absolute within 512 instructions (two pages). The branching is controlled by two
sets of testable conditions (14 conditions per set), so the flow of control through
any section of microcode can be closely responsive to the system status.
The computer directs the control unit by means of these input/output commands:
Read Status, Read a Keyboard Buffer, Enable Keyboard Entry, and Write to the
Display Screen. The last of these is followed up by orders from the host computer
core; these orders control operation of the display system. The orders stored
there are of three kinds: those which produce alphanumeric characters or special
symbols (see Fig. 2), those related to image intensity, etc. (Fig. 3), and the
graphic or vector orders which produce lines (Fig. 4). It should be noted that the
display system does not in general employ "mode switching;" i. e., each order has
a fixed meaning which does not depend on the current state of the system.

889
 Vector Orders
(see Fig. 4)

0 1 2 3 4 5 6 7 8 9 A B C D E F
0 NULL space & - 0

1 ,-oJ \ I • j A J 1

2 $
b k s B K 5 2

3 .r l.: n .. c I t C L T 3

4 <r ~ -(>
b d m u 0 M U 4

5 <I D. I> 'V e n v E N V 5

6 L .J r -, f 0 w F 0 W 6

7 0 0 ~ 9 p x G P X 7

8 f l t:. h q Y H Q Y B

-< -> z I
[ R
9 J i r Z 9

A ¢ ! 1\ : Control Orders

.
(see Fig. 3)
B I $ , #

C! < • % @

0 I ( ) I

x
w
J: E + ; > =
I-
J:
I
-, ?
(!)
II:
F "
o 2 3 4 5 6 7 8 9 A B c D E F
LEFT HEX

Fig. 2. Order Code Table for Alphanumeric and Special Characters

Set Text
A Line
Int Set . Phony Plot
B Off
Dot DimM Match Si7.e 1
Load lnt Reset Load Plot
C S.R. Dim Dash DimM Tag Size 2

o Cond. lnt
Jump Norm
Loaed Type
Line Reset Camp Size 1
x
~
....
E End
S.R.
Exec lilt
S.R. Brite
Load
MBC EOT
Load Type
Apert Size 2
a
ir
F 9 A B c D E F
LEFT HEX

Fig. 3. Order Table for Control of Image Intensity, Plot Size, etc.

890
 0 NULL J X.... X+R, J X.... X+R2 J X.... R,

1 J X-I, J Y.... Y+R, J Y..-Y+R 2 J Y-R2

2 J Y-I, JX-X-R, J X-X -R2 J X.... R2

X-I, X-R,
3 J Y-12 J Y.... Y-R, J Y.... Y -R2
J Y.... R2

4 J X-X+I,

S
NL A R,-X
5 J Y-Y+I, LF V
E
X-X+I, S
A
6 J Y-Y+12 BS LR V R2 .... X
E
L S
0 R,-I, A R,-X
7 A
D
V
E
R2_Y
L
0 R2- 1, X-X+R2
L X.... X+R, L X-X+R2 L Y.... Y+R,
8 A
D
X-X+R, X.... X+R2 X-X+R,
9 LX-I, L Y-Y+R, L Y-Y+R 2 L Y.... Y+R2

L Y.... I, L Y-Y+R, L Y-Y+R2 X.... X -R,

A L y .... Y+R2

X-I, X-X-R, X-X -R2 X.... X- R2

B L Y.... 12 L Y... Y+R, L Y-Y+R2 L Y-Y+R,

L X-X -R, X.... X- R2

C L X-X+I, L X-X -R2 L y ... y -R,

X-X -R, L X-X-R2 X... X -R,

D L Y.... Y+I, L Y_Y -R, Y.... Y-R 2 L y_y -R2

X.... X+I, X-X+R,

x
Q)
E L Y-Y+12 L Y-Y -R, L Y-Y -R2 L Y_Y -R2
:J:
+-' L R, .... 1,
.r:::. 0 X-X+R, X-X+R2 X.. X+R 2
.E' F A R2- 12 L Y_Y -R, L Y_Y -R2 L Y.... Y -R,
a: D
o 1 2 3
Left Hex

NL - Carrier Return
LF .. Line Feed L prefix denotes Line
LR .. Line Return J prefix denotes Jump
BS .. Back Space

Fig. 4. Order Table for Lines (L) and Jumps (J) (See Section III)

891
III. GRAPHIC ORDERS
Specifying a line to be drawn as part of an image is obviously a more complex
problem than specifying which of a given set of characters is to be reproduced.
Each line segment ''painted'' on the display starts at the endpoint of the previous
operation. The line may be followed by a change in line direction, or by a I1jump"
to another point. Straight horizontal lines can be specified completely by successive
X values, and straight vertical lines by successive Y values. Curves (composed
of line segments) involve a series of changing X and Y values and are correspond-
ingly more complex. Graphic orders are supplied to cover all these possible needs,
and more.
Several of the orders provided include accompanying data (two or four bytes),
and produce either lines or jumps. The endpoint of the beam motion on the display
screen can be expressed either absolutely or incrementally by the data transmitted
with the order. Orders with two bytes of data move the beam in the X or Y
direction; those with four bytes move the beam diagonally. These orders are most
efficient for large motions of the beam, and for positioning the beam to some
initial location.
Certain graphic orders make use of two control unit registers which can be
accessed by the orders sent from the host computer. These registers, called RI
and R2, can be loaded with two-byte values from the host computer (orders 07,
08 and OF). Lines can then be produced by consecutive application of 24 single-
byte incremental orders which specify operations of this form:
X = X + (RI or R2 or NULL)
Y = Y + (RI or R2 or NULL)
These orders allow complex connected curves to be specified very compactly. A
small number of jump orders also use RI and R2. There is also a one-byte order
(3 F) which will cause RI and R2 to be loaded with the current value of X and Y,
the beam position registers; another (33) will jump the beam to the position given
in RI and R2.
A description of the way a graphic order is decoded by the control unit will
suggest how microcode is employed. For any graphic order, two controlling
parameters are set up by a unique sequence of two microinstructions. The setup
sequence branches to a single entry point of a routine which calculates the infor-
mation needed to move the beam in the necessary manner. If there is data
associated with the order itself, a lower-level subroutine is called to obtain the
required two bytes of data. The "get data" subroutine then returns to the calculation
routine, which figures out the X positioning information on the first pass and the Y
information on a second pass. There are many new types of vector orders which
could be added by simply adding a new setup sequence.

892
IV. GRAPHIC SUBROUTINES
In applications where special characters are needed frequently, they can in effect
be added to the vocabulary of the display system by means of graphic subroutines.
In an electronic circuit analysis program, for example, the symbols needed often
would be resistors, capacitors, transistors, and so on; in a continuous systems
modeling program, they would be integrators, summers, coefficient multipliers,
etc. The graphic subroutines specify special "characters" in such a way that they
can be invoked by single orders. This obviously reduces the size of the order table
which must be generated in the host computer and transmitted from it.
The host computer can load a series of orders, or a subroutine, into the area
of the control unit's core buffer which is reserved for each video buffer channel,
specifying the relative starting address of the subroutine within that particular
core area. The control unit then obtains orders and data from the host computer
and puts them in consecutive core locations until an "End Subroutine" order is
encountered. Orders are not executed as they are being placed into the subroutine
buffer. After a subroutine has been loaded, it can be invoked by a single order
which identifies its relative starting address. The control unit then operates in an
essentially normal manner, except that orders are obtained from its own core
storage rather than from the host computer. When an "End Subroutine" order is
encountered, the subroutine mode of the control unit is reset and subsequent
orders are obtained from the host computer.
While the control unit is in the subroutine mode, a conditional branch order
may be executed to any location within the core storage area associated with that
particular video buffer channel. The branching condition can be a loop counter
going to zero, a vector being drawn off the screen, or the image falling (partially)
within some user-specified rectangular region. The conditional branch order can
also alter the value of the loop counter or the value in register Rl or R2. This
latter ability allows for the introduction of variations in the scale of an object
drawn by a subroutine, with the scale varying as a function of the number of times
the subroutine is invoked.
The graphic subroutine capability can of course be utilized in a great many
ways, but it is particularly useful in producing repetitive image content. One can
position the beam to some absolute location with a jump order, and then request
a given subroutine to be executed at the "current" beam location. The beam can
then be repositioned and the same subroutine invoked again, repeatedly. The image
shown in Fig. 5 required that kind of procedure. One way in which it could be
generated by invoking interconnected subroutines is shown in Fig. 6.
The basic image component in Fig. 5 is a square which is generated by four
one-byte orders. The square is called by another subroutine which reduces its
size and decrements a loop counter each time the "square" subroutine is invoked.
In our application, it was decided to put the loop-counting logic in the control unit
program, but that logic could just as well have been placed in the host computer's
order table. Such flexibility is a real advantage, since functions can be divided
between the control unit and the host computer as desired to achieve optimum

893
 Fig. 5. Image Produced by
75 Bytes of Data
(See Section N)

AE ACOD Done? No, go to *

AD 0001 Load $Ubroutine
9F Yes, exit and end
AE 900F subroutine
} Initialize
OF OCOO 0000
AF 0001 Plot (call subroutine)
* 3E 0604001200 Move right
3C
3A
39
}BO' AF 0001
060400 1200
AF 0001
Plot (call $Ubroutine)
Move right
Plot
06 C1FF F8EO Move to next row
06 0120 FEDF Move corner
Repeat last group for
AE.E4CO Decrease size next two rows

AE FOOO Increase ti It

AE 8000 Decrement index

Fig. 6. Sequence of Orders Used to Produce Image Shown in Fig. 5 (To

produce Fig. 7, order AE FOOO was changed to read AE F040.)

894
efficiency in any particular application.
Since image generation time is limited by the vector generator, our choice in
this case results in a considerably lower average bandwidth requirement oor the
host-display connection. That is, the average bandwidth would need to be higher
if the entire order table had been placed in the host computer core. To be explicit,
the image shown in Fig. 5 contains 576 visible lines. To load the subroutine
required the transmission of 33 bytes of data, with no speed requirement. Once
the subroutine was loaded, only 75 bytes of data had to be transmitted to produce
the image. Thus, on the average, more than seven lines are produced for each
byte (data or order) sent from the host computer,. If the entire image were sent
from the computer, at least 2050 bytes of data would have to be transmitted. In
this example, then, the fact that the control unit can execute subroutines and
perform conditional branches results in reduction of bandwidth requirements by a
factor of 27. The saving in total core employed (host computer plus control unit)
is also considerable, representing a factor of 20.
The savings in other situations will depend on the degree of repetition in the
image which is generated. The number of distinct images and image generation
routines which can be stored in the control unit is limited by the available core.
If a sub-image can be drawn by 20 incremental lines or jumps, then approximately
25 sub-images can be stored for each video buffer channel in the experimental
system described here. The image in Fig. 7 was invoked by the same order table
required for Fig. 5. The difference in the images was brought about by making
the ''tilt'' data nonzero; that is, by changing the orders given in Fig. 6 so that
order code AE FOOO reads AE F040 instead.

V. MICROPROGRAMMED MONITOR
The monitor residing in the control unit functions as indicated in Fig. 8, checking
requests for service and responding to them as soon as possible. The existence
of a priority structure is indicated in the fixed order for checking requests. When
requests must be placed in a service queue, entries at a given priority level are
held in a first-in, first-out queue using the core of the control unit as buffer
storage.
The operation of the scheduler is determined by the occurrence of key-strokes
at a terminal, by the re-availability of the character or vector generator (after
completion of its last task), and by other asynchronous external events. Some
operations have unpredictable durations (painting an order table, for example),
but many others have a known maximum length--accepting and processing a
character from a keyboard, for instance. Since such "transactions" are always
executed to completion once service has begun, the scheduler is transaction-based.
When any service is completed, control is passed to the top of the scheduler,
i. e., to the waiting request which has the highest priority. This means that a
low-priority request could in theory wait a considerable time for service.

895
 Fig. 7. Variation of hnage
Shown in Fig. 5.

896
 In general, activities governed by the control unit are not subject to "rate
overrun"; that is, errors will not occur if requests are not serviced within a
fixed time. When the host computer initiates contact with the display system,
however, quick response by the control unit is necessary to avoid an error indi-
cation. To assure prompt response, a priority interrupt is provided which can
be enabled and disabled by the microprogram. When the interrupt is enabled and
the host computer attempts "initial selection" of the display system channel,
control is passed to a microcoded routine. The microroutine saves registers for
working space, completes the initial selection dialog, sets a flag to indicate that
a channel command has been received, and finally restores the saved registers
and returns to the interrupted microprogram. The command from the host
computer is later decoded and carried out, as indicated in Fig. 8.
To understand the way the scheduler microprograms, and the way the system
interacts with the user, we might look at some specific timing information.
Consider a line-producing order code which references registers R1 and R2. Such
an order is interpreted by the control unit microcode in about 16 microseconds,
and a request sent to the vector generator. The vector generator accepts the
request immediately, but will be busy drawing the line for 8 to 125 microseconds
(depending on the length of the line). For a series of lines which are one-fourth
the width of the full screen, the control unit is thus occupied only 40 percent of the
time, leaving the rest of its time available for other activities. While the character
or vector generators are busy, the control unit will service attention requests
from the keyboards and/or cursors. If a keyboard-entered text line is being painted,
the scheduler can transmit status information or accept a line of text to be edited
from the host computer.
If characters are being painted (rather than lines being drawn), the microcode
requires 11 microseconds to present the transformed request to the character
generator. The time to generate a large character averages about 20 microseconds.
If automatic spacing between characters is desired, an additional two microseconds
of microprogram time is required. The vector generator is used to position the
beam to the "next" character location after the current character has been painted.
For a large character, this move requires 3 microseconds. We can see that when
large characters are painted, the control unit is occupied 30 percent of the time.
When small characters are involved, the times are only about half as long, so the
control unit usage becomes 50 percent.

VI. USER-SYSTEM INTERACTION

The user works at the display-keyboard terminal, and has available the usual
alphanumeric characters and special characters. To implement his "conversation"
with the computer about the images displayed, he has available a nondestructive
cursor which he controls from the keyboard. The cursor used in this system is
not painted on the scan converter, but is produced directly by hardware. This is

897
 Edit and Store
. . . - - - - - - - - - - - -..... Character.
Set Paint
Request
Read Process
Character Fully

Obtain and
Process One
Graphic Order

Yes

Process
Fully

Start
Scan Out

Initialize
Video
Channel
Paint

Initialize
Video
Channel
Paint

Fig. B. General Flow of Microprogrammed Monitor

898
accomplished by means of coincidence circuits and cursor position registers which
can be set by the control unit. This means that keyboard operations which only
move the cursor can be serviced immediately and never have to wait for the
character/vector generator to become available. Thus keyboard throughput rates
can be quite rapid in situations which involve considerable editing.
The "Enable Keyboard Entry" command from the computer can be accompanied
by control information specifying the size, brightness and vertical location of the
lines to be used for input. Appropriate "default" values are provided by the control
unit to supply any needed information not specified. When a message of any kind
from the keyboard is ready for transmission, the user keys "End of Message, "
and this causes the control unit to alert the host processor.
The keyboard includes keys to advance or backspace the cursor, tab the
cursor, ''backspace'' vertically, erase the line, go to the end of the current line,
and signal "End of Message" (as mentioned). With these tools available, the user
can manipulate the image far more easily than a typist can rearrange the material
on a page of hard copy. Up to three lines of text sent from the host processor, or
the same amount of text entered from the keyboard, can be edited at one time.
Using the cursor as a pointer, the user can insert or delete characters at will,
the system making the requested changes automatically. If characters are inserted
in a line, the rest of the line is moved to the right; if characters are deleted, the
rest of the line is moved to the left to close up the space created. These editing
functions are implemented in the microcode of the control unit, and place no load
on the host computer.
When a character has been inserted or deleted by the user, the text string
must be repainted and scanned out to the refresh buffer. This is accomplished by
a request to paint the altered keyboard text buffer. If the character/vector gener-
ator is busy at the moment with some other video buffer channel, the request is
placed in a queue.
Since the character/vector generator can be allocated for as much as two
seconds for a paint, there may already be a request in the queue to repaint the
current video buffer's text. (The user may have already indicated the need for a
change earlier in the same line, for example.) To keep the queue size manageable
and speed up the procedure, a double-list queue is used: a linear list ordered by
buffer number, and a ring list based on time of arrival of the requests. The linear
list is checked first, when a request is received, to see if a request i", already
in line for the current video buffer. If not, the ''new'' request is entered there, and
the head of the ring list is incremented and replaced. The next location on the ring
list is loaded with the buffer number (offset into the linear list), and the request
is enqueued. This double-list scheme takes additional core, but prevents duplicate
entries and yet avoids the need for searching the whole ring list each time.
It was implied earlier that once the host computer has loaded subroutines
for a given video buffer channel, those subroutines can be used for any subsequent
paints for that channel. An exception occurs when the video buffer channel has
been used to display characters entered from a keyboard. In such a case, the
subroutines must be reloaded by the host computer before they will be available

899
as before. This situation is due to the fact that the control unit core is allocated
in fixed blocks to the separate video buffer channels, with one block for common
control information and waiting queues. Each video buffer's core area can be used
to hold either graphic subroutines or keyboard-entered text, but not both at the
same time. Where the output from several video buffers is mixed to produce a
single display, as is generally the case, one buffer can be dedicated to holding
keyboard-entered messages. With that precaution, the subroutines associated
with the other channels can be kept in operation and will not be overwritten by
keyed entries.

VII. A SUBJECTNE EVALUATION OF MICROCODE

It may be instructive to compare microcode with machine language (or ordinary
code) in regard to ease of writing and debugging. Let us assume that the micropro-
grammed machine is one which has considerable p'arallelism, like the one used in
the system described. Perhaps the first point to be made is that there is no higher-
level microprogram language. This is probably due to two reasons: it is difficult
to specify parallel operations easily, and the instruction format would have to be
very long. An additional reason is that it is much more difficult to apply topological
operations to optimize parallel computations than to optimize serial computations.
Therefore, one of the greatest appeals of a higher-level language has been removed.
The main difference in techniques for ordinary coding and microcoding is due
to the four-address instruction format. Since every instruction contains the address
of the next instruction to be executed, the code can be quite convoluted. The poten-
tial for using the same blocks in many different logical paths is increased since
every microinstruction can be a four-way branch. Because a branch can be per-
formed in the same microinstruction as an arithmetic statement, most microcode
includes many forks. Good programming practice dictates that inner loops be
highly optimized for timing purposes, even if this results in complex code wherein
many blocks are entered (branched to) from many different locations. However,
good programming practice also requires that microcode should be simple in its
structure if it is to be extended functionally, or if it is to be maintained by someone
other than the original author. Unfortunately, it is often impossible to know in ad-
vance which sections of the microcode will be altered.
Because of the complex nature of the parallel operations and branching, good
documentation is even more necessary with microcode than with ordinary code. One
factor which eases the documentation problem is the fact that microcode is written
on a two-dimensional form. By that, I mean that microinstructions do not appear in
a list, but rather are positioned on a large sheet, with successive microinstructions
being joined by lines. Thus the code reflects the way in which microinstructions are
linked together to form loops. This means that every branch is indicated, and every
entry to a block can be determined. If instructions are incorrectly punched, of
course, there can be an unexpected entry to any microinstruction from any other.

900
 The microcode debugging process is no harder than that of debugging ordinary
code. The only real difficulty is correcting the errors once they have been dis-
covered. If the microcode is executed from a writeable control store, it is a fairly
simple matter to alter the erroneous microinstruction. However, our microcode
was contained in a read-only storage device, and it was not possible to correct more
than two microinstructions in an hour. If the error did not require the addition of a
microinstruction, the correction rate was two errors per hour. However, if an
additional microinstruction had to be inserted, two had to be punched--the new one
and the one immediately preceding it (altered to make the new one the next one to be
executed). The impossibility of entering instruction corrections directly through
console switches was the biggest drawback to the control unit we have described.
This limitation is due to the hardware employed, not the nature of microcode.
In some situations it is necessary to decide whether to use microcode or hard-
wired logic to implement a subsystem. If a microprogrammable unit can be obtained
(purchased, rather than being constructed), it will normally provide a quicker im-
plementation of the subsystem. The design problems are comparable for hardwired
logic and microcode, but the production time is much less for microcode. Even if a
microprogrammed unit cannot be obtained without constructing it, a microcode im-
plementation is still desirable for an experimental or developmental vehicle. This
is because even a read-only store can generally be altered more easily, quickly,
and cheaply than can hardwired logic. Of course, read-only storage cannot be easily
altered if it is based on optical or integrated-circuit techniques, but normally these
techniques are employed only after the system design has been thoroughly checked
out.
Occasionally it is possible to choose between implementing some function in
microcode and in ordinary code. Microcode becomes an attractive choice in two
situations: If system performance would be enhanced by the addition of a few
special instructions (to implement list-processing operations, for example), then
microcoding those instructions would be very desirable. The other situation which
favors the use of microcode is one in which a single (micro)program will fully
occupy the system. Then the entire application could be written directly in micro-
code. The penalty one pays for doing this is that any operating system supplied by
the manufacturer (as well as any assemblers, loaders, etc.) will probably not
operate. But in certain cases the increased performance due to direct use of
microcode is worth this price.

VIII. CONCLUSIONS
In the experimental display system described, microcode is employed in an unusual
way to implement a multiprogramming monitor directly. A hardware approach
might not have used multiprogramming or queues; a pure programming approach
might have implemented macro-instructions in the microcode and linked the

901
 macro-instructions together via some higher level language. The compromise
approach taken has produced an expandable control unit which can readily accept
additional devices.
The microprogrammed control system was designed, coded, debugged, and
documented with sixteen man-months of effort. An additional investment of nine
man-months was required to produce the micro-assembler, simulator and
interface program in the host computer. We feel these times show that microcode
is a quick way to implement control unit logiG.
The debugging of the microcode was greatly aided by a simulator which
allowed representation of the control unit on a convention3.J. computer even before
the control unit hardware was fully constructed and checked out. The simulator was
written in a higher level language to facilitate the inclusion of hardware changes
which occurred during the construction of the control program. The experience
of building the simulator forced us to understand the operation of the control unit
hardware thoroughly before we had written much of the control unit microcode.
The simulator enabled us to check out nearly all the control unit microcode before
the microprogram was loaded in read-only storage. This was a considerable help,
since it was much easier to rerun the simulator than it would have been to alter
the read-only storage. The simulator also provided diagnostic aids in the form of
traces and dumps which do not exist in the hardware.
The monitor which was microcoded into the control unit resembles a computer
operating system in many ways: It multiprograms; it services requests according
to fixed relative priorities; it services the requests at anyone priority level on a
first-in, first-out basis using queues maintained in the control unit core. By
editing text according to data entered by the user at the terminal keyboard, the
control unit reduces the load on the host computer-display unit connection and on
the computer itself •.
We have also demonstrated that placing more control capability in the control
unit leads to a reduction in the average bandwidth required for the computer-
display connection. In the example given, the use of graphic subroutines executed
from the control unit core reduced the total core required by a factor of 20, and
the average bandwidth more than 25 times. The relative costs of transmission
bandwidth versus logic in the control unit will ultimately determine--for a given
application--how function is distributed between the host computer and the display
system.

ACKNOWLEDGMENTS
We wish to thank Mr. Tony Rall for microcoding the host computer interface
control. Also, Mr. Dale Fisk and Mr. Don Chesarek made valuable comments
on the initial design of the microcoded monitor.

902
REFERENCES
1. Wilkes, M. V., "The best way to design an automatic calculating machine, "
Manchester University Computer Inaugural Conference, 1951, pp. 16-21.
2. Wilkes, M. V., "The growth of interest in microprogramming: A literature
survey, " Computing Surveys, Vol. 1, No.3, September 1969, pp. 139-145.
3. Douglas, J. R., ''References in microprogramming, " ACM Sic Micro Newsletter,
Vol. 1, No.2, August 1969, pp. 7-73.
4. "Project summaries, "Second Annual ACM/IEEE Workshop on Microprogramming,
Phoenix, Arizona, October 13-14, 1969.
5. Tucker, S. G., ''Microprogram control for System/360, " IBM Systems Journal,
Vol. 6, No.4, 1967, pp. 222-241.
6. Rose, G. H., "Intergraphic: A microprogrammed graphical-interface computer, "
IEEE Transactions on Electronic Computers, Vol. 16, No.6, 1967, pp. 773-784.
7. Ophir, D., et al., "BRAD: The Brookhaven raster display," Communications
of the ACM, Vol. 11, No.6, June 1968, pp. 415,-416.
8. Terlet, R. H., "The CRT display subsystem of the IDM 1500 Instructional
System, " Proceedings of the 1967 Fall Joint Computer Conference, AFIPS Vol. 31,
pp. 169-176.
9. Hendrickson, H. C., "A high-precision display system for command and
control, " Information Display, July/August 1967, pp. 32-36.
10. Unimari, D. C., "Standard glass memory modules for low-cost computer-
driven displays, " Computer Design, Vol. 8, No.4, April 1969, pp. 118-122.
11. Ma, J. T., "TV consoles as computer terminals, "Telecommunications, Vol. 3,
No.9, September 1969, pp. 25-26.
12. "Theory of operation of IBM 2314 File Control Unit, " IBM Field Engineering
Form Y26-3671.

903
AN INTERACTIVE GRAPH THEORY SYSTEM*

M. S. Wolfberg

Massachusetts Computer Associates Inc., LakesideOffice

Park, Wakefield, Massachusetts 01880, U.S.A.

INTRODUCTION

The medium of computer graphics provides a capability for dealing

with pictures in man-machine communication. Graph theory is used to
model relationships which are represented by pictures and is therefore an
appropriate discipline for the application of an interactive computer
graphics system. Previous efforts to solve graph theoretic problems by
computer have usually involved specialized programs written in a symbolic
assembly language or algebraic compiler language.

In recent years graphics equipment with proces sing power has been
I

commercially available for use as a remote terminal to a large central com-

puter. Although these terminals typically include a small general purpose
computer the potential of using one as a programmable subsystem has re-
I

ceived little attention.

These motivations have led to the design and implementation of an

interactive graphics system for solving graph theoretic problems. The
system operates on an IBM 7040 with a DEC-338 graphics terminal connected
by vOice-grade telephone line. To provide effective response times com-
I

puting power is appropriately divided between the two machines.

The remote computer graphics terminal is controlled by a special-

purpose executive program. This executive includes an interpreter of a
command language oriented towards controlling the existence and display of

*This .
paper written for the Advanced Research Projects
I Agency under ARPA
Order Number 1228 I describes work done at the Moore School of Electrical
Engineering I University of Pennsylvania I Philadelphia I Pennsylvania for
Rome Air Development Center and the Information Systems Branch of the
Office of Naval Research under Contract NOnr 551 (40) •

905
graphs. Several interactive functions such as graph drawing and editing,
I

are available to a user through light button and pushbutton selection. These
functions, which are local to the terminal, are programmed in a mixture of
the terminal computer's machine language and the interpreter command
language.

For more significant computations the central computer is used, but

response time for interactive operation is then diminished. In order to over-
come the low bandwidth of the telephone link, the central computer may
call upon a program at the terminal as a subroutine.

Based on the mathematical terminology used to define graphs, a high

level language was developed for the specification of interactive algorithms.
A growing library of these algorithms includes routines to aid in the con-
struction and recognition of various types of graphs. Other routines in the
library are used for computing certain properties of graphs. Graphs may be
transformed by some routines with respect to both connectivity and layout.
Any number of graphs may be saved and later restored.

A programmer using the terminal as an alphanumeric console may call

upon the programming features of the system to develop new interactive
algorithms and add them to the library. Programs may also be created for
the graphics terminal, using -the central computer for assembly.

ENVIRONMENT

The Interactive Graph Theory System is an experimental computer

software system which operates as a user program in the environment of the
Moore School Problem Solving Facility (or MSPSF) at the Moore School of
Electrical Engineering of the University of Pennsylvania. The MULTILIST
Project at the Moore School designed and developed the MSPSF as an
attempt to combine storage and retrieval capabilities of a computer with its
computational power to solve problems [3,7,8,9,10]. * The hardware used
for this work consists of a multi-console system attached to an IBM 7040
central processor. Since the 7040 does not directly support a variety
of terminals, a small DEC PDP-8 computer is interfaced to the 7040 and is
used to service Teletypes over 110-baud dial-up telephone lines and an
elaborate graphics terminal via a 2400-baud private line. The graphics
terminal is a DEC-338 Programmed Buffered Display, which includes a
PDP-8 computer as one of two processors; the other is a more specialized
processor oriented towards the control of an attached digital CRT display.
Both processors share a common 8I92-word I2-bit core memory with 1.5J.ls
cycle time. Although the DEC-338 can be used as a stand-alone system it
is configured as a remote computer graphics terminal, with a fixed-head
minidisk of 32K I2-bit words and one DECtape for more permanent storage.
The terminal includes an ASR-33 Teletype for keyboard and paper tape input

* Numbers within brackets indicate references.

906
and' printed (and punched tape) output a box of pushbuttons
I I and a light
pen for graphical input.

A user of the Interactive Graph Theory System sits in front of the ten-
inch-square display screen of the graphics terminal with the light pen in
one hand and the pushbutton box conveniently placed for accessibility by
his other hand. The system at the user's fingertips provides a simulated
piece of II paper II on which he may draw an abstract graph. The user directs
the system by using the light pen to point at light buttons and by depressing
appropriate pushbuttons. Indicative messages displayed by the system
instruct the user of what he may cause to happen. The novice user slowly
reads these messages and carefully points at his choice of light buttons I
giving the appearance that the system is controlling him. The experienced
user I however, so quickly points at light buttons and depresses push-
buttons that he appears to control the system.

The user is given the tools to construct a graph of arbitrary connec-

tivity consisting of any number of vertices and directed or undirected arcs.
Any vertex or arc may be labelled, and the relative position of each label
may be individually controlled. Six distinguishable shapes are available
for vertices, while arcs are generally straight lines directly connecting a
pair of vertices. An elliptically-shaped arc is employed when it is a loop
connecting a vertex to itself. The user may view the graph on the "full"
paper or he may select anyone of three smaller window sizes (half- fourth-,
or eighth-paper) and "move" the window to a chosen section of the paper
for more detailed work. The user is given the facilities for altering or
deleting any part of a graph on the paper.

Once a user has drawn a graph he may save it for future use along
with any number of associated key words in the large file or data base which
is available for all users of the MSPSF. Later restoration of any number of
graphs may be specified by a retrieval description as a logical combination
of key words.

The Interactive Graph Theory System includes a growing library of

interactive graph theoretic algorithms which the user may call upon. He
may for example, choose to apply a particular algorithm to a graph which
I

he has drawn. Figure 1 is a picture of the display screen resulting from a

shortest path algorithm applied to a graph which the user drew. The integers
along the directed arcs are labels the user included to indicate the cost of
traversing each arc. The path computed by the system, indicated by darker
arcs, is a minimum cost path from the upper vertex as the given starting
point to the lower one as the given ending vertex. With this interactive al-
gorithm, the user may request the shortest path between any pair of vertices;
he may also alter any aspect of the graph and again seek a shortest path.

Figure 2 shows another example of the application of an interactive

907
algorithm to a user-drawn graph. In this case the user has drawn a non-
cyc1ic graph and then applied a layout algorithm to move the vertices so the
graph appears in the form of a tree. Next, the user caused the algorithm to
further refine the layout of the tree by permuting the order of the five arcs
emanating from the root. In particular, the leftmost arc moved to the fourth
position and the tree then appeared as in Figure 3.

Another algorithm which has been included in the system determines

all maximally complete subgraphs of a given non-directed graph. * This al-
gorithm alters the shapes of vertices to display to the user one such sub-
graph at a time. Figure 4 shows one maximally complete subgraph which
has been computed.

These three algorithms demonstrate the types of graph theoretic prob-

lems which can be solved. The novice user can take advantage of the
Interactive Graph Theory System to the extent of applying existing interactive
algorithms, but the primary significance of the system is the way in which
users can compose interactive graph theoretic algorithms as programs in a
compiler-level language. To enable the user to develop programs, the
graphics terminal can be made to operate as °a text console. In this mode
the DEC-338 mimics the characteristics of a Bunker-Ramo Teleregister al-
phanumeric console, which used to be a terminal of the Moore School Pro-
blem Solving Facility. The display screen is arranged as twelve lines of 64
characters each, and the Teletype keyboard is used to control the contents
of the screen, with some of the special characters reserved for local
character editing functions. One of the keyboard characters has the meaning
of the TRANSMIT key of the alphanumeric console, which is to cause trans-
mission of the contents of the display screen from the terminal to the com-
puter. The DEC-338 is used as a text console in this system for preparing
and editing programs ,file manipulation, and data retrieval.

THE ALLA DATA STRUCTURE AND LANGUAGE

The approach taken to represent graphs in this system was dictated by

the classic definition: a graph is an ordered pair of sets (X, 1'), where X is
a set of elements (vertices) and r is a set of ordered pairs of elements of
X (arcs) [1]. The FORTRAN IV language was chosen as a base, and a new
data type was introduced which would allow for the representation of ordered
pairs, sets, and other appropriate constructs not representable in FORTRAN
IV. Also incorporated is the facility to associate an arbitrary amount of
data with any element of the data structure. The approach used was based
on that used by George Dodd in the design of the Associative Programming
Language as an extension of PL/I [2]. This extension of FORTRAN is called

*A complete subgraph of a given undirected graph G is a subgraph of G such

that each pair of vertices of the subgraph is connected by an arc. A
maximally complete subgraph of a given undirected graph G is a complete
subgraph of G which is not a subgraph of any other complete subgraph of G.

908
ALLA. One deficiency of Dodd's APL which has been eliminated in ALLA is
the necessity for specifying in advance the allowable associations an entity
may have.

The additional data type which has been introduced is named entity.
There is no literal naming of entities in ALLA except for the undefined entity
UNDEF. Instead, entities are referenced through entity variables or by a
relation or association with an entity. There are three types of entities:
atom, pair, and set. Each declared entity variable may, at anyone time,
name a particular atom, pair, or set r or it may have a value of UNDEF.

19

,,
'.
ll,3
"\
.,
\

"

ft IMGmm PAftI Ie SHOUll

SIB II' Fait aMImIER WlIR
P9 •• to ILftR 'MPH

Figure 1. A Shortest Path Computed

Each atom, pair, or set may have any amount of associated data. An
associated datum is called a property and is referenced by a property name.
The value of the property of an entity may be an integer, real, or logical
constant, or it may be an entity.

909
 · An entity of the type atom is one which has no structure other than its
associated properties. A pair is a type of entity which, in addition to any
properties, has a left-element and a right-element, each of which may be
an entity or may be undefined.

P8 9 TO PlRMUTl ARCS
PI 18 rOR AHOTHlR ROOT
P8 11 TO ALTER 6RAPH

Figure 2. A Tree After Layout

A set, besides having associated properties, 1S a structure with any

number of elements e·ach of which must be an entity. A set may have no
I

elements, in which case it is called empty. Although the word "set" is used,
the implementation imposes an ordering to the elements and so one may make
I

use of the "list" nature of this structure. Also, membership in a set is not
limited to a particular element appearing once. There are no restrictions on
the structuring of data in this system. For example I a particular set may
even be a member of itself three times. More important, however, 1s the
unlimited hierarchy of the relationships which can be modelled in this
structure.

910
 With this data structure a graph will be defined as an ordered pair,
where the left-element of the pair is the set of vertices, and the right-
element is the set of arcs. Each arc is an ordered pair I where the left ele-
ment is the "from-vertex" of the arc and the right element is the "to-ver-
I

tex". Each vertex will ordinarily be an atom, but the ALLA data structure
permits any type of entity as ;an element of a pair or set. Thus one could
even represent a graph of graphs or other interesting structures. More
I

commonly ,one finds the following structures appearing in graph theory

manipulations:

PI 9 TO P£R"UTl ARCS
PI I. rOR ~OTHlR ROOT
PI II TO ALTlR .RAPH

Figure 3. The Same Tree with Arcs Permuted

1. A set of arcs (where order is important) for a path.

2. A set of arcs as an entity property of a vertex for its outgoing arcs.
3. A set of vertices as an entity property of a vertex for its neighbors.
4. An integer property of a vertex for its depth in a tree.

911
EXAMPLE OF A GRAPH THEORETIC ALGORITHM

Instead of pre"senting a full description of ALLA, a practical example

will be explained in detail. The SHPTHW function chosen for this illustra-
tion is the algorithm for finding a shortest .2.ath in a ~eighted directed graph.
It was this function, used along with an interactive ALLA routine to interface

of
~-----,#

•
AH "CS IS SHOll"
~. .. TO 5[[ H[XT ON[

Figure 4. A Maximally Complete Subgraph Computed

with the user, which was responsible for producing Figure 1. The reader
should refer to the source listing of SHPTHW in Figure 5 in the following dis-
cussion. The lines of the function have been numbered for reference.

Figure 5 constitutes the definition of the function SHPTHW whose value

or res.ult is a shortest path given a graph G and the starting vertex A and
ending vertex B. The result of the function is a set of arcs of the given
graph; if no path is possible, the set is empty. Line 1 is the function dec-
laration. It is an entity function since its result is an entity, i.e. a set of
arcs. Lines 2 through 4 declare the data types of the three arguments of

912
the function and all of the variables used within the function body I both
locals and externals. Line 5 declares DIST as a property name.

LINE

1 ENTITY FUNCTION SHPTHW(A~B~G)

2 ENTITY A~BIG~DSET~TDSET~V~OAV~RVOAV~AA
3 ENTITY INARC~OUTARC
4 INTEGER WEIGHT~DIST
5 PROPERTY DIST
6 THROUGH 10 FORALL V IN LELM(G)
7 10 DIST(V) = 1000GOOO
8 DISTCA) = 0
9 INSERT A INTO CRSET(DSET)
IG 20 TDSET = DSET
11 CREATE SET DSET
12 THROUGH 4G FORALL V IN TDSET
13 THROUGH 30 FORALL OAV IN OUTA'RC (V)
14 RVOAV • RELMCOAV)
15 IF (DISTCRVOAV) .LE. (DISTCV) + WEIGHTCOAV») GOTO 30
16 DISTCRVOAV) = DIST(V) + WEIGHTCOAV)
17 INSERT RVOAV INTO DSET
18 3G CONTINUE
19 40 CONTINUE
2G DELETE TDSET
21 IF C.NOT.EMPTYCDSET» GOTO 20
22 DELETE DSET
23 CREATE SET SHPTHW
24 IF CDISTCB) .EQ. 10000000) GOTO 300
25 V• B
26 110 IF CV .EQ. A) GOTO 300
27 THROUGH 120 FORALL AA IN INARCCV)
28 120 IF CCDISTCLELM(AA»+WEIGHTCAA».EQ.DISTCV» GOTO 130
29 CALL ERRORC6HSHPTHW)
30 130 INSERT AA INTO SHPTHW
31 V = LELMCAA)
32 GOTO 110
33 300 RETURN
34 END

Figure 5. Shortest Path Function

The SHPTHW function assumes that the given graph is of the form
described in the previous section, and associated with each vertex is its set
of incoming arcs (INARC) and its set of outgoing arcs (OUTARC). Also
associated with each arc of the given graph is its integer weight (WEIGHT).
Throughout the body of the function the uses of the names INARC, OUTARC,
and WEIGHT are purposely ambiguous. That is I the ALLA syntax is ambig-
uous I so that each of these three names may be either properties or functions;

913
only the environment determines which is the case. Thus the SHPTHW
function assumes either the given graph already possesses values of the
three properties I or there are equivalent functions which compute them.

The program I which employs Moore I s algorithm [6] I begins on lines 6

and 7 by assigning an associated distance of infinity (actually ten million
here) to each vertex in the given graph. The THROUGH statement on line 6
specifies that the entity variable V should on each iteration of the range of
the THROUGH loop as sume the value of the next element of the set LELM (G) •
The term LELM(G) represents the left-element of the pair G, which is the set
of vertices of the given graph. On line 8 the starting vertex is given an
associated distance of o. The property DIST is being used to represent the
minimum known path cost from the starting vertex. Initially I the distance
assigned to the starting vertex is trivially known to be o. All other dis-
tances are assumed to be infinite, since without considering the graph's
connectivity all other vertices are potentially unreachable.

The algorithm consists of an iterative search .on Jines 9 through 21

followed by a reverse trace. The search begins at the starting vertex and a
distance is assigned to each vertex which can be reached from the starting
vertex by traversing one outgoing arc. Next, a distance is assigned to each
"r;leighb'or" vertex which is connected by an outgoing arc to one of the ver-
tices just assigned. The distance of each neighbor vertex is equal to the
distance of its previous vertex plus the weight of their connecting arc. If a
distance has already been assigned to a vertex, it is replaced with a new
dis tance only when the new dis tance is numerically smaller. This proces s
is repeated until a pass is made which does not improve any distance in the
graph. At this time, the distance associated with each vertex in the graph
is the minimum cost to reach that vertex from the given starting vertex.

The statement on line 9 should be read as "insert the element named

by entity variable A into a created set henceforth named by entity variable
DSET". The statement on line 10 has entity variables on both sides of the
equal sign. Whereas FORTRAN semantics dictate a copy would be made if
these were integer, real, or logical variables, the entity variable TDSET is
made to reference (or name, or point to) the entity referenced by DSET. In
general, this interpretation applies to entity expressions on the right side of
the equal sign, as occurs on line 14.

During each iteration of the search, the entity variable TDSET refer-
ences the set of previously assigned vertices. DSET names the set used to
keep track of the new vertices being assigned during an iteration. Line 21
contains the test for whether another iteration is needed. EMPTY is a pred-
icate function which is . TRUE. when its argument is a set with no members •.

Note that the ALLA programmer is required to perform his own manage-
ment of storage: on each iteration the DELETE statement on line 20 causes
the freeing of the space used to model the set referenced by TDSET.

After the last iteration there is a check at line 24 to ascertain if the

914
given ending vertex has been assigned a distance; if its distance has re-
mained infinite it cannot be reached, and there is no trace. Otherwise, the
trace starts with the ending vertex at line 25. Each incoming arc is con-
sidered along with the vertex from which the arc emanates. If the distance
of that vertex plus the weight of that arc equals the distance assigned to
the ending vertex, that arc is part of a shortest path. This process contin-
ues until the statement on line 26 determines the starting vertex ha s been
reached, at which time the answer has been computed as the set of arcs
SHPTHW.

IMPLEMENTATION OF ALLA

The ALLA data structure and language which has been introduced above
is implemented on two modular levels. First, the compilation of the la:ngua~
is effected by preprocessing all of the non-FORTRAN statements into FOR-
TRAN subroutine and function calls. The package of subroutines which con-
stitutes the run-time system to realize the ALLA data structure is the second
level of implementation. In order to provide for machine independence, and
allow for easier writing, debugging and modification, the L6 language was
selected for both the implementation of the ALIA data structure into a par-
ticular memory structure, and the preprocessing of ALLA into FORTRAN.
L6 was originally designed and implemented at the Bell Telephone Labora-
tories where it was named "Bell Telephone Laboratories I Low-Level Linked
List Language or L6 (pronounced "L-six ") [5]. Based on-the 'Original imple-
II

mentation on the IBM 7094, the author implemented UP. L6 for the IBM 7040.
In the process of translation, improvements and new features were added,
including the facility of linking L6 programs with both FORTRAN and MAP
assembly language subroutines [12].

The separation of data structure (the ALLA programmer l s view) from

the implementation of memory structure (the systems programmer's view) is
most valuable, especially when the language used to implement memory
structure is of the level of 1 6 • This modularity supports the freedom to
reorganize the memory structure at any time in order to adjust time-space
operating characteristics. Also, a researcher may use such a framework for
comparative studies of memory structures. For example, a doubly-linked
list approach might be compared against the utilization of lists with only
forward pointers.

ROLE OF THE GRAPHICS TERMINAL

A common concern of designers of computer graphics systems is the

choice of data and memory structures not only to model relationships among
the data, but also for the maintenance of the display of the data. When a
single computer system is used for the implementation of a computer graphics
system, the tendency is to employ one structure which can also be used to
drive the display controller. However, when the graphical equipment re-
sides at a remote site along with a small computer linked to the central

915
computer by voice-grade telephone line, a t least a graphics -oriented
structure must be maintained at the terminal for effective interaction.
One possible solution to the need for two structures in two (often)
different computers is the implementation of the same structure in both
machines. Perhaps the terminal computer woo ld handle a subset of what
the central computer can do. A strong motivation for such an approach is
the capability for having programs which can operate in either or both
machines. Although this is potentially powerful, unless the two computers
are appropriately related, it could be stifling to the effectivenes s of both
machines. Namely, the structure in the smaller one might be so general
that its small capacity is too quickly exceeded, and, at the same time, the
possibility for sophistication in the larger machine might be suppressed.

The advantages of modularity have dictated the division of labor em-

ployed in the Interactive Graph Theory System. A special-purpose structure
in the graphics terminal contains only the parameters relevant to the dis-
play of graphs. This structure and its associated display file are managed
by a special-purpose executive program named DOGGIE, for Display of
Graphs Graphicallnterpretive t.xecutive, which controls the I>EC-338-ter-
minal. As its name indicates, its primary role is the interpretation of a
speCial-purpose command language. DOGGIE commands are scanned by the
interpreter as sequences of 12-bit bytes which may either be received over
the telephone line from the central computer or taken directly from user
programs running in the DEC-338 itself. 16008 locations of the DEC-338
are reserved for the execution of these user programs which consist of a
mixture of PDP-8 machine language and DOGGIE command language. A
programmer-user of this system may easily avoid the need for knowledge of
the DEC-338 and restrict his programming efforts to the interactive ALIA
language. However, the facilities are available for anyone to write his
own user programs. User program preparation is performed using the termi'"
nal as a text console. The assembly of DEC-338 programs is carried out
on the IBM 7040 by the PDPMAP Assembly System [4J, which is significantly
superior to using the DEC-338 itself.

All DOGGIE commands implicitly refer to a scratchpad "paper" on

which a single graph may be defined. It is only one graph in the sense
that there is no facility for hierarchical grouping; however, the single graph
may consist of any number of disjoint components which may give the effect
of displaying more than one graph at a time. The graph may consist of any
number of vertices or arcs, and it may be only partially defined at any time,
since it is permissible to define an arc in terms of vertices which do not
yet exist. There is separate control over which parts of the defined graph
are to be dis pIa yed •

The graph maintained by DOGGIE is built, modified, and deleted

through interpreted DOGGIE commands. The command language inc! udes
elements which affect the gross aspects of the existing graph or the way in
which the graph is being displayed. A group of commands may refer to a
unique vertex or arc by internal name or to all existing vertices or arcs.

916
The option is also available for DOGGIE to supply a created internal name
when a vertex or arc is defined. A list of other services performed by
DOGGIE follows:

1. manages all input/output of the DEC-338 by handling interrupts from

the various display flags, the Dataphone interface, the minidisk,
and the Teletype.
2. manages the display of the graph on the "paper" with four window
sizes available for viewing all or any part of the paper.
3. performs light pen tracking with optional horizontal and/or vertical
constraints on a pseudo-pen-point.
4. interprets light pen hits as a result of a user's pointing at displayed
parts of a graph.
5. helps in the management of the pushbutton box.
6. handles overlays of user program segments by name by interfacing
with the PDP-8 Disk Monitor System.
7. collects and maintains status information concerning the state of
DOGGIE and its existing graph.

Note that this system deSign gives the programmer explicit control of
what is displayed instead of automatically monitoring the ALLA structure.
Also the division of labor employed makes it feasible to substitute another
I

computer at either end of the telephone line. For example, an equivalent

DOGGIE executive and set of user programs could be implemented on an
ADAGE terminal.

INTERACTIVE PROGRAMS

A user program which operates at the terminal is appropriate for prob-

lems where nearly instantaneous system response is important. An inter-
active algorithm may be entirely resident in the DEC-338, it may be entirely
resident in the IBM 7040, or it may be divided between the two computers.
There are facilities to shift the center of control from one computer to the
other. For example, an interactive ALLA program running in the IBM 7040
may call upon a user program in the DEC-338 as a subroutine.

An interactive algorithm written for execution at the terminal may be

appropriate only if minor computing is required and if associated data can
be conveniently represented within the framework of the terminal's data
structure. Although this is not the recommended method for implementing
graph theoretic algorithms the power of the small machine has been demon-
I

strated by implementing a user program which interprets a Mealy state

graph prepared in a prescribed format and carries out the operations of a
finite state acceptor. The "current" state is indicated by a blinking vertex,
and the user supplies an input character from the Teletype keyboard (or
paper tape reader). According to the typed (or read) character, an output
character (or string) is immediately typed out on the Teletype printer, and
the new current state is made to blink.

917
 The set of DOGGIE commands constitutes a machine-independent
language for controlling the display of graphs. The language in the pure
sense is not interactive since it is only an output language. It becomes
interactive when used in conjunction with other languages which include
control specification. The DOGGIE language is used in two different en-
vironments within the Interactive Graph Theory System: first, it is embed-
ded into ALLA language for execution in the IBM 7040. Second, it is em-
bedded into PDPMAP Assembly Language through macros for use in user
programs operating in the DEC-338. The use of the DOGGIE language in
either environment has the same meaning, which is to direct the DOGGIE
interpreter to perform commands which define, alter, and display graphs.

The writing of interactive programs is somewhat different in the two

environments, but the basic idea is common to both languages. The input
aspect of the interaction is accomplished by programming in the host lan-
guage the observation of communication cells. These cells reflect the
status of the DEC-338 and DOGGIE back to the programmer. The information
contained in these cells includes:

1. current graph display status - intensity, window size and pOSition,

2. light pen tracking indicators,
3. indication of the amount of available free blocks,
4. light pen hit information, and
S. complete status output for a vertex or arc.

A communication cell is a rather natural concept for use in the

DEC-3 38, for in that environment it is simply an accessible memory location.
User programs operating in the DEC-338 are written with references to the
symbolic names of these cells. There are some communication cells in the
DEC-338 which are used as indirect addresses of subroutines included
within DOGGIE, such as the subroutine to send an 8-bit character over the
Telephone line. A number of communication cells of this type are not du-
plicated in the ALLA environment.

Communication cells in the ALLA environment are referenced as any

other FORTRAN integer variable or logical variable. They are automatically
declared in each ALLA subprogram, so the programmer Simply references
these cells by symbolic name.

Many of the communication cells in the 7040 are essentially copies

of the "real" cells in the DEC-338. The "real" introduced here means real-
time. For example, a pair of communication cells indicates the position of
the pseudo-pen-point linked to the light pen tracking cursor. In the DEC-
338, user programs observing these cells may do so in real-time. However,
the communication cells of the DEC-338 are copied over to the 7040 only
when requested by certain statements in interactive ALLA programs. Since
this copying opera tion takes about one or two seconds to complete, and
since tracking may alter the position of the pseudo-pen-point every few
milliseconds the communication cells in the 7040 cannot reflect this data
I

in real-time.

918
EXAMPLE OF AN INTERACTIVE PROGRAM

An example of a rather small, yet complete interactive ALLA program is

presented in Figure 6. The following discussion references the SAMPLE
subroutine in Figure 6, which assumes a graph is already being displayed at
the terminal. On line 2, the subroutine call causes the clearing of the flag
associated with pushbutton number 11 on the pushbutton box at the terminal.
Line 3 contains a DOG statement which indicates the remainder of the line

LINE

1 SUBROUTINE SAMPLE
2 CALL CLRPB(ll)
3 DOG STAHT LTPEN WHOLE VERTEX# ALL
4 CALL MESSAG(2)
5 DOGSTRING 'POINT TO VERTICES TO BE'
6 CALL MESSAG(l)
7 DOGSTRING 'MADE SQUARE# PB 11 TO STOP'
8 10 DOG ALLHIT
9 20 W'AITCHANGE
10 IF (PBCll» GOTO 30
11 IF CLPHITI .EQ. 0) GOTO 20
12 DOG START EXIST SHAPE VERTEX 6#CLPHIT2)
13 GOTO 10
14 30 TERMINATE
15 STOP
16 END

Figure 6. Sample Interactive Program

is a symbolic DOGGIE command. This symbolic form of DOGGIE command

causes two 12-bit bytes to be sent to the DEC-338: octal 3600 and 0000,
which the DOGGIE interpreter will interpret as a command to make light pen
sensitive all vertices currently existing in the graph. Next, the statements
on lines 4 through 7 cause a message for the user to be placed on two mes-
sage lines at the lower left corner of the terminal's display screen. As the
text of the message indicates, this sample program allows the user to force
the shape of any vertex "seen" by the light pen to be made square (vertex
shape 6) until pushbutton 11 is depressed. The statement on line 8 causes
light pen hits to be allowed. The WAITCHANGE statement of line 9 shifts
control of the system to the terminal until some change occurs in the status
of pushbuttons, light pen, or Teletype input. When a change occurs, com-
munication cells in the ALIA environment are updated and control shifts to
line 10 where the current status of pushbutton 11 is checked. If it has not
been depressed by the user, control flows to line 11 where the communication
cell LPHITI is checked for a value of O. A non-zero value indicates a light
pen hit occured and the communication cell LPHIT2 contains the internal
I

919
name of the vertex which caused the hit. In this case I the statement on line
12 causes the shape of the hit vertex to be square.

SUMMARY

This paper has described how a remote computer graphics terminal with
processing power is used in a multi-console operating system as an alpha-
numeric console and an interactive graphics device. An Interactive Graph
Theory System was built in this environment to exhibit the effective use of
such a terminal and to demonstrate a design for a programming system for
solving graph theoretic problems.

In order to express interactive graph theoretic algorithms I the central

computer's FORTRAN IV language has been enriched with data structure and
associative operations and a class of statements to control the existence
and display of graphs at the terminal. The implementation of this language
employs a separate module to specify the underlying memory structure using
L6.
The terminal computer is managed by an executive program which in-
corporates an interpreter of a special-purpose command language oriented
towards controlling the existence and display of graphs. It may be pro-
grammed to carry out local functions as well as those which are performed
as subroutines of an interactive program running in the centra 1 computer.

Examples of system use and programming in the interactive ALIA lan-

guage have been presented.

All of the work described in this paper is fully reported in the author's
Ph. D. disseration [11] which includes complete programming manuals of
I

interactive ALLA and DOGGIE command language. Copies are available from
the author.

REFERENCES

1 C BERGE
The theory of graphs and its applications
John Wiley and Sons NY 1964

2 G G DODD
APL - a la·nguage for associative data handling in pL/I
Proc nCC 1966 677- 684

3 D K HSIAO
Afile system for a problem solving facility
Dissertation in EE Univ of Pa 1968

4 T H JOHNSON M S WOLFBERG
The PDPMAP assembly system

920
 Moore School of EE Report 68-11 Univ of Pa 1967

5 K C KNOWLTON
A programmer's description of L6
CACM Vol 9 No 8 1966 616-625

6 E F MOORE
Shortest path through a maze
Annals of the Computation Laboratory of Harvard Univ
Vol 30 Harvard Univ Press 1959

7 R P MORTON
On-line computing with a hierarchy of processors
Dissertation in EE Univ of Pa 1968

8 R P MORTON M S WOLFBERG
The input/output and control system of the moore school problem
solving facility
Moore School of EE Report 67-30 Univ of Pa 1967

9 N S PRYVVES
Man-computer problem solving with multilist
Proc IEEE 1966 1788-1801

10 R L WEXELBlAT
The development and mechanization of a problem solving facility
Dissertation in EE Univ of Pa 1965

11 M S WOLFBERG
An interactive graph theory system
Dissertation in EE Univ of PA 1969
also Moore School of EE Report 69-25 Univ of Pa 1969

12 M S WOLFBERG PAT WOLFGANG

UP .L6 - an L6 system for the IBM 7040
Moore School of EE Univ of Pa 1966 internal report

921
DEVELOPMENT AND PRODUCTION OF DESIGN
CHARTS USING A DIGITAL PLOTTER

A. W. Beeby and H. P. J. Taylor

Research and Development Division, Cement and Con-

crete Association, Wexham Springs, Slough, Bucks,
England.

INTRODUCTION

In 1964, a committee was set up to write a new Code of Practice for the
structural use of concrete. This Code is now in draft form and is in the
process of being introduced to the structural engineering profession.

The new Code requires a more complete design study of both the safety and
serviceability of structures and has introduced a more accurate method of
designing critical sections than any contained in previous Codes. The
process of section design involves determining how much steel reinforce-
ment is required to safely carry the imposed loads and moments acting on
the section. This process requires the solution of a set of equations which
is most easily carried out using design charts or design tables.

The introduction of the new Code means that new sets of charts will be
needed. In order to save the duplication of effort that would be involved if
this were done in every design office in the country, the British Standards
Institute commissioned the Cement and Concrete Association to produce a
standard set of charts. This paper describes the production of these charts
and also describes the development work that was carried out to ensure that
that the charts could be used quickly and with a minimum of error.

REQUIREMENTS OF THE CHARTS

In order to cover the cases met most frequently in design it was necessary
to produce five different types of chart: two types to design reinforced
concrete beams, with and without compression reinforcement, two for
reinforced concrete columns, and one for prestressed concrete beams. To

923
cover the full practical range of material strengths and geometrical
properties of the members, a number of each of these were required: in all,
156 charts were required. A vital requirement of the charts is that they
should be capable of being used in design to a sufficient accuracy. The
European Recommendations for an International Code of Practice suggest
that design calculations within 3% are adequate and the safety factors in this
and the new Draft British Code assume this order of precision. It was
decided to produce the charts on A4 size paper, as initial tests showed that
charts of this size could be read to the required accuracy.

WHY CHOOSE A PLOTTER?

The complexity of the section design equations and the fact that so many
calculations had to be made with slight changes of data required that a
computer be used to calculate the points from which the charts were to be
plotted. In fact, the early versions of the charts were plotted by hand from
figures produced by the Cement & Concrete Asso~iation 's Sirius computer.
When a Benson and Lehner Plotter was purchased and fitted on line to the
computer, it became apparent that great savings in drawing office time
would be made if the plotter could produce the charts to the required
standard. Obvious advantages are the ease of producing charts once the
programs are developed and the ease of running new charts if the design
parameters in the Code are changed. Another important advantage is that
the plotter is capable of drawing and labelling the charts in one operation,
so eliminating any human error in labelling large numbers of apparently
similar charts.

REQUIREMENTS OF SOFTWARE
The most important property required of the plotter software is that the
charts must be produced in a form suitable for immediate publication. In
this respect, it was fortunate that the software was being written at the
Cement and Concrete Association's Research and Development Laboratories
at the time the charts were being developed, so that a very useful feedback
could be arranged with the software writers. In its earliest form the
plotter software was written with upper case alpha-numeric characters only.
It was soon apparent that, because the Code had a notation employing them,
lower case and Greek letters had to be provided unless the charts were to
be labelled by hand. The first reaction of the software writer was that this
was difficult to provide because of the small size of the computer, the
mounting size of the plotter package and the fact that none of the teleprinters
had lower case letters. Eventually, these characters were provided and

924
 12
0.040
/~ 0.025
V 0JJ20

h ~~~ ......::::
10 0.015
V' V J....- t/' ASC
y v V
.....-:::: ~~ /" 0.010
~
~ I--
- b d,
-
~ b-'" l2=
~ ./
~ ~ v t/ 0.005
8 V I-- ..... -
~V J....- I--
4 ~~ ~
~ I--I-- I-- 0.000
..... ~
--
V I -I -
M ~e::: v I-
Ih ~V V l -I-- - ---
----- 2
bd, 6 r;;;" ~ -
~ ~
V t/
~ ~V
j.o'"
~
~ V
~ ~ ./
V
4 ~
~ VV
~b /
V V
V ~~ / V
2 v
~ VV
V ~ 1/
V [7
~ V
V V ..
- d."
0.005 0.010 0.015 0.020 0.025 0.030 0.035
Ast
1. Design chart 1. bd,
--
~
CI1
were addressed by setting a switch for lower case and using a code for the
Greek letters. At first, subscripts and primes which were needed to print
titles such as M/bd12 and Ast/bdl were not available. The titles were
therefore printed in a series of texts using a number of changes in print size
and pen shifts. By this time, the software writer was interested enough to
prove his virtuosity and wrote prime and suffix routines so that each of these
titles could be written in one text instruction. A glance at Figure 2 will give
an idea of the standard that was finally obtained.

At a later stage a need arose for a facility to draw dotted lines and this too
was quickly incorporated into the package. All these requirements were
met very rapidly and their need was seen because the software was being
written at the same time that a major programming job was going on using
the software. A further refinement that could be included is to introduce an
automatic facility to vary the space between letters according to their bulk,
as printers do in typesetting. The titles of the charts were printed in a
series of short texts and fine pen adjustments were carried out between each
section. The word 'prestressed' was printed'from the five text instructions
pr-es-t-r-essed
with a fine pen movement backwards in each space. It is hoped that an
automatic facility for this will be introduced in future versions of the
software.

PROGRAMMING

The programming for the charts was carried out in Sirius auto code from
which the plotter package was designed to be accessed. The programs were
written and developed in a period of three months. As the plotter has two
pens, each chart can be plotted in one run, including the titles. Thus, it
was not possible to title the charts incorrectly, so eliminating a possible
source of error. The section drawings on the charts (Figure 2) were
plotted separately as they required an intermediate size of pen.

LAYOUT STUDIES

The accuracy with which a chart can be read and the likelihood of making
mistakes when reading it depends on its layout. Though a fairly reasonable
layout can usually be achieved using common sense, it was felt· that these
charts required much more careful consideration because, since they are
intended to be a standard set of charts, they can be expected to be in constant
use by a great many people.

926
The nature of the problem set some basic restraints on the layout; for
example, the range of variables which had to be accommodated along each
axis was already fixed by the requirements of practice. The decision to use
A4 size paper imposed a further restraint.

At early discussions on the layout, it was decided that the grid increment
should be either a half, one or two centimetres so that a normal ruler with
millimetre divisions could be used to scale values off the charts. It was
further decided that each increment of the grid should represent O. 5, 1 or 2
units of the variable represented on that axis or multiples of ten of these
figures. Experience soon showed that these rules were incompatible with
producing a chart which reasonably filled the paper. Therefore, since a
brief investigation showed that hardly anyone would scale off the chart, the
rule on the size of grid was relaxed.

Once the programming had reached a stage where a prelim inary chart could
be produced, it was decided to use this to see just how accurately it could
be read. The chart used for this experiment is shown in Figure 1. The
test was carried out with the co -operation of partiCipants on a course on
Limit State Design which was being held at the Cement and Concrete
Association's Training Centre at Fulmer Grange. All people attending this
course were practising designers who would be likely to use design charts
of this type. Each person was given a copy of the chart and a set of fifty
questions to answer. Each question consisted of a value of M/bd12 and a
value of Asc/bd1. The answer was obtained by entering the value of M/bd12
on the vertical axis of the chart, reading across until the line corresponding
to the required value of Asc/bd1 is reached, then dropping down and reading
off the resulting value of Ast/bd1 from the horizontal axis. Four types of
question were set so that the errors resulting from interpolation for each of
the parameters could be isolated. These types of question were as follows

(1) An integer value of M/bd 12 was given, together with a value Asc/bd12
which corresponded exactly to a line on chart; interpolation was only
necessary in reading Ast/bd1

(2) Asc/bd1 exactly on a line; interpolation necessary for both M/bd12 and
A s t/ bd 1·

(3) M/bd 12 exactly on a line; interpolation necessary for both Asc/bd1 and
A st/ ba1.

(4) Interpolation necessary for all variables.

Each person was told that he had a different set of questions while in fact
they were given the same questions in a different order, the order of the

927
 0.5 1.0 1.5 2.0
12
11
10
9

8
N
E
E 7
.........
~
~~
Z

6 J'
"
~ ~ I-"";

-
N_
"C
.0
.........
5 .-
..4 ~
~"7
~ .? / '
10-

~~ ~ ~
::E
t;.......
4 ~ ~~
~ ......
~
3

2 ./
, ~~
~v

/'
V
./
/'
./
oL
0.5 1.0 1.5 2.0
100 Ast/bd,

Rectangular reinforced concrete beams

2. Design chart 2.

questions having been randomised by the computer which stored the final
order used on each question sheet and was thus able to re -sort the answers
later. This procedure was adopted to reduce the· possibility of collusion
between participants and to remove any effects caused by the order in which
the questions were answered. A preliminary test carried out on members
of the DeSign Research Department had shown that it was very easy to
misread the scale on the horizontal axis by one square (e. g. 0.023 instead
of 0.024). To try to reduce the likelihood of this mistake, half the
participants were asked to thicken the vertical lines corresponding to the

928
 2.5 3.0
4.0
/.
V ~

;--
V ~ L- ~ /
/

2.0
-0
~V
--
~ .c
~~
/
/ ........0
/
r/ ~ f- 1.5
~
Ul
;....- a:
~~
~ ~ V/ ~
~
~~
~
-'

-
/
1..-

I-- ~ I-- - - 1.0 0

0

-
~

-
dn/d, = 0.3 --------
I-- 0.5
~
/

I...- I-- ~ .-
/
i-- lIn/d, = 0.4 - - - - -
~
~ I-- ~
0.0 d,.Id, = 0.5- - - -
I--
I-- ~
I-- l -
I--I--

Uw 30

2.5 3.0 3.5 fy 410

numbers on the axis, i. e. 0.005, 0.01, 0.015, etc. (see Figure 1). The
participants were allowed half an hour to answer as many questions as they
could, after which the answers were punched onto paper tape and processed
by the computer. This processing consisted simply of sorting all the
answers to each question into ascending order and printing out the result.
All further treatment was done by hand since no adequate method had been
devised for rejecting answers which were definitely mistakes. These
mistakes were easily removed by hand since they all lay either at the
beginning or end of the list of answers. The only problem was to decide

929
where to draw the line between mistakes and legitimate inaccuracy. The
accuracy of the remaining answers was then assessed.

It was found that up to 15% of the answers were mistakes and since this
seemed an excessively large percentage, a careful study was made to try to
discover the causes of these mistakes. This could usually be done, though
it involved some degree of subjectivity. The causes of the mistakes fell into
four groups.

(1) Misreading the scale on the vertical axis (M/bd12)

It can be seen from Figure 1 that only the alternate lines on the grid were
numbered on this axis. This caused some confusion as many people misread
the un-numbered lines as halves, e. g. they read 3 as 2.5.

(2) Using the wrong Asc/bd1 line

This was the most common mistake and was of, two forms. Firstly, the
value of Ast/bd1 was misread by a factor of ten, e. g. 0.0025 was misread
as 0.025. This accounted for about 80% of the mistakes in this category.
The remaining mistakes were caused by using the line adjacent to the
correct one, e. g. 0.015 for 0.010.

(3) Misreading the answer from the Ast/bd1 axis

Commonly this scale was misread by one square, 0.017 for 0.016. As
mentioned earlier, this source of mistakes had been forseen and half the
participants in the test had thickened up every fifth line. This reduced the
errors in this category by half.

(4) Other causes

These were mistakes for which no specific cause could be found and errors
in writing down the answer, commonly transposition of two digits.

Once these mistakes had been removed, the accuracy with which the chart
had been read could be studied. This was done by finding the number of
answers which lay outside ~ 3% and ~ 5% of the correct answer. It was found
that five questions were answered particularly badly when judged against
these criteria. Four of these were questions of type (4) where one had to
interpolate for Asc/bd1 in the region of the discontinuation in the curves.
Attempts to do this will show that it is not easy. For example, using
Figure 1, try finding Ast/bd1 for M/bd12 of 6. 35 and Asc/bd1 of 0.0025;
this was one of the badly answered questions. The fifth badly answered
question had as data M/bd12 = 2.65 and Asc/bdl = 0; the correct answer to
this is Ast/bd1 = 0.00795. Not unnaturally, the common answers to this

930
question were either 0.0075 or 0.008; O. 0075 is just more than 5% out.
Table 1 shows the accuracy with which the various types of question were
answered both with the five poorly answered questions included and with them
removed. It is felt that these results are satisfactory.

It was concluded from these results that, although the size of the charts and
of the grid was satisfactory, the likelihood of mistakes would have to be
reduced considerably. Once the common causes of mistakes had been found,
it was not difficult to think of changes in layout which would make it less
likely that these would occur. To this end the following changes were made.

(1) Every line on the M/bd12 axis was numbered instead of alternate lines.

(2) Every fifth vertical line was thickened.

(3) Values of Asc/bd1 and Ast/bd1 were multiplied by 100 and given as
percentages.

(4) The Astlbd1 scale was marked along the top of the chart as well as the
bottom, because the user's hand obscures the bottom scale while the
chart is being read.

(5) One Asc/bd1 line was removed and the numbering of these lines improved.

After the addition of titles and further identifying information, the final
version of the chart is shown in Figure 2. This chart was given to
participants on another similar course at the Cement and Concrete
Association Training Centre and tested in the same way as the earlier
version. Figure 3 shows a comparison of the mistakes made in each
version of the chart tested: the chart as shown in Figure 1, the same chart
with every fifth vertical line thickened, and the chart as shown in Figure 2.
Comparing the first and second columns in Figure 3, it can be seen how
thickening the lines has reduced the number of mistakes made in reading the
Ast/bd1 axis, while mistakes from other causes have not changed signifi-
cantly. If the results from the original chart are compared with those from
the final version, it can be seen that the numbers of mistakes have been
reduced in all categories except for those caused by transposition and
unexplained circumstances. These are in any case errors not associated
with reading the chart but rather with reading the question sheet and writing
the answer down. The largest source of mistakes remains the use of the
wrong Asc/bd1 line. Multiplying the values of Asc/bd1 by 1 00 has reduced
the errors caused by confusion over the number of zeros after the decimal
point by a factor of four. It is not clear how the layout could be further
improved to reduce these errors; however, most reinforced concrete beams
and slabs used in practice are singly reinforced (i. e. Asc/bd1 = 0), in

931
which circumstance these mistakes do not occur. Not surprisingly, the
accuracy with which the second chart could be read once the mistakes had
been removed was not Significantly different from the first chart.

A word of caution must be added here about the results of these tests. The
participants were asked to answer fifty questions in thirty minutes; in a
design office where the charts would be used less intensively, considerably
more care would probably be taken over each reading. Thus, the actual
percentages of mistakes made are probably higher, and the accuracies
lower, than those which would occur in normal use; nevertheless, the
comparisons between charts are still valid.

More generally, these tests have shown how apparently quite trivial
alterations in presentation of data can make great differences to the general
efficiency of a chart. It also raises the whole question of the clear and
unambiguous presentation of graphical or visual information, a subject
which must surely be relevant to a symposium on computer graphics. It
must be clear that it is not sufficient merely to output this information,
whether on a plotter or on a cathode ray tube: it must also be in a form such
that it can quickly and easily be assimilated and used with the minimum of
ambiguity and the maximum possible accuracy. This may be particularly
important in some display techniques where the information is not retained
for future reference.

FURTHER WORK

Because of the results from the tests described above, it was decided to
carry out further tests to gain a greater inSight into the problems involved
in graphical presentation of data and, if pOSSible, to develop some basic
rules of good practice.

In the true research manner, the first tests attempted to break down the
operation of reading a result from a chart into its basic sub-operations and
to study these.

In its simplest form, the use of design charts involves:

(1) Taking the number which constitutes the input data and interpolating on
the scale on one axis a point corresponding to this number.

(2) Carrying this point across to a curve on the chart.

(3) Transferring from the curve to the output axis.

932
:4) Estimating the number on the output axis.

rhe first tests, which is shown in Figure 4, was designed to test operations
Land 4 listed above. In the first column (marked 'IN') the 'testee' had to
nark on the short section of scale a point corresponding to the number given
)ll the left. In the second column (marked 'OUT') he had to write down the
lumber which he thought corresponded to the point marked on the section of
scale.

rhe results of this test were treated by tabulating, for each question, the
iifference between the correct answer and the answer given. For the IN
:.!ase, this was in millimetres, and so the results from the OUT case were
:.!onverted to an equivalent figure in millimetres for easy comparison. The
standard deviation of the results about the correct answer was then
:.!alculated.

I\.s the IN and OUT cases both gave substantially the same answers, tLe two
were averaged and these averaged results have be.en plotted in Figure 5.
rhis Figure shows the averaged standard deviation of the errors in milli-
metres plotted against the grid size (i. e. 5, 10, 20 and 40 mm) for the
various ways of numbering the grid. The best result was obtained for the
scale using two units per division of the grid, followed by one unit per
:iivision and half a unit per division. These three gave results which were
fairly closely grouped for each grid size. The final grid numbering used, a
~uarter of a unit per division, generally gave worse results.

rhese differences in accuracy with different numberings for constant grid

size can only be due to confusion over the scales chosen. This is shown
most clearly from the results from the third and fourth questions in the
second section on the IN side (Figure 4). Both questions require that the
~rid interval be exactly bisected, yet the standard deviation of the answers
to the first question where there was one unit per division was 0.75 mm
whereas for the second question, where there was 0.25 units per division,
:he standard deviation was 1. 6 mm.
[t had been assumed before this test that one unit per division would be the
nost accurate; thus the result actually obtained, which shows two units per
iivision to be better, was rather a surprise. Why this should be so is not
!lear but may be in some way due to the particular questions chosen.

fi'rom Figure 5 it is possible to estimate the change in accuracy which will

)ccur if the scale on a chart is varied. For example, if a chart is drawn
with a 20 mm grid along both axes using a scale increment of one unit per
livision and the accuracy is compared with the same chart drawn over a

933
 \
\
\
\
\
\
\
Mistaken \
Ast I bd1 5'28 % \
\
\
\
\
2· 81 % \
\
\
.... ........ \
\
\
\
\
\ \
Mistaken \ \
Asc I bd1 5'65 % \ \
\ \
5.30 % ~
0.53 %

2,82 %
Mistaken
1'67%
-- ....
-
M I bd12 1'61 ....
--
%

Transposi tion
& unexplained 2.18 % 1.81 % 2·00 %
errors

Chart 1 Chart 1 Chart 2

with
th ickened
lines

3. Summary of mistakes made in using the three versions of beam design

charts.

934
 IN OUT
6-21 I I I
~
I
7 6 7
5-32
~ ~ l I
~
1-18 I I I I I
1'0 1·5 1'0 1'5
0-38 I I I
0-25 O-~O 0-25
I
0-50
1-65 ---t- I II I
1 1 2 1 2
2-60

7-70
6 4-
3 6 I
~
I I I I
7!5 8 7-5 8
2-79 I I I I I
2 4 2 4
0-11 I I I I I
0 0·25 0 0-25
8'33 I I I I
8 10 8 16
2·90 I I I I I
2·5 3·0 2-5 3-0
4·50 I I I I
2 4 5 4
I
5
3-88 I I I I I
3-75 4-00 3-75 4-00
1- 63 -~
1
-+2 1
I I I
2
2-58 I I II I
2·5 2·75 2-5 2-75
7'75 I

9·20 I
6 8
I
t-+t
3 9 10
I II
9
I
10
0'40 .1. I
0 0·5 oI I I
0-5
3-40 -+-------+ I Ii
3 4 3 4
0·17 -+---+
·1 ·2
-4-+
-1 -2

4
0-32
H -n
2-0
H -4-+-
05
37 -+-+-
25 50
-H-t-
25 50

4_ Interpolation test.

935
5 mm grid with 0.25 units per division, the ratio of the standard deviation of
the errors on the 20 mm grid to the standard deviation of the errors on the
5 mm grid will be about 0.82, not the fourfold increase in accuracy which
might have been expected. .

Grid sizes of less than 5 mm were not examined, but common sense suggests
that the increase in accuracy that would be achieved by reducing the grid
size to, say, 1 mm would be small. It is doubtful whether the standard
deviation of the errors could be much less than 0.2 mm, and experience on
the beam design charts suggests that a high percentage of the results would
be misread by one or two millimetres. Thus, it seems likely that any
increase in accuracy obtained by reducing the grid size below about 5 mni
would be offset by an increase in the number of mistakes.

To check the results from the test described above and to obtain further
information, a series of five charts was produced. The charts were
identical in size with a single identical curve. Four of the charts had a
20 mm square grid but with different numbering systems on each, while the
fifth chart had a 5 mm grid with every fourth line numbered 1, 2, 3, 4, etc.
Figure 6 shows these charts to a reduced size. Each person participatiIig
in the test was given a chart and twenty questions to answer. Although the
numbers given to each person were different, depending on the scale of the
chart, the questions corresponded to the same points on each chart. Thus,
the results from the different charts were directly comparable. The four
charts with the 20 mm grid corresponded to the results for a 20 mm grid
obtained from the previous test while the chart with the 5 mm grid
corresponded to the example discussed above.
In treating the results from these tests, the first task, as before, was to
remove any mistakes from the answers. The total number of mistakes made
on each type of chart was estimated and these figures are given in the fourth
column of Table 2 expressed as percentages of the number of answers
obtained for each chart. As with the design chart tests, the decision as to
whether a particular answer was a mistake or merely on the edge of the
distribution of reading errors is often subjective and different people marking
the results would produce slightly different results; thus the figures should
not be considered as exact. They do, however, clearly show the superiority
of using one unit per division and the inferiority of using 0.25 units per
division.

To study the relative accuracy of the charts, the results from the 20 mm
grid marked with one unit per division were taken as standard and the
performance of 'the other charts was estimated relative to these. Similar
ratios can be derived from Figure 5 for the previous test. The fifth and

936
sixth columns in Table 2 show these comparisons both for the interpolation
test and for the five charts. It can be seen that the two sources generally
agree except for the case of two units per division. This performed better
than one unit per division in the earlier test but was worse in this later test.
Since the chart test result is based on many more data than the interpolation
test, it is probably the more reliable result.
The accuracy with which a particular answer can be obtained on a
particular chart will depend on the gradient of the curve at the point
considered. Elementary statistical theory leads to the following relation-
ship between the accuracy of a result and the gradient of the curve:

-E 5. Results of interpolation test. ",

......

-
E "
/
/
",
"
." L"
0,\/
\/
. ~C:>/
~\/
~......

O·~
~ I-' ,~
/'
+
4~ ......
,,- " 4
~"Q
" + ." V"
- "." " "
o
c
~' "

~/
I~
~'
\~
.~J6~""""'"

rr/
o
~
nJ 0-5 + /'
>
tI • = 0'25 units/div
'0
'0
+ = 0·50 units I div
L o = 1-0 units I div
nJ
'0 A = 2·0 units I div
c:
~ 00
1
(/) 10 20 30 40 50
grid size (mm)

Equation 1

where OTOT = standard deviation of result

= standard deviation of error in reading from the x
axis

937
6
I I
t- .
t- A ,.... '- ~ """"
~~
5
L-- ~
~
~
~tI"
4 l/
V
V
3 I

II
J
2 II
I
II
1 J
I
!I
o
1 2 3 4 5 6 7 8 9
12

B ~
~
~
10
~
l/
/
8

/
/
4

o
v
2 4 6 8 10 12 14 16 18
938
6

c ....--
~
5 ~
~
/
V
4

/
/
2

o ~ 1 2 3 4 5 6 7 8 9
3

D ~
~

~
~
:/
Iv
2

/
/
1

o
/ 1 2 3 4
939
 E ~
...-
~
V
V
V
1'0

/
/
0'5

o
I
0'5 1·0 1·5 2·0
6. Chart test.

.-x
.-
80
•
CI)

-,
0

X 70
'0
C
60
•4 •
0
Q)
c 50 '\
t:
Q)
40 \
\•
Q)
~

"".
~
Q)
.0 30
Q)
Ol 20
c
« ~ ~I-----. [calCulated result from
equation 1
II

CD
10
• •
0·2 0'4 0·6 0·8
Standard deviation of error (mm)

940 7. Results of chart test.

 0y = standard deviation of errors from reading in only
axis
e = tan- 1 (dy/dx)

Values of Ox and 0y for the scales used may be obtained from Figure 5 and
hence the standard deviation of the errors for each question on each chart
may be calculated and compared with the actual values from the tests.
Agreement was generally found to be good, as can be seen from Figure 7.
Where there is a family of curves and interpolation between these is
necessary, there will be a further term in equation 1 defining the accuracy
with which this operation may be carried out.

A number of additional tests has been carried out with other courses at the
Training Centre. These have investigated other types of design chart, the
accuracy obtained when equations for the design of reinforced concrete
beams are solved using a slide -rule instead of a chart, some general work
on the accuracy of slide-rule calculations and some work on the optimisation
of graph paper deSign. However, sufficient has-been written here to support
the formulation of some general rules on layout for the clear presentation of
information in graphical form.

LAYOUT RECOMMENDATIONS

(1) Size of grid.

This should be as large as possible consistent with the required accuracy.
Grid sizes of less than 10 mm should generally be a voided as they cause an
increase in the number of mistakes which outweighs any increase in
accuracy. If smaller spacings are essential, then some lines should be
thickened. The ideal size is probably 10 to 20 mm.

(2) Numbering the axes.

(a) The numbers should preferably be in the range 0.1..;N..;100. Numbers
much outside this range tend to confuse.
(b) The best system of numbering is to have one increment of the grid
corresponding to one unit of the chart variable. (i. e. each line of the grid
numbered 1, 2, 3 etc.) This is the least confusing and probably the most
accurate. However, 2 or 0.5 units per grid increment are also acceptable;
0.25 units per grid increment should not be used.

(3) Accuracy.
For the most satisfactory result, the commonly used parts of the curves
should make an angle with the x axis of not less than 30 0 (assuming the
graph is to be read, y axis ---> curve ---> x axis).

941
In practice, these recommendations may sometimes be incompatible and
may need modification. It is hoped that there is enough general information
in the paper to show the likely effect of any such modification. The precise
criteria which a particular chart or graph is required to fulfil should be
borne in mind in designing the layout: e. g. for some uses, clarity may be
more important than accuracy.

TABLE 1
Accuracy with which design chart could be read.

Type of question interpolation for Percentage Percentage

errors errors
M/bd 12 A /bd 1 Ast/bd 1
sc
> ~ 3% > ~ 5%

(1 ) - - X 0 0

(2) X - X 5.8 2.8

(2) with question

7 removed X - X 4.6 1.7

(3) - X X 5.0 0.8

(4) X X X 9.6 2.6

I
(4) with four I
questions removed X X X 4.7 0.3

All questions
combined 7.1 2.2
I I
All questions
except the five
badly answered
questions. 4.7 0.5

942
TABLE 2
Comparison of various types of grid and numbering for the interpolation tests
and the chart tests.

Type Grid Numbering Mistakes Interpolation Chart test

size units/div in chart test
(mm) (%) (Fig. 4) (Fig. 6)

C 20 1.0 2 1.0 1.0

A 5 0.25 5 0.82 0.82
E 20 0.25 7 1. 53 1. 45
D 20 0.5 4 1. 20 1. 36

B 20 2.0 4 0.85 1. 38

CONCLUDING REMARKS

The authors feel that the production and proving of the design charts
described in this paper has highlighted a number of points of general
relevance.

Firstly, as in any situation where a service is provided, the customer is

always right. In this instance, it is the job of good software writers to
produce software which fully satisfies the users I requirements. These
requirements may be stringent but the usefulness of the result depends on
their being met. Of course, there must be a degree of compromise here
but the user should be a party to this compromise; it should not be left
entirely to the software writer. In the project described here, the plotter
was used only on the condition that the end product was of a quality suitable
for publication. Had the results required re-drawing, it would have been
more economic to use the computer to produce the numbers only and then to
plot the charts by hand. It has been clearly demonstrated in this case that
these requirements can be met where there is a close co-operation between
the software writer and the user.

943
Secondly, the function of any graphical output is to communicate information.
The latter part of this paper shows clearly how the user of computer-graphic
facilities must take great care in the presentation of this visual information
if it is to be communicated with maximum efficiency. The precise layout
chosen will depend on the use to which the information is to be put. For
example, maximum accuracy of reading a chart is not compatible with an
absolutely minimum likelihood of mistakes being made. A balance has to be
struck between these two. This paper gives data which should allow this
balance to be struck more rationally than has hitherto been possible.

ACKNOWLEDGEMENTS

This paper is presented by permission of Dr R. E. Rowe, Director of

Research and Development of the Cement and Concrete Association. The
authors would like to express their appreciation of the unstinted efforts of
members of the Operational Research Department, particularly
Mr W. G. Batchelor, to meet their often very stringent requirements. Also
thanks are due to those people attending Limit State Design courses at
Fulmer Grange over the past two years who have participated in the various
tests described in this paper.

944
 PART 11

Graphic Languages
 A FORTRAN PACKAGE FOR
INTERACTIVE GRAPHICS

O. A. Budin

Department of Engineering, University of Leicester,

Leicester, England.

1. INTRODUCTION

1.1 Hardware

The hardware used throughout this development work was an Elliott 4130
64K 2J,lsec, 8 mag. tape handlers and 4280 grap~al dispJ.q. The effect
of the 64K of core dedicated to the display and the effect of no disks
and no separate keyboard for the display each played a positive part in
shaping these programs. Furthermore the author struggles to remain an
engineering applications programmer.

1.2 Origins

This package of routines has developed from the need te rationalize and
organise the various problems of producing-a large interactive graphics
applications program (the LUISA system (Ref. 1, 2)). The illustrations
show the layout used on the screen and an example of each of the present
display control devices (only one device would normally be used at a time).
The main interaction processor or reaction handler subroutine is the
kernel of the package but there are also other routines which ofier
separate facilities in themselves. These include same routines for
reading users' messages from data cards, displaying them on the screen
and changing them by simple subroutine calls referring to a code for each
message. Display control device routines can also be used independently
of the main interaction processor routine. They are described below in
more detail. There are also some routines for updating the display of
"last operation", "central processor unit" and "real" times on the screen.

1.3 Means of Interaction

The three major classes of interaction that seem to be offered by a

digital computer equipped with a c.r.t. display screen are:

947
(a) the selection of an operation or sequence of operations which the user
may wish to perform. ("DO THIS"),
(b) the identification of an object or symbol which represents some part
of the users data or model ("TO THAT"),
(c) the control of the value of one or more program variables ("BY THAT
MUCH") .
The means of interaction on the Elliott 4280 graphical display are:
(a) the lightpen which can return the identifying number of the item
which it sees while the footpedal is depressed,
(b) the eight display console buttons which can return a number
between one and eight each time they are depressed,

(c) the keyboard which can return a code for each key as each key lS
depressed.
Three other means of control are also available:
(a) a "mechanism" is available whereby the execution of a program may be
delayed for a specified number of refreshments of the displayed
picture,
(b) a tracking cross may be activated to return its x and y coordinates,
(c) the eight display console buttons along with six sense switches on the
main control console may be examined to see whether they are on or off.

2. INTERACTION PROCESSOR

2.1 The Case for Some Sort of General Purpose Processor

with this apparatus there is clearly the potential for complicated

arrangements of interaction and on-line control. As each newcomer to
this apparatus develops interaction programs, ingenious arrangements
are devised for combining the various interaction facilities demonstrated
by each research project undertaken by undergraduates, research students,
staffs and industrial.workshop participants in Leicester University over
the last eighteen months, and as a program expands so the organisation of
the interactions gets more inVOlved.

The graphics package described in this paper is written entirely in Fortran

and makes extensive use of the FRED package (Ref. 3) and the elementary
data structure routines (OPEN, IALLOC, RETURN etc.) supplied. by the
computer manufacturers. Although the FRED package is very well tailored
for FORTRAN programs there is a need to develop many more facilities for
general use in the computer-aided design field. This package of Fortran
subroutines for interactive graphics, developed in Leicester, amount to
a prototype of such facilities. The interaction processor, in this
package, is a suggestion for how to go about organising a large repertoire
of interactions and on-line controls. It was designed to act as the

948
main control program for the package of programs which are becoming known
as the LUISA system. However it is written in such a way that subroutines
which it is desired to control with this interaction processor have
simply to be loaded onto the operating system tape, a deck of data cards
(which describe each subroutine and their arguments), have to be added
onto the end of the main program deck, and a few program cards have to
be added to the main control program. These two last mentioned decks of
cards are prepared according to a few'simple rules (see 2.4.2 below and
page 14). With these facilities the introduction of additional interactionf
and controls is so simplified as to actually encourage such additions,
whereas, experience proves that without these facilities a definite
discouragement exists. Apart from LUISA, this package has been used in
the three dimensional drawing scheme (Ref. 4) being developed in
Leicester (by Mr. R.J. Hubbold).

2.2 The Operation of a Program from the Display Screen Using the
Interaction Processor (I.P.)

The layout of the screen prepared for the execution of programs using
the I.P. is shown on page 12. The main features of the operation of the
I.P. are:
(a) the display control devices, the buttons, the tracking cross, the
lightpen and the keyboard all supply values to a set of value buffers,
(INTEger, REAL, etc.) where the value in the buffer is displayed
immediately above the name of the buffer,
(b) one of the value buffers on the screen will be the active value
buffer, but anyone can be made active by 'hitting' (i.e. seeing)
it with the pen; the active value buffer has an arrow beside it to
indicate that it is active,
(c) at the start of a run only the top lightbutton name in the hierarchy
will appear on the screen.with.the next level ax menu. of options
(or lightbutton names) displayed beneath it,
(d) when one of this menu of options is hit then that particular
lightbutton name is placed in the next command position and the
current manu of options is replaced with the next lowest menu,
relevant to this last option chosen,
(e) if there is only one option in a particular menu then this one is
automatically 'chosen', placed in the next command position and its
next menu of options is displayed,
(f) if a route has previously been specified through. the hierarchy of
menus then this route will automatically be 'chosen' and displayed,
(g) the last command hit with the pen (whether it is one from the current
menu or a command previously chosen) will be the active command and
will have an arrow placed above it,
(h) if when a string of command names exist and a new option is chosen
higher up the hierarchy which will indicate that a different route
is being started through the hierarchy then the rest of the existing

949
 command string is removed from the screen to avoid confusing or
irregular command strings,
(i) a command name may be made active by hitting it with the lightpen,
and the current menu of options will be replaced with the menu
relevant to this new active command,
(j) the last command name in any route through a hierarchy must be the
execute command name (ensured by the order of the data cards - see
below), which when hit causes an attempt to be made to execute the
command specified by the string of command names (which are simply
a list of subroutine names and those arguments requiring values to
be input at run time),
(k) if when an attempt is made to execute a command string an argument is
found which does not have an appropriate value 'in' it then a message
is displayed to this effect and that argument or command name is made
active and therefore ready to receive a value from a value buffer,
(1) execution may also be attempted at the depression of button one if
that mode of execution has been chosen with a lightbutton; the option
is also available to be able to attempt execution whenever button one
is found to be 'on',
(m) values are inserted from the active value buffer to the active command
when the value buffer is seen, or when button two is depressed, or
when button two is found to be 'on'; the particular mode of insertion
being chosen again by lightbuttons,
(n) if on an insertion attempt the value types of the active value buffer
and the active command do not match, a message to that effect is
displayed, and the insertion is not made,
(0) whenever the machine is busy with a calculation or an operation, a
message to that effect is displayed, the message being replaced by
a call for action on the part of the user when it is idle again,
(p) when button five is on, values are inserted directly into the
appropriate active value buffer from any display control device which
is seen, from the buttons when depressed, from the tracking cross,
from the lightpen when it sees items on the screen and from the
keyboard,
(q) a menu of display control devices is permanently on the screen with
an arrow indicating which one is active at anyone time,
(r) when button six is depressed another copy of the active control
device is set up and displayed at the position of the tracking cross,
(s) when button seven is depressed the next control device of the active
type which is seen by the pen, is removed from the screen,

2.3 The Processor Programs

The processor consists of various subroutines for setting up the data

structures and pictures for the menu hierarchy, the set of value buffers
and the menu of control devices. Each of these sets of routines use
smaller, simpler routines for reading characters into beads, displaying
characters and standard pictures, for stringing beads into lists and for
changing and moving sets of displayed characters.

The main processor subroutine is in two parts. The first calls on the
various "set-up" routines, creates data structures for the menus, displays
the first menu on the screen and puts all the logical variables in their
initial state. The second part has a flow-chart which starts with a
"main control" label followed by a main line which can be diverted around
several side loops depending on whether certain buttons are on or off.
This is followed by a call to the interaction routine after which the
flow of the program branches according to the type (button, pensee,
keyboard) of interaction received. Along the path for each type there
are then further branches corresponding to the various values which may
have been returned by the interaction device.

The buttons are reserved for major operations, such as execution of a

previously chosen subroutine, or the operation of the synchronised
camera or the creation of a new display control device. The lightpen
is used for the many detailed choices required in a thoroughly interactive
program because it is more difficult to indicate the meaning of a set of
buttons; with only eight buttons various meanings would have to be assigned
to each button. From experience it has been found that the organisation
of complex sequences of interactions is far more satisfactorily achieved
by the use of lightbuttons. Another very important feature of such a
processor is that all possible interactions are positively catered for.
Control always being returned to the main control label after each
interaction is processed. If an attempt has been made to execute a
subroutine whose arguments are not set in the correct range or an attempt
is made to insert a value somewhere of the wrong type or an unexpected
picture is seen etc., then an error message to that particular effect ~s
displayed and control is still returned to the main control label.

Although interaction procedures are greatly simplified by organising them

through a single call to the interaction routine there are of course
cases where it is very convenient to include an interaction call inside
one of the users operation subroutines. This is of course possible and
although it complicates the problem of time keeping it is very easy to
keep the user well informed of the relevant set of actions that he can
take at all times by means of the messages. For this purpose it has been
found useful to allocate two positions on the screen for messages to be
displayed, one position being used only for informing the user of the type
of action he can take at anyone time, and the other position for warning
and error messages.

2.4 The Preparation of a Program for Execution from the Processor

2.4.1 An Example
As an example let us look at the Fortran subroutine MUVE, whose call
would normally be

951
 CALL MOVE (WHAT. HOWNOD. IVAL, XMVE, YMVE, HOW, WHLINE,
INTEGX, INTEGY, ZD, DF)

where
(a) ZD and DF are present to carry over the free storage data zone (array)
and the display file (array),
(b) WHAT is expected to be a code indicating that a NODE, or an ELEMNT
or a NDLIST (node list) is to be moved,
(c) HOWNOD is a code only relevant to the option NOD~ of the previous
argument and js expected to bea code indicating whether the node
to be moved is to be located with a tracking cross, WCROS, or a
quadrilateral device, WQUAD (see below),
(d) IVAL will be a boundary of an element in which a node is to be
selected or a boundary of the element to be moved or a pointer to a
node list, depending on the option. chosen in the first argument,
etc., but the diagram on page 13 makes the rest of this subroutine and
its corresponding command almost self-explanatory in the light of these
few note s above.

Each series (note definition in diagram on page 13) of options 1S

arranged to appear on the screen in turn according to the route chosen
through this hierarchy of series. Thus, an example of a choice of options
might be
MUVE NODE WCROS BDY/NL MOVEX NOTMVY TOCROS
which amounts to the command in English:
"move the nodes chosen with the tracking cross from the element containing
this boundary, in the x direction and not in the y direction to the
position of the tracking cross". Execution of this command will of
course need the depression of buttons (specific type of interaction) at
certain places to indicate when the choice of each node is complete and
when the movements of the nodes with the cross is to be stopped. These
subsidiary actions are of course requested by displaying the appropriate
messages on the screen.

Having designed each subroutine and its command structure (like the one
shown for MUVE in the diagram on page 13) a single call to each sub-
routine must be prepared in a special generalized form to go into the
execute routine of the I.P. This execute routine contains a computed
GO TO statement and the calls to all the subroutines to be executed
from the processor. Data has also to be prepared to describe the command
structure and to arrange for each series of options to appear on the
screen at the appropriate time and place.

2.4.2 Preparation of Data for Execution of a Subroutine from the

Interaction Processor

(a) Each subroutine name and each option for each subroutine argument

952
 needs one data card (i.e. one for each name, or lightbutton, that
will appear on the screen),
(b) in addition one data card is needed which forms the head (or starting
point) of the hierarchy, called OPERAT, and which points to the first
level of options. One other card is also needed which forms the tail
(or lowest level or terminating point) of the hierarchy and is called
EXECTE,
(c) the format for these data cards is shOw"ll on page 14. There follows
here a more detailed explanation of the names of these input variables:

NMSERS (13) a group of options for each subroutine name or arguments

form a unique series with a number or code defined by
NMSERS. This number has a reference to enable each
option of a series to refer, or point, to another series.
The head of the hierarchy (OPERAT) forms a series of its
own and is given the number 1. The tail (EXECTE) also
forms a series which happens to have been given the
number 17 (!).

ARGNBR (13) Each argument of a subroutine has to be given a number

which is used in its generalised call (in the execute
subroutine) . This argument number also enables the
correct retrieval of the input value for the argument
from the data structure of the hierarchy. For instance
when one particular sequence of options for one sub-
routine does not involve some of the arguments in that
subroutine (see above example in MUVE).
NAME (2A4) Is the name which will appear on the screen to represent
its subroutine or argument option. It is therefore,
effect i vely, what is commonly called a lightbutton. The
pointer to the data bead (Ref. 5) in the menu hierarchy
data structure containing all.the information about this
option is used as the item identifying number of the
picture of this name in the display file in order to enable
rapid processing of the data' associated with each option .
displayed when it is seen by the lightpen (Ref. 6). Only
six of the eight characters are usually used (the last two
being blanks) so that more names can be fitted in across
the screen.

VALTYP (12) - Is the type of value which is associated with the display
option. If VALTYP is equal to 2 it indicates that the
option is the name of the subroutine. If it is greater
than 2 it indicates that the option is an argument name.
If it is equal to 3 then it indicates that no value has to
be inserted into the argument name but its selection will
make available a code (associated with the particular
argument name) to the execute routine. If it is equal to
4 or 5 or 6 then the argument needs an integer, real or

953
 character value, respectively, to be inserted before
execution is possible.

VALUE (14) - Is (a) if VALTYP is equal to 2, the number chosen to

uniquely represent the subroutine associated with the
option name (as is used in the computed GO TO statement
m the subroutine), (b) the value of the code if VALTYP
~s equal to 3 and (c) equal to -10 if VALTYP is equal to
4, 5 or 6.
NXTLV (13) - Is the number of the next level (or series) ~n the
hierarchy, relevant to this option.

ILLIM (17)
Are the lower and upper limits of the range of values
IULIM (18) which will be expected by the execute routine if the
VALTYP is equal to 4 (i.e. an integer value).

RLLIM (FIO.5) Are the lower and upper limits of the range of values
which will be expected by the execute routine if VALTYP
RULIM (FIO.5)
is equal to 5 (i.e. a real value).

3. DISPLAY CONTROL DEVICES

Although the display control devices described below are thoroughly

integrated into the ideas of the interaction processor, they are a set
of subroutines which can be used quite separately from.i~. A new device
can be added to extend the menu of devices by
(a) preparing data for a new menu name in a similar way to the bead for
the menus of options (see above), and,
(b) inserting a few instructions into the main processor program to deal
with a pensee of this new menu name.

3.1 The Need for Display Control Devices

The development of these devices was prompted by the often recurring need
to control the value of one or more program variables - such as scales,
orientations, dimensions, coordinates, aspect ratios and the values of
various parameters used in optimization routines. Parts of a picture
more closely representing the actual parameter to be varied or controlled
could easily be arranged to change in sympathy with the movement of the
tracking cross or a value input from buttons or the keyboard. Indeed
there will be cases where this is preferable to using any special control
device. But there are other problems of varying the value of a variable
interactively.
One problem of inputting a number from buttons or keyboard is how to be
explicit about how many digits are to be input and which digits they are

954
intended to be. A problem of directly controlling the value of a variable
from the position of the tracking cross is the limitation on the range and
the sensitivity. The need to be able to specify the magnitudes of the
upper and lower limits of the range of variation and the problems of
definition in controlling more than one variable at once all add to the
incentive to produce some routines to organise these methods of controlling
variables.

A display control device will of course not always be necessary but as

the problems mentioned above, of controlling values of variables, are
encountered some or all of the features of this control device arrangement
are very likely to be redeveloped. Nevertheless this arrangement is by
no means fixed and final. Further experience along with some repetition
of development will undoubtedly lead to a more elegant and efficient
scheme.

3.2 The Organisation of the Devices

After specifying some routines for all these cases some common features
were apparent and a set of control devices have been designed and
implemented on the following lines. For each control device there are
three routines,
(a) a routine for setting up a device on the screen, assigning. identifYing
numbers, to the parts of the device, in a strictly controlled range.
These identifying numbers are grouped into distinct sections:
those which will, when seen, lead to action and those passive to being
seen. Any number of devices of anyone type can be set up at one
time because the group of identifying numbers is. relative to a number
specified to, and incremented by the set up routine~
(b) a routine for operating the device; enabling values to be changed andl
or ranges to be set as those active parts of the device are seen,
(c) a routine for removing the device from the screen.

The set of devices are controlled by a menu of names of devices which are
displayed on the screen along with an arrow indicating which device type
is active. The active device type is then the one which can be set up,
made operational or removed by three buttons reserved for these purposes.
The values returned from a device can then be used for setting the values
of the variables that are to be controlled. For instance a program loop
could be set up which would cycle through (a) a check on the button
assigned to make the active device operational, (b) a call to the active
device operation routine to pick up one or more variable values, (c) an
entry to the user's calculation and redisplay routines and (d) a return
to (a) (producing a "Figure of eight" flowchart). This would then enable
some dynamic calculation and display to proceed in sympathy with the
control device.

3.3 The Operation of the Devices

955
3.3.1 Devices in Use at Present

(1) A digit changer (DIGT): Three routines have been written to set up
~SUDICR), operate (OPDICR) and remove (REDICR) a device to enable the
s~ven digits of an integer variable to be specified by lightpen sees of
displayed digits. The device as it appears on the screen is shown on
page 12, where
(a) the digits at the top represent the value of the variable being
changed,
(b) the small arrow underneath one of these seven digits indicates which
digit is to be changed next - i.e. the active digit position,
(c) the digit, of those in the circle, seen by the pen will be inserted
into the active digit position if the device is in the 'digit value
required' state,
(d) a pensee of a digit puts the device into a 'triangle required state',
whereupon the central triangle must be seen to return it to the
'digit value required' state,
(e) a pensee of the W puts the device into a 'digit number (or position)
required' state, whereupon the next digit seen will move the small
arrow to sit under that digit position and sets this as the active
digit .position,
(f) the active digit position increments one position to the left or
right depending on whether the L or the R was last seen.

(2) A continuous scale, thermometer like, value changer (THRM):

Three routines have been written to set up (SUDTHE), operate (OPDTHE)
and remove (RIDTHE) a device to enable the variation of a variable through
a range of values which are only limited by the largest and smallest
numbers that the computer can represent. The device as it appears on the
screen is shown on page 12, where
(a) the long thin vertical rectangle is an active part of the device such
that when it is seen the bar (which moves up and down this rectangle)
is placed at the y-coordinate of the tracking cross (as long as it is
within the length of the rectangle),
(b) the bar indicates the value of the variable returned by the device;
the value being proportionally between the upper and lower limits
of the range which the thermometer represents at anyone time,
according to the proportion of the height of the bar to the length
of the thermometer.
( c) the numbers 2.0 and 4.0 are an example of the limits of the range of
the thermometer at this time~
(d) the displayed words INCREASE and DECREASE are also active parts of
the device and when seen cause the range to increase (in this case
from 4.0 to 8.0) or to decrease (in this case from 1.0 to 2.0) res-
pectively. The seeing of one of these active parts puts the device

956
 into a state which requires the thermometer rectangle to be seen
next, and also moves the bar to the opposite end of the rectangle,
(e) a number of devices of this type can be set up and operated in turn
as the user chooses,
(f) the exponential of the range is set within the set up routine and is
of course in this case, equal to 2; if there is a need for being able
to easily change this exponential then it could be arranged to change
it dynamically during the operation of the device.

(3) .An orientation changing" joystick" (JOYS): Three routines have been
written, to set up (SEALS) a set of "angled lines", to operate (OPALS)
and to remove (REALS) any or all of the set. On calling SEALS a line
appears at the tracking cross, on calling OPALS one end of the line
follows the tracking cross and an angle between 00 and 3600 is returned.
Thus for example the orientation of an object on the screen can be
arranged to move w sympathy with this angle. (Also shown on page 12.)

(This device can be extended (using the length as a parameter) to

represent a 3-D joystick pivoted about the centre of a sphere which
would return three values which could in turn be used to control the
projected view of a 3-D object. Incidentally, in TDD (Ref. 4) it has
been found more convenient to use three 2-D joysticks.)

(4) A quadrilateral range finder (QUAD): Three routines have been

wri tten to set up (QUSTUP), operate (QUOPTE) and remove (QUFMVE) a
device to establish whether a point is inside or outside a convex
quadrilateral. Within the operate routine the option exists of changing
the position of the whole quadrilateral or moving any vertex across the
screen before "asking" whether a given point is inside or outside.
(Also shown on page 12.)

4. DISPLAYED MESSAGES

4.1 The Use of Messages

One of the nice features of operating a program from a c.r.t. display

screen is that an operating manual is not necessary. If all possible
actions are indicated to the operator at anyone time and warnings and
error messages displayed after each irregular action then the program
is effectively self-teaching. Knowledge of programmed teaching methods
would of course be useful but it is fairly easy to follow simple rules
to produce a program which fresh operators can teaea ~hemselves how to
use by trial and error.

Nevertheless extra written or oral instruction may be necessary to

illustrate ingenious, possibly obscure, sequences of operations that
might not readily occur to the new operator.

It is possible to take the trial and error method of operation to a very

957
interesting extreme where no instructions or warn~ngs are displayed but
just the effects of each action are shown to the operator, however
bizarre. This is only possible in cases where all the information being
handled and the effects of the operations on this information can be
expressed in totally graphical form. There is of course a need then to
incorporate all the facilities necessary to recover from the effects of
single, or ·sequences of, regrettable operations.

But most interactive programs that attempt to include any self-teaching

features need a large repertoire of messages with frequent changes on
the screen. This aspect of interactive graphics is therefore a candidate
for a specially designed package of routines.

4.2 The Message Routines

One routine has been designed to read characters from a data card and
insert them in A-format into a bead of data (using the free storage
allocation routine) and return the handle or pointer to this stored string
of characters or message. Another routine reads a series of such
messages and stores the pointers to each in another data bead, and a
third routine sets up two positions on the screen where all the messages
will be placed and replaced. This routine also initially displays the
first two messages at these two positions. A further routine enables
the message displayed at either of the two positions to be changed for
another message. The programmer uses a code number to refer to a
particular message and a code number to refer to the position where that
message is to be displayed. Thus CALL MESCHG (2, 3) causes the present
message at position 2 to be replaced by message 3. A fifth routine is
used to display series of characters at the required size and brightness
and location on the screen. The data input for messages is illustrated
in this example :
01
04
WAITING FOR YOU
03
04
INPUT MISMATCH
02
07
DATA STRUCTURE WRONG TYPE
04

958
where the first number is the code number of the message and the second
is the number of characters divided by 4 and rounded up to .the next
largest integer. "WAITING FOR yOU" etc. are of course the messages to
be displayed.

5. FUTURE DEVELOPMENTS

At the time of writing, this package of Fortran subroutines and its various
sub-packages are undergoing a maj or overhaul to introduce several new
features which have arisen from several months of use of the packages,
and discussions with colleagues and friends in Leicester and Cambridge
(namely Mr. R.J. Hubbold, Dr. R.F.D. Porter Goff, Mrs. C. Grafton and
Dr. C.A. Lang). Some of the new features will be:

(a) the digit changer and the thermometer device will be replaced by a far
more flexible and convenient device for controlling the value of a
variable,
(b) the ability to put a value into this variable controller as well as
take one out of it will be introduced,
(c) the control of a synchronised camera will he included in therapertoire
of controls available at the 'top level',
(d) the ability to be able to create a personal file or list of commands
which will be output at the end of each run and re-input at the
beginning of the next run, each personal command being defined by the
user of the c.r.t. in the usual way from the pre-defined hierarchy,
except that it will be possible to store its definition instead of
executing it. The file will also be editable from the screen,
(e) the limitation of a maximum of 100 subroutines on the ICL 4100 series
has led to an effort to amalgamate several groups of subroutines
into single subroutines (as large as they are allowed to be) to
minimise the number 'taken up' by the package. Care is also now being
taken to ensure that as much Fortran code as possible is in the
setting up routines to enable as much as possible to be overlaid.
(f) Variable length 'value buffers' will also be introduced,
(g) the execute light button will always be placed on the far right-hand
side of the screen regardless of the number of options within a camman~
(h) some routines are being written to ease the problem of keeping an
accurate display of the division of real time between the user and
the central processor unit,
(i) a larger character size will be used for the menu options and a
corresponding adjustment will be made in the layout on the screen.,
(j) each successive menu will be displayed at a different position from
the last one (i.e. alternating between two nearby positions) in
order to prevent gulps of options by the light button (which although
entertaining are inconvenient) ,

959
(k) the majority of the items displayed for the 'top level' control will
be removed from the screen whenever the execution is down 1n a level
below the 'top level' (i.e. within a users sub:toutine),
(1) a separate light button package will be developed on much the same
lines as a device for individual use in users suites of 'screen
executable' subroutines,
(m) a dimensioning device is being produced to simplify the interpretation
of dimensions on the screen.

It is recognised that this package is by no means appropriate for every

graphics application, even in the C.A.D. field. It has proved to be
very useful in systems of programs involving many interactions which
have no pre-defined order. As the industrial co-operative workshop
scheme continues in Leicester 'candidates for packages' (not for the
post) will be isolated and facilities provided for the more conventional
'paging' teChnique for programs with well-defined sequences of interactions.

REFERENCES

1. BUTLIN, G.A., and R.J. HUBBOLD: A Scheme for Man-Machine Interactive

Analysis, Int. Conf. on Computer-Aided Design, I.E.E.,
Southampton, April 1969.

2. BUTLIN, G.A.: Man-Machine Interactive Structural Analysis as a

Preliminary Design Aid, paper presented at the AGARD
Symposium on Structures and Optimization, Istanbul, October
1969.
3. The FRED package - Fortran IV Routines for the ~lliott Qisplay,
Vol. 2, Part 16: Section 3~

4. HUBBOLD, R.J.: TDD - An Interactive Three Dimensional Drawing

Program for Graphical Display and Lightpen. ibid.

5. ROSS, D.T., : The AED Approach to Generalized Computer-Aided

Design, ACM National Meeting 1967.

6. THORNHILL, D., et al: An Integrated Hardware and Software System

for Computer Graphics, MIT 1968.

ACKNOWLEDGEMENTS
The work presented 1n this report was done while the author has been

960
employed as a Research Fellow in connection with S.R.C. Grant No.
B/SR/3383. The University's Elliott 4130 was used for this work and
the assistance of the Computer Laboratory's staff is gratefully
acknowledged. This project was initiated by Professor G.D.S. MacLellan
in 1966. The author also acknowledges the many useful discussions
held with members of the C.A.D. group in Leicester and the extensive
assistance from many members of the assistant staff of the Department.
Acknowledgement is also made to Dr. D.T. Ross and Mr. D. Thornhill
for their extremely valuable assistance in introducing me to computer
graphics while I was a guest at MIT in the spring of 1968.

001
~

WAITING FOR YOU REL 6 B CPU 2 14 LOP 0 0

Interaction request and Real Time, CPU time,
... . .. .. ...... . . . ... . DIGT THRM JO';f.S QUAD
warning messages ~ast OPeration time in minutes
and seconds
Menu of display control devices
with arrowhead showing which
is active

81324
"Joystick" device with c.
tracking-cross "Digit Changer" device with the
L W R sixth digit about to be changed
0 9
1
~ b. 8
2 7
3 6
4 5
INCREASE
4.000000
"Thermometer" device with a
value between 2.0 and 4.0 "Quadrilateral" device placed
available over two nodes of a triangular
element which have just been
aligned on the y-axis by exe-
cution of the operation MUVE

2.000000

An example of a command DECREASE Eight input buffers with their

generated from the hierarchy latest values above their names
81.J2.<f. 2..&00 ~
.,.. 600 ..,
XT..... tt.
and an arrowhead indicating
of options, with an arrow- %NT" ...."L (:.Hoi", V BWTT YTIt"tI. V&C.T
>'S" which is active
head indicating which is acti OPEAAT MUt'1J. NODI' "".UfII,D .PV/NL HaVeK NOrMVY ,"oellos £XET"E'

ILLUSTRATION OF THE SCREEN SHOWING THE LAYOUT AND FOUR CONTROL DEVICES
 MENU DATA SHEE.T FOR INTERACTION PROCESSOR
, ~ ~." /.'" ~.
"((,4r ~ "'~ ~.,4r ~~ ~
,,~, CI"""; .".:. ~ ., ~ .... ~ ,~AO ~ .$ .$ 4
....
, ,v
# rJ. tf .,,"~ ~~ ~fl...I;,.'-' .)-I':.J,.q. ..l~·" ~' fl·
~~
!/'fI) rJ>oII,.. y>'" ..i" ~, Jl" o· ,~ o. ~.". I "," I
~..> ..q; ~.. ~..,. +~.., ~q ~ ..., .tJ ~q ,tit

FORTRAN FORMAT IS IS 2~" 12 14 JS 17 1'7 FlO,S FlO,S

I
c:.OL.UMN NUMB_Ii 4 , 15 n ~I ~ ~I
,. ~ 1
I
I
- - - -- __ LJ

ffi
~
I~i -SERIES 1
•
. • ~
f- <
rrw:.:1 ... i\Z" ,..,.,..",.. I."..,..,.,.,. •I SERIES 2
argument
DO. name
, t SERIES 3
1 WHAT ELafir

- -.... SERIES 4

3 IVAL h::l I""\V ~"II - SERIES 5

III ..' "•r X .. InT·• .. \ IV i • SERIES 6

4 XMVE
 I
I -----..
IMOVEY NOTMVY I . SERIES 7
5 YMVE
I I

SERIES 8
6 HOW ITOLINE TOPONT TOCROSr
I I 9
7 WHLINE I • SERIES
I I SERIES 10
8 INTEG X lWH~EJ IXPOSI

II • SERIES 11
9 IlfTEGY lyJ,SI

-- SERIES 17
IEXt:.'~ I t:.1

~ DIAGRAM SHOWING A TYPICAL HIERAJtCHY OF SERIES OF OPTI(lfS

 VISPLA Y, THE C.S.I.R.O. GRAPHICAL
FORTRAN SYSTEM

G. Shearing

Division of Computing Research, C.S.I.R.O.

P.O. Box 109, Canberra City, A.C.T. 2601, Australia.

1. INTRODUCTION

1.1 Interactive Computing in General

Nowadays, there can be few enlightened members of the scientific

computing fraternity who are not convinced that interactive computing has
many benefits to offer. In particular, program development is greatly
speeded up. However, the main emphasis in this paper is in so~ving problems
(of a difficult scientific nature) with the aid of graphical display
facilities.

The fundamental idea is that man and computer should work together in
partnership, for the abilities of one naturally complement the abilities of
the other. In some fields, clearly the computer is very much superior to
man - inverting matrices, for example. However, it should never be over-
looked that man is far superior to the computer in many other fields. For
example, consider the problem of recognising human faces, something we all
do every day with apparently little effort, regardless of the angle of view
or the lighting conditions. This is rather an extreme example but, in
general, the human eye-brain combination is extremely efficient at extract-
ing vital facts from pictorial information.

The scientist, with his training and experience, can be expected to

solve difficult problems in his field if a computer is used to do the
'number crunching' and present the results in pictorial form for him to
study.

Although this sounds straightforward, when one gets down to the details,
it is quite difficult to provide really good facilities for this type of
interactive system. There are often constraints and conflicting requirements
from other computer users to be taken into consideration.

Recently, there have been published several books on the subjects of

interactive computing and computer graphics. Some of these have been

967
frequently referred to while the work described here was under development.
They are listed at the end as References 7, 13, 14, 16, 17, 18 and 22.

It is worthwhile to briefly classify various types of interactive

computing systems. They differ both in their fields of application and in
the sophistication of hardware and software necessary to provide them. The
list is probably not exhaustive and the boundaries between some of the
classes can be rather blurred in practice.

i) Documents or files are retained in the computer system and

the user may modify them.

ii) A job may be entered from a terminal.

iii) A program may be executed immediately and the results studied

in alphanumeric form, (possibly with the user controlling
the program as it runs).

iv) Within a limited field, (e.g. statistics), a user interacts

in a 'question and answer' mode under the control of a
spec1a
• . I program.

v) The user specifies parameters and results are displayed by

a program in graphical form; the user studies them and
repeats the process.

vi) As for v) but with the extra facility of altering parts of

the program also.

In C.S.I.R.O. we now enjoy all the above facilities. (There are also
other, more specialized, types of interactive system such as 'computer aided
design', 'computer aided instruction', and airline seat reservation systems.
These are rather outside the scope of the typical general-purpose scientific
computing environment and will not be considered further).

Let us elaborate on some of these types. For developing programs,

i), ii) and iii) are perfectly adequate and can be implemented on teletypes
or character display devices. However, it should be realized that they
mostly provide rapid turnaround for running normal jobs. For on-line
problemrsolving, however, a graphical display facility is required -
"a picture is worth a thousand words", (or numbers). This brings us down to
stage v).

If the programmer anticipates everything clearly in advance, he may be

able to make good progress with his problem by experimenting with various
sets of input parameters. However, as Poincare, the famous French mathemat-
ician, stated about a hundred years ago, "The question is not, 'What is the
answer?' The question is, 'What is the question?'''. In other words, to
solve the problem, it is first necessary to ask the right question by having
the correct program. With some problems, it is virtually impossible to get

968
the program right at first, hence the desirability of the type vi) inter-
active system. The way in which this has been achieved within an existing
computing environment is the main topic of this paper.

~ Computing in C.S.I.R.O.

The Division of Computing Research provides most of the computing

facilities for the Commonwealth Scientific and Industrial Research
Organization in Australia. This organization has numerous research stations
allover the Australian continent and has an annual budget in excess of
$50A. million.

The D.C.R. does computing for users from a very wide range of scientific
disciplines. Its main computing facilities are located in Canberra but
there are smaller machines in other cities.

The Canberra computer is a Control Data 3600 and most of the work
(about 70% of all jobs) is run in a batch-processing manner. The operating
system known as 'DAD' (irums ~nd iisplays) has been developed mainly by
members of the Division over the past four years and will be described in
the next section.

The VISPLAY (Vista and dis~) system has been written completely
within the existing DAD framework. However in order to understand the
development and workings of VISPLAY, it is necessary to describe some back-
ground information in the next three sections.

2. THE 3600 AND THE DAD OPERATING SYSTEM

2.1 General Description.

The 3600 at Canberra has a 32K, 48-bit word core store of 1.5 ~s
cycle time. A magnetic drum backing store has a capacity of over a million
words and the transfer rate is 250,000 words/sec (2 million characters/sec)
with an average access time of 17 ms. Furthermore, any number of consecut-
ive words can be transferred directly between any core and drum locations -
an extremely useful feature. A disc file provides storage for a further
16 million words. A collection of standard peripherals includes card reader,
card punch, three line printers, two graph plotters, two paper tape readers,
two paper tape punches and 8 magnetic tape units. Thus, it is evident that
the installation caters for a wide range of scientific programs in a
conventional batch-processing system.

However, multiple-access facilities are also provided. These will be

described more fully in Section 2.2. The 6 DD 210 display consoles
originally provided the only means of direct access to the system but more
recently the teletype system has been added. This is controlled by a PDP-8
computer, which is connected to the 3600, and there are currently 8 remote
teletypes at various locations around Canberra but only 5 may be connected

969
at anyone time. The teletype system is organised so that it appears, to the
3600, to be part of the display subsystem, (see 2.2).

There is also the Vista device which is described below in Section 3.

Most of this paper will be concerned with the Vista and one DD 210 but it
should always be borne in mind that these form only a small part of the
total DAD system.

The main feature of the DAD system is its use of the high-speed drums.
All input and output is buffered via the drums. A document is a piece of
information, usually a program and/or data for input or produced by a
running program to be sent to one of the output devices. However, the
program can also manipulate documents directly. Most documents are serial
access documents; that is, they are stored on the drums as a series of
linked records in a kind of list structure. As documents come and go, this
allows the space to be fully used without frequent re-ordering of the
material. Documents can also be preserved in the system; this is necessary
for the display and teletype systems.

An alternative way of using the drums is by means of random access

documents. Here, information is copied directly in a single drum transfer
operation, thereby bypassing the elaborate buffering and linking process
of serial access documents. This technique is used a great deal by the
operating system itself, for example~ to call in a compiler. Random access
transfers are an order of magnitude faster than serial access transfers.

All documents are referenced from within a program as logical ~it

~umbers, ('luns'); control statements define the correspondence between the
document names and luns.

Fuller descriptions of the DAD system can be found in Refs. 1, 2, 3, 8

and 15.

2.2. The Display Subsystem

This is so called because it can be turned off if necessary while the

rest of the DAD system continues to operate. It is rarely turned off
however, during normal working hours.

The 'displays monitor' organises the time-sharing of a single display

program in core with the main job. It also organises the swapping of
programs from different display consoles or teletypes between core and drum.
The core store normally contains the 'resident' part of the monitor,
(including the displays monitor), an active display program, input-output
buffers for serial drum and peripheral transfers, and the current main
program. The system is described in [151~

A DD 210 display console is illustrated in Fig. 1. It consists of a

CRT screen which can display 25 lines of 40 characters each and an alpha-

970
numeric keyboard. There is also a row of function keys and an interrupt
button. The information on the screen can be transmitted to the CPU (and
vice versa) in about 35 ms. The information on the screen is not copied
to the CPU until the interrupt button is pressed. The screen acts as if
it were a memory while the user types or thinks.

To use a particular display program at a console, a user must 'log in'

to that program by typing a simple message on the screen. From then until
he 'logs out' the action at that console is determined by the display program
and what the user types. The most commonly used display programs are for
editing documents stored on the drum but there are others which, for example
copy documents between disc and drums, list a user's drum documents and list
the magnetic tapes currently mounted.

One special feature of the DAD system in this respect is that anyone
with sufficient knowledge can write and develop his own display programs
while the main system is running. There is little danger of 'crashing the
system' while this is being done since the displays monitor acts as a safe-
guard. It is now even possible to write display programs in Fortran, [6],
but there are restrictions because a display program is limited to 2000 words.

Besides logging in to a display program, a user may make simple requests

to the system directly, e.g. delete a drum document, print a document,
execute a program, (more strictly, put it in the queue of programs awaiting
execution). It is also possible to run a short job 'immediately'. In
practice, this means within 2 or 3 minutes if the system is busy but if not,
within 2 seconds.

2.3. The Control Statement Language of the DAD System

To run a job under DAD, besides his program and data, a user must
include some control statements. For standard jobs, these usually have
almost the same form and the simple-minded user regards these as somehow
necessary for the running of his job.

In reality, there are over 50 distinct control statements, which fall

into about 20 groups, (many of which have only a single member). These
statements may be regarded as constituting a kind of language in their own
right, namely, the language in which the system is instructed to run the
user's job. A flexible operating system necessarily requires such a
language.

A few examples will be given, all of which have relevance to the

VISPLAY system. The full description is given in the DAD Manual [8].
An example of each statement is given on a separate line followed by the
meaning.

i) *DESC,BK,1630

971
 The job uses the breakout facility and will not start before 4.30 p.m.
(see 3.2 below).

ii) *EQUIP,I=(CBCCR*GS,ABC),RO,SV

Lun 1, (as referred to in the program), is the document with 'charge

code' CBCCR*GS and name ABC. It is a '~ead £nly' document and will be saved
(i.e. retained on the drum) at the end of the job. The job cannot start-
until this document is available.

iii) *FTN,I=10,L,X=20

Call in the Ior~ra~ compiler to read source program input from lun 10
and list the program on the standard output unit. The program is to be
executed and the resulting relocatable binary (RLB) document written to
lun 20.

iv) *LOAD

*RUN,2

These two almost always come together. Load the various RLB
subroutines, filling in cross references, read the complete program into
core and enter it. The program will be terminated automatically if it
runs for over 2 minutes.

3. THE VISTA GRAPHICAL DISPLAY EQUIPMENT

3. 1 The VISTA Hardware

This is a Control Data DD 250 device and is described in detail in [4].

The user console has a CRT screen with a 1211 square working area, a light
pen, an interrupt key and three rows of function keys which may be used to
specify an integer in the ranges 0 to 7, 0 to 7 and 0 to 63 respectively.
The device can display characters (in four sizes), dots and vectors at or
between any points of a 1024 x 1024 grid. Two levels of intensity and a
flashing on-off mode are provided by the hardware for any part of the
picture. Characters may also be displayed sideways or in italics. The
Vista console with an elaborate picture on the screen is shown in Fig. 2.
The Vista has associated with it a controller which is like a small special-
purpose computer and communicates with the 3600 via a high-speed data
channel. The controller has a memory, (the Vista buffer) which can store
over 4000 24-bit 'instructions'. Typical instructions move the electron
beam to position (X,Y), display strings of characters starting at the
current beam position, or set subsequent elements to be displayed at double
intensity. The 'program' in the controller is arranged to recycle
indefinitely so that a picture on the screen is continuously regenerated
and normally appears static. (A built-in delay of 20 ms prevents the
picture from becoming too bright and burning the screen coating). Typical

972
instruction times are: move the beam to a new position, 1.25 ~s; display a
character, 2.5 ~s; draw a basic vector, (see 3.3. below), 2 to 12 \.lS,
depending on the length. Any part of a picture may be made 'penable' i.e.
capable of being detected by the light pen. When the pen is pointed at
such a part an interrupt is generated and its buffer address stored.

The controller also has instructions for addition and subtraction,

register tests and return jumps to subroutines. These allow quite elaborate
drawing and tracking operations to be performed by the Vista controller
alone without the aid of the 3600.

A picture which is to be displayed is first built up in the 3600 as an

image of the Vista buffer. This is then sent off to the controller almost
as if it were output for any other peripheral device. Special instructions
are used to start or stop the controller cycling through its program
thereby displaying or erasing the picture on the screen.

Figure 1 (Visplay System) .

973
 A fairly recent development has been the addition of a camera,
automatically operated by the Vista controller, (and thereby, indirectly,
by the user's program in the 3600). It is a Robot Recorder with a 75 mm
lens mounted 6 feet in front of the screen and permanently focussed on it.
Photographs may be taken either manually or under program control [24].

Figure 2 (Visplay System)

3.2 Special DAD Facilities for Vista

Since a picture on the Vista screen will remain displayed until another
one is sent from the 3600, the 3600 is not required for the full duration of
a Vista job. There are times when the user merely wants to study the
picture at leisure. Also, since most Vista programs use elaborate Fortran
subroutines, it is not normally possible to incorporate them into the
display subsystem since their storage requirements are too great.

974
 For these reasons, the breakin-br~akout facility was provided. On
encountering the special breakout instruction in the 3600 program, the DAD
monitor causes the main Vista program in core (with a record of all vital
registers and other necessary information) to be copied directly to the
drum and the program temporarily suspended while another one starts or
resumes (see below). This is normally done immediately after displaying a
picture on the screen.

However, as soon as the 3600 receives a Vista interrupt - produced by

the user pressing the interrupt key or the light pen detecting a 'penable'
element, the main Vista program will 'breakin'. This causes the currently
running main program to be likewise suspended, written off to the drum and
the user's Vista program brought back and resumed exactly as it left off.
By this means, a Vista program may take possibly an hour to run in real
time but only use a few minutes CPU time. Note that this process depends
for its efficiency on the speed and versatility of the drums.

Two comparatively minor facilities, (in terms of systems programming

effort required) have nevertheless been very important in practice for
Vista users.

Firstly, the 'deadline time' option has been described in 2.3,(i).

Its judicious use can save a user from having to wait around for his job
to start and is especially useful for those who normally work away from
the computer building.

Secondly there is now a mechanism which, in effect, gives Vista jobs a

priority in the scheduling process. Jobs are arranged in queues, 'long'
jobs (>4 minutes) and 'short' jobs; no long job can start if there is a
short one present. Since a Vista job almost always runs in short bursts
it may be regarded as a number of short jobs even if its total time defines
it as a long job. Such a Vista job can be classified as 'short' provided
it never runs continuously for more than two minutes without breaking out.
However, after 20 minutes CPU time has been used, it is automatically
terminated. The above facilities have been described in [3] and [8].

3.3 Vista Software

Although the Vista device is capable of displaying elaborate pictures

combined with complicated light pen operations, it is extremely tedious to
program at the lowest level - even with the aid of the special Vista macros
which were written (Appendix 13 of [8]). It is made even more complicated
by the fact that the hardware can only display vectors with a maximum dis-
placement in the X and Y directions of 256 grid points (i.e. a quarter of
the screen). Consequently, to draw a line from A to B may require as many
as four basic vector instructions and interpolation is necessary to work
out what these instructions are. Furthermore, the displaying of a string
of text is also rather awkward since the characters must be packed up three
to a word and preceded by a special 'setup' instruction. Therefore, for the

975
user with a real problem to solve, some high-level software is absolutely
necessary so that he doesn't have to worry about these complications.

Two such systems are now in common use. They are both subroutine
packages, originally written in Compass Assembly Language, but used as
Fortran subroutines. They are known as the PLOTV and VISTRAN systems and
are fuily described in [12] ancCT26] respectively. Both of these packages
are independent of the VISPLAY system and they differ fundamentally in the
range of facilities provided.

PLOTV was designed for fairly simple applications where the main
program generates a complete picture, displays it on the screen, and breaks
out. The user then studies it, alters parameters, generates another picture
and so on. It does not allow the light pen to be used but the programming
is very simple, (especially for one familiar with the local graph plotter
software).

VISTRAN , on the other hand, allows all the potential power of the
Vista to be used. Instead of a complete picture being the basic unit as
in PLOTV, it allows the user to work with parts of pictures. These basic
parts may then be displayed, shifted, rescaled, rotated and erased in any
combination. A simple example of the use of VISTRAN is shown in Fig. 3.
It provides light pen detecting, tracking and drawing facilities. There is
also a group of subroutines which use VISTRAN for performing standard tasks,
including the copying of pictures on the graph plotter [25] and the use of
the Vista camera [24].

Both PLOTV and VISTRAN include simple Fortran calls to break out and
read the Vista function keys. As a measure of their relative complexity,
their specifications are 7 and 51 pages long respectively.

4. KWIKTRAN

This is a locally written version of the standard Fortran compiler-

loader system and is fully described in [11]. Although the basic compiler
is identical, the system differs in the following respects.

(i) The most commonly used library subroutines are read into
fixed core locations in a single drum transfer. This
not only avoids the scan of the whole library but the
loading of the necessary library subroutines as well.

(ii) An intermediate Compass Assembly Language stage of

translation is replaced by a fast one-pass assembler
which generates absolute code.

(iii) The system uses random access drum transfers for maximum speed.

(iv) With the experience of the previous system under DAD, some
vital parts were rewritten in a more efficient manner.

976
 Fortran Program Vista Screen

DIMENSION SQUARE(30), CROSS (20)

C GENERATE AND STORE IMAGE OF
C SQUARE IN 3600
CALL CLEAR (SQUARE,30) .......
CALL MOVE (0,0)
CALL VECTOR (0,1023)
CALL VECTOR (1023,1023)
CALL VECTOR (1023,0)
CALL VECTOR (0,0)
C GENERATE AND STORE IMAGE OF
C CROSS IN 3600
CALL CLEAR (CROSS,20)
CALL MOVE (512,412)
CALL VECTOR (512,612)
CALL MOVE (412,512)
CALL VECTOR (612,512)
C DISPLAY SQUARE AND CROSS ON VISTA SCREEN
CALL DISPLAY (SQUARE,CROSS) ....... +

CALL SHIFT (300!0,CROSS)

CALL ERASE (CROSS) CALL DISPLAY (CROSS)

Fig. 3. Example of the use of VISTRAN

977
 The two main effects of this are that less storage is available than
with the Fortran compiler-loader system but the whole translation process
is about six times as fast.

A feature of Kwiktran, (which has been added since [20] was written),
is a facility to process relocatable binary documents. It turns out that
due to the general speeding up, this can be done about seven times as fast
as the corresponding Fortran source code. Since all the basic Vista soft-
ware must necessarily be written in Compass Assembly Language (from which
a relocatable binary version can be easily obtained), Kwiktran can now be
used for Vista programs.

These very significant speed increases prompted a complete rewriting

of the VISPLAY system as it was being developed. A full account of the
earlier versions is given in [20]. The user pays only a small price for
much faster on-line response - the maximum size of his program is reduced.
Some timing figures are given below.

Figure 4 (Visplay System)

978
5. THE VISPLAY SYSTEM

5.1 The Development of VISPLAY

VISPLAY is not a complete system for using Vista since it must be used
in conjunction with one of the packages PLOTV or VISTRAN, described earlier.
Since these are both self-contained systems, it is natural to ask what extra
facilities are provided by VISPLAY. The answer is, briefly, three things.
Firstly, a very convenient form of input using the DD 210 console, secondly,
built-in rescue and diagnostic facilities and thirdly, (and the most power-
ful), the ability to modify any part of the user's source program on-line
using the 210 console. In other words, a VISPLAY program can recompile
parts of itself.

Historically, the project started by the devising of a more convenient

method of input than was possible using the Vista function keys or the light
pen and 'light buttons' on the screen. Many users do not need to become
involved with the intricacies of light pen programming and they are content
to work within the confines of the PLOTV system. Also, in practice, it has
been found that it is very cumbersome to set decimal numbers using the
function keys (and it uses an extravagant amount of CPU time).

A DD 210 console is physically situated at the side of Vista. With the

VISPLAY system, information is typed on the 210 keyboard and this is used as
input for the Vista program. The two consoles, with input data displayed on
the 210 screen and corresponding pictorial output on the Vista screen, are
shown in Fig. 4. The method of using the two consoles has been described in
detail in the earlier paper [20J and we shall only briefly summarise it here.

The user 'logs in' to a special display program (see 2.2 above) which
displays data on the 210 screen, [19J. While the Vista program is 'broken
out', he alters this data by re-typing the necessary parts of it and inter-
rupting on the 210. This causes a corresponding drum document to be altered.
When the Vista program breaks in, this drum document is read by standard
Fortran READ and FORMAT statements. Since DAD only allows a document to be
used by one program at a time, in order to share the drum document in this
way, both the main Vista program and the display program must release the
document when they have finished reading or writing it and they must
Ire-define' it before they can use it again. This system has worked very
well in practice for it is easy to program and to use on-line.

Having firmly established the use of the DD 210 for altering data on-
line, it was natural to explore the possibility of changing the program as
well. Clearly, if this could be done then whole new realms of interactive
problem solving would be opened up.

The early attempts to do this using the original Fortran compiler-

loader system were also described in [20]. Suffice it to say that compared
with what was achieved later, they were not only very slow but extremely
difficult to use. By a lucky coincidence, at a critical time Kwiktran was
extended to deal with relocatable binary (see 4, above). This prompted the
work to be started afresh using a completely new approach and most of the
previous work abandoned, (although a great deal of experience had been
acquired). In the latest version, recovery and diagnostic facilities have
been built into the system so that it is usually possible for the user to
restart after making an error (see 5.4, below).

5.2 The Use of VISPLAY

The user must write his program mainly in Fortran and access the
VISPLAY package by means of subroutine calls. However, apart from the stor-
age restrictions imposed by Kwiktran (see 4, above), there are a few other
restrictions imposed by the VISPLAY system itself, but most of these are of
a minor nature. However, the most important difference between a VISPLAY
program and any other Vista program is that the program has to be organized
in a special way in terms of control statements and input documents. The
details are not relevant to this description but may be found in [21].
The user's complete program must be made up of a number of different
documents. These fall into three classes and there may be several members
of each class. Each document may contain any number of subroutines (one of
which must be a main program). The three classes will now be described.

i) R Documents. These consist of relocatable binary (RLB)

subroutines, two of which must be the VISPLAY package
itself and either PLOTV or VISTRAN.

ii) K Documents. These consist of source Fortran (SF) sub-

routines. When the program is recompiled, K documents
are compiled directly from the SF form by the Kwiktran
compiler.

iii) S Documents. These may be either SF or source Compass

(SC). The important thing about an S document is that
it is first translated into RLB form by the appropriate
compiler. This RLB document is called an X document and
appears to Kwiktran exactly like an R document.

The way in which the complete program is processed is illustrated in

Fig. 5. The various stages are controlled initially by DAD control state-
ments but after the program has been entered, by calls to the VISPLAY sub-
routines.

As mentioned earlier, Kwiktran can process RLB documents very rapidly.

It is for this reason that SF S documents are translated into the intermed-
iate X document form. We now distinguish a fast recompile (FR) and a
slow recompile (SR). An FR refers to the right-hand part of Fig. 5, while
an SR refers to the left. The philosophy behind this double classification
and some typical timing results are given in the next section.

900
 We shill now describe in detail) what happens when the program calls in
the VIsPLAy·recompiling mechanism. Other calls will be described in section
5.4 but some of the more straightforward ones will not be discussed in detail
Note that the Fortran calls, in a way, correspond to DAD control statements,
(see 2.3).

A statement of the form

CALL CONTROL (22H*KTN,I=10,X,L.KTNPART.)

allows the user to alter lun 10. The details are as follows:

i) Lun 10 is released,
ii) A message is displayed on the Vista screen,
MODIFY KTNPART AND INTERRUPT
iii) The program breaks out.
iv) The user modifies the document KTNPART using the DD 210 console.
v) He interrupts Vista to breakin.
vi) Lun 10 is defined to be the new KTNPART.
vii) The program resumes at the next statement.

Note that no recompiling is done here, it merely allows the user to

alter the K document.

The statement

CALL LOADRUN

calls in the Kwiktran compiler to do an FR using the latest versions of all

the K, R and X documents. As this is being done, an appropriate message is
displayed. If the new program compiles correctly, it is entered at the
beginning. (Any numerical values left over from the old program are lost
but these can be saved and retrieved via a drum document if necessary). If
the new program is faulty, the diagnostic and rescue facilities are called
in (see section 5.4).

The statement

CALL CONTROL(25H*FTN,I=30,X=40,L.FTNPART.)

calls in the Fortran cOlnpiler to do an SR and generate a new X document.

The detailed effect is similar to the previous CONTROL call described above
down to stage vi). Instead of resuming the user'sprogram there follows:

vii) The Fortran compiler is called with parameters as given in the

Hollerith string and an appropriate message is displayed on
the Vista screen. This generates a new X document, lun 40.

9Rl
viii) If the compilation is successful, control returns to the next
statement in the user's program. Again, see 5.4, if errors
are discovered. Lun 30 must be free of Fortran source code
errors before the program can continue.

< SR 7"< FR ?
-

0 SF

0 RLB

..
Kwiktran
CompHer
OBJECT

PROGRAM
S Doc. X Doc.
Fortran
SF RLB
Compiler

S Doc.
C0Il!pass EJDOC'
SC ~----~---------- RLB
Confpiler
.-

Fig. 5 The VISPLAY method of slow and fast recompiles.

5.3 The Response Time of VISPLAY

Since an SR, by definition, is comparatively time consuming, the user

should organise his program so that the S documents contain those sub-
routines which he is least likely to recompile on-line. As few subroutines
as possible should be in K documents, these being the ones that the user is
experimenting with.

For example, a test program which was used during the development of
VISPLAY displays a graph of a mathematical function on the Vista screen.

HH2
The scalefactors, range of the independent variable etc. were defined in a
data document; the function itself was defined as a Fortran function sub-
routine in a K document. (Later, it was realized that these two could be
combined into a single document and this made the program even more conven-
ient to use on-line). The rest of the program, about 12 subroutines, was
subaitted in the form of R or S documents. The complete program occupied
about 4500 words of core.

Various stages of the process were timed with a stopwatch and the
results recorded in the table, Fig. 6. As with all other interactive use
of the DAD system, the response varied considerably depending on the number
of on-line users active at the time and the amount of background 10 activity.
(There are also periods when DAD is busy 'housekeeping' and on-line users
find themselves ignored for possibly minutes on end. Timings obtained during
these periods have been ignored.) During the experiment, separate timings
~re made in a period when it was noticed that the system was less busy than
10 an earlier period. These periods are defined as 'not busy' and 'busy' in
the table. It should be noted that however busy the system is, there is
always an average delay of one second before DAD takes action on a breakin.
rbis is because it only tests for a breakin condition at the time of its
'two second interrupt'.
The pleasing thing about these figures is that the time for an FR
~er reasonable conditions is not much greater than the breakin time. Even
~ith a much longer program, provided the K documents are kept very short,
the time for an FR should not be very much longer since a substantial part
)f the time is taken up with fixed overheads anyway.

MACHINE NO. OF MAXIMUM MINIMUM AVERAGE

OPERATION
STATE TIMINGS TIME TIME TIME

Breakin busy 19 8.5 1.9 3.4

Breakin not busy 20 5.7 1.5 2.6

210 interrupt busy 14 7.5 1.2 2.5

210 interrupt not busy 10 1.6 1.0 1.2

FR " " 14 5.9 3.1 3.8

SR " " 6 14.9 12.7 13.7

Fig. 6 The results of a timing experiment,

(all times given in seconds).
 There is an important point worth mentioning here. When the user is
concentrating on his problem (as distinct from his program which helps him
to solve this), by altering parameters and trying out various forms of short
subroutines using an FR, delays of up to about 8 seconds are not intolerable
However, when he decides to make large-scale alterations to the main part of
the program, presumably at less frequent intervals, a delay of even a minute
can be tolerated without undue annoyance, since he is aware that the
computer is doing a lot for him. However, a long delay in response to a
seemingly trivial request is extremely frustrating. The design of VISPLAY
is based on this fundamental psychological aspect of human nature.

Figure 7 (Visplay System)

5.4 Rescue and Diagnostic Facilities in VISPLAY

One of the first statements in the users program must be of the form

CALL INITIATE (ISN,FTTS,pl,p2, •.. )

where ISN has been set to the address of a statement number (by a previous
ASSIGN ••• statement),

984
 FTTS is the name of a "first .!ime .!hrough ~ubroutine" and pl, p2, •••
are actual parameters of FTTS.

The effect of this call is threefold. The very first time that the
program is entered, a simulated call is made,

CALL FTTS (pI, p2, ... )

but whenever the program is recompiled and entered (i.e. after a LOADRUN
call), this call is bypassed. The purpose of this is mainly to allow the
user to display a preliminary message or 'test pattern' on the Vista screen.
However, it also provides a means whereby a large set of data need only be
read once as a serial access document and then converted to a random access
document. Any other preliminary processing of data can also be done at this
stage.

The second effect of the INITIATE call is to set up a rescue mechanism.

If ISN had been defined to be the address of statement number 999, for
example, then whenever the program encounters a 'non fata1 i run time error,
the program obeys a GO TO 999, in effect. Unfortunately, there are some
errors which the monitor always regards as 'fatal', (e.g •. exceeding the
time limit), and VISPLAY cannot rescue the user from these. In practice,
they are far less common than the 'non-fatal' errors.

Thirdly, a method is provided for the user to rescue the program

manually if it gets stuck in a loop, e.g. if an iterative process is not
converging. If he presses the Vista interrupt key while the program is
computing, a message appears on the screen and the program jumps to 999
as before.

Although it is easier to solve difficult problems on-line than it is

via a batch-processing system, it is also very much easier to make car~~8ss
errors. Therefore, it is absolutely essential, in a system like VISPLAY,
to provide such rescue features.

There is also a warning facility which is used in conjunction with the

manual interrupt.

CALL TIMELIM (20 ,SUB)

has the effect of interrupting the running program 20 seconds after every
subsequent breakin. It calls the user's subroutine SUB and then resumes
where it left off. SUB can be used to display a warning on the screen,
after which, the user may wish to manually interrupt as described above.
If the parameter SUB is omitted, a short subroutine in VISPLAY itself is
called instead. This causes a flashing warning message to appear but it
also erases any picture from the screen, hence the optional user's
subroutine.

985
 Whenever the program encounters a non-fatal error, including recompil-
ing errors, VISPLAY causes a whole Vista screenful of diagnostic information
to be displayed. This consists of a message followed by the last 36 'usefu~
lines written to the standard output unit, (lun 61) which is later output
on the line printer. An example is shown in Fig. 7. 'Non-useful' lines
include blank ones and standard page headings etc. produced by the Fortran
compiler. Thus the maximum amount of useful information is displayed. To
display the information from 1un 61, the following basic cycle takes place:

backspace a record,
[ copy it to the Vista buffer if useful,
backspace a record,
display the contents of the Vista buffer,
skip to the end of the document.

The Y coordinate of the first line read and displayed is set to the
bottom of the screen and this is then decreased for each successive line.
Thus although the lines of text are stored in reverse order in the Vista
buffer, they appear correct when displayed on the screen.

Finally, a word about recompiling errors. There are three types to

distinguish. Firstly, the Hollerith string in a CONTROL call may be
incorrect. Secondly, an SR may discover a fault in the new S document and
thirdly, an FR may find that the complete program has a fault in it. The
latter is usually due to a fault in a K document. All of these errors are
fairly straightforward to deal with and recover from.

However, the most awkward case is the one where there is faulty cross-
reference ('loading error') due to a wrong name in an S document which
cannot be detected by the Fortran compiler. Thus it is necessary to be able
to go back to an SR after the FR finds an error. This is done by the user
setting the Vista function keys to define the lun of the faulty S document.
Since, it is possible to set the keys wrongly, an extra check has to be
included and if necessary yet another error message displayed.

In the user's technical specification of Visp1ay [21], it requires

a two-page flowchart to describe the details of the LOADRUN call in all ca~,
but provided the user doesn't make a mistake, only a short path is traversed
through this.

5.5 The Implementation of VISPLAY

Since Vista jobs form only a very small proportion of the total number
of jobs run on the CSIRO 3600, (certainly very much less than 1%), any
system for using Vista must fit into the normal operating system. However,
because of their special requirements, Vista users were provided fairly
early in the development of DAD with the fundamental breakin-breakout
facility, and later, with the other two special facilities described in
3.2, above.

9~
 VISPLAY was developed completely within the framework of the existing
DAD system apart f~om two very minor modifications to the monitor. That
such a system was possible says much for the versatility of DAD, bearing in
mind that the Control Data 3600 is now a comparatively old-fashioned machine
and lacks many of the hardware features which are currently found on machines
designed for multiple-access use. Some of the DAD facilities which were
useful or vital will now be described.

i) The ability of a normal Assembly Language program to go into

'interrupt mode'. It is interesting that this has been described as "a
design error copied from SCOPE", [3], but this was found to be absolutely
vital in two places in VISPLAY and useful in a few others. The writing of
code in 'interrupt mode' is dangerous because an error here can cause the
whole system to crash. (" .. interrupt routines should only be written by
DCR [Division of Computing Research] staff" ,[8]).

ii) The use of the drums as a large store for serial access documents.
A1~hough the request, "'read the last line printed on the line-printer" is
meaningless, the request "read the last record of the standard output unit"
is not. This unit is just the same as any other until the job terminates,
when the printing actually starts. Other strange requests which have been
found to be necessary are, "write a card to the card reader", "delete cards
in the card reader" and "read cards backwards through the reader". The point
is, of course, that by the time 'cards' are read by the program, they have
long since passed through the reader and exist as card ima~ on the drum.
(By using the display consoles and the disc file, the card reader is often
bypassed altogether).

iii) The use of the drums for random-access transfers, though not
strictly necessary, has made the system far more efficient, especially for
Kwiktran recompiling and performing the breakin and breakout operations.

iv) The large number of special 'system macros' allows the sophistic-
ated programmer to take full advantage of DAD's basic versatility. In
particular should be mentioned the macro for calling in a compiler which
was provided for part of DAD itself ('Interjob'). This has been used, as
far as the author is aware, in only one other program besides VISPLAY.
Although its use is far from straightforward, the fact that it was available
at all has made the VISPLAY recompiling facilities very much more efficient.

v) The provision for running more than one program in a single job
was essential. One reason was that certain information about the structure
of the main program, (in connection with the names and numbers of the user's
K, R and S documents), had to be stored on a drum document before the main
program could start. This is set up by running a short preliminary program
in the same job. A 'switch' for controlling the calling of the user's FTTS
subroutine (see 5.4 above) is also stored in this document. It was vital .
that this document could be used for the duration of the whole job and not
just for the period of the preliminary program.

987
 vi) The facility for any user to write his own 'display program' h..
been mentioned above in 2.2. This was useful since the standard editing
programs CIDER [15] and FRED [10] were not entirely suitable for the on-line
input of parameters via the 210 console. A special display program, BEEk.
was written for this purpose [19].

6. ON-LINE MATHEMATICS

Consider the following Fortran arithmetic statements

Y = A*X**2 + B*X + C
Y = A*COS(X) + B*SIN(X)
Y = F(A,B,X**2,COS(2.*X» + X**N/LOG(X)
If A,B,C and N are constants and F( ••• ) is a given function then all
these statements may be regarded as expressing a functional relationsh~
between an independent variable X and a dependent variable Y.

Now 3600 Fortran [5] makes provision for a user to define other tyPes
of variables besides the five basic ones (real, integer, double, complex~d
logical). Having defined a new type, the user must provide subroutines
which define what is meant, for example, by

Accumulator = Accumulator * Variable.

One such system has been written at C.S.I.R.O. for dealing with
matrices, [9].

A system now being prepared defines an array of (real) numbers as a

new type of variable and thereby allows a statement such as

Y X**2

to be equivalent to

DO 1 I 1,N
1 Y (r) x(r)**2

The former looks much more familiar to a mathematician. Preliminary

subroutine calls have to be made to define the range of the independent
variable and the number of intervals.

To incorporate these into the VISPLAY system, subroutines are also

required to display one variable plotted against another on the Vista scree~
It is also planned to provide the basic mathematical functions, (SIN,EXP,
etc.) and subroutines to numerically differentiate and integrate these
variables.

988
 With a short VISPLAY K document containing a list of such mathematical
statements displayed on the DD 210 screen and all the other necessary sub-
routines in RLB form, the mathematician will have a powerful tool for
exploring problems involving functions of a single variable.

7. DISCUSSION AND CONCLUSIONS

Some of the more important lessons learned during the development of

VISPLAY are listed below. Some are the result of over two years general
observations on the use of Vista in practice. Most of them may equally well
apply in other en.ironments with graphical on-line devices.

i) The Vista user with a problem to solve must be able to

write his programs in a familiar high-level language.

ii) It is very often necessary to clearly distinguish the

writer of an interactive program and the on-line ~
of the program. Even though they are often the same
person, he thinks differently in the two situations.

iii) The programming effort required to provide good inter-

"active graphical facilities is quite considerable and
it will probably be measured in man-years rather than
man-months.

iv) A simpler system (e.g. PLOTV), which does not use all the
facilities of the ha=dware is very much worthwhile as it
will be adequate for many problems. Preferably, it should
form a subset of a more powerful system.

v) For many types of problem, a light pen is not essential.

Of far more use is an alphanumeric keyboard. The light
pen is all too often used because of its novelty, (and
the light pen facilities account for a considerable
proportion of the total programming effort).

vi) Any interactive system should aim to provide fairly rapid

response to seemingly trivial requests. A user can
tolerate a longer response to a request which, to him,
obviously requires much computing. But in all cases,
there should be some means of informing the user that
his request has at least been 'noted', even if it cannot be
immediately dealt with. A simple light is adequate for
this purpose.

vii) When the program finds an error or when it is carrying out

some lengthy process, a message on the screen to inform
the user is essential. Even the person who wrote the
program can become quite confused at times when confronted
with a blank screen, especially if response is erratic due
to the machine's other activities.
989
 viii) The operating system should make special provision fpr the
scheduling of Vista-type jobs. Even the 'deadline time'
option (though much better than nothing) has not prevented
much wasted human time. The ideal situation is always to
start a new Vista job if there is one waiting. A device
like Vista represents a large capital investment and the
system should aim to keep it busy for as much of the time
as possible.

ix) A person using a display device to solve a difficult

problem is entitled to be able to think in reasonable peace
and quiet. A man writing a difficult program normally does
it in the seclusion of his office and not in the hurly-burly
of the computer room.

x) In many ways, people are very conservative - even computer

users. If it is hoped to make the use of graphical display
equipment more popular, it should be physically situated
where it can be seen in use by as many potential users as
possible. Of course, the person using it should not have
crowds peering over his shoulder all the time but many users
do not mind being observed from a distance, (preferably
through glass) and are often willing to explain what they
are doing to people who are interested enough to enquire.

xi) Some simple method of obtaining 'hard copy' is extremely

useful. The best arrangement is probably to have a
'slave tube' with a camera or microfilm recorder permanently
attached. This slave tube should at all times have an exact
copy of the picture on the main screen. Unfortunately, if
user and camera have to share the same screen, they tend to
get in each others way. It should be possible to take photo-
graphs both manually and automatically under program control.
A 'software link' between the display screen and a
graph plotter is also very useful [25].

xii) When the earlier versions of VISPLAY were being written,

anything resembling 'systems programming' was deliberately
shunned. The resulting system was slow and cumbersome.
Later, the author 'took the plunge' and became quite
deeply involved in systems programming of a sort and the
VISPLAY system which resulted was far superior.

xiii) A good operating system like DAD, if sufficiently flexible,

will allow elaborate things to be done with it which could
not possibly have been envisaged initially.

xiv) The high-speed versatile drums of the DAD system provide a

storage medium which is intermediate in size and speed
between core and disc. Without them VISPLAY would have
been much slower even if it had been possible.

990
8. ACKNOWLEDGMENTS

Several of my former colleagues in the Division of Computing Research,

Canberra have been responsible for much of the work described in this paper.
The VISPLAY system would not have been possible without a few man-years of
total effort on their part.

Two of these in particular deserve special mention. Firstly Mr. R.H.

Hudson for much detailed assistance with the technicalities of Kwiktran and
secondly Mr. C.E. Wallington who not only wrote most of the VISTRAN system
but was the first person to attempt to use Vista with a large problem. He
also inspired the work on the camera facility and had many fruitful discuss-
ions with the author on the problems of using Vista efficiently.

Messrs. J.S. Armstrong, S.W. Cump~ton, H.G. Mackenzie, G.A.V. Bary

and Dr. J.F. O'Callaghan have all been willing to tryout various versions
of the software as they were being developed. Dr. J.P. Penny was respons-
ible for some vital modifications to the Vista hardware in the very early
stages. Mr. G.R. Knowles wrote the Vista macros, developed software for
efficient light pen tracking and drawing; he later constructed the electron-
ics to control the camera and with Mr. C.D. Gilbert was responsible for
attaching the camera to Vista with the cooperation of the local Control
Data engineers.

Dr. C. Abraham wrote an elaborate software package (VBS) for using

Vista which provided the necessary experience for the designing of VISTRAN
later. Mr. R.J. Hurle's PLOTV system allowed several people (including the
author) to obtain practical experience of using Vista for simple problems as
painlp.ssly as possible.

Dr. B.J. Austin not only provided the special DAD facilities described
in 3.2 but also started off the main part of the VISPLAY project with a
bright idea and gave much assistance with the earlier versions of VISPLAY.

Finally, a word of appreciation to those other members of the DAD

systems group who have been willing to answer numerous minor technical
questions over many months - Messrs. T.S. Holden, P.M. Ewens and especially
P.P. Hanlon.

REFERENCES

1. AUSTIN, B.J. and HOLDEN, T.S. (1966): "The Development of a Drum

and Display Monitor". Proc. of the Third Australian Computer
Conf., Canberra.

2. AUSTIN, B.J., HOLDEN, T.S. and HUDSON, R.H. (1967): "DAD, the
C.S.I.R.O. Operating System", Comm. A.C.M., Vol.IO, p.575.

3. AUSTIN, B.J. and HOLDEN, T.S. (1969): "Recent Developments of the

DAD System". Australian Compo J., Vol. I , p. 201.

991
 4. CONTROL DATA CORPORATION, Data Display Division (1967): CDC 250
Series Display Equipment Reference Manual.

5. CONTROL DATA CORPORATION (1967): 3400, 3600, 3800 Computer Systems

Fortran Reference Manual.

6. EWENS, P.M. (1968): "A Fortran I/O Package for On-line Consoles".
Technical Memorandum 68/4, C.S.I.R.O., Division of Land
Research, Canberra.

7. GRUENBERGER, F. (ed.) (1967): "Computer Graphics, Utility,

Production, Art". Academic Press, London. Thompson Book Co~,
Washington.

8. HOLDEN, T.S. (ed.) (1969): "DAD System Reference Manual". C.S.I.R.O.

Division of Computing Research, Canberra.

9. HUDSON, R.H. (1964): "MTRXPACK". Subroutine Library Specification,

C.S.I.R.O., Division of Computing Research, Canberra.

10. HUDSON, R.H. (1969): "FRED, Fast Reliable Editor". C.S. I.R.O.,
Division of Computing Research, Canberra.

11. HUDSON, R.H. (1969): "KWIKTRAN, a Version of the Control Data 3600
Fortran System Modified for Fast Translation and Rapid Loading".
Manual Supplement No. 33, C.S.I.R.O., Division of Computing
Research, Canberra.

12. HURLE, R.J. (1968): "PLOTV, Plot and Text for the Vista Display".
Subroutine Library Specification, C.S.I.R.O., Division of
Computing Research, Canberra.

13. I.B.M. (1969): Systems Journal, Vol. 7, Nos. 3 and 4.

14. KARPLUS, W.J. (ed.) (1967): "On-line Computing, Time-Shared Man-

Computer Systems". McGraw Hill, New York.

15. KERR, R .H. and KAROLY, G. (1966): "The Utilization of Keyboard

Display Consoles in a Conventional Operating Environment". Proc.
of the Third Australian Computer Conf., Canberra.

16. KLERER, M. and REINFELDS, J. (1968): "Interactive Systems for

Experimental Applied Mathematics". Academic Press, New York and
London.

17. ORR, W.D. (1968): "Conversational Computers". John Wiley & Sons,
Inc., New York, London, Sydney.

18. SASS, M.R. and WILKINSON, W.D. (eds.) (1965): "Computer Augmentation
of Human Reasoning". Spartan Books Inc., Washington. Macmillan
and Co. Ltd., London.

992
19. SHEARING, G. (1968): "BEER, Brief Easy Editing Routine". Display
Program Library Specification. C.S.I.R.O., Division of Computing
Research, Canberra.

20. SHEARING, G. (1969): "VISPLAY, an On-line Problem Solving System

Using Fortran and Two Display Devices." Proc. of the Fourth
Australian Computer Conf., Adelaide.

21. SHEARING, G. (1970): "The VISPLAY System for Using Vista".

Technical Note. C.S.I.R.O., Division of Computing Research,
Canberra.

22. SIDERS, R.A. (ed.) (1966)": "Computer Graphics, a Revolution in

Design". American Management Association, New York.

23. WALLINGTON, C.E. (1968): "Display Systems in Numerical Meteorological

Experiments." Australian Compo J. Vo1.1, p.158.

24. WALLINGTON, C.E. (1969): "PHOTO - A Camera Facility". Addendum to

Technical Note No. 30, C.S.I.R.O., Division of Computing Research,
Canberra.

25. WALLINGTON, C.E. (1969): "VISPLOT - A Subroutine for Plotting

VISTRAN Pictures on the Calcomp Plotter". Technical Note No. 33,
C.S.I.R.O., Division of Computing Research, Canberra.

26. WALLINGTON, C.E. and KNOWLES, G.R. (1969): "VISTRAN - A Subroutine

Package for General Purpose Use of the Vista Display". Technical
Note No. 30, C.S.I.R.O., Division of Computing Research, Canberra.

993
 SOFTWARE FOR SATELLITE GRAPHICS

A. R. Rundle

Marconi-Elliott Computer Systems Ltd., Elstree Way,

Boreham Wood, Herts. England.

Abstract

This paper is in three parts, the first comments on the size of

satellite graphic configurations, the second on the software problems of
effecting a link between two computers, while the last describes a
software system designed for use with satellite displays. This system
is currently being implemented by Marconi-Elliott Computer Systems Ltd. ,
under A. C. T. p. Contract No. K. 78Bl/306.

Configurations

There are two main reasons for putting a graphical display onto a
satellite computer linked to a larger, multi-access machine, instead of connecting
it directly. The first of these is to spread the computing load in an efficient manner
on the basis that, for trivial operations such as pent racking , a word of core in a
low cost satellite is cheaper than a word of core in a large computer with many
expensive pe riphe rals. Secondly, if the display is to be situated remotely from the
main computer, some local computing power may be necessary to provide response
to users actions within an acceptable time limit.

The nature of the link connecting the machines is dependent on the distance
between them. If less than 1,000 ft. (approx.), a parallel interface such as a
peripheral interface or the British Standard Interface may be considered, with a
high transfe r rate of the hundreds of kilobaud. Above this distance it is normal to
use modems, either over private lines or via the public telephone network. The
G. P. O. wideband facilities are usually too expensive to be worthwhile.

995
 The ideal size for each computer theoretically depends on the application.
For satellites over a modem link, there has to be sufficient storage to hold all
routines giving immediate response, and the data that they need to operate on. The
size of the big machine and the power of the central processor is determined by the
calculations involved and the response required from the main computer. This in
turn depends on the characteristics of the operating system and the number of
displays to be serviced within the maximum allowable response time.

Where a very fast link is used it is usual to employ the smallest satellite
configuration possible to perform the trivial but repetitive tasks, such as pent racking ,
reading keyboards, joysticks, etc. It is worth noting, however, that there is a large
step in the price of multi-access systems when ohangtngfrom a situation where
"active" programs are held on disc, to one where they are resident in core. If this
change has to be made in order to provide a fast enough response time, the use of a
larger satellite may ease this restriction and reduce the total cost of the system.

We have noticed, however, that these criteria are not always the dominant
ones when choosing a configurati on. Given an adequate response time for the big
machine, the factors which affect the choice most seem to be,

a) the cost of using the big machine,

b) its availability and reliability,
c) whether it is heavily loaded or not,

d) the desirability of having spare computing power remote from

the main machine to perform other tasks.
e) In addition,
it is possible that the accounting and costing method employed
may influence the configuration.

a) Cost
If the big machine is expensive to use and the line charges are high, it
soon becomes worthwhile to add extra core, or possibly backing storage,
to the satellite, using the big machine only when absolutely necessary.
Indeed it is possible to imagine situations whe re the cost of using a
large expensive comouter a long way away is sufficient to justify a
local stand alone graphics installation.

b) Availability
The main machine may not be available for sufficient periods of time,
for example, it may not be possible to use it for evening shift working.
This could necessitate the use of a large satellite, probably with some

996
 form of backing storage, so that data can be created ove rnight and
sent, next day, to the main computer

In the worst case, such restri'ions could rule out the use of
satellite displays altogether.

c) Loading
A factor that then has to be considered is the loading on the big machine.
If it is heavily loaded, it is usually sensible for the Eatellite to do more
work to avoid having to upgrade the main system. On the other hand, if
it is very lightly loaded then it is not worthwhile buying a large satellite
to do work that could be done, albiet inefficiently, by the big machine.
I might add that this latter case does not occur often.

d) Other Work
On occasions there are other reasons for having local computer power
especially if the satellite has to perform other work in addition to
graphics, such as data logging, or providing a remote batch service.

e) Finance
Finally, it is possible that by adding the smallest satellite possible to
an existing installation, one can minimise capital expenditure. On the
other hand, if this requires a large core resident program in the
multi -access compute r, this will downgrade the total syst em and
increase the cost per job.

It is, therefore, impossible to be dogmatic about the size of satellite one

should employ. One comforting fact is that one of the limitations we are working to
is the response time that human beings will accept from t he system. Humans are
highly adaptable and it seems likely that whateve r configu ration is chosen, within
sensible limits, compromises can be made to produce an acceptable system.

Linking the Machines

The most vital piece of software in any satellite graphics system is the
communications package, since it is this package which organises the transfer of
all data between the two machines. Part of the package will therefore, be
resident in each machine.

The job of actually transferring data is quite straightforward, but it is

complicated by the variety of procedures and conventions adopted. The current
situation is rather like that prevalent with paper tape, since there are a number of
codes that can be used. The variety does not stop there; then are different
methods of error checking, e. g. parity or cyclic redundancy c!lecking, and

997
different interpretations of the "handshake" procedure that has to be adopted to
ensure that no data is transferred until the device at the other end of the line is
ready to receive it, although the actual operations involved are fairly standard.

A further major difficulty is that although it is fairly easy to implement

suitable software in the satellite, the software in the big machine may involve
alterations to the executive and the operating system. This is invariably a
lengthy and costly ope ration.

An approach we have found successful is to examine the product range

of whatever big machine we wish to link to, in order to find a peripheral that
operates remotely via a suitable modem. Most manufacturers, for example, supply
card reader/lineprinter terminals which fit this bill. By Simulating the operation
of the chosen peripheral we fool the operating system into accepting the satellite
as if it were a standard device. This means, for example, that by simulating the
IBM2780 terminal we can transfer data from a satellite 905 to a 360 without
altering the operating system at all.

Standard software, such as Remote Job Entry, provides adequate

facilities for initiating jobs and transferring data between machines.

Although the format of the data transferred is rigidly defined, this

imposes very few restrictions on the software interface in the satellite.

It is perhaps worth mentioning some of the desirable features of such a

communication package.

a) Each machine should be able to read or write an

arbitrary amount of data from anywhere in one machine
to anywhere in the other.

b) There should be a mechanism to indicate to the user

program when a transfer is complete. In this way, use can
be made of the time taken to transfer data.

c) The user programs in each machine should be able to

effectively interrupt each other. Without this facility one
machine might wait in a loop while the other one was busy.

d) Messages from the satellite to the big machine should be

stacked in a buffer to make fullest use of the big machine when
a time slice becomes available. Such a system allows the
user to work continuously on the satellite even though the

998
 big machine program may only be running intermittently.
Ideally, the re should be the option to display sho rt messages
on the display screen to keep the operator informed about
the state of the link and the information waiting to be processed.

e) It should be useable, both in assembly code and the chosen

high level language. The simplest method, for the user, is
to arrange the standard input/output routines (e. g. Fortran
READ and WRITE statements) to be routed to the link.

f) It should be able to filte r out system messages from the big

machine to the satellite, directing them as necessary.

Graphics Software

The software packages required for a satellite graphical display fall

into four main categories. Firstly, there should be a package to build data
structures in a high level language such as Fortran or PL!. This in itself is a
major problem area since it is very dHficult to build a system that is both
sufficiently comprehensive for general use and yet makes reasonable efficient use
of the storage available. Languages such as L6(1], LEAP[2], ASP[3], LISP[4],
etc. are, however, extremely useful for particular classes of problems. At the
moment though, we do not have a univerally accepted data structure language n
the same way that we have univerally accepted high level programming languages"

Secondly, we need a mechanism to enable the big machine LISeI' to

generate pictures on the graphical display attached to the satellite. We have to
cater not only for the needs of those using the display on-line, but also for the
users who may wish to generate pictures, perhaps on batch runs overnight, for
subsequent examination at a more convenient time.

Thirdly, it is becoming apparent that for complex applications, providing

the right response to user aetions is becoming a difficult problem in itself. If one
thinks of actions such as pointing to an object with the lightpen, or pressing a
button, as statements in a graphical language then the user has, in effect, to write
a compiler for this language.

While procedural extensions to Fortran are perfectly adequate for the

simpler tasks, there is a real need for a much higher level software interface,
Newman's Reaction Handler [5] is an example of the type of system required,

Finally, certain application packages should be provided. While it is

possible to argue at length over this point, there are certain operations that nearly
all users wish to carry out. The two most obvious are text editing and the
displaying of graphs. While few C. A. D. installations would justify their existence
for these jobs alone, they are an immense help in getting such systems off the
ground, since many programs can make use of these packages wit h comparatively
little alteration.

Data Structure Package

The approach we are adopting is to provide basic systems routines with

which the application programmer can easily build his own special purpose,
efficient routines. The most important routines are those that deal with allocation
of free storage in which the user can build his data structure. We have to cater
for a wide variety of satellite configurations and this creates problems when
performing operations on large data structures, in particular:-

a) the large backing store which will hold all data relevant
to the problem (the data base) will be attached to the main
computer. The system therefore, has to cater for
transfers of data from this backing store to the satellite.

b) the satellite will generally be too small to hold all the data
it reqUired, and hence some method of fragmenting the data
structure has to be provided.

c) the machines may wish to work on different parts of the

data structure independently, so it should be possible to
hold different fragments (or pages) in the two machines,
without the necessity for duplication.

We are dividing our free storage into pages, and each reference pointer
will, therefore, contain a page number and an address relative to the start of that

OBJECT TYPE

POINTER TO NEXT IN RING

LENGTH OF SIDE

ORIGIN X CO-ORDINATE

ORIGIN Y CO-ORDINATE

Figure 1 - Format of Record Describing a Square

1000
page. Page tables will be kept in each machine to indicate the whe reabouts of
each page. When a page is transferred from one place to another, only the page
tables need be updated, not the pointers, so that each page is relocatable.

The algorithm we use for storage allocation within the pages basically
forms free store lists, merging adjacent areas of free store where possible, but
does not move data records to perform a proper garbage collection operation.

Although, under certain circumstances, this is less efficient in its use

of store than one might ideally hope for, it does greatly simplify the manipulation
of pOinters since the user can store pointers in his data without the system having
to take special action to update them. This simplifies programming and reduces
the system overhead for dealing with pointers. This seems to be yet another case
of "swings and roundabouts" for, although we may not always be able to use all
the free store available because of fragmentation, we can make more efficient use
of the store that we can access.

In addition to the basic functions of allocating and returning areas of

store, and checking pointers to bring down pages from backing store where
necessary, we hope to be able to provide a number of other sub-routines to perform
such operations as finding the next or previous records in a ring, finding the start
and end of a list etc.

With such a system we hope it will be possible for use rs to implement

either one of the existing data structure languages, or their own tailor made
system very quickly.

An example of the type of sub-routine that the user would have to write
is shown in figure (2~ IGET (L) is an intege r function which takes the value of a
pointer to a record of free store of length L. (Its counterpart IPUT(R, L) returns
a record whose reference is R, of length L, to free store.) IFIND(R) is an
integer function which takes the reference pointer R, brings the appropriate page
into core if not already there, and becomes the page relative pointer (i. e. the
reference R minus the page number). SETUP will have initialised the system, and
have allocated array A as the area to be used for core resident page. ILAST(I) will
find the last record in the ring starting at I.

The format of the record to be created is in figure 1.

GraphiCS for the Big Machine

A large satellite can be used like a stand-alone machine except for the
fact that occasional data transfers occur when lengthy computation or file searching
is required. For smaller satellites, however, stand-alone graphics software is

1001
not enough; the big machine user will want to generate pictures, but it is often
useful for the satellite to perform operations such as zooming or edge clipping
without recorse to the big machine, for example, to change the view of an object.

SUBROUTINE SQUARE (LENGTH IX, 1Y)

COMMON IRING, A

J = IGET(5)
C CREATE A RECORD FIVE WORDS LONG, POINTER IN J

I = IFIND(J)
C COLLATE OUT PAGE No.

A(I) = 100
C OBJECT TYPE

A(I+1) = IRING
C IRING IS A POINTER TO THE START OF THE RING

A(I+2) = LENGTH
A(I+3) == IX
A(I+4) +IY

I + IFIND(IRING)
C FIND LAST RECORD IN RING

I == IFIND(I)
A(I+l) == J

C ADD NEW RECORD ON TO END OF RING

RETURN
END

figure 2. Subroutine to create a data record.

Since this normally means the use of a pseudo display file, we can define
many geometriC shapes as functions of the system. We are no longer restricted
to lines, arcs, characters, etc. This in turn means that we can present the user
with a much higher level software interface, for example, he may merely tell the
system to draw a transistor or a surface patch without having to generate these
line by line. Similarly, it is possible for the satellite to inform the big machine of
changes to the picture by communicating in terms of alterations to specific objects.

1002
 • I PSEUDO DISPLAY ... ....
M
o
o,....,
, ,
ALGORITHMS
FILE
i
I
,
DATA ~ COMMUNICATIONS 928
LINK PACKAGE DIS MAN I. I DISPLAY FILE DISPLAY
INTERACTION
MODULE
......-
~
•
• -- lIGHTPEH
1
~- I.
I ~ .. I: DECISION
TABLES
I
FIG.3. SCHEMATIC DIAGRAM OF SOFTWARE IN SATELLITE 905.
 Ideally, the display should ope rate on the data structure directly,
but any major alteration is likely to involve examining the whole of the data
structure, which could take a considerable time, especially if the link between the
machines is slow. The satellite will, therefore, probably hold its own minimal
subset of the data structure containing only the information which requires
graphical representation. We are, therefore, providing a mechanism to enable
the user to specify new object types. Each object type will require an algorithm
in the satellite to process the pseudo display file to generate a suitable picture,
since, for complex objects this is likely to be more efficient than holding complete
graphical information in the pseudo display file. It will be possible either to
generate the file completely in the big machine for subsequent transmission to the
satellite, or me rely to communicate changes so that the file can be updated in the
satellite.

When using this system, each installation will have to define the classes
of object that it is desired to operate on, for example, one user may wish to
operate on pipes, valves and pressure vessels, while another may wish to operate
on transistors, resistors and capacitors. Once this has been done, the user has
his own application orientated graphics package and to use it merely has to note
changes to the graphics data structure and update his problem data structure
accordingly.

Graphical Input Language Computer (G. 1. L. C. )

Although we have now made life much easier for the application
programmer writ ing for the big machine, we have in some respects merely
transfe rred the problems to the satellite, since the satellite has to conve rt the
pseudo display file into real display file, and also has to modify the picture and
the display file in response to the operator's actions.

The sub-routines that perform these operations are termed the

"interaction module" in figure (2). This module interprets the viewing parameters
calling algorithms to regenerate the picture, and informs the main machine of
significant changes as necessary.

The algorithms required are those previously referred to which examine

objects in the pseudo display file and call the basic display manipulation
sub-routines (DISMAN[6]) to generate the appropriate picture.

We are producing a system to generate an interaction module. Given

that the algorithms have already been defined, the user will prepare what is basicall
a set of decision tables which, when compiled, will call the appropriate routines
into operation in response to actions by the operator.

1004
 Again, a certain amount of initial work has to be done to define the
routines required for each installation, but we can provide a number of the more
basic routines. We believe that this approach will significantly reduce the amount
of work necessary in this area.

Although this system is particularly suitable for satellite graphics, the

communications routines are basically transparent, so this software can also be
implemented on a stand-alone graphics configuration.

We therefore have a method of providing a very high level, hardware

independant, software graphics interface.

User Packages

The functions of a graph package or a text editing program are

self-evident, but both packages must be very easy to use in order to be successful.

In addition, the text editing program should have a simple interface

for character input and output so that it can be readily added onto existing programs
or modified to edit disc files, etc.

ACKNOWLEDGEMENTS-

Thanks are due to A. C. T. P. for permission to publish information

relating to contract no. K. 78B1/306.

References

1. Knowlton K. C. A Programmers' Description of L6.

~ Comm. ACM No.8 August, 1966.

2. Rorner P. D. and An Associative Processing System for

Feldman J. A. Conventional Digital Computers.
Tech. Note 1967-19, MIT Lincoln
Laboratory, Lexington, Mass. April 1967.

3. GmyJ.C. and ASP - An Associative Structure Package

Lang C.A. Comm. ACM 11 No.8 August, 1968.

4. McCarthy J et al LISP l' 5 Programmers' Manual

MIT Press, Cambridge, Mass. 1962.

1005
5. Newman W. M. A System for Interactive Graphical
Programming Proc.1968 SJCC. P. 47.
Thompson Books (April, 1968).

6. Rundle A. R. DISMAN 900 - A Package of SIR Subroutines

for the 928 Graphical Display.
Marconi-Elliott Computer Systems Ltd. ,
Manual No. 566/BJ4/C.

1006
 OPTIMUM SYSTEMS DESIGN OF
COMPUTER DRIVEN GRAPHICS
TERMINALS

1. D. Foley

Information Control Systems, Inc., 109 E. Madison,

Ann Arbor, Michigan, U.S.A.

1. Introductio~

The subject of the study reported here is the systems

design of highly-interactive graphical display terminals for
time-shared computer systems. A more detailed report of the
work is available in a reference (6). The overall goal of the
study is to develop insight into how the choice of subsystems
for a display system can affect the system's performance. and to
develop methods of finding the combination of subsystems which
will be optimum for any well defined display application, where
optimum is defined as minimizing a display system's response
time subject to a cost constraint.

Viewed in a slightly different way. display system design

can be thought of as presenting a problem in resource
allocation. The resource is a fixed number of dollars, which
are allocated to the purchase of display subsystems in a manner
which minimizes the total system's response time.

Response time is important in any highly-interactive remote

access computer system, and is even more important when
considering the graphics terminals which often form part of such
systems, because fully capitalizing on the potential interacti~n
rates achievable with a graphics terminal demands good response
time. Dollars are significant because display system hardware
is still quite expensive, and improper allocation of the dollars
can produce a display system whose response time is orders of
magnitude worse than what can be aChieved with the optimum
allocation.

Figure 1 shows the type of system with which we will

concern ourselves. The four subsystems of particular interest
are the data link, the remote computer-display control, the

1007
 a::
w
zl-
:::>
<:to...
22
o
()

0::
WW
1-1-
0:::>
~o...
w~
0::0
()

~
~ffi
-1-1
0...6
(/)0::
o~
o
'-----.()
---

o
~------~---------+------ ----~

Figure 1. General display system.

1008
display terminal's core storage, and the display terminal's bulk
storage. In specific cases the terminal's bulk store may not
exist, or the data link may simply be a cable between adjoining
rooms. In most cases, at least the remote computer-display
control and its core storage will be part of the display system,
with the core serving both as a refresh buffer for the display,
and as program and data storage for the remote computer. This
computer (usually small and inexpensive) is used to take the
burden of much of the display processing from the main
computer. The exact nature of the relationships among the
display control, remote computer, and core storage is discussed
in a reference (11). The main computer is included in the
system to provide inexpensive bulk storage and, above all,
because of the extensive computations demanded by most display
applications, such as network analysis (3, 4, 14, 18), drafting
and numerical control (13), integrated circuit layout (8, 15),
and many others.
When designing a display system, there are large numbers of
hardware-software and hardware-hardware tradeoffs or
alternatives which can be exploited. By hardware-hardware
tradeoffs we mean the possibility of increasing the capability
of one display subsystem in exchange for decrease capability of
another display sybsystem, while keeping response time constant.
The purpose of juggling hardware in this manner is of course to
minimize cost. As a specific example, if we wish to maintain a
specified response time at the display console and wish to
decrease the data link speed, it is necessary to increase the
"power" of the remote computer-display control, or the amount of
core storage, or the amount of remote bulk storage, in order to
compensate for the longer data transmission time. The converse
also applies. Increasing remote computer power cuts computation
time, while increasing core storage decreases bulk storage
accesses, either at the terminal or at the main computer, and
increasing remote bulk storage cuts down on data link usage.
In some cases, however, it may not be possible to
completely compensate for a lower transmission rate. This will
depend both on the amount of decrease in transmission rate and
on the relative usage of the four system components.
Specifically, a small decrease in transmission rate for an
infrequently used data link is far easier to accomodate than a
large decrease in a heavily used link.
Similar statements can be made with respect to each of the
other system resources: a decrease in anyone can be
compensated for by an increase in one or more of the other
resources, within certain limits.
With hardware-software tradeoffs, we are referring only to
the remote computer-display control. Certain display-oriented

1009
functions can be implemented either by software with the remotE
computer or by hardware in the display control. Severa:
possiblities exist here.
When a position indicating
device, such as a RAND table1
(2) is used at the display console, it is often necessary t<
correlate a position with an entity currently being displayed OJ
the CRT. This can be done with software, or with displa:
control hardware which continually compares the current CRT beal
position with the indicating device's position (9). The firs1
method can consume much remote computer time, but cost:
nothing: the second method takes neither computer time no]
display time, but does take money.
If, on the other hand, a light pen-type entity indicatinl
device is employed, its position will frequently need to bl
known: this is the familiar light pen tracking problem. Onci
again, the work can be done with either special purpose hardwarl
built into the display control, or with a program running on thl
remote computer. A current hardware implementation takes abou'
10% of the display control's time. decreasing by a like amoun'
the quantity of flicker free material which can be displaye l

(17). Software implementations of various pen trackinl

algorithms do not affect the display, but do require remot,
computer time to execute.
One of the most demanding display functions is the rotatiol
of a three dimensional object, which requires a matri:
multiplication operation of six scalar multiplications ani
four scalar additions for each point and line of the display
Implemented in software, this can be very slow, and can limi1
the smoothness and rate of dynamic rotation. A first ste]
toward improvement is adding hardware multiplication to thl
remote computer. A second step is implementation, in the displa:
control. of the actual matrix multiplication. There are severa:
current manifestations of this second possibility. Two USI
digital techniques (16, 17). The second uses analog multiplier:
and analog addition (7).
Hardware facilities for display subroutining allow onE
display list to be used many times in the course of drawing
p-icture. and therefore avoids needless duplication in core 0;
display instructions. This is all a direct parallel t(
subroutining for computer programs.
Similar display control hardware-remote computer softwarE
tradeoffs exist with respect to problems of dashed lines~
blinking lines. transfer of control. recursive sUbroutining~
displaying lines, and displaying alphanumerics.
With this multitude of tradeoffs between the variou:

1010
display system components, an important question arises: for a
given display system application, and a given dollar cost, what
combination of display subsystems will produce the best possible
service for display users? The best hardware will produce the
fastest, or minimum, average response time experienced by the
display system's users.

What is needed for use by display system designers is a

rigorous objective method for evaluating the effects upon system
cost and response time of the various tradeoffs discussed
qualitatively in this section. Be now the qualitative
tradeoffs, which are in fact rather obvious, are well
understood. The tradeoffs need to be quantified for the sake of
intelli~ent systems design, because the consequences of using
poor systems design are the overloading of some sUbsystems.
under utilization of other subsystems, and decreased
productivity for the system's user. The work reported here has
been conducted with this goal always foremost.

2. Display System Model

In order that display systems be studied in a rigorous

manner, particularly to find optimum display systems. a
mathematical model or abstraction of how a display system
operates is needed. To be useful. the model must reflect the
varying capabilities of the display subsystems; the remote
computer-display control. the data link, and the remote
terminal's core and bulk storage. The model must also be
sensitive to the varying computational. storage. and data
transmission requirements of the many different applications
which might be implemented with a display system. Furthermore,
any explicit or implicit assumptions imbedded in the model must
be tenable. Finally, the model. when appropriately analyzed,
must yield some measure of system performance; specifically. the
system's response time will be the desired performance measure.

A model which satisfies these requirements has been

developed. It posesses the properties that as the capabilities
of the display subsystems increase. the system's response time
decreases and its cost increases. These two complementary
properties will greatly facilitate the finding of optimum
display systems. The model also includes a mechanism for
dividing display processing between the main and terminal
computers.
Figure 1 showed a typical display system with R display
consoles being serviced by a single remote computer. which in
turn is supported via a data link by a large time-shared
computing system. The model. shown in Figure 2. represents an
abstraction of the flows of information and control which are

1011
likely to occur in the total system. Each box in the mode
represents a server and when R is greater than 1. a possib]
queue of tasks waiting to use the server. As can be seer
servers are the remote computer. its bulk storage, the dat
link. the main computer. and its bulk storage. It is often tt
case that several servers in the model refer to the sarr
physical device. performing different functions.

The best way to understand the model's operation is t

follow a typical man-machine interaction as it passes throu~
the system. An interaction is begun when a user at one of the
display consoles requests service by introducing informatic
into the system. The user does this by typing on an inp~
keyboard. depressing a function button. causing the light pe
(or a similar device) to sense a point on the display. or son
like action. The resulting service required by the user'
action may be so trivial as adding an additional a1phanumerj
character to the information already in the display. or E
difficult as analyzing a complex electrical network.

Having received the input information. the remot

computer's interrupt handling software is able to determine, j
a time interval usually so short that the process is n(
modeled. whether the requested service will be performed by tl
remote computer or the main computer. The main computer will t
used if it has been programmed to do what is needed; if not. tr
remote computer will have been programmed to perform the desirE
service.

If the main computer is to be used. a task is entered j

the queue of tasks waiting to use server 6 (when R-1. queuE
never exist, so the task always begins service immediately;
which is the remote computer in a pre-processing mode (
operation. The pre-processing involves preparing a message f<
transmission to the main computer, giving it all the informati(
needed to perform its task. The work involved may be as simp:
as requesting transmission of a previously-prepared message, (
as complicated as creating a compact description of a disp1,
from its display file. Having finished pre-processing.
message is queued for use of the data link, server 7. and:
eventually sent to the main computer. after which the job queuE
for service by the main computer. server 8.

One of two situation will usually prevail at the ma:

computer. Either display terminal tasks are given priority OVE
other tasks, such as those from teletype terminals. or they al
not. In either case, the model's queue 8 contains only disp1c
tasks; however, in the priority case. the main computer'
service time will be less (possibly substantially less) the
when there are no priorities. That is, the fact that not
display tasks may be competing with display tasks for use of tl

1012
CPU will be treated implicitly in the CPU's service rate, rather
than explicitly by having non-display tasks in queue 8. No
matter what the priority structure (or lack of it) may be.
intervals of main computer service ensue, interspersed with bulk
storage accesses to programs and/or data.
Whenever processing ends, a message containing results is
queued for transmission to the remote computer via server 10.
Following transmission the task queues to use the remote
computer, server II, for post-processing. During post-
processing, results received from the main computer are expanded
into a display file, after which the user sees his results on
the display console, and is able to generate a new service
request.
Several general observations concerning the model are
appropriate. A very clear distinction is made between the two
roles played by the main computer. The first role, that of a
processor, is modeled by servers 8 and 9; the second role, that
of storage for data programs for the remote computer. by server
4.
Because several servers are in fact the same physical
device. a system of priorities is included in the model. They
are indicated in Figure 2. For example. if tasks are waiting to
use the remote computer in both its pre- and post-processing
roles, post-processing is given priority. This is just an
extension of the read before write philosophy used in scheduling
the paging drum of current time-shared computer systems (10,
19). The goal of course is to keep response time down. In the
case at hand reads are associated with post-processing and
writes with pre-processine;, since it is the "reads" which bring
a task nearer to completion with more certainty than a "write".
Indeed, in this example, post-processing completes a task.
Beyond this, however, remote processing (server 1) 1s given
top priority for use of the remote computer. This helps the
display terminal users maintain a high interaction rate while
doing the ordinary work supported by the remote computer, for
which the user expects fast responses. Interactions involving
the main computer, for which users are usually prepared to wait
a bit longer, are accordingly given lower priority. Priorities
for use of the data link are assigned on the same basis, that
is, read before write, with preference Given to the remote
computer.
Finally, it is important to remember that each of the R
users can have only one task in the system at any time. This
means that the maximum queue length at any server is R-I (one
will be in service), and that no more than R tasks can

101:3
 MAIN COMPUTER
9 BULK STORAGE 4

,
a
n. j
MAIN
8 COMPUTER
•
a
n.
0

PRIOR ITY3 PRIORITY 4 PRIORITY I PRIORITY 2

DATA
10 7 LINK 5 3

PRIOR IT Y2 PRIORITY 3
REMOTE REMOTE
COMPUTER:
POST-
PROCESSING
II 6 COMPUTER:
PRE-
PROCESSING
• 0
cr
Q.
I

~RE MOTE
~d CO MPUTER
f-+ 2 f.+- BU LK
STORAGE

•
u
~ cr
0
Q.

j REMOTE
'-- I ~ CO MPUTER:
PRIORITY I ,IrRE MOTE
PROCESSING
u
I-PM cr
PM 0
Q.

-
I
". :11SERVICE
USER .
WAIT FOR NEXT REQUESTS WAIT FOR NEXT
REQUEST REQUEST

Figure 2. Display system model.

1014
simultaneously be in the system.

The parameters of the model (that is, the branching

probabilities and service times) are functions of both the
hardware's capabilities and the use made of the hardware by the
display system's application. We will not concern ourselves here
with the exact functional relationships between these
quantities, but will point out what must be known about the
hardware and the application in order to use the model. Note
that we will be discussing averages of quantities which often
posess a probability distribution.

With respect to the hardware, it is necessary to know the

time taken to retrieve files from the main computer's and remote
computer's disk storage units, the data link transmission rate.
the amount of core and disk storage at the remote computer, and
the instruction execution rate of the remote computer-display
control and the main computer.

There are many application characteristics which need to be

known, the first of which is the user's think time between
presentation of results to him and initiation of a new
interaction. For each type of interaction (or service request)
which can occur, we define the four-tuple (PCi), NCi), AMCi),
ARCi)). Here PCi) is the probability that the type i
interaction is requested, N(i) is indicative of the processing
requirements for the interaction, and AMCi) and ARCi) are the
number of accesses to bulk storage which will be made if the
processing is done at the main or remote computers,
respectively.

It is on the basis of this four-tuple of information that

each service request is assigned to either the main or remote
computer. A recent article by Williams (21) contains a general
discussion of a graphics system at SDC. It establishes just
three types of interactions, which are then assigned to either
the main or remdte computer depending on the interaction's
computational requirements. In our case we will assign an
interaction type to whichever computer can process it faster.
Also needed is a measure of the amount of computation
performed by the remote computer when in the pre- or post-
processing modes of operation. and the length of messages sent
over the data link between the main and remote computers.
Finally, we must know the relative and absolute usage of the
data and program files associated with the display application.
Of specific interest here are all files associated by the remote
computer, regardless of whether they are stored in the main or
remote computer's bulk storage, or in the remote computer's core
storage.

1015
 At this point it must be very evident that the forgoing
paramater1zed application characterization may, in fact, be very
difficult to estimate. This is true. However, what is equally
true 1s that the better an application and the programming and
computational requirements of that application are understood,
the easier will the estimating process be, the better will the
parameter estimates be, and the better will the average response
time estimate be. This model does not give something for
nothing. It does not give a good estimate of response time for
an ill-defined application implemented on an ill-defined
hardware display system. On the other hand, the model should
give an accurate estimate of the system response time for a well-
defined application, subject only to the appropriateness of the
assumptions incorporated into the model.

Certain assumptions are explicitly and implicitly imbedded

in the model. The first of these is that the model requires
that all remote computer pre-processing be finished before any
information is sent to the main computer. This need not be the
case; in a real system, information might be sent as it is
extracted from the display file, and the main computer might
begin processing as well. Other examples are easily seen. As a
result~ the response time as predicted by the model will be
worse than might realistically be obtained from a system whose
programmers make intelligent software design~ decisions to take
advantage of any possible concurrent operations.

This is not as serious as it may seem to be, as a certain

amount of concurrency is implicitly included in the model. The
most conspicuous example is that of sending or receiving data
link messages. The actual transmission would be requested by an
application program, but the word-by-word I/O operations would
be handled either on an interrupt basis by the executive system,
or possibly by a hardware block-transfer facility, while other
application programs could be executing.
Another assumption is that all actions associated with a
particular service request must be completed before the user can
ask for further action. A plausible counter example is an
application in which a user requests that a display be prepared
for later offline plotting on a hard copy device. In most cases
there would be no logical reason that the ensuing computations
not be performed in a low priority background mode of operation
while the display console user proceeds with his graphical work.
This assumption can be overcome by not including such cases in
the estimates of computational requirements used to find the
model's parameters.
The basic structure of the model makes remote disk accesses
in the pre- and post-processing operations impossible, while

1016
there is certainly nothing inherent in display applications to
preclude the desirability of such actions. By eliminating the
possibility of such accesses, the model will tend to
underestimate the modeled system's response time if the system
actually makes the accesses.

The model also allows only one level of bulk stor'age at the
remote computer, specifically head-per-~rack disks or drums.
This limitation is based on two premises. The first is that
other reasonably priced bulk storage media which might be used
at the remote computer (magnetic tape, for ins~ance) a~e not as
cost-effective as disks or drums, unless very large ahlounts of
on-line bulk storage are needed. The second is that if a large
amount of on-line bulk storage is needed, there should still be
included a disk or drum for storing the more frequently used
files, to help maintain a reasonable response time.

A final assumption is that the main computer is not needed

when the remote computer accesses the ma1n computer~s bulk
storage. While this is not really tI'ue. the processing time
needed will be small when compared with the storage access time,
and is consequently neglected. thereby slightly reducing the
model's response time estimate.

Why have these assumptions been made? Why can~t the Thodel
be bigger and more sophisticated so that the as~umptlons arenit
needed? For several reasons: the most impor~ant is that as the
model becomes larger and more detailed. more and more must be
known about the fine details of an application to determine the
model's parameters. The model as it exists now is already
detailed, and is rather demanding in what must be known about
the display system application; asking for even more application
parameters is most unreasonable and unI'ealistic.

A second reason for limiting tne model's size is

limitations of the available analysis tools, i. e., as the model
acquires more detail more computer time is needed for analysis.
Because the model will be analyzed many times, the time for a
single analysis must be kept within reasonable bounds. That Is.
a tradeoff exists between the model's con~lexity and tne
computer time needed for its analysis. A relatively simple
model has been chosen, so that many points in its parameter
space can be examined. An excellent exrunple of the converse
choice is work done by Hielsen (12). which uses a highly
detailed model of the IBM 360/67 and its time-snarirlg software
to predict user response time and system loading. Because of
the model's detail and resulting long analysis time, only a
single very haphazard optimization was possible.

To conclude our discussion of the model. it can easily be

shown that, under very mild restrictions, increasing the display

1017
system's hardware capabilities also increases the system's cost
and decreases its response time. These properties will prove to
be most useful.
3. Analysis Techniques
In the preceeding section a mathematical model of a display
system was presented. The model attempted to abstract and
solidify the essential salient characteristics of display system
operation. In and of itself, however, the model is not
particularly helpful unless we can use it to find response time.
When the display terminal serves only one display console,
no queueing occurs. In this case a closed form expression gives
the system response time. However, with more than one user,
queues can occur, so that either simulation or Markovian
(queueing) analysis must be used. A problem arises here.
Markov analysis requires that the model possess certain
properties. there is unfortunately no assurance that the display
model satisfies the requirements. Simulation, on the other
hand, places virtually no restrictions on the model. The
problem is that in terms of computer time, simulation costs from
5 to 15 times more than Markov analysis.
Because of this problem a study was made to compare the
results of simulation and Markov analysis as applied to the
model, even when the model did not meet the requirements for
Markov analysis. The results showed less than a seven percent
difference between the two analysis methods for the paramater
set used with the model. While this is definitely not
generalizable to other models or to greatly different parameter
sets, it does justify the use of Markov analysis for the work
reported here. This means that the Recursive Queue Analyzer
(RQA) programs developed by the University of Michigan's Systems
Engineering Laboratory (20) can be used to analyze the model.
4. Optimization
An optimization procedure has been devised to find the
display system (data link, remote computer-display control, its
core storage and bulk storage) which minimizes response time
subject to a cost constraint. The optimization accepts as
inputs a paramaterized description of the display system's
application, and descriptions of up to sixteen choices for each
of the four display subsystems.
The optimization procedure occasionally uses the display
system model to calculate the response time which a display
system will yield. indeed, the most important feature of the
optimization is that it uses the display model's properties

1018
pointed out at the close of section 2, along with a lower bound
on response time, to minimize the number of times RQA is used:
even though RQA is less expensive than simulation, it is still
not cheap. Typically in examining about a thousand possible
display systems, RQA is used but two or three times during the
optimization: therefore an optimization becomes very
inexpensive, sometimes costing less than a single simulation.
5. Computing Power - Display Capacity
A critical necessity in the optimization is the creation of
a suitable data base of hardware subsystems from which an
optimal display system can be chosen. This can be rather easily
done for all the display subsystems except the remote computer-
display control subsystem for which not just computing power,
but also display capability must be determined. Display
capability must be known because not every display control can
display the same amount of information. Only those able to
display some minimum amount of information can even be
considered for inclusion in a display system; this minimum
amount of information is application dependent. If some display
controls can be eliminated by this criteria, the remaining
display control-remote computers need then be rated only
according to their computational abilities.
A convenient way to measure the display capability of
various display controls is with standard test patterns typical
of various applications. The method used by Adams Associates in
The Computer Display Review is typical of this approach.
The second part of the problem, measuring the computing
power of remote computer-display controls, is a bit more
difficult. The most expeditious approach is to create a list of
display oriented macro level operations, such that any and all
display work can be performed be programs made up of sequences
of these macros. Different pieces of hardware are evaluated by
finding the execution time of each macro. These times will vary
as the hardware's capabilities change, and will decrease or
increase as more or less of the hardware-software tradeoffs are
manifested in hardware. By taking a weighted sum of the
execution times (where the weights are application dependent), a
particular remote computer-display control is evaluated for a
particular application. A detailed discussion of this technique
is available in two references (5, 6). Its final result is a
set of remote computer-display controls, each of which can
display at least some minimal amount of information, and each of
which can execute display macros faster than any other unit of
comparable price. These units are then input to the
optimization program.

1019
6. Application

We have presented a display system model which, when given

a parameterized description of a display application and display
hardware, predicts average response time. There is an
optimization technique which uses the display system model, the
application description, a description of various possible
display subsystems, and an upper cost limit to find the optimum
hardware configuration for the application, at the given price.

Where do we go from here - what now? We could just use

these tools from time to time, designing optimum display systems
as the need arises, as it surely will. As we mentioned in the
introduction, graphics equipment is expensive. Yes, wider usage
and technological advances will help drive prices down, but even
then we will still want to use our display system money in the
most effective way. and therefore the tools developed here will
continue their usefulness into the future.

We can, however, use the model and optimization here and

now to look for some useful general information about designing
display systems, by doing just that - designing display systems.

Specifically, in this section these previously developed

tools will be used to select optimum display hardware
configurations for several diverse applications. The results
of the optimizations will be useful in several ways. The wide
range in system response time of optimal versus nonoptimal
display systems can be illustrated. One of the motivations for
the work reported here is that since this range eXists, display
systems' designs should be on the fast response side of the
range. The use of the tools in providing cost-effectiveness
information for use in selecting which of several optimum (for
different costs) display systems to install will be shown.
Finallyj an attempt will be made to deduce from the results some
general guidelines or statements which will be useful in and of
themselves to designers of graphical display systems.

To accomplish this, two types of data are needed: hardware

and application. A hardware data base including a wide range of
hardware capabilities has been developed: data links with
transmission rates from 100 bps to 500,000 bps, head per track
disks from 400,000 bits to 6 million bits, core storage from
50,000 bits to 400,000 bits, and a variety of remote computer-
display controls, including many combinations of hardware
options. This is basically factual information compiled from
hardware specifications.
Application data, to the contrary, is unfortunately not
readily available, and must therefore be guessed at and
estimated. This has been done for four different display
applications, each of which are now briefly described.

1020
Text Editing

In this application the display console and an

associated typewriter keyboard is used first to
enter text into the computer system, and then to
scroll through the text to make corrections,
additions, and deletions. The light pen is used
to indicate what words or letters are to be
modified, much as a cursor is used in some
systems. As this is a very simple application,
none of the more sophisticated remote computer-
display controls' extra capahilities are used,
and many of the display macro instructions are
not used.

Two-Dimensional Drawing

This application is intended to provide a general

two-dimensional drawing capability for a
multitude of users. The user can either recall
an old drawing from a library and do
modifications, or start with a blank screen.
build up a picture, name it, and store it in the
library. Pictures consist of elements. which can
be points, lines) text, or arcs of circles.
These elements can be individually positioned
into place, temporarily deleted. or permanently
deleted. In addition, the entire picture can be
translated. and its size can be arbitrarily
scaled up or down. The light pen, naturally, is
used for indicating elements and positions. A
keyboard is used for entering text elements and
picture names.

Three-Dimensional Drawing
Aside from the addition of a third dimension, the
only substantial external difference between this
and the previous application is the capability to
rotate a solid object in three dimensions.
Computationally, however, more effort 1s needed
to keep track of the third dimension.

General Network Analysis

This is meant to represent anyone of many

network analysis programs. The network elements
might be electrical components such as resistors,
inductors, capacitors, transistors. and sources.
or they might be mechanical devices such as

1021
 springs, masses, and dashpots, or they might
represent the stochastic service system elements
of queues, servers, branches, and blocks.
Whatever the case, the user progresses through
several phases. First, a network consisting of
elements and their connections is constructed.
Elements ar~ chosen from a menu and moved into
place with the light pen, and connections drawn.
Changes and deletions are made as required. In
the next phase, numerical attributes are assigned
each element. For electrical networks, this
would correspond to ohms, henrys, farads, or a
transistor type. In the third phase, the desired
analysis results are specified. The network is
then analyzed by whatever numerical techniques
are appropriate to the type of network drawn, and
finally, the requested results are plotted.

These applications have been selected to cover a wide span

of computational, display, data storage, and data transmission
requirements. Optimum display systems have been found for each
of the applications, for a range of costs and for one, two, and
three display consoles serviced by the remote computer. This
resulted in a total of 73 display systems, each of which is
optimum for its intended use.
The per-console cost and average response times of these
systems are depicted in Figures 3 to 6. R'refers to t~e.~umber
of dis,lay consoles in a display system. It is important to
understand that display systems do not exist below and left of
the curves - the curves themselves represent the fastest (in
terms of average response time) possible display system for
their cost. This is indeed the meaning of optimum! On the
other hand, there are many display systems above and right of
the curves, but they are nonoptimal: they cost more and give
poorer response time than systems on the curves.
Given the curves, what can we do with them? Their first
usefulness is in providing a cost-effectiveness measure for
various optimum systems. Let cost-effectiveness be defined as
the number of user-display interactions/second obtained for each
dollar spent. Then

The reciprocal of the numerator is the time needed to

complete one interaction. The system's cost in the denominator
is divided by R to place the calculations on a per-console
basis.

1022
----------------------------------------------~o
-
d

(\/rt')
II " II
0:: 0::0::
0
r<)
•

(f)
u
w
.
(f)

w
-:Et-
q LLJ
(f)
Z
0
a.
(f)
w
cr
LLJ
~
ffi
rt')
•
~
:E
::>
~

-:E:2

rt')

~----------O-O~O-g----O-O~O-v--~O-O~O-£--~O~O~O-G---O-O~blq
S(:IVllOa lSO:> AlH1NOLN
Figure 3. Optimum text editing system costs and response times.

1023
 '. -

r<)
o.

~------------------------o~------~------~o~------~o
a '
0 0 0
0 0 0
v (\J

S~\1ll0a 'lSOJ AlHINOW

Figure 4. Optimum two-dimensional drawing system costs and response times.

1024
 The results of applying equation (1) to the optimum display
systems found for the 3-D.drawing application (Figure 5) with
one, two, and three display consoles are shown in Figure 7.
The peaks in cost-effectiveness determine which of several
optimum (in the sense of minimum response time) display systems
is optimum in the cost-effectiveness sense. The three most cost
effective systems occur at costs of $2180, $2065, and $1999 per
display console. This is just a reflection of economies of
scale: for more users, the most effective system costs less,
and provides more interactions/second/dollar. On Figures 3 to
6, an asterisk denotes those systems chosen as most cost-
effective on the basis of (1).

A more sophisticated cost-effectiveness analysis would also

take into account the monthly cost of the system's user, which
would probably fall between $2000 and $3000. A display system
judged best on the basis of equation (1) and having a response
time of 30 seconds wastes a lot of human time which, if taken
into consideration, would force selection of a faster and more
expensive display system.

On a more intuitive basis, Figures 3 to 6 all show that

starting with the slowest responding systems, very small
incremental expenditures (less than $200) result in order-of-
magnitude improvements in response time. As more and more money
is invested, however, the returns become less and less
significant. Indeed, there exists on many of the graphs a
rather distinct breakpoint at which the slopes of the minimum
response time curves become distinctively negative. This
emphatically signals a diminishing returns situation. in which
more expensive display systems give back relatively little in
return for their increasing prices. The curves seem to say that
it is wise to spend somewhat more than the necessary minimum,
but not too much more. We will now turn our attention to
determining what should be purchased beyond a minimum system by
finding some general guidelines for display system designers. A
word of caution must first be interjected.

Guidelines are not absolutes; they are aids to be used in

context. That is, guidelines can he used only within the context
of applications for which they are intended. The applications
studied here have been selected to provide a reasonably broad
base on which to establish guidelines, so the guideline's
usefulness can go across (but not necessarily beyond) the base.
The implicit danger with guidelines is that it is easy to use
them where they do not apply: it is easy for a designer to
become little more than a cookbook technician, merely looking up
guidelines and indiscriminately applying them. Having given
this warning, the optimization results in Figures 3 to 6 and the
descriptions of the hardware selected for each system ( which
are not reproduced here, but are available in (6)) can be

1027
 o
r-------------------------------__------------~Oo II)

0
en
~ 0::
<t
..J
..J
0
C
..,:
en
0
u
~
~
~
Z
0
0 :E
0
0
",

o
o
oC\I

.,01 x SS3N3AI.l:>3.:1.:13 .lSO:>

Figure 7. Cost effectiveness for three-dimensional drawing systems.

1028
~-------------------------------------------------'Q
r<>

(/)
c
z
Q 0
u
w
(/)
.
w
~
t-
w
(/)
z
0
r<> a.
(/)
w
rx:
w
(9
•
<t
0::
W
>
<t
- ~
:J
:E
z
:E

OOOg OOOv 000£ 0002 000 I

S~'VllOO 'lSOJ AlH1NOlN

Figure 5
1025
 o
o
rt) - C\J
II II II
a:: 0::: 0:::

0
r<>
(,
(,
L
C.
ole
..-=
l

« ~
l
q (
..
(
(
(
l
(

l
(
c

r<)"
.

OOOS OOOV 000£ 0002 0001

S~'1110a elSO:> AlHlNOV\l
Figure 6. Optimum network analysis system costs and response times.

1026
Additonal response time improvements are obtained (at high cos
first by improving the remote computer-display control and th
by using more core storage."
To justify the necessity for these guidelines, Figure
shows just how scivere the penalties of using a nonoptimal desi,
can be. The figure plots response ti~e versus cost for tl
network analysis application with three users. Both optimum ru
worst case response times for various values of cost al
plotted. The worst case response time is the maximum respon~
time of those display systems which cost the same as an optimt
system. The graph's interpretation is that, for instance, j
$2340 per month is to be spent on a display system, the respon~
time can range from .155 seconds (Point A) to 3.92 secone
(Point B). These times differ by a factor of 25. Also, tl
graph can be interpreted to show that if a response time of ,
seconds is needed, the display system's ~onthly cost can val
from about $2600 (Point C) to about $3400 (Point D). Th~
represents an unnecessary expenditure of up to $800! Thus ~
see that the differences between optimu~ and worst case displc
systems are significant, with respect to both cost and respon~
time. Therefore, display system designers must have at thej
disposal means of making intelligent design decISions, becau~
the consequences of making bad decisions are too serious.
In conclusion, the goals set forth at the start of thj
section have been ~et. The tools presented in earlier sectior
have been applied to several display applications, and tt
results have been interpreted so as to justify the search fc
display system design guidelines. These guidelines have beE
stated. Of course these guidelines must be used in the propE
perspective, first because parameters on which they are basE
were only estimated, and second because the relative costs c
the subsytems studied might change in the future.
7. Summary
The purpose of the research reported here has been t
develop aids for the analysis and design of highly interactiv
graphical display systems. These aids are needed because iner
design decisions can be very wasteful.
To provide a framework within which to work, a mathematica
model of a display system was developed. The model uses
description of the system's application and hardware to predic
response time. Included in the model is a scheme for dividir
display processing between the main and remote computer. 2
that the model can be simple enough to facilitate quic
analysis, and to make it realistic to use, the level of detai
is relatively crude.

1030
examined in an attempt to deduce general guidelines for display
system designers.

The most striking phenomenon which has been observed is

that as additional money is spent. the first subsystem to be
upgraded is the data link. This is because small amounts of
additonal money yield large improvements in data link
transmission rate, which are in turn reflected in significant
improvements in average response time. Note that this might not
be the case with applications making less use of the data link
than the applications studied here.
Once the data link has been upgraded to the synchronous
switched line or private voice grade line level (2000 or 2400
bps), additional transmission speed increases become
considerably more expensive. For the applications being studied,
small incremental amounts of money must therefore either go
toward more core memory. bulk storage. or a faster remote
computer-display control. In every instance bulk storage was
added, and in some cases the computer-display control was
improved (only in cases when an improvement is inexpensive).
Only twice was core memory added. In some cases. the data link
speed was decreased, because adding bulk storage decreased data
link traffic and thus made a fast data link less important.
This was particularly evident in the text editing and the two-
dimensional drawing applications. for which response times on
the order of 80 milliseconds were obtained with data links no
faster than private voice grade lines. For three-dimensional
drawing, about a 100 millisecond response was obtained, and for
network analysis. about 200 milliseconds. The next step beyond
these response times was taken with Telpak A service, providing
a transmission rate of 40,000 bps, and also providing a
substantial increase in cost. By consulting the graphs of
Figures 3 to 6 it is seen that the response times mentioned
above correspond in general to pOints beyond which the returns
on expenditures decrease significantly. However, if better
response time is needed, the results show that both Telpak A
service and additional bulk storage are the most rewarding;
significantly increasing core storage and remote computer-
display control capability are relatively less important.

The general guidelines derivable from this narrative might

thus read as follows: itA satisfactory inexpensive display
system uses a voice grade data link, no bulk storage, little or
no core storage beyond the absolute minimum needed, and the
least expensive remote computer-display control. For little
additional expenditure, the addition of a significant amount of
bulk storage provides better response time. Inexpensive
increases in the remote computer-display control's capabilities
are also helpful. Further response time decreases are achieved
with broad band data link speeds and more bulk storage.

1029
 10.0..----< \-----------------~
F \
\
,,
,,
\
sq
\
\
\
\
\
\~
C/)
o \\~
z \~
o
~ 1.0 \0
C/) \~
... \\"\\
w \
2 \
I- \
W
C/)
\
Z \
o \
,,
0...
(f)
W ~
0::
\
\ ,
.I 0 "~ \ 0

\
E

1500 2000 2500 3000 3500

PER TERMINAL MONTHLY COST
Figure 8. Optimum and worst case response times.
 We determined that numerical queueing analysis is much
faster (in terms of computer time) than simulation, and produces
equally satisfactory results. We developed an optimization
procedure which very efficiently finds an optimum display system
having no more than a given cost. This optimization, which in
turn uses the display system model, is the primary analytical
tool developed in this research. All else is subsidiary to it.
The optimization can be used by display system designers as a
tool in itself. It is used here to study several display
applications, and to find design guidelines.

The usefulness of all this work was demonstrated in section

6. The characteristics of four different display system
applications are estimated (not measured). and many optimum
display systems are found. These results are used to
demonstrate the necessity for system design aids. and to develop
some guidelines for system designers.

8. Critical Evaluation

What are the good points of this research? First and

foremost, it provides system analysts and designers with a
conceptual basis on which their efforts can be established. The
steps required for designing display systems on an objective
basis have been illustrated. Second. the specific mathematical
tools developed here have been shown to be useful. Finally,
the design guides should prove helpful to system designers.

What is wrong with the research? First, it is most

difficult to evaluate the effect of the various simplifications
and assumptions which have been made to develop the display
system model. Second. the model's output is only as good as its
inputs, which are the application and hardware specifications.
Because the appropriate data is not available. the application
specifications have been estimated. They mayor may not be
satisfactory. The taking of detailed data on display
applications would be most helpful. As time goes by. relative
costs of the display subsystems will change. The guidelines will
therefore also change: they are not lasting and enduring.
although the techniques used to find them are.

Despite these weaknesses, and because of the strong points,

it is felt that this research provides a sound starting
foundation on which others can build toward the Optimum Design
of Computer Driven Display Systems.

9. Acknowledgements

The work reported here was supported by U. S. Air Force

contract AF30(602)-3953. and was performed at the Systems

1032
Engineering Laboratory, The University of Michigan. The
author's work was guided by Professor K. B. Irani.

REFERENCES
(1) Adams Associates, The Computer Display Review, Bedford,
Massachusetts, 1968.
(2) M. R. David and T. O. Ellis, "The RAND Tablet; A Man-Machine
Graphical Communication Device," Proc. FJCC, Washington D. C.,
Spartan, 1964, pp. 325-331.
(3) D. F. Dawson et. al., "Computer-Aided Design of Electronic
Circuits - A User's Viewpoint," Proc. IEEE, vol 55, pp. 1946-l954j
November, 1967. .
(4) M. L. Dertouzos, "An Introduction to On-Line Circuit Design,'
Proc. IEEE, vol. 55, pp. 1961-1971, November, 1967.
(5) J. D. Foley, "Evaluation of Small Computers and Display
Controls for Computer Graphics," IEEE Computer Group News,
January, 1970.
(6) J. D. Foley, Optimum Design of com~uter Driven Display Syster
Systems Engineering Laboratory Report 3 , The University of
Michigan, Ann Arbor, 1968.
(7) T. S. Hagan et. al., "The Adage Graphics Terminal,"
Proc. FJCC, Washington D. C., Thompson, 1968, pp. 747-755.
(8) J. S. Koford et. al., "Using a Graphic Data-Processing Syster
to Design Artwork for Manufacturing Hybrid Integrated Circuits,"
Proc. FJCC, Washington D. C., Spartan Books, 1966, pp. 229-246.
(9) K. H. Konkle, "An Analog Comparator as a Pseudo Light Pen fOl
Computer Displays," IEEE Trans. on Elec. Comp., vol. 17, pp.54-55
January, 1968.
(10) H. C. Laver, "Bulk Core in a 360/67 Time-Sharing System,"
Proc. FJCC, Washington D. C., Thompson Books, 1967, pp. 601-609.
(11) M. H. Lewin, "An Introduction to Computer Graphfc Terminals,
Proc. IEEE, vol. 55, pp. 1544-1552, September, 1967.
(12) N. R. Nielsen, "The Simulation of Time Sharing Systems,"
Comm. ACM, vol. 10, pp. 397-412, July, 1967.
(13) D. f1. Prince, "Man-Computer Graphics for Computer-Aided
DeSign," Proc. IEEE, vol. 54, pp. 1698-1708, December, 1966.

1033
(14) H. C. So. "OCLA: An On-Line Circuit Analysis System,"
Proc. IEEE, vol. 55. pp. 1954-1961. November. 1967.
(15) A. Spita1ny and M. J. Goldberg. "On-Line Graphics Applied t
Layout Design of Integrated Circuits," Proc. IEEE, vol. 55,
pp. 1982-1988, November, 1967. ,
(16) R. F. Sproull and I. E. Sutherland, "A Clipping Divider,"
Proc. FJCC, Washington D. C., Thompson, 1968, pp. 765-775.
(17) R. Stotz, "Man Machine Console Facilities for Computer-AidE
Design," Proc. SJCC, Washington D. C., Spartan, 1963,
pp. 323-328.
(18) G. C. Ternes and D. A. Calahan, "Computer-Aided Network
Optimization - The State-of-the-Art," Proc. IEEE. vol. 55,
pp. 1832-1863.
(19) University of Michigan Computing Center, Michi~an
Terminal System, (2nd Ed.), Ann Arbor, Michigan, 19 7.
(20) V. L. Wallace and R. S. Rosenberg, RQA-1, The Recursive
Queue Analyzer. Systems Engineering Laboratory Report 2, The
University of Michigan. Ann Arbor. 1966.
(21) T. G. Williams, "Time Sharing System Organization for
Computer Graphics," Proc. Second Hawaii International Conferenci
on System Sciences, Western Periodicals Company, 1969.

1034
 TOO
AN INTERACTIVE THREE DIMENSIONAL
DRAWING PROGRAM FOR GRAPHICAL
DISPLAY AND LIGHTPEN

R. J. Hubbold
Department of Engineering, University ofLeicester,
Leicester, England.

INTRODUCTION

This paper describes a set of FORTRAN programs written to investigate

the use of a CRT graphical display with lightpen as a three dimensional
sketchpad. The programs are operational on an ICL 4130 computer with
an Elliott 4280 graphical display unit, and they form part of a more
general investigation into using displays for 3D problems, including
Coons' patch techniques for surface modelling.

Various data structures are being tried, which express the topological
nature of the associations between data. The design of the data structure
is discussed and a list of the programs which comprise the system is
included in an Appendix.

SOME VISUAL APPRECIATION PROBLEMS

The term "interactive problem solving", used in relation to computer

graphics, implies a two way communication between man and computer. Many
obstacles exist which complicate this communication process, and they are
particularly evident if the picture is three-dimensional. Much effort has
been devoted to overcoming problems (f visualization: for example,
algorithms for removing hidden lines 1) and use of stereo views. However,
as much as these may aid the viewer in understanding the picture on a
display screen, they represent investigations into one aspect of the
communication process, namely, the flow of information from the computer
to the man. The programs described here are concerned with improving the

1035
flow of information in the reverse direction by attempting to provide a
natural means for constructing three dimensional pictures.

A truly effective communication cannot be established without

considering flow of data in both directions, and it might be thought
that improving the man's understanding of the picture will aid him to
communicate his ideas back to the computer. This is often true but
the use of stereo views is an example which serves to show that this is
not always the case. What needs to be established is some kind of feed-
back loop where the user can get a feel for what happens on the screen as
he controls the various input devices available to him. The lightpen is
a very suitable form of input for achieving this loop as it can be used
to alter a picture dynamically.

USING THE PROGRAMS

Using a tracking cross and lightpen, only two degrees of freedom can
be controlled independently at anyone time, corresponding to the X and
Y coordinates of the cross. Effectively, in drawing in three dimensions,
three coordinate values must be controlled and if this is to be achieved
with the tracking cross, one of the coordinates must be related in some
way to the other two, or held constant. The choice of how to relate these
coordinates plays a significant part in determining how it will be
possible to arrange the operation of the program.

The usual approach to 3D drawing is to define the plane of drawing.

The method suggested here, however, is to define planes in which points
may be specified and then to allow a drawing to be constructed by joining
these points. Therefore drawing of lines is not limited to the specified
planes. In order to define points in space, use is made of a pseudo
tracking cross which moves in three dimensions under control of the
lightpen. The operation of the programs is based on the use of light-
buttons - words or symbols displayed on the screen which when selected
with the lightpen cause some appropriate program to be executed, or option
to be chosen. To control the movement of the pseudo cross, use is made
of "dynamic" lightbuttons which appear, at the appropriate moment,
clustered around the tracking cross on the screen, an idea used by
Wiseman at Cambridge, in the PIXIE system. Usually this corresponds to
the current position of the lightpen and makes selection very rapid,
because the relevant lightbuttons always appear close at hand. Some other
lightbuttons appear at the right-hand edge of the screen and for major
operations, menus of options appear at the bottom of the screen. The
arrangement of these menus and the way in which they are use~ to construct
commands using the lightpen are the subject of another paper(2~

Whenever the command "DRAW A NEW OBJECT" is executed a set of isometric

local axes labelled X, Y, Z appears at the tracking cross position. The
three lightbuttons XYFLANE, YZPLANE, ZXPLANE appear down the right-hand
side of the screen. Selecting one of these defines a plane containing

1036
the last defined point in space, parallel to the XY, YZ or ZX plane.
This plane is termed the ACTIVE PLANE.

Pressing a console key on the display unit causes three lightbuttons

to appear clustered around the tracking cross. If the active plane is
XYPLANE these lightbuttons will be X, Y and N. Choosing one of these
causes the pseudo tracking cross to appear, in the active plane. If N
is chosen the pseudo cross position on the screen coincides with that of
the true tracking cross. Choosing X would cause it to appear on the line
in the active plane, parallel to the local X axis, passing through the
last defined point. Its local Y coordinate would be the same as if the
"N" option had been chosen and its X value is, of course the same as that
of the last defined point.

If the active plane had been YZ the options would have been Y, Z or N.
and similarly Z, X or N for the ZX plane.

In general, the pseudo cross is constrained to move in the active

plane and may be fUrther constrained to move parallel to one of the
local axes, depending on the choice of lightbutton. Choosing a different
console button has the same effect as already described, with the addition
that the pseudo cross and last defined point are connected by a straight
line. Lines drawn in this way are updated dynamically as the cross is
moved, while the console button is held depressed (a technique usually
referred to as drawing rubber band lines). The pseudo cross is programmed
to grow larger as it is moved towards the user, a feature which has
proved very useful and which enables the user to appreciate that he is
not drawing in the plane of the display screen.

Figure 1 illustrates some of the steps in drawing the simple figure

shown in l(f). In l(a), the arrangement of the screen is shown: various
messages are displayed along the top edge of the working area to guide
the user, and the menus of options from which commands are constructed
appear at the bottom of the screen. The command "DRAW A NEW OBJECT" has
already been executed and the local axes and active plane lightbuttons
are present on the screen.

l(b) shows the dynamic lightbuttons corresponding to the currently

active plane which is XYPLANE. A line has already been drawn from the
local origin parallel to the Y axis and choosing the X lightbutton gives
rise to the situation represented in l(c). In l(d) a rectangle in the
XY plane has been completed and the active plane is now ZXPLANE. Selecting
the N lightbutton leads to fig. l(e). Continuing in this manner, the
completed figure in l(f) 1S obtained.

Some further features of the programs are

(1) The deletion of lines (edges)

(2) The ability to copy any previously drawn object any number of
times.

1037
1 (0) 1 (b)

1 (c) 1(d)

1 (c) 1(1)
 (3) The facility for moving items around on the screen and joining
them to other objects (and linking their data structures)
enabling larger aRd'mere complex· objects to be constructed
from a series of simpler units for building bricks.
(4.) The possibility of rotating objects to view them from another
point and also as a check on their three-dimensionality.
(5) The ability to cause the pseudo tracking cross to latch on to
any previously defined point when it is within a certain
distance of it. The test for proximity ean be made in both
a two and three dimensional mode.
(6) The whole picture may be scaled, or individual objects may be
scaled aepa?ately.

Figure 2 illustrates some examples of more complex objects constructed

from simple units and then modified.

INVESTIGATION OF DATA STRUCTURES

Much effort has been devoted to providing general schemes and packages
of programs for data structuring(3) Ring and tree type structures
employing facilities for allocating data areas and linking them together
with pointers have been developed for various problems at many research
centres. Because of the need to conserve space it is generally regarded
as desirable that modelling plexes(4) should be developed for each new
problem rather than use a more general scheme such as ASP(5).

Ring structures seem to be very well suited to use with interactive

graphics prog~ams, but the sizes of the data areas are now creating
problems if too many pointers are introduced. These problems are rapidly
becoming more acute with the increasing use of small satellite computers,
and time sharing systems on larger machines where only a small amount of
core store is available. This pinpoints the need to have compact and
efficient data structures and implies a minimum of pointers. This, in
turn, leads to a reduction in the number of associations which can be
expressed between sets of data. The alternative is to have larger
structures but to make use of disk storage to provide an extension of the
structure held in core. Investigations into these subjects are being
carried out at Leicester University.
The data structure used for TDD includes a large number of pointers and
cannot be regarded as a compact structure, but it enables the use of
simpler and more efficient algorithms. It is, however, a more compact
structure than would have been achieved using a general scheme such as ASP.
From a study of this some conclusions have been reached about how to
achieve a more efficient and compact structuring for the data without
complicating the algorithms unnecessarily. The structure of the data will
now be described.

1039
TDD DATA STRUCTURE

The data structure used in TDD is af ex~ension of tha used in another

project at Leicester, the LUISA system 6,7. The structure is based on the
use of rings and beads. A BEAD is a block of data, or more correctly, a
block of information, because a bead may contain both problem data and
pointers. The POINTERS are used to show the relationships (associations)
between groups or beads of data. The need to have mixed data and pointers
is particularly important in interactive programs. Without this facility,
associations between beads on separate rings cannot be shown, and the
data structure becomes a tree with all the data stored at the lowest level,
leading to long search times. Dynamic modification of the structure

1040
OBJ
~ NEXT f-+ Pointer to next ~ead on object ring
XORIG X
YORIG Y global coordinates of origin of local axes
ZORIG Z
ALPHA
BETA orientations of local axes w.r.t. global axes
GAMMA
SCALE Local scale for this object
NVERTS Number of vertices
NEDGES Number of edges
FVERT ~ Pointer to ring of vertices
LVERT ~ Pointer to last vertex bead on ring
FEDGE f- Pointer tOi ring of edges
LEDGE ~ Pointer to last edge bead on ring

VERT
---iI NEXT 1-+ Pointer to next bead on vertex ring
OBJ f-p Pointer to object bead
LAST ~ Pointer to preceding bead on ring
X
Y Local coordinates of vertex
Z
GX
GY Global coordinates of vertex
GZ
DX
Display coordinates of vertex
DY

Pointer to next bead on edge ring

Pointer to object bead
Pointe~ to preceding bead on ring

Pointer to vertex at end of this edge

Pointer to vertex at other end of this edge

Number of objects
Pointer to ring of objects
Pointer to last object bead on ring

FIG. 3 CONTENTS OF DATA BEADS

1041
becomes difficult with these tree structures, although they may be
suitable for batch programs if dynamic modification is not needed.
Modification of the structure requires the use of a free storage package
for the dynamic allocation of workspace and data areas (beads), otherwise
"garbage collection" becomes an overWhelming problem.

For the purposes of data storage in TDD an OBJECT is said to be composed

of EDGES whose ends are defined by VERTICES. For each object, three
types of bead are used:

an OBJECT BEAD containing information about the object (things like

colour or volume or density)

several
VERTEX BEADS containing data about vertices (for example their
coordinates in space)

several
EDGE BEADS containing information about the edges of the object
(e.g. length, orientation)

In order to associate the appropriate edges and vertices with a given

object, the edge beads are grouped on a ring pointed to from the object
bead and there is a similar pointer to a ring of vertex beads. Because
a given edge is defined by the vertices at its ends, a pointer to each
end vertex is stored in each edge bead.

Figure 3 shows the contents of the data beads and figure 4 illustrates
the relationships between them. In order to make some of the algorithms
more efficient several additional pointers have been included. These are:

(1) A pointer from each EDGE bead to the bead for the OBJECT
containing the edge.
(2) A similar pointer from each VERTEX bead to the OBJECT bead.
(3) A pointer from the object to the last VERTEX and another to the
last edge on the vertex and edge rings respectively.

Both forward and backward pointers are used for beads on a rlng.

In order to process the whole picture, which may include a number of

objects, the object beads are grouped on a ring pointed to from a single
bead termed the SCENE bead.

When the command "DRAW A NEW OBJECT" is executed a new object bead is
allocated and added to the ring of objects. A set of local axes appears
at the position of the tracking cross on the screen. The values of the
global coordinates of the origin of the local axes are stored in the
object bead along with the orientations of the axes.

1042
 j -
---., l ---.,
('I)

!;
('I)

~~ ___ J
If)

~ ~i. _ _ .J I

..,
~ii ..,
~

~!.~ N -----, N ---I

til ____..JI
8 ____ JI

_lttt
LLI
,> w
Nr
~I __ ---II
0 1

" ,( .., (
- -
~

8
t-

~
-
LLI
-
- ~

r
a ~

Ij
-
~
~

1
'"'"z
 As vertices and edges are defined, new beads are added to the vertex
and edge rings for the object concerned. This involves some updating of
pointers and several checks. In creating an edge, for example, it becomes
necessary to ascertain whether a new vertex is being created or whether
the ends of the edge correspond to some previously defined vertices. When
an edge is deleted it is necessary to perform a check on the vertices at
its ends. If these vertices do not form the end of some other edge they
too must be deleted and the appropriate edge and vertex beads returned
to free storage. Removing beads necessitates further updating of pointers.

From an examination of the data stored in the vertex bead it is

apparent that the local and global coordinates of the vertex are stored
in addition to the coordinate position of the point on the display screen.
Evidently this represents a duplication of data because the three sets of
coordinates are related, but it enables simpler algorithms to be used.
For example, in using the "latch on" facility in a three dimensional mode,
a two dimensional proximity check is made first, using the display
coordinates. If this check is positive the test is made in three
dimensions using the global coordinates of the vertex. Similarly, the
local coordinate values are of interest in some of the other routines.

CONCLUSIONS

As stated in the introduction, these programs represent part of a more

general investigation. It has been found that the user intuitively
watches the movement of the pseudo tracking cross and very rapidly becomes
familiar with the concept of working in different planes in space. Making
use of the lightpen in the manner described provides the feedback loop
mentioned earlier.

Future inclusions in the present programs which are being implemented

at the time of writing include the ability to fix dimensions exactly and
the facility to rotate an object with respect to its local axes, thereby
redefining the sets of active planes. The capability for modifying the
position of points tn space using the pseudo cross is also being
programmed. It now appears that these concepts of 3D model manipulation
can be extended to allow surfaces to be sketched with the lightpen and
some investigation of this is planned.

One problem which has been experienced has been the time to process
the whole scene to produce rotations for purposes of viewing the objects
in three dimensions. This is because of the time taken to search round
a ring updating the global coordinates. As a result of this a suggested
modification of the data structure is to remove the global coordinates
from the vertex beads and to place all of them together in one bead.
In their place in the vertex bead a pointer is inserted which indicates
their position in the global coordinates bead. For complete picture
transformations only the global coordinates bead needs to be processed
and search times are much reduced.

1044
 Finally, some comment is called for to justify the use of the feedback
loop mentioned earlier, because this does lead to greater use of central
processor time. At present, emphasis is beginning to shift towards the
use of small satellite machines for interactive graphics work. As a
consequence of this the user has at his disposal a dedicated computer,
and extra use of C.P.U. time does not incur extra cost. Depending on
the amount of local (satellite) computing power available it is necessary
to arrange the programs accordingly, to use as little of the main computer
C.P.U. time as possible.

Taking these factors into account, it is hoped that further investigation

into the techniques outlined above will yield some interesting new uses
for interactive computer graphics particularly in industrial design
applications.

REFERENCES

(1) A Survey of techniques for removing hidden lines.

A.R. Forrest, C.A.D. Group Document No. 19 Cambridge University
Mathematical Laboratory.

(2) A Fortran Package for Interactive Graphics.

G.A. Butlin, University of Leicester Engineering Department
(See chapter in this collection).

(3) A Mass Storage Relational Data Structure for Computer Gra~hics

and other arbitrary data stores.
T.E. Johnson, Department of Architecture, MIT. October 1967.

(4) The AED approach to generalized computer aided design.

Douglas T. Ross, Proceedings A.C.M. National Meeting, 1967.

(S) ASP Programming Manual.

J.e. Gray, C.A.D. Group Document No. lS Cambridge University
Mathematical Laboratory.

(6) An Interactive Structural Analysis System.

G.A. Butlin and R.J. Hubbold~ University of Leicester
Engineering Department Report 68-16 November 1968.

(7) A Scheme for Man-Machine Interactive Structural Analysis.

G.A. Butlin and R.J. Hubbold~ I.E.E. International Conference
on Computer Aided Design, April 1969. Conference Publication
No. Sl.

ACKNOWLEDGEMENTS

The author would like to express his thanks to members of the

Computer-Aided Design group at Leicester for their suggestions and

1045
encouragement, and in particular to Dr. G.A. Butlin for many useful
discussions.

APPENDIX Li st of programs

(Figures in brackets indicate length of code (24 bit words) generated).

KIKOFF main administration program including processor functions (2424)

EXECTE execution program which calls subroutines in the package (265)

DRAW main drawing routine (1268)

KOPY
enable an object and its data and data structure to be copied
COPYOB
(122, 453)

BUILD
enable objects to be moved or to be joined together and their
JNOBJ data structures linked (180, 772, 354)
TRLATE

TUMBLE enable objects to be rotated about global axes for viewing

ROTATE purposes. (Data not changed) (139, 709)

TWIRL enables objects to be rotated about local axes and updates

coordinate data (596)

AXES displays local axes of an object (280)

AXISLB
dynamic lightbutton routines (265, 48)
RIDLIB

TRFORM performs 3D coordinate transformations (120)

CR pseudo tracking cross routines (112, 8)

RIDCR

LATCA causes tracking cross or pseudo tracking cross to latch on

to vertices near to them (241)

DISPIK main display routine to extract data from data structure and
display pictures (161)

VALCHG enables various parameters to be changed (661)

COORDS tracking routine for the pseudo-cross (552)

DSPRNT for printing the data structure and data on a line printer
(344)

1046
SCENE
NEWOBJ
NEWEDG programs for building and manipulating the data structure
NEWVRT (56, 280, 200, 264, 321, 144)
RIDEDG
RIDVRT

A further 32 programs are us~d, belon~i~g to the Fortran Interactive

Graphics package, developed at Leicester 2. In addition 16 display
routines from the FRED package are used. (FRED - Fortran Routines for
the Elliott Display.)

All programs, with the exception of two or three small ones, and the
display routines, are written in FORTRAN IV.

Total length of code generated is about 20 K words. Dynamic arrays

and workspace account for a further 16 K words and generated constants
amount to 4 K.

1047
 LANGUAGES FOR GRAPHIC
ATTENTI ON-HAN 0 LI N G

I. w. Cotton

UN I VAC, Division of Sperry Rand Corp. Blue Bell,

Pennsylvania, Pennsylvania 19101, U.S.A.

INTRODUCTION

The primary area of software research into interactive computer

graphics has been in the design of languages for the definition of
pictures and the required underlying data structures. While this research
is undoubtedly important, it is llilfortunate that it has been performed
largely to the neglect of research into improved techniques and languages
for the interaction phase. The result has been that while it is getting
increasingly easier to define pictures to be displayed, it is still rather
difficult to specify the control path to be followed in response to oper-
ator interactions which seek to identify and perhaps modify picture
elements. The state of the art would appear to be at the macro-using or
subroutine-calling level, with little convenience and no particular
graphic or interactive orientation.

Complicating this problem is the current trend in interactive com-

puter graphics towards remotely accessed, time-shared systems which
utilize a small computer as a display processor. The satellite processor
is intended to handle a large number of display functions internally,
calling on the central processor only when extensive display file modifi-
cation or manipulation is required, or when console operator actions are
to be transmitted to the application program at the central site. Such
an organization should result in better responsiveness to the console
operator as well as less overhead on the central processor.

Typical graphic applications vary widely in the type of response

required of the satellite processor. For example, one application might
be to display intermediate results of a large data reduction process,
and interactively direct the course of the analysis, while another common
application is to provide the console user with a sketching facility.
In the first case, the satellite would be required to transmit key
depression information back to the central computer to direct the calling

1049
of different subroutines, while the second case requires that the satel-
lite be programmed to analyze the actions of the console operator, define
new structures, alter existing structures, and perhaps notify the central
computer of such additions and deletions. However, most remote systems
are limited in their flexibility since it is difficult, if not impossible,
for the ordinary user to specify the program in the satellite processor.
Adequate language facilities for multiple processor systems have been slow
to develop.
Computer response begins with operator input. Graphic attention
handling refers to the processes and techniques whereby human inputs to a
computer graphic system are serviced. An attention event, or simply
"attention", is a stimulus to the graphic system, such as that resulting
from a keystroke or light pen usage, which presents information to the
system. Servicing includes accepting or detecting the hardware input,
processing it to determine its intended meaning, and either passing this
information to a user routine or taking some immediate action related to
the display and/or its underlying data structure, or both. The emphasis
is on "immediate". Attention-handling is not intended to include any
detailed, application-oriented processing which the attention information
may indicate is to be performed. Thus, attention handling may be consid-
ered separately from any particular application.

This paper will examine the various levels of software support which
have been provided for programming the attention-handling task. Since
most of the graphic systems constructed in the past were single processor
systems, most of the discussion will not be complicated by multiple
processor considerations. The last systems to be discussed, however, will
be systems designed expressly for such a central site - satellite config-
uration. Languages will be described whereby each user can specify the
processing required in the satellite for his particular application.

HARDWARE CONSIDERATIONS

At first glance it might appear that the hardware characteristics

of the display system would play the greatest role in determining the
type of attention-handling support which could be provided. Certainly
it is true that the hardware capability will affect the ease of implement-
ing certain facilities, but it seems to be relatively unimportant in deter-
mining the level of facilities which can be provided. Compare this to the
case of the compiler languages, where basically similar (and roughly
compatible) facilities have been implemented on widely dissimilar proces-
sors, from the mini's all the way up to the super-computers. Where hard-
ware to perform a particuJar task is lacking (say, multiply-divide),
software can fill the gap (as with subroutines).

In the area of computer graphics, certain hardware features have been

found desirable, though none are essential. A partial listing of the more
useful features for attention-handling are given in Table I.

1050
 TABLE I USEFUL HARDWARE FEATURES FOR ATTENTION-HANDLING

HARDWARE FEATURE COMMENTS

x Y position registers Desirable information from light pen detects;

available may be obtained by software techniques if
not available.

Real-time clocks Facilitates light pen tracking; permits

adjusting refresh rate.

Priority interrupt system Eliminates the need for polling; attention

information more easily available.

Trap command Used in a variety of ways, including pen

(Program controlled tracking, maintaining identification of ind-
interrupt) ividual structures as they are displayed, and
calculating positioning vectors "on the
fly". [20J

Pushdown stack Useful for identification of structures in

hierarchial systems; usefulness enhanced if
coupled with display-file subroutining.

It is beyond the scope of this paper to consider the tradeoffs

between providing hardware features or implementating software routines.
It is generally enough to know that certain functional tasks can be
accomplished, one way or another. One particular functional task, how-
ever, is crucial to the attention-handling process: that of determining
that an attention has occurred. Hardware (not) provided in this area
has had greater impact on the level of support available, so a more
detailed explanation is warranted.

Flags and Interrupts

There are two basic ways in which input devices may enter attentions
into a }raceMo!': setting internal "flags" or via interrupts. The setting
of an internal flag is the more basic and simple-minded approach, but is
less efficient in terms of the programming required. Under this sort of
scheme, whenever the status of the input device changes (as, for example,
a key is depressed), an internal "flag" or indicator is set ("posted")
which may be tested and cleared under programmed control. This testing
may be performed in a "wait loop" waiting for a flag to be raised, or.by
periodically "polling" the device to see if the flag has been raised.
For example, the following block of code is used in the PDP-8 [4J to read
a character into the accumulator from the teletype:

LOOK, KSF /SKIP ON KEYBOARD FLAG

JMP LOOK /LOOP BACK AND TRY AGAIN
KRB /READ IN CHARACTER AND CLEAR FLAG

1051
A similar sequence is used to test if a light pen detect has occurred.

There are two alternative difficulties with this type of approach.

If the loop approach shown above is employed, the processor may not
function asynchronously with the attention sources. That is, while the
processor is waiting for the input device it is not doing any useful other
processing. Also, there is no way to break out of the loop if the flag
is never raised (the key never struck). However, multiple tests for many
types of flags may be included in the loop, and if the processor has an
internal real-time clock, the loop may be periodically broken.

The alternate approach is to code the flag test sequence as a sub-

routine which may be periodically called in order to poll the device.
This polling may be controlled by a timer, or may simply occur at differ-
ent places in the program which the processor is executing. In either
of these two cases, additional programming is required to perform the
poll, and of course the processor is not doing useful work when it is
actually performing the poll.

A better and more advanced scheme is to allow the input devices to

send a change of status to the processor as an external interrupt. Under
this scheme, a location in memory (called an "interrupt entrance") is
permanently associated with the type of interrupt. When the status of
the input device changes, the processor interrupts its normal control
flow and (without changing the contents of its program counter) executes
its next instruction from the assigned memory register. Typically, a
"Return Jump" or subroutine-calling type of instruction is stored there,
so that the present contents of the instruction counter are saved and a
subroutine is entered to process the interrupt. At the end of the sub-
routine a subroutine-exit type of instruction is executed which refers
to the previously saved instruction counter and returns the processor to
its normal control flow. Naturally, the accumulator and any other reg-
isters or indicators must be saved at the start of the subroutine and
restored before exiting from it. All interrupt sources associated with
this subroutine should also be locked out while in the subroutine to
prevent the processor from getting itself into an infinite loop as will
occur if the processor is in the subroutine while another interrupt occurs.
A simplified sample of this type of coding folIous for the UNIVAC@ 1557
Display Controller:

013 RJ INTRPT .INTERRUPT ENTRANCE

•
INTRPT ri .SUBROUTINE ENTRANCE
S ACCUM • SAVE ACCUMULATOR
SCA .RETRIEVE INTERRUPT DATA & ACKNOWLEDGE

UNIVAC® is a registered trademark of the Sperry Rand Corp.

1052
 S KEYBUF • STORE IN BUFFER
L ACCUM .RESTORE ACCUMULATOR
SET 1,0 • ENABLES INTERRUPTS
J IN'l'hPT .S~BROUTINE EXIT

The advantage of this scheme is that the processor and the attention
sources may function completely asynchronously. Interrupts may occur at
any time, be rapidly processed, and the normal control flow resumed (or
altered, as a result of information form the interrupt, by changing the
return address). Many different interrupt entrances may be provided for
the different classes of interrupts which may occur.

In fairness, it has been pointed out* that while the interrupt method
is intuitively preferred, it does not always gain as much as expected,
since the processing of attention information still may have to wait for
an idle point in the monitor loop. Consequently the interrupt processing
routine now sets flags rather than the hardware.

Finally, it should again be stressed that the hardware organization

of the graphic system for detecting and accepting attentions is not
critical in determining the attention-handling capabilities which can be
provided to a user. A system requiring polling for detecting attentions
may be every bit as good to a user if adequate system software is provided
to perform this polling automatically. A system permitting asynchronous
interrupts by attention events may not be utilized to its full capability
if the language structure provided to the user does not perIni t asynchron-
ous entry to his program. Thus, when in the discussions which follow we
speak of "synchronous ll or "asynchronous" invocation of attention handling,
we will be referring to software organization, not hardware capability.

LEVELS OF SOFTWARE SUPPORT

Now that the basic ways in which the interactive devices, or
attention sources, present information to the central processor have been
briefly explained, the various levels of software support for accepting
and processing this infonnation may be meaningfully discussed. In general,
such support permits the specification of a procedure to be executed upon
the occurrence of an attention. In each case, the system generally
collects certain information concerning the status of the display and its
associated program when the attention occurred.

Johnson L12.1 has suggested that the major differences in attention-

handling schemes are the methods of specifying the procedures to be
executed upon occurence of the attention and the means by which these
procedures are actually invoked after the attention event occurs. While
noting that at the point of invocation attentions may be handled either
synchronously or asynchronously, he bases his main classification (and

*G. E. Halliday, personal correspondence

1053
consequent discussion) on the various language forms for the specification
of attention routines.

We shall be more concerned here with comparisons based on the capa-

bilities of the various software levels. The detail of the information
collected by the s,yst~ when an attention occurs, and the types of proce-
dures which may be specified in response, may vary considerably from level
to level. As it turns out, however, a classification scheme based on
language form is also convenient for comparison on a functional basis,
since language development and level of capability seem to go roughly hand
in hand. The classification scheme adopted here is more general from a
language view than Johnson's since we want to make the finer cuts on the
basis of level of capability. We consider the following levels of soft-
ware support:
o. No Support
1. Subroutine or Macro Library
a. Low level
b. High level

2. Language Extensions

3. Special Purpose Graphic Languages

a. Graphical approaches
b. Command languages

These will be seen to correspond roughly to increasing levels of capa~

ity for accomplishing the attention-handling task.
o. No Support
As stated, the first level of support is the absence of any support.
This is equivalent to the position of a s,ystem programmer approach~ng a
new machine or input device. Knowing how the input devices present infor-
mation to the central processor, he designs a handling scheme to meet his
needs. If he is a s,ystems programmer, he will be concerned with the needs
of other users and will seek to develop a general purpose scheme which will
then fall into one of the other levels.
Too often, however, a graphics s,ystem incorporating a small display
controller is delivered without any attention-handling software, and each
user undertakes to wi te his own, resulting in a large number of special-
purpose, non-compatible subroutines. Such circumstances are usually
resolved when for "political" reasons or hopefully when a package is some-
what more general purpose and demonstrably better than the others, that
package comes into general use. Such a package is generally still inferior
to any well-designed, general purpose support package at even the lowest
(non-zero) level of support.

1054
1. Subroutine or Macro Libraries
The first actual level of support to be considered consists of librar-
ies of routines for the various attention-handling tasks. This level may
be provided as macros for assembly language usage, or as subroutines
(which, of course, use the attention-handling macros), for compiler-
language usage. Compiler language usage is somewhat easier (though likely
to be less flexible) since data areas and assorted control blocks needn't
be explicitly coded. However, considering the level of support in terms
of services provided and functional capability, there is no justification
for splitting the assembly language and compiler language implementations
into separate levels.
There is justification, though, for splitting the consideration of
such library support into low-level and high-level classes on the basis of
functional capability.
a. Low Level Libraries
The routines provided at this level of support have the purpose
of routing attention information to user routines. Polling is
generally required, either explicitly by the user or implicitly
within the software, so we may refer to this level as s,rnchronous
attention handling. Furthermore, attention information is not gener-
ally queued at this level, so that if an attention is not serviced
before a second attention occurs, information about one of the
attentions will he lost. (Note, however, that these restrictions
make no assertions concerning the level of complexity of the graphic
hardware.) There is no correlation of the attention information with
any of the user's data structures or picture elements. The infor-
mation provided by the attention is simply routed to a user-defined
routine for processing.
An example of a macro library at this level is provided by IBM's
"express" attention handling [9J. The macros provide linkages to a
graphic attention analysis routine which tests for attentions and
routes attention information to user routines according to attention
type, and to a graphic attention service routine which resets the
system to accept further attentions. Polling must be provided either
by a program loop (very inefficient in a multi-programming environment)
or use of the system interval timer to provide periodic linkages to
the graphic attention analysis routine.

An example of library support for a compiler language using

synchronous attention handling is provided by IBM's GPAK package. [IO]
In this package, the user must specify the addresses of all the
attention handling routines in an "attention table", which also con-
tains a code to indicate if the various attention sources are enabled
or disabled. The user may provide his own attention routines for any
or all of the attention sources, or he may rely on routines provided

1055
within GPAK. For light
GPAK attention routines
enable codes associated
The routines to process
the secondary tables.
pen detects and function key depressions, the
examine two secondary tables which also have
with individual keys or graphic elements.
these types of attentions are entered through

Attentions are processed only when specific GPAK subroutines are

called. The program may periodically test to determine if there is
an attention waiting to be serviced (essentially polling) or may wait
for an attention by relinquishing control to GPAK. In the latter case,
the GPAK package assumes the responsibility for determining when an
attention occurs.
In the area of light pen correlation, GPAK does provide more
facilities than low-level support ordinarily would. This is accom-
plished somewlmt after the fact of attention handling by data
structure correlating routines, but the scope of what is considered
attention handling may be extended to include this facility. The
routines provided build cross reference tables relating buffer
address for the display file with the actual graphic structures
represented. Rather than being returned the buffer address of a pen
detect, the application program may be returned data related to the
structure itself.

Another example of compiler-level support using synchronous

graphic support will be given in the discussion of attention-handling
integrated into higher level language syntax.

b. High Level Libraries

High level support packages are distinguished from low level

packages on the basis of several areas of functional capability.
Attention procedures are generally dynamically invoked immediately
upon receipt of the attention (or as soon as the program attains an
interruptible state), eliminating the need for polling. We may hence
characterize this level as asynchronous attention handling (while
still remembering that our classification is based on functional
capability rather than means of invocation). Attentions are also
queued at this level, if they occur at a time when they cannot be
~erviced. Finally, some correlation may be provided between screen
images and some data structure.
An IBM implementation of this type of a library are the "basic"
attention handling macros [9J. The discussion of these macros will
be somewhat expanded, since it is a typical and widely used scheme.*
The "basic" attention handling macros permit the programmer to:

*Much of this discussion is adapted from [9 J.

1056
 (1) Assign his own processing routines for specific groups of
attention sources'

(2) Dynamically re-assign routines or change the entry conditions

(which (group of) attentions they are to respond to);

(3) Wait for a particular anticipated (group of) attention(s),

while optionally continuing other processing;

(4) Poll for selected attention types as desired regardless of

routine entry conditions.

(5) Dismiss undesired attentions.

Particular advantages of this level of attention handling are:

• Attentions are not lost if the routine designed to handle

them is busy with an earlier attention at the time they
are received.

• Processing may be overlapped with attention input or

operator response time.

• Attentions not relevent to a particular interactive

sequence can be ignored.

• Gene~alized graphic-device programs may be incorporated

by the user into the attention-handling scheme.

Ifu-is at this level that attentions are first treated as logical,

rather than physical, stimuli. The priorities of the various
processing routines are assigned by software; the higher priority
attentions interrupt the processing of attentions with lower priority.
This is not to be confused with the physical hardware device prior-
ities that determine which of several simultaneous inter~lpts are
to be accepted. The software scheme requires that all hardware
interrupts be examined, with the order of processing to be that
logically assigned.

The macros provided for "basic" attention handling for the IBM
2250 are listed in Table II. The user can designate one attention-
handling routine to service all attention sources, or he can provide
separate routines for individual graphic devices, attention types,
or both. Whatever his decision, he must define his attention handling
capability to the system using the SAEC, SPAR and DAR macro-instruc-
tions. The ATTNINQ macro-instruction is also provided to facilitate
establishing and maintaining a communication sequence between the
display operator and an attention-handling routine.

1057
TABLE II. IBM BASIC ATTENTION HANDLING MACRO-INSTRUCTIONS FOR S/360-2250

Mnft1!l9ni c Macro-Instruction Name Function

SAEC Specify Asynchronous Entry Defines a control block that

Conditions specifies the entry point of a
user-written attention-handling
routine and the exact conditions
(i.e., attention types and
graphic device) that will cause
entry to the routine.

SPAR Specify Attention Routine Establishes control program

references (pointers) to the
control block created by the
SAEC macro-instruction; this
enables an attention routine
and also establishes a priority
classification for the atten-
tion routine.

DAR Delete Attention Routine Deletes the control program

references established by a
SPAR macro-instruction.

A.TTNINQ Attention Inquiry Permits polling for a (group

of) attention(s), either taking
a conditional branch (based on
the availability of desired
attention information) or wait-
ing until the information is
available, if none is currently.

When an attention occurs, the routine currently processing is

interrupted and the graphic attention handling (system) routines
receive control. All available user attention routines are then
examined one by one, in order of priority down to the priority level
of the currently active routine. (To be "available" in this con-
nection, a routine must have been specified by a SPAR macro-instruc-
tion; see below.) On each routine, the following tests are made, in
the order shown:

(1) Device. If the routine has not been designated to handle

attentions from the device that originated this attention,

1058
 no further test is made on it and the next routine is
e:xamined.

Activity. If the routine is active (i.e., interrupted

because it is already responding to a previous attention
is in a wait state, or already has attention data on its
queue, the attention is queued,for this routine.

~. If the routine has been specified to handle

attentions of this type (SAEC macro-instruction), the
attention is queued for this routine.
If no available attention routine can satisfy (1) and either (2)
Q£ (3), the attention is ignored and control returns to the
interrupted routine. Note that no routine of lower priority than
the currently active routine (if any) is e:xamined. Thus, if
attentions of a particular type are queued for a routine not
specified to handle routines of that type (because it was the
currently active routine and was of higher priority than the routine
specified for the particular attention type), they will be lost if
that routine exits without inquiring of their existence (AT~'INQ
macro-instruction).

After the control program's graphic attention routine has per-

formed its function of queuing the attention data, control returns
to the interrupted routine unless the routine for the attention
just queued was previously inactive. In the latter case, the new
routine receives control.

While in control, each attention routine processes the attentions

on its queue in the order in which they occurred, unless an ATTNINQ
macro-instruction within the routine requests the control program
to examine the queue for a particular type of attention. If any
attention on the queue does not meet the routine's entry require-
ments at the time it is dequeued, it is not processed and is lost,
unless it previously has been called for by an ATTNINQ macro-
instruction within the routine. ATTNINQ can also be used to clear
all attentions from a queue.
When an attention routine relinquishes control, (i.e., returns)
any attention remaining on its queue is serviced before the routine
becomes inactive.

The user programming required to interface with this type of

support is reasonably complex. An attention routine must be defined
by means of the SAEC macro-instruction, which establishes a Graphic
Attention Control Block (GACB) for the routine. In the GACB are:

(1) The address of the entry point of the associated attention

routine.

1059
 (2) The address of a Qata Qontrol ~lock (DCB) associated with
the device to be serviced.

(3) The address of a COMmunication AREA (COMAREA) to be used

to pass attention information to the attention routine.

(4) The types of attentions to be serviced by the attention

routine.

If an attention routine is to service attentions from more than

one device, or if multiple routines are to be available to service
attentions from the same device, a separate GACB must be established
to identify each device-routine combination.

Although defined, an attention routine is not available for use

until it has been "specified" by means of a SPAR macro-instruction.
This establishes control program references to it and, by means of
a priority designation, establishes its processing precedence in the
hi.erarchy of specified attention routines. (Technically, GACB's are
given precedence, not the routines; however, since it is common to
have only one GACB for each routine, one speaks of the priority of the
routine.)

Upon entry to an attention routine, the data control block and

communication area are made available. Using the information avail-
able in the COMAREA and the DCB, the attention routine can perform
necessary calculations, issue appropriate input/output macro-instruc-
tions, and do whatever else is required to respond to the attention.
If further communication from the display unit operator is required,
an ATTNINQ macro-instruction can be used to relinquish control or
enter a wait state until an appropriate type of attention occurs, or
to take a conditional branch based on availability of the appropriate
attention type(s).

The user has considerable flexibility to determine where the

attention processing (application-oriented processing, not attention
detection, queuing, etc.) is to be performed. There are two main
possibilities:

1. The user can set up the attention routines to merely feed

parameters to a background routine, which does all the work.

2. The attention routines can be programmed to do all the work,

while the background routine may be nothing more than a "wait
loop" until the console operator indicates that he wishes
to "sign-off."
Either scheme requires certain housekeeping functions to be
performed before attentions can be accepted. Likewise, certain tasks
must be performed in the attention routine itself.

1060
 Following is a brief outline of functions that might be performed
by a housekeeping/background routine and by an attention handling
routine (most typical of case 2):

Housekeeping Background Routine

1. Open the DCB for the display unit (required once).

2. Establish the attention routine by means of the SAEC and

SPAR macro-instructions (required once).

3. Issue input/output macro-instructions (eg., to create the

initial display).

4. Wait for posting of completion of graphic processing (case 2)

or perform background processing, which mayor may not be
related to the attention routine (case 1).

5. Close the DCB (once).

6. Indicate task completion by issuing the RETURN macro-

instruction (once).

Attention Routine

1. Perform standard entry functions: save registers, establish

addressability, etc.

2. Perform operations based on the attention information.

3. Issue input/output macro-instructions (eg., alter the display)

4. Wait for the next attention by means of the ATTNINQ macro-

instruction (or exit at this point).

5. After the last attention is serviced, (the console operator

is finished for this interactive sequence) post completion
and return control to the background routine.

Synchronization of the housekeeping/background routine and the

attention routine is the programmer's responsibility (case 2).
One method is to use the WAIT system macro-instruction to delay
exeoution of the housekeeping/background routine until completion
has been posted by the user's attention routine. The attention
routine passes control back to the housekeeping/background routine
by simply returning. Since completion has been posted, the house-
keeping routine is taken out of its wait state and execution contin-
ues. This cycle, the passing of control to the attention routine
when an attention occurs and the returning of control to the

1061
 interrupted (housekeeping/background) routine when completion is
posted (hybrid, cases 1 and 2) continues as long as the attention
routine is available and as long as attentions occur. A sample pro-
gram may be found in reference [9J.
The compiler language counterpart of basic attention handling, as
implemented in the Graphic Subroutine Package for FORTRAN IV, COBOL,
and PL/I [11, 23J is somewhat easier to use, though functionally no
more powerful. The queuing of processing of attentions is permitted
for sources which are explicitly enabled by the programmer. GSP
permits several enabled attention sources to be grouped into sets,
according to how and when they are used in the program. These sets
are called "attention levels". Only one level, called the "active
attention level" is able to accept attention information at any given
time. All other levels are called inactive attention levels. When
an attention occurs for an enabled source, attention information is
placed in the queue for the active attention level and processed as
directed by the programmer. The queued attention information contains
the identification of the source which caused the attention, and
other data as appropriate for the attention source. Once the atten-
tion information is queued, control is immediately returned to the
user's program at the point where the program was interrupted. The
program is not notified that an attention has occurred until atten-
tion information is requested by a call to a subroutine for this
purpose. When the use of an attention level is terminated, all
attention information in the queue for that level is deleted.

2. Language Extensions

For some reason, perhaps due to the difficulties inherent in compiler

modification, very little published work has been done in the integration
of graphically-oriented language facilities into existing compiler
languages. This may even be a more powerful approach than that to be
discussed next and at greatest length in this paper, but it is not yet a
very popular technique. S,1stems at this level may provide no facilities
beyond those available at levels la or Ib, but they provide a more struc-
tured framework for exercising those facilities.

One published example of this technique is the GRAF System (Graphic

Additions to FORTRAN). [8J GRAF's emphasis is on the definition of a
new type of FORTRAN variable, the "Display variable". Di splay variables
are named the same way as other FORTRAN variables, and must be declared
by the "Display" statement. Display variables permit the convenient
definition and output for display of graphic structures within the syn-
tactic structure of FORTRAN. In the area of attention handling, however,
GRAF reflects the limitations of the macro-level support used to implement
it. Since only low-level macros were available at the time of implement-
ation, the FORTRAN program is not informed that an attention has occurred
until and unless the information is specifically requested. Thus, GRAF
does not provide an elaborate method of handling attentions.

1062
 In GRAF, the DETECT function returns information about the occurrence
attentions. Its form is:

J DETECT (array)

The value of the function (J) indicates the type of attention, and
additional information appropriate to the particular type is returned
in the parameter array. DETECT may return with J - 0 if no attention
has occurred. A second function, DETAIN, has the same parameters and
sense as DETECT, except that it waits for an attention to occur before
returning.

The significant advantage of the system results from the ability to

correlate pen detects with display variables. This ability is provided
by another function, LPNAME. One of the parameters returned in the array
of DETECT or DETAIN function for a pen detect is an internal value associ-
ated with any of a number of named display variables. For example, suppose
the value is returned in the first work of the array. Then if the follow-
ing statements occurred in a program:

DIMENSION INQ(5)
DISPLAY s, T, U(5,4), W(7,3,5)
IB = PLOT (S, T, U, W)
J = DETAIN (INQ)

and a light pen occurred, then:

If T caused the detect

LPNAME (INQ (1), s, T, U, W) has the value 2 or

If U (2, 3) caused the detect,

LPNAME (INQ (1), s, T, u, W) has the value 3 and

LPNAME (INQ (1), S, T, U/I/J, W has the value 3, and

I has the value 2, J has the value 3

Thus, in general, the value is II if the detect occurred on the nth display
variable in the calling sequence.

The use of this function relieves the programmer of the task of keep-
ing track of all his display variables. In general, all the elements
which must be plotted, erased, or identified with the light pen as distinct
entities will be defined using distinct display variables or distinct
elements of an array of display variables.

A potentially much more powerful facility for the integration of

attention handling into a compiler language is represented by the ALGOL

1063
and PL/I "ON" statement. The ON statement specifies the action to be
taken for a particular as,Ynchronous interrupt or condition. For example,
the following type of statement is presently permitted:
ON OVERFLOW GO TO ERROR;
It is an obvious extension to add statements of the form
ON KEYSTROKE GO TO KEYSUB;

or

ON LIGHTPEN BEGIN;

statement 1

statement n
END;

As Johnson [12J explains, execution of the ON statement in such an example

would be equivalent to changing a table entry containing the branch
address for keystroke or lightpen action. Since the ON statements executed
within a given procedure are in effect only for that procedure, ~t is
possible to disable or enable specific attention types or vary the atten-
tion routines at various stages of the program. Johnson indicates that
he has implemented l::oth synchronous and as,Ynchronous versions of this
approach [13J.
Finally, Wolfberg [3lJ has described an interesting approach to the
problem of extending an existing compiler language to include graphical
capability. He defines the new S,Yntactic types which constitute the
language extension, and then provides a preprocessor which creates state-
ments to accomplish t.he desired task. Normal compilation follows pre-
processing. In this way the necessity to rewrite the compiler for the
existing language is avoided. The end result is at no higher a level than
the subroutine-calling levels of support already discussed, but the appear-
ance to the application programmer is that of graphic facilities integrated
right into the language syntax.

3. Development of Attention-Handling Languages

The last method to be considered for the specification of attention-

handling is the development of a special language for that purpose. Now
this is a very popular technique, so popular, in fact, that a ~roan may
arise when mention is made of a llilli special purpose language. There is
justification, however, for the development of a new language to operate
in a limited environment or satisfy a special need where no more-general

1064
language will suffice.

As was mentioned in the introduction, most of the work on language

development in computer graphics has centered on picture-definition
languages. Such languages run the gamut from primitive macros for coding
display commands through elaborate hierarchical organizations [3, 29J and
picture calculi [17J. All of the attention handling schema presented in
this survey have associated display-oriented facilities. Sammet [24J
presents a brief but representative survey of "graphical and on-line
display languages." Less work has been done on what might be called
picture-modification languages, or, more generally, attention-handling
languages, though interest in this area is increasing. It is convenient
to make a classification on the basis of whether such languages are
primarily graphical or primarily verbal.

a. Graphical Approaches
Some of the work on attention handling languages has focused on
languages which were themselves interactive or graphical, or both.
Flowcharts have been a popular area of investigation, with a number
of researchers desiring to specify programs by drawing their flow-
charts interactively [16, 21J. Most such systems are designed to
create programs for batch submission later. We should not consider
any of these systems as attention handling schema unless it is
possible to specify the interactive program itself graphically. One
system which is not truly an attention handling scheme will be briefly
discussed, because it is typical, has been widely referenced, and has
served as a basis for systems more within the scope of our discussion.

Sutherland has described a picture language [27J about programs

and an augmented graphic system capable of executing a program so
described. Sutherland's program allows operators to be graphically
connected to form a program in much the same sense as processes are
described for an analog computer. For example, the arithmetic state-
ment

might be represented graphically as follows:

b It

Figure 1

A variety of operator primitives or symbol terminals may be

defined. Symbol terminals may be classified by data type in a
manner similar to the declaration of data types in conventional

1065
written languages. Connections between terminals with incompatible
data types are disallowed (see below). The data type restrictions
and a restriction that connection lines be directed from output to
input terminals provide a rudimentary syntax for the pictorial pro-
gramming language.

1
CONNECTION IS ILLEGAL
(BOOLEAN- NUMERICALl Figure 2

The system allows a program to be developed interactively using

the available operators (new operators may be defined), and then
provides for its interpretive execution. Such a system is very inter-
esting, but must be classified as a graphical demonstration program
or an application.

Newman, however, chose to adopt the same type of philosophy for

describing the control program fora graphical device. [18, 19J
Newman's system uses the conventions of state-diagrams to describe
the processing to be done in response* to certain actions. The
essence of this method is to define for each state the responses to
allowable actions, and the next state entered. The example is given
of "rubber-banding" a line. This is accomplished in a sequence of
five operations:

1. Press button to start pen tracking

2. Track pen to starting point of line

3. Press button to fix starting point

4. Track pen to end point

5. Press button to fix end point and stop tracking

The "rubber-band" effect is effected by displaying a line from

the starting point to the current pen position throughout step 4.

The state diagram representing this sequence is shown below.

Only valid actions are included.
Such state diagrams may be developed interactively by using a
somehow preconstructed state-diagram to build state-diagrams, after
the fashion of bootstrapping, but it is often more convenient to have

*While in Newman's discussion [18J a "response" is a prompting message

displayed to the user, we shall use the term as it is more generally, to
rei'er to a program block, or in Newman's terms, an "instruction for
~ecution" (iex).

1066
 MOVE PEN

RESPONSE:
STORE Figure 3
STARTING POINT

a means of offline preparation. For this purpose, a Network Defin-

ition Language was developed. The state-diagram is described by
defining each state with a list of the branches from that state and
their properties. For example, the simple example just given could
be compiled as follows:

STAT 1 Comment: State definition, state 1

ACT 10 Branch definition, category

10 (button)

SE 2 State entry, i.e., branch leads

to State 2

STAT 2 State 2 definitions

ACT 7 Branch definition, category 7

(pen movement)

ACT 10 Branch definition; pressing

button leads to state 3

lEX STORPT Instruction for Execution:

STORPT is a subroutine to store
starting point

SE 3 Branch leads to state 3

STAT 3 State 3 definition

ACT 10 Branch definition; pressing
button leads to state 1

SE 1 Branch leads to state 1

ACT 7 Branch definition, pen movement

lEX DLINE Define a fresh line at eve~

pen movement

END

1067
 The language has been designed to avoid explicit references to
peripherals. As a result, the state-diagrams are largely device-
independent and compile into similarly device-independent programs.
The Network Definition Language does not even contain facilities of
its own for coding the procedures named in the state-diagrams. Rather,
it is intended to be used in conjunction with some procedure-oriented
language more suited to the required tasks. The result is an inter-
active program consisting of three separate components: the control
component, procedure component, and supervisor.

The supervisor contains routines for handling interrupts and main-

taining the display; at its nucleus is a program which analyzes and
interprets attentions. This component, called the Reaction Handler,
is basically a table-driven syntax analyzer. The tables to which it
refers are ring structures and include a model of the state-diagram
created by a compilation of the network definition.

Attention inputs to the system are treated on a logical, rather

than a physical level. The user defines what the acceptable inputs
are by means of a specially provided Category Definition Language.
A considerable degree of pre-processing of attention information may
be specified in this language to determine how such inputs are to be
treated (into which category they are assigned). Categories may be
as selective or as indiscriminate as desired; for example, a cate-
gory may contain inputs from more than one type of device (e.g. push
buttons and light buttons treated alike) or only some of the inputs
from one type of device (i.e., only some keys are "enabled" or only
light pen usage in a particular quadrant of the screen is permitted).
This ability to define special-purpose categories permits the very
flexible and efficient use or input devices. The Category Definition
Language has a structure similar to the Network Definition Language
and is likewise compiled into tables which are used by the Reaction
Handler.
The tables form the control component of the program. They con-
tain references to test routines, program blocks, and instructions
for execution, which constitute the procedure component and are
compiled separately. Attention processing is a form of syntax anal-
ysis whose goal is to match the attention to an entry in the
appropriate table. By providing primitives in the language corres-
ponding to the available attentions and by permitting any sort of
response to be coded in the procedure component, the system provides
an attractive scheme for conveniently specifying the course of
attention handling at a level somewhat above that of an assembly
language.

Engelbart and English [6J have also employed a state-chart repre-

sentation for control-language design. In this scheme, boxes on the
charts contain abbreviated descriptions of relevent display-feedback
conditions, representing the intermediate states between successive

1068
user actions. They have also developed a control meta-language
for describing such state-charts, and a translator which can process
such a description to produce a corresponding version of an inter-
active system which responds to user actions exactly as described.
The system appears to have been restricted to text and file manip-
ulation applications thus far.
As was mentioned previously, Sutherland's system is not a ff,Ystem
for attention-handling in the strict sense such systems had been
considered up to then. This is because the attentions mu£t actually
be analyzed at a lower level in the supervisor in order to implement
his scheme. This is not true in Newman's system, since the language
statements directly interrogate the attention sources at a logical
level, and the processing is directly driven by them. Thus, we may
freely consider this as a full-fledged, general purpose method
of attention handling. As such, however, it has its shortcomings,
though perhaps it was not ever intended as a comprehensive attention-
handling system.

The crux of Newman's system is the scheme for defining and proces-
sing state graphs, both defined interactively and through the Network
Definition Language. The system is most powerful when used to indi-
cate control flow, with the actual routines executed at each stage
almost an afterthought. (Indeed~Newman's claim is that need to
separate the control and the procedures). In particular, no attention
is paid to data structures or picture processing, and the scope of the
currently available procedures does not seem overly rich. On another
level of criticism, state-diagrams are not a method of representation
familiar to most programmers, although they are not difficult to
learn. It is not desired, however, to cast aside the state-graph too
lightly, for once understood, it does seem well adapted to specifying
the type of control flow desired for attention-handling processors.

Very limited work has been done in defining truly interactive

languages, that is, languages with operator actions included in their
syntax. Due mention must be made of I. E. Sutherland's SKETCHPAD L26]
which, though it was not a language, or strictly even an attention-
handling scheme in the present sense, demonstrated the potential for
interactive graphics. Licklider[15] lists a number of interesting
"twists of the wrist", including Sproull's* techniques for communi-
cating to the computer the angle of rotation as well as the position
of the lightpen ("literally a twist of the wrist"l) and the "scratch-
out" employed by a number of researchers [5, 25J to cause deletion
of a symbol or figure from memory. The only unified approach to the
problem has been taken by the AED project at MIT. The work is
grounded in D. T. Ross's algorithmic theory of language [22J, which
provideR the basis for automaticall~ constructing a compiler for a

*Personal communication with Ivan E. Suthe~land, 10 February 1968.

1069
specified language. The system can be applied to the graphics L14J
since it permits the intermingling of graphical elements (e.g.,u,~ of
particular keys or the lightpen) with verbal elements (e.g., +, -, for)
in the syntax of a single language. The AED system is not in wide-
spread use at the present time (perhaps due to its obstruse documen-
tation), so no more can be reported on this approach.
-b. Command Languages
The two systems to be described next satisfy both objections to
Newman's system: they are richer in the procedures and types of
processing which may be specified, and they are coded in a form more
familiar to most programmers. Both systems arose from a common
ancestor -- a graphic software study contract let by the Univac
Division of Sperry Rand Corporation to Adams Associates. The basic
requirement was to support a satellite graphics controller and termin-
al connected over a voice-grade telephone line to a large central
data processing system. The system was to have the twin goals of
providing an immediate and meaningful response to console operator
actions, while minimizing the load on the central computer. This is
an interesting and increasingly popular software problem -- to provide
sophisticated control procedures in a small computer of distinctly
limited capability, connected to a large central time-shared
computer.
The Adams Associates' report [lJ (an internal document not gener-
ally available) recommended a scheme whereby a basic monitor program
would be loaded in the graphics controller, along with an interpreter
for an attention-driven, graphically-oriented language. Programs
written in the language would be converted to a byte string in the
central computer (similar to a compilation process) and then trans-
ferred to the controller for interpretive execution as required. A
syntax and semantics for such a language was proposed.
From this base, two separate efforts emerged, both, incidentally
for the same customer: NASA's Marshall Space Flight Center. Computer
Sciences Corporation undertook to develop a system for the PDP-9/339
display system, and Univac, in a joint effort with Adams Associates
continued development of the system for the 1557/1558 Advanced Graphic
Display System. Both systems were intended to remotely access a
UNIVAC 1108 multi-processor at Marshall. The resultant systems are
functionally very similar, as is not surprising, but differ in many
details of implementation, as is also not surprising. What is some-
what surprising is the fact that the CSC system more closely resembles
the original Adams Associates system than does the final Univac-Adams
Associates system.
CSC System

The CSC system has been described in published literature [2J and
in internal programmer's reference material. An interactive Erogram-

1070
ming language, IPL, is provided, with a simple, event-oriented grammar,
consisting of structuring rules, instruction codes, and the logical
operators AND, OR, and NOT. Instructions are of two types: condi-
tional, used in forming BOOLEAN strings; and action, used in perfo~
ing tasks. The general format of statements in the language is

<N> IF <c ondi tional string) THEN (action string)

Where N may be a statement number to be used in a logical trans-

fer action command, the number of a software register for arithmetic
operations, or null. If the conditional string evaluates TRUE, the
actions in the action string are executed, otherwise they are ignored.
If the conditional string is omitted, the actions are unconditionally
performed.

The conditional string consists of any number of conditional

instructions separated by logical operators. In practice, the "IF"
is not required, AND, OR, and NaT may be represented by", ", "/",
and "-", respectively, and "THEN" may be represented as ".". The
codes are processed from left to right with ll£ operator hierarchy
inherent (and parantheses not provided in the syntax). The action
string is also composed of any number of action instructions,
separated by a concatenation operator (","). The action instruc-
tions are performed left-to-right in order of occurrence. Execution
of a statement terminates upon detection of a period.

There are, at present, about 100 instruction codes incorporated

in the language. The codes are grouped according to function in the
following classes:

1. Arithmetic - performs basic computational functions.

2. Auxiliary - perform logical transfer of program control, non-

sequential single-statement executions, establish state
parameter values, and assorted housekeeping functions.
3. Character - performs basic character manipulation within
text strings and handle teletypewriter input.

4. Definition - defines basic display elements: point, line,

etc.

5. Light button - defines,displays, and manipulates light

buttons.

6. Light pen - enables and disables light pen and control of

associated functions (blink, copy, move, scale, etc.)

7. Positioning - controls tracking and point (screen location)

designation.

1071
 8. Response buffer - permits programmed into a buffer and trans-
mission to central site computer.

9. Text-editing - controls cursor and text (line) manipulation.

The instruction set is open-ended. Because of the interpretive

implementation of the processor, new instruction routines are very
simple to add.

Features intrinsic to the system include a tracking routine,

cursor, pushdown program label stack, and automatic manipulation of
display items through a bit mask. Tracking is done with a displayed
cross and the light pen. The position of the tracking across is
always available to the program. Operator repositioning of the cross
can be programatically constrained and/or tested. The cursor is a
unique character which may be positioned by the program and/or by the
operator's use of the physical push buttons. Its principal use is in
text-editing and character manipulation. The push-down, pop-up label
stack provides automatic alternate execution paths somewhat like an
ASSIGNED GO TO in FORTRAN. Utilizing this feature, the programmer
may establish a number of execution levels within the program and
provide for response to operator actions without regard to the current
level of execution. At any given time, the top entry on the stack
automatically reflects the level of program execution. In addition,
a prompting message is associated with each stack entry providing
a method of program communication to the operator. Since this
message is displayed on the screen whenever the entry is brought to
the top of stack, it can be used to:

1. Give the operator instructions;

2. Inform the operator of the level of program execution; and

3. Verify to the operator that he is performing the desired
function.
A l2-bit mask associated with each display item controls functions
commonly desired with reference to a display item; i.e., hide, delete,
blink, copy, move, etc. Identification information is associated with
each item defined for the display. This ID includes a definition
mask, each bit of which corresponds in a set format, to one of the
above functions. In addition, a state mask variable is maintained
whose value may be set by the IPL program. When an item is picked
with the light pen, the definition mask associated with that item is
AND-ed with the program state mask variable; functions associated
with the bits set as a result of the logical product are automatically
performed on that item. In this manner, an item definition mask
establishes a set of permanently allowable manipulations for that
item, while the program state mask provides dynamic control over the

1072
functions to be performed by the system at any given time. Other
mask functions al~ow recording of item identification in the response
buffer, designation of an item as a light button, and binary control
of item light-pen sensitivity.

Use of the above features together with the IPL instructions which
control them provides the programmer with a high degree of interaction
and program flexibility in design of a graphics application.
Jtather than describe all the IPL commands in detail, a sample
program will be offered to give a feel for the flavor of the language:
Example of Tracking Cross Usage

1 PCT 0 = TPN, STR 25 25, SPP.

= GOT 2.

2 PLR = RTP, SPP, DRP

PCT 40 = CRB, RLR 1 2, RLR 2 J.

= STP.

3 PLR = RTP, SPP, DRV.

PCT 40 = CRB, RLR 2 1.

END

This simple program can be read as follows:

1 if Point Count is 0 then Track Pen, Set Range to
x = 25 and y = 25, Save
the Pen Position. Go to
Next Statement Through Soft-
ware Register 2 (indirect
addressing)
2 if Pen Logically Repositioned then Record Tracking Point,
Save Pen Position, Display
Recorded Points.
if Point Count is 40 then Clear Response Buffer, Reset
Software Register 1 to 2,
Reset Register 2 to J. Stop
Interpretation.
3 if Pen Logically Repositioned then Record Tracking Point, Save
Pen Position, Display
Recorded Vectors.

1073
 if Point Count is 40 then Clear Response Buffer, Reset
Program Logic.

END OF PROGRAM.

This program is interpretively executed by the executive once each

time the display picture is refreshed (for all practical purposes).
During the first pass through the program, no points have been pre-
viously stored in an internal buffer so the point count is O. Thus,
PCT 0 evaluates TRUE, so the tracking cross is displayed (TPN), an
invisible box (50 raster units square) about the center of the track-
ing cross is defined (STR 25 25), and the present tracking cross
position is saved by the system (SPp) to provide a test for
repositioning of the pen. The next statement is unconditional;
interpreter control transfers to the statement addressed by software
register 2 (which is automatically preset to contain its own number,
2). When the pen is logically repositioned by the operator (the
tracking cross is moved outside the invisible box), the center of the
tracking cross is recorded in the response buffer (RTP), and the
point is displayed (DRP). When 40 (octal) points have been thus
recorded (PCT 40), the buffer and the points being displayed are
cleared (CRB), the address of statement 2 is saved in register 1
(RLR I 2) and the address of statement 3 is saved in register 2
(RLR 2 3). Statement 3 is not executed since the interpreter exits
on the unconditional (STP) command. Once the point count reaches 40
and the content of register 2 has been altered, the execution path
resulting from the transfer (GOT 2) command skips statement 2 and
processes statement 3. Instead of displaying the points recorded in
the buffer (DRP), the vectors between those points are now displayed
(DRV). After 37 (octal) lines are visible (PCT is 40), the content
of register 2 is replaced by the content of register 1; i.e., the
address of statement 2 is put back into register 2 so that, on the
next pass through the program, the original execution path is resumed
(points are displayed instead of vectors). The END command has the
same effect during execution as the STP command; the interpreter exits.
This switching process continues for every set of 40 points defined.

The main objection to be raised to the IPL system is that while

it was intended as a terminal executive for a remote graphics con-
troller, the logical interface to any central site system has not
been designed (or if it has, it has not yet been published, and it
certainly has not yet been implemented). This would be no great
objection if the problem were merely to get the two processors "to
talk to each other," to exchange data, but the problem is much deeper
that that. It has increasingly come to be recognized that in the area
of computer graphics, "Data Structure is KING", [30J and it is in
this area that the IPL system has no facilities.

A variety of data struotures have been employed for computer

1074
graphics [7J. The justification for graphic data structures may be
very simply stated: data structures give meaning to points and lines.
As a very simple example of this, consider Figure 4. Figure 4a
indicates the end coordinates of a set of vector defining some graphic
image. Looking at the set of coordinates gives no insight into the
organization of the image. Figure 4b shows that same basic data
organized into a very simple data structure. Figure 4c shows the
graphic image represented in both cases. Certainly the organization
in Figure 4b is more perspicuous.

The other side of the data structure coin is also indicated in

Figure 4: data structures cost. The data structure in Figure 4b
required two additional cells of data than did the unstructured data,
modest overhead compared to some systems. Some applications might
require such a massive quantity of data to be displayed that use of
an elaborate data structure would saturate available storage. The
only reply that can be given to objections on these grounds is that
you don't get anything for nothing in this world, and that the
benefits have been found to justify the expense. As van Dam has
indicated [30J, the advantages and disadvantages of a data structure
may be listed side by side, each under the same general heading of
"flexibility" •
The last system to be described is the Univac system as it was
finally implemented. [28J This system meets the objections raised to
the IPL system in that it provides both a data structure and a logical
interface to be used in central site - satellite communications.
Because the attention handling facilities of the Univac system were
designed as an integral part of a 2-processor graphics system, some
appreciation of the design of that system, particularly as regards
the roles of each processor is required. Of equal importance is an

SQUARE
10,10

10,10 10,20

10,20 20,20

rn
20,20 20,10 (20,20)
20,10 TRIANG

15,10 15,10

20,15 20,15 (10,10)

15,20 15,20

a. End Points Only b. Data Structure c. The Image

Figure 4. Motivation for a Data Structure

1075
 -l
I
APPLICATION
I
I PROGRAM
I
I
I
I COMMUN-
...._ - I - J ICATIONS
ENTITY
TABLE
EXECUTIVE ... .,.. -------+-+~
"'--+-r- - ---, I
I
HANDLER
I ~__~__~~~
I
I
I
I
I GRAPHIC
I
PROGRAMMING
( paging) I
LIBRARY
I
I
....I--+_J CENTRAL COMPUTER
a. Central-Site Organization

INTERACTION ( Interrupts)
CONTROL TABLE
INTER- INTERPRETER
ACTION
CONTROL
TABLES

COMMUN-
ICATIONS II I L. ________ _

HANDLER
- l.--t-- -::~~~~O~_-:
i

DISPLAY FILE
CONTROLLER

DISPLAY (cycle stealing)

FILE I--------~--~*

DISPLAY CONSOLE
SATELLITE PROCESSOR
b. Satellite Organization

Figure 5. Graphic System Organization

1076
explanation of the graphic data structures on which the system oper-
ates. Such explanations may best be gleaned from a previously
published description [3J, of which a brief summary will be presented
here.

The hardware on which the system is implemented consists of a

satellite graphics controller which drives a CRT display and services
operator inputs, remotely connected to a large, time-shared and possi-
ble multi-programmed central data processing system. Figure 5a and b
show the software system organization at the central site and in the
satellite respectively. All runs begin with the application program
at the central site. Via the Graphic Programming Library (GPL) of
service routines, a graphic data base may be constructed and manip-
ulated. Data structures at the central site are hierarchically
organized and represented in so-called "user coordinates" (in floating
point). Such graphic operations as windowing and scaling are auto-
matically applied when a portion of the data base is delimited and
selected for display. The scissored and appropriately scaled portion
of the data base is then transmitted to the satellite controller,
where it is retained in the "structure file", in a format which is
descriptive (not yet a display file) but which is related to the
screen characteristics (coordinates expressed in raster units). A
routine in the satellite known as the Display File Controller then
builds the display file of hardware commands for the scope from the
descriptive information in the structure file.

The ability for the programmer to specify the processing to be

performed by the satellite in response to attentions is provided (as
for the CSC system) via a higher-level language, called the Inter-
action Control Tables, which are "compiled" in the central processor
but interpretively executed in the satellite. The Interaction
Control Tables, which were processed at the central site to con-
vert them from symbolic to binary form, are also transmitted to and
stored at the satellite (as memory availability permits). Whenever an
attention occurs, the Interaction Control Table Interpreter makes one
pass through whichever table was designated as the "master" table.
Attention-handling is strictly local to the satellite until such time
as a message is composed by the ICT's and transmitted to the central
site.

The data structure with which the system works, both in the central
site and at the satellite, is a hierarchically organized system of
groups (masters) and uses of groups (instances). The groups and uses
constitute an organizational structure only, with the displayable data
being contained in structures called items which, along with uses of
other groups, constitute the data within a group. Conceptually, we
have a directed graph structure whose heads are the groups, whose nodes
are positioned uses of other groups, and whose terminals must be items
in order to contain any actual graphical data. Figure 6 illustrates
this concept (For a more complete discussion see references [12, 13J).

1077
 Interaction Control Table syntax is somewhat more powerful than
that for the IPL system. Commands are of two types, interrogatory
commands which determine the truth value of a statement or phrase,

b. Picture Elements

--1r---
a. Meta-Linguistic Symbols

C> o
---'\IVY-
RESISTOR CAPACITOR

GROUP USE ITEM

FILTER
SUPER FILTER
c. Directed Graph Representation

Figure 6. Directed Graph Representation of Picture Organization

and action commands, which are performed so long as the truth value
is true. Statements are preceded with a period (.) which initializes
the truth value to TRUE. The "not" operator ('-.) may be used to
change the sense of an interrogatory command. There are two types of
statements: basic statements which do not contain alternative clause~
~nd complex statements which do. Basic statements are simply strings
of action and interrogatory commands. The commands are performed so
long as the truth value of the statement is TRUE. Whenever an inter-
rogatory command causes the truth value to become FALSE, all subse-
quent commands, including interrogatory commands, are ignored until
the next start of statement (period). The truth value cannot be
chwged back from FALSE to TRUE in a basic statement. Some examples
of the form of basic statements follow, where "A" represents any
action command, and "Q" any interrogatory command:

• A (A performed l'Dconditionally)
• QA (A performed iff Q is TRUE)
· Al Q A2 (AI performed unconditionally)
(A2 performed iff Q is TRUE)

1078
 • Ao QI Al Q2 A2 (Ao performed unconditionally)
(AI performed iff QI is TRUE)
(A2 performed iff QI and Q2 are both TRUE)

Complex statements consist of two or rnore basic statements (with-

out periods) as alternative clauses separated by an "or" delimiter
(/), followedbyafinal basic statement as an object or "then" clause
separated by an object or "then" delimiter (=). Each basic statement
clause is executed as described above; however, the following addi-
tional rules apply to the statement as a whole:

1. Each "or" delimiter will reset the truth value of the

statement to TRUE if it had been declared FALSE.

2. rf the truth value of an alternative clause remains TRUE

for its entire execution (wltil an "or" or "then" delimiter
is reached), execution of the statement shall continue with
the object clause.

Thus, the object clause is executed if any of the alternative

clauses are TRUE, and is not executed only if all alternative clauses
are FALSE. This type of a syntax permits rather complex logic to
be coded in a single statement, as illustrated in Figure 7.

The Interaction Control Tables for each application program

(corresponding to a unique display console) have available 65 soft-
ware registers which serve as a virtual memory for the rCT programs.
All console registers may be referenced at will l'y those lCT commands
which require registers to be specified. Certain registers, however,
are implicitly addressed by particular reT commands, and certain
registers serve as interface registers between console attentions and
the ICT programs. The contents of these registers Day change without
a direct reference to them, so they may not be used for long term
storage (storage from one attention to the next).

In addition to the console registers, a pushdoWIl list with a capa-

city of fifteen words (an arbitrary, easily-changed value) is provided
for those ICT commands which search data structures or refer to a
structure's genealogical identification. The pushdoWIl list is not
directly addressed, but is implicitly accessed by those leT commands
which examine or alter it. The pushdoWIl list may only contain struc-
ture identification codes.

The Interaction Control Table repertoire includes a smaller

number of generally more powerful commands than those provided by the
IPL system.

Interaction Control Table commands include the following

capabilities:

1079
 . NODE,5 A1 Q1 A4/ A2 Q2 A5 /A3 GO,10 = At) Q3 A1
. NODE,6' ..

A1

YES
A4

A2

YES
A5

A6
A3
GO,10

YES
A1

Figure 7. Complex Logic May Often be Coded in a Single Statement

• Arithmetic and logical capability using software registers for

the retention of results,

• Ability to transfer control conditionally within an Interaction

Control Table and to other Interaction Control Tables

• Ability to decode keystrokes and to react to timer expirations

• Control of light pen tracking and picking identification and

feedback

Definitional capability for points, lines, text and conics

1080
 • Facilities for obtaining the complete genealogy (hierarchical
identification) of an entity in the data structure, as well as
the identification of its type

• Ability to search the data structure either horizontally (within

a group) or vertically (from parent to dependent entity)

• Ability to define new entities and alter existing entities,

including the ability to reposition entities and to turn them
on and off

• Ability to record data into report blocks for transmission to

the central computer, and to initiate this transmission

There are presently about 70 ICT commands implemented. They are

grouped into functional classes and summarized as follows:

Interrogatory Commands

Interaction Control Table Interrogatory Commands permit the user

to determine the source of an attention and to direct the course of
ICT execution accordingly. A separate interrogatory command is pro-
vided for each attention source or type. (A single physical input
device such as a light pen may be a source of more than one type of
attention, as for example, picking and tracking.) Arithmetic compar-
isons may also be made between software registers and on bits within
registers.

For example, the following command will test whether the leT
interpreter was invoked as a result of the key labeled "A" having
been struck:

KEY, 'A'
Likewise, the following command yields TRUE if software registers
10 and 11 are equal:

REQ,lO,ll

Control Commands

Control commands allow an Interaction Control Table to invoke

sub-Interaction Control Tables, and to vary the execution flow within
itself and within other Interaction Control Tables. Used in conjunc-
tion with the interrogation commands and/or th~s:h~act~:rist:!.cs of
the top of the pushdown list, the control commands offer the pro-
grammer the ability to specify the amount of processing to be
performed in the satellite processor.

For example, the NODE command (which must immediately follow a

1081
"." start-of-statement) establishes a logical address to which GO
commands may refer. In the following ICT fragment, control passes
to node 4 if the key "A" is struck, otherwise it continues with
node J:

.Key, 'A' GO, 4

.NODE, J ...
• NODE, 4 ...
The XTABL command transfers control to another table as a sub-
routine call. The EXIT command causes a subroutine exit. If the
"master" table executes an EXIT, the ICT interpreter is dismissed for
that attention.

Attention Control Commands

Under the ICT philosophy, attentions are logical, rather than

physical interrupts, which the ICT programs must analyze and act
accordingly. When such an attention occurs, internal flags are set
in the remote monitor, and the master ICT for the particular console
is initiated. The internal flags are examined by the interrogation
commands which test the various possible attention sources. Atten-
tions can occur from the following sources:

Central site processor

Timer expiration
Keyboard entry
Light pen picking
Light pen tracking

CentraJ.qinitiated and keyboard attentions may not be "controlled" as

such, but may be ignored simply by taking no action in the Interaction
Control Table in response to them. Explicit control is provided, how-
ever, for the other attention sources.

Control over the interval timer is accomplished by a command which

loads an initial value into the timer. When the timer expires, an
attention occurs.

Control over light pen picking is accomplished by two commands

which logically enable and disables the pen for picking. Pen detects
will only be processed on structures defined as valid light targets.

Control over light pen tracking is independent from light pen

picking. Tracking may be enabled while picking is not. Tracking is
a logical function of pen motion in that a range may be established
about the present position of the tracking cross. Only when the cross

1082
is moved beyond this range is an attention generated.

Light pen picking and tracking are important and complex oper-
ations, and are discussed in greater detail following this summary
section.
Arithmetic Commands

Arithmetic commands provide the standard arithmetic operators for

the manipulation of the console registers. Other data from the atten-
tion sources and the data structure are also available for manipula-
tion in the console registers.

For example, the following command subtracts the contents of

console register 11 from console register 10 and stores the result
in console register 12:

SUB,10,11,12

The result may be copied from console register 12 to console

register by the following:

STR,12,lJ

Similar commands permit addition, multiplication, division,

double register transfers, and the setting and cleaning of individual
bits in registers.

Structure Identification Commands

Structure identification commands are designed to permit the

identification of times detected by the light pen, but they also may
be employed to search the satellite data structure in any arbitrary
fashion. As the data structure is searched, the genealogy of the
present position is retained in the pushdown list (PDL). In the case
of light pen detects, this genealogy may be made immediately available
for the particular instance of an item sensed by the pen. Further
explanation on the correlation of light pen detects with the data
structure is given in the discussion of the use of the light pen.

Note that it is the structure file, not the display file, which
is searched by the ICT commands. The organization of the structure
file parallels the data structure at the oemtral site.

The DW command initializes the PDL to the first drawing window

defined on the screen face. The PUSH command allows dependent struc-
tures (uses and items) to be accessed, while the contrasting POP
command permits returning to parent structures. Structures at the
same level in the data structure (for example, the several uses and

1083
items which comprise a single group) may be accessed by the RING
command.

Figure 8 following, gives an example of these commands used to

move from one structure (X) to another (Y)

Figure 8

Following a light pen detect on a structure, the ROOT command

may be employed to define a pushdown list representative of the par-
ticular item instance picked. The PDL is defined just as if the
structure had been reached by the minimal sequence of DW, PUSH, and
RING commands. The PICK command is identical to ROOT, except that in
addition, it returns the coordinates of a point on the structure with-
in the light pen field of view into two console registers. Since this
information is not provided automatically by the hardware, it is
obtained by the software technique of re-displaying the locus of
points comprising the structure until a second light pen detect is
obtained.

Structure Modification Commands

Structure modification commands permit additions or deletions to

be made to the data structure of the satellite processor. Existing
structures may be modified or new structures may be defined. Either
the structure file of the display file or both are affected. All
modifications are strictly local to the satellite and do not alter
structures in the central site. Thus, the satellite memory may be
used as a scratch pad to view alterations before they are actually
made in the central data structure. The facilities of the report
blocks may beem~oyed to notify the graphic application program of
any changes to be made to the Entity Table. These changes could then
be made using the appropriate PI subroutine. An example of structure
definition is given with the discussion of light pen tracking.

Whenever structures are added or modified at the satellite, a

routine is invoked in the monitor to perform any required scissoring.
If sufficient information is available in the structure file, it may
be possible to perform scissoring without reference to the centnisite.
:If, however a complete description of all structures is not available in
the structure file, a request must be made to the graphic system in the
centralsitetoprovide the necessary information. This request is made
automatically by the monitor.

1084
 Display Aid Commands

Display aid commands provide programmable assistance for the con-

sole operator in a number of ways. Construction points are labeled
dots displayed under ICT control which are not part of the data
structure. These points or dots may be used for the definition and/or
positioning (under ICT control) of graphical entities on the face of
the CRT. A cursor box may be manipulated for text operations. Feed-
back is provided in the form of blinking of selected structures.
Feedback of items may be defined for all or only particular instances.
Likewise, structures may be selectively blanked or displayed without
reference to the central site.

For example, if the light pen is used to pick one of the resist-
ors in Figure 6, it may be fed back by blinking by the following code:

Roar ONE FLASH

If it were desired to feed ba.ck the entire filter, a structure

identification command could be added:

Roar POP ONE FLASH

Report Block Commands

Report blocks provide for the transmission of information about

the console user's actions from the satellite to the central computer.
Report blocks are built in response to Interaction Control Table
commands, and only transmitted to the application program at the
direction of the Interaction Control Table. Report blocks allow
accumulation of data to form a logical, comprehensive set of para-
meters for application program execution. By deferring application
program activation until a complete message is ready, this approach
should keep conversational overhead to a minimum.

Actually, report block information is not simply allowed to

accumulate in the satellite until the report block is terminated
and sent. Sim e memory i s at a premium in the sa telli te , and in order
to decrease the amount of transmission which must actually be per-
formed when the completed report block is requested to be sent, a
report block buffer is provided in the satellite which is flushed and
transmitted to the central site whenever it fills. A completed
report block, however, implies a report block header and terminator,
indicating a complete logical message. While the report block may be
transmitted in fragmented physical segments as it accumulates, it is
not made available to the applications program until a complete logi-
cal report block is built and sent by the SEND command.

The following types of information may be recorded into a report

block by the Interaction Control Tables: constant values, software

1085
register contents, pushdown list contents (genealogy of an entity),
coordinates of a particular point, text, and new use and item entries.
This information becomes available to the graphic application program
in a general parametized form which the application program can employ
to reconstruct the actions of the display console operator which the
Interaction Control Tables were programmed to record. Based on this
information, the application program may alter the data structure in
the central computer to reflect the current status of the image on
the tube face. Thus, the report block facility provides a path for
the console operator to express his wishes to the graphic application
program.

For example, the following code could be used to report the

coordinates of a point selected by the light pen back to the appli-
cation program:
'TARGEr PIck STD,4,10 RPT SEND
The TARGET interrogatory command insures that this code is only
executed in the event of a light pen detect. PICK creates a PDL
representative of the structure on which the detect occurred, and
stores the coordinates of a point under the pen into console registers
4 and 5. STD ("store double") moves these coordinates to registers
10 and 11, from which they are recorded into the report block by the
RPT command and sent by the SEND command.

Light Pen Picking

Light pen picking refers to the identification of an image by
detecting it with the light pen. Interaction Control Tables permit
the user to identify the picked image to any desired degree of detail,
while relieving him of the responsibility for correlating the infor-
mation provided by the pen detect interrupt and the graphic data
structure himself.
The remote monitor only accepts pen detects on those entities
whose attributes designate them as acceptable targets. In addition,
the light pen must be logically enabled for detection. This is the
case when a particular console is initialized, but may be changed by
the TARG¢F and TARG¢N commands. When an acceptable detect occurs,
certain status inform~tion is retained in the monitor within access
of the ICT interpreter, and an attention is generated, which invokes
the master Interaction Control Table. Certain ICT commands may then
be employed to identify the detected image.

As described previously, the R¢¢T command initializes the pushdown

list to represent the particular instance of the item picked. In
addition, the identification of the item is stored in a console
register, as are component number and character number, if text.

1086
 With the PDL thus defined, the ¢NE and FLASH commands may be
used to provide feedback in the form of blinking of the item instance
picked. Interaction Control Table response is sufficiently rapid so
that if this is one of the first commands executed, the feedback will
appear to be instantaneous.

In some cases, the identification of the selected item is not

enough -- what is desired is the exact location of the pen on the CRT
face. This information may be obtained by using the PICK command
described previously.
With the identification of the item selected available in the PilL
and console registers, to the level of detail of component, character,
if any, and pen position, all the information which a pen detect may
provide is now available and may be employed in any fashion by sub-
sequent leT commands.

Light Pen Tracking

Light pen tracking refers to the process whereby a special symbol,

typically a tracking cross is programmed to follow the motion of the
light pen across the tube face. ~ttentions may be generated when the
tracking cross is moved a certain distance or is not moved a certain
distance (e.g., tracking stops). When an a:t,tention is generated, the
current position of the tracking cross is made available for any use
desired.

Monitoring of the tracking cross so that it follows the light pen

is performed automatically by the graphic system. Tracking attentions
however, occur as a logical function of pen motion which is under
programmed control. A range is established such that a tracking atten-
tion only occurs when the cross is moved a certain amount along either
axis.
Pen tracking techniques have been found to be most valuable in
the implementation of sketching facilities. The following Interaction
Control Table fragment gives an example of tracking used to rubber-band
a line from the origin of the item at the top of the pushdown list;

*** STRIKE 'T' F¢R 'TRACK' T~ START TRACKING ***

• KEY, 'T' = CONST,25,23 ***RANGE = APPROX t INCH***

TRK~N *** DISPLAY CR~SS WHEREVER REGS 8, 9 INDICATE·***
~RGXY,lO POINT,l STD,8,lO P~INT,2 LINE
*** DRAW LINE FR¢M ITEM IN PDL TO CR~SS~HH~
CLEAR,l CLEAR,2

TRKED = STD,6,lO POINT,2 REPLAC LINE CLEAR,2

*** LINE REDEFINED T~ F~LL~W MOVEMENT ¢F CR~SS ***

1087
 Figure 9
A range of approximately til is established by loading the constant
25 (raster Units) into a defined console register (#23). The tracking
cross is displayed at a screen position defined by the contents of
console registers 8 and 9 for X and Y respectively. These console
registers are continuously updated to reflect the current position of
the pen. Construction points are always drawn at an X, Y position
defined by console registers 10 and 11. The clear command erases con-
struction points. The ORGXY command obtains the origin coordinates
for the structure at the top of the PDL and stores them into selected
console registers. The REPLAC command causes the following LINE
structure definition command to replace the last line, rather than
add a new line.
The ICT advantages of providing a data structure as well as
satellite - central site communications have already been mentioned.
By way of comparison with the IPL system, the ICT syntax is more
powerful and the mnemonics somewhat more perspicuous" since they are not
limited to three characters in length. There are less commands in the
ICT system, but these are each generally more powerful than the IPL
commands. This would seem to make for easier programming. The system
is operational and has proven to be a viable system for attention
handling. Its most serious shortcoming is the lack of usable debug-
ging aids.
CONCLUSIONS
Now that the survey of existing attention-handling systems is completed,
it would perhaps be appropriate to try to draw some conclusions. The first
of these is that the lack of really workable, easy to use, powerful and
general facilities has certainly been a major factor in delaying the boom
in computer" graphics which was predicted some years ago. A second con-
clusion is that ~ of the methods surveyed provides the final solution.
~~cro and subroutine liberties are the most commonly available support, and
simply are not adequate. The special languages just described are experi-
mental only, and not too widely used. The attempts at integration into
existing languages appear to have been interesting projects which were
attempted, results published, and then abandoned. No attempts at standard-
ization appear to be in the works.

State-graphs are a useful complement to flow charts in representing

the attention handling control flow, but it is not expected that they will
become a popular means of actual programming. As was suggested in the
section on compiler languages, it is this author's opinion that the best

1088
solution lies in the integration of attention-handling facilities into the
syntax of existing, standardized programming languages. It is this author's
further opinion that languages with a block structure are the best can~­
dates for this integration. Facilities already exist in some of these
languages for specifying asynchronous processing.
Additional work appears required in the area of satellite processor
systems, to provide some convenient means of specifying the processing to
be performed in each machine. The main objection to the special purpose
languages is that they require a bi-linguality in programming which ought
not to be required. An advantage of a uni-lingual system would be that
programs could be run on either main-frame driven or satellite display
systems without modifieations.
But until such time as more flexible software facilities become
available, the special-purpose languages, and especially the ICT system,
offer the most complete and general support for programming the attentio~
handling process.

BIBLIOGRAPHY

1. Adams Associates. Report on Graphical Programming language.

Delivered to UNIVAC, Division of Sperry Rand Corp., August, 1967.
2. Conn, C. G. and P. T. Hughes. "An executive for a remote interactive
graphics terminal". DECUS Fall Symposium, 1968, pp. 169-174.

3. Cotton,!. W. and F. S. Greatorex. "Data structures and techniques

for remote computer graphics". Proc. FJCC, 1968, pp. 553-544.

4. Digital Equipment Corporation. Small Computer Handbook. Maynard

Mass., 1969.

5. Ellis, T.O. and W. L. Sibley. "On the development of equitable

graphic I/O." RAND Corp., Santa Monica, Calif., July 1966, 12 p.
(Report No. P-3415) (AD-637 781)
6. Engelbart, D. C. and W. K. English. "A research center for
augmenting human intellect." Proc. FJCC, 1968, pp. 395-410.
7. Gray, J. C. "Compound data structure for computer aided design."
Prec. ACM National Conference, 1967, pp. 355-365.

8. Hurwitz, A. and J. P. Citron. "GRAF: Graphic Addi tiens to FORTRAN".

Proc. SJCC, 1967, pp. 533-557.

9. IBM Corporation. IBM System/360 Operating System Graphic Programming

Services for IBM 2250 Display Unit, Form C27-6909, International
Business Machines Corp., White Plains, N. Y.

1089
10. IBM Corporation. GPAK - An on-line Systeml360 graphic data processing
subroutine package with realtime 2250 input and display. Version II.
International Business Machines Corp.,~ite Plains, N.Y.

11. Subroutine
Inter-

12. Johnson, C. I. "Principles of interactive systems." IBM Systems

Journal, 1 (3 & 4), 1968, pp. 147-173.
13. Johnson, C. I. "An experimental PL/I extension for graphic program-
ming." IBM Cambridge Scientific Center Report 320~2025, International
Business Machines Corporation, Branch Office, 1968.

14. Lang, C. A., R. B. Polansky and D. T. Ross. "Some experiments with an

algorithmic graphical language." MIT Electronic Systems Laboratory
Technical Memorandum, Cambridge, Mass., August, 1968. (ESL-TM-220)

15. Licklider, J. C. R. "Man-computer communication." In Annual Review

of Information Science And TechnologY (Vol. 3), Encyclopedia Britannic~
Inc., Chicago, Ill., 1968.
16. Michener, J. "Flowchart Programming System." In Progress Report for
the Period May 1 to August 11, 1968, for International Business
Machines Corp. TData Processing Division).
17. Miller, W. F. and A. C. Shaw. "A picture calculus." Emerging Concepts
in Graphics, University of Illinois, Urbana, 1967.
18. Newman, W. "A system for interactive graphical programming". Proc.
SJCC, 1968, pp. 47-54.
19. Newman, W. "Definition Languages for Use With the Reaction Handler".
Centre for Computing and Automation, Imperial College, England, October,
1967.

20. Ninke, W. H. "A satellite display console system for a multi-

access central computer." Proc. IFIP Congress. Edinburgh, 1968.

21. Richardson, F. K. Gra~hiCal Specification of Com utation.

University of Illinois Department of Computer Science, Urbana, Ill.,
1968. (Report No. 257).

22. Ross, D. T. An Algorithmic Theory of Language. M.I.T. Electronic

Systems Laboratory, Cambridge, Mass., Nov., 1962 (ESL-TM-156).
2.3. Rul1y, A. D. "A subroutine package for FORTRAN." IBM Systems Journal.
1, (.3 & 4), 1968, pp. 248-256.

1090
24. Sammet, J. E. Programming Languages: History and Fundamentals.
Prentiss-Hall, Englewood Cliffs, N. J., 1969.

25. Stotz, R. H. and T. B. Cheek. "A low-cost graphic display for a

computer time-sharing console" Project MAC and Electronic Systems
Laboratory, M.I.T., Cambridge, Mass., July, 1967. (ESL-TM-3l6)
26. Sutherland, 1. E. "SKETCHPAD - A man-machine graphical communication
system." Proc. SJCC, 1963, pp. 329-346
27. Sutherland, W. R. "On-line Graphic Specification of Computer Pro-
cedures". M.!.T. Lincoln Laboratories Technical Report 409, May,
1966.
28. UNIVAC, Division of Sperry Rand Corp.
Display System - Programmers Reference Manual.,

29. van Dam, A. and D. Evans. "A compact data structure for storing,
retrieving and manipulating line drawings." Proc. FJCC, 1967,
pp. 601-610.
30. van Dam, A. and J. W. Brackett. Lecture Notes: Interactive Computer
Graphics. Cybex Associates, Inc., Great Neck, N. Y.

31. stem. University of

School, Philadelphia, Pa., 1969~ (Technical

1091
 PART 12

Computer Generated
Geometric Shapes
 INTERROGATION TECHNIQUES FOR
PARAMETRIC SURFACES

M. A. Sabin
B. A. C. Weybridge

Mathematical Services, B.A.C., Weybridge, Surrey,

England.

The British Aircraft Corporation has a ~ofting system c~~ed the

'Numerical Master Geometry' (NMG), which has been in production use for
3t years. The surfaces used are ve~ similar to those used in the
Boeing Master Dimensions system «(1)) except that B.A.C. uses the 'corner
twist' vectors «(2)) «3)) to get continuity of curvature across the
mesh lines.

To describe this aspect of the system wou~d be to repeat what is now

more or ~ess common knowledge, but there is another side, which has been
surprisingly underreported in the ~iterature. This is the question of
getting information about the shape into the form required for subsequent
stages of the design process and for manufacture. B.A.C. calls this the
'interrogation process' and has spent some considerable effort making
simple, reliablemd general algorithms to calculate the various practical
requirements.

The facilities implemented are listed in the Appendix; the more

important are illustrated in the Figures.

EXAMPLES
The 'aircraft' shown in Fig. 1 took about 1~ to 2 hours to design,
using paper and pencil.

The fuselage is main~y circular in cross section except that the

underside has a bulge for the undercarriage near the trai~ing edge of the
wing. This bulge is smoothly faired in as may be seen from Fig. 2.

Fig. 3 sh~ws a perspective view looking over the second pilot's

shoulder, and again shows the non-circulari ty of the sections (if one
looks closely).

Also visible are the canted frames at the back of the fuselage, seen
in side view in Fig. 4.
1095
 <C

t
1096 ~
o
-
>-
...

W
1--1
>
o
z
w

w
(f)
0
Z
LL
0
~
W
1--1
>
0
Z
W
1097
INTERIOR VIEW OF FUSELAGE
SHOWING:-FRAMES
CANTED FRAMES
AND WING INTERSECTION
3

1098
 These frames couple the fin loads into the structure and typiCally
have cutouts where the stringers (the fore and aft lines) pass through.
For the detailed design of the frame to proceed, information is required
about the shape of the outside profile and of the cutouts as drawn in
Fig. 5. The skin thickness and stringer dimensions have here been
exaggerated by a factor of about 20 to make them visible.
Wings are usually designed in terms of fore and eft sections,
because, to a first approximation, that is the way the air flows.
Fig. 6 shows these sections; the change in shape from root to tip is
fairly evident.

To make this wing, though, needs the shapes of its spars and ribs.
Figs. 7 and 8 show the structure in plan and perspective views. Two
spars run outboard along lines which cannot be made isoparametric
because they are chosen quite a while after the surface is 'frozen'.
Main ribs run more or less perpendicular to the rear spar and leading
edge ribs perpendicular to the forward spar. This structure is
considerably simpler in detail than actual wing structures, but
demonstrates the kind of capability needed to produce the actual shapes
of the ribs (Figs. 9 and 10).

Another requirement for manufacture is the developed shape of each

skin panel, so that they can be machined in the f~at, formed to the
correct profile and will then fit together accurately when assembled.
Fig. 11 was generated by an algorithm which will only be bettered by a
full structural analysis of the deformation of the panel during forming.

An important design calculation relates to fuel volumes and levels,

and plots of the kind shown in Fig. 12 are required for a variety of
aircraft attitudes. This was obtained by taking a set of horizontal
sections through the wing (Fig. 13) and integrating the areas progressively
against depth to give VOlume. }olig. 12 is a fake to the extent that the
area and volwne figures were taken from the printout normal~ produoed and
re-input to a general purpose plotting programme to make the plot.

Fig. 14 shows the wing in two distorted positions. The aotual

distortions (not usually this large) for the various flight load
conditions can be estimated within a few percent. The signifioance of
this slide is that each distorted surface is handled as a surfaoe in its
own right; the fuel volume algorithm can be applied just as easi~ as to
the basic surface. By applying two distortion fields wind tunnel models
can be made which distort under tunnel forces to the same shape as the
real aircraft in flight.

Finally, Fig. 15 shows a perspective view of the rear of the

fuselage and the wing. Visible in the surface of the wing is the
reflection of the fuselage; visible in the fuselage is the reflection of
the wing. The gaps in the reflections in the wing are Where the
algorithm failed. It has only been used twice in the last three years
and has not been subject to the foolproofing and tuning which have been
applied to the more important algorithms.

1099
 (f)
a::
w
~o
WZ
r-~ 1--1
>0:::
~
W (J)
o
1--10
(f)Z
<C
(J)
l.iJ
w~
0<C
<C 0:::
---1 LL
W
(j) 0
:J Lu
LL t-
Z
LL<C
OU

1100
 !he si!houette proces8, which was intended to have supplied a line
aloDg the leading edge of the wing also failed (in the region wi. th high
rate of change of ourvature near the tip) for the same reason.
!be author implemented these faoilities as a ohallenge rather than
because of their usefulness, (although there was a suggestion that
aiihouettes and reflections woUld be a powerful test of fairness) but they
do illustrate the power of the parametric surface S,Ystem. The equations
tor the reflection, which wou~d be extremely cumbersome in tradi tl.onaJ.
ooordinate geometr,y becrmes ver" terse and elegant in vector form
d( 11(14,") - ~ + j1>(IA,v} - £ J)/dL4.,V : 0

where Q is the point being reflected

E 18 the eye point
p(u,v) 1s the point of reflection
and Ivi is the magnitude of vector V.
The algorithm itself is essentially the same as the inner loop of
the pl8D8 8ection algorithm described below.
Theae diagrams have illustrated some of the graphical outputs
required frOil a surface system. There is also a great deal of printed
output, but of more interest is the output in the form of machined
aurfacea; wind tunnel models cut by numerically controlled (NC) machine
toola.
Here we have three practical constraints. The first is the cost of
BC machine time. While it is quite possible to remove the unwanted
material by running the finishing tapes 'high' or b, manually machining,
the most coat-effeotive solution is to use special roughing tapes to
drive a square cornered cutter at something approaching the theoretical
maximum metal removal rate. This involves driving the cutter horizontally,
along plane sections rather than isoparametric lines, and is illustrated
in liga. 17, 18 and 19 where billets are being roughed. The contours and
the shape of the cutter.are both visible.
The second constraint is that a model is much more complex than a
aingle surface, and that straightforward parameter line cutting is not
quite adequate, even for finishing.
The test piece shown in Fig. 16 demonstrates the need for bounded
outting, using one surface to limit the machining of another, and the
need for cutting along the intersection of two surfaces.
The third is that models have to be made quickly, and that long
programming times are unacceptable. Use of NC machining, culminating in
the use of the facilities mentioned here, has progressively reduced the
tiae taken to plan and make a model, despi te the fact that
modela, once made of wood, are now usually of light alloy, sometimes of
ateel, and are now being made to much closer tolerance. This is cost
effectivene8s, beoause the making of wind tunnel models is often on or
near the oritical path.

1101
 CANTED FRAME - TRUE VIEW
WITH STRINGERS

(J)
Z
o
I--i
I-
U
W
(J)

w
(J)
I--i
~
2
<C
w
cr:
5 I-
(J)

1102
METHOD

Most of these interrogations have involved plane sections. Let UI

consider this more deeply.
The form in which the intersection curve is required is that ot an
ordered list of points, whether to drive a draughting machine, a _chiDe
tool or just an area algorithm. This list can be obtained in two wqs:-
1) by calculating the intersection points of the individual
generators (lines of constant u or v) with the p~ane and
sorting these into order.
2) by "marching" along the curve, calculating the points in
the right order.
Most of the few papers, (6), (7), (8) and (9), which mention this
topic suggest method 1 as a possible technique. The notable exception is
P.J. Payne (4) who has actually implemented it and haa produced a systea
very well suited to the CRT based multipatch system (5).
Although method 2 has the theoretical disadvantage that it is
difficult to ensure that all parts of a multipart section are
calculated if some parts do not cut the boundar,y this has not proved a
problem in practice. Method 2 has the overwhelming advantage for high-
resolution lofting systems that the spacing of the points round the
curve can be continuously controlled as a function of curvature. This
method works as follows:-
The first phase in the calculation is the finding of a starting
point, which will be one end of the final curve. This is obt ained by
scanning round the boundary of the surface looking for a change in
sign of f = [p - Q N 1.
where Q is a point on the plane and N is the normal to the plane. Note
that f = 0 is the equation of the plane.

Let the two points spannin8 f = 0 be U o Vo with f = fo (-ve SBiY)

and u l VI with f = f, (+ve). Then by linear interpolation in u, v, f,
spar-eu.. ~ V1. J ~ [~ 0 v0 J +, [ k. I V,) f 0

f, - fo
will lie between the two and will be a good approximation to the required
start point. flo is then calculated and tested. If it is within the
necessary tolerance of zero (f is in fact the distance of the point from
the plane), then the required start point has been found. If not, then
depending on the sign of f). either (u o Vc fc) or (u l VI f.) is replaced
by (u~ v~ f~) and the process repeated. This process is the classio
divided difference technique.
Once the starting point has been found the stepping commences. Let
the initial point be Po. Then(P~ x p v ) at Po gives No, the surface
normal, and (No x N) gives To, the tangent to the intersection.

1103
 W
0::::
LL:::::)
0"-
U
3::::::)
wO::::
I-i ..-
>(f)
zO
<cZ
-1 I-i
0..:3:

1104
 The increments in u and T to give a step of length e along To may
be calculated as follOWS

<: To '> e ~
f~ ~ ~ ~ f~ ~v

[< To ') )(
f"1t = ['P~ x1\] ~"'- ;;.
No ~'"

8To) )t fv J. No t .: tv I) • No b"
S~ ~
[<10> , 1" , Nol /( tva . Nt)
and similarly ~v -- [ 1'" )
t. 10 ")
)
No 1/ ( No. No)
The increments give a new position (u l VI)' which is the first
approximation to the required point.

At this point, PI' we eva.1.uate t\ : [1\ - Q J. N

and note that f~ ~ l' 01. • N f" c: 'P v. N

We also evaluate Q, -: I f, -10

and note that e... -:: 1~ . ['. - l' oJ / ~ I
and
e." -- 1" . [f 1 01 / 0., I -

Near P ~ -; Q, + e. . . ~ . . -+ e." ?, 1/

r
r :: +, -l- f~ b~ ~
t" ~ V

e. [~- ~,]
[::J r~'f ...
and therefore
I
-:::
C, - t,
to give u 1. v t' the second approximation to the required point.

It is convenient to work in tenns of (e. - ~~) (i. e. the pitch error)

instead of i~, since then we have two functions (~- e~) and f:, which
are lengths, and which need to be wi thin tolerance of -.ro for the
iteration to end.

1105
GENERALITY
It is a feature of the NMG system that the same plane seotion
algorithm is applicable to all situations. Most systems based on
curves in parallel plane sections would require three routines to ooyer
the four tasks:- spars, ribs, wing horizontal seotions and canted trame ••
The generality is deeper than this, though, because the marching
method described above does not use the surface equations. These appear
only inside the EVALUATION subroutine, whi9h calculates P, fir h ... and
~p /~IJ from u and v. By interposing the offsetting process the same
algorithm takes sections through an offset surface (demonstrated in lig. 5),
and by supplying a suitable evaluation routine rational biotibios, or any
other surface expressed in parametric form, can be sectioned.

REFERENCES
(1) Ferguson, J.C. MultivariabJ.e CUrYe Interpolation
The Boeing Comp~, Document D2-22501f.,
July J.963. Also J. JeM, Vol. 11 No.2,
ApriJ. J.964.
(2) Coons, S.A. Surfaces for Computer-Aided Design ot
Space Forms
M.I.T. Project MAC, MAC-TR~1, June 1967.
Pages 21, 59.
(3) Forrest, A.R. Curves and Surfaces for Computer Aided
Design
Cambridge Computer-Aided Design Group Thesis,
July 1968. pp 65, 71, 80 - 81.
(4) Payne, P.J. Contouring Program for Coons' Surface Patohes
Cambridge Computer-Aided Design Group
Document 16, November 1968.
(5) Armit, A.P. A Mllltipatch Design System for Coons'
Patches
lEE International Conference on Computer
Aided Design, Conf. Publ. 51, Southampton,
April 1969.
(6) Gel~ert, G.O. Geometric Computing - Electronio Geometry
for Semi-Automated Design
Machine Design, March J.965.

(7) McCallum, K.J. The Intersection of Surfaces and Planes

May 1966.
(8) de Lotto, I. Innovative Design with Computer Graphios
Galimberti, R. Alta Frequenza, Vol. 36 No 5,K~ 1967.

1106
(9) Hamilton, M.L An Approach to Computer Aided Preliminar,y
Weiss, A.D. Ship Design
January 1965.

ACKNOWLEDGEMENT
The author gratefUl~y acknowledges the help that he has received from
colleagues in the preparation of this paper. He would also like to thank
the management of the British Aircraft Corporation for permission to
present it.
Appendix Interrogation facilities in Numerical
Master Geometry system.

Plane sections
Intersections of two surfaces
Cylinder intersections
Silhouettes
Simple offsets
Non-isotropic offsets
Line intersects
Nearest points
Reflections

Bounding of curves by planes or surfaces

Interpolation of curves
Generation of stringer traces
Plane inte~sections with stringer sections
Quick and dirty hidden lines removal
Orthogonal views
Rotated views
Isometric views
Perspective views
Non-isotropic scaling
Listed ordinates
Angles
Areas
Volumes
Centres of Gravity
Moments of Inertia
Tool Centre Paths for sculpture milling
Link to Profiledata N/C language
Panel development.

1107
 <..')
Z
1--1
3: (f)
0 en LL
:c 1--1 0
(f) 0::::
3:
<..') w
<..') Z 1--1
Z 1--1 >
1--1 3:
3: w
z ::>
1--1 0::::
<t: f-
~

1108
L·EADING EDGE
RIBS

1109
 I-
%
UJ
~
a..
0
..J til
UJ a:::
>
UJ
<C
0-
0 til

UJ z:
(.) w
<C w
u... ~
a:::: I-
:::J LLJ
til CO

(!) ....
-
z
):
ow
Z
4:
a..
~
w
C-
o...
::>
1110
 w
() 2 I
N ::::> f-
--.J 0....
OOw
>f-O
,/
,/
,/
,/
,/
,/
,/
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
;'
-'

;'
/
/
/
/
/
(
I
I
I f-
I
I
0....
~ w
\
\
o
\
\
,
""
""
" " '-
"-
"-
"-
"-
"-
"-
'- .... ....
.... ....
.... ....
.... ....
.... ....
'-
'-
....
.... ....
"-

,,
"-
"-

....0 "
N~ ___________________________________________________'_,~

w
U
<C
w LL <C
w cr:: w
cr:: ::::> cr::
LL (f) <C

1111
 WING WATER LINES

1112
(f)
z
ot-"\
\-
t-"\
o
Z
o
<..)

1113
1114
1117
1118
 ANALYSIS OF AN EFFICIENT
HOMOGENEOUS TENSOR REPRESENTATION
OF SURFACES FOR COMPUTER DISPLAY*

T. M. P. Lee**

Mail Station 8611, Sperry Rand Corporation, Univac,

P.O. Box 3525, St. Paul, Minnesota 55101, U.S.A.

SUMMARY
There has been growing interest in the interactive construction of free-
form surfaces using displays to view and control the design process. Appli-
cation of computer graphics in this area requires a wise decision as to the
class of surfaces to be considered and careful selection of an appropriate
mathematical representation for them. We present and analyze such a repre-
sentation, placing emphasis both on its mathematical properties and on the
implications for the associated computer algorithms. The primary goal of
this research was to enable the efficient and rapid presentation of true
perspective views of a moving object while permitting convenient means to
specify the desired surfaces. Within this context it is desirable that the
mathematical representation chosen be capable of handling as wide a variety
of surfaces as possible. In particular, the algorithms encompass as simple
cases such surfaces as cones, spheres, toroids, and saddle surfaces, with-
out recourse to lengthy trigonometric functions.

We build a complete surface from a set of elementary surface patches. The

representation chosen for a single patch is a sixty-four element tensor of
fixed-point numbers. Rather than conventional Cartesian coordinates we .use
the four homogeneous coordinates of projective geometry. This decision both
unifies the perspective, rotational and translational transformations into
* The research reported here was performed at Harvard University and
supported in part by the Advanced Research Projects Agency (ARPA) of
the U. S. Department of Defense under contracts SD-265 and subsequently
F-19628-68-C-0379 with Harvard University, under contract AF 30(602)-4277
with the University of Utah, by the Office of Naval Research under con-
tract ONR 1866(16) with Harvard University, and by a long standing agree-
ment between Bell Telephone Laboratories and the Harvard Computation
Laboratory. The author was a National Science Foundation Graduate Fellow
during the time the research was performed.
**Federal Systems Division, Univac Division of Sperry Rand Corporation,
St. Paul, Minnesota, U.S.A.

1119
one operation and introduces significantly useful extra degrees of freedom
into the representation.

To display a surface patch we first apply a transformation matrix to the

tensor to establish location and orientation. The resulting tensor is then
used to generate iteratively a network of curves lying on the surface, such
as the latitude and longitude lines on a globe. The iterative generation
involves the application of finite-difference techniques to four polynominals
represented by the tensor, with only twelve additions and shifts necessary
to compute the next point for display. The alternative approach would be
to generate first all the points, and then to apply the transformation matrix
to them--unless one has a fast matrix multiplier, this is clearly inefficient
since our approach replaces multiplications with additions. Each point is
then converted to scope coordinates by performing the division required to
obtain perspective. Satisfactory implementation of the finite-difference
algorithm requires an analysis of the computational errors in the process,
taking into account finite precision computer arithmetic. In particular,
unless some form of floating-point operations are used it is necessary to
have on the order of eighteen bits accuracy to adequately display surfaces
with sharp corners, such as a church steeple.

Effective use of the generality of this surface formulation can be better

achieved through an expandable data structure capable of representing the
numerous concepts involved. A particular surface can be specified and
represented in numerous overlapping manners, such as by the set of curves
lying on the surface, by a specification of points and slopes, or by the
basic surface tensor. Or, one may desire the facility to define and use
prototype classes and special cases, such as surfaces of revolution. These
considerations point toward the use of a relational data structur~ in which
intrinsic properties of surfaces may be made explicit and through which
generic operations and attributes may be applied when appropriate. By in-
cluding elementary deductive algorithms we hope to construct a surface de-
sign system that is tolerant of human errors and which can to some extent
learn from experience.

1.0 GOALS
This paper presents some of the results of a research effort~]directed
towards the development of a computer-aided system for the design of free-
form surfaces. Since the previous publications of the work [1, 4]have been
primarily concerned with the theoretical mathematics of the surface dis-
play algorithms, I will be here coneerned with the not-so-obvious implica-
tions of the nature of the mathematics on the practical problems of inter-
facing the computer with the designer. In order to make this paper more-or-
less independent, I will briefly repeat some of the basic surface material
as well as develop the goals and motivating considerations behind the re-
search.

1.1 Interactive Surface Design

Naturally, the obvious goal of applied research such as discussed here
is the creation of a system or process which is better than previous methods

1120
As usual we make such a comparison based on ill-defined criteria of cost
and performance. Since such evaluations are difficult to perform at any
time, much more so during the research phase of a project, our goals have
had to be more ephemeral, based on a desire to apply the techniques of inter
active computer graphics to the designer's task, while maintaining the bene-
fits of precise mathematical formulations. Hopefull~ the favorable results
of previous such commitments imply eventual positive benefits from this
particular research.
We thus assume our goal as the following: to develop an interactive
system of computer hardware, software, and terminals replacing the conven-
tional modelling clay and sketch paper traditionally used by a surface
designer. As is usual in such a situation, this primary goal can be re-
phrased as a question of representation--how does one talk about surfaces
in a language suitable for both man and machine, where by the term language
we imply a complex set of pre-defined actions and reactions capable of re-
presenting and communicating information, either internally between compon-
ents of a system (including the designer) or externally with other individ-
uals or systems, such as a programmable machine tool. Implicit in this
phrasing of the problem is the assumption that computer processes are cap-
able of providing and manipulating the representation we are seeking; im-
plicit in the direction we have taken for the research is the assumption
that mathematical formulations will provide such a representation, even
though they may have to be translated into more human terms and actions.

1.2 Efficiency and Mathematical Accuracy

Several particular goals for this effort can be listed once we have made
the decision to look toward mathematical formulations for a primarily non-
mathematical problem. These goals are in some sense ex ~ facto in that
they may never have been explicitly mentioned until after the direction of
the research was clear; perhaps a better way to say it is that the about-to-
be presented properties are what the goals for the research should have been,
had it progressed in the never observed scientific textbook manner. In any
case, these goals may be taken as a catalogue of what appear to me as the
essential merits of the results here discussed.
1.2.1 Speed
In order to offer any hope of creating a practical surface design system,
the mathematics and display algorithms must be fast enough to permit a high
degree of interaction without requiring extraordinarily expensive special-
purpose equipment. In particular, rather complex objects consisting of
several component surfaces will need to be displayed rapidlY enough to per-
mit a ready observation of their shape through a continuous motion of the
object on the display.

1.2.2 Efficiency
Since the scarcest and most expensive resource on a computer display
system tends to be memory, we need a representation which makes efficient
use of that resource. More specifically it must be amenable to swapping
from lower-cost but slower backing stores as well as being inherently par-
simonious in its demands for memory.

1121
1.2.3 Simplicity

It has been widely observed that on the order of 40 bits is all that is
necessary to select any particular document from the entire U.S. Library of
Congress. This is an efficient representation, but not at all simple. We
require thus in addition to efficiency in a representation, simplicity both
in specifying the particular representation for the object desired and in
transforming between one internal representation and anot~er, such as be-
tween the mathematical formulation about to be discussed and the list of
commands necessary to create a picture on the display screen. Similarly,
even though a certain representation may have a degree of mathematical ele-
gance and simplicity, it should also be comprehensible in simple terms to
the primarily non-mathematical potential users of the surface design system.

1.2.4 Generality
Lastly, once all the above goals have been met we may find that the
chosen representation is suited only for the most elementary cases. Hence
we demand a certain level of generality in the representation in order that
we may talk about interesting and useful surfaces. Luckily the representa-
tion here discussed meets this goal very well, in that it can talk about
a wide variety of surfaces in a mathematically precise but efficient way--
the simplicity will have to be created by the interactive software mediat-
ing between the mathematics and the user.

2.0 ~ASIC ALGORITHMS AND REPRESENTATION

Although the interesting aspects of the computer-aided surface design
problem are primarily non-mathematical, their precise formulation depends
on the mathematical context in which they arise. We will thus present as
quickly as possible the mathematical representation we have chosen for
surfaces, with a slight digression to analyze the impact of computer pro-
cesses on the practical implementations of the representation.

2.1 Homogeneous Coordinates and Perspective

We are talking about objects in a three-dimensional world, a world to
be observed through a person's sense of sight. Since people perceive ob-
jects in a certain way, they have become adapted to expect to see them that
way, and only with difficulty can other modes of perception be used to con-
vey precise information about the objects. A computer generated visual re-
presentation (display) of a true three-dimensional object will thereby be
more effective if it follows the rules of perspective vision as given by
the simple laws of elementary optics.
Without belabouring the details, the result of deciding to display sur-
faces in perspective is to force a division to be used in the conversion

1122
between three-dimensional object coordinates and the two-dimensional coor-
dinates of a flat display. Once it has been decided to use this division it
becomes convenient and desirable to represent the position of a point in
three-dimensions by four numbers, rather than three. Thus, a general point
[ x, y, z ] can be represented by any of a set of numbers [hx, hy, hz, hl
where h is an arbitrary scale factor. This is called a homogeneous coordinate
representation.
Such an apparent 33% increase in memory space for the representation of
a point leads eventually to three ameliorating circumstances, which when
taken together increase the effectiveness of a surface design system by de-
creasing program size, simplifying notation, and increasing the surface re-
presentation's capability:

1) The automatic scale factor in the homogeneous coordinates allows

the use of fixed-point arithmetic without complicated scaling pro-
cedures. This has proven particularly effective in matrix arith-
metic routines, which as we will see later must preserve as much
accuracy as possible.

2) The projective geometry of homogeneous coordinates allows all the

operations associated with the manipulation of points in three-
dimensions to be expressed in simple matrix forms[6]. In particular,
the complete set of numbers necessary to specify the position, orien-
tation, and perspective viewpoint of a rigid object can be expressed
in a single 4 X 4 homogeneous matrix.

3) The mathematics of homogeneous coordinates introduces extra degrees

of freedom into a representation, by virtue of the fact that any of
an infinite set of four-vectors can be used to represent a particu-
lar point. The representation scheme presented here is easentially
an extension of one of Coon's special cases[2)to homogeneous coordi-
nates: his method could not represent a sphere (although it could
approximate it to better then one percent) whereas our scheme pro-
vides a precise representation for the sphere without greatly com-
plicating matters. In addi tion, the representation provides for
certain continuity constraints whi~h could not be met before.

2.2 Tensor Representation of Surface

Without going into the historical or technical motivations, the basic

representation chosen for surfaces can be described in a deceptively simple
equation as:
3
v
2
u , u, 1] XBX
v
v
2
los: u, V s: 1}
1

1123
 where S is a set of homogeneous coordinates for all the points on the sur-
.face and B is a 4 X 4 matrix each of whose 16 elements is a four-dimensional
vector; B has the properties of a tensor under appropriate interpretation
of the allowable transformations for points represented in homogeneous coor-
dinates. Or, more directly, if T is a matrix representing translations
along an axis, rotation, and perspective; and if B represents a surface in
a given orientation; then B X T represents the same surface after the trans-
lation, rotation, and perspective projection have been performed. (The
multiplication B X T here is to be interpreted to mean the application of
the transformation matrix T to each of the 16 vectors in B.)

The practical problems of using this representation will take the remain
der of the paper; at this point notice that we will eventually talk about
surfaces composed from several "'elementary" surface patches, each of which
is represented in this fashion by a different tensor. Our two primary pro-
blems will thus be on the one hand to find or compute the tensors necessary
to represent a particular object--often only vaguely defined as a designer's
mental conception--and on the other hand to produce a visual representation
of the object suitable for human observation, control, and understanding.
The display problem is more-or-less solved; the specification problem has
only the beginning, albeit a strong one, of solution.

2.3 Interactive Generation of Surface Display

Talking about surfaces in the above abstract mathematical language is

rather useless when it comes to solving the practical problems of getting
a picture up on a display tube--it may clarify some conceptual problems of
classifying the nature of the problem, but it certainly does not give us
any commands to drive a display processor. To generate these commands we
use a highly efficient iterative (or incremental) process to compute a set
of successive points on a set of successive curves lying on the surface--
the points are connected by straight lines, the lines forming a visual
approximation of the curves which in turn give a feeling of the surface
shape.
The tensor formulation of the surface expresses each of the four coor-
dinates of a point as a polynomial in two variables; if we fix the value of
one of the variables we have a polynomial representing a curve in one vari-
able, the coefficients of which are the values of polynomials in the other
variable. The values of these polynomials for successive equally spaced
values·of the variables can be computed by finite-difference techniques
long familiar to numerical analysts. At this point notice that such a space
curve, can be re.J:>I'esented in a consi stent fashion by a 4 X 4 matrix A as

If we are drawing the curves for v =

compute a 4 X 4 matrix Cn for each curve
to compute the successive points P- (rna,
-
constant, P (u, nY), we first
Pn and then iterate upon the matrix
ny) QD the curve. We actu_allY

1124
compute Cn through the difference equation C~~~ = C~J'k +KC~J'+lk where
o n n IJ
C" k = C" k and C' k = C' Ok C" k is a 4 X 4 X 4 tensor derived from the
IJ IJ 1 1; IJ
initial representation of the surface. The successive points on the curve
are computed via

Cnm +l = Cnm + € Cnm

ik ik i+lk
nO n nm
where CIJ .. and Pk (mB, ny) = COk ' Pk being the four
.. = CIJ _ components of the
homogeneous coordinates of the point. Once the point P is calculated, we
.
compute Its dIsplay
. coor d Inates
. as [ PI P2 ] an d connect successIve
P4 t P4 .. pOInts
bY vectors. ( 1. f el. t her PIP4 or P4P2.1 S greater t h "In magm tu de, or
an one
if P3 is opposite the sign of P4 we have a point outside the viewing region
and must take steps to remove it--this is the clipping or windowing pro-
P3
blem in three dimensions; the term P4 could be computed to give an inten-
sity value to simulate varying brightness with varying distance from the
observer.)

2.4 Analysis of Iterative Process

Although the incremental finite-difference process is an efficient

algorithm, it leads to severe accuracy requirements in the computations.
As an incremental differencing process, errors tend to accumulate and to be
unstable as the number of increments on a curve increases. In particular,
the choice of the scaling factors € and Ie are strongly dependent on the num-
ber of curves per surface.

A statistical error analysis, too long to go into here, leads to the

following conclusions:

1. Conclusion: Select the number of increments (or curves) as small

as possible consistent with the number of elements necessary accur-
ately to represent visually the curve.
Reason: The mean error increases linearly with the number of incre-
ments and the standard deviation of the error as the square root of
the number of increments.
2. Conclusion: Select the scale factor to be within a power of two of
the reciprocal of the number of increments.
Reason: The errors vary strongly with the square or inverse square,
whichever is worse, of the product of the scale factor and the num-
ber of increments; the higher the degree of the polynomial the more
critical is the requirement that nE and mKbe equal to one.

1125
 3. Conclusion: For the most severe pOlynomial the accumulated error
after drawing n points on m curves is on the order of 36 (n + m),
or, for 32 points and 32 curves, eleven bits. To leave a suitable
number of bits (say, seven) for display, this requires at least 18
bits in the calculations.
~ason: Fixed point arithmetic forces normalization of the largest
value in the computations to be one; in the worse case polynomial
u~ v3 this worse term is the third difference, which like the third
derivative is rather large compared to the polynomial itself.
4. Conclusion: Use of a proper unbiased rounding process rather than
mere truncation is important.
Reason: Truncation has a mean error on the order of one bit, which
grows linearly with the number of increments; rounding has a mean
error of zero, which does not propagate, and a standard deviation 0:
one bit, which only grows as the square root of the number of incre·
ments.
Notice that these conclusions are of general nature and do not take inti
account the possible magnifications of errors caused by the perspective
divide; t~ey are, however, experimentally quite valid when talking about
relatively smooth surfaces which just fill the display.

3.0 ALTERNATIVE REPRESENTATIONS

As mentioned in the introductory sections, the major problem to be

solved in creating a surface design system is providing useful answers to
the representation question. Thus far we have indirectly introduced three
representations--the basic tensor representation of the surface as a poly-
nomial, the finite-difference version of that tensor, and the actual visual
display. Although these representations are most suitable for the creation
of the actual display image, they are not at all suited towards specifying
the desired surface on an interactive basis. In the following paragraphs
we will briefly discuss different aspects of this interactive specification
in each case leading to a slightly different form of representation.

3.1 Polynomial Representations

Still speaking from a mathematical point of view, we can generalize the
polynomial representation to include a more useful sst of numbers than in
the original 64 element tensor. Instead of using v, v2, v, I as the
basis for polynomials, we pick four polynomials which have the property of
directly relating to the position and tangent vectors of the surface at its
corner points. Once this is done, we can now represent a surface patch as

1126
-
P(u,v) -
- [FO(U)' Fl(u), GO(u), Gl(U)] x 00 01 00
v
01
v FO(V~l
10 11 10 11 FO(v)
v v X
00
u
01
u
01
uv
01
uv GO(V~
10 11 10 11 Gl (v)
u u u uv

- -
where the vectors in the tensor have the following meanings:

00 = PW,O); 01 = P(O,l); etc.

-gT OP
oou au u=O'
01
u
=
au u=O' etc.
v=O v=l

00 =
OP OP etc.
v Ov u=O' 01 v = Ov u=O'
v=O v=l

02p iJ2p
00 = 01 = etc.
uv OuOv u=O uv OuOv v=O
v=O v=l

Conversion among these various polynomial representations (original poly-

nomial, endpoint/derivative, and finite difference) can be accomplished by
appropriate transformation matrices acting on each of the four homogeneous
coordinate slices of the tensor.

3.2 Relation of Curves to Surface

Once we are given the above representation, notice that various slices
of the surface tensor can be interpreted as the matrices for the boundary
curves of the surface, when those curves are represented in a similar fash-
ion. (See Figure 1). In terms of Coons' language the polynomials FO' FIt G
Gl are blending functions which express the surface as a smooth interpola- 0
tlon between its boundary curves. By appropriate manipulation of the ma-
trices it is possible to obtain a surface for any set of four boundary
curves expressed in this matrix form.

Notice that once the four boundary curves have been specified there are

1127
 , A AUI
UO
'"
h;J
#fa ) I '\

AOV
h~
h'lf
h;f AIV

•pOO ..
pal •pOO
v
..
pal
v

"II
P
.
pia
v

...
pOO
U
.pal
u ?• ?•

..
pia
U
..
pll
U
?• ?•

Figure 1. Constructing the Surface from

Boundary Curves

1128
still sixteen elements undetermined in the surface tensor. Any of several
alternative conditions could be used to completely determine the surface;
each of the condition sets can be viewed as a different means of represent-
ing the surface. We will briefly mention four examples of such additional
condi tions. (See Figures 2-5.)
1. Specifying the J'twi st vectors'" at the corner points of the surface
patch; this is mathematically simple, but difficult to interpret
physically since a second partial derivative is not very intuitive.
2. Specifying outward tangent vectors at one point on each boundary;
this is far more intuitive, although it would require a more complex
set of equations to be solved to fill out the surface tensor.
3. Specifying a pair of non-intersecting interior curves lying on the
surface and passing from one boundary curve to the opposite curve.
These interior curves could themselves be specified in any of a
number of ways.
4. Forcing the surface to pass through four points at specified values
of the parameters; again we have an intuitive formulation which is
not too demanding in terms of computation.

Even within each of the representations there are several additional

possibilities since the curves used to specify the surface can themselves be
described in several similarly different manners. In particular, we can fit
a curve through five points or characterize it in terms of endpoint values,
a midpoint value, and tangent vectors at the endpoints. (See figure 6).

ov

u=O
v=1

• p.s

uo

Figure 2. Mixed Partials As Specifications

1129
 All of the above surface characterizations (as well as those to follow)
are supposed to be designed to permit a user to directly control the appear-
ance of the surface desired. At this stage, most of these concepts are only

00

aP
av u= a
v= 1

uo

IV

Figure 3. Outward Tangents as Specifications

mathematical possibilities since they have not been tested for their inter-
active characteristics; we have however specified curves in terms of end-
pOints and tangent and found such a characterization to be useful.

3.3 Constraints

In most of the above examples we have been talking about internal pro-
perties of the surfaces; in most practical cases additional external contin-
uity constraints will have to be imposed in order to fit adjacent surface
patches together. The additional flexibility supplied by the use of homo-
geneous coordinates allows such continuity to be specified directly in terms
of the tangent vectors and partial derivatives associated with the boundary
between two surface patches. As a result of such specification, we can
force two adjacent patches to have boundary continuity to first order and
yet be able to mold them to fit several additional internal shape require-
ments; in particular, the boundary curves of the adjacent surfaces will be
arbitrary except for the requirements of first derivative direction contin-
ui ty. (See Figure 7)

Other potential constraints, not at all investigated, might include

surface area, curvature, or volume specification. It is anticipated that

1130
solution of such problems is best done by a digital error minimization hill-
climbing technique. Other constraints, such as that a surface be a surface
of revolution or be quadratic or have conic sections, are more readily
specified analytically and have been explored to some detail.

UI

u=b

bv Iv

u=b
Uo
Figure 4. Interior Curves as Conditions
on the Surface

4.0 IMPLICATIONS FOR DATA STRUCTURE

After developing an initial set of programs for the simple display of

surface patches, using only the various tensor representations, it became
clear that a significantly useful implementation of the curve and surface
theory would requi re the development of routines that really "knew" about
surfaces rather than ones that were only capable of blindly manipulating
the tensors in the fashion of conventional programs. The primary evidence
for this conclusion was the awareness that throughout the development and
use of the programs experience would suggest continual changes in their

1131
mathematical and functional appearance. These changes need to be incorpor-
ated into the system in as painless a manner as possible by the use of
appropriate data structuring.

v =b
v =a

= c

Four Interior
Points Spec-
ified

=d

Boundary
Curves
Specified

Figure 5. Surface Through Four

Points

Philosophically speaking, the purpose and appropriateness of a data

structure are operationally determined by the uses to which it is put, that
is, by the questions the data structure is expected to help answer and what
those answers are expected to accomplish. We think of the data structure
as being used to form a model of some possibly changing set of concepts;
instead of asking questions about the concepts directly, we ask questions
about the model and expect that the answers can be interpreted as answers
to equivalent questions asked about the concepts.

The choice of a data structure thus implies not only a particular

modelling of the concepts but also a modelling of the questions: to answer
a question put to the set of concepts, we map the question to its appropria"

1132
model, ask that question or questions of the data base, built in accordance
with the chosen data structure, and map the answer back to an answer of the

Figure 6. Specifying the Curve

original question. If we choose a simple data structure to model a complex

set of concepts, a simple question asked in the language of the set of con-
cepts will be mapped into a complex question asked in the language of the
data structure. If either the resulting question or the mapping determining
it--presumably some program--is too complex, it is obvious that the data
structure is unsuited to finding an answer to the original question; in
fact, it may be impossible to do so. In choosing a data structure if we do
not know in advance all the questions to be asked we at least ought to be
able to convince ourselves that the types of questions likely to arise will
not be too difficult, the difficulty being measured in terms of the mappings
necessary to apply the question to the structured data base.

1133
4.1 Multitude of Concepts

To relate these general comments to the problems of a surface design

system, let us review the variety of concepts involved in the geometry of

Figure 7. Adjacent Surface Continuity

Conditions

the problem. The claimed result of thi s research is that the homo\jl'ieous
tensor representation of surfaces as rational bi-cubics is desirable. We
thus assume that part of the representation of a surface will be such a
tensor. Immediately we notice that this tensor is not unique. since there
are several different such representations suitable for different purposes:

1. The polynomial representation is good as an abstract prototype of

the surface.
2. The endpoint derivative representation is good for specifying the
curve from geometrical considerations.
3. Any of several difference equation representations is good for
generating a visual representation of the surface, the particular
difference equation used dependent on how many and what type of
curves we wish to display.
4. The code driving the display is itself a representation. making the
surface vi sible.

1134
 In addition to these explicit representations applicable to the general
bi-cubic rational surface we have the representation of a I~roduct surface fl
in terms of two curves, each curve in turn represented as a matrix. And
then we have a surface of revolution represented as a product surface in
which one of the curves is an arc of a circle and the other an arbitrary
plane curve. Or, by the results mentioned in section 3.2, we can represent
a surface by six curves and a few additional parameters. In the course of
working with a particular surface all of these different representations
might be useful and might exist at the same time.

4.2 Increasing Levels of Sophistication

Matching this multitude of concepts to a user will require an increas-

ing level of sophistication on both the part of the computer system and on
the part of the user. For instance, in addition to the specific represen-
tations above we can conceive of more such representations or characteriza-
tions, as yet undeveloped in detail, such as requiring that a surface be a
torus, a sphere, the hull of a three-masted schooner, or the right tail-fin
of an Edsel station wagon, assuming all such concepts can be formulated to
a sufficient degree of precision. We will not succeed in building an inter-
esting and useful surface manipulation system unless it is capable of freely
wandering about this proliferation of representations, choosing the appro-
priate one for the task at hand.

Further examples of the complexity of the concepts involved can be

found in the problems of relating the internal geometry of a surface to the
external geometry of the user and his display presentation; we wish him to
be able to converse with respect to any of several coordinate systems, but
yet to have the computer guide him through this potentially very confusing
set of orientations. Whether he must do this in two dimensions or in three
further complicates the situation; it is not at all clear how to talk about
three dimensional surfaces in only two dimensions. We would hope that com-
puter aids towards the visualization and expression of such properties as
tangent planes, local coordinate systems, and various constraints of con-
tinuity could be developed to remove the designer as far as possible from
the confusing wealth of useful but sophisticated tools at his disposal.

4.3 Deductive Information Model

If we grant that any or all of these various representations of a

surface need to be modelled we see two types of questions to be answerable
by use of a sophisticated data base. Prototypes of these questions are:

1. "What is the di splay code to be used to draw thi s surface?~'

and

2. ~'I find that there is no display code for this surface; how do I
generate it in order that I may answer question 1?I'

1135
flow of information in the reverse direction by attempting to provide a
natural means for constructing three dimensional pictures.

A truly effective communication cannot be established without

considering flow of data in both directions, and it might be thought
that improving the man's understanding of the picture will aid him to
commUnicate his ideas back to the computer. This is often true but
the use of stereo views is an example which serves to show that this is
not always the case. What needs to be established is some kind of feed-
back loop where the user can get a feel for what happens on the screen as
he controls the various input devices available to him. The lightpen is
a very suitable form of input for achieving this loop as it can be used
to alter a picture dynamically.

USING THE PROGRAMS

Using a tracking cross and lightpen, only two degrees of freedom can
be controlled independently at anyone time, corresponding to the X and
Y coordinates of the cross. Effectively, in drawing in three dimensions,
three coordinate values must be controlled and if this is to be achieved
with the tracking cross, one of the coordinates must be related in some
way to the other two, or held constant. The~ice of how to relate these
coordinates plays a significant part in determining how it will be
possible to arrange the operation of the program.

The usual approach to 3D drawing is to define the plane of drawing.

The method suggested here, however, is to define planes in which points
may be specified and then to allow a drawing to be constructed by joining
these points. Therefore drawing of lines is not limited to the specified
planes. In order to define points in space, use is made of a pseudo
tracking cross which moves in three dimensions under control of the
lightpen. The operation of the programs is based on the use of light-
buttons - words or symbols displayed on the screen which when selected
with the lightpen cause some appropriate program to be executed, or option
to be chosen. To control the movement of the pseudo cross, use is made
of "dynamic" lightbuttons which appear, at the appropriate moment,
clustered around the tracking cross on the screen, an idea used by
Wiseman at Cambridge, in the PIXIE system. Usually this corresponds to
the current position of the lightpen and makes selection very rapid,
because the relevant lightbuttonsalways appear close at hand. Some other
lightbuttons appear at the right-hand edge of the screen and for maJor
operations, menus of options appear at the bottom of the screen. The
arrangement of these menus and the way in which they are use~ to construct
commands using the lightpen are the subject of another papert2~

Whenever the command "DRAW A NEW OBJECT" is executed a set of isometric

local axes labelled X, Y, Z appears at the tracking cross position. The
three lightbuttons XYPLANE, YZPLANE, ZXPLANE appear down the right-hand
side of the screen. Selecting one of these defines a plane containing

1136
the last defined point in space, parallel to the XY, YZ or ZX plane.
This plane is termed the ACTIVE PLANE.

Pressing a console key on the display unit causes three lightbuttons

to appear clustered around the tracking cross. If the active plane is
XYPLANE these lightbuttons will be X, Y and N. Choosing one of these
causes the pseudo tracking cross to appear, in the active plane. If N
is chosen the pseudo cross position on the screen coincides with that of
the true tracking cross. Choosing X would cause it to appear on the line
in the active plane, parallel to the local X axis, passing through the
last defined point. Its local Y coordinate would be the same as if the
"N" option had been chosen and its X value is, of course the same as that
of the last defined point.

If the active plane had been YZ the options would have been Y, Z or N.
and similarly Z, X or N for the ZX plane.

In general, the pseudo cross is constrained to move in the active

plane and may be further constrained to move parallel to one of the
local axes, depending on the choice of lightbutton. Choosing a different
console button has the same effect as already described, with the addition
that the pseudo cross and last defined point are connected by a straight
line., Lines drawn in this way are updated dynamically as the cross is
moved, while the console button is held depressed (a technique usually
referred to as drawing rubber band lines). The pseudo cross is programmed
to grow Larger as it is moved towards the user, a feature which has
proved very useful and which enables the user to appreciate that he is
not drawing in the plane of the display screen.

Figure 1 illustrates some of the steps in drawing the simple figure

shown in l(f). In lea), the arrangement of the screen is shown: various
messages are displayed along the top edge of the working area to guide
the user, and the menus of options from which commands are constructed
appear at the bottom 0-£ the screen. The command "DRAW A NEW OBJECT" has
already been executed and the local axes and active plane lightbuttons
are present on the screen.

l(b) shows the dynamic lightbuttons corresponding to the currently

acti ve plane which is XYPLANE. A line has already been drawn from the
local origin parallel to the Y axis and choosing the X lightbutton gives
rise to the situation represented in l(c). In led) a rectangle in the
XY plane has been completed and the active plane is now ZXPLANE. Selecting
the N lightbutton leads to fig. lee). Continuing in this manner, the
completed figure in l(f) 1S obtained.

Some further features of the programs are

(1) The deletion of lines (edges)

(2) The ability to copy any previously drawn object any number of
times.

11:J7
 Fig ure 9. Tor us

Fig ure 10. Hy per bol ic Par abo loi d

113 8
 Fi gu re 11. Sp he re

Fi gu re 12 . Cy lin de r

11 39
1. Surface construction and display shall be sufficiently fast so that
the appearance of continuous motion and immediate resppnse to simple
requests will be possible. .
2. Surfaces shall be able to be specified in terms of previously de-
fined surfaces or surface types, allowing several simpler surfaces
to be composed into a more complex surface.
3. We do not propose to use an actual three-dimensional display of the
surfaces; rather, a two-dimensional perspective display providing
several different simultaneous views will be used to give the illu-
sion of a true three-dimensional object. The visual appearance of
the surface will be a flwire frame" image consisting of a user-
selectable network of curves lying on the surface, such as the
latitude and longitude lines on a globe. The intensity of the lines
should decrease with increasing apparent distance from the viewer.
4. Interaction with the system is to be via graphical input and output
devices and with such continuous controls as joysticks or potentio-
meters; keyboard devices shall be used only when suitable graphical
means are not available or convenient.
5. The graphical surface design system shall be easy to interface with
other processing functions, such as the computation of surface areas
or aerodynamic properties. Permanent output via mechanical plotter
or photographic means can be considered in this context. In the
latter case, a halftone image wi til hidden lines removed is a
possibility.
6. An advanced information retrieval system using techniques borrowed
from artificial intelligence research in deductive systems should be
used in order that the system may take into consideration an expand-
ing set of facts about surfaces in general and the current design
problem in particular. This is an ambitious goal in that very few
serious attempts have so far been made to apply the results of
artificial intelligence experiments to practical problems. A
specific goal here would be allowing a natural specification of
various continuity constraints, interpreted for the particular
surface on hand.

REFERENCES

1. Cohen, D., and Lee, T. M. P., ·'Fast Drawing of Curves for Computer
Display," Proceedings of the 1969 Spring Joint Computer Conference.

2. Coons, S. A., Surfaces for Computer-Aided Design of Space Forms,

Project MAC Report, MAC-TR-41, Massachusetts Institute of Tech-
nology (June, 1967).
3. Feldman, J. A., and Rovner, P. D., 1'An Algol-based Associative
Language,1' CACM, vol. xii, #8, August 1969, pp. 439-449.

1140
4. Lee, T. M. P., nA Class of Surfaces for Computer Display, II Proceedings
of the 1969 Spring Joint Computer Conference.
5. Lee, T. M. P., Three-Dimensional Curves and Surfaces for Rapid Com-
puter Display, Ph.D. Thesis, Harvard University, June 1969;
available as ESD-TR-69-l89 to ESD, AFSC, USAF, L. G. Hanscom
Field"Bedford, Massachusetts.
6. Roberts, L. G., '''Homogeneous Matrix Representation and Manipulation
of N-Dimensional Constructs, 'I' The Computer Di splay Review, Adams
Associates (May, 1965J.

1141
 ON LINEAR DIFFERENCES CURVES*

D. Cohen'
Aiken Computation Laboratory, Harvard University,
Cambridge, Massachusetts 02138, U.S.A.

* This work was supported in part by the Advanced Research Projects

Agency (ARPA) of the Department of Defense under contract SD-265

with Harvard University.

1143
Abstract

This work discusses the geometrical properties of the curves which

are drawn by connecting the points which are generated by the following

iteration: P(n)· TP(n-l), where T is a 2x2 matrix. This iteration

may be implemented efficiently hy both, hardware and software. It is

shown that by proper choice of the matrix T, the iteration can

a
generate any conic, generalized parabola (y a kx ,for any a )

spirals and some other curves. A necessary and sufficient condition

for generating conics is proved to be det(T) - 1. The curve classi-

fication according to the given matrix T, is also discussed. The

paper is followed by examples, photographed from a software simulation

of the iteration.
(1) Summary

This paper discusses the family of curves of the form:

n• (p(s)lp(s) • TSp(O) o< s < co}

where T is a 2x2 real matrix, P(O) is the initial point in 2D

apace, and s is a continuous variable.

These curves can be displayed by generating the sequence of

pof,nts {pen)} where n is an integer, and connecting successive

points by straight lines. The sequence {pen)} can be generated

incrementally by using:

P(n+l) a TP(n) •

1144
The simplicity of this iteration makes it very attractive for

digital systems involving either a special hardware or conventional

programming.

There are several different definitions for these linear-

differences-curves. The main ones are:

(a) P(n+l) = TP(n) or P(n)· TUP(O).

(b) 6P(n+l) "Tl~P(n) where ~P(n) - P(n+l) - Pen).

(c) ~P(n) .. T2P(n).

dP(n) .. T P(n),
(d)
dn 3
All these definitions are equivalent. In (2) below we prove this,

and show the connp-ction between Tl , T2 , T3 and T. Although we

use only the fJrst of these definitions we want to point out that

for some applications, the other definitions might be more

appropriate, (or even still other definitions).

In (3) below we prove that any origin-centered-conic<*) may be

generated by the above process. The proof is constructive and

gives a "recipe" fol. getting the generating matrix T, for any

conic, specified by its implicit form. As corollaries from this

theorem we get the generating matrices for circles and hyperbolas.

Each of the generating matrices obtained by this method belongs

to a one-parameter family of matrices, all of which generate the

same curves but of different speeds. The free parameter can be

used to control the generating speed, for example, by specifying

pel) on the curve; (with P(O) already specified).

~-*-t=- A~-~-r-~-f-;i-n---c-e-n-t-e-r-e-~---con i c .is ...:.d~e,-f-,i~n~c..:;;d~b....

y_.:;.;.ax~2+.;..2:;;.;b:;..:x;;.y+~c::ooYr...2_._---:d:.:...

1145
 In (4) we show that if two curves are obtained from each

other by a linear trnnsfonnation, then their gcneratinlj matrices

are similar (in the usual mathematical sense). As a result we

have a method for constructing the generating matrices for

ellipses and hyperbolas according to their geometrical properties.

In (5) we show that the condition det(T) :> 1 implies that T

generates:

(a) an ellipse if I trace(T) I < 2

(b) a straight line if Itrace(T)1 '" 2

(cl an hyperbola if Itrace(T)1 > 2

Next we are concerned with the IIspeed ll of the conic generation,

where the IIspeed ll is defined as the distance bet\·yeen successlve

computer-generated points. In (6) \ole show that unlike the

perspective methodflJhe linear differences method makes it

possible to generate a circle with a uniform speed (1. e., equally

spaced points) and hyperbolas with the right kind of speed (i,e"

the speed decreases as the radius of curvature decreases). As a

corollary from the equally spaced circle generatiGn it f01lo\o1s

that it is possible to generate ellipses with the right kind of

speed. Next we show the connection between the area of successive

triangles(*) {A} and det(T). In particular we show that the areas of

n
all the triangles of a conic are constant. This implies that the

spacing on a conic is necessarily good.

A is the triangle whose verticles are P (n), P (n+1) and

n
the origin.

1146
 It is important to mention that the family of conics includes

two kinds of slraigilt lines, the ones which pass through the origin,

and the ones which do not. In (7) we discuss these lines.

In (8) we discuss the curves which are generated by matrices

with a non-unit determinant. We show that for any ~, the curve

~
y ~ kx can be generated by the iteration, as well as elliptic

spir .... ls.

Finally, in (9) we discuss so~~ programming a~pects of coding

the itcrnticl1. In (10) we show pictures of curves generated by

the linC!:1 r-·d i f f crenccs-tncthod.

~Je will show that the 4 follmdng definitions of linear-

differences curves, are essentially equivalent, in the sense that

they define the same family of curves.

(a) Pen) D T P(n-l)

(b) 6P(n) = Tl 6P(n-l)

(c) 6P(n) ... T2 Pen)

dP{n) a T3 Pen)
(d)
dn
We will show the equivalence of each definition to (a) •

(2.a) (a) implies (b), i.e., if a curve belongs to the

family \.,hich is defined by (a), then it also belongs to the

family of curves which is defined by (b).

P(n+l) ... TP(n); Pen) = TP(n-l)

1147
 AP(n) .. P(n+l)-P(n) - TP(n)-TP(n-l) a T[P(n)-P(n-l)] a T6P(n-l) (QED).

(b) does not imply (a), but:

P(n+l) .. 6P(n)+P(n) "" 6P(n)+6P(n-l) ...... • 6P(n)+' .•• +6P(l)+6P(O)+r(O)

.. Tn 6P(O)+T n- l 6P(O)+ ... + 6P(O)+P(O) .. (Tn+T n- l + ... I) llP(O)+P(O

Assume that 1 is not an eigenvalue of T, then we can write:

llP(O) a (T-I)P(O)

then:
1 ~ +l~ ~
P(n+l) .. (Tn+Tn- +"'+I)(T-I)P(O)+P(O) a Tn P(O)+(P(O)-P(O»

which shows that (b) defines the same curves as (a) but they

might be off-centered by E a P(O) - P(O). The reason for this

possible displacemant is that (a) requires only an initial PO'

but (b) requires initial P(O) and llP(O). If

AP(O) .. T P(O)-P(O) a (T-I) Po then E = 0, and there is no

center displacement.
If 1 is an eigenvalue of T, then T generates a straight
line, which obviously can be generated by (a).
(2.b) (a) implies (c):

AP(n) .. P(n+l)-P(n) = (T-I) Pen) .. T2 Pen) .

(c) implies (a):

P(n+l) .. P(n)+llP(n) .. P(n)+T 2 Pen) .. (T 2+I) pen)

(2.c) (a) implies (d):

Pen) - Tn P(O)

l148
 dP(n) = (tg T) Tn P{O) • (tg T) pen) • T3 pen)
dn

(d) implies (a):

dP(n) .. Tl{n)
dn

P{n) III enTSAj

substitute n =0 and get A = P{O),

Note that if T has non-positive eigenvalues then there does not

exist a real matrix T3 " 19 T, and (a) does not imply (d).

For displaying an off-centered curve, one can generate the

{P{u)} using (a), and add some displacement to each point, or

position the initial P{O), and generate the {IlP(n)} using (b).

The latter scheme saves the addition of the displacement to each

point, and is, therefore, prefered if a special purpose hardware

is not available.

(3) Obtaining the Generating Matrix for a Conic iimplicit form)

Theorem: For any given origin-centered non-degenerate conic, there

exists a one parameter family of matrices {T{k)} which

generate the conic, and det(T{k») • 1 for all k.

Proof: Let the conic be

1149
We construct a matrix T, such that if P(i) is on the conic,

then so is P(i+l) = T P(i). Consider P(i+l) = P(i) + ~P(i) •

Define:

E • [P(i)+~P(i)]1I: C [P(i)-MP(i)] - P(i) 11: C P(i) •

Expand it:

E a 2ax(~x)+a(~x)2+2bY(lh)+b(~y) (~x)+

+2bx(~y)+b (~x) (~y)+2cy (~y)-:·c(fly) 2",

n (l)~{)( 2ax+2by+a(hx)+b (fly») -:- (ily)[ ?bx+2cy+b (l\x)+c(fly»)

For ilx,~y and any k which satisfy the follouing:

~x = k [2bx+2cy+b(ilx)+c(ily)]

~y co -k [2Clx-1-2bx+a(flx)+b(~Y)J

E vanishes, ",hi'ch means that P(i+l) is on the conic. Separate

~x and ~y:

(l-kb) ~x -kc ~y = 2k{bX+cy)

ka ll,*(l+kb )ily == -2k[ ax+by)

which is in matrix form:

[ l-k [b-a -bc] 1 [~x].." 2k [b-a -bc] [x]

~y y

1150
Introduce:

then,

'T -kGMP .. 2kGP.

The matrix (I-kG) is invertible for all (except two, at most)

values of k:

6P • 2k{I-kG)-lGP

P{i+l) .,. P(i)+L\P(i) ... (I+2k(I-kG)-lG]P(i)

Hence T(k) = I+2k(I-kG)-IG. Substitute a.b,c and define e • b 2 -ac.

Then for k2 ~ e- 1 :

1+2kb+k 2 e
(
-2ka

It is easy to varify that det(T)~ 1, for all k.

Consider the trace of T(k):

1+k2 e
trace(T) .. 2 .=...:..:-=-..;::;.

trace(T) .. { :
> 2
~ ~!
if
: ~> ~ }
e 0
for all k.

It is well-kno\-Tn that e < 0 implies an ellipse, e > 0 implies

1151
 an hyperbola, and. e - 0 implies straight lines.

Corollary: The generating matrix for the circle x 2+y2 - a is

obtained by substituting a· c - 1 and b· 0 (e n -1):

1 2k ] [cose -Sine]
T ---
C 1+k2 1-k2 • sine cose

lor the hyperbola x 2_y2 - S, substitute a D -c a 1

and b - 0 (e - +1) :

·T 1-
a- (
1+k 2 -2k 1 rCh~ Sh~l
H l-k 2 -2k l+k~ a lSh~ Ch~J
-2k -2k
where e- arctg and ~ - argth
1+k2 l-k2

(4) Obtaining the Generating Matrix for a Conic (Geometric Approach)

Theorem: If T generates the curve TI, and the linear trans-

formation II, maps IT into the curve r, such that r = lin
then the generating matrix of r is S - IITII- 1

Proof: Let TI a {pen)} and r - {Sen)} such that Sen) - IIP(n)

for all n, then:

S(n+l) • HP(n+1) - HTP(n) • HTH- 1S(n) QED

Namely, Sand T are "similar matrices", and have the.same eigen-

values (and therefore the same detenninant and trace).

This theorem suggests another method for finding the generating

1152
matrices for ellipses and hyperbola. Consider the ellipse, whose

axes are parallel to the X-Y axes, the length of the horizontal

axis is 2A, and the length of the vertical axis is 2~.

This ellipse is obtained from the unit circle by the transformation:

If this ellipse was titled by the angle a then it could be

obtained from the unit circle by the transformation R(a)D, where

R(a). [cosa -sinal

sina cos a

Hence the generating matrix of the ellipse is EaR(a)DR(0)-la(-a).

Th~ gen~rating matrix of x 2_y2. I 1s

( Ch~ sh~l
sh~ ch~

It is obtained from x 2_y2 • 1 by the transformation

H • R(a)D - [
cosa
-sinal [A 0]
sina eosa 0 l.I

1153
Hence its generating matrix is:

(5) Characterization of conics by the Generating Hatrices

Theorem: If TI· {p(s)lp(s) .. ~sP(O)} and det(T) a 1, then IT is

a conic, whose type depends on trace(T).

Proof: Assume that T ~ ±I as these cases generate either P(O)

repeatedly or P(O) and -P(O) alternately. Let

Consider the following cases:

(a) la+dl > 2 (b) la+dl .. 2 (c) la+dl < 2 •

Case (a): If la+dl > 2. Consider A, an eigenvalue of T,

A
'l .' a+2d + V 41 l'a+d)2 - 1. T can b e wr i tten as:

T • QnQ
-1
where Q .. [A-ab t c-d] and n ...

1154
D can be vritten as

D ... STIIS
-1
where S· [ Ch~ Sh~]
sh~ ch~

where ch~'" ~ (~ + f) and sh(j> A ~ (~ - i). Hence,

TH generates the hyperbola II, and T generates the hyperbola

(QS)ll.

~e~): If a+d'" 2 and c ~ 0 then:

T• -QLQ-1 •

The matrix L'"

(01 11] generates lines since

Because L generates a line so does T. If a+d'" -2 and. c ~ 0

then

T_ [a+1 -1] [-I 1] (a+1 -1]-1

c O O -1 leo
1155
The matrix 1-1o 1]
-1
generates a line, or two lines, and so does T.

If . c .. 0 then T CI 1-1o -1
b] which generates one or t\'lO lines.

Case (c): If /a+d/ > 2. Consider A, an eigenvalue of T,

A.. ~d + V 1 - t (a+d)2 i
.. e ia where cosO = 1-.2 (a+d)

and sinO.. V 1 - 4I (a+d)2 ' The sign of sine is chosen to be

like the sign of b, because of a reason that becomes clear later •

. Note that b '" 0 because b co 0 implies ad" 1, which

implies /a+d/ > 2. We will show later the existence of a real

matrix Q such that

I cose
-sine
Sine]
cose
Q
-1
•

As T generates the circle C, T generates a linear trans-

c
formation of it, which is the ellipse QC. We will construct

the matrix Q. As T and T do not determine Q uniquely,

c
we can expect some freedom in the solution for Q.

QT Q-l ..
c
[
X y] [ cose Sine]
( w -Y] _ [a b] T.
co

z w -sine cose -z xed

Equate components:

1156
 (E l ) : a .. (xw - yz)cosG - (xz+YW)!:iinG

(E 2 ) : b = (x + y)s1nG

(E 3 ) : c ." -(z + w)sinO

(E 4): d = (X\v-yz) cosO + (xz+yw)sin0

(ES) : 1 = X\v-yz.

The identity (xw-YZ)2 + (xz+yw)2 I: (x 2+y2)(z 2+w 2) shows that one

of the equations El through 1':4 can be discarded, and we can

impose another external condition on the system. We choose y. 0,

then

X" ~ b ' _ ,.:=:b==:=..

sin0 ~b sinG'

1
w=-a sin0
x
\J b sinG

d-a d-a
z c
:c: -=;::====.
2x sinO 2 ~ b sinG

Note that b sinO> O. We get:

1 [2b
Q D

2 Vb sin0 i

d-a 2 :ine]
This is the real matrix Q such that T • QTcQ-l, hence

[Zb
d-a
o
2 sin0
] [ cose Sine]
-sinG cos0
[2b
d-a 2 :ine r .. [: :] .
1157
 This completes the proof of the theorem.

(6) On the Spacing. Between Successive Points

Theorem: Let us consider the circle X2+y2 .. 1, and'the hyper-

bola x2_y2 - 1, both passing through the point

P(O) ~ (~) The circle is generated by the matrix

Te ' and the hyperbola by TH where

Te -
[cose -Sine]. and TH =
[Ch~ .h~l
sh4> ch¢
sin0 cos0

The point P on the circle is

n

[COS(ne) 1
n • Te ~ 0 ..
p
sin(n0)

and the point P on the hyperbola is

n

[
Ch (n4» 1
sh(n¢)

Let d be the distance bet\-leen P (n) and P (n+1) •

n
We want to show that d is constant for the circle,
n
but is an increasing function of Inl for the

hyperbola

Proof: For the circle:

P(n)" [cos <n0)]

sin(n0)

1158
 d
n
= (x n+l _X)2
n
+ (y
n+l
_ Y )2 -
n

a (cos(n+l)G-cos nG)2 + (sin(n+l)G-sin nG)2

2n+l
= (-2 sin 2n+l Gsin ~ +
2 2
(2 cos ---2- Gsin 2) 2 a

=4 sin 2 G (sin 2 2n+l G + cos 2 2n+lO) = 4 sin2 0

2 2 2 2

which is independent of n.

For the hyperbola p = [ch(ncP)] ,

n sh(n¢)

d 2
n
= (x n+l x )2 + (y
n
y)2
n+l n
=

sa (ch(n+l}¢-ch n¢)2 + (sh(n+l)¢-sh n¢)2

... (2 sh 2n+l ¢sh 1)2 + (2ch 2n+l ¢sh 1)2 ""

2 2 2 2

~ 4 sh2 t (sh 2 2n;l ¢ + ch 2 2n;1 ¢) = 4 sh2 t ch(2n+l)¢

which is an increasing function of In! • Q.E.D.
This theorem is illustrated in figures 10.1, 10.2 and 10.3.

On a conic all the areas {A} are equal.

n

The dist~nce between successive points on ellipses gets

smaller when the distance of the points from the origin

gets longer.

It is clear that by stretching a uniformly spaced

circle into an ellipse the uniform spacing is changing

into a good spacing.

1159
 The first theorem shows that is is possible to

generate conics in good spacing, but because of the

second theorem any matrix which generates a conic, must

generate it in good spacing.

(7) Straight Lines as Degenerate Conics

There are two kinds of straight lines which are degenerate

conics. The ones which pass through the origin, and the ones which

do not.

The lines which pass through the origin are asymptotes to

hyperbolas, and are generated by the same matrices ,...hich generate the

hyperbolas when the initial points are eigenvectors of the matrices.

The matrices T, which generate hyperbolas satisfy det(t) u 1

and trace(T) > 2. These conditions guarantee the existance of two

distinct eigenvectors, which introduce the two asymptotes.

The lines which do not pass through the origin, are arcs of an

ellipse whose major axis is infinite. For example, the ellipse who~e

axes arc of length infinity and of length ~ is the two parallel

Theorem: The Areas Law: Let P ~ rnp(O) and let t = deter).

n
Let Si be the triangle ,.,hose vertices are the origin

and the points pen) and P(n+l) . Let A be the

n
n
area of S . Then: A tAo'
n n z:

Proof:

1160
 Substitute P(l); Tr(O) and get AO a t P(O)*GTP(O)

Similarly

Consider

T*GT =
[: :] [-: :] [: :] .. [-c
-d
a] [a b]
bed
..
.
(-: :]
(-ac+ac -bc+adj .
- TG
-ad+bc -bd+bd

The reader should notice that although there is a similarity

this is not the Kepler area law.

lines y'" ± ~. The implicit form of the ellipse is y2 ... ~2 •

Using the method 0), and substituting a" b .. 0; c ... I (e "" 0), we

get:

1 2k ]
T(k) z: - - -

1+k 2

As expected: trace(T(k») - 2 •

1161
 This matrix, with the initial point generates

the line Y ... YO' in the positive direction along the ellipse, which

is to the right for YO > 0 and to the left for YO < 0. All the

points of the form P(O) • (xO,O) * are eigenvectors of T, corres-

ponding to the eigenvalue 1, and therefore are not changed by the

iteration. It is easy to show that T does not have any other

eigenvectors.

The generating matrices of proper ellipses [det(T)=l,ltrace(T)I<i

do not have any real eigenvectors, and cannot generate any lines.

(8) On Curves Created by Natrices with a non-unit Determinant

This chapter suggests, implicitly, building special hardware for

the iteration P(n+l) co TP(n) or 6P(n+l) D TllP(n). '1;'his hardware

can, as shown before, generate conics. However it is interesting to

know what happens if one iterates with a matrix with non-unit deter-

minant (which is a necessary condition for conics). In this section

we answer this question.

It should be noted that if T has negative eigenvalues then the

function TS is not well defined and required an extra care for

getting continuit~. However by observing only integer powers of T,

most of this danger is bypassed.

(8.1) Consider the cases T a deteT) > O. The matrix

S a T- l / 2T satisfies det(S) = 1, and\

S generates some conic. IfE
generates an ellipse then T generates an elliptic spiral which winds

outward to infinity if T > 1, or winds inward to zero if T < 1. See

figure 10.5.

1162
 If S generates an hyperbola, then T has two distinct eigenvalues,
a Then
and p. If both are positive then we can define a by ~ • lJ.

-1
T a:: H H

a If
which shows that T generates a linear transformation of y - kx •

both are negative then -T has two positive eigenvalues. T generates

points which alternate between the curve which is generated by -T from

PCO), and the curve which is generated by -T from -P(O). Note that

~= -1 implies an hyperbola, and a =0 (i.e., 1 is 8n eigenvalue

of T) implies a straight line. See figures 10.6 through 10.S.

If S generates a straight line then if T P 1, T generates

lines which belong to a family of curves, all of which pass through the

origin, and go to infinity. The shape of these curves is illustrated

in figure 10.9. T generates these curves (or a linear transformation

of them). Note that one straight line belongs to this family.

(8.2) Consider T c det(T) = O. If T is a non-zero matrix

then dim[Range(T)]ol, which means that all {pes)} belongs to a

I-dimensional space. Hence T generates a straight line thrOugh the

origin.

(8.3) Consider T Q det(T) < O. If det(T) < 0 then det(r 2 ) > O.

lIenee T2 generates one of the curves discussed before. Every second

point {P(2n)} which is generated by T is on the curve which is

generated by T2. The other points {P(2n+I)} are on the curve which

is generated by T2 through PCI). Hence T generates a sequence of

1163
 points which oscillate between two curves of the same type.

(9) Progra~ming Aspects of Coding the Linear Difference Scheme

This chapter suggests an incremental method for generating curve!

We pointed out in (2) that the same scheme which is used for genera til

the {P(~)} can be used for generating the {~P(n)}.

This iteration can be implemented either by conventional program

ing or by hardware. We give in this section some "coding-tips" for

programming the linear differences scheme.

(9.1) When P(n+1) = TP(n) is coded there is no need to store

array of {pen)}, as one can do only with the current value of P,

i.e., the values of x and y. The straight fon-lard coding of the

iteration is:

ax + by ... temp
cx + dy ... Y

temp ... x

The need for the temporary storage "temp" rises because x cannot

be changed before it is used for the y calculation. However, the

iteration can be defined such that x(n+l) is expressed by means

of x(n) and yen), but y(n+l) is expressed by x(n+1) and yen)

Consider the following identity:

1164
Multiply by Pen):

[
Xn+1] [8 b] [Xn] [ 1 •
Yn+1 = c d Yn a cIa

This may be coded as:

ax + by -+ x

ax + By -+ y

where 0"'-
c
an d B • ad-be If a - 0 but d ,. 0, a similar
a a
scheme works. This eliminates the need for the temporary storing.

(9.2) The well known-iteration:

x - <s.y -+ x

y + <S·X -+ y

gener<!tes an ellipse, because y uscs the "new" x as set by the

first statement. This iteration can be formulated as:

x .. x - <s.y
n+1 n n

Yn+l a Yn + <S'X n+l • (1 - 02)Yn + c5xn

or:

1165
 det(E) = 1, trace (E) = 2 - 0 2 < 2, hence E generates an ellipse.

(9.3) The iteration:

x+O·y~x

y + o·x ~ y

generates a hyperbola, as it is equivalent to:

P(n+l) - [~ :+6'] [:] • H pen}

n

and det(H) = 1, trace (H) = 2+0 2 >2.

(10) ~xa~p1es

All the pictures (except 10.2) wh~ch are appended to this section

were taken from a PDP-1 program which generates curves using the

method which is discussed in this chapter.

Figure 10.1: A circle generated by 16 segments. Note the uniform

spacing.

Figure 10.2: A circle which was generated by a perspective technique.

Note the non-uniform spacing.

Figure 10.3: Two ellipses. The generated points are marked by

asterisks. Note the IIgood ll spacing, regardless of

the starting point.

Figure 10.4: A family of hyperbolas, all of which were geI.lerated by

1166
 the same matrix. Note the good spacing.

Figure 10.5: An elliptic spiral which is generated by an elllpse-

generating-matrix, multiplied by a scalar whose magni-

tude is less than 1.

Figure 10.6: The parabola y c x2 is generated by the matrix

T = diag{a,a 2 }. Each part of the parabola has to be

generated separately.

Figure 10.7: The cubic y - x3 is generated by the matrix

T c diag{a,a 3 }. Each part of the cubic has to be

generated separately.

Figure 10~8: The sequence of points 1-2-3-4-5-6-7-8-9-10 was generated

by the matrix -H, where H is the generating matrix

of the hyperbolas 1-3-5-7-9- and 2-4-6-8-10.

Figure 10.9: A fnmily of curves which is generated by a matrix which

has two equal eigenvalues, but only one independent

eigenvector. As discussed before, this family contains

one straight line, which is in this example the X~axis.

1167
 ···~
I
.0
+
.0
"\1
t0
I-'-
OJ
r.n
:-.
0) 0

+
~O
+
,0
'''1 :--
m -{\
0) ~
:- 0
'i1 CJ 0)

7\) "c ........••. .............•.................... .•.•......•...........••.....•.••

m ~

-.0
-.:.

1168
 ···
·
/-
.
_.
r.~.h.:.::.~
f·~"
~.. .
:. ~~".
""",

" !. ""-
:r~,

~ / ~

I" l -\\
~I
l i: \.
/ \jt -
:
o•
~~ ,~

', .~

-
u.

'\. J"
", ~~"
~~";,i~V'~
,'" ~
.. "
./
~~

·
··..
~

1169
 0
N
~
~
l~.
'
+ -}

~ ttl
ttl r..J
a .-
(t'
~
'-
.••..••..•••••.•••••..•..•.•..•..•.•...•....

-
(\) 0 ""~•
u:~ ~

I,f.- ru 0
U) ru u.s
L., 0
....,( o· at
-:-- -:-::>
-
..!>
~
.....
0 "-
(.\j
ru CD
N cu
.....
'-'. v.
0,
+

1170
 CJ a
a CJ
CJ C'J
0 ~
0 D.
;;=t ru
+ +
I- LU
LU u
0 a:
cr.
t-
~ ...... : ........ .. . . .... .. .............. .. . . . ..........................
0 a
-
-
0
..... a ~

0-
0
a
ru
ru
0. U3
o· ......
.:- + §
0
0
0
CJ
~
a-
@ 0.-.
0. Cli
~ o·
+ ......

1171
 . , .. .. .. .. . ~ .~ ~ ....
,
.. .. .. .. . . ... ..
"
... .. .. .. .
.

1172
...................... .. e ........ •• ~ ... ~._~ .... .- . . . . . . . . . . . . . . . e ......... e .......... ~ ...... _ .. ~ ........ , ............................. ..
.................... ",. ................ .......................................................... ........................ ....................................................... .
~ '

1174
 o

.. .. .. .. .. .. ..
.. .. .. .. .. .. ..
.. .. .. ..
cU Cf)
.
(Y :) (.0
¢
.. -4

-
o U)
(\j (Li
CU.
0
+
o
,
......
.\
.

( \1
to
~
(\l
CU.
0•
'.~

1175
 0
t.) P
-\"-
(j)
0
80 ~
0
0
~
C)
A(h
,+...
0
,d.~ 0
0 0
.....0..:..1........00...
......•........... ............
............
.. .... .. ....
"

"
"
. . . . . . . ".
"
"

-4
:?J
0
~
r ~
n
.......

·nm.l
to\-
r-
~
g
0 '"
0
0 -
o
:.0
(ll) Conclusion

The method discussed in this work can be implemented either

by software or by hardware. The softw3re implementation is quite

straightforward. For hardware implementation we suggest having a

2x2 digital matrix multiplier, which can multiply a stored matrix

by a given vector, and replace this vector by the result. The

result is also used for generating the display vectors. If the

precision of the hardware is small, it is advisable to have two

separate scaling registers (preferably analog). This method can

be easily implemented by display systems which have a built-in

digital matrix multiplier, like the ESCC display system.

(12) Acknowledgments

I would like to thank Dr. L. G. Roberts, from ARPA, for his

help throtlgh some discussions we had. He also supplied me another

proof for the T(k) recipe which is given in section (3). I

would also like to thank Professor S. A. Coons and Professor Ivan

E. Sutherland for their remarks and criticisms.

Reference

(1] L. G. Roberts

"Homogeneous Hatrix Representation and Manipulation of N-Dimen-

sional Constructs"

Lincoln Laboratory Report MS-l405, May 1965.

1177
 INTERACTIVE SURFACE DESIGN

A. P. Armitt* and A. R. Forrestt

The University Mathematical Laboratory, Corn Exchange

Street, Cambridge CB2 3QG, England.

I. Introduction

The design of curved surfaces has always presented difficulties to

the engineer. Some types of curved shapes, such as cylinders, spheres,
surfaces of revolution and singly-curved surfaces can be represented or
indicated on a two-dimensional drawing with considerable precision, and
wherever possible the engineer has constrained curved portions of his
design to belong to one of these types. However, this is not always
possible, particularly where the surface has to pass certain criteria of an
aerodynamic, hydrodynamic or aesthetic nature. Sophisticated drafting
techniques, such as lofting, have been developed to enable doubly curved
surfaces to be represented on two-dimensional drawings with as little
ambiguity as possible, but often at the expense of complexity of drawing.
Increasingly, however, the shapes demanded by the designer cannot adequate-
ly be defined even by lofting techniques, and the possibilities of using
computers and graphic displays for curved surface design are now being
investigated. Although we shall confine our attention to the design
problems, the benefits of representing complex shapes mathematically in a
computer-amenable form should not be overlooked, especially when such
shapes can only be manufactured economically by numerically controlled
machine tools.

In this paper we consider the problems of interactive surface design

based on our experience with several different systems at Cambridge
University and elsewhere. We do not discuss those systems which are merely
computer versions of existing design methods, but rather those systems
which make use of techniques for design which are beyond the possibilities
of conventional drafting. We shall first discuss the principles of inter-
active surface design systems and then some practical systems, under two

t*Memher of British Aircraft Corporation, Stevenage.

tCambridge University Computer-Aided Design Group.

1179
main headings: mathematics, and software and hardware.

2.1 Mathematics

The use of computers and associated plotters, displays, numerically-

controlled machined tools, etc. in the design and production of three-
dimensional curved shapes demands a fresh approach to the mathematics and
geometry of shapes which we term computational geometry. Just as the
conventional geometry of draftsmen is based on straight edge, compass and'
french curve/spline constructions so we can take advantage of the
properties of the computer and its peripherals to perform rather different
constructions. For example computer graphics can be used to display
virtually any curve (given its formula) with equal ease, whereas a drafts-
man is limited to circles, french curves and splines. Computational
geometry covers the computer design, description, manipulation and
analysis of shapes.

Mathematical considerations for interactive surface design systems

are:

(a) The mathematical form selected should be capable of

representing the shapes required by the design exactly
or to a sufficiently close approximation.
(b) Mathematical techniques should be available to
enable the designer to specify shape changes in
a natural manner.

(c) The mathematics should be amenable to computation.

(d) The mathematics should take advantage, where

possible, of the qualities of the equipment used
and compensate for any inadequacies.

(e) As a result of (c) and (d), it should be possible

to represent a given shape in several different
mathematical forms and to be able to transform one
to another.

These considerations apply, as one might expect, to the design of curves,

a topic discussed in a recent paper (1).

At first sight it might seem that the methods for surface fitting
developed by numerical analysts may be applied to shape description.
These techniques are certainly applicable but only to restricted classes
of shapes. Conventional numerical analysis tends to assume a surface
equation of the form z ; f(x,y), for example the bipolynomial

m n
z I
i;O
I
j;O

1180
This implies several restrictions on the type of surface which can be
represented - the surface must be single valued for given x and y ,
slopes must not be too large (infinite slopes are of course out of the
question) and the data defining the surface must normally lie on the
planes where x = constant or y = constant. Examining the surfaces
encountered in engineering, for example, car bodies, aircraft wings, etc.,
one finds typically that the surfaces may be multi-valued, slopes are
large, and there is no convenient orientation of the coordinate axes to
avoid these difficulties. Moreover, some of the curves which bound or
otherwise define the surfaces are not planar but are fully three-
dimensional. Although a surface is a function of two independent
variables, one cannot arbitrarily declare that these are x and y; it is
more logical to assume that the surface equations are of the implicit or
potential form: f(x,y,z) = 0 or the vector parametric form [x y z] =
[x(t,u) y(t,u) z(t,u)]. In numerical analysis considerable emphasis is
placed on error. In computational geometry, however, error analysis is not
always meaningful. Naturally, if a designer requests a circular cylinder
he will expect an exact representation or failing that a close approxima-
tion, but often the designer merely requires a surface to conform exactly
to certain localised conditions and as a general condition to have the
indefinable quality of looking right, a quality which is generally
impossible to measure.

In lofting, a three-dimensional shape is represented by one or more

series of planar sections and the surface is interpolated between them.
By careful choice of sections many complex shapes can be handled, but
ambiguous interpretation is still possible. Lofting, like the surface
fitting schemes mentioned above, is not convenient when the defining
curves are truly three-dimensional, for example intersection of an aircraft
wing and fuselage.

To overcome the shortcomings of lofting and provide surface

description techniques suited to the computer rather than the drafting
table, two main approaches have been suggested. These are the surface
moulding method of Flanagan and Hefner (2) and the parametric patch
techniques due to Coons and others (3,4,5,6).

In surface moulding, which was originally intended for shapes akin

to aircraft fuselages, the approach taken is to start with an initial
non-parametric basic shape either in cartesian or cylindrical coordinates,
and to modify the shape by adding to or subtracting from selected
portions. The result of a design is a single complex equation, which
represents the entire surface as a sum of simpler individual equations.
Surface moulding is a mathematical analog of the sculptor working in clay,
adding and removing lumps of clay to modify his design. Surface moulding,
as implemented, is not suitable for designing and describing the aircraft
wings for which a different system is used.

In the patch approach which potentially is not restricted to any

particular type of surface, a surface is represented by an assembly of

1181
 smaller surfaces called patches which are joined by their edges to adjacent
patches with any desired order of continuity. Depending on the desired
continuity conditions the effects of a change can be confined to one
patch, one patch and its adjacent patches, or to as many patches as the
designer requests. Where more detail is required in a localised area
patche~ may be subdivided or split to provide more control. In multiple
patch design systems it is important that careful attention is paid to
the correct handling of the various continuity conditions.

Fig. 1
A duct designed on the multipatch design ,system (Armit/Forrestl

Patch techniques can be used to fit a surface through a grid of

points, and because the patches are parametric the defining points may
lie on three-dimensional space curves and are not restricted to lie on
planar curves. As surface moulding can be compared to sculpting, so
patch methods may be thought of as analogous to working with sheets of
flexible metal which can be bent, stretched and cut to shape, and welded
into larger assemblies.

There have been quite a number of implementations of Coons surfaces

and related techniques, (7,8,9,10, etc.) some of which we shall discuss
later in the paper. Whereas considerable progress has been made on the
mathematics of the patch technique and the development of new and more
powerful patches the practical implementations largely use the simple
bicubic patch suggested by Coons (3). This we believe is because little
research has been done on the designer/mathematics interface. For example
the rational bicubic patch of Lee (6) has great potential but a convenient
interpretation of the mathematics for the designer has yet to be developed,

1182
except for some of the special subsets of the patch, such as quadric
surfaces and 'polyconic surfaces'. In particular, a good shape characteri-
sation of the general rational bicubic patch is awaited. It must be
possible for the designer to have a good feel for the shapes which the
rational bicubic formulation, or indeed any other formulation, can produce.

Fig, 2
The duct with viewing ambiguity removed by brightness modulation

2.2 Software and Hardware

The combination of man and machine can leave design decisrons to the
man and calculations to the computer. The main distinction between
'design decisions' and 'calculations' is that the latter are readily
programmed and the former are not, being a function of experience, etc.
This sharing of the work seems useful in many areas of design and is best
achieved when man-machine communication is good. Computer aided design
systems consist of programs for calculation and presentation of the
results the man needs to make his design decisions and programs enabling
the man to communicate his decisions and data to the machine.

Evidently the output of a good CAD system will be of interest to the

designer and will be readily comprehensible and unambiguous. The man's
input to the system will be concise and yet provide flexible control of the
machine's activities. We now consider the implications of these require-
ments for interactive surface design (using graphics).

The man must unambiguously interpret the static projection of three-

dimensional surfaces on the two-dimensional screen, or else his design

1183
Fig. 3 Surface moulding. Longitudinal moulding using morbero
1184
Fig.4 Cross·section moulding using radial and angular controls

1185
Fig. 5 Blending functions controlling longitudinal extent of
cross-section moulding

1186
Fig. 6 3rd angle projection of moulded fuselage

1187
 Fig. 7 3rd angle projection of aircraft

llSS
effort is not directed at the 'model' held in the machine. (Pictures of
the object rotating at speed help visualisation but do not allow design to
proceed.) Half-tone pictures is one way to show three-dimensional objects
on the screen but is expensive in hardware, computing time and program
size. Stereo pairs of space figures may be used but involve wearing
special glasses, etc. or placing one's head in a fixed position relative to
the screen. (About 10% of the popUlation cannot perceive stereo.) A
cheap and effective method is to show 'brightness modulated' space figures
where bright parts of the picture are near the man and dim parts further
away, Figures 1 and 2. This takes very little computation and can easily
be appreciated.

Surfaces may readily be represented on the screen by lines of

constant parameter (for parametric surfaces), surface normals or sections,
etc. These different representations tend to emphasise different aspects
of the surface shape. The screen size, resolution and flicker rate can
limit the usefulness of displays for some tasks, but we believe that
useful surface design is possible with good design systems.

The man may spend some time modifying the surface he sees represented
on the screen (much more time than to create the surface). A direct
approach is to point the light pen at the offending part and then drag it
'by pen' (on a plane parallel to the scope face) to effect a change.
However, the rate at which the picture can follow the pen is limited by
the picture recomputation time and exact data is not easily specified.
Also, after an incorrect change to a design the man cannot easily correct
his mistake since he does not know the exact alteration made - he there-
fore has to redesign rather than restore after errors. A particular
difficulty with 3D information is the recognition of front and back when
projected onto a 2D screen.

Another approach is to display labels on the surface so that the man

can immediately identify parts of the surface which need changing. He
can then type a suitable command (giving increments in X, Y, Z) or
equivalently point to light-buttons to input commands and values. This
less direct approach does not rely on very fast (or 'frequent')
recalculations or upon the user's ability to point at 3D information on a
2D screen. The effects of making an error are much less serious since the
knowledge of the exact change made usually allows correction. Failing
this, correction is made by going back to the last saved design and
giving commands as previously up to the point of the error. By this means
the design process is 'digital' rather than 'analogue' and is made
'stable' in that previous good work is rarely destroyed. There should be
a close relationship between the command given and its effect to enable the
user to know what command is needed on observing a defective shape on the
screen.

In any surface design system commands are needed for three areas of
activities. Apart from those to alter the design we need commands to
show the required aspect of the shape on the screen. This may involve

1189
changing the scale of the screen representation and showing a 'rotated'
view of the object, etc. Often the manoevuring to a suitable view takes
longer than the surface modifications then suggested. A 'joystick' may
be used to control the rotation of the object but knowledge of the
rotations is needed to give commands in terms of object X, Y, Z. Design
in screen X, Y, Z may be allowed but this means a change in screen X only
may cause changes in object X, Y, Z and this effect is less easily
removed once the rotation is altered.

The other necessary commands are those for input and output of
designs. Any picture on the screen should be able to be plotted and any
data-structure representing the object under design should be savable.
segmentation of the design (i.e. the data-structure) can be helpful when
attempting large designs. Any values the user gives (for insertion in
data structures r-he should be able to interrogate and have printed on
the teletype or displayed on the screen.

In general, there should be a range of commands for the user to

give in terms natural to his discipline. New users may work by giving
many simple commands, experienced users should be able to give a few
complex commands.

When the shape under design looks satisfactory the user will want
to apply various application programs in a controlled way to the data-
structure holding his design and to get intelligible results. At first
he may wish to ensure that various criteria are satisfied (e.g. maximum
surface area). Thereafter he may wish to generate the NC control tape
to cut the surface.

3. Practical Systems

3.1 Introduction

In this section we shall discuss interactive surface design systems

which are capable or nearly capable of being used for the practical
design of three-dimensional objects. We have chosen to deal with the
surface moulding system developed at Lockheed-Georgia's Research
Laboratory (2,11) - a system with which we are familiar through
discussions with those responsible for the system and through the
excellent film of the system - and three patch design systems developed
by P. Bezier at Renault (12), Paris, K.J. MacCallum at Imperial College,
London (8), and by one of the authors, A.P. Armit at the University of
Cambridge (7). As far as we are aware these systems represent the most
sophisticated interactive surface design systems which have been
implemented. Others may well exist, but we have not seen published
references to them. We exclude from our consideration the primitive
patch design systems of the past, which were either difficult to use or
were intended to demonstrate graphics equipment. We also exclude
surface fitting programs which run in batch mode but which may produce
graphical output on a cathode ray tube or plotter (4,9,13).

1190
 Three of the systems we shall discuss were intended for specific
applications, aircraft fuselages in the case of Lockheed, car bodies
at Renault, and ship hulls at Imperial College, whereas Armit's
Multipatch Design System was intended for research into the interactive
design of three-dimensional shapes. These differing applications make it
difficult to compare the different systems' capabilities. Our comments
on the patch systems are based on hands-on experience (the Lockheed
system is no longer available). We designed a simple duct on the
Cambridge system and on the Imperial College system, and we hope to show
a model of this duct cut on the Renault system.

3.2 Surface Moulding

The surface moulding system of Flanagen and Hefner (2,11) was

implemented on a CDC 3300 computer and Digigraphics display at Lockheed-
Georgia; the system is no longer used because of hardware changes. Taken
with a separate design system for wings and tails, surface moulding
formed a part of a sophisticated preliminary aircraft design system which
included assessment of mission capabilities.

The designer starts by selecting from a displayed menu a plan and

profile for the aircraft fuselage, Figure 3. The plan and profile
curves consist of three segments differentiated by markers which are
activated by light pen selection and controlled positionally by light
button menus. The centre line of the fuselage may be modified as in
Figure 3. The designer then selects a cross-section of the fuselage which
he wishes to modify; in Figure 4 the wheel pods are being defined.

curve by man with

estimated control pOints.
x
FIGURE 8

Modifications to the cross-section are defined in terms of radius and

angle (i.e. polar coordinates) in a manner analogous to the definition of
fuselage plan and profile. Two cross-sections which limit the longitu-
dinal extent of the cross-sectional modification are indicated, whilst
the radius and angular extents are controlled by blending functions,

1191
Figure 5, top and bottom, respectively. Similar modifications which may
overlap are used to specify other fuselage features. Figure 6 shows the
completed fuselage in 3rd angle projection and Figure 7 shows the entire
aircraft (less engines) with additional longitudinal lines drawn,
specified by angular position. The design can be displayed in any
orientation with any number of cross-sections computed.

Surface moulding has several advantages. The design method is

particularly suited to preliminary design where overall configuration is
important~ gross changes can be made very rapidly, and there is good
control over the extent of modifications. It would probably be a more
cumbersome approach than a patch method for detail design as the number
of functions required to define a point on a complex portion of the
fuselage would become large. With patches, only one patch defines any
given point although the number of patches in an assembly could be large.
A particular advantage of surface moulding is the ease with which cross-
sections can be computed and other properties of the surfaces analysed.
An open question is whether the light pen methods 'are sufficiently precise,
although they are adequate for preliminary design. Surface moulding by
its very nature produces fair surfaces which are acceptable to the loft.
The system as implemented was oriented towards surfaces which had some
degree of symmetry and were topologically equivalent to a cylinder. The
extent to which surface moulding could be adapted to a less restricted
geometry has not been discussed.

3.3 Renault Systeme Unisurf

Bezier's Systeme Unisurf (12) is intended for car body design and is
implemented on novel hardware consisting of a drawing machine and a
3-axis NC milling machine on-line to an 8K computer. Standing at the
large drawing board (5' x 24') of the drawing machine the designer draws
a freehand curve with a pencil. This can (approximately) be modelled
into one or more parametric curve segments by simple means. High order
curves can be managed by one high order segment or piecewise by several
low order segments, e.g. parametric cubics (12,14).

The drawing head of the machine is moved until it is over the start
of the curve and the drawing machine X-Y coordinates are noted
(currently on a piece of paper) from a digital readout. This is repeated
for the points defining the slopes and the end of the curve segment,
Figure 8. These four X-Y pairs - the model - may be set on some
computer-readable switches and the computer asked to draw the curve thus
specified. The computer now controls the drawing machine which draws a
curve similar to the designer's, Figure 9. If this curve differs
greatly from the designer's the points defining slopes are modified and
the model redrawn.

Repeating the above process the designer completes his model of the
curve segment by specifying the Z values of the four points, Figure 10.

1192
After defining more curves sufficient data to define a surface patch is
obtained, Figure 11. The man can punch this data onto paper tape for

p------~
/ curve by
y
/
/
/
,.
/

,.- -(---- .... \

~
m.chine.
/ ,.
curve by man.

x
FIGURE 9

x design completed in plan view.

FIGURE 10

...
aBNAULT SYSTEME UNISURF CURVE DESIGN

computer input to output rotated views of the specified curves on the

drawing machine or produce a paper tape to control the NC machine to cut
the surface. This latter tape has quadruples of numbers (just like the
input patch-data) to specify curve segments to be traversed by the NC
machine. As this tape is read (at the NC machine) the numbers are
passed to the computer which generates (in real time) the signals to
control the machine to cut along the curve in 100 steps. The NC machine
is built to cut soft materials like polystyrene or wood and has a point
cutter.

1193
 This system provides a mechanisation of a projected-view design
process (at full size), plus the ability to rapidly produce the shape
itself cut in soft material on the NC machine. B~zier quotes about 4
hours to design and produce a shape, and himself refers to the NC
machine as a '3D drawing machine'.

FIGURE 11
RENAULT SYSTEME UNISURF PATCH DEFINED
BY 8 CURVES OR 16 POINTS.

The system does not build a data-structure as design proceeds, so

the designer has to note the numerical description of his design on
paper. Furthermore, multipatch designs have to be tackled patch by
patch with continuity conditions maintained by the designer.

Many of these inconveniences are offset by the ability, quickly

(and cheaply) to cut the surface designed and this is a strength of the
system.

We emphasise that the present system (like the others to be

described) is a prototype and that future systems will overcome some of
our criticisms. Figure 12 shows a car roof panel and Figure 13 an
exhaust manifold designed and cut by Unisurf.

1194
"
.00

(")
'"..........
o
o....
"0
'"
::l
(1)
V>
Q.
(1)
V>
.00
::l
(1)
Q.

'"::lQ.
3
(1)
Q.
0-
-<
CIl
-<
....
V>
CD
3
CD
C
::l
V>
C
....
.....

1195
 'TI
~'

w
m
x
:T
Q)
C
~
3
Q)
::J
:;;
o
a:
0..
Cl>
VI
<C'
::J
...,
Cl>

Q)
::J
0..
3
...,
Cl>

cr
'<
Ul
'<
~
Cl>
3
Cl>
C
::J
VI
C
~

1196
3.4 Surface Dragging

The system due to MacCallum (8) originally used an 8K POP7 with

DEC340 display and now has a 16K POP9 with the same display. The
surfaces used are currently bicubic Coons' patches. Design starts by
causing the machine to read a tape of very approximate patch data.
Thereafter design proceeds mainly by pointing with the light-pen and

Fig. 14 The duct designed by su rface dragging

'dragging' part of the surface. Much work of the system is in the

routines to decide what patch parameter is to be changed during dragging -
e.g. a corner moved, a slope changed, etc. - following a pen hit on part
of the displayed patch. The system can show short lists of data on the
screen describing a patch and these act as light-buttons so that values
typed in may be directed at them. A single projection is shown on the
screen at one time and the patches are represented by lines of constant
parameter. The object can be made to rotate and design changes occur in
the rotated view. Up to about ten patches are held in the machine and
multipatch design is being implemented where changes in one patch reflect
to others as indicated by patch joins. Patches can be split to allow
local refinement of surfaces.

This system lacks visualisation aids and suffers from the readiness
with which work is destroyed when errors are made. Changes in 3D are
achieved by modifying two 20 projections - unfortunately modifying the
second projection provides opportunity to upset a carefully adjusted

1197
value of the first. The problem of pen identification of front or back
of surface exists, but the system was developed for half-hull ship design
where no great nuisance occurs. Very good 'analogue' communication
between man and machine is achieved in this system when surface dragging
by light-pen. Figures 14 and 15 show two views of the duct the authors
designed by surface dragging.

Fio. 15 Rotated view of the duct designed by surface dragging

3.5 Multipatch Design Program

The Multipatch Design Program due to Armit (7,15) uses an 8K PDP7

with DEC340 display. It has been used in the design of aircraft skins,
engine parts, a shoe last, etc. The designer arrives at the computer
with approximate patch coordinates and the layout of patches on a piece
of paper. By typed command the user creates a patch which appears on the
screen with its corners labelled A,B,C,D and with its name shown. Patch
modification commands are given in terms of the corner labels and are
directed at the currently selected patch. For example, PAT A X 100 sets
the X coordinate of corner A of the currently selected patch to 100.
Incremental commands, e.g. PAT A INX 100 are also provided. There are
over three hundred possible commands to allow patch modification, view
modification and input/output. Any command need only give the
differences from the previous command; this vastly reduces the necessary
input.

The system can show three 3rd angle views and an arbitrarily
rotated view, Figure 16. Any of these may be shown singly or as a

1198
stereo pair to be viewed using a mirror. Any of the views may be
brightness modulated, Figure 2. Patches are represented by lines of

Fig. 16 3rd angle projected and rotated view of BAC 3·111

airbus canopy (Multipatch Deisgn System)

Fi~. 17 Sectional shoe last (Multipatch Design System)

1199
constant parameter and/or normals. Design is relative to the X-Y-Z
of the object; rotation may be set by command or varied using a joystick.
The system holds up to about twenty patches and maintains any J01ns and
continuity conditions the designer requests. Designs can be output on
paper tape and may be segmented, and data describing patches can be output
on the teletype.

Fig 18 Rolls-Royce aero engine part (Multipatch Design System)

Patch splitting is not included. This system has a 'stable' design

procedure and provides some visualisation aids. In practice design has
proceeded with a single brightness modulated view on the screen, perhaps
rotated a known amount about one axis.

Figures 1 and 2 show the duct as designed on the system, wh~le

Figure 16 shows parts of an aircraft body during a design exercise with
the British Aircraft Corporation, Weybridge. Figure 17 shows a rotated
view of a shoe last which was part fitted, part designed in an exercise
with the British Shoe and Allied Trades Research Association. section
lines (16) are shown bright and parametric lines dim. Figure 18 shows
part of a Rolls Royce aero-engine also produced in a design exercise.

4. Conclusions

Interactive surface design is still in the early stages of

development. Several widely different approaches to the problem have

1200
been taken, influenced by the type of application in mind. The systems
we tested were by no means ideal, even for their intended purposes, and
we have indicated some of their varying failings in the paper. We
consider that experience with further practical applications and
different implementations is necessary before more definite principles for
interactive surface design systems can be formulated. We believe,
however, that interactive surface design is practicable.

5. Acknowledgments

The authors would like to express their thanks to their colleagues

in the Computer-Aided Design Group at Cambridge, and to K.J. MacCallum of
Imperial College, P. Bezier of Renault and S.H. Chasen of Lockheed-
Georgia for their help in preparing this paper. Figures 3 - 7 are
courtesy of the Lockheed-Georgia Research Laboratory, Figures 12 and 13
are courtesy of R6gie Renault. The surface dragging system depicted in
Figures 14 and 15 was developed by K.J. MacCallum at Imperial College
under Ministry of Technology Contract F/HP/09. A.P. Armit is seconded
to Cambridge from the British Aircraft Corporation, Stevenage.

6. References

(1) Forrest, A.R. Curves for Computer Graphics

U. of Illinois Conference, Pertinent Concepts
in Computer Graphics, 1969.

(2) Flanagan, D.L. Surface Moulding - New Tool for the Engineer
Hefner, O.V. Astronautics and Aeronautics, April 1967.

(3) Coons, S.A. Surfaces for Computer-Aided Design of

Space Forms
M.I.T. Project MAC, MAC-TR-41, June 1967.

(4) Ferguson, J.C. Multivariable Curve Interpolation

The Boeing Company, Document D2-22504,
July 1963. Also J. ACM, Vol. 11 No.2,
April 1964, pp 221-228.

(5) Forrest, A.R. CUrves and Surfaces for Computer Aided Design
Cambridge Computer-Aided Design Group Thesis,
July 1968.

(6) Lee, T.M.P. A Class of Surfaces for Computer Display

AFIPS, Proc. SJCC, May 1969.

(7) Armit, A.P. A Multipatch Design System for Coons' Patches

lEE International Conference on Computer Aided
Design, Conf. Publ. 51, Southampton, April 1969.

1201
 6. References (Cont'd.)

(8) MacCallum, K.J. The Use of Interactive Graphics in Preliminary

Ship Hull Design
International Symposium, Computer Graphics 70.
BruneI University, April 1970. (see this volume,
Part 12)
(9) South, N.E., Analytic Surface Methods
Kelly, J.P. Ford Motor Company, N/C Development Unit,
Dearborn, Michigan, December 1965.

(10) de Lotto, I. Innovative Design with Computer Graphics

Galimberti, R. Alta Frequenza, Vol. 36 No.5, May 1967.

(11) Chasen, S.H. The Role of Man-Computer Graphics in the

Design Process
Lockheed-Georgia Research Laboratory,
February 1969.

(12) B~zier, P. Proc~d~ de D~finition Num~rique des Courbes et

Surfaces non Math~matiques - systeme UNISURF
Automatisme Tome XIII No.5, May 1968.

(13) Sabin, M.A. Numerical Master Geometry Reports VTO/MS/146 -

156
British Aircraft Corporation, Weybridge.
(Various dates)

(14) Forrest, A.R. A Re-examination of the Renault Technique for

Curves and Surfaces
Cambridge Computer-Aided Design Group Document
24, May 1969.

(15) Armit, A.P. A Language Processor for Interactive Work

at the PDP-7
Cambridge Computer-Aided Design Group
Document 17, October 1968.

(16) Payne, P.J. Contouring Program for Coons' Surface Patches

Cambridge Computer-Aided Design Group
Document 16, November 1968.

1202
THE USE OF INTERACTIVE GRAPHICS FOR
THE PRELIMINARY DESIGN OF A
SHIP'S HULL

K. J. MacCallum

Imperial College of Science and Technology, Centre for

Computing and Automation, Prince Consort Road,
London, S. W.7, England.

1. INTRODUCTION
The work reported in this paper was carried out
under a contract awarded by the Ministry of Technology to
Imperial College to study the use of interactive graphics
in the shipbuilding industry. The equipment initially
available to those working on the contract was an 8K
PDP-7 without any form of backing store, and a D.E.C.
type 340 C.R.T. display. (1) In February 1969 the
PDP-7 was replaced by a 16K PDP-9 and an exactly similar
display unit. Backing store on the PDP-9 consists of two
'DECtape' units and will soon be augmented by a disc.
The machine chosen to be linked to the PDP was the
Univac 1108 situated at The National Engineering
Laboratories, East Kilbride, and for some time a telephone
line connection between the PDP and 1108 has been available.
The software which was developed to allow the machines to
communicate and to work under the time sharing operating
system of the 1108, EXEC~8, is described in another paper (2)
2. THE PLACE OF HULL DESIGN IN THE SHIP DESIGN PROCESS
The preliminary design of a ship, in common with
that of most other engineering objects, involves careful
compromise between a number of factors in order to pro duc e
the most economical result satisfYing the functional
requirements of the design. In ship design the basic
functional requirements are usually stated as the ability
to take a given payload a certain distance at a certain
speed, where payload is a general term whose definition
depends on the type of ship. It may mean the weight of
cargo to be carried (deadweight), or the volume of cargo
to be carried, or even the number of passengers to be
carried.
1203
 To satisfy the functional requirements a hull
form must be determined such that it minimises drag,
motions in a seaway,hull weight, and constructional
complexity. These functions can all be related to a
desire to reduce the capital or running costs, or both.
At the same time the hull must provide adequate static
and dynamic stability and have good manoeuvrability
characteristics.
A recent example of the constraints involved
in hull design is provided by the growth in the size of
tankers and bulk carriers. The maximum dimensions of the
ship (length, beam and draught) are limited by the
facilities for building, berthing, and even by the depth
of water at any part of the proposed route of the ship.
At the same time, the desire to reduce the total
structural weight and hence the building costs provides a
constraint on the dimensions, particularly length. The
shipowner will wish to have as much cargo as possible
fitted into the limiting dimensions and the logical
conclusion is a hull which occupies a cuboid block.
However, the power necessary to drive such a shape would
be prohibitive. In fact, for a given Rueed and len~th
of ship there is a limit of fullness or degree to which
the hull fills its circumscribing cuboid above which it
would be uneconomic to go.
Because of the complexity of the shape being
developed, an initial design usually progresses by
relating the functional requirements to a set of parameters
which are of greatest significance to the characteristics
desctibed above.
The normal procedure is to assume for the ship a
total loaded weight from which the size can be
approximately calculated. By estimating the power
necessary to drive this size of ship a check is provided
on the weight intially assumed. Any variation between
the initial assumption and the final check can be
minimised by repeating this 'design cycle'. At all stages
of the design cycle, empirical relationships based on
previously successful designs are used to generate more
information although the designer can use his specialised
experience, knowledge of current trends, and variation
with ship types to adapt these basic relationships for his
own particular design.
The complete initial design cycle is executed
without determining the actual shape of the hull and yet
predictions are made about the power necessary to drive
1204
the ship. The power predictions are derived from a
series of tank tested models and the use of this technique
obviously assumes that the hulls which are produced
conform to modern practice. Production of a hull form,
therefore, usually depends on an ability to use the
information from existing designs. Considerable work
has been done on the determination of the parameters which
most affect the resistance of a ship and these parameters
have been linked to existing information available from
the results of previous stages of the design cycle.
The parameters available from the initial design
cycle which directly relate to the shape of the hull
provide non-dimensional measures of the volume, longitud-
inal and vertical centres of the volume, longitudinal
distribution of area and a number of boundary conditions
such as a measure of the area of the waterplane and a
measure of the angle at the foremost point of this
waterplane.
At this stage the naval architect is ready to
prepare, usually to a scale of 1/48th of 1/50th, a sketch
of the hull which will form the basis of all design
calculations and of more detailed design. The hull is
described by a series of plane sections taken through it
in the three principal co-ordinate directions. The
sketch is usually initiated by defining the principal
design lines on the ship. Thus the midship section can
be defined by the area at midships and the waterline can
be estimated from its measure of area and its'
angle of entrance. The remainder of the hull can usually
be estimated by sketching sections which have an area
consistent with the longitudinal distribution of area.
Sketching a hull can be a complex task principally
because it is necessary to relate a two dimensional
sketch to a three dimensional object. Thus once a sketch
has been produced in one view it is necessary to draw the
other two vi ews and perfonn a manual cros s-fairing or a
check on all curves in all three views to ensure that the
same points correspond on each.
During the development of the hull form, the
designer will introduce a number of other constraints
based on his own experience and on special requirement s of
the design. For example, the need for a large deck area
in a car ferry may result in the introduction of a knuckle,
or longitudinal discontinuity in slope, into the hull;
or the resistance characteristics may be altered by the
introduction of a bulbous bow. Practical considerations
may also affect the hull shape even at the initial design

1205
stage. Extreme examples of this are provided by a series
of ships being built with straight line sections (3).
Tank tests have indicated that careful alignment
of the discontinuities between the plane surfaces may
result in only a small increase in resistance while
considerable savings can be made at the fabrication stage.
Most important is the architects own judgement with
respect to the drag of the hull. Especial care has to be
taken close to the stern to provide an adequate and even
flow of water to the propeller. If separation occurs
prematurely, it can result in poor efficiency of the
propeller with an increase in vibration and reduced
manoeuvrability. Separation has also been known to occur
in the forebody and thus 'hard shoulders' should be
avoided.
The preliminar,y hull form is used in many ways in
further design and production stages. In design, a number
of calculations are based on the hull form. The
calculations relate to the compartmentation of the ship,
and its resultant ability to carry cargo and to resist
complete flooding if damaged. If tank tests are to be
carried out on the hull shape then the preliminary hull
form can be used as a basis for building the model. For
the production stage the preliminary hull form is used for
producing a larger scale drawing (either full scale or
1/10th scale) from which production and steel design
information can be taken.
3. PROPOSAL FOR A HULL DESIGN SYSTEI'1
It was shown in the last section that, although a
part of the traditional method of hull design comes from
the formulation of rules and from previous successful
designs, a very important constituent of the process is a
graphical assessment and modification by the naval
architect. The creative ability of the designer and the
need to allow him to contribute to a design has long been
recognised and has resulted in emphasis on the use of
interactive facilities when using computers to assist in
the design.
In the present proposal for a hull design system,
an interactive graphics terminal will effect the
communication between the computer and the designer. In
hull design this is necessar,y since so much of the assess-
ment is visual and since feedback from modifying a design
should be rapid to allow experimentation and convergence
on the final design. However, visual assessment of a hull
is not nearly enough. As previously stated, a number of
1206
parameters of the design should be adhered to; but lacking
a completely automatic way of generating a hull with
these parameters, it is necessary to supply the naval
architect with their values. Thus the interactive displ~
becomes a way of inputting data to a number of analysis
programs and of outputting the results of these
calculations. Because of the flexibility to change this
graphically expressed input data and because of the
quick response of results of calculating the design
coefficients, the designer can be closely involved and
can make effective use of his experience.
It is, therefore, proposed to set up a central
data base containing information relevant to the design,
in this case hull information. A suite of analysis
programs can operate on this data base and produce
results relevant to the design. Such programs might, for
example, calculate volumes, stability of the vessel, or
a number of other parameters. A graphical program
operates on this data base to display the hull surface on
the screen and will accept modifications to this surface,
using some kind of input device. At any time, the
designer may request some analysis to be performed on the
current data base and may compare the result with his
desired value.
Implementation of this proposal has been
commenced at Imperial College. It was decided at an
early stage to use the concept of a fast graphics
satellite computer, linked over telephone lines to a
large central multi-access computer. This type of
configuration is justified for a number of reasons:-
a) Interaction with surfaces is a somewhat
complex task and a fast local processor is
required to support the graphical display
(servicing of this interaction by the central
computer would be liable to impose unacceptable
delays).
b) The use of a central data base and of a
suite of analysis programs requires the
existence of a large and fast computer.
c) The use of a large machine which can be
multi-accessed means that data bases and
programs may be shared among a number of
users.
d) Since many users will be accessing the

1207
 large machine, the cost of running a
program is minimised,
e) The use of telephone lines implies
(theoretically) that choice may be made,
at short notice between a number of central
machines; it certainly places no constraints
on the distance between the central machine
and its satellite.
The allocation of tasks between the two computers
depends on the fact that transmission of data along the
link is relatively slow and that immediate access to the
central machine is not normally guaranteed. Thus the
central machine can only be used where delays are
acceptable; this is in running analysis programs and in
making major accesses to the data base. As much graphics
activity as possible must be controlled in the satellite
and thus it has to contain a subset of the data base, all
the display and graphical interaction routines and a fairly
comprehensive communications handler.
This paper is chiefly concerned with techniques
for designing surfaces on the satellite machine. They
provide a general approach to surface design, although
they have been,to some extent parti~llarly related to
the problems and approaches met in ship design. It is
felt, however, that their use has something to offer in
other fields of surface design.
4. HULL SURFACE DESIGN
For the work on the design of hull surfaces the
mathematical surface representation of Coons (4) was
chosen as the most suitable. In the Coons representation
the surface is defined by blendings of a number of given
coefficients; normally four boundaries and slope conditions
across these boundaries. For computer-aided design work
it is normally written in its tensor form, i.e.
f(u,v) = u M B Mt v t
where u is a vector of linearly independent functions of
parameter u,
v is a vector of linearly independent functions of
parameter v,
M is a constant square matrix and B is a tensor of the
surface coefficients. The choice of Coons' surfaces was
made for a number of reasons:
1. Continuity with neighbouring patches is
simple to define,
1208
 2. Since the surface is defined para-
metrically infinite slopes can be catered for,
3. Again, due to the parametric definition,
the definition of the three co-ordinate
directions is independent, and,
4. The relation between engineering surfaces
and a bounded analytic definition is close.
The principal disadvantage in using a parametric
definition of the surface has been that it is, in general,
time consuming to present a useful display to the user,
i.e.to display plane sections through the surface. Sections
are often required in ship design for assessment of the
hull and methods should be available to allow this to be
done interactively.
A design, therefore, will consist of an arrangement
of surface patches joined along common boundaries and made
continuous to some degree across these boundaries. In
ship design, in particular in the initial stages,
continuity is only required up to the first degree.
Having chosen the mathematical model by which
designs are represented the most important problem is to
relate this to the design methodology. The principal
difference between the design method and the model is that
the former deals in shapes whereas the latter deals in
numbers. It is the work of a surface design program to
provide the interface between the two. Using an inter-
active graphics terminal an nbvious method for providing
this interface is to use the graphical input device (light
pen or tablet) to indicate a part of the surface to be
altered. Then by entering a 'dragging' function this part
of the surface will follow all movement s of the input
device. Since the algorithm will relate these movements
to changes in the mathematical model the intrinsic
properties of the model will not alter. This method of
providing a complete interface between the model and the
graphiB poses a large number of problems principally
concerned with interpreting the meaning of a designer when
alt ering the surface.
One of the more basic problems is to determine the
range over which an alteration should take place.
Flanagan and Hefner (5) solved this problem by letting the
designer indicate the range graphically. In general this
is difficult to specify for surfaces and the patch approach
can be used more simply and more effectively. Thus
constraint s can be applied so that any alt eration will
1209
oIlly aLfect a single patch, unless continuity conditions
with neighbouring patches are affected. In this case the
alteration will affect the neighbouring patch. The range
of alteration can be termed the 'effective segment'.
Allowing for this constraint on the range of dragging,
what characteristics can be stated for the effect of a
dragging operation? In other words, when a designer changes
a point on a Gurface patch what happens to other points in
the effective range?
Subjectively one can say that the only condition
should be that the effective segment should retain its
character. This can be defined more precisely by the
following conditions:
a) The new surface should pass through
the new position of the dragged point.
b) For a given dragging operation, the
maximum deviation of the final position
of the surface from its first position
should be small in relation to the size
of the effective segment. It is important
to note that intermediate positions of the
surface should not affect its final
position,
c) The effective segment should retain
its boundary conditions (in this case
boundaries and slopes across boundaries
for first degree continuity) and, by
definition, nothing outside the effective
segment should alter,
d) The deviation from the original surface
should be a maximum at the dragged point;
this condition is not so stringent as the
others although large variations from it
cannot be tolerated, and,
e) the deviation from the original
surface should be of one sign, in
other words, the new surface should
lie totally on the same side of the
original surface.
When endeavouring to satisfy these conditions,
it immediately becomes obvious that the bi-cubic surface
normally chosen for surface design does not have enough
degrees of freedom. In order that the effective segment
can be a single patch an extra term is reqQired in the
1210
boundary equations and in the blending functions. By a
simple extension, this would suggest a bi-quartic
surface. In fact to satisfy condition Cd) more degrees
of freedom are required. However, it has been found that
if the point being dragged is central to the surface, the
variation from this condition is small. An alternative to
choosing bi-quartics is to use a rational cubic surface
(6). This equation provides the extra degree of freedom
required together with a number of other advantages.
However, this surface form has been rejected for the
following reasons:
a) The principal advantage of the
rational approach is the simple
representation of conic curves and
quadric surfaces. Since these are
relatively unimportant in ship design
the bene fi t is not so great.
b) A number of problems arise when trying
to apply the techniques of surface
dragging. Principally this is due to a
longer more complex algorit4ill and
the occasional appearance of slngularities
in the surface when the denominator term
of the equation goes to zero.
In practice the bi-quartic has been found to be
satisfactory for surface dragging. To cater for the
number of different conditions of dragging which may occur
depending on the position of the dragged point the
following rules have been adopted:
a) If the point being dragged is in the
central region of the surface only that
surface is affected,
b) if the point being dragged is near
to or on a boundary common to another
patch then both patches are affected,
and,
c) if the point being dragged is near
to or on a patch corner common to other
patches then all patches with that common
point will be affected.
The concept of being near to a point or boundary
can conveniently be described by using values of the
parameters within certain ranges.

1211
 In the case of altering single surface patches
the algorithm for dragging has been simply to alter the
single relevant coefficient. Where more than a single
patch is involved, more than one coefficient often needs
to be changed; an attempt is then made to find a solution
which satisfies dragging condition Cd).
In solving the problem of dragging, an implicit
range over which a change will take place has been
introduced. How, therefore, does the designer use this to
specify the range he wants? Design is a convergent process
and in normal surface design methods alterations start by
being of a gross nature. As the design gets closer to its
objective, changes are smaller and the range of alterations
decreases. This convergent process can be simulated in
surface patch methods as long as there is a process for
splitting a patch into more than one patch. If this is
possible then a design can begin with a single patch and
as more local areas of design are required the patch is
split into subpatches. The splitting Crul continue to allow
fine detail to be designed. An important criterion to make
splitting effective is that the result of splitting a patch
should be two patches initially identical to the original.
If this condition is not satisfied then plitting ceases to
be a convergent process. In fact it can be shown that the
bi-quartic surface can be split along a parameter line to
result in two bi-quartic patches identical to the first.
The split is simply a transformation in parametric space.
Although splitting is a powerful convergent process
it is necessary to be able to join patches as well. The
situations in which this will arise are as follows:
a) Where the complete surface has a
discontinuity. In ship design this might
be a knuckle or chine and as such is a
design line which will be configured as a
patch boundary. It is useful in this case
to design both parts separately and to join
them at a later stageo
b) Where there is a continuous surface
composed of two distinct objects joined
by blending surfaces. An example of this
would be an aircraft fuselage and wing with
the wing fillet as the blending surface.
Although this forms one continuous surface
it is important that the designer should
consider the wing separately from the
fuselage and should leave the blendlllg
problem until later.
1212
 Other problems involved in interpreting the
designers wishes are those of working in three dimensions
with a two-dimensional screen and two dimensional drawing
device. The basic solution to this problem is provided
by the normal engineering representation. This is
particularly convenient in ship design since all lines on
the three views of the object are true views and
alterations are only made in two dimensions at a time.
A secondary problem is determining which surface (i.e. which
depth co-ordinate) is required when using the pointing
device, if two surfaces are superimposed. Armit (7) has
conveniently surmounted this problem by supplying nares to
all the patches. Fortunately the problem seldom arises in
ship design.

In a good design system there are a number of

constraints which a designer would like to apply. In ship
design these are relatively few and the only one which
presents any problem is representing a circular arc. In
referring to rational cubics it has already been stated
that conics are not required. None the less a designer may
request a circl e wi thout the stric t requirement of it being
precisely a circle. This would arise, for example,
in defining the middle section of a ship. Thus, as Coon's
has shown that a go degree arc of a circle can be very
closely approximated by a cubic, (4) the problem can be
solved by using this approximation.
One of the difficulties in using Coons surfaces is
in the presentation of surface information. The naval
architect is used to plane section views and in fact it is
difficult to design without these views. In using
parametric surfaces the parameter lines normally used for
display purposes are generally space curves and therefore
unsuitable for the design of some types of surface. In
the surface scheme presented here, this is solved by
constraining the surface patches so that opposite
boundaries are linear in one co-ordinate direction with
respect to a parameter. If, further, the two other
boundaries lie in this one co-ordinate plane then so
also will all intermediate parameter lines. This, of
course, immediately places restrictions on the flexibility
of the surface patches but it is found that the two types
of surface in combination provide the most flexible system.
5. DESIGN INITIATION
What has been described so far ate the techniques
developed to allow a design to be modified and refined.
An outstanding problem in ship design is to provide a @Dod

1213
 starting point for the design. It is not satisfactory for
the program to supply a single surface patch which only
resembles a ship type shape. The designer does have some
geometric constraints which he wishes to apply and from
these he should be abl e to get a reasonab le first
approximation to the design.
Traditionally, one of two techniques are generally
adopted as a starting point. In the first of these the
designer uses the available design coefficients to produce
the main boundary curves i.e. waterline, midship section
line, and stem and stern lines. From this he proceeds to
produce interpolating sections which satisfy the boundaries
and also the requirements of sectional area at various
stations along the length. A similar technique could
obviously be used with surface patches to define the
boundaries. However, lack of information on the
interpolation required could result in a poor first
approximation.
The second technique uses information generated
by a previous design to directly produce the new hull.
Methods exist for methodically varying an existing hull
surface to produce a new one with the required design
characteristics. Unfortunately this method suffers from
lack of flexibility. It assumes that th basic ship is
approximately the same type and shape as the new design.
If any new design features are incorporated (e.g. a knuckle
or bulbous bow) then only a very preliminary solution to
the problem is found.
With the surface patch design program, it is
realised as soon as several examples of hull shapes are
developed that the sequences of splitting of surfaces to
create the correct shapes are similar each time. In
other words, parts of the hull are created from
topologically similar sets of patches. This leads
immediately to the idea of 'topologies of patches'
where a topology can be considered as a fixed set of
patches in a predefined arrangement. In Ship design the
need for a topology can arise from a number of
considerations: the midship section should for practical
reasons be defined by two straight lines connected by a
curve; patches should be joined at a knuckle line; the
planar constraint (i.e. where parameter lines are in
co-ordinate planes) should be applied to the main portion
of the hull.
Here, therefore, is a method which a designer can
use to rapidly construct a starting point for his design.
1214
The naval architect can re~est types of bow forms, types
of sterns, length of parallel middle body, the existence
or not of a knuckle and any other features which might
affect the design. The program can be left to construct
an initial form by piecing together items from its
library of topologies, and so provide the designer with
a good starting point. It should also be possible to define
new topologies as the need arises and to store them in the
librar,y. This obviously achieves more flexibility than the
normal library of ships since the starting point is a
'composite' of a number of re~ired features. At the
same time all the flexibility of the surface design
program becomes available to make small modifications.
6. CONCIDSIONS
The central graphics operation of a complete intial
design process for ships has been described. Where
possible, the traditional approach to developing hull
forms has been parallelled by a graphics approach but in
this case a system with much mere flexibility than is
normally available with computer systems has been made
available. Where possible, the computer provides a
rapid feedback of design information, but there are no
restrictions on the designer in how he develops or changes
his design.
The use of an interactive graphics terminal has
thus given the naval architect the power of the computer
without removing his control over the design.

7 REFERENC ES.

1. 'Type 340 Precision Incremental CRT

Display" Digital Equipment Corporation
H-340.
2. Elliott, W. S., An interactive Graphic System using
Jenkins, A. P., Computers linked by Voice Grade
Jones, C. B. Line. See this volume, Part 2.

1215
3. 'Blohm and Voss "Pioneer" Ship'
Shipping World and Shipbuilder, April,
1968 p.661.
~. Coons, S. A. 'Surfaces for Computer Aided Design of
Space Forms' M.I.T. MAC-TR-41, July,
1967.
5. Flanagan, D. L.,
Hefner, O. V. 'Surface Molding - New Tool For the
Engineer' Astronautics and Aeronautics,
April, 1967.
6. Lee, T.M.P. 'A Class of Surfaces for Computer
Display' Proceedings of SJCC, 1969.
7. Armit, A. P. 'A Multipatch Design System for Coons
Patches' Cambrid.ge· University Maths.
Lab. December, 1968.

1216
 The all-round graphics system.
The new ICL 7300 Advanced Graphics
E1
System is powerful and comprehensive.
It can be used as a satellite to both ICL 1900
series computers and ICL System 4 computers.
The user has the advantages of a new
advanced graphics software package, a flexible
and comprehensive operating system,
a FORTRAN compiler and a very large
screen area. When used as a free-
ICL.
standing configuration, it has the same
software facilities.
The basic system consists of a
International Computers
Europe's world-class computer company
graphics console with a 22" diameter screen,
an ICL 7301 processor with 24K words of core
store; an EDS transport; console typewriter;
paper tape reader punch.
The system can be enhanced by
additional core store (28K or 32K words), line
primer, card reader/punch and second
EDS transport.
For full details write to
Mr. V. H. Cross, International Computers
Limited, Computer House, Snow Hill,
Birmingham.Or telephone 021-6435033.
 Ir you were one of tbe
1138 people who visited
tbe: CompugnpbJ
tud at the G 10
exblbitlon you wm be:
intefi d to note: tblt
IdJlomnow costs
£27,000 I teld of
£34,000.
You mlgbll.lsobe:
inlefi ted in
ompu raphi lat
developm ts In
rvi offered' 10
printed drcu1t IUd
lnttgJated circuit
d Ignc •
For r informa-
tion, Dr. Hlrr I the
man to talk to al
ompugnp ClI
tau do
ted
Croft
, CroftROId
Aldersbot
Tel: AId tll386
A "quick-look" facility to
c.omplement your mechanical
Incrementel plotter but much
more than lust this.
I High-speed Incremental plols.

Up to 8000 points on each axis.

• Variable mag.nlfic81ionend
"zooming." on either or both
axe• .
• Up to four display units
selectable manually or under
program control.
• Graphic Input feature facllitateB
program modification and
debugging .
, Software supported.
Exlst,l.ng applIcations
programs may be run
without modification .
• ' Direct. connection tolBM
1130 siorage Access
Channel. lnt,erfa.ce to other
ma.chlne8 avaIlable.
• Tektronix qual.ity engIneering . seles and Service throughout Europe, backed by the
'r'elOurces of·one ·o fthe world's leading electronic instrument manufacturer• .
PERMAN,ENTPA·PER COPIES Of AN·Y T400& DISPLAY AREMAD,E IN A FEW SECONDS WI'TH
THE. TEkTRONIX 4601 HARDCOPY UNIT.

AI'IO aYll1abl.....the T4OO2; I fr •••l1lnd ng lnl.rlctive gln.,11

ptlrJro" comput. terminaL
Full ASCU keyboard, Inlarlctlv. graphlc.a. oll·lIn.edlting
flellltin Ind mlny othe~ tlniqtll Illttl'''.

Write or phone for more information.

U.K. Enquiries : ,P.O.Box 69,
Ha~penden. , . Herts. Harpenden 61251 . Telex: 25559.
Other Enqu.iries: P.O. 8·0·x7718., schiphol Airport (East), The Netherlands.
Phone: 020·452165. Telex: 16665.
TEl . II BIT.nl ".1. P.lrt olth. world-wid. Tekllonht: organizet,lon.
 PracHcal compuler-aided design
The most
fl xlbl
h rdw r

The most
ext nsiv
softw r
Product deIogn

5 tellite
or
t nd- lone

r------..,
I I DISMA II
I I DOAR II
I Any I FR D II
QD Plot
I
I
I
m in
fr m
I
I
I
+ G APH P ck
COMMUNICATOR
T ••t dlt
I comput r I D. nOltle.
I I
L ______ ...JI
I Softw ,. 921 D'.pl Y

marc[]n.L
ELL.L[]TT
C[]mpUTEr
Marconi-Elliott Computer Systems Limited
the real-time data communicators

SYSTEmS
Elstree Way, Borehamwood, Herts
Telephone: 01 -953 2030 Telex: 22777
A GEC~Engli5h Electric Company LTD/C07
 The 430
is the first dataplotter to
understand curves.
Aswe11 as figures.
Electronic Associates 430
Da taplotter is the world's fastest
hybrid system capable of plot-
ting true curves as well as
straight lines.
It plots straight lines and
shallow curves at an incredible
20 inches per second. Sharp
curves smoothly at 5 inches per
second using the unique 'look-
ahead' facility. And never gives
you the saw-tooth 'curves' of
the conventional digital plotters.
You get this speed and a
resolution of 0.001"! You get 430 saves on-line computer
software to print special symbols, time in a big way. Or, if you're
to plot poin ts and to scribe alpha- off-line, it sa ves tape. Ei therway,
numerics. You get eithera you save cash for other things.
3l"x26"ora54"x76"plottingarea. So write, or phone and ask
And above all, you get re- us to show you a curve or two.
liability by using large-scale Theywon't bequite like the
integration techniques, and by ones in the picture, but we know
eliminating relays, mechanical you'll find them interesting.
choppers and linear feedback Electronic Associates Limited.
potentiometers. The 'data verify' Burgess Hill, Sussex. Telephone
feature ensures absolute Burgess Hill (04446) 5l0l.
positional accuracy. •. •.
The efficient, high speed Electromc Associates limited
 anders
a at1ce
sy te .
Unrivalled flexibility is the secret. It gives the Sanders
Advanced Data Display System/900 the ability to meet nearly
every display system need.
ADDS*/900 System interacts with analog, digital and
operator input. Information is processed and formatted, then
presented visually on up to 12 displays.
ADDS/900 System features a larger variety of display sizes
and speeds than any other comparable system available today.
High-speed vector, position and _character function generators
permit unrivalled density of displayed graphics and alpha-
numerics. ADDS/900 System offers rotation and translation of
data, and exclusive graphic overlay on TV or radar video data.
Data entry devices having a common interface for standard 1/0
data transfer include Photopen®, trackball, joystick, keyboard,
data tablet, and cursor control.
Sanders ADDS/900 System can solve your most demanding
display problem. We've got the hardware, interfaces and software
support. On the shelf. Whatever your data handling requirement
-from microimage retrieval to a complete data management
system---consider Sanders as your single
source.
Contact the Marketing Manager,
Sanders Associates Incorporated, Bury Mead ...-------1
Road, Hitchin, Herts. Tel: 0462-51185. SANDERS
ASSOCIATES, INC.
"TM.sandersAssociates.lnc.
IBM demonstration of graphics
in engineering and science

This IBM 1130/2250 Graphic Data Processing System was shown at Brunei
University in April. Visitors were able to experiment with the light pen,
using programs available from the system's Disk Storage.
The 1130/2250 is a powerful and direct method of man-machine
communication. It gives designers, engineers and research scientists
instant visual access to results of their computer programs. And the
information presented is in an immediately usable form. Using the IBM
Graphics Subroutine Package, you can easi Iy write your own programs. And
with the latest Disk Monitor Operating System, now available, the full
power and flexibilityofthis disk based graphics system is at your command.

IBM
The 1130/2250 can also be linked to IBM Systemj360 thus giving
access to the facilities of Operating System/360. If you would like a leaflet
and more information about the IBM 1130/2250, write to Mr. K. Parkes,
IBM United Kingdom Limited, 389 Chiswick High Road, London W4.
 A Berman, M. L. 735
Bijl, A. 433
Academy of Sciences, USSR, Computer Centre Blanking die & technology 179-193
701 Boeing Airplane Company 105
Adage (AGT) 109, 803, 831-850 Bootstrap cycle 171
Adams Associates 1070 Bown, H. G. 279
Advanced Research Projects Agency 905, 1119, Bracchi, G. 263
1143 Briabrin, V. M. 701
Aerodynamic design 201, 1095-1118, 1184- Britch, A. L. 463
1187 British Aircraft Corp. (BAC) 1095, 1179, 1200
Aero engine design 1200 British Shoe & Allied Trades Research Assoc.
Aiken Computation Laboratory, Harvard 1143 1200
Aircycle 170, 172-3, British Standards Institute 923
Air traffic control 58-59 Brookhaven National Laboratory 59-61
Analysis techniques 1018 Brown University 831, 851, 884
Analytical studies 562 Building component assemblies 463
Anderson, S. E. 717 Building design (See "Architectural design")
Animation, computer 327-344, 717-721, 723- Bunker-Ramo computer 562
730 Burgers' Equation 408
Application characteristics 4-7, 21-25, 46, Butlin, G. A. 947
58-65, 84-85, 111-113, 138-159, 201
Architectural design 263, 433-448, 477-486, c
513-529, 531-540, 541-551
Architectural practice 439 CADEP 263-277
ARDS terminals 858 Calcomp plotters 339, 444, 474, 638, 717
Argonne National Laboratory 681 California, University Dept. of Engineering
Armit, A. P. 1179 161
Armour, G. C. 531 California, University Graduate School of
Artwork generation, history of 314-6, Business Admin. 531
Atiyah, J. 301 Cambridge, University Computer-Aided De-
Attention handling 1049-1091 sign Group 11 79
Automobile hood linkage 155-156, CAMP System 316-324
Avionic design 202 Canopy design 1199
Avon High School project 516 Canton Junior High School Project 516
Car body design 1192
B Cardwell, D. W. 555
Carr, C. S. 549
Beeby, A. W. 923 Cement & Concrete Assoc. 923
Bell, D. A. 629 Chace, M. A. 115
Bell Telephone Laboratories 1119 Character displays 56-57
Bergeron, R. D. 831 Character recognition 614-617, 619
Berhold, E. D. & M. P. 161 Charts, production of 923-944
Chasen, S. H. 17

1225
Chromosome analysis 621, 624 Design wheel 545
Circuit analysis 279-299 Diagram generation 555-573
Colorado, University Computing Center 345 Digigraphics System Div., CDC. 635
Colorado, University Dept. of Civil Engineering Digital Equipment Corp (DEC) 71, 75, 92,
327 120, 281, 444, 546, 563, 726, 858, 883,
Colour displays 53 90S, 1203
COMDAC Project 487 Digital plotter 923-944
Commands, language 275 Digital television 49
Communications Research Centre, Canada 279 Direct program control 596
Communications techniques 30-33 DISGOL package 489
Computational array 166, 169 Display control devices 954-957, 962
Computek display terminal 724-726, 858, 880 Dot grid routine 164-166,
COMPUTE Routine 168 Dot matrix characters 56
Computer-Aider Design 18, 72 Dowe, R. J. 27
Computercentrics 22 Drafting machine 316, 323
Computer Displays Inc 858, 881 Duct design 1197
Computer Industries MTD plotter 324 Durachka, R W. 577
Computer Sciences Corporation 1070 DVST characteristics 854
Concomp Project 115, 120 Dynamic analysiS 115-160,
Construction routine 255-256
Control Data Corp. (CDC) 27, 29, 73, 105, I
107, 322, 339, 340, 347, 635, 637, 969,
Economics (See "Costs, Economics")
973, 974
Edinburgh, University Architecture Research
Cossor Cosprite text editor 659
Unit 433
Costs, economics, cost effectiveness 14, 19-
Electrocardiagram signals 622
20, 30, 45-46, 49, 104, 113, 526, 540,
Element symbols 93-100,
730, 852, 996, 1022-1031
Elliott 4130 444, 947
Cotton, I. W. 1049
Elliott 4280 1035
CRAFT Program 515-517, 531-540
Elliott, W. S. 71
Cramer, P. A. 531
EMILY system 681-699
Crawley, S. W. 541
Engineering drawing proceSSing 245-259
Crittall-Hope Ltd 489
Engineering tool 103,
C. S. I. R. 0., Australia 967, 969 Errors, line transmission 80-83
CUG 345-365 . Errors, recompiling 986, 989
Curve generators 875 Evans, D. C. 551
Cutrell, J. D. 327 Ewing, D. K. 245
EXEC 8 72, 73, 1203
D Exhaust manifold design 1196
DAD System definition 970
"Daisy chain" of events 21 F
Daly, C. J. 577 Falk, P. 887
DAMN System 119 Federal Aviation Agency 58
Data array 162, Federal Highway Administration ADP Branch
Data Language System (DL/1) 7 327
Data Reduction Laboratory, NASA. 577-580 Feeser, L. J. 327
Data structuring 775-802, 1039-1044 Ferenczy, J. 179
Datel72 Ferrari, D. 263
Debugging 735 File Handler 77-80
DeSign considerations 34, 108, 196 Film scanner 601, 602
Design Drafting (DD) 208-215 Fingerprint scanning 618
Design process 544 Flow control valve routine 174

1226
Fluid flow analysis 407
Foley, J. D. 1007,
Forrest. A. R. 1179
FORTRAN Packages 947-965, 967-993
Fractionator analysis 219-243
Freedman, R. A. 635
Fundamental problems 17-26
Future developments 11-15, 26, 37, 46-47,
65, 299, 536, 690-692, 712, 884, 959-
960, 1044
G
Garnett, A. 487
General model builder concept 799
General Motors Research Labs. 31
Generators, character & vector 861-862
Geometric variables 269
Geometry data base 247-249
Gerber 323
Gillespie, R. G.103
Giorgini, A. 407
Goddard Space Flight Center 577
GOFAST 219-243
GRAF Language 163
Graph generation 555-573
Graph theory 775-802, 905-921
Graphical Data System 50
Graphics Subroutine Package (GSP) 42,
Graphics Terminal Services (GTS) 9, 42
Graphic symbols 161-178
Graphic variables 272
H Image processing 617
Hamilton's Principle 127
Hansen, W. J. 681
Hardware, role of & configurations 10, 24-25,
35, 41, 71-73, 87-89, 109, 198-201,
229, 281-2, 303, 322-4, 339-341, 444,
546, 556, 562, 578-580, 595, 599-614,
629, 637-638, 655, 658-659, 717-718,
724-727, 805-813, 832-834, 851-885,
906, 947, 969, 972-975, 995-989, 1050-
1053
Harris Intertype Fototronic CRT 655, 659
Harvard Computation Laboratory 1119, 1143
Harvard Graduate School of Design 449
HASP priority monitor 138-140
Hazeltine Corporation 49
Hazlett, L. 313
Heat exchanger routine 173, 175
Herbst, N. M. 595
Hertfordshire County Architects' Dept 489
HICAMP, HICAMPER programs 718-719
Hidden line removal 334
Hierarchical data structures 778, 781-783
Highway engineering 327-344
H. M. Stationery Office 258
HPCG Program 136
Hubbold, R. J. 1035
Hungarian Academy of Sciences 179
Hypertext editing system 831, 851
IBM 2250 163, 463, 599, 655, 682, 717, 1058
IBM360 8, 41, 92, 107, 120, 198, 339, 463,
562, 563, 717, 726, 884, 1058
IBM7040 905
IBM 1130 13, 659
IBM1401595
IBM Advanced Systems Devit. Div. 887
IBM CRAFT 532
IBM Los Angeles Development Center 3
IBM Los Gatos Laboratory 887
IBM Scientific Subroutine Package 136
IBM Thomas J. Watson Research Center 595
ICG Systems 513
ICL4120489
ICL 4130 303, 371, 381, 1035
ICL System 4 474
IDIlOM hardware 578
IGS System 34, 35
Image description formats 814-822
Imperial College Centre for Computing &
Automation 71, 1203
IMS/360 7
Information Control Systems Inc. 1007
Information systems, nuclear safety 563
Input tablet 602
Integrated circuits design 313-324
Interdata Mod. 3. 884
Interface problems 25
International Computers Ltd (See also "ICL")
489
Interrogation techniques 1095-1118
Istituto di Elettrotecnica ed Elettronica,
Milan 263
1227
 J Marconi-Elliott Computer Systems Ltd 995
Markov analysis 1018
Jenkins, A. P. 71
John Hopkins University 717 Massachusetts Computer Associates Inc. 905
Mass storage 29
Jones, C. 487
MASTER operating system 34
Jones, C. B. 71 .. ~ McAllister, A. S. 887
McDonnell Douglas Corporation 195
K
McNamee, L. P. 161
KAM System 118 Mechanical networks, analysis of 115-160
Keyboards, Terminal 862 Merlin project 735-774
Korybalski, M. E. 115 Merlin Systems Corp. 735
Krueger, E. R. 345 Messages display 957-959
Meta System 735-756
L Michener, J. C. 851
Michigan, University of 115, 120, 138, 723,
Labelling 296-7,
1033
Laboratory for CG and Spatial Analysis, Har-
Microcoded programming 887
vard. 449
Milan Polytechnic 263
Lagrange's Equation 127-137
Minimum cost tree structure 790
Language design criteria 264
Ministry of Technology 245, 1203
Lavick, J. J. 195 Ministry of Technology, National Physical
Leckie, F. A. 397
Lab. 489, 629
Lee, T. M. P. 1119
Mixing duct routine 174
Leicester University Dept. of Engineering
ML language 735, 741, 744
367, 381, 397, 947, 1035
Mobil Oil Computer Communications Dept.
Library routine 293-6, 317 219
Light buttons 251-254, 280 Mona Lisa ripple picture 643
Limit loads 397
Monitor Systems 61
Linear differences curves 1143-1177 Moore School of Electrical Engineering 905
Line drawing 621 Moseley plotter 562
Links, computer 995, 997-999, 1029 Motorola Semiconductor Division 313
Link Handler 76 MTS time-sharing monitor 138, 726
Liverpool, University Dept. of Building Science
Multipatch design 1182, 1198-1200
463
Multiprogramming 28-29, 34
Load analysis 397-405 MVT 8, 41
Lockheed Georgia Company 17, 1201
Loft engineering 205-208
LOKAT 449-456 N
Longitudinal Strength Program 85
NASA 61, 62, 63, 577, 1070
LUISA 367-379, 949 National Engineering Lab. (NEL) 72, 1203
Lunday, P. A. 3
National PhYSical Laboratory 489, 629
Navier Stokes equations 407
M
Network analysis 1021-1022
MacCallum, K. J. 1203 New South Wales, University of 50
Machanik, J. W. 735 New York, University School of Engrg &
Maclean, M. A. 279 Science 775
Magazine composing 655-680 Northwestern University 118
Management approach 105-6 Nuclear reactor development 555-573
Manned Space Flight Center 50 Numerical control 215-217
Map analysis 621, 623 Numerical Master Geometry System 1107

1228
 o Program logic 223-229
Programmer considerations 43
Oak Ridge National Laboratory 555 Purcell, P. 487
Office of Naval Research 905, 1119 Purdue, Univeristy School of Civil Engineering
Olivetti teleprinter 658 407
Opaque document scanner 600, 602
Operating System/360 8 Q
Operating Systems, programs & languages
28-33, 58, 73-76, 110, 138-159, 162- QAS System 93
177, 180-191, 250, 282-297, 302-308, Quann, J. J. 577
316-322, 330-335, 347-361, 369-371, "Queues" 91
383-386, 449-461, 467-474, 490-512,
515-517, 532-535, 578-590, 597-598, R
608-614, 630-634, 638-650, 684-692, Racal Research Ltd 301
718-721, 727-729, 735-774, 838-849, Ranaweera, M. P. 397
892-895, 947-965, 967-993, 999-1001, RECOUP facility 43
1003, 1036-1047, 1049-1091, REDAC Software Ltd 303
ORACLE first generation computer 556 Refresh problem 852-853
OUtput specification 297-8 Reinforced concrete building design 3'81-395
Renault Systeme Unisurf 1192-1196
p Resedent core 29
Response time (See also "User considera~
Page layouts magazine 655-680
tions") 983, 1022-1031
Paging scheme 792
Rich, Phinney, Lang & Cote Inc 514
Panel displays 231-243
Ring structures, definition 778-779
Panel format 221-223
Rohn, J. 531
Parametric surfaces 1095-1118
Rolls Royce Ltd 41, 1200
Patch techniques 1181
Rome Air Development Center 905
Pattern recognition 595-627, 629-634
Royal College of Art, Industrial Design
PDP (See Digital Equipment Corp.)
Research 487
Pendry, B. 487
RUMOR program 449
Pendulum, dynamic compound 150-155
Rundle, A. R. 995
Pennsylvania, University 905
Performance routine 171
Perkins & Will 449 5
Perspective transformation 332 Sabin, M. A. 1095
Peters, B. 463 Sanders hardware 578
Philco Ford 64 Satellite displays 995-1006
Phillips, R. L. 723 SCADS scan pattern 614
Phosphor control loop 607 Schaefer, L. J. 803
Phosphor correction 605 Schiffman, R. L. 345
Photographic processing 729 School design 487-512
Picture processing 822 Science Research Council 367, 382
PIXIE System 1036 SCOLA 489
Plan layouts 449 Scottish Special Housing Assoc. 443
PLAN System 6, 13 SEAC Building System 489
Polaroid photographs 717 SELMA System 93
POLYGRAPHICS package 727 Sender, M. 487
Poole, E. J. 577 Sequential decision logic 629-634
Porter Goff, R. F. D. 381 Service d'Etudes Techniques des Routes et
Printed circuits 301-312 Autoroutes de France 340
Productive environment 41, 103 Sewell, D. S. 219

1229
 Shearing, G. 967 Turbine routine 173
Shellans, S. 735 Turbulence model dynamics 407-430
Shepherd, B. J. 887 Turner, F. C. 342
Sherr, S. 49 Two-dimensional drawing 1021
Ship'S design 84, 1203-1216 Two-dimensional patterns 263
Shoe last design 1199
Shut-off valve routine 174 U
SIGMA 7 time sharing system 282 UMMPS supervisory program 138
Signal processing 595-627, 635-651 Union Carbide Corporation 555
Sirius computer 924 Unisurf System 1192-1196
Smith, P. 41 Univac 71, 546, 578, 1049, 1070, 1119, 1203
Software (See "Operating systems, Urban planning 263
programs & languages") U. S. Air Force Contract 1032
Software design 803-829, 831;. . 850 U. S. Atomic Energy Commission 555, 681
Soil engineering 345-365 U. S. Dept. of Defense 1119, 1143
Space science displays 577-591 User considerations & reactions 42, 104, 112,
Sperry Rand Corp. 1049, 1119 199. 220-221, 279-281, 298, 350, 434-
Stein, J. R. 345 439, 514-515, 556, 577-578, 682, 804,
Stereoscopic animation 720 897-900, 907-908, 984-986, 989-990,
Steuber, P. 655 1049-1050, 1189
Storage tube terminals 851-886 Utah, University 541, 1119
Stromberg Datagraphic film recorder 717
Structural analyses 202-204 v
Structural building data 381-395
Van Dam, A. 831, 851
Structural design 367-379
Varian computer 587
Structural optimization 204-205
Video systems 853
Sun Printers 655
Viewing, film 729
Surface design 1179-1202
VISPLAY system 967-993
Surface dragging 1197
Visualization 257
Surface moulding 1191
Voice grade line 71, 1029
Surface representation 1119-1141
Sussex Research Associates 531
Systems design of terminals 1007-1034
w
Systemshare 444 Wall, P. K. 301
Systems support 8 Walter, P. E. 477
Washington, University Computer Center 103
T Water separation routine 174
Taylor, H. P. J. 923 West Sussex C. C. Architect's Dept. 477
Tedd, D. W. 245 Will, P. M. 595
Tektronix Inc 858, 879 Williams, J. H. 513
Tensor representation 1119-1141 Williams, R. 775
Text editing 655-680, 681-699, 701-713, 747, Windowing comparisons 878
831, 851, 1021 Wolfberg, M. S. 905
Text reading 614-617 Wood, J. 487
THREAD 245-259
Three-dimensional drawing 1021, 1035-1047 x
TIES 327
X-ray movies, study of 621
Timing experiment 983
Torson, B. T. 41 y
Tree structure, graphic representation 778,
780, 783-795 Young, A. G. 367

1230