Satellite graphics terminals, which include amicro or minicomputer to perform interactiveprocessing, present a number of advantages-not the least of which are accessibility andresponsiveness. This paper describes two basictypes of satellites and outlines techniques forbest exploiting their capabilities.

A Tutorial onSatellite GraphicsSystemsJames D. FoleyBureau of the Census*

What is a satellite graphics system?A satellite graphics system is a three-processor

computer network, as shown in Figure 1. The hostis usually a large multiprogrammed or timesharedcomputer system, and the satellite is usually de-dicated to servicing the one or more attached dis-play consoles. It may be a microprocessor or a ratherelaborate minicomputer system. The display proces-sor generally has very limited general-purpose com-putation capability, and may be a primitive point-plotting system or a sophisticated high-performancesystem. The communications link rmight be a high-speed path to the host's main store, a dial ordedicated phone line, or a packet-switched network,with a transmission speed typically from 1K bits/secto 1M bits/sec.An essential aspect of a satellite graphics system

is the potential for frequent host-satellite interac-tion at a rate of several times a mninute to many timesper hour. This precludes from our consideration therelatively straightforward though useful mechan-ism of infrequently batched transmission of graph-ical information between host and satellite.

Why satellite graphics?

The satellite configuration shown in Figure 1 isjust one of several possible system configurations.

*This paper was written while the author was at the Universityof North Carolina.

At one extrerne we have dedicated standalone sys-tems, with enough computational capability, mainstore, and backing store to accommodate the wholeapplication. Such a configuration is particularly wellsuited for those applications, like drafting, withrather modest and consistent requirements forcomputational and storage resources.At the other extreme, we have the large multi-

programmed or timeshared computer that directlysupports one or more display consoles as well asother interactive terminals. The display consoles areeither refreshed directly from main memory, orperhaps from a separate refresh buffer. Massiveresources can be provided on a shared basis.

DISPLAYCONSOLE(S)

Figure 1. Typical satellite graphics system

14 COMPUTER

Satellite systems fall between these two extremes,seeking to exploit the advantages of both systemswithout suffering their disadvantages. Among thepotential advantages to satellite graphics, derivedin large part from the literature, 1-3 are:

Accessibility. The satellite terminal is often con-veniently located in the user's laboratory or office,rather than at the computation center some (pos-sibly large) distance away. Accessibility is oftencited as the major motivation for installing graphicssatellites.

Control. The user has a larger degree of controlover the graphics system. Contention for resourcesis reduced; less interuser interference occurs from asatellite than from a display processor directlyconnected to a large timeshared or multiprogrammedhost.Minicomputer availability. An existing mini-

computer can be used for nongraphics work.Resource conservation. The host is not burdened

with processing trivial user interactions which mayoccur frequently, would require much operating sys-tem overhead for task-switching, but need very littleactual processing.Resource sharing. Some applications require infre-

quent but massive computations. Sometimes thehost can be used to provide these resources at lowercost than can the satellite, because of both thesharing and economies of scale.Response. The satellite is able to respond imme-

diately to many user actions independently of thehost. Response is also a major reason for usingsatellites, especially if the host operating system isbatch-oriented.Economics. Money can be saved by the above

resource conservation, since use of the satellite forsome classes of work is more cost-effective than useof the host.Host independence. If the host be unavailable,

some interactive work on the satellite may stillbe possible. Picture changes must be saved foreventual transmission to the host.

Compatibility. The satellite's minicomputer canbe used to emulate other terminal devices, such asstorage tube displays, without modifying the hostcomputer's graphics subroutine package.Data base sharing. A single data base can be

centrally maintained, yet be easily accessed frommany different locations.

In many ways, these are just the advantages ofdistributed computing networks, of which satellitesystems are instances. Usually only a subset of theadvantages will be relevant to a specific application:if the subset is quite small, or of little weight,then satellite graphics might not be the proper ap-proach.

Satellite graphics is not without its difficulties.The two CPU's mean additional hardware and soft-ware to install, maintain, and manage, plus theprobable need to deal with several computer vendorsand a communications services vendor. On the otherhand small computers tend to be relatively reliable,and some display manufacturers do offer softwarepackages to support satellite systems.

Design considerations

