A SMALL SCALE REAL TIME COMPUTER GRAPHICS SYSTEM Thesis for the Degree of M. S. MlCHIGAN STATE UNIVERSITY CHRISTOPHER SCUSSEL 1976 “‘3 '\‘u' / ABSTRACT A SMALL SCALE REAL TIME COMPUTER GRAPHICS SYSTEM by Christopher Scussel With the increasing popularity of graphic dis- plays as a medium for computer interaction, and with the advent of the relatively inexpensive small scale computer, a need for an inexpensive add-on real time graphics system has developed. A review of current display technology indicates a lack of availability of such a system. This paper describes a system consisting of an oscilloscope, an analog vector generator, IBM 1800 computer, and a set of FORTRAN compatible user level subroutines. The system is capable of displaying up to 200 vectors, representing several three dimensional wire frame objects, and can translate, rotate, deform, and project them in perspective in real time. The system is compatible with most modern minicomputers, and if an oscilloscope is already available, the total additional cost of hardware for the system is about thirty dollars. A SMALL SCALE REAL TIME COMPUTER GRAPHICS SYSTEM by Christopher Scussel A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Department of Computer Science 1976 To My Wife and Parents ii ACKNOWLEDGMENTS I would like to thank my advisor, Professor J. Forsyth, for his time, effort, and very helpful organizational suggestions during the preparation of the several drafts of this manuscript. Also, I would like to thank the other members of my examination committee, Professors R. Reid, J. Burnett, and F. LeCureux, for their time, consideration, and sug- gestions. And finally, I would like to thank Gary Bergeron, senior in electrical engineering, for con- structing the prototype vector generator. iii TABLE OF CONTENTS LIST OF FIGURES INTRODUCTION 1. Current Real Time Display Technology . . . . 1.1. Display Devices . . . . . 1.1. Systems Utilizing Cathode Ray Tube Displays 1. Video Based Systems. . . . . . . . 2. Oscilloscope Based Systems . . . . . 3. High Performance Hardware Systems . . . Systems Not Utilizing Cathode Ray Tube Displays. . . . . . 1. Plasma Panel Displays . . 2. Light Emitting Diode Matrices 3. Liquid Crystal Displays . . Conclusions . . . . . . . Vector Generation. . . . . . . Digital Vector Generation Techniques . Binary Rate Multipliers . . . . Digital Differential Analyzers . . Integer-Scaled Proportioning. . . Conclusions . . . . . . . Analog Vector Generation Techniques . Exponential Techniques. . . . . Interpolation Techniques . . Integration Techniques. . . Conclusions . . . . Conclusions . . . . . . . Display Controller . . . . . . Display Controller Separate From Comput . Computer As Display Controller (Software Display Controller) . . . . Conclusions . . . . . . . . . . . Conclusions. . . . . . . . . . . . kw wwwwwwwmnwwwwwwwHHH HHHH Hp HHHHHHHHHHHHHHHHHHH HHHH iv Page Page 2. The Prototype System . . . . . . . . . . 32 2.1. Display Device . . . . . . . . . . . 32 2.2. Vector Generator. . . . . . . . . . . 33 2.3. Display Controller . . . . . . . . . . 36 2.4. Summary. . . . . . . . . . . . . . 37 3. The Prototype Software System . . . . . . . 39 3.1. User Level Routines. . . . . . . . . . 41 3.1.1. Display Control . . . . . . . . 41 3.1.1.1. Activate Refresh-~VGON . . . . . . . 41 3.1.1.2. Deactivate Refresh--VG¢FF . . . . . . 42 3.1.1.3. Erase Screen--ERASE . . . . . . . . 42 3.1.1.4. Reset System--VGEND . . . . . . . . 42 3.1.2. Object Generation. . . . . . . . . . 43 3.1.2.1. Point Generation--P¢INT . . . . . . . 43 3.1.2.2. Vector Definition--VECTR. . . . . . . 44 3.1.3. Object Manipulation . . . . . . 45 3.1.3.1. Object Positioning And Orientation--¢BP ¢S . 45 3.1.3.2. Individual Point Repositioning--PNTMV . . 46 3.1.3.3. Display Buffer Update--UPDAT . . . . . 47 3.1.4. Example Of Software Use. . . . . . . . 48 3.2. Transformation Software . . . . . . . . 51 3.2.1. Rotation. . . . . . . . . . . . . 52 3.2.2. Translation. . . . . . . . . . . . 56 3.2.3. Perspective Projection . . . . . . . 56 3.2.4. Concatenation of Transformations. . . . . 57 3.2.5. Transformation Simplification. . . . . 59 3.2.6. Transform Limitations . . . . . . . . 60 4. Summary . . . . . . . . . . . . . . 62 Appendix--Listing of Prototype Software System. . . 80 LISTS OF REFERENCES. . . . . . . . . . . . 81 LIST OF FIGURES Figure Page 1. RC Circuit and Waveforms . . . . . . . . 22 2. Integrator Vector Generator . . . . . . . 26 3. Prototype System Vector Generator . . . . . 34 4. Software Overview . . . . . . . . . . 40 5. Example of Prototype System Software Use. . . 49 vi INTRODUCTION With the increasing popularity of graphic dis- plays as a medium for computer interaction, and with the advent of the relatively inexpensive small scale computer, a need for an inexpensive add-on real time graphics system has developed. A review of current display technology indicates a lack of availability of such systems. The purpose of this paper is to describe an inexpensive stand-alone graphics system, designed around a typical minicomputer. The system consists of a display processor, display software, a hardware vec- tor generator, and a display device. To help attain the cost objective, the display processor is actually the minicomputer, which shares its time between dis- play processing, display refreshing, and normal (non-display) processing. The display software allows apparently continuous transformations on up to two hundred vectors (typically) in three space, including rotation and perspective, without requiring floating point hardware, thus attaining the real time objective. The vector generator is a small device consisting of operational amplifiers and solid state switches, and the display device is an unmodified laboratory oscil- losc0pe. Since oscilloscopes are generally available at minicomputer installations, the additional hardware cost of the system is quite low. The system is designed to provide the minicom- puter user with small scale real time interactive graphical capability, through the use of a set of FORTRAN-compatible subroutines for generating and manipulating wire-frame representations of objects. A prototype of this system has been assembled, using an IBM 1800 processor-controller as the minicomputer, a low performance vector generator (total component cost about thirty dollars), an object oriented software system, and a laboratory oscilloscope associated with the IBM 1800 installation. This system, hereafter referred to as "the prototype system," is capable of displaying multiple wire-frame objects undergoing distinct rotational, translational, deformational, and perspective transformations, in real time. This paper is divided into three sections: a review of current real time display technology, a des- cription of the prototype system, and an explanation of the prototype system software. L 1. Current Real Time Display Technology Even though real time graphics systems range from rudimentary point drawing systems to extremely expensive systems capable of generating images of shaded polyhedral objects, all graphics systems can be broken down into three basic parts: the display device, the display generator, and the display controller. A small scale system designed for real time operation cannot currently hope to achieve a shaded image, so the best that can be hOped for is line drawing capability. Thus, the display generator is actually a line, or vector, generator. These three divisions are discussed below, and the best candidates for a small scale real time gra- phics system are selected. 1.1. Display Devices The cathode ray tube has been the traditional choice for electrovisual systems for many years, and there are a number of ways in which it can be used in a graphics system. Also, new forms of display devices are beginning to emerge from the laboratory, such as plasma panels and liquid crystal displays. Since the choice of display device is crucial to the design of the rest of the system, it is logical to begin with an examination of the devices available. 1.1.1. Systems Utilizing Cathode Ray Tube Displays 1.1.1.1. Video Based Systems Video devices utilize a raster scanned cathode ray tube, similar to a television monitor. Some sys- tems are designed to take advantage of this similarity by using standard television format video signals to drive the display. This enables such systems to use a television monitor as a display device, making large screen and multiple displays readily available, as well as inexpensive. The raster scan technique continually retraces the screen in order to maintain the image, and so the data comprising the image must be constantly resupplied to the display. This may demand excessive data rates from the computer. As an example, consider a display with about 500 scan lines.and as many points per line, where each point may be intensified or unintensified, and suppose thirty frames per second are displayed. This is similar to an ordinary television monitor, except that such a monitor has many more than just two intensity levels. The specified resolution generates about 250,000 points for which intensity information must be sent to the display thirty times per second. Even though this information amounts to only one bit per point, the required data rate is in excess of 7,000,000 bits per second, which is too fast for the computer to provide directly unless it is doing little more than refreshing the display. Because of the excessive demand upon the com- puter if it is driving the display directly, a buffer memory is generally inserted between the two. This shifts the high data rate to being between the display and the buffer, and allows the computer to spend most of its time performing display computations instead of refreshing the display. Also, the computer need transmit to the buffer only those points which have changed state (dark to light or vice versa) since the last frame. This results in a considerable decrease in the amount of data transmitted, especially in the case of line drawing or wire frame displays. The buffer memory is comprised of integrated circuits, either random access memories or shift registers. While shift registers are inexpensive and require very simple control circuitry, the average time for access to a given point is one half of the time required to refresh the display. In the example given above, this is 0.0167 seconds, which is far too great to be tolerated. Thus, shift register buffer memory is generally limited to applications in which the display changes relatively infrequently, and so the computer can afford to access all the points of the screen sequentially in one frame. Random access memories completely circumvent this problem, although with increased cost and controller complexity (in particular, the computer can be allowed memory access only between accesses by the display). Random access buffer memories are utilized in several display systems designed specifically for use with minicomputers having a sixteen bit word size and video monitors.R1’ R2 These devices provide 256 by 256 resolution, yielding a one to one correspondence between addressable display points and all possible sixteen bit words. Such a system is not suitable for real time applications, as the computer must generate lines by accessing each point of the line, and so each line may require on the order of a millisecond to be formed. 1.1.1.2. Oscilloscope Based Systems Recently a number of display interfaces have been marketed for use with a laboratory oscilloscope as the actual display device. The simplest of these interfaces is a point plotter, which is supplied with points, in the form of digital coordinate pairs, by the computer.R3 After entering a coordinate pair into its single point buffer, the coordinates are converted into voltages by a pair of digital to analog converters and the beam of the oscilloscope is deflected to the desired point, and that point is illuminated. The computer must draw lines as a series of points, and must periodically redraw the image if it is to remain on the screen. More sophisticated devices combine point plot- ting capability with a refresh buffer and a vector generator, so that the oscilloscope display may be maintained without the attention of the computer.R4 The vector generator vastly lowers the required computer-to-display data rate and the refresh memory size, if the images to be produced consist mainly of line segments. Generally, the refresh memory cannot be accessed by the computer, and thus the refresh memory must be completely cleared and reloaded in order to make the slightest change in the display (short of the addition of new line segments). This is a property common to most display devices which maintain refresh memory external to the computer ser- viced by the display. The concept of "Shared memory" for the computer-display interface has evolved to avoid this difficulty (see section 2.3). 1.1.1.3. High Performance Hardware Systems There are a number of commercially available graphics systems which rely on fast special-purpose hardware to maintain and transform the display on a cathode ray tube.R5' R6 Such hardware usually includes circuitry for rapidly performing matrix multiplication, in order to facilitate translation, rotation, and per- spective transformations. At least one system contains not only this but also hardware for hidden surface elimination and smooth shading of polyhedral objects.R8 This system is fast enough that objects consisting of several hundred triangular faces may be displayed with shading and transformed in real time. Unfortunately, this capability is prohibitively expensive to all but the largest computer graphics laboratories. 1.1.2. Systems Not Utilizing Cathode Ray Tube Displays The cathode ray tube is far from ideal as an electrovisual interface. It is bulky, requires unwieldy voltages to accelerate and deflect its electron beam, can smear moving images through phosphor persistence, may be damaged by overly bright images, and is poten- tially dangerous because of the risk of implosion. Several alternative devices have been proposed which avoid some of these problems: the plasma panel, light emitting diode matrices, and liquid crystal displays. Of these devices only the plasma panel is currently commercially available, while the other two are still undergoing development. 1.1.2.1. Plasma Panel Displays The plasma panel is a flat, rectangular enclo— sure containing 1ow pressure gas, which may be ionized by applying a voltage across electrodes on opposite sides of the device. The electrodes are arranged vertically on one side, and horizontally on the other, so that the gas may be made to ionize, and thus glow, in a small, discrete point, by energizing one vertical and one horizontal electrode. By exploiting the difference between the sustaining and extinguishing voltages of the gas, the panel can provide its own memory, and thus maintain an image with neither com- puter intervention nor external memory hardware. This does not provide for gray scale, although it has been shown that several stable ionized states of the gas may be used to provide different intensities, but this is still experimental.B1 The plasma panel display suffers from the same data manipulation problems as all the non-vector displays, namely, that a large amount of information must be passed to the display in order to move some part of the image. This can become a serious problem in real time situations. Plasma panel displays have just recently become commercially available for use with small computers, although their resolution (about sixty points per inch) and size (about nine inches square) somewhat limits their usefulness.R7' R9 10 1.1.2.2. Light Emitting Diode Matrices These displays are constructed from subarrays of integrated light emitting diodes. Each individual diode is addressable in a manner similar to that of a word in a plane of random access memory: by selecting the row and column containing the desired diode. Light emitting diodes respond to changes in current very rapidly (within a few nanoseconds), and so smearing is not a problem. Since they have no inherent memory the display must be continually refreshed by the com- puter or external circuitry. Even so, this task is less difficult than with cathode ray tube systems, because light emitting diodes are low voltage devices and thus do not require high voltage drive circuitry. Currently the cost of this type of display is very high, even though its resolution is poor (at best about fifty points per inch). This situation will undoubtedly improve as integrated circuit technology continues to advance. 1.1.2.3. Liquid Crystal Displays Liquid crystal displays are based upon the fact that certain chemicals change their light scat- tering properties in response to an electric field. A flat, rectangular cell with electrodes on the front and back (similar to the plasma panel) containing liquid crystal material can be made to selectively ll scatter or transmit incident light at each of the cells formed by the matrix of electrodes. Note that the display does not generate any light of its own; thus, constrast is improved, rather than degraded, by high ambient light conditions. By viewing scattered light, a conventional display is presented. By viewing trans- mitted light, the display becomes projecting, and thus may generate very large images. Liquid crystal displays are capable of inher- ent memory, and share most of the data rate problems of point addressable displays. In addition, they are quite slow to respond to changes in the electric field, and thus smear can be a severe problem for rapidly moving images. Resolution is approaching one hundred points per inch, but cost reliability are still major problems. Further research should eliminate most of these difficulties. 1.1.3. Conclusions Cathode ray tube displays are the best selec- tion for a small scale graphics system for two reasons. First, their technology is well developed, allowing relatively low cost through mass production and proven driving circuitry design. Second, it can be used to directly display lines, as opposed to the quantization inherent in raster and matrix displays. This is a 12 result of the fact the cathode ray tube is an analog device, and thus not limited to a fixed set of digital inputs. The benefits of both advantages may be had by using an oscilloscope as the display device. Aside from its self—contained power supplies and deflection amplifier circuitry, the oscilloscope often has the additional feature of being readily available at a minicomputer installation, perhaps in connection with maintainance of the computer and its peripheral equip- ment. Since the oscilloscope may be used in several ways to generate images, it must be decided which technique is appropriate for the desired graphics system. In the small scale system considered here, the images are to consist entirely of lines (or vectors), so that the image generation problem reduces to one of vector generation. 1.2. Vector Generation Because many real time computer graphics applications require lines to be drawn as part of the completed image, it is worthwhile to have vector gener- ation capability in the display hardware. Points can then be generated by treating them as zero length vectors, and thus a vector generator is sufficient to generate most desired images. The vector generator 13 has no processing power, and simply draws a line seg— ment between two specified endpoints. Also, the vector generator has no refresh memory, and thus the task of refreshing the display is left to the display controller. In an oscilloscope based graphics system, vectors may be generated by either digital or analog circuitry. Analog circuitry has the advantage that it can be connected directly to the oscilloscOpe, whereas digital circuitry requires digital to analog converters in order to drive the oscilloscope. Digital techniques will be treated first, then analog techniques. 1.2.1. Digital Vector Generation Techniques Digital techniques generate a vector as a sequence of points, and thus if the vectors comprising the image are to be drawn fast enough to avoid flicker, the hardware must generate the points very rapidly indeed. For example, in a system designed to display up to two hundred vectors with an average of two hundred points each, and refresh the display thirty time per second, points must be generated at a rate of more than 1,000,000 per second. While this is not excessive, it does require careful circuit design and a simple sequential algorithm in order to be practical. 14 Three digital techniques are treated here: binary rate multipliers, digital differential analyzers, and integer-scaled proportioning. 1.2.1.1. Binary Rate MultipliersBl An n-bit binary rate multiplier accepts as input an n-bit number m and a sequence of clock pulses, and during its 2n clock pulse period generates m more or less regularly spaced pulses. Thus, by using two binary rate multipliers with counters to accumulate their output pulses, any given vector can be approxi- mated. The algorithm and circuitry involved for the binary rate multiplier is quite simple, and in fact high speed implementations are available as a single integrated circuit. Its major disadvantage is that the m output pulses are not sufficiently equally spaced in time to draw straight vectors, resulting in lines which vary in intensity and direction along their length. Note that since each circuit will go through one com- plete 2n clock pulse cycle for each vector drawn, each vector requires 2n clock pulses to be generated, regard- less of its length and direction. While this tends to simplify the display controller, it lowers the number of vectors which may be displayed without flicker. 1.2.1.2. Digital Differential AnalyzersBl The digital differential analyzer type of vector generator seeks to determine the set of points 15 out of which to form the desired line segment by approximating the solution to the differential equa- tion which determines the line. This differential equation is where AX and AY are the X and Y coordinate differences between the two endpoints of the line. There are various forms of digital differential analyzer algorithms, all of which are incremental in nature. That is, the next step in the discrete solution is found by incrementing either the X or Y coordinate (or both) of the previous step. This means that a new point is generated for each clock pulse, and so the desired vector may be generated much more quickly than with the binary rate multiplier form of vector generator. However, all forms of the digital differential analyzer require division to determine one or more of the parameters involved in the algorithm. This division can be per- formed in the vector generator, but this adds consider- ably to the cost of the circuitry. On the other hand, if the division is performed by the computer, it is time consuming, and thus reduces the number of vectors which can be displayed during one refresh cycle. The division required by this type of vector generator is its main fault. In some algorithms, the parameters 16 are set up so that the division operation becomes a matter of shifting, after forcing the divisor (an estimate of vector length) to be a power of two. While this avoids the division, it causes some points to be displayed more than once and displays some points which should not be displayed. 1.2.1.3. Integer-Scaled Proportioning This method takes advantage of the fact that since the slope of any vector to be displayed is rational, the parameters of the vector can be scaled up by an integer (namely, the product of the X and Y differences of the vector endpoints) in order to make all of the parameters integral. Explicit multiplication is not necessary, and so this method does not succumb to arith- metic difficulties, as does the digital differential analyzer. Since this type of vector generator is not treated in (B1), it will be presented here in somewhat more detail than the other two types of digital vector generators. This method is similar to the binary rate mul- tiplier technique, in that it generates pulses which are fed to counters, and the counters keep track of the coordinates of the point which is to be displayed. The method is iterative, and either one or both of the counters is incremented during each iteration. A pair of registers keeps track of which of the counters is 17 to be incremented. These registers maintain a scaled version of the progress made in drawing the line seg- ment, with the scaling such that in order for the generated line segment to be as close as possible to the desired line segment, the two registers should be as close to being equal as possible. The desired scaling results if, during each iteration, the counter corresponding to the smaller of the two registers is incremented, and that register is increased by the component of the desired line segment along the other coordinate. For example, if the X register is smaller, the X counter is incremented, and the X register is increased by the difference of the Y coordinates of the endpoints of the desired line segments. If the two registers are equal, then both counters are incre- mented and both registers are increased. The algorithm is defined in F¢RTRAN below, where X and Y are the counters and XC and YC are the registers. Notice that the coordinate differences DXl and DYl are actually the differences plus one, and the registers are initially these differences rather than zero. This causes the algorithm to work for horizonatal and vertical line segments, without additional logic. 18 SUBROUTINE DRAW(XA,YA,XB,YB) IMPLICIT INTEGER (A-Z) DXl = XB-XA + 1 DYl = YB-YA + l XC = DYl YC = DXl X = XA Y = YA CALL PLOT(X,Y) l IF(X.EQ.XB .AND. Y.EQ.YB) RETURN IF(XC-YC)2,3,4 2 X = X + 1 XC = XC + DYl CALL PLOT(X,Y) GO TO 1 3 X = x + 1 Y = Y + l XC = XC + DYl YC = YC + DXl CALL PLOT(X,Y) GO TO 1 4 Y = Y + 1 YC = YC + DXl CALL PLOT(X,Y) GO TO 1 END In the above subroutine, (XA,YA) and (XB,YB) are the endpoints of the vector to be drawn, with XBZXA and YBZYA, and PLOT intensifies the given point on the screen. By keeping the quantities X and Y in up/down counters, the hardware can easily handle those cases where XB . I l REFRESH | I BUFFER GENERATOR I l ROUTINE I l , I ________ J I I I I <'— :3353é3: I‘ 255:3: ILII’ZR'E‘? I FIGURE 4. SOFTWARE OVERVIEW 41 use. The second section is a description of the Operation of the transformation software. 3.1. User Level Routines These routines are primarily designed to show how the basic transformation and display software may be interfaced to user-oriented software, and to show that the transformation software is capable of func- tioning in real time (as Csuri notes, "Too often systems which are the result of a research experiment in hard- ware or software design do not go beyond a beautiful demonstration of potentialities.")BZ The software is object oriented, and all computations are performed in the object coordinate system, down to the final transformation into screen coordinates. The software is in three basic categories: display control, object generation, and object manipulation. 3.1.1. Display Control 3.1.1.1. Activate Refresh--VG¢N The routine VG¢N first checks an initialization flag, and initializes the display software system if it is not set. In the prototype system, the hardware does not have its own power supplies, and derives its power (+10, -10, and +5 volts) from analog outputs on the IBM 1800. So, as part of the initialization process, 42 these analog output lines are set to the appropriate voltages. Also, the point and vector counts are set to zero. Finally, the initialization flag is set, to prevent subsequent call to VG¢N from causing reinitialization, and the refresh programming is activated. This activation consists of replacing a timer interrupt vector with the address of the refresh program, on the prototype system. The old address is saved (see seCtion 3.1.1.4). The second phase of VGON is always performed, regardless of the setting of the initialization flag. In this phase the timer is set for the time that is to elapse between the end of one refresh cycle and the start of the next, and started. VG¢N then returns to the calling program, with the refresh programming maintaining the display. 3.1.1.2. Deactivate Refresh--VG¢FF This routine turns off the timer, preventing timer interrupts and thus disabling the refresh pro- gramming. VG¢FF then returns to the calling program, with the display screen blank. 3.1.1.3. Erase Screen--ERASE The ERASE routine is used to clear the screen, and should be called only when the refresh programming is active. ERASE first turns off the timer, disabling 43 the refresh programming. Then, the refresh buffer is cleared, and the refresh vector count is set to zero. Finally, the timer is restarted, reactivating the refresh programming, with the display screen blank. 3.1.1.4. Reset System--VGEND The VGEND routine restores the timer interrupt address (see section 3.1.1.1.) after disabling the timer, thus restoring the operating system of the com- puter to its original state, in preparation for terminating the run of the graphics program. VGEND should be called only after the graphics software has been initialized (by a call to VGON), so that the location reserved for the saved interrupt address indeed contains that address. VGEND returns to the calling program, not to the Operating system, and thus the system may be restarted with VGON. 3.1.2. Object Generation 3.1.2.1. Point Generation--P¢INT(IOBJ,IX,IY,IZ) The POINT routine increments the point count and stores the coordinates of the point specified by the integer triple (IX,IY,IZ). Points thus stored are used as vertices for wire frame representations of objects. An integer object number, I¢BJ, is associ— ated with the point, so that all points with the same object number can be transformed as a single set, or 44 “object“ (see section 3.1.3). The actual value of I¢BJ is not important, as long as the same value is used for other points that are to be in the same object, and the value used does not exceed the maximum number of objects for which the system is configured. For example, the prototype system is configured for a maximum of ten objects, so the integers from one to ten, inclusive, may be used as object numbers. Also, the number of points which may be created is limited by the amount of storage which the graphics software has reserved for them. In the prototype system, up to two hundred points may be created. Although points are transformed in groups according to object number, vectors may span between any two points, and thus between points belonging to different objects (see section 3.1.2.2). 3.1.2.2. Vector Definition--VECTR(IPNT,IBEAM) The routine VECTR creates a vector from the current point to the point with integer ordinal IPNT. That is, the endpoint of the vector to be created is the point which was created in the IPNT-th call to P¢INT. The starting point for the vector is the endpoint of the previous vector, so that the starting point of the first vector is undefined. The integer argument IBEAM controls the intensification of the vector; if IBEAM is one, the vector is visible, and if IBEAM is 45 two, the vector is invisible. Thus, the first call to VECTR should always have IBEAM equal to two, to ensure that the vector with the undefined initial point is not visible. Since a point ordinal is specified to determine the endpoint of each vector, a vector may span between any two points, even if the points are in different "objects" for the purposes of transfor- mations. Only the points are subjected to transformation, and when the transformation parameters change so that the screen coordinates of a point change, all the vectors which have that point as an endpoint are altered so as to end at the new position of the point. Thus, the vectors act as "rubber bands" stretched between their endpoints, and automatically follow the motions of the endpoints, stretching and shrinking as the points move relative to one another. There is a maximum number of vectors which may be defined: the prototype system is configured for a maximum of two hundred vectors. In order to save time, no checking is performed against this limit, and the results are unpredictable if it is exceeded. 3.1.3. Object Manipulation 3.1.3.1. Object Positioning and Orientation-— ¢BP¢S(IOBJ,IXANG,IYANG,IZANG,IXM¢V,IYM¢V,IZM¢V) The ¢BP¢S routine allows the user to specify rotational and translational transformations to be 46 applied to the set of points with object number I¢BJ. First, the specified set of points is rotated IXANG degrees about X-axis. Then, the result is rotated IYANG degrees about the Y-axis, and then IZANG degrees about the Z-axis. The sense of rotation is right-handed for the X and Y-axes, and left-handed for the z-axis, meaning that a positive angle specification will cause a rotation in the direction of the curl of the fingers of the appropriate hand, if the thumb is pointing in the positive direction of a given axis. The result of the rotation transformations is then translated IXM¢V units in the direction of the positive X-axis (to the right on the screen), IYM¢V units in the direc- tion of the positive Y-axis (towards the top of the screen), and IZM¢V units in the direction of the posi- tive z-axis ("into" the screen). The position and orientation of the point set on the screen does not change at the time of the call to ¢BP¢S. Rather, the parameters of the call are stored in the parameter buffer for that particular point set, and the new transformations are performed when the display buffer is updated by a call to the UPDAT routine (see section 3.1.3.3). 3.1.3.2. Individual Point Repositioning—- PNTMV ( I¢BJ , IPNT , IXM¢V, IYM¢V , IZM¢V) The PNTMV routine allows individual point positions to be changed, and thus change the "shape" 47 of a displayed object, even if all of its vertices belong to the same point set. A particular point to be moved is referenced as the IPNT-th point of the I¢BJ-th point set, or "object." The translation para- meters IXM¢V,IYM¢V, and IZM¢V are added to the originally defined coordinates of the specified point, and the sums replace the original coordinates. No change is made to the display until the UPDAT routine is called to recalculate the transformations (see sec- tion 3.1.3.3). The routine can be used to translate an entire point set (by using multiple calls), so that if a rotation and a compensating translation are specified for the translated point set, the effect is to offset the axis of rotation. This increases the versatility of the prototype rotation scheme (see section 3.2.1). 3.1.3.3. Display Buffer Update-—UPDAT The UPDAT routine performs the transformations specified by calls to OBPOS on the points defined by calls to POINT and modified by calls to PNTMV. It then creates a display buffer by tracing through the point-to-point vectors specified by calls to VECTR, using the screen coordinate representations of points resulting from the perspective projection. Then, while inhibiting display refresh, the new display buffer is copied over into the refresh buffer area, and the refresh 48 vector count is set to the vector count of the new buffer. Thus, all transformations which are specified between calls up to UPDAT do not take effect until UPDAT is called. After the refresh buffer is updated, refresh is reactivated, and a refresh cycle is begun immediately, in order to minimize the time the display is blank after the buffer transfer is complete. 3.1.4. Example of Software Use Figure 5 illustrates the use of the user level routines in a short FORTRAN program segment. First, the call to VGON initializes the software and activates the display. Next, a small square base pyramid is defined by calls to POINT and VECTR. The pyramid is as high as its base is wide. The first DO loop repeatedly calls OBPOS and UPDAT, moving the pyramid slowly away from the user while rotating it twice about its vertical axis. After this, VGOFF is called, blanking the display, and a square is defined which surrounds the pyramid, by calls to POINT and VECTR. A call to OBPOS specifies no translations or rotations for this new object, and when VGON is called to reactivate the display, it shows the square in the plane of the screen, and the pyramid quite far away. Note that the plane of the screen is just the plane of perspective projec- tion, and objects can pass through it with no effect, since the eye point is located along the negative Z-axis. 100 200 300 CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL 49 VGON PDINTII’IOOO’OQIOOO) P01NTI191000909“1000I POINT‘19-1000909’1000) POINTIID'IOOOPOPIOOOI POINTI1909200090) VECTRIIPZI VECTRIZPII VECTRIBPII VECTRI491) VECTRIIPII VECTRISPII VECTRIZPII VECTRI392I VECTRISPII VECTRI491I DD 100 J=lc720 CALL CALL OBPOSI1909J1090909J*10I UPDAT CONTINUE CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL CALL VGOFF POINTI2930009300090I P01NTI29'30009300090) POINTI29’30009'300090I POINTI2930009-300090I VECTRIOPZI VECTRITDII VECTRIBPI) VECTRI991I VECTRIOPII OBPOSI2909090909090I VGON DO 200 J310720 CALL CALL OBPOSI19090.090,097200-J*10I UPDAT CONTINUE DO 300 J819360 CALL OBPOSI19J9090909090I CALL OBPOSI29J9090909090) CALL UPDAT CONTINUE CALL VGEND FIGURE 5. EXAMPLE OF PROTOTYPE SYSTEM SOFTWARE USE 51 The second DO loop serves only to move the pyramid back to the plane of the screen, while the square remains stationary. The third DO loOp rotates the square and pyramid in unison about the X-axis once. This causes a dramatic perspective effect as the apex of the pyramid and the top and bottom of the square alternately approach and recede. After this single rotation, the display system is reset with a call to VGEND in preparation for terminating execution of the program. If the program had a new set of images to display, ERASE could be called instead of VGEND to remove the previously defined objects from the graphics system. 3.2. Transformation Software The transformation routines are a critical part of a real time graphics system which does not have transformation hardware. If the display is to be updated often enough to maintain the illusion of motion, the routines which perform translation, rota- tion, and perspective projection must be carefully coded (generally in assembly language) so as to be as fast as possible. As few minicomputers possess floating point arithmetic hardware, it is generally impossible to attain the necessary speed unless all the transfor- mation calculations are performed using integer arithmetic. The integer multiply and divide 52 instructions found on many minicomputers allow the transformations to be rapidly performed. 3.2.1. Rotation Rotation requires the evaluation of sums of products, where the products are of object coordinates and the sine or cosine of a rotation angle. This involves two difficulties: the evaluation of trigono- metric functions, and the handling of numbers less than unity in magnitude, by using integer arithmetic. In keeping with the integer orientation of the low level display programming, an angle of rotation is represented as an integer, indicating number of degrees of rotation. Thus, if the angle is treated modulo 360, it may be used as a subscript to find the required values in precalculated tables. It is common for minicomputer divide instructions to have provisions for obtaining the remainder upon division, so that the modulo operation may be performed very quickly. However, if the divide instruction lacks this feature, the remain- der may be computed in a manner analogous to the FORTRAN expression N - N / 360 * 360 . Once the angle is reduced to between zero and 359 degrees by the modulo 360 Operation, it may be used directly as a subscript to look up the corresponding sine and 53 cosine values, if enough memory is available to con- tain the required tables. Each value occupies one word, and two tables are required, so a total of 720 words is necessary, if separate tables are used. However, because of the identity cos(6) = sin(6 + 90°) the cosine table can start at the ninety-first entry in the sine table, so that the combined sine-cosine table occupies 450 words. Although this is still a good deal of memory to use for a table, it is not exces- sive, and yields a very fast technique for obtaining the values of sine and cosine. By exploiting the symmetries of these functions, further compression of the table can be accomplished, at the expense of more programming to reference the table and a longer access time. If sufficient memory is available to contain the larger table, then such compression efforts serve only to lower the performance of the system. The significance of the one degree resolution of the trigonometric functions is two-fold. First, it allows the use of a very natural technique for specifying angles: an integer number of degrees. This is consistent with the idea of avoiding floating point arithmetic, and is convenient for the user of the system. Second, it provides a simple method for pro- gramming animation. For example, if an object is 54 rotated through an angle which is increased by one degree per frame, say, then the object will appear to rotate continuously, if slowly, even though each change of angle would be barely perceptible, if viewed by itself. Thus, a number of rotation rates may be pro- grammed by incrementing rotation angles by small integers. Because of the modulo 360 computation involved in the sine and cosine evaluations, angles in excess of three-hundred sixty degrees are permitted, and in fact angles as large as the maximum integer size imposed by the word length of the minicomputer can be used. In the prototype system, this limit is 32767, and thus an object will rotate more than ninety times before integer overflow occurs, causing a sudden jerk in the otherwise smooth rotation. Now, the required calculations may be performed if the actual numbers stored in the trigonometric table are scaled to fit the available integer range of the minicomputer. Thus, with the sixteen bit orientation of the prototype system, the trigonometric table entries are scaled by a factor of 32767. A typical integer :multiply instruction will form a thirty-two bit product from two sixteen bit numbers (assuming a sixteen bit word), so if a number is multiplied by a value from the trigonometric table, the most significant word of the product will be within one least significant bit 55 of half of the desired product. This is true because the table is scaled by a factor of 32767, and the result of the multiplication is scaled by a factor of 1/65536, since only the most significant half of the product is used. Therefore, two of the aforementioned "rotation products" may be computed and added without fear of overflow, or they may be shifted one bit to the left before or after the addition, yielding the correct result, within the two least significant bits. The actual transformation equations used to implement rotation depend upon the means chosen to represent object orientation. One commonly used technique specifies an axis of rotation (in terms of direction cosines) and an angle through which the rotational motion acts. This is somewhat inconvenient for the user, since direction cosines are not a natural way to specify a direction. Unfortunately, there seems to be no convenient way for the user to specify a given rotational motion. The prototype system attacks this problem by providing the user with three ordered rotation transformations: X-axis, Y-axis, and Z-axis rotations, where the user specifies the number of degrees of each rotation. The transformations are applied in the order shown, allowing the general orientation capability offered by the direction cosine techniques above, and also providing a natural way for the user to specify 56 certain classes of orientations. This method has performed moderately well, in terms of ease of use. Also, it allows a good deal of computation optimization, thus helping to assure smooth animation (see section 3.2.4). 3.2.2. Translation Translation can be implemented by simply adding the appropriate integer displacements to each coordi- nate of each point involved. If all three coordinates are treated identically, however, the resulting "coordinate space" will be cubical, due to integer range limitations, and thus has very limited depth and perspective cues. This can be remedied by treating the Z-coordinate separately (see section 3.2.6). 3.2.3. Perspective Projection Generating a perspective image requires division, which is generally a time-consuming operation, and thus perspective projection is not provided in many inex- pensive real time display systems. If the display screen is the plane Z = 0, the eye point (Xe,Ye,Ze) with Ze< 0, and the point to be projected (Xe,Ye,ze), the projected point in screen coordinates is K II I< + 33 m (D * I'D With the exception of the division, the equations are trivial to implement using integer arithmetic. A typical integer division instruction acts on a thirty-two bit dividend and a sixteen bit divisor to produce a sixteen bit quotient and a sixteen bit remainder, if possible, and this instruction can be used to provide the division required by the perspective projection equations. If the numerator is placed in the thirty—two bit register and divided by the denominator, the required quotient is obtained, scaled by a power of two depen- dent upon where the numerator was positioned in the dividend register. This scaling can be used to increase the depth of field available from the system (see section 3.2.6). 3.2.4. Concatenation of Transformations A significant increase in the speed of the transformations can be realized if they are applied simultaneously rather than one at a time. In a typical graphics system, the transformations are represented as matrices, and the transformations are applied by multiplying the vector representation of the points 58 to be transformation matrices, so time may be saved by computing the product of all the transformation matrices beforehand, since matrix multiplication is associative. While the matrix implementation is straightforward and versatile, since transformations may be added or deleted at will, it is relatively slow, and thus is a luxury that cannot be afforded in a small real time system. Instead, concatenation of transfor- mations is accomplished while the transformations themselves are being performed. Taking the prototype system as an example, the order of transformations is X-axis, Y-axis, and Z-axis rotations, X-axis, and Z-axis translations, and X-axis and Y-axis screen coordinate perspective projections. But instead of implementing them in this order strictly, the software overlaps the calculations as much as the available registers will allow. The results of each calculation are used immedi- ately, if possible, to eliminate unnecessary load and store operations. This saves precious time during the operation of transforming objects from their original position and orientation down to screen coordinates, which can make the difference between a real time system and a jerky, eye—fatiguing graphics display. The integrated character of the transformation coding in the prototype system is evident from the program listing (see appendix). 59 3.2.5. Transformation Simplification Further enhancement of transformation speed is possible if the transformation equations are reduced to their simplest practical state. In the perspective transformation equations, one addition and one subtrac- tion can be eliminated from each equation if the eyepoint is constrained to lie on the line X = Y = 0. This limits the system to displays in which the projection plane and the observer are stationary, and the objects being displayed move relative to them. This is not a serious limitation, because the user of the system is always facing in the direction of the display, and thus should receive the impression that the objects which he is observing are in motion, rather than himself. Three operations of addition or subtraction may be eliminated from each rotation equation, if all the axes of rotation pass through the origin: X' (X - X0) - cos(ez) - (Y - YO)-sin(ez) + XO becomes I . _ o I X X cos(02) Y Sin(02) where (X0, Y0) is the point where the axis of rotation (here, parallel to the Z-axis) intersects the plane Z = 0. Since as many as six rotation equations must be implemented (see section 3.1.3.1), the elimination 60 of these operations can save a good deal of time in processing the transformations. In the prototype system, this saves about 18 percent of the time which would otherwise be spent in performing rotation com- putations: 104 microseconds versus 128 microseconds per expression evaluation. The IBM 1800 has a relatively slow multiplication instruction, so that a machine with a faster multiplication instruction will realize a greater percentage gain in time by using the simpli- fied equations (although the faster machine would probably not need the increase in speed). 3.2.6. Transform Limitations Because sixteen bit integers are used throughout the transformation calculations (using the prototype system as an example), the coordinates used to define points (object vertices) must be sixteen bit integers. This means that the object space is a cube, centered on the origin (the center of the display screen), and approximately 65,000 units on a side. This is many times larger than the display screen (typically about 1,000 units in diameter), but lacks sufficient depth for convincing perspective effects. This is overcome by scaling during the concatenation process, so that the depth of field is increased by a factor of sixteen. During the computation of the denominator of the perspec- tive factor, the Z-coordinate of the point being 61 processed is shifted three bits right, instead of the normal one bit left, before the Z-coordinate translation is added. This amplifies the effect of the Z-axis translation by a factor of sixteen, without distorting the cubical object space. Thus, whenever a Z-axis translation is specified by the user, he must be sure to use one sixteenth of the actual trans— lation desired. 4. Summary The prototype system described in this paper is capable of displaying over 100 vectors, representing as many as ten objects, and perform all the described transformations fast enough to present a flicker-free display. Fewer objects increases its vector count for a flicker—free display, and more still may be displayed by tolerating some degree of flicker. Static displays may have up to 200 points before flicker becomes noticable. The hardware cost of the system, exclusive of the minicomputer and the oscilloscOpe, is about thirty dollars. The software must of course be rewritten in assembler for each different minicomputer, but this is not difficult, and generally can be done by adapting the prototype system code, provided in the appendix. The IBM 1800 used in the prototype system is quite slow, by modern standards, and so a new system, using a minicomputer, should yield markedly better performance. Thus, the prototype system achieves its goal of being a small scale real time minicomputer graphics system. 62 APPENDIX ENT UPDAT ENT OBPOS ENT POINT ENT VECTR ENT VGOFF ENT VGON ENT VGEND ENT ERASE ENT PNTMV **#****#**#****#******************¥**#*********t**** *************#*#**********#******#****************** *** *** *** *$* ##t VECTOR GENERATOR SOFTHARE VERSION 2 Pt: *** **# #** **# *#* MASTER'S THESIS PROGRAM *t* *R* CHRISTOPHER SCUSSEL *tt #** MICHIGAN STATE UNIVERSITY *t* **P ENGINEERING COLLEGE COMPUTER OPERATIONS *tt #** *** *** *** *************#*#***#****#**#**#********#************ **********#*#**$*****##**#**##***#***********#****** * 1 ************************#*************¥************* * t * SOFTWARE CONFIGURATION CONTROL * * * *********#****************#********#***************# 4 MXPNT EOU 200 SET 200 POINTS MAXIMUM MXVEC EOU 200 SET 200 VECTORS MAXIMUM MXOBJ EOU 10 SET 10 OBJECTS MAXIMUM LOGCO EOU 0 SET LOGIC 0 TO 0 VOLTS LOGCl EOU 10000 SET LOGIC 1 TO 3 VOLTS * A 63 64 #*#*****#*#***#***#*****####*********#************** 3 t * SOFTHARE PARAMETER STORAGE * a * **#**#*#**#**#*#**#**********#*********#***********# * =PNTS DC NUMBER OF POINTS =VEC DC NUMBER OF VECTORS =VREF DC NUMBER OF VECTORS TO BE * OISPLAYED BY REFRESH ROUTINE LOGO DC LOGCO ADDRESSEO LOGIC 0 LOGl DC LOGCl ADDRESSED LOGIC l * #*#********#**#**##***#**#**#**#*#*#****#*#*****#*** g * * DISPLAY UPDATE ROUTINE * t * #**#*****#*****#*##******##*#**##**t**#***#*****#**# * UPDAT DC ENTRY POINT LO L INTFG FETCH INITIALIZATION FLAG BSC I UPDAT,+- RETURN IF NOT INITIALIZED STX L3 X3NIN SAVE INDEX REGISTER 3 * # ROTATE' TRANSLATE, AND PROJECT POINTS * DOWN TO SCREEN COORDINATES # LOX Ll PTSTR FETCH POINT STORAGE ADDRESS LOX 13 =PNTS FETCH NUMBER OF POINTS MOVLP LO 1 0 FETCH PARAMETER STORAGE ADDRESS STO TEMPl LOX IZ TEMPI PREPARE TO RETRIEVE PARAMETERS LD 1 2 GET OBJECT Y-COORD M 2 0 MULT BY SIN X STO TEMPl STORE INTERMEDIATE LD 1 3 GET OBJECT Z-COORD M 2 l MULT BY COS X S TEMPl SUBTRACT INTERMEDIATE SLA l CORRECT FOR TRIG TABLE STO TEMP3 STORE X-ROT Z-COORO LD 1 2 GET OBJECT Y-COORD M 2 1 MULT BY COS X STO TEMPl STORE INTERMEDIATE LD 1 3 GET OBJECT Z-COORD M 2 O MULT BY SIN X A TEMPl ADD INTERMEDIATE SLA l CORRECT FOR TRIG TABLES STO TEMPZ STORE XeROT Y-COORD LO TFMP3 GET X-ROT Z-COORD M 2 2 MULT BY SIN Y TEMPI TEMPZ TEHPB TEMP4 STO LD SLA STO 65 STORE INTERMEDIATE GET OBJECT X-COORO MULT BY COS Y SUBTRACT INTERMEDIATE CORRECT FOR TRIG TABLES STORE XY-ROT X-COORD GET X-ROT Z-COORD MULT BY COS Y STORE INTERMEDIATE GET OBJECT X-COORD MULT BY SIN Y ADD INTERMEDIATE CORRECT TRIG AND ADJUST PERSPECTIVE ADD Z-TRANSLATION COMPUTE DISTANCE FROM EYE STORE PERSPECTIVE FACTOR GET XY-ROT Y-COORD MULT BY SIN Z STORE INTERMEDIATE GET XY-ROT X-COORD MULT BY COS Z SUBTRACT INTERMEDIATE CORRECT FOR TRIG TABLE ADD X-TRANSLATION ADJUST PERSPECTIVE COMPUTE PERSPECTIVE STORE X-SCREEN COORDINATE GET XY-ROT Y-COORD MULT BY COS Z STORE INTERMEDIATE GET XY-ROT X-COORD MULT BY SIN Z ADD INTERMEDIATE CORRECT FOR TRIG TABLE ADD Y-TRANSLATION ADJUST PERSPECTIVE COMPUTE PERSPECTIVE STORE Y-SCREEN COORDINATE ADDRESS OF NEXT PTSTR RECORD DECREMENT COUNT DO NEXT POINT PREPARE T0 T0 UPDATE RFSTR 66 * * CONSTRUCT IMAGE OF REFRESH STORAGE AREA * IMAGE SRA 16 ZERO AGCUMULATOR, STO XPOS INITIALIZE X-POSITIDN STO YPOS INITIALIZE Y-POSITION LDX Ll VCSTR PREPARE TO RETRIEVE VECTORS LDX I2 =VEC FETCH NUMBER OF VECTORS LDX L3 PLTBF FETCH PLOT BUFFER ADDRESS DRHLP LD 1 0 FETCH ENDPOINT ORDINAL SLA l MULTIPLY BY 2 A I 0 FORM PRODUCT WITH 3 SLA 1 FORM PRODUCT WITH 6 A PTADR COMPUTE X ADDRESS A ADDR4 COMPUTE X ADDRESS STO XSTR+1 STORE ADDRESS A ADDRI COMPUTE Y ADDRESS STO YSTR+l STORE Y ADDRESS XSTR LD L *-* FETCH X-SCREEN COORDINATE S XPOS COMPUTE DIFFERENCE STO 3 O STORE DIFFERENCE IN PLOT BUFFER A XPOS RESTORE X-SCREEN COORDINATE STU XPOS STORE CURRENT X-POSITION YSTR LD L *-* FETCH Y-SCREEN COORDINATE S YPOS COMPUTE DIFFERENCE STO 3 I STORE DIFFERENCE IN PLOT BUFFER A YPOS RESTORE Y-SCREEN COORDINATE STO YPOS STORE CURRENT Y-POSITION LD 1 l FETCH BEAM CONTROL STO 3 2 STORE IN PLOT BUFFER MDX 1 2 PREPARE TO FETCH NEXT VECTOR MDX 3 3 PREPARE TO STORE NEXT VECTOR MDX 2 -l DECREMENT VECTOR COUNT MDX DRHLP LOOP BACK FOR NEXT VECTOR *# XFER EYEZ XPOS YPOS PTADR ADDRl ADDRA X3NIN *‘*1$* LFVLl 67 TRANSFER PLOT BUFFER TO REFRESH STORAGE LDX Il LOX L2 LDX L3 XIO L LD STO LD STO LD STO MDX MDX MDX MDX LD STO XIO ththrvuavama r'F LDX 13' BSC I =VEC PLTBF RFSTR TMOFF 0 wkvnawrdh'o -l XFER =VEC =VREF LEVLl X3NIN UPDAT FETCH NUMBER OF VECTORS FETCH PLOT BUFFER ADDRESS FETCH REFRESH STORAGE ADDRESS CEASE REFRESHING DATA TRANSFER DATA TRANSFER DATA TRANSFER DATA TRANSFER DATA TRANSFER DATA TRANSFER INCREMENT ADDRESS INCREMENT ADDRESS DECREMENT VECTOR COUNTER GO TRANSFER NEXT VECTOR FETCH NUMBER OF VECTORS SET NUMBER OF REFRESH VECTORS TAKE AN IMMEDIATE REFRESH CYCLE AND RESUME REFRESHING RESTORE INDEX REGISTER 3 RETURN TO CALLING PROGRAM CONSTANTS AND VARIABLES DC DC DC DC DC DC DC IOCC 855 E DC DC 1024 PTSTR-6 1 4 IAOOO /04AO EYE POINT Z-COORDINATE X FOR GENERATOR CONVERSION Y FOR GENERATOR CONVERSION ADDRESS FOR ORDINAL POINT RECALL 1 FOR USE LOCALLY 4 FOR USE LOCALLY TEMPORARY STORAGE FOR XRFG 3 IN NONINTERRUPT ROUTINES GET AN EVEN ADDRESS LEVEL 1 INTERRUPT BIT SET PROGRAMMED INTERRUPT IOCC 68 #**********#********#***********************¥**¥**** # * * ac: REFRESH ROUTINE * * #************#**##**#*****#****************#*#**#*** RFRSH OUTLP RSTS * g * TIME RSAVE DC STS STD STX 1 STX 2 XIO LDX ll MDX 1 LOX L2 XIO LD 2 STO LD 2 STO LD 2 STO XIO MDX 2 MDX MDX X10 X10 LD STO L XIO LDD LDX I1 LDX I2 LDS BOSC I '— RSTS RSAVE RSAVE+2 RSAVE+3 TMOFF =VREF l RFSTR RNON 0 XOUT 1 YOUT 2 BMOUT VC OUT 3 -l OUTLP STDBY TMRST TIME /0006 TMON RSAVE RSAVE+2 RSAVE+3 D RFRSH REFRESH ROUTINE ENTRY POINT SAVE STATUS SAVE ACCUMULATOR SAVE XREG l SAVE XREG 2 PREVENT TIMER CYCLE STEALS GET NUMBER OF REFRESH VECTORS ADD EXTRA FOR LAST VECTOR FETCH STARTING ADDRESS OF RFSTR TURN RUN LINE ON FETCH X-SCREEN COORDINATE STORE IN ANALOG OUTPUT TABLE FETCH Y-SCREEN COORDINATE STORE IN ANALOG OUTPUT TABLE FETCH BEAM CONTROL STORE IN ANALOG OUTPUT TABLE OUTPUT VECTOR TO GENERATOR ADVANCE TO NEXT VECTOR ADDRESS DECREMENT VECTOR COUNT OUTPUT NEXT VECTOR PLACE GENERATOR IN RESET TIMER FETCH RERESH CYCLE TIME STORE AT TIMER LOCATION TURN TIMER ON RESTORE ACCUMULATOR RESTORE XREG l RESTORE XREG 2 RESTORE STATUS RETURN AND TURN OFF INTERRUPT STANDBY MODE CONSTANTS AND VARIABLES DC 855 E 855 -3 O 4 RERFESH CYCLE TIME GET EVEN ADDRESS STATUS SAVE STORAGE AREA OTAB XOUT YOUT BMOUT SBTAB IOCC'S DC DC DC DC DC DC DC DC DC DC DC DC IOOOO /O420 IZODO /0420 IOTZI LOGI lblOS VOTAB l6500 SBTAB l6500 69 TIMER TIMER TIMER TIMER STATE -- OFF STATE CONTROL IOCC STATE -- C ON STATE CONTROL IOCC DUMMY WORD FOR TIMER STATUS IOCC TIMER STATUS SENSE IOCC SEND OUT LOGIC 1 ON LINE 59 THE RUN LINE TABLE ADDRESS FOR ANALOG OUTPUT INITIALIZE WRITE TABLE ADDRESS FOR ANALOG OUTPUT INITIALIZE WRITE ANALOG OUTPUT TABLES TABLE TO OUTPUT VECTOR TO GENERATOR SINGLE SCAN WITH NO INTERRUPT ATTACH INPUT SWITCH LINE AND' TURN IT OFF ATTACH X-OUTPUT LINE AND SEND X-VOLTAGE OUT ATTACH Y-OUTPUT LINE AND SEND Y-VOLTAGE OUT ATTACH BEAM CONTROL LINE AND SEND BEAM VOLTAGE OUT ATTACH INPUT SWITCH LINE AND TURN IT ON TABLE FOR VECTOR GENERATOR STANDBY MODE DC I4OOA DC 7 DC LOGCO DC 2 DC DC 4 DC DC 3 DC DC 7 DC LOGCI DC IAOOA DC 7 DC LOGCO DC 3 DC 3276? DC 5 DC LOGCO DC 2 DC 0 DC 4 DC 0 SINGLE SCAN WITH NO INTERRUPT ATTACH INPUT SWITCH LINE AND TURN IT OFF ATTACH BEAM CONTROL LINE AND TURN IT OFF WITH 10 VOLTS ATTACH RUN LINE AND TURN IF OFF ATTACH X-OUTPUT LINE AND SET IT TO 0 ATTACH Y-OUTPUT LINE AND SET IT TO 0 70 ********#***#**#***#*****#****#*******##*#**#*#****$ * * OBJECT PARAMETER ENTRY ROUTINE * * g * ******#********#**##**#**#*****#*#***#******#******* * OBPOS DC STX LDX LD SLA A A STO LDX LD BSI LD STD LD STO LD BSI LD STO LD STO LD BSI LO STO LD STO LD STO LD STO LD STO LDX BSC 12 II L3 L3 II L3 L3 Il L3 L3 II N ~Jx