Designing a satellite system for a specific applica-tion and operational environment requires numer-ous interrelated decisions about the system's hard-ware and software. Each of the hardware subsys-tems shown in Figure 1 must be selected. A graphicssatellite and its host constitute a two-computernetwork, with one or both computers having a hier-archy of storage devices, from main store to fixedand moving-head disks. Thus processes (programsand subprograms) must be assigned to the two pro-cessors, and data must be allocated to storage de-vices. A "division of labor" between the host andsatellite must be established.In making these decisions, the designer of a satel-

lite graphics system usually contends with two con-straints which in large part dictate the feasible de-signs. These constraints are cost and performance.One-time capital costs and recurring hardware

maintenance changes are relatively easy to deter-mine. Software maintenance and host computercharges for CPU time and memory space are moredifficult to estimate. Yet the design of the system'shardware and software affect all these cost factors.Performance has several dimensions, the most im-

portant of which is response time. Response timerequirements differ greatly for interactions at thelexical, syntactic, and semantic interactions, asdescribed by Wallace:4

At the lexical level are those things which are doneby reflex, either natural or trained. It appears thatour time to perform such actions goes down to about50 ms, which approximates the period between keydepressions for a very fast typist. [This figure looselycorresponds to one provided by Miller.5] To be useful,system response to lexical actions must be withinthe same time interval, since human psychology doesnot tolerate interruption of reflex actions.At the syntactic level are the semiconscious actions

by which sentences, or complete thoughts, are con-structed. The basic elements meaning "add a 5 ohmresistor between this node and that node" would beconstructed more deliberately than the lexical con-struction, because the user is forming his "idea"as he works. Time intervals of approximately 1 sseem most characteristic of syntactic actions. Thesystem's responses to them are correspondingly lessexacting, with a half-second delay being entirely ade-quate, while often even 2- to 4-s delays are tolerated.The semantic level involves requests of major im-

port for which the user expects "thoughtful" answers.Semantic actions are completely conscious actions,and may take tens of seconds and more. The tol-erable response time appears to be highly variable. Ifthe action were the sentence "Hello, I'm Joe," itwould be disconcerting to wait more than 2 s for theresponse, "Hi." On the other hand, a request to dis-play the minimal energy bond in a complex moleculecould take 10 s or more without a user losing his trainof thought.

The activities of choosing a hardware and a soft-ware system are not orthogonal; they are intimatelyintertwined. A division of labor which handles lexi-cal, syntactic, and semantic interactions on the satel-lite represents a heavy processing load and requires

AugusZt 1976 15

a large satellite; conversely, a minimal satellite withlittle main store and no backing store can usuallyhandle only some lexical interactions.

Program structures

Figure 2 represents the structure of a typical in-teractive graphics application program. The lexicalprocessing functions are separated from the main-line interaction monitor, and are further divided intothose handled by the graphics support package andthose handled by the application program. Thissubdivision of lexical processing tasks will be veryimportant in the discussion of the division of laborin some types of satellites. Lexical processing in-cludes light pen tracking, dragging, sketching, textinput/echo/edit, and cursor movement; a more com-plete list is given in the following section. How-ever the lexical processing is done, it may requireaccess to routines which modify the display pro-cessing unit (DPU) program, perhaps to the trans-form/clip routines, and to the correlation table. Thistable identifies specific sequences of DPU instruc-tions with a name provided by the application pro-gram, so the DPU program can be modified inresponse to user interactions. Any user actions nothandled by the subroutine package's lexical pro-cessing are queued for the application program,where additional lexical processing and syntacticand semantic processing will be performed.

r T.APPLICATION PICTUREDATABASE DATABASE F.n

BUILD,MODIFY BUILD, MODIFYINTERROGATE INTERROGATE

SEMA TIC PROCESSING:ANALYSIS PROGRAMS

DEVACICPOESSIG ICTUR

MAIN-LINE INTERACTION 4 DATA BASEHANDLER TRAVERSER

ATTENTIO ,QUEUE LEXICAL PFROCESSING:..-m >PERFORMED BYAPPLICATION +-

TRANSFORMA-PROGRAM \ PTIONGACLIP

r. J

Proram an onrlf/o DP

ar~.~IrL_--nnrnR ItrIrtjr

ICORRELATIONI |SUFFER MANAGEMENT1TABLE

INFPUT DPU_J-__DEVICESIDP IPROGRAMI

Data and data N/owsprograms and control flow DPU

Figure 2. Typical interactive graphics (annliation nroaram s:trucrtulre

Syntactic processing may include prompting, en-abling of input devices, interpretation of valuesfrom input devices in the context of the applica-tion, and simple modifications to the data baseand DPU program. Operations which require dif-ferent views of displayed objects, or which requiredisplay of new objects may require traversal of thepicture data base. Semantic processes usually ac-cess much of the data base and perform signifi-cant computations, as typified by analysis of anelectrical network or of a ship's hull design. Seman-tic processes might display a single number or agraph, modify the data base, or modify the previouslydisplayed image.

Details of the application program's structure willvary from application to application, and from onedisplay processor to another. For DPU's whichdirectly execute from the picture data base, the lex-ical processes will update the displayed image bymodifying this data base. Some applications likedrafting may have no semantic functions incorpo-rated into the system.The satellite system designer must decide which

processor will be assigned each of the processingtasks and which memory device will store each database. The possibilities for distributing processingtasks between the satellite and the host are many,but two major categories have been identified. Theseare the fixed-function satellite and the program-mable satellite. These are sometimes called the "in-telligent terminal" and "intelligent satellite," res-pectively. They are described at length in the nexttwo sections.The fixed-function satellite, so named by Kilgour6,

is seen by the host's graphics application programas a "black box" whose behavior is essentially fixedand unvarying. The application program may con-trol the satellite's behavior by enabling or disablingvarious functions, or by setting parameters used byalgorithms executing in the satellite. But still, thesatellite can perform only a certain predeterminedset of functions with which the application pro-grammer must be satisfied. The programmablesatellite remedies this problem. The applicationprogrammer has direct access to the satellite, andhas at least partial control over the division oflabor.

Fixed-function satellites

The application programmer controls the fixed-function satellite through calls to a graphics sub-routine package. The graphics package implementerfixes the division of labor, programming some of thepackage's functions on the satellite, some on thehost. Changing the division of labor often requiresthe skills of a system programmer. With the ap-plication program executing exclusively on the host,large amounts of picture description/modificationinformation will be sent across the communicationslink. Whatever can be done to minimize the lengthand frequency of such messages can thus have animportant influence on response times.

COMPUTER

apa,luyatmoll. ..

'16

Because the application program executes ex-clusively on the host, many user actions will needto be reported to and serviced by the host. Beforethe application program actually receives the report,delays are likely from one or more of the follow-ing: operating system task scheduling and switching,waiting for higher priority tasks to release the CPU,and program roll-out/roll-in or page swapping. Suchdelays can be debilitating and should be avoidedwhenever possible. Ideally, host operating systemsshould be structured to eliminate such overheadfor at least a majority of interactions. Since this isoften not the case, the alternative is to maximize thenumber of user actions which can be processed bythe satellite, thereby minimizing the number ofactions processed by the host. User actions processedby the host will be called "significant events"; theirnumber is to be minimized, especially for lexicalactions, all of which require quite rapid response.

The minimal system. Any satellite must haveresident a certain minimum set of programs anddata to function at all. The data required is justthe DPU program, whereas the programs are devicedrivers for the display, communication link, andoperator interaction devices, along with a simpleexecutive with the following basic functions:

(1) pen tracking, if a light pen is available;(2) cursor positioning in response to movements

of locator devices such as mouse, joystick, tablet'spen, or keystrokes, if any of these devices exist;

(3) accept new DPU programs or portions thereoffrom host, to be stored in satellite's memory atlocations specified by host;

(4) provide host, when asked, status informationsuch as the -current position of the tracking cross,cursor, mouse, or joystick;

(5) report to host each significant event's use ofinteraction devices, and device status.

Figure 3 shows the division of labor for this"minimal fixed-function satellite." The host buildsand modifies the DPU program, allocates memoryin the satellite, and is informed of many, but not all,user actions. The significant events reported to thehost would include pen detect (other than tracking),loss of pen tracking, and keystrokes on the alpha-numeric keyboard and on other devices such as pro-grammed function keyboards. The only user actionsnot reported to the host are those involving move-ment of the tracking cross or other cursor(s).These are, however, actions which can occur fre-quently.By adding functions to this minimal system, in

ways described below, the length and frequency ofmessages sent between the host and satellite can befurther decreased.

Data compression. The goal is to send the satel-lite efficiently encoded display information, which isthen expanded into DPU code by the satellite. Forinstance, graphs are sent as an initial (X,Y) loca-tion, an X increment, a point count N, and then

the N ordinate data values. Arcs are sent as acenter point, and starting and ending points. Textis sent as ASCII or EBCDIC codes and then, if nec-essary, expanded into series of short line segments.A dashed line is sent as two end points plus aline type code. Other graphics primitives which canbe used to effect data compression are graph grids,conic sections, parametrically represented surfaces,and subpictures.Some, but not all, DPU's have instructions to

handle exactly these and similar sorts of graphicsprimitives. The instructions exist as a means toshorten DPU programs, decrease the DPU's load onthe satellite's memory bus, and to increase theDPU's flicker-free drawing capacity. To achievedata compression, satellite software can be used tosimulate unavailable DPU instructions.For any of these primitives to be used, the graphics

package must actually make them available to theapplication programmer. There is thus a very strongand close, but often neglected, relationship betweenthe design of fixed-function satellites and the de-sign of the graphics subroutine package (or otherlanguage) used to drive the satellite.

Eliminating redundant transmissions. The sub-picturing mentioned above can be considered as onemeans of eliminating transmission of redundantdata to the satellite. A description of the subpictureis sent just once. Then for each instance of the sub-picture, only a reference to the subpicture and the

r- -T ,-

APPLICATION PICTUREDATABASE DATABASE

.

___,__L___IL______ -.i

INPUTDEVICES

Data anddate f/owPrograms and confro/ f/ow

Figure 3. Division of labor for minimal andmaximal fixed-function satellites

August 1976 17

instance's position, scale, orientation, and- other at-tributes need be transmitted. This can also be donewith picture macro-definitions.Many graphics packages allow a displayed picture

to be logically divided into disjoint parts, usuallycalled segments. By properly segmenting the pic-ture, it is possible to minimize the number and sizeof new segments which must be sent to the satel-lite to effect picture changes. Any picture partwhich may be displayed at various times during aninteractive session can be defined as a segment,transmitted to the satellite once, and turned on andoff by the application program, as necessary. Seg-ments which are "off" can in theory be written tobacking store, although in practice this is seldomdone. Picture parts which can be easily treated thisway are menus, prompts, and error messages.The notion of segments is also useful if the satel-

lite drives a direct-view storage display. Segmentsare maintained in the satellite's memory. When asegment is to be erased from the display, the entireremaining picture need not be retransmitted from thehost to the satellite for redisplay. This approach isused in the Bell Labs GlOl system7 and the LosAlamos system.8In summary, there is a significant potential for

decreasing data transmitted from host to satellite.As with data compression, the graphics subroutinepackage used by the host's application must bestructured so that the potential can be realized. Un-fortunately, much contemporary fixed-function satel-lite system software either is not appropriatelystructured or else is structured to only take advan-tage of one DPU's actual hardware. The singlealmost universally used concept is that of tempora-rily removing segments from the refresh cycle.

Servicing user interaction in satellite. Anotherway to improve the performance of fixed-functionsatellites is to use the satellite to service as manyuser actions as possible, thereby reducing the num-ber of such actions reported to and serviced by thehost. The user's lexical actions are primary candi-dates for satellite servicing. They occur frequently,require fast response, usually use memory space andCPU time sparingly, and can almost always be struc-tured in a way which is completely independent ofthe syntax or semantics of any particular applica-tion program. Indeed, the name "lexical" was chosenby Wallace4 partially in recognition of this separa-bility. The term implies that standard system soft-ware can be used to handle simple actions and feed-back for all applications. Only those lexical capabili-ties built into the graphics support package can beconsidered for implementation on the satellite, sothe support package's design is again of criticalimportance.A partial list of lexical actions which might be

processed by the satellite is pen tracking; cursormovement; control of an object's scale, position,orientation, or other attributes dynamically by useof knobs, dials, pens, styli, etc.; automatic in-tensification of the object being detected by lightpen or other pick devices; unconstrained or con-

18

strained (horizontal, vertical, oblique) rubber bandline drawing; sketching (inking); simple text entryand editing using character delete and line deletekeys; and continual display of potentiometer values.Most existing systems provide at least a few ofthese capabilities, and several systems provide areasonably broad selection.Figure 3 shows the division of labor for a "maxi-

mal fixed-function satellite"-one which implementsall the techniques described in the preceding discus-sions. All application-dependent code and data, aswell as some graphics system code, remain on the host.

Typical systems. A number of existing fixed-function satellites are described in the literature.Dill and Thomas' system9 uses a 16K byte PDP-11and GT40 display, with a 1200 bps communica-tions link. The link is judged too slow for experi-enced users of certain application programs. Kellnerand Maas8 describe a microprocessor-based systemwith 13K bytes of main store, a floppy disk,Tektronix 4014 DVST display, and 1200 bps link.Woodsford'0 describes two satellites, one with a 20Kbps link, the other with a 4.8K bps link. TheARPA graphics protocol,11 which can be thought ofas a definition of a fixed-function satellite, hasbeen at least partially implemented on several satel-lite systems.

Several popular device-independent graphics sub-routine packages support fixed-function satellites,and include the satellite software. GPGS1213 can beused with a remote PDP-11 and Vector Generaldisplay. GINO-F14 can support IMLAC, GT-40, andVector General displays. The GC5116'6 package canbe used with IMLAC displays. Graphics systemmanufacturers also offer fixed-function systems.The author knows of systems offered by VectorGeneral, CDC, DEC, and IBM.

Programmable satellites

No matter how capable a fixed-function satellitesystem may be, it is intimately tied to the host,where some lexical and syntactic and semanticprocessing are performed. Programmable satellites(also called intelligent satellites) offer a means ofbringing some (or in special cases, all) of the syn-tactic and semantic processing to the satellite.This can further decrease system response time,usually at additional cost for system hardware.

Basic divisions of processing and data. With aprogrammable satellite, all functions incorporatedinto the graphics package are implemented in thesatellite. The application programmer controls thedivision of application code between the two com-puters. The major consideration, then, is how theapplication program is divided between the twoprocessors. The first component of application code(Figure 2) likely to be moved to the satellite isthe lexical processing not performed by the graphicspackage. This increases responsiveness by decreasingcommunications link traffic. Next to be moved to

COMPUTER

the satellite would be some or all of the main-line interaction handler.This now presents a problem. The data base is

accessed by three programs: syntactic processing,semantic processing, and the picture data base tra-verser. The first of these programs is now satellite-resident; the other two, host-resident. Where shouldthe data be: at the host, at the satellite, duplicatedin whole or in part, or distributed between the-twocomputers?There is no simple answer to the question:

answering it requires a thorough familiarity withthe application program, and knowledge of how ofteneach of the three programs accesses the data as wellas how much data is transferred on each such access.Simple computations can then estimate lower boundson response time for various communications linksand bulk storage devices.

more languages, and communications protocols. Itis for these reasons, plus the higher cost of the largersatellites needed to support application programs,that relatively few programmable satellites existoutside universities and research labs. Programmablesatellite systems have been described by Bruce,Corman and Moulton17'18 (DEC); Cotton and Great-orex19'20 (Univac); Chistensen, .Ninke, and Pinson21'2(Bell Telephone Labs); van Dam, Harrington, Michel,and Stabler3,2" (Brown University); Foley and Ham-lin2m28(University of North Carolina); Kulick29(University of Pennsylvania); and Ross et al.30(MIT). Sunmaries and evaluations of many of thesesystems appear in the literature.1'3'27'31Three criteria are sometimes used to evaluate pro-

grammable satellites:(1) how effectively the host is unburdened of lexi-

cal processing tasks, and how capable the system isrif vnxr;linc fciatL roer%netnaflawinl LiLr int.Lr-

In one typical division, the picture data base actions;might be stored at the satellite, the application data (2) how easily the application programmer canat the host. Since the two data bases are typically distribute and redistribute processing tasks andnot disjoint, some duplication of information will data between the host and satellite; andoccur. The application programmer must take care (3) how easily the programmer can learn to usethat all updates of this duplicate information are the system.performed on both data bases. This is sometimesreferred to as the synchronization problem: two data These criteria are best met by the systems de-bases must be kept synchronized one with another veloped at Brown, DEC, and the University ofeither continually or at least when the data is North Carolina. The DEC system is used with twoaccessed. The converse problem, that of two pro- different satellites: a PDP-11 and GT-40 display,grams simultaneously trying to modify the same or a PDP-11 and VT-15 display. Each processordata base element, can occur whenever concurrency uses about 48K bytes of main memory, a 10K(parallelism) exists between the host's and satel- bps link to the PDP-10 host, and no backinglite's application program modules. store. The application program is written in aThe "data structure distillate" method is often high level language like Algol. ON-blocks in the

used. Information is sent to the satellite describing program contain functions assigned to the satellite,only that portion of the picture currently being and are coded in a special language with an Algol-displayed. The satellite can send user-caused changes like syntax. The semantics of the special languageback to the host either as they occur or in batches, allow interaction handling and picture creation andor it can send the entire modified distillate back~~ ~- modification, but exclude general-purpose computa-to the host, to be used in updating the permanent tion.data base. The Brown and University of North Carolina

systems have important differences in implementa-So long as the picture data base is at the host, tion techniques but share a common purpose: to

the picture data base traversal process and the allow an application programmer to write with atransform/clip process should also be host-resident, single general-purpose language with minimal re-unless the link is fast and the host CPU's effective gard for the existence of two CPU's. Once written,speed is rather less than that of the satellite CPU. each program module can be assigned to executeThis avoids transmitting picture elements which are on either the host or satellite. Further, the initialsubsequently discarded as being outside the view- program configuration (division of labor) can being window. At the same time, though, the very later reconfigured or changed, with no reprogram-same data compression techniques discussed earlier ming. The programmer never explicitly deals withcan be used to further decrease the communica- interprocessor comnunications.tions link load. The Brown system (ICOPS, for InterCOnnectedA viable division is to keep only the application Processing System) allows interprocess communica-

data structure and semantic processing routines at tion through subroutine calls and passed param-the host. Many real applications are so structured, eters. The hardware includes an IBM 360/67 host,since the link to the host is much less crucial than a 50K bps link, a 64K byte microprogrammedwith most other divisions of labor. Furthermore, Digital Scientific Meta 4 satellite, disk, and a dis-the satellite can usually give faster response to play processor consisting of a second Meta 4lexical and syntactic interactions than can the host. driving a Vector General. The programming lan-

guage is Algol-W.Existing systems. Programming a satellite graph- The University of North Carolina system (CAGES,

ics system can be a nontrivial task. The programmer for Configurable Applications for Graphics Employ-may have to learn two operating systems, two or ing Satellites) supports interprocess communica-

August 1976 19

tions by subroutine calls and passed parameters,and by references to variables known to both hostand satellite. Hardware includes an IBM 360/75host, a 2M bps link, an 88K byte PDP-1 1/45 withdisk, and a Vector General display processor. Theprogramming language is a PL/I subset.This "configurable programming" approach to

the use of programmable satellites has a number ofdesirable attributes, as has been pointed out byHamlin and Foley.26 First, a single programminglanguage is used. The language processors can pro-duce executable code for either the host or satellite.Second, the application programmer does not ex-plicitly program inter-CPU communications. Suchcommunications are automatically provided by therun-time system whenever a reference to a non-resident procedure or data element is made. Theprogrammer continues to use the familiar subroutinecall or data reference to implicitly initiate the com-munication. Third, performance data can be used tofine tune the division of labor, minimizing responsetime, host usage charges, or some other metric.Fourth, the programmer can conceive of and

write the entire application program as a unit,as if it were going to be executed only on onecomputer, without knowing its eventual configura-tion. For execution efficiency, however, he maywant to be aware when designing the program struc-ture that it will eventually be distributed. He mayalso want to optimize performance for what heconsiders to be likely configurations. Fifth, programconfigurability is a necessary but not sufficientcondition for program portability among dissimilarhost-satellite systems. When programs are movedto another satellite graphics sytem, they may en-counter drastic changes in the size of the hostand satellite computers. Some parts of the appli-cation program may have to be moved from thesatellite to the host due to memory limitations orother restrictions on the satellite.The major disadvantage of this approach is that

more complex system software is required than withthe DEC or fixed-function systems. Program de-bugging is complicated by the distributed processingnature of the system, and because the programmermust know two sets of operating systems,debugging tools, and techniques.

Summary. Programmable satellites can improveperformance beyond that of fixed function satellites,by moving function and data to the satellite. Dis-tributed processing systems, when used as a basefor programmable satellites, give considerable flexi-bility to the application designer.

Conclusions

Of the several motivations for using satellitegraphics systems, the most persuasive tend to beaccessibility, resource sharing, data base sharing,and response. Fixed function satellite graphicstechnology is well-developed, and is available in avariety of forms. Its use will likely continue togrow rapidly in coming years.

20

Programmable satellite graphics technology drawson and is closely related to general distributedprocessing technology, and the two will likely growtogether.A more detailed discussion of this material

appears in another work by the author.31E

References

1. J. D. Foley, "Software for Satellite Graphics Systems," Proc.of theACM1973Annual Conference, pp. 76-80.

2. A. R. Rundle, "Software for Satellite Graphics," Proc.Computer Graphics '70.

3. A. van Dam and G. M. Stabler, "Intelligent Satellites forInteractive Graphics," Proc. AFIPS, 1973 NCC, Vol. 42-,pp. 229-238.

4. J. D. Foley and V. L. Wallace, "The Art of Natural GraphicMan-Machine Conversation," Proc. IEEE, Vol. 62 (4),April 1974, pp. 462-470.

5. R. B. Miller, "Response Time in Man-computer Con-versational Transactions," AFIPS Conf Proc. 1968 FJCC,Vol. 33, pp. 267-277.

6. A. C. Kilgour, "The Evaluation of a Graphics Systemfor Linked Computers," Software Practice and Experience,Vol. 1, 1971, pp. 259-268.

7. S. Pardee, P. Rosenfeld, and M. Dowd, "G11-ARemote Time-Share Terminal with Graphical OutputCapabilities," IEEE Transactions on Computers, Vol.C-20 (8), August 1971, pp. 878-881.

8. R. Kellner, and L. Maas, "A Developmental System forMicrocomputer Based Intelligent Graphics Terminals,"Proc. 3rd Annual Conference on Graphics and Inter-active Techniques, Philadelphia, 1976, pp. 137-142.

9. J. D. Dill and J. J. Thomas, "On the Organization of aRemote Low Cost Intelligent Graphics Terminal," 2ndAnnual Conference on Computer Graphics and InteractiveTechniques, Bowling Green, Ohio, 1975.

10. P.A. Woodsford, ''The Design and Implementation of theGINO 3D Graphics Software Package," in Software-Practice and Experience, Vol. 1, 1971, pp. 335-365.

11.

12.

R. Sproull and E. Thomas, A Network Graphics ProtacoL

L. Caruthers, and A. Van Dam, General Purpose GraphicSystems User's Tutorial; Katholieke Universiteit, Nij-megen, The Netherlands, July 1973.

13. L. Caruthers, D. Groot, E. Hermans, and J. Patberg,GPGS Reference Manual Rev. 1, Feb. 1975. TechnischeHogeschule, Delft, and Katholieke Universiteit, Nijmegen,The Netherlands. (Originally issued 1972.)

14. GINOF Reference Manual; Computer Aided Design Centre,Cambridge, England.

15. Introduction to the Graphics Compatibility System,United States Military Academy, West Point, New York.Available from NTIS, AD-778750.

16. R. Puk, GCS-The Graphics Compatibility System,Computing Center, Purdue University, Lafayette, Indiana,August 1975.

17. S. Moulton and P. Cornian, "Remote Progranmabilityof Graphic Interactions in a Host/Satellite Configuration,"Proc. 3Sd Annual Conference on Graphics and InteractiveTechniques, Philadelphia, 1976, pp. 204-211.

18. E. Bruce, "Device Independent Interactive Graphics ina Time-Share Environment," Proc. European Computing

COMPUTER

Conference on Interactive Systems, London, Sept. 1975,pp. 109-125.

19. I. W. Cotton and F. S. Greatorex, "Data Structuresand Techniques for Remote Computer Graphics," Proc.AFIPS 1968 FJCC, Vol. 33, Part I, pp. 533-544.

20. I. W. Cotton, "Languages for Graphic Attention Handling,"Proc Computer Graphics Symposium, Brunel University,1970.

21. W. H. Ninke, "A Satellite Display Console System for aMulti-Access Central Computer," Proc IFIP Congress,Edinburgh. 1968.

22. C. Christensen and E. N. Pinson, "Multi-Function Graphicsfor a Large Computer System," Proc. AFIPS, 1975 FJCC,pp. 697-711.

23. J. Michel and A. van Dam, "Experience with DistributedGraphics Processing on a Host/Satellite System," Proc. 3rdAnnual Conference on Computer Graphics and InteractiveTechniques, Philadelphia, 1976, pp. 190-195.

24. G. M. Stabler, A System for Interconnected Processing, Ph.D.Dissertation, Brown University, Providence, Rhode Island,1974.

25. A. van Dam, G. M. Stabler, and R. Harrington, "Intel-ligent SateUites for Interactive Graphics," Proc. IEEE, VoL 62(4), April 1974, pp. 483-492.

26. G. Hamlin and J. D. Foley, "Configurable Applications forGraphics Employing Satellites (CAGES)," Proc. 2nd AnnualConference on Computer Graphics and Interactive Techniques,Bowling Green, Ohio, 1975, pp. 9-19.

27. G. Hamlin, Configurable Applications for Satelite Graphics,Ph.D. Dissertation, University of North Carolina, ChapelHill, 1975.

28. G. Hamlin, "Configurable Applications for SatelliteGraphics," Proc. 3rd Annual Conference on ComputerGraphics and Interactive Techniques, Philadelphia, 1976,pp. 196-203.

29. J. H. Kulick, THEMIS-A Distributed Processor GraphicsSystem, Ph. D. Dissertation, University of Pennsylvania,1972.

30. D. T. Ross et al., "The Design and Programming of a Dis-play Interface System Integrating Multi-access and SateUiteComputers," Proc. ACM/SHARE 4th Annual Design Work-shop, June 1967.

31. J. D. Foley, "The Design of Satellite Graphics Systems,"in Data Structures in Pattern Recognition and ComputerGraphics (A. Klinger, ed.), Academic Press, New York, 1976.

James D. Foley has just joined the Bureauof the Census, where he wiU help developinteractive color raster display systems forcartography and presentation of demographicdata.

Previously, he was on the computer sciencei faculty at the University of North CaroLina,

Chapel Hill, where he conducted research indistributed processing, system modeling,and computer graphics, especially satellite

graphics, device independence, and human factors.He received the BS degree in electrical engineering from Le-

high University, Bethlehem, Pennsylvania, in 1964; the MSdegree in electrical engineering from the University of Michigan,Ann Arbor, in 1965; and the Ph.D. degree in computer, in-formation, and control engineering from the University of Mich-igan in 1969.

Dr. Foley is a member of Phi Beta Kappa, Tau Beta Pi,Sigma Xi, Phi Kappa Phi, Eta Kappa Nu, and the ACM. Hewas vice-chairman of the ACM SIGGRAPH and is the CACMgraphics and image processing editor.

August 1976

A1139ILEVERy' 3 0 $ 53t3001.. r Bd E ;- ~ .Et

DIGITRANEPasadena, California * Phone (213) 449-3110

For more information use the Inquiry Form provided on this page.

INQUIRY PFORM11. O YOU WANT MORE INFORMATION? Ye*, send date :0 K MINIKEY KOyboard C] Sariat 8000 MIWS(TI~ )re23000 'MAO-N SLIMSMWIT I Srites 2900SoNSWITC1 0 0Series 1200 MINI1UTTON O'Series 24:Va SerIes,280 *NIINLsVER C] OPL..Approed DIIA SICEa', GiT~ vG'LTA,

J

IER and RESISANCE EA aaoC)$es~me yod cnlW "of0ITAL SWITl1 CtaIq.Oeil

Sa Enneer toee. My phone is::W..)2.1; thepur eofthis type prod l?Xf

3.is your requireant. 0 Curr"nt1]io i er410w man?Cyas eea n 00 IJ0' 1' 0AS0'

or more.S. Are -you repnil o:C einC SeiiaInC uoaip8. Hae youspeciiedr ourehaseDtidi Q6of:0jthVlihd#y I

f

comnpayCii ,,,y State ' '< >A St'p i _5iji>1_'-k

Fobdmt.Sile '.infrato abuD'gi0tran'Sprod'"ucts,'''pI;eas. epi.X44INQUIR FO. clipL and0 sen ittO:SR:^ t f - .S

THE

COMPANYA Diision of Becton DickinnnCompany Bn-D

855 South Arroyo Parkway v Pasadena, California 91105