As a temporary measure the Library files for GINO as described in this third edition are named CAD/GINOSAL/E and CAD/GINO/GRAPHE. CAD/GINOSAL/* and CAD/GINO/GRAPH contain versions corresponding to the second edition (June, 1969). Users will be informed when the third edition is prefered; until then it may be used on an experimental basis.
The following brief summary of the new facilities in the third edition is provided for the benefit of those familiar with the earlier edition:-
June 1970
The version of GINO described in this third edition of the user's manual is a result of extensions and improvements made to the version described in the second edition. These improvements are the result of the experience of over a year's usage of GINO at the University Mathematical Laboratory and at the Ministry of Technology CAD Centre, Cambridge. The extensions are mainly in the direction of accommodating a larger range of graphical devices. This edition of the manual is a revision of the second edition. One consequence of this is that TITAN is used (except when obviously juxtaposed with 'ATLAS') to mean TITAN or ATLAS. The term PDP is also sometimes used to mean PDP or Elliott.
Some parts of the first version of GINO, which was the work of C.A. Lang, P.J. Payne, J.C. Gray, A.P. Armit and A.R. Forrest, are still in use. The bulk of the current version is the work of P.A. Woodsford. Contributions have also been made by P. Cross and R.P. Parkins and by C. Litherland and M. Newell of the Ministry of Technology CAD Centre.
The latter has also provided valuable feedback from the use of GINO at the Centre. C. A. Lang gave valuable advice about the design of GINO and A.W. Nutbourne helped with the presentation of this manual, which has been again typed most efficiently by Mrs. S. Williams.
GINO was developed by members of the Cambridge University CAD Group and is available on the TITAN computer. It is also available on the ATLAS computer at the Ministry of Technology CAD Centre, Madingley Road, Cambridge.
GINO provides a set of graphical facilities for use with the TITAN and ATLAS computers. A number of graphical devices can be used including the PDP 7/9 computer with DEC340 display, the Elliott 905 computer with 928 display, the CALCOMP digital plotter and the COMPLOT on-line plotter. Programs using GINO are basically independent of the particular graphical device used. An initialisation routine is provided for each device and this is the only routine which has to be changed when changing a GINO program from using one graphical device to another.
Two or three-dimensional pictures may be generated in TITAN or ATLAS and displayed (as two-dimensional projections) on any available graphical device. Optional transformation and windowing facilities are provided for use in generating pictures. Further facilities allow for applications using interactive graphics with the PDP or Elliott as a satellite of the central computer. These facilities include the naming of picture parts and the management of communications between the two machines.
The GINO routines are designed to be usable by programmers in any of the languages available in the TITAN Mixed Language System (MLS) (1).
It is anticipated that the majority of GINO users will write their programs in FORTRAN, SAL or Assembly Code. All examples of routine calls in the manual are given in the FORTRAN style, but complete sample programs in both FORTRAN and SAL are included.
The present facilities provided by GINO are:-
The routines to be described in Section 2 make up a system for generating 2D or 3D pictures for a range of graphical devices. The pictures produced appear as assemblages of lines, points and characters. However, they are generated as sequences of picture parts, and it is as such that we shall describe them.
The simplest kind of picture part is called a built-in object. Built-in objects are the basic components of pictures (e.g., lines, points, characters, arcs of circles) that are built-in to the GINO system.
Most pictures contain some kind of regularities in shape or pattern. In order to exploit such regularities, two other kinds of picture parts may be included in GINO pictures. One of these is the user-defined object. A user-defined object is defined by the user as a sequence of picture parts; once defined it has the same status as a built-in object. The other kind of picture part is the subpicture. It is also defined by the user, but has a much more specialised nature. The differences between objects and subpictures, as they affect the user, are tabulated in Fig. 2A. Subpictures are only available on devices that have a subroutining facility (i.e. the PDP & Elliott displays). They are used to shorten the length of a display file which contains repetitions of the same image by treating this image as a display subroutine. This facility is not available on the plotters and so when GINO is used for plotter output subpictures are treated like user-defined objects.
To summarise, GINO pictures consist of sequences of picture parts, where picture parts are built-in objects, user-defined objects and subpictures.
The function of each picture building routine is to add a picture part. Precisely what this means depends on the context of the routine call. The picture part can be added to the definition of a user-defined object, to the definition of a subpicture or to the picture being constructed. Definitions are explicitly opened and closed by the user; if no definition is open, the picture construction process takes place. The three processes are illustrated in Figs. 2B, 2C and 2D and discussed fully in Sections 2.2, 2.3 and 2.4.
Pictures must be specified in terms of space coordinates. Space coordinates must be cartesian; they may be in 2 or 3 dimensions (they will be denoted by upper case letters X,Y,Z). Space coordinates are abstract. They are chosen by the user to suit his picture and they are only restricted by the fact that they are held as TITAN integers (i.e., - 1048575 < X < 1048575, etc.)
Pictures are produced in terms of picture coordinates. (These will be denoted by lower case letters x, y, z.) Picture coordinates are either screen coordinates or plotter coordinates. In any case, their limits are the physical limits imposed by the output device (e.g., for the screen O < x < 1023; 0 < y < 1023). z is usually ignored, but there is an option with pictures for the display to vary the brightness of the picture with z (this is termed depth modulation).
In general a transformation is made from one coordinate system to the other. When this happens we shall speak of the total picture, expressed in space coordinates, being transformed into a view of the total picture, expressed in picture coordinates. Typical basic transformations are rotation, magnification, and projection. General transformations are built up as combinations of basic transformations.
In addition to this transformation process (described in detail in Section 2.6), the view may also be windowed (i.e., restricted to a visible 2D or 3D region specified by the user). Details of this are in Section 2.7.
A facility is provided for giving any picture part a name so that it can be identified by the light pen. This facility, which is only useful to those who wish to use the light pen for interactive work, is described in Section 2.8.
In general a GINO program can produce several pictures. For the PDP and Elliott displays each picture is a picture segment, which is the smallest amount of picture that can be individually displayed or replaced. Any number of picture segments can be displayed simultaneously and each one can be switched on and off. On plotters each new picture corresponds to moving the plotter on to fresh paper.
This highlights another distinction between user-defined objects and subpictures. An object definition is available for any number of pictures whereas a subpicture is local to a particular picture segment and will have to be redefined for each new picture segment.
The remaining sections deal with system initialisation, output facilities and routine specifications. Since most GINO programs are likely to be written in FORTRAN, sample programs and routine specifications are given in terms of FORTRAN. However, the routines may be used from SAL or assembly code and relevant details (and a sample SAL program) are also given.
| USER-DEFINED OBJECTS | SUBPICTURES |
|---|---|
| 1. Must be used if transformed views are required. | 1. Frozen in shape when defined and cannot subsequently be transformed. |
| 2. Full windowing facilities available. | 2. Not clipped when windowing. |
| 3. Definition takes more buffer space than a subpicture definition. | 3. Definition takes less buffer space than an object definition. Also the display file produced is shortened. |
| 4. May be used in any number of picture segments. | 4. Local to a particular picture segment. |
| 5. Available on all devices. | 5. Only effective on PDP & Elliott displays. |
Built-in objects are provided by single GINO routines and include such basic picture parts as points, lines, character strings and arcs of circles. They are used both in the definition of user-defined objects and subpictures, and as picture parts when constructing pictures.
Points and lines can be defined in two or three dimensions, (2D pictures can be considered as being set up in the plane z = 0.) A point is defined by its space coordinates. A line may either be defined as a vector increment or by its end point.
GINO pictures consist of ordered sequences of picture parts. At any point in the sequence there is a current position in the picture. In physical terms this corresponds to the position of the electron beam on the display screen or the pen on the plotter paper. In constructing a picture it is often necessary to change the current position before adding the next picture part. Points and lines can be added invisibly for this purpose. (The corresponding routine names are derived by prefixing the letter I to the visible routine name.)
Built-in object calls may be named so that they can be identified by the light pen. This facility is only useful to those interested in using the display interactively.
Each routine has an optional last argument for specifying the name associated with the built-in object call. Thus,
CALL LINE3(100,0,-100,81)
CALL LINE(20,60,82)
names the specified lines as 81 and 82, respectively. A pen hit anywhere on these lines will be identified with the appropriate name. (Further details of picture part naming are given in Section 2.8.)
The following routines are relevant to this section:
Name Purpose
BCDCHARS To add characters held in binary coded
decimal form.
CHARS To add a character string in FORTRAN
CHARINT To display an integer in character form.
CHARFPT To display a floating point number in
CHARREAL character form.
CHARTYPE To select the size of characters.
CIRCLE To add an arc of a circle
CIRCLE3 3D equivalent of CIRCLE
CONTROL To control light pen sensitivity,
hardware scaling and intensity.
CREATEDISPLAY To provide formatted output facilities
in FORTRAN
LINE,ILINE To add a 2D line, specified by vector
increments, visibly or invisibly.
LINEP,ILINEP To add a 2D line, specified by its
end point, visibly or invisibly.
LINE3,ILINE3 3D equivalents of LINE,ILINE.
LINEP3, ILINEP 3D equivalents of LINEP,ILINEP.
POINT,IPOINT To add a 2D point, visibly or invisibly.
POINT3,IPOINT3 3D equivalents of POINT,IPOINT.
.SALCHARS To add a character string in SAL.
Details of these routines are to be found in Section 2.13.
The purpose of user-defined objects is to allow the user to define for himself picture parts more complicated than those provided as built-in objects. Each user-defined object, once defined, can be called as many times as it is needed in the construction of a picture. A user-defined object is given an identifier when it is defined and this identifier is used to refer to the user-defined object when it is called. The identifier is a TITAN integer chosen by the user.
The definition process is illustrated in Fig. 2B. It is started by a call to routine DEFOBJ and closed by a call to routine ENDOBJ. Picture parts added between these two calls are added to the definition of the object and not to the picture being constructed. The object is given its identifier by the argument of DEFOBJ.
A concrete example will help the beginner. Suppose we need as a picture part a square of side 50 space units. This is not provided as a built-in object, so we must define it as a user-defined object. We decide to give it the identifier 10 and proceed as follows. The sketch illustrates the geometry.
CALL DEFOBJ(10)
CALL LINE(50,0)
CALL LINE(0,50)
CALL LINE(-50,0)
CALL LINE(0,-50)
CALL ENDOBJ
Notes:
We can now add the square to the picture how and when we need it. In fact we can use it in several different pictures or even file it away and use it another day.
There is no restriction on the picture parts which can be used in an object definition. They may be built-in objects, other user-defined objects or subpictures provided, of course, that the picture part is defined when it is called (since subpicture definitions are local to a picture segment, the case of subpictures within an object definition, whilst legal, is likely to be more trouble than it is worth).
There is only one restriction on the definition process.
Definitions may not be nested. A new object definition cannot be started before ending a previous one. Neither can we start a subpicture definition inside an object definition and vice versa.
Having defined object 10 we can now use it in the construction of a picture by calling routine OBJECT. Thus, to obtain a square at X = 500, Y = 500 space units:
CALL IPOINT(500,500)
CALL OBJECT(10)
is all that is required.
The particular merit of user-defined objects is that they are transformed and windowed each time they are called in the picture construction process (see Figs. 2A and 2D). The definition process is independent of any transformation or windowing bounds that have been set up, and is in terms of geometrical information only.
So our humble square object is not so humble. By calling it with suitable transformations set up we can get any square (by MAGNIFY and ROTATE) and even parallelograms (by SHEAR). Further, if we position it near a window boundary it will be appropriately clipped:
The reader familiar with the term will see that user-defined objects are succinctly described as picture macros, i.e., every time an object is added to the picture, code is inserted into the display file to generate the desired picture part.
We have so far dealt with case A in Fig. 2B in which the object definition is an identical copy of its component picture parts. There is an alternative facility in which the component picture parts of an object definition may be subjected to transformation and windowing (case B). The reader unfamiliar with these terms should just note this option until he has read Sections 2.6 and 2.7.
If DEFOBJ is given a second argument (the value of which is immaterial) then the component picture parts of the object definition are passed through the current transformation and windowing routines and the results are entered in the object/subpicture buffer as the object definition. In other words the object definition process is exactly the same as the picture construction process shown in Fig. 2D.
This facility allows for considerable flexibility. It allows the use of transformations in building up an object definition (Example 3 in Section 2.6 is a case of this). It may also be used to reverse the built-in order of transformation and then windowing by using windowing with transformations switched off at definition time and then transformation (and perhaps windowing) at call time.
When using this facility the user must take care to explicitly set the transformation and windowing environment he requires prior to defining the object.
User-defined object calls can be named for the light pen in the same way as built-in object calls. The name is an optional second argument, so if we add a square to the picture by
CALL OBJECT(10,I)
a pen hit anywhere on this particular square will be associated with the name given by the value of I.
Names may also be given at definition time to the component picture parts of a user-defined object. This leads to the nesting of names. Details are given in Section 2.8.
Facilities are available for deleting a user-defined object (thus freeing the space used), saving an object definition on backing store and recovering an object definition from backing store. Note that if an object identifier is reused the previous definition is automatically deleted.
The following routines are relevant to user-defined objects:
Name Purpose BUFFERS To set up a buffer for object definitions. DEFOBJ To open an object definition. DELETEOBJ To delete a user-defined object. ENDOBJ To close an object definition. GETOBJ To recover an object definition from backing store. OBJECT To call a user-defined object. SAVEOBJ To save an object definition on backing store.
Details are to be found in Section 2.13.
The purpose of subpictures is to allow users of the PDP and Elliott displays to define picture parts like user-defined objects, but of a more specialised nature. The differences between user-defined objects and subpictures have been tabulated already in Fig. 2A. The limitations and advantages of subpictures are such that they will only be useful in highly schematic contexts such as circuit layouts.
These differences hinge on the fact that only a single copy of each subpicture exists in the display file, repeated subpicture calls causing the same display file code to be executed. On the other hand, each object call has its own display file.
The mechanics of using subpictures is the same as for using objects. Each subpicture must be given an identifier and must be defined before it can be called.
The definition process is illustrated in Fig. 2C. To the programmer it mirrors the process of defining an object, the corresponding routines being DEFSUB and ENDSUB. Between a call to DEFSUB and a call to ENDSUB, picture parts are added to the subpicture definition and not to the picture being constructed. The restriction on nesting of subpicture definitions is precisely the same as for object definitions and so a subpicture definition cannot be started while another is unfinished.
Again we take an example. Suppose we wish to use a subpicture for a special symbol (a cross) to be used to mark data points on a graph. We have decided to give this subpicture the identifier 7 and so we proceed as follows. In the sketch illustrating the geometry, full lines are visible and broken lines are invisible.
CALL DEFSUB(7)
CALL LINE (5, 5)
CALL ILINE(0,-10)
CALL LINE(-10,10)
CALL ILINE(0,-10)
CALL LINE(5,5)
CALL ENDSUB
Having defined subpicture 7 we can now add it to the picture where and when we need it by calling routine SUBPIC. If we are using our cross subpicture to mark data points on a graph made up of straight line segments we might proceed as follows (the arrays IX, IY hold coordinates for the N data points):
DO 10 J = 1,N
CALL LINEP(IX(J),IY(J))
10 CALL SUBPIC(7)
Note that since LINEP draws a line from the current position to (IX(J), IY(J)), the current position must be correctly fixed before entering the DO loop.
Notes:
Subpictures are not as powerful as user-defined objects. They are not transformed each time they are called (see Fig. 2D) and so are frozen in shape when they are defined. Furthermore, they are not clipped when windowing. Either the whole subpicture is displayed or, if any part of it is outside the window, then it is omitted entirely. The advantages of using subpictures are that the display file is shortened and that less TITAN core space is needed. (Subpicture definitions use much less space than object definitions.) Subpictures are chiefly used for special symbols like crosses on a graph or electrical circuit symbols.
Notes:
Subpictures are analogous to ordinary program subroutines without arguments.
Like user-defined objects, subpictures may be made up of any defined picture parts. It is usual, however, only to use incremental picture parts like lines and character strings in subpicture definitions. This is because a subpicture containing an absolute point will always appear in the same position, no matter what was the current position when the subpicture was called. This effect is generally unwelcome although it can be useful, eg when making character strings stand out brighter than the rest of the picture by displaying them several times over.
Subpicture calls, like all other picture parts, can be given a name for purposes of identification by the light pen. An optional second argument of SUBPIC is used to specify this name. A special PDP program (the Display File Manager) must be used in running display files containing named subpicture calls (this is dealt with in Section 2.8).
There is no facility for deleting an individual subpicture definition. A call to routine BUFFERS deletes all current subpicture definitions.
The following routines are relevant to subpictures:
Name Purpose BUFFERS To set up a buffer for subpicture definitions. DEFSUB To open a subpicture definition. ENDSUB To close a subpicture definition. SUBPIC To call a subpicture.
Details are to be found in Section 2.13.
Initialisation of the GINO system is in two stages. First is the basic initialisation of the system to produce output for a particular graphical device. This will normally only be done once. Second is the initialisation of each new picture. When using a display, a new picture involves starting a new display file. When using a plotter it involves moving to fresh paper. Since a typical GINO program produces several pictures, this initialisation may be repeated several times.
There is one basic initialisation routine for each available graphical device. One of these must be called before any other GINO routine. This causes GINO to be loaded with the code generating routines for the chosen device and no other. Only one graphical device can be used by a given program and a program is not allowed to contain more than one of the basis initialisation routines. However, to change from one device to another only the initialisation routine has to be changed.
The current set of basis initialisation routines is
Name Graphical Device Availability DF Buffer
needed
PDPGINO DEC 340 display with PDP7 TITAN & ATLAS yes
or PDP9 computer
ELLIOTTGINO Elliott 928 display with ATLAS yes
905 computer
PLOTTERGINO Calcomp digital plotter TITAN & ATLAS no
(2 sizes)
COMPLOTGINO Complot on-line plotter ATLAS no
The user program must supply buffer space to GINO. Each buffer is specified by 3 arguments - the start address, the length and an overflow error label. For the PDP and Elliott displays, the picture. is built in a display file buffer, which must be supplied. Output for other devices (e.g. PLOTTERGINO, COMPLOTGINO) is sent to an output stream and so a display file buffer is not required and if one is declared it is ignored.
The second buffer which may be required is the object/subpicture buffer which must be provided if either user-defined objects or subpictures are used.
The routine used to set up the required buffer space is called BUFFERS and it must be called before any picture part routine is called. With PDPGINO and ELLIOTTGINO it may be called with 3 arguments to set up the display file buffer or with 6 arguments to set up both buffers. With PLOTTERGINO and COMPLOTGINO a call with 3 arguments sets up the object/subpicture buffer and a call with no arguments is used if user-defined objects and subpictures are not required. A call with 6 arguments is not rejected but the space declared for the display file buffer is wasted.
In addition to establishing buffer space, a call to BUFFERS also starts a new picture. Once buffer space has been established, BUFFERS may be called with no arguments to start a new picture, reusing the same buffer space. User-defined object definitions will still be available since they are global but all subpicture definitions will be lost since they are local to a particular picture. Object definitions are only lost if the basic initialisation call (e.g., ELLIOTTGINO, PLOTTERGINO) is repeated or if the location of the object/subpicture buffer is changed.
The user does not need to declare any COMMON variables for the GINO system. Internally the system uses named COMMON blocks to hold the transformation matrix and the current position. The user may declare the necessary COMMON blocks if he wishes to have access to this information (the details are in the next section).
FORTRAN users can economise on the space taken by their programs by using arrays in blank COMMON for their buffers. This reuses space used by the loader which is otherwise wasted, e.g.,
COMMON BUFF(400)
CALL PDPGINO
ASSIGN 99 TO L
CALL BUFFERS(BUFF(1),200,L,BUFF(201),200,L)
The first three arguments of BUFFERS specify the display file buffer (giving start address, length and overflow label). The second three specify the object/subpicture buffer in similar fashion. Details of how much buffer space the user should allow, etc., are to be found in the routine specifications in Section 2.13.
The ability to transform picture parts during the picture construction process is essential for 3D work and very useful for 2D work. Transformations include scaling, translation, rotation and point projection in any combination. They are an optional feature in GINO.
In 3D work the basic reason for using transformations is to allow us to produce different views (projections) of total pictures. For instance having defined a simple rectangular box we might wish to view it as an isometric projection:
Routines are provided for this and for any other projection. These routines all work by projecting on to a picture plane passing through the origin of space coordinates (they have to make some assumption about the total picture being viewed - the assumption made, that the centre of interest is at the origin, seems to be the most reasonable).
The view produced will always have to be related to the coordinate system of the display or plotter being used. All the devices currently available with GINO have their origin of coordinates at the bottom left hand corner and only permit positive coordinate values. So a second transformation is necessary to position the view on the screen or paper. It may also be necessary to scale the view to fit the available area.
We have described the use of the transformation facility for two distinct purposes - to project the total picture so as to produce the required view and then to position (and perhaps scale) the view to the appropriate position on the screen or paper. There are many other uses. For instance we may regard the screen as a window on to a large total picture and use the windowing facility (described in Section 2.7) to remove all parts of the picture outside the window. Then we would use transformations to position the appropriate part of the total picture under the visible window. Another use is in connection with the facility to transform a user-defined object while it is being defined (see Section 2.3). This enables us to use transformations in building up an object. This can be very useful for example in an object which has axial symmetry.
When GINO is set in transform mode (which can be switched on and off as required) the space coordinates in the total picture are multiplied by the current transformation matrix to produce the corresponding picture coordinates. This is shown in the diagram of the picture construction process, FIG 2D.
Mathematically we have
r = M R (*)
where
r = (x,y,z) is a position vector in picture coordinates
R = (X,Y,Z) is the corresponding position vector in
space coordinates
M = current transformation matrix (TR matrix)
(In fact, homogeneous coordinates and (4×4) transformation matrices are used, so as to include projective transformations. The theory of this is given in (9).)
Note that M in equation (*) above is the matrix current when the picture part is called in the picture construction process. The required transformation must therefore be set up before constructing the picture. The x - y plane is taken as the picture plane and z is ignored unless depth modulation (as described in the next section) is used.
The current TR matrix is built up by calls to basic transformation routines so that it represents the cumulative effect of the sequence of transformations. Thus in the simplest case, that of producing an isometric or perspective projection, two routines will be used to set up the TR matrix. The first (ISOMETRIC or FROMXYZ) sets up the projection. The second (OSHIFT) positions the resulting view. Conceptually it is easiest to think of these as separate operations - in fact they are achieved by a single matrix multiplication of the form (*) above.
In general the TR matrix will be built up from some sequence of translations, rotations, magnifications and point projections. The effect achieved is as if each picture part were subjected to this sequence of transformations. Of course the order of the sequence is often crucial, particularly in 3D work. For instance a translation followed by a rotation will in general produce a different result than a rotation followed by a translation.
Transformations do not affect the position of the space coordinate axes, which remain fixed. They only affect position,orientation and scale relative to these axes. Suppose we set up a TR matrix as follows:
CALL SETTRANSFORM - initialise to unit matrix
CALL OSHIFT(-500.,0.) - translate through DX = -500., DY = 0.
CALL ROTATE(2,-120.) - rotate -120° about Y axis
If we then ask for a line AB joining (400,400) to (600,600) we shall get A'B' (A" B" represents position of line if shifted only).
If we ask for CD joining (-100,400) to (100,600) we will get C'D'. Note that the rotation is still about the fixed Y axis.
N.B. D" is closer to the axis of rotation than C". Hence D' is also closer than C'.
If we had followed the rotation by another translation through DX= 500,, DY= 0, we would have the effect of a rotation not about the Y axis but about a parallel axis through X = 500.
CALL SETTRANS
CALL OSHIFT(-500.,0.) - shift the point (X=500,Y=0) to Y axis
CALL ROTATE (2,-120.) - rotate about Y axis
CALL OSHIFT(500.,0.) - undo previous shift
This is the standard technique for effectively changing the coordinate system.
We emphasise again that in order to use transformations GINO must be set into transform mode by call routine SETTRANSFORM and the appropriate TR matrix must be built up by calls to transformation routines before the picture is constructed. The transformation applied to a given picture part is the one current when that picture part is called.
Some care is necessary in the choice of space coordinates, since rotations, scalings etc. all work relative to the fixed space coordinate axes. This is particularly important in 3D work where it is best to arrange that the centre of interest of the total picture is at the origin. Note that this means that the total picture must at least start with an absolute point (e.g. IPOINT3).
If we are using transformations to produce a particular view then the transformation matrix is built up from a call to the appropriate projection routine followed by scaling and positioning routines. If the total picture does not centre on the origin then a translation before the projection may be used to position it for the projection routine. (This is the same technique as used above for rotations.)
Routines are provided to set up several standard axonometric projections. These are projections in which the projection point is at infinity. The main virtues of axonometrics are the relative ease with which they can be produced in the drawing office and the absence of any distortion. Using GINO it is just as easy to produce full perspective views in which the projection point is a local point. These will be characterised by having vanishing points and will generally produce a more pleasing visual effect (see FIGS 2E, 2F). FIG 2G shows a simple rectangular parallelipiped under eight different projections.
Having chosen the required projection there remains the problem of relating the view to the coordinate system of the display or plotter. The simplest and most efficient way of doing this is to follow the projection with a shift to the centre of the screen e.g.,
CALL SETTRANSFORM
C INITIALISE TO UNIT MATRIX
CALL FROMXYZ(1000.,200.,1500.)
C FULL PERSPECTIVE VIEW FROM X=1000, Y=200, Z=1500
CALL OSHIFT(511.,511.)
C POSITION TO CENTRE OF SCREEN
A problem arises if the transformed view does not fit in the available area. Two solutions are possible. One is to use the windowing facility (described in the next section) to remove everything falling outside the available area. This takes very little extra computing but may not be satisfactory if the user wants to see the whole view. The other approach copes with this. A routine (named PICTURE) is available which automatically scales and positions the transformed view to fit exactly into a specified area. It requires that the total picture be defined as a single user-defined object and does involve rather more computing than the straightforward method. Suppose the total picture consists of user-defined object 1 and an axonometric projection is required with line of sight joining X=100, Y=50, Z=80 to the origin. We are plotting and we require that the plotted view should fill the paper:-
CALL SETTRANSFORM
CALL AXONXYZ(100.,50.,80.)
C WE NOW HAVE THE REQUIRED PROJECTION.
CALL PICTURE(1,5,1055,5,1055)
C OBJECT 1, UNDER THE REQUIRED PROJECTION, IS MAPPED ON TO
C 5 < x < 1055, 5 < y < 1055 ON THE PLOTTER PAPER.
Which approach to adopt depends on circumstances. Automatic scaling and positioning is suitable for non-interactive work - when working interactively scaling and positioning is best controlled by the user.
The easiest way to use transformations in building up a total picture is to use the facility to pass the component parts of a user-defined object through the current transformation (and windowing routine) while that object is being defined (see Section 2.3). Care is needed here due to the fact that the transformations have a cumulative effect, e.g. a rotation is superimposed on the existing transformation - if a rotation on its own is required, the TR matrix must be set to the unit matrix (by CALL SETTRANSFORM) before ROTATE is called. When building up an object in this way it is often convenient to save the current transformation and later restore it, rather than build it up again. Routines SAVETRANSFORM and SETTRANSFORM can be used to do this. It is also useful to suspend transform mode temporarily so that picture parts are not transformed at all. Routines UNSETTRANS and RESETTRANS provide this facility.
Some GINO programs will not need transformations at all. If a program does not contain calls to any transformation routines then none of the transformation machinery is loaded.
This example shows the use of transformations in 2D to produce composite pictures. Suppose we have four 2D user-defined objects, identified as 1, 2, 3 and 4. Each would fill the screen if displayed directly. We construct a composite picture in which each object occupies one quarter of the screen area.
CALL SETTRANSFORM
C TRANSFORM MODE ON. TR MATRIX= UNIT MATRIX
CALL MAGNIFY (0.5,0.5)
C REDUCE TO HALF SIZE
CALL OSHIFT (0.,511.)
C ORIGIN NOW APPEARS AT x = 0, y = 511
CALL OBJECT (1)
CALL OSHIFT (511.,0.)
C ORIGIN NOW APPEARS AT x = 511, y = 511
CALL OBJECT(2)
CALL OSHIFT (-511.,-511.)
C ORIGIN NOW APPEARS AT x = 0, y = 0
CALL OBJECT(3)
CALL OSHIFT (511.,0.)
C ORIGIN NOW APPEARS AT x = 511, y = 0)
CALL OBJECT(4)
CALL DFOUTR
C OUTPUT IN RELOCATABLE FORM FOR THE DISPLAY FILE MANAGER
The make-up of the resulting picture is shown in the sketch below:
This example shows how to use transformations to map a given rectangular area on to the whole screen. Then by using the windowing facility to remove all parts of the picture that would fall outside the screen area we can examine any part of the total picture in detail.
Suppose the required visible area ABCD is bounded by x0≤x≤x1; y0≤y≤y1 (space coordinates) and that these bounds are held in Fortran real variables x0,x1,y0,y1. Then to achieve the desired effect the following program must be executed before the picture is constructed:
CALL SETTRANSFORM
C PARTS OF THE TRANSFORMED VIEW OUTSIDE 0≤x≤1023, 0≤x≤1023 - THE SCREEN
C SIZE - ARE TO BE REMOVED BY THE CLIPPING ROUTINES
CALL SETWINDOW(0,1023,0,1023)
C SHIFT SO THAT POINT A WOULD BE MOVED TO ORIGIN
CALL OSHIFT(-x0,-y0)
C MAGNIFY SO THAT ABCD WILL FILL SCREEN
FX = 1023./(x1-x0)
FY = 1023./(y1-y0)
CALL MAGNIFY (FX,FY)
C NOW PROCEED TO CALL PICTURE PARTS TO CONSTRUCT PICTURE.
We wish to construct and view a rudimentary lawn sprinkler. The arm of the sprinkler is defined as a user-defined object. The sprinkler is defined as a second user-defined object. The component parts of this second object are transformed as the object is defined, so that the arm can be rotated into its different positions. Finally we produce an isometric projection and position it as required.
C DEFINE THE SPRINKLER ARM OF THIS OBJECT AS OBJECT 1. THE COMPONENT PARTS
C OF THIS OBJECT ARE NOT TRANSFORMED. y-AXIS IS TO BE AXIS OF SPRINKLER
CALL DEFOBJ(l}
CALL IPOINT3(0,100,0)
CALL LINE3(200,0,0}
CALL LINE3(0,0,-20)
CALL LINE3(-30,0,-30}
CALL LINE3(60,0,0)
CALL LINE3(-30,0,30)
CALL ENDOBJ
C DEFINE WHOLE SPRINKLER AS OBJECT 2. COMPONENT PARTS ARE TO BE
C TRANSFORMED - HENCE SECOND ARG OF DEFOBJ
CALL DEFOBJ(2,1)
DO 1 I=1,3
CALL SETTRANS
D=I*120
CALL ROTATE(2,D)
CALL OBJECT(1)
C WE NOW HAVE 3 ARMS EVENLY SPACED. THE CENTRE SHAFT DOES
C NOT NEED TRANSFORMATION
CALL UNSETTRANS
CALL IPOINT3(0,100,0)
CALL LINEP3(0,-100,0)
CALL ENDOBJ
C WE NOW SET UP AN ISOMETRIC PROJECTION. NOTE THAT OBJECT 2
C IS CORRECTLY CENTRED ABOUT THE ORIGIN OF SPACE COORDINATES
C WE HAVE FIRST TO RESET TR MATRIX TO UNIT MATRIX
CALL SETTRANS
CALL ISOMETRIC
C THEN A SHIFT TO POSITION THE VIEW
CALL OSHIFT(511.,511.)
C FINALLY WE CALL OBJECT 2 PRODUCING THE OUTPUT SHOWN BELOW
CALL OBJECT(2)
The reader will have noticed that most of the arguments of the transformation modifying routines are reals. This is because the TR matrix is necessarily real. The only integer arguments are those specifying axes, where 1 indicates the x-axis etc.
A user who intends using his own matrices will need to know the format of the TR matrix. This is given in the specification of SETTRANSFORM in Section 2.13. The salient point is that matrix multiplication is taken as pre-multiplication.
As mentioned in Section 2.5, transformation information is held in FORTRAN named COMMON blocks, so that it is accessible to the user. The following information is available:
Thus, if we declare
COMMON/TRBOD/T(4,4)/SPACEPOS/IX,IY,IZ/PICTPOS/JX,JY,JZ.
Then T contains the TR matrix, (IX,IY,IZ) is the current position in space coordinates and (JX,JY,JZ) in picture coordinates.
The following routines are relevant to transformations:
AXONXYZ To set up an axonometric projection along the line joining (X,Y,Z) to the origin.
CABINET To set up a cabinet projection.
CAVALIER To set up a cavalier projection.
DIMETRIC To set up a dimetric projection.
FROMXYZ To set up a perspective view, with (X,Y,Z) as
viewpoint and horizontal line of sight towards origin.
ISOMETRIC To set up an isometric projection.
MAGNIFY To superimpose a magnification.
MODTRANS To multiply TR matrix by a user-supplied matrix.
OFIX To fix point (0,0,0) of space coordinates to be
specified point.
OSHIFT To translate through a specified vector.
PICTURE To call an object, mapping the resulting view
(i.e. the view under the current transformation)
onto a specified picture area.
PROJECT To project from a point on a coordinate axis onto
x-y plane as picture plane.
PROJXYZ To set up a perspective view with (X,Y,Z) as
viewpoint and line of sight through origin.
ROTATE To superimpose a rotation about a coordinate axis.
SAVETRANSFORM To save current TR matrix in a user-supplied array.
SELECTVIEW To permute coordinate axis, thus selecting new
picture plane.
SETTRANSFORM To set transform mode and initialise TR matrix.
SHEAR To superimpose a shear transformation.
TRIMETRIC To set up a trimetric projection.
UNSETTRANS To unset/reset transform mode.
RESETTRANS
Details of these routines are to be found in the second half of Section 2.13.
The range of picture coordinates is dictated by the size of the display or plotter used and is much smaller than the range of space coordinates. An attempt to draw outside the available area is termed an edge violation. The behaviour of each graphical device when an edge violation occurs is described in section 2.11. In general edge violations should be avoided and this is one of the purposes of the windowing facilities in GINO. This use was referred to in the last section.
The windowing facilities can also be used to examine a particular region of the total picture. This region may be defined in 2D or in 3D. Only parts of the total picture falling in the chosen visible region will appear. One technique for doing this was illustrated earlier.
Two types of windowing operations are provided in GINO - 2D windowing and 3D windowing. A program may select either or none of these. In the normal picture construction process (illustrated in Fig. 2D) the windowing operation takes place after transformation, i.e. on picture coordinates. This is the most useful order as it enables windowing to be used to avoid edge violations. When circumstances arise in which another order of operation is required, the facility to transform and window the component parts of an object definition, as already described in section 2.3, may be used. In this case the distinction between space and picture coordinates becomes blurred.
The user can specify a rectangular window in the picture plane. The picture is then clipped so that only parts within the window appear in the picture.
Picture parts added as objects (built-in or user-defined) are clipped exactly (the only exception being that character strings are clipped to the nearest character). Picture parts added as subpictures are only displayed if entirely within the window.
The user sets up the window bounds by a call to routine SETWINDOW. The presence of a call to this routine causes the system routines for 2D windowing to be loaded. (See Fig. 2D.) In the normal case the window bounds are in terms of picture coordinates. So if we just wish to avoid edge violations on the display we can set the window by
CALL SETWINDOW(0,1023,0,1023)
The user can, however, set the window bounds to any value he requires.
When 3D windowing is used, clipping is to a rectangular parallelipiped or box defined by
BW ≤ x ≤ BE; BS ≤ y ≤ BN; BACK≤ z ≤ FRONT
In the usual case (when x and y are in the picture plane), z is normal to the picture plane and towards the viewer. The bounds are set and the appropriate windowing routines loaded by a call to routine SET3DWINDOW. Clipping to the 3D window is exact, so the effect of a depth cursor can be achieved by making the 3D window be a narrow band at the relevant z value. 3D windowing may be used to remove clutter from the foreground or background of a picture and it is also used in connection with depth modulation (see below).
3D windowing as provided in GINO should not be confused with clipping to a pyramid of view, as required when perspective transformations are used. This is essentially a 2D windowing operation and is provided by the 2D windowing option in GINO. (See Section 6 of (13)).
In all 2D representations of 3D total pictures, the third dimension presents a problem. The most useful visualisation aid provided in GINO is depth modulation. This is available on the PDP and Elliott displays. The brightness of the picture is modulated over the intensity levels of the display, with maximum intensity at the front and minimum at the back of the visible z-region. Six intensity levels are used on the PDP and five (two of them simulated) on the Elliott. Depth modulation is automatically switched on by a call to SET3DWINDOW. The user can then switch it on and off as required.
The following example shows how the transformation and windowing routines together can be used to produce quite complicated effects. User-defined object 99 is an aeroplane occupying a region of space within the bounds
X -4000 (nose) to +4000 (tail) Y -1000 (bottom) to +1000 (top) of fuselage Z -4000 (starboard wing tip) to +4000 (port wing tip)
We wish to obtain two pictures:
We proceed as follows. In the comments we locate the nose (N) and tail (T).
CALL SETTRANSFORM
CALL MAGNIFY (0.25,0.25,0.25)
C REDUCE TO QUARTER SIZE. N AT (-1000,0,0). T AT (+1000,0,0)
CALL OSHIFT (1023.,767.)
C N AT (23,767,0). T AT (2023,767,0).
CALL SET3DWINDOW (0,1023,512,1013,-1000,1000)
C UPPER HALF OF SCREEN. INTRODUCES DEPTH MODULATION ACROSS WING SPAN
CALL OBJECT (99)
C TOP HALF OF FIRST PICTURE. N DISPLAYED. T CLIPPED.
CALL SETTRANSFORM
C TR MATRIX RESET TO UNITY.
CALL MAGNIFY (0.25,0.25,0.25)
CALL OSHIFT (0.,255.)
C NAT (-1000,255,0). T AT (1000,255,0)
CALL SET3DWINDOW (0,1023,0,511,-1000,1000)
CALL OBJECT(99)
C BOTTOM HALF OF FIRST PICTURE. N CLIPPED. T DISPLAYED.
CALL DFPUNB
C FIRST PICTURE OUTPUT ON PAPER TAPE
.............
CALL SETTRANSFORM
CALL MAGNIFY (0.5,0.5,0.5)
C N AT (-2000,0). T AT (2000,0,0)
CALL OSHIFT (-1500.,0.)
C N AT (-3500,0,0). T AT (500,0,0). REAR QUARTER NOW
C CENTRES ON ORIGIN
CALL ROTATE (2,-30.)
C ROTATES ABOUT Y AXIS 30° TOWARDS VIEWER
CALL OSHIFT (511.,511.)
C SHIFTS ROTATED VIEW TO CENTRE OF SCREEN
CALL SET3DWINDOW (0,1023,0,1023,0,500)
C CLIPS PART OF TAIL BEHIND AXIS OF ROTATION AND
C POSSIBLY PART OF WING
CALL OBJECT (99)
CALL DFPUNB
C OUTPUT SECOND PICTURE TO PAPER TAPE
A problem often arises in setting the values of the z-bounds in SET3DWINDOW. If the bounds are set too far apart, the picture produced will only use part of the available range of intensities. If they are too close part of the picture that was required may be removed by the clipping. Two routines are provided to help with this. PICTZCLIP is an extension of the automatic scaling and positioning routine, PICTURE.
As well as specifying the x-y region the picture is to occupy,the visible z-range can be specified on a normalized scale in which the back of the whole object is represented by 0 (zero) and the front by 1. Thus to view the front half only values of 0.5 and 1.0 would be used.
PICTZCLIP invokes the whole machinery of 3D-windowing, which may well be redundant. In the case where depth modulation without clipping is required the routine OBJZDM should be used. This displays any view of a user-defined object, with depth modulation across the full range of z, and no clipping. Space and time are saved since SET3DWINDOW is not used.
2D-windowing adds about 600 words to the length of a TITAN program. 3D-windowing and depth modulation adds about 950 words and lengthens the display file. The cost in terms of time depends on the number of boundary intersections. Even if there are no intersections, there is a slight penalty so windowing should not be used if it is not required (e.g., with the graph routines of Section 3).
There are some anomalies in the windowing of subpictures. Subpictures are not clipped. They are either displayed as a whole, or omitted. This process only works properly for subpictures containing only incremental picture parts. Subpictures containing absolute points or hardware scale changes are always displayed and may give rise to boundary violations.
Programs must not include calls to both SETWINDOW and SET3DWINDOW. 2D-windowing is included in 3D-windowing and may be obtained by setting large z-bounds (e.g., -1000000 < z < 1000000) and turning depth modulation off. If a program contains SETWINDOW or SET3DWINDOW, bounds appropriate to the size of the screen or plotter are assumed until the bounds are explicitly set.
The following routines are relevant to this section:
DEPTHON To restore depth modulation.
DEPTHOFF To suspend depth modulation.
OBJZDM To provide automatic depth modulation
across the full range of z.
PICTZCLIP To provide automatic scaling, positioning,
clipping and depth modulation.
SETWINDOW To set up a 2D-window.
SET3DWINDOW To set up a 3D-window and initiate depth modulation.
Full details are in the routine specifications in Section 2.13.
Every picture part used in the picture construction process may be given a name. The purpose of this name is to enable the picture part to be identified by the light pen. This facility is essential if the light pen is to be used as a tool in interactive graphics. It is of no interest to the user who does not intend to use the light pen in this way.
The name of a picture part is specified by giving an optional last argument in the relevant routine call, as described in Sections 2.2, 2.3 and 2.4. The use of the term name may cause difficulty to those who think of names as things like FRED or X or GINO. Picture part names are, in fact, numbers which the user may assign in order to identify picture parts. This number may be specified either by a constant, or by using a program variable, e.g.,
CALL LINE (100,200,3)
C The name of the line is 3
CALL LINE (200,100,K)
C The name of the line is the value of K
The name is used effectively to identify what a picture part represents, rather than the picture part itself. For example, when pointing at a circle which is part of a picture of a car the name may be used to identify it as the nearside front wheel, rather than just a circle.
The name may be used in various ways. The simplest is just as a code number. For example, suppose we wish to display a sequence of squares (already defined as user-defined object 6) across the screen. The squares are to be distinguished by having names 1 to 10.
DO 1 I= 0,9
CALL IPOINT (100*I,500)
1 CALL OBJECT (6,I+l)
A second way that names may be used is as pointers to a data structure. When parts of the car are pointed at with the light pen, the program may need to access information about the part pointed at. For instance, information about the wheel (tyre characteristics, materials, weight, etc.) might be held in some kind of data structure. If we make the name of the picture part representing the wheel a pointer to the data structure representing the wheel, then, when the wheel is pointed at by the light pen, we can get very fast access to the wheel information without any searching.
Suppose user-defined object 20 is a wheel. Then we might say
Note: The value of variable NAME points to the data structure representing the wheel.
Picture parts may also be given names when they are used in the construction of a user-defined object, so that the individual parts of a user-defined object can be distinguished by name.
The object may also be named when it is called. This leads to the nesting of picture part names, so that a given picture part may be distinguished as say picture part I within picture part J within picture part K. The maximum allowed depth of nesting is 16 although 4 is nearly always enough and is the maximum assumed in the standard version of the Display File Manager and the Handler (described in Section 6.3).
Subpictures are treated differently. They are regarded as atomic entities and their component picture parts cannot be distinguished by name. Names given to picture parts used in the definition of a subpicture are ignored and a warning message given.
One of the parameters of the display is light pen sensitivity. When the pen is turned on circuits are enabled so that the display is interrupted whenever the light pen can see light. The pen has a manually operated shutter and so can be used as a pointing device on the screen. When an interrupt occurs owing to the pen seeing light from a particular picture part we say that a pen hit has occurred on that picture part. When the pen is turned off, pen hits cannot occur. Pen sensitivity is controlled by the display file so it is possible to turn the pen on for some picture parts and off for others. The user can do this explicitly using routine CONTROL. Without any action on the part of the user, the GINO system turns the pen on for named picture parts and off for unnamed picture parts.
The Display File Manager (DFM) is the basic satellite program for managing display files. One of the functions of DFM is to deal with pen hits on named picture parts. When a pen hit occurs DFM passes control to the user's satellite program with the relevant name (or stack of names) in a standard position. This may result in some computation in the satellite or in the transmission of the name(s) to TITAN for computation and possible picture modification there. The facilities for transmitting information over the link are described in Section 5 and more details of DFM are in Section 6.3.
The Interactive Handler is a satellite program designed to make the facilities of an interactive graphics terminal easily accessible from FORTRAN programs running in ATLAS (or TITAN). The Handler may be used without writing any satellite code at all. It provides the following facilities for handling named picture parts and many other facilities described in Section 6.3.
After transmission the list can be converted into a FORTRAN array and processed.
Versions of DFM and the Handler exist for both the PDP 7/9 and the Elliott 905 computers.
The display file segment number is always recorded with each pen hit since any modification to the picture part chosen will involve the replacement of this segment. The usual strategy in highly interactive work is to use a large number of display file segments so that the amount of display file to be replaced will be small.
The name of a picture part should not be confused with the identifier of a user-defined object or subpicture.
Picture part names are only available to the programmer. If a user wishes some name to appear on the picture beside the picture part he must program this explicitly. The Interactive Handler provides a facility akin to this. A piece of display file may be associated with a call to a user-defined object and this associated display file will only be displayed when the object is selected by the light pen. The routine for adding an associated display file is called ASSOCIATE.
Names are TITAN integers, excluding 0 (zero) which is regarded as the null name. Unless nested names are used (in which case only unique combinations should be employed) unique names should be given to each picture part.
The routines so far described are used to generate pictures for a variety of graphical output devices. We now consider methods of actually outputting and displaying pictures. The output devices fall into two classes, depending on whether or not they are associated with a satellite computer.
These two displays are associated with satellite computers. PDPGINO or ELLIOTTGINO are the appropriate initialisation routines. We need to distinguish two cases depending on whether the display file is loaded into the satellite from paper tape or sent directly over the link.
Display file paper tapes are punched out in binary form by routine DFPUNB or in character form by routine DFPUNC. Relocation (i.e., setting up the display file to be loaded at a particular satellite address) is then performed in the satellite by loading the tape with the Display File Tape Loader (DFTL). The specification of DFTL is in Section 6.2. Binary tapes are approximately one third the length of character tapes and should be used unless the user wishes to print his display file as well as display it.
The methods of sending display files to the satellite over the link divide into two categories depending on whether the user is logged in in normal mode or expensive mode on TITAN. In normal mode the display file has to be output in binary to a disc file or pending stream and then sent over the link by use of the PDP command (this is one of the commands available on the Cambridge Multiaccess System (10)). In expensive mode link transmissions can be initiated at any time and the display file can be sent to the satellite as soon as it is constructed. In either case there are two options. The display file can be relocated in TITAN and sent to the appropriate satellite address (optionally with a small program to make it self-running). Alternatively, the display file can be transmitted in relocatable form. The Display File Manager (DFM) is used to organise relocation of such transmissions. DFM treats each link transmission as a picture segment and provides facilities for displaying several picture segments, switching picture segments on and off, etc. (Details are in Section 6.3.)
In normal mode the first effect is achieved by using routine DFOUTB, which outputs the display file in binary, together with a small program to run the display. The second effect is obtained by using routine DFOUTR. In expensive mode both effects can be obtained by using routine SENDPDP. Note that this is the method that must be used for real time manipulation of pictures (details of this are in Section 5).
It should be noted that the PDP and Elliott links are handled in the same manner by the ATLAS supervisor. They are only differentiated at the time when the link is created (by the SIGNAL command when in expensive mode, see specification (10)).
Since DFOUTB, DFOUTR and DFOUTC (for relocated character output) send their output to a stream set up by the user, display files in character or binary form can be sent to disc file, paper tape or magnetic tape. They can then be displayed or plotted as and when required.
Pictures produced as display files can be plotted on the CALCOMP plotter by outputting them to a disc file and reading them back into core and plotting them using routine DFPLOT described in Section 4. Display files which have been sent to the PDP or the Elliott to run under DFM can also be read back for plotting (see Section 6.3).
It is possible also to generate display files and plotter output in the same program by using routines PLOTPDP or PLOTELL to translate the display file produced into plotter output. To do this PDPGINO or ELLIOTTGINO will be used as initialisation routine, and two output routines will be called, one for the display file, and PLOTPDP or PLOTELL for the plotter output.
Output for the CALCOMP and COMPLOT plotters may be generated directly, PLOTTERGINO and COMPLOTGINO being the appropriate initialisation routines (see Section 2.5). The basic routine for outputting a picture to the plotter is PLOTEND although all the display file output routines are equivalent to PLOTEND if plotter output is being generated.
The size of the plotter paper is only limited in one direction - across the drum. The standard length along the paper per picture is 3000 units. This can be extended by cutting routine PLOTLENGTH. The standard picture orientation is with x across the page. Output with x along the page can be generated by calling routine XALONG before generating the picture. The standard orientation can be restored by calling routine XACROSS.
To aid identification each plotter picture produced by GIN0 is normally preceded by a stream header giving user identifier etc. If this is a nuisance it can be suppressed by calling routine NOSTRHEAD (STRHEAD restores the plotting of stream headers).
The details of these routines are included in the specification of PLOTTERGINO in Section 2.13.
Output is sent to the CALCOMP plotter automatically when PLOTEND is called. Should control fail to reach PLOTEND (e.g. because the plot causes an edge violation) the on-line user can choose to have the output so far plotted {by typing 'CLOSE') or lost (by typing 'DELETE'). Off-line the output will be plotted as far as the edge violation. The procedure for producing output on the COMPLOT on-line plotter can be demonstrated at the Ministry of Technology CAD Centre.
The following routines are relevant to this section:
Name Purpose
DFOUTB To output a relocated, self-running binary display file.
DFOUTC To output a relocated display file in character form.
DFOUTR To output a relocatable display file for use with DFM.
DFPLOT To output a picture in the form of a display file on
the plotter. (See Section 4.2.)
DFPUNB To punch out a display file in binary form for DFTL.
DFPUNC To punch out a display file in character form for DFTL.
DFREAD To read a display file into core in TITAN.
DFTERMIN To terminate a display file in the manner stipulated
by the user.
PLOTPDP To produce a PDP or Elliott display file together with
PLOTELL corresponding plotter output in the same program.
PLOTEND To end a plotter picture when using PLOTTERGINO
or COMPLOTGINO.
PLOTLENGTH To set the paper allocation when plotting.
NOSTRHEAD To suspend or restore the plotting of stream headers.
STRHEAD
SENDPDP To send a display file over the link in expensive mode.
SENDSAT
XALONG To control the orientation of output on the plotter paper.
XACROSS
Full details are in Section 2.13.
Special entry points for SAL and assembly code programmers are provided in many of the routines. Use of these rather than the FORTRAN entry points will make for more efficient code. The GINO routines will not disturb B20 to B64 but may change any other B-line.
Arguments are handed over in B89, B88, B87, etc., and the link is stored in B90. The following conventions apply about optional arguments. The optional last argument in the picture part routines, which specifies the name for light pen purposes, is normally not picked up. A special routine called .NAMING is provided so that if light pen names are required, they can be used. A call to .NAMING causes the routines to pick up the name argument. Every picture part routine then picks up the optional argument, until another call to .NAMING cancels the arrangement.
Routine BUFFERS may be called with only 3 arguments by setting B86 < 0. All other routines that can have an optional number of arguments are only available via the MLS calling sequence. Also routines that have real arguments can only be called using the MLS calling sequence.
For routine entries in which arguments are held in B-lines, the name of the entry points is obtained by prefixing . to the FORTRAN routine name. In SAL such names must be declared as global labels. In ETAL they will be name parameters. For routines using the MLS calling sequence, or which have no arguments, the only entry point is the FORTRAN routine name.
The only exception to this rule is the routine equivalent to CHARS. This is called .SALCHARS (it has to be a different routine owing to the different methods of packing characters in FORTRAN and SAL).
In the following examples parallel FORTRAN and SAL routine calls are given. A full SAL program may be found in Section 2.12.
CALL LINE(10,-20) B89 = 10; B88 = -20; ENTER .LINE
(ENTER .NAMING has not been executed.)
CALL OBJECT(77,I) B89 = 77; B88 = I; ENTER .OBJECT
(ENTER .NAMING has been executed.)
CALL INITGINO ENTER INITGINO or MLS INITGINO
CALL CHARS ('FRED') B89 = PTR ::FRED::; ENTER .SALCHARS
CALL OSHIFT(Sll.,511.) MLS OSHIFT(511.,511.)
| CHARACTERISTIC | PDP (DEC 340 display) | ELLIOTT (928 display) | CALCOMP PLOTTER |
|---|---|---|---|
| Raster size | 1024×1024 (0≤x≤1023) Viewing area is 9.375" by 9.375" | 1024×1024 (0≤x≤1023) Viewing area is 10" by 10" | 1 unit = 0.01 inches, Width = 1060 (small), 2920 (large). Length can be set by program (PLOTLENGTH) |
| Edge violation behaviour | Display stops and interrupts the PDP processor. (DFM deals with this) | Within an area of 4096×4096 the beam is blanked if it falls outside the viewing area. | Program monitors. Output may be deleted or plotted as far as the edge violation. |
| Available intensities | 0-7. Six of these (2-7) are used for intensity modulation. | 0-2. Two more are simulated for intensity modulation. | No variation of intensity. (Colour of ink may be changed sparingly.) |
| Characters | 4 sizes provided by hardware:- 6×7, 12×14, 24×28, 48×56 | 2 sizes provided by hardware:- 8×10, 16×20 | 4 sizes provided by software:- 6×7, 12×14, 24×28, 48×56 |
| GINO initialisation | CALL PDPGINO | CALL ELLIOTTGINO | CALL PLOTTERGINO |
| Buffer space requirement | Display file buffer must be provided; object/subpicture only if required. | No display file buffer. Object buffer only if required. | |
| Picture starting routine | BUFFERS | BUFFERS | BUFFERS |
| Picture ending routine | DFOUTB, DFOUTR, DFPUNB, SENDSAT | PLOTEND (DFOUTR, etc. have same effect.) | |
| Subpictures | Provided | Provided | Treated as objects, automatically. |
| Availability (June 1970) | CUML, MINTECH | CUEL, MINTECH | CUML, MINTECH |
Notes:
Visible picture parts are numbered in the order in which they are added.
C FORTRAN PROGRAM TO PRODUCE DISPLAY FILES FOR
C PICTURES OF BOOKENDS. OUTPUT IS TO BE FILED ON
C THE DISC SO THAT PICTURES CAN BE DISPLAYED LATER.
C OUTPUT IS TO STREAM 6 WHICH SHOUID BE SET UP TO FILE.
COMMON DBUFF(300),OBUFF(300)
C INITIALISE GINO SYSTEM. OUTPUT IS TO BE PDP DISPLAY FILE.
CALL PDFGIN0
C SET UP DISPLAY FILE BUFFER AND OBJECT/SUBPICTURE BUFFER. IF EITHER
C BUFFER OVERFLOWS CONTROL IS TO PASS TO LABEL 10 AT END OF PROGRAM.
ASSIGN 10 TO L
CALL BUFFERS(DBUFF,300,L,OBUFF,300,L)
C WE DEFINE A BOOKEND AS USER-DEFINED OBJECT 1. THIS IS LOCATED
C AT ORIGIN OF SPACE COORDINATES AND IS PICTURED IN FIG 2H OPPOSITE.
CALL DEFOBJ(1)
C MOVE TO STARTING POINT IN FIG OPPOSITE. WE FOLLOW ARROWS.
CALL IPOINT3(-150,0,0)
CALL LINEP3(-150,500,0)
C ARGS 1,2,3 SPECIFY CIRCLE CENTRE. ARGS 4,5,6 SPECIFY END
C POINT OF ARC. IN GENERAL ANY POINT ON END RADIUS VECTOR SUFFICES.
C ARGS 7, 8, 9 SPECIFY DIRECTION OF INITIAL TANGENT VECTOR.
CALL CIRCLE3(0,500,0,150,500,0,0,100,0)
CALL LINEP3(150,0,0)
C NEXT LINE RETURNS TO STARTING POINT.
CALL LINEP3(-150,0,0)
C WE CAN SPECIFY LINES AS INCREMENTS AS WELL AS BY ENDPOINT.
CALL LINE3 (0,0,200)
CALL LINE3(0,30,0)
CALL LINE3(0,0,-175)
CALL LINE3(0,470,0)
CALL CIRCLE3(0,500,25,150,500,25,0,100,0)
CALL LINE3(0,-470,0)
CALL LINE3(-300,0,0)
CALL ILINE3(300,0,0)
CALL LINE3(0,0,175)
CALL LINE3(-300,0,0)
CALL IPOINT3(150,0,0)
CALL LINE3(0,0,200)
CALL LINE3(0,30,0)
CALL ILINE3(0,-30,0)
CALL LINE3(-300,0,0)
C CLOSE DEFINITION OF BOOKEND.
CALL ENDOBJ
C DEFINE X-Y-Z AXES AS USER-DEFINED OBJECT 2.
CALL DEFOJBJ(2)
CALL IPOINT3(0,0,0)
CALL LINE3( 200,0,0)
CALL CHARS(' X')
CALL IFOINT3(0,0,0)
CALL LINE3(0,800,0)
CALL CHARS(' Y')
CALL IPOINT3(0,0,0)
CALL LINE3(0,0,240)
CALL CHARS(' Z')
C CLOSE DEFINITION OF AXES AS YET NOTHING HAS BEEN
C ADDED TO DISPLAY FILE BUFFER ('PICTURE').
CALL ENDOBJ
C SET TRANSFORM MODE.
CALL SETTRANSFORM
C SET UP ISOMETRIC PROJECTION
CALL ISOMETRIC
C POSITION ON THE SCREEN.
CALL OSHIFT(511.,300.)
C FIRST PICTURE IS TOBE ISOMETRIC PROJECTION OF BOOKEND
C DRAWN WITH SPACE COORDINATE AXES.
CALL OBJECT (1)
CALL OBJECT (2)
C OUTPUT FIRST PICTURE ON STREAM 6 TO FILE,IN RELOCATABLE FORM.
C THIS PICTURE, PLUS ANNOTATION,IS SHOWN IN FIG 2H OPPOSITE.
CALL DFOUTR
C NEXT PICTURE,SO CLEAR OUT DISPLAY FILE BUFFER. SINCE PDPGINO
C IS Nor CALLED AGAIN OBJECT DEFINITIONS WILL STIll BE AVAIIABLE.
CALL BUFFERS
C THE AXES ARE NO LONGER REQUIRED. WE DEFINE A NEW OBJECT 2
C CONSISTING OF TWO BOOKENDS, REDUCED TO 7/10 SIZE AND
C PosITIONED AS ON A SHELF.
C DEFOBJ IS CALLED WITH 2 ARGS AS THE COMPONENT PARTS OF OBJECT
C 2 ARE TO BE TRANSFORM!ID AND WIDOWED.
CALL DEFOBJ(2,1)
C RESET TR MATRIX TO UNITY.
CALL SETTRANSFORM
C SET WINDOW BOUNDS EXPLICITLY. AT THIS STAGE WE REQUIRE NO
C CLIPPING. SET3DWINDOW IE NECCESSARY AS IT IS USED LATER.
CALL SET3DWINDOW(-10000,10000,-10000,10000,-10000,10000)
C ONE BOOKEND IS ID BE AS DEFINED BUT REDUCED TO 7/10 SIZE AND
C POSITIONED AT X-0,Y=0,Z=300.
CALL MAGNIFY(0.7,0.7,0.7)
CALL OSHIFT(0.,0.,300.)
C ADD FIRST BOOKEND TO DEFINITION OF OBJECT 2.
CALL OBJECT(1)
C RESET TR MATRIX.
CALL SETTRANSFORM
C SEC0ND BOOKEND IS TO BE SIMILARLY SCALED AND VIEWED,
C BUT AT 'OTHER END' , AT X=0 Y=0,Z=-300.
C NEGATIVE SCALE FACTOR CAUSES REFLECTION.
CALL MAGNIFY(0.7,0.7,-0.7)
CALL OSHIFT(0.,0.,-300.)
C ADD SECOND BOOKEND.
CALL OBJECT(1)
C CLOSE DEFINITION OF OBJECT 2.
CALL ENDOBJ
C WE NOW GENERATE SECOND PICTURE - A PERSPECTIVE VIEW OF THE BOOKENDS
C WITH VIEWPOINT AT X=-1200, Y=1000, Z=2000 AND INTENSITY MODULATION.
CALL SETTRANSFORM
C SET UP PERSPECTIVE VIEW.
CALL FROMXYZ(1200.,1000.,2000.)
C POSITION ON SCREEN.
CALL OSHIFT(511.,300.)
C SET 3D-WINDOW BOUNDS.
CALL SET3DWIND0W(200,800,0,1023,-450,450)
C CALL OBJECT 2 TO GENERATE PICTURE.
CALL OBJECT(2)
C OUTPUT SECOND PICTURE - SEE FIG 2J.
CALL DFOUTR
C THIS IS OVERFLOW EXIT.
10 STOP
END
C DETAILS OF H0W TO DISPLAY THE PICTURES ON THE PDP ARE IN
C SECTION 6.3. FIGS 2H AND 2J WERE PRODUCED ON THE PLOTTER SIMPLY BY
C SUBSTITUTING PLOTTERGIN0 FOR PDPGINO AT LINE 8.
Note: Part of left-hand bookend is outside the visible window.
|SAL PROGRAM TO DISPLAY THE PRIMITIVE TWISTED CUBIC.
|NOTE THAT B-LINE ARGUMENT ENTRIES COMMENCE WITH '.'
|ROUTINES NEEDING REAL ARGUMENTS MUST USE THE MLS
|CONSTRUCTION. ENTER USES B90 AS LINK.
GLOBAL LABEL GO INITGINO,.BUFFERS,.CONTROL,.IPOINT,.LINEP,→
.SALCHARS,.SET3DWINDOW,.IPOINT3,.LINEP3,.ILINEP,SETTRANSFORM
INTEGER DBUF(200)
BLINE 20 T |BLINES 20-64 ARE UNTOUCHED BY GINO.
|ENTRY POINT. INITIALISE GINO AND DF BUFFER.
GO, ENTER INITGINO
B89=PTR DBUF(0) ;B88=200;B87=DERR;B86=-1;ENTER .BUFFERS
|NOW SET SCALE 1, INTENSITY 3 FOR AXES.
B89=-0;B88=1;B87=3;ENTER .CONTROL
B89=-0;B88=0;ENTER .IPOINT
B89=1023;B88=0;ENTER .LINEP
B89-511;B88=0;ENTER .ILINEP
B89=5ll;B88=1023;ENTER .LINEEP
|SCALE UNCHANGED,INTENSITY 7 FOR TITLE.
B89=0;B88=-1;B87-7;ENTER .CONTROL
B89=350;B88=900;ENTER .IPOINT
B89=PTR::THE PRIMITIVE TWISTED CUBIC.::
ENTER .SALCHARS
|RESTORE SCALE 0
B89=0;B88=0;B87=-1;ENTER .CONTROL
|SET UP WINDOW AND TRANSFORMATION FOR TIWISTED CUBIC.
B89=0;B88=1023;B87=0;B86=1023;B85=-600;B84=600
ENTER .SET3DWINDOW
MLS SETTRANSFORM |COULD HAVE ARG SO MUST BE MLS
|MAGNIFY, SO THAT CUBIC FILLS SCREEN.
MLS MAGNIFY(0.5,10.0,50.0)
MLS OSHIFT(511.) |SHIFT TO THE DISPLAYED AXES.
|THE CUBIC IS (T*T*T,T*T,T) FOR T IN [-10,10)
B89=-1000;B88=100;B87=-10;ENTER .IPOINT3
FOR T=-9 STEP 1 UNTIL 10 DO
B87=T;B88-T*B87;B89=T*B88
ENTER .LINEP3
REPEAT
DERR, MLJ3 DFPUNB
|BINARY PAPER TAPE OUTPUT,FDR USE WITH DFTL.
|COULD HAVE ARGUMENT,so MUST BE MLS.
STOP
|SEE A.R.FORREST'S THESIS FOR DERIVATION OF GENERAL TWISTED
|CUBIC FROM THIS PRIMITIVE FORM.
FINISH
Routine specifications are given in terms of FORTRAN. The type of each routine argument is indicated by the first letter of the argument name, following the standard FORTRAN convention (I - N indicates integers, others indicate reals). Where optional arguments are allowed, several examples of the routine call are usually given or the optional arguments are indicated by ?.
Each routine specification is on a separate sheet, so that it may be rapidly updated. The practice of giving routine lengths has been discontinued since the lengths usually depend on which device (e.g. PDP, Elliott, plotter) is being used. Those lengths which remain should be regarded as very loose upper bounds. As an approximate guide, enough GINO to do points, lines and characters and to output pictures will take about 1.5 K of core. User-defined objects and the full range of transformation facilities use about 1/2 K each and 3D-windowing with intensity modulation takes about 1K. A full selection of facilities will not take more than 4K (excluding buffer space).
All routines needed by other routines are loaded automatically. Each routine specification contains details of any error messages that may be provoked. In the case of serious faults the GINO system stops the user's job by forcing a fault 49. For FORTRAN jobs this causes line number information to be given, which, together with the GINO error message, should pinpoint the mistake. For SAL and assembly code jobs, the fault causes an entry to System Monitor. The user may, of course, trap fault 49 or set up his own post mortem routine.
The routines for handling transformations are grouped together and given after the general picture routines.
This section contains specifications of the following routines:
ASSOCIATE BCDCHARS BUFFERS CHARINT, CHARFPT, CHARREAL CHARS CHARTYPE CIRCLE CIRCLE3 COMPLOTGINO CONTROL CREATEDISPLAY DEFOBJ DEFSUB DELETEOBJ DEPTHOFF, DEPTHON DFCONTIN DFOUTB DFOUTC DFOUTR DFPUNB DFPUNC DFREAD DFTERMIN ENDOBJ ENDSUB GETOBJ INITGINO, PDPGINO, ELLIOTTGINO LINE, ILINE LINE3, ILINE3 LINEP, ILINEP LINEP3, ILINEP3 OBJECT OBJZDM PICTURE, PICTZCLIP PLOTTERGINO PLOTPDP, PLOTELL POINT, IPOINT POINT3, IPOINT3 .SALCHARS SAVEOBJ SENDSAT, SENDPDP SETWINDOW SET3DWINDOW SUBPIC CABINET, CAVALIER FROMXYZ, AXONXYZ, PROJXYZ ISOMETRIC, DIMETRIC, TRIMETRIC MAGNIFY MODTRANS OFIX, OSHIFT PROJECT ROTATE SELECTVIEW SETTRANSFORM, SAVETRANSFORM SHEAR UNSETTRANS, RESETTRANS
CALL ASSOCIATE(IDN)
DIMENSION CH(4)
...
READ(2,10) CH
10 FORMAT(4A4)
CALL BCDCHARS(CH, 16)
CALL CHARFPT{123.456,16)
produces
.123456E 3
GINO ERROR - CIRCLE NOT DEFINED.is printed on stream O and the job continues.
CALL LINE3(100,200,-100)
CALL CIRCLE3(-,-,-,-,-,-,100,200,-100)
is used to produce continuity, i.e.
GINO ERROR - CIRCLE NOT DEFINED.
is printed on stream 0 and the job continues.
Degeneracy in the tangent vector (i.e. it passes through the centre)
does not produce an error
if the plane of the arc is determined, In this case the minor arc is
drawn.
PLOT O7 ( 'O' for output)
after running a COMPLOTGINO program, to plot output sent to pending
stream 7. Output may also he sent tn a file and
plotted (using 'PLOT <file title>') when convenient. PDP (/DFB) W A2000 D2000
INPUT D2 (PAW/BDF) ...... ...... ***C runout (PAW/BDF) ***FThe binary tape must then follow the JD on the same tape reader. It is set up as input stream 2.
GINO ERROR - OBJECT <n> NOT ON STREAMis printed on stream 0 and the job stops.
GINO ERROR - OBJECT <n> NOT FOUND
is printed and a fault 49 is forced, which the user may trap if he wishes.
CALL XALONG
The standard orientation may be restored
CALL XACROSS
CALL PLOTLENGTH(N)
which sets the limit to N × 1024 units.
It is not of course possible to vary the width
across the paper. This is 1060 units for the
small plotter and 2920 units for the big plotter.GINO ERROR - OBJECT <n> NOT SAVEDis printed on stream 0 and the job continues.
GINO ERROR - SUBPICTURE <n> NOT FOUNDis printed and the job stops.
CALL OFIX(-500.,-500.)
CALL Magnify(2.0,2.0)
.....
CALL POINT(600,600)
produces a point whose picture coordinates are (200,200) whereas
if the order is reversed it
produces a point at (700,700)
CALL SAVETRANSFORM(A)
C Preserve the current transformation.
CALL OBJECT(10)
.........
C Display x - z view (front elevation)
CALL SETTRANSFORM(A)
CALL SELECTVIEW(1,3)
CALL OBJECT (10)
....
C Display y - z view (side elevation)
CALL SETTRANSFORM(A)
CALL SELECTVIEW(2,3)
CALL OBJECT(10)
CALL SAVETRANSFORM(T)
may be restored by
CALL SETTRANSFORM(T)
SAVETRANSFORM does not unset transform mode.
This is achieved by a call to routine
UNSETTRANS.
The first two routines of this section may be used to produce graphs. One routine generates the graph raster and the other generates the graph. More than one graph may be plotted on any one raster and more than one raster may be used at a time. Four different symbols are available for points and five intensities of lines can be selected to distinguish graphs on the same raster. Scaling is done by an internal routine and can be linear or logarithmic on either axis. Graphs are plotted from arrays of their true values to suit the raster on which they appear. Information about the raster is transferred from the raster routine to the graph plotting routine by a 12-element array argument. Scaling numbers appear alongside the axis when sufficient space is available. the graphs can be plotted as individual points or as straight lines joining consecutive points. Points off the raster are not plotted, but lines to such points are taken to the edge of the raster in the correct direction.
The third routine will produce histograms. The histogram is defined to the routine by an array containing the heights of the columns in the correct sequence together with the information about the scales and the size and position of the frame. Columns outside the frame are not plotted but the end columns are taken to the edges of the frame. Provision is made for having scaling numbers alongside the axis or not and for omitting the internal vertical lines of the histogram. A control for brightness is provided (only applicable for display output) to make it possible to have two distinguishable histograms in the same frame; this is done by two calls to the routine with those parameters which affect the scaling unaltered.
These routines use the picture part routines of Section 2, so that graphs may be incorporated in some more complex picture if desired. GINO must be initialised (Section 2.5) usingthe routine appropriate to the display or plotter before calling the graph routines. Note that an object subpicture buffer must be provided so BUFFERS should be called with 6 arguments (when using PDPGINO or ELLIOTTGINO) or 3 arguments (when using PLOTTERGINO or COMPLOTGINO). Also the LIBRARY command must arrange for the graph routine library file to be scanned before the main library file (see Section 7). The graphs are output just like any other GINO picture (see Section 2.9).
This section contains specifications of the following routines:
PLOTGRAPH PLOTPAPER PLOTHIST
0 ≤ WI ≤ 1023; 0 ≤ H ≤ 1023 XO ≥ 0; YO ≥ 0; 0 ≤ XO+ WI ≤1023; 0 ≤ YO+ HI ≤ 1023For plotter output the only check is XO ≥ 0; YO ≥0, so as to permit long graphs. (In this case it is the user's responsibility to avoid edge violations.)
XO ≥ 56 YO ≥ 56 XO+WI ≤ 1016 Yo+HI ≤ 1016This means that the largest raster obtainable on the screen with scaling numbers is 960 × 960.
95 0 5 10 15The true extreme value nearest the bottom left corner is additionally displayed in exponential form to 3 significant figures, e.g., .995E 4 in example above. For logarithmic scaling, only the exponents of the integral powers of ten are displayed along the axes; the extreme value again appears in exponential form.
C EXAMPLE OF USE OF GRAPH ROUTINES.
C LEAST SQUARES FIT TO STRAIGHT LINE IAW,Y-A*X+B.
C DATA IS TO BE READ OFF STREAM 0. CALCLINE IS EXTERNAL ROUTINE.
COMMON SPACE(20),X(100),Y(100),XX(4),YY(4),P(12)
C INITIALISE GINO. CALCOMP PLOTTER OUTPUT IS REQUIRED.
CALL PLOTTERGINO
C SET UP OBJECT BUFFER. NO OVERFLOW IS ANTICIPATED SO USE
C -VE THIRD ARGUMENT.
CALL BUFFERS(SPACE,20,-1)
C N.B. IF PDPGINO OR ELLIOTTGINO ARE USED, BUFFERS MUST HAVE
C 6 ARGS. AS A DISPLAY FILE BUFFER IS NEEDED AS WELL.
C READ DATA, THE X ANDY VALUES OF POINTS.
CALL SELECTIN(0)
N=READREAL(0)
DO I=1,N
X(I)=READREAL(0)
1 Y(I)=READREAL(0)
C CALL SUBROUTINE TO COMPUTE MAX AND MIN VALUES AND THE
C CONSTS A AND B.
CALL CALCLINE(N,X,Y,A,B,XMIN,XMAX,YMIN,YMAX)
C PLOT RASTER, LINEAR/LINEAR, MAXIMUM SIZE.
CALL PLOTPAPER(960.,960.,56.,56.,1,XMIN,XMAX,1,YMIN,YMAX,P)
C TEST FOR ERROR.
IF (P(1)) 5,5,2
C PLOT POINTS AS GIVEN AS SMALL SQUARES.
2 CALL PLOTGRAPH(N,X,Y,-3,P)
C COMPUTE 4 X-VALUES STRADLING EDGES OF RASTER FOR
C STRAIGHT LINE.
Z=(XMAX-XMIN)/50.
XX(1)=XMIN-Z
XX(2)=XMIN+Z
XX(3)=XMAX-Z
XX(4)=XMAX+Z
C COMPUTE CORRESPONDING Y-VALUES.
DO 3 I=1,4
3 YY(I)=A*XX(I)+B
C PLOT STRAIGHT LINE.
C THIS WILL BE CLIPPED TO RASTER EDGES BY THE ROUTINE.
CALL PLOTGRAPH(4,XX,YY,0,P)
C END THIS PLOT. IT WILL GO TO THE PLOTTER AUTOMATICALLY.
5 CALL PLOTEND
C N.B. PLOTEND WOULD BE REPLACED BY DFPUNB, DFOUTR DFOUTR, OR SENDSAT
C WHEN USING PDPGINO OR ELLIOTTGINO.
END
Pictures in the form of PDP display files may be drawn on the CALCOMP plotter attached to TITAN. The display files may be produced by GINO, or punched from the PDP (see the description of DFTP in Section 5.2), or produced in any other way. Corresponding routines for Elliott display files will be produced shortly.
The basic routine used for plotting a display file is DFPLOT (DFPLOTNS can also be used for the same purpose, and has a simplified argument format). At the time of plotting the picture contained in the display file may be clipped to a rectangular region, scaled and than positioned on the plotter paper. The user can also control the plotter output stream so as to plot a number of display files as one composite picture, or separately, or in any other grouping.
Routine PLOTLIMITS is used to set up limits on X and Y in display coordinates. Parts of the display file outside these limits are omitted; clipping being exact. The picture inside these clipping limits may be scaled (routine PLOTSCALES is used to specify X and Y scaling factors) and positioned on the plotter paper (routine PLOTSHIFT being used to specify transverse and longitudinal shifts). The scaled and positioned picture is clipped (if necessary) so as to fit the plotter paper. Routine PLOTSTREAM may be used to control the plotter stream.
All these routines are optional and the parameters they set have default settings such that if none of them are called, DFPLOT copies the picture from the screen to the plotter (there is a slight change in size owing to the differing basic increments on the two devices).
Display files produced by the other GINO routines may be plotted directly, without an intermediate output stage to paper tape or file, by using routines PLOTPDP or PLOTELL (see Section 2.13).
This section contains specifications of the following routines:
DFPLOT DFPLOTNS PLOTLIMITS PLOTSCALES PLOTSHIFT PLOTSTREAM
Routines DFREAD, PLOTPDP and PLOTELL of Section 2.13 are also relevant to this section.
Let IFRAME = N1 + N2 + N3N1 = 0 or 1. If N1 = 1, then draw a frame around the picture; otherwise omit. This is the frame option. The frame corresponds to the current values of XLIM1, XLIM2, YLIM1, YLIM2 (see PLOTLIMITS).
DISPLAY FILE n PDP WORDS AT m PLOTTED.- where m is the value of ISTART - is sent to stream 0.
DFPLOT ERROR - DISPLAY ENTRY BEFORE DISPLAY FILE START. DFPLOT ERROR - OP CODE ZERO IN SUBROUTINE MODE. DFPLOT ERROR - SLAVE MODE.
C PROGRAM TO PLOT A DISPLAY FILE PUNCHED OUT FROM THE PDP USING DPTF.
C THR PAPER TAPE HAS BEEN SET UP AS STREAM 6 IN THE WAY DESCRIBED IN
C THR SPEC OF DFREAD. THR PICTURE IS TO BE UNCHANGED.
COMMON DFARRAY( 1000)
C READ IN DISPLAY FILE FROM STREAM 6.
CALL DFREAD(DFARRAY, 6)
C OUTPUT ON PLOTTER, WITH FRAME, NEW PICTURE AND Y AXIS ALONG PAPER.
C OUTPUT STREAM 7 Will BE CREATED TO PLOTTER.
CALL DFPLOTNS(0,0,DFARRAY,1)
END
C PROGRAM TO OUTPUT 4 FULL SCREEN SIZE DISPLAY FILES AS ONE COMPOSITE
C PLOTTER PICTURE. THE DISPLAY PICTURES ARE TO BE REDUCED TO HALF SIZE.
C THE DISPLAY FILES ARE HELD IN DISC FILES AND INPUT STREAMS 6, 7, 8
C AND 9 ARE SET UP FROM THESE FILES.
COMMON DFARRAY(1000)
C READ IN FIRST DISPLAY FILE.
CALL DFREAD(DFARRAY, 6)
C SET SCALING FACTORS FOR HALF SIZE REDUCTION.
CALL PLOTSCALES(0.5,0.5)
C POSITION FIRST PICTURE ID LOWER LEFT HAND QUADRANT.
CALL PLOTSHIFT(-256,0)
C SEND FIRST PICTURE TO PLOTTER. ADVANCE PAPER AND OMIT FRAME.
CALL DFPLOTNS(0,0,DFARRAY,0)
C READ IN NEXT DF.
CALL DFREAD(DFARRAY,7)
C POSITION TO LOWER RIGHT HAND QUADRANT.
CALL PLOTSHIFT(256,0)
C SEND SECOND PICTURE TO PLOTTER. PAPER NOT TO BE ADVANCED.
CALL DFPLOTNS(O,O,DFARRAY,2)
C REMAINING PICTURES ARE TO OCCUPY UPPER QUADRANTS.
CALL DFREAD(DFARRAY, 8)
CALL PLOTSHIFT(-256,512)
CALL DFPLOTNS(0,0,DFARRAY,2)
CALL DFREAD(DFARRAY, 9)
CALL PLOTSHIFT(256,512)
CALL DFPLOTNS(0,0,DFARRAY,2)
END
Programs in TITAN may use the PDP7 as a satellite computer and programs in ATLAS may use the PDP9 or the Elliott 905. In any case the TITAN or ATLAS program is independent of which particular satellite is used (e.g. WRITEPDP may be used to write to the PDP or Elliott and SELECTPDP is used to select a link to either machine). So far the only use made of the link has been in Section 2.9 where its use for sending a display file to the satellite was described. This section deals with the use of the link in a more general way, including interaction between the central computer and the satellite.
The full facilities of the link are described in "The ATLAS-PDP Link (3rd Edition)" (2). Extracodes are provided to attach one (or more) satellites to a TITAN program, which may then initiate data transfers to and from the satellite at any time. An attention" mechanism is provided so that the satellite can also initiate data transfers by signalling a request for attention. When the satellite issues an attention, the user's TITAN program is interrupted so that it may read and process the attention data. Attentions may be queued in the satellite and dealt with in TITAN in the order in which they were made. When the TITAN program is not actively computing it can be put into a state of waiting for attentions, which imposes a minimum burden on the supervisor.
These facilities are only available when logged into the multiaccess system in expensive mode. At the TITAN end the routines of this section provide the facilities of the link extracodes for the FORTRAN programmer. Routine SELECTPDP is used to select the link before it is used. READPDP and WRITEPDP are used to effect data transfers from the satellite to TITAN and vice versa. EXPAND and SQUASH are used with READPDP and WRITEPDP for conversion between satellite and TITAN integer formats. INASC and OUTASC may be used to convert between TITAN internal code and ASCII (the PDP character code) and vice versa.
ATTNSET and ATTNREAD are the basic routines for handling attentions. ATTNSET must be called before any attentions occur, in order to set up the attention machinery. It may also be used to control what happens when a link fault occurs. ATTNREAD is used to read an attention and to translate it into FORTRAN integer format. It provides sufficient facilities for the user who is content to process attentions one by one and who can predict the maximum attention word count. If he cannot do the latter he can use ATTNWAIT to find out the length of the attention before reading it, and use some kind of free storage system. ATTNLOOK allows the user to find out at any time whether or not there is an attention waiting. This allows him for instance to decide whether or not to abandon the attention he is currently processing, if a new attention invalidates the old.
ATTNSET in fact sets up a delayed fault trap routine for fault 60. Control is never returned to the user in delayed trap status.
The facilities for initiating attentions in the satellite are provided by the EXEC B program described in reference (2). This program, the Display File Manager (to be described in Section 6.3) and the facility for naming picture parts (described in Section 2.8) provides the basic tools for interactive graphics using the PDP or Elliott as a satellite of TITAN or ATLAS.
The routines may be used from ASA FORTRAN (not T3) as described in the specifications. They may also be used from SAL using the MLS construction.
The routines specified in this section are:
ATTNSET ATTNWAIT, ATTNLOOK, ATTNREAD EXPAND, SQUASH INASC, OUTASC, PDPCR, PDPCW READPDP, WRITEPDP SELECTPDP, SELECTSAT
Routine SENDSAT (for specification see Section 2.13) is also relevant to this section. It is used to send display files produced by GINO to the satellite over the link when operating in expensive mode.
GINO ERROR CLOCK FAULT GINO ERROR CHECKSUM FAULTThis satellite is dead or the link is malfunctioning. The job stops. This only happens if LCLOCK, LCKSUM are not given.
CALL READPDP(IWS,27,400,0)
CALL EXPAND(IWS,IA,27)
and to transfer 100 integers held in J(100) to J(199) to PDP
locations 1000 to 1099:
CALL SQUASH(IWS,J(100),100)
CALL WRITEPDP(IWS,100,1000,0)
Note that the top 3 bits are lost in writing to the PDP.
In reading from the PDP, the routine ensures that negative numbers
are preserved.
0, 8-bit character, 0, 8-bit characterIn addition to code conversion PDPCW and PDPCR actually perform write and read transfers, using the address (20008) and data word (zero) required by TERMINAL.
SIGNAL LINK PDPon the multiaccess console allocated to the PDP and wait for "READY". The link may then be selected and used. It will have to be recreated if a restart occurs.
SIGNAL LINK SATELLITE <N>where <N> is the octal number set on the handkeys (which acts as a kind of password) and wait for "READY".
C THE PROGRAM IS TO GENERATE A PICTURE FROM SOME DATA AND
C DISPLAY IT IN THE SATELLITE. THE SATELLITE MAY ISSUE
C ATTENTIONS REQUESTING CHANGES IN THE DATA AND HENCE IN THE
C PICTURE. AN ATTENTION WILL HAVE 1 IN THE FIRST WORD FOR
C CHANGE OF DATA AND 2 FOR QUIT.
COMMON DFBUFF(200),IATTN(20)
CALL ELLIOTTGINO
C SELECT THE LINK
CALL SELECTSAT
NSEG=0
C SET UP THE ATTENTION HANDLING MECHANISM. IF A LINK
C FAULT OCCURS A MESSAGE IS PRINTED ON STREAM 0 AND
C THE PROGRAM MUST BE RESTARTED IN THE SATELLITE AND THEN
C IN THE CENTRAL COMPUTER BY TYPING A CARRIAGE RETURN.
ASSIGN 10 TO LERR
CALL ATTNSET(LERR, LERR)
3 CALL BUFFEFS (DFBUFF,200 -1)
NSEG=NSEG+1
C GENERATE NEW PICTURE
. . . .
CALL SENDSAT(NSEG)
C READ NEXT ATTENTION, HALTING UNTIL THERE IS ONE.
C AN ATTENTION HAS OCCURRED.
N-=IATTN(2)
L=IATTN(3)
GOTO (1,2)L
C 1 PROCESS ATTENTION DATA IN IATTN(4) TO IATTN(N+2),
C CHANGING PROGRAM DATA. GENERATE NEW PICTURE
GOTO 3
2 STOP
C AVOID THIS WRITE STATEMENT IF CORE SPACE IS A CONSIDERATION,
C USING PRINTCHAR OR A SMALL M/C ROUTINE INSTEAD.
10 WRITE (0,99)
99 FORMAT( 'LINK FAULT - RESTART SATELLITE AND
1TYPE CARRIAGE RETURN ON THIS CONSOLE')
C STREAM 0 MUST BE ATTACHED TO CONSOLE FOR THIS.
ASSIGN 3 TO LCH
CALL SELECTIN(0)
12 CALL SYMREAD(LCH)
C CONTROL PASSES TO LABEL HELD IN LCH WHEN NEWLINE IS RFAD. THIS
C RESULTS IN ATTEMPT TO SEND A NEW PICTURE.
GOTO 12
END
Several programs are available for both the PDP and Elliott computers. The first group (DFTP and DFTL) may be used without the link to TITAN/ATLAS. The second group (DFM, the Interactive Handler and Terminal) use the PDP/ELLIOTT as a satellite. Full specifications of DFM, the Interactive Handler and Terminal are published separately as they are to a greater or lesser extent dependent on which machine is used as satellite. The purpose of Section 6.3 is to provide a summary of the facilities available and an indication of how to use a basic subset of them.
The Display File Tape Producer (DFTP) extracts a display file from the PDP and punches it on paper tape in relocatable form. DFTP which is itself relocatable, may be loaded anywhere in core and needs only the first address of the user's display file. An Elliott version will be produced when required.
The Display File Tape Loader (DFTL) loads into the PDP relocatable display file tapes produced by DFTP or GINO, at any desired location. DFTL can also start the display from any address. A version of DFTL for the Elliott is available.
The Display File Manager (DFM) is a program used to manage the display, particularly when the PDP/Elliott is being used as a satellite. It can be used in a standard preassembled form (as described in Section 6.3) or as a module that can be incorporated in user's satellite programs. Versions of DFM are available for both computers.
The Interactive Handler and Terminal are two prepackaged programs designed to make interactive graphics facilities easily available, without any necessity to write code for the satellite computer. The Handler provides interaction using the light pen, the button keyboard, the satellite teletype and the joystick (PDP only). Terminal provides text editing facilities which can be used for the preparation, modification and monitoring of program data. Versions of the Handler are available for both computers. A version of Terminal for the PDP is available and an Elliott version is being prepared.
The Display File Manager (DFM) offers a convenient way of displaying pictures produced by the GINO routines. Pictures are handled as display file segments, each of which can be switched on or off, or replaced or preserved on backing store. Segments are identified by their segment number. Any number of display file segments can be used (up to a limit preset by the user) and the segments may be generated in the satellite or in the central computer, using GINO. In the later case, core allocation in the satellite is performed automatically by DFM within a region of core set aside by the user for display files. DFM also deals with all display interrupts and with named picture parts.
Those wishing to use the full range of facilities of DFM should consult the detailed specifications of the PDP version (14) and the Elliott version (15). Use of the standard preassembled versions, which provide a subset of facilities suitable for picture viewing but not for fully interactive work, is described below.
PDP(CAD/DFM) W AO DO22 (O22 is 'O' for 'Octal')
SIGNAL LINK SATELLITE <N> (N is the octal number set on the hand.keys)
PDP(CAD/DFM/905) W AO DO22 (O22 is 'O' for 'Octal')
Display file segments produced by DFOUTR may be transmitted using PDP commands with address ≤ 256. The address is taken as the segment number. Address zero is taken as meaning allocate the lowest unused segment number to this segment. Several segments may be sent in one PDP command. In this case all but the first are treated as having zero address. In expensive mode segments may also be transmitted using SENDSAT.
Thus if file (USER/DF) contains a display file segment
PDP(USER/DF) W A6
transmits it as segment 6, overwriting any existing segment 6.
PDP(USER/DF) W AO
would transmit it as a new segment, the number being allocated by DFM.
The standard version allows up to 16 segments. Numbers 1 - 9 can be switched (on if off and off if on) by typing the corresponding digit on the satellite teletype. Segments can also be switched using the data word (+N switches segment N on, -N switches it off, N=256 switches all segments). This is most likely to be useful in expensive mode (using WRITEPDP to transmit zero words of data with the required data word) but it can also be used with the PDP command, e.g.
PDP W NO DO777771
may be used to switch off segment 7 (O777771 = -7 in octal).
Any segment originally sent to the satellite over the link can be read back, e.g. to read segment 7 to file (USER/SEG7)
PDP(01 USER/SEG7) R A7 P1
is used. One circumstance in which this facility is useful is when a plotter copy of the display file segment is required (see Section 4).
The following error conditions may arise when using either the standard versions of DFM described above or any program (e.g. the Interactive Handler or Terminal) that uses DFM. The error is indicated by a message on the screen. Error messages are:-
DFM may also halt if an attempt is made to switch a segment whose number is too large.
In all cases the satellite program must be restarted. Two kinds of restart are available - a complete restart and a partial restart in which existing segments are preserved. In the standard versions for picture viewing described above 228 in the complete restart address and 238 in the partial restart address. In some circumstances a partial restart may not be possible, so that a complete restart cannot be avoided.
The Interactive Handler is designed to make the facilities of the PDP/Elliott, as an interactive graphics terminal, easily available from FORTRAN programs running in the central computer. The user of the Handler need write no satellite code at all.
Facilities provided include graphical input using the light pen (tracking cross, sketching, character input), means of selecting named picture parts and reporting the names to the central computer (as already described), the provision of light buttons and the handling of the button keyboard and the joystick (PDP only) as a means of interacting with the program. Versions are provided for both computers and a full user's guide is available (16).
The version of TERMINAL provided for the PDP is designed to enable the PDP to be used as a graphical on-line terminal for TITAN/ATLAS. It can be used without writing any PDP code.
It consists of a standard DFM plus a scope text editor program. The facilities of DFM have already been described. The text editor allows the display of text and provides deletion and insertion facilities using the lightpen or the teletype. When using the editor, part of the text buffer is displayed on the screen. The part of the text buffer chosen for display can be varied at will. More sophisticated editing facilities are also provided. The full specification of TERMINAL is to be found in Ref. (17).
TERMINAL may be used in normal mode or in expensive mode to prepare, modify and monitor program data. For a discussion of this method of interaction see Ref. (18).
The routines are kept in precompiled form on disc files as detailed below. Programs will usually be run under the COMMAND program although they can also be run under MLS. The GINO routines are obtained by scanning the appropriate library files using the .LIBRARY command.
The main GINO library file on both TITAN and ATLAS is called CAD/GINOSAL/*. This contains all routines except the graph routines of Section 3, which are held in a disc called CAD/GINO/GRAPH and the routines for plotting display files, described in Section 4, which are held in file CAD/GINO/PLOTTER.
For the benefit of those new to the COMMAND program and the on-line system we give a few basic details of how to run a program which uses GINO. Those needing more information should consult The TITAN ASA FORTRAN System Manual (1) and The Cambridge Multiple-Access System - User's Reference Manual (11) and Command Specifications (10).
A typical FORTRAN job is run in three stages: compilation, loading of library routines and execution. Suppose the file (USER/GINO/PROG) contains an ASA program which uses GINO routines from Section 2 only. Then the following commands are required:
.ASA USER/GINO/PROG .LIBRARY CAD/GINOSAL/* .ENTER
This may fail for large programs, when the standard space allocations are not enough (see Section 11 of Volume I of Ref. (1) for details). The allocations may be increased by using various options with the .ENTER command. One common source of trouble is insufficient space for forward references. This can be avoided by adding FR 1024 after the .ENTER command. The program may also require more than the standard allocation of core space. More core may be requested by, say, STORE 12K with the .ENTER command. Thus for a large program we might need
.ENTER FR1024 STORE 16K
An environment declaration may also be used with the .ENTER command to set up input or output streams for the program. This must be enclosed in round brackets and must follow the .ENTER, preceding any of the options. It is made up of directives such as O n <file title> used to set up output stream n to a file.
If the graph routines are used the appropriate library file must be scanned before the main library file, i.e. the command must be
.LIBRARY CAD/GINO/GRAPH CAD/GINOSAL/*
An incorrect .LIBRARY command causes a loader printout with unset parameters (e.g., LINE --- unset).
The most appropriate way to run a job on-line is to use the COMMAND command, which takes a list of commands and obeys them. The commands may be taken from a file or from the on-line input stream. This may be set up in the environment declaration of the COMMAND command. It is introduced by the letter H followed by a single terminating character. All that follows until the terminating character is found on a line of its own is taken as the on-line input stream, i.e. the list of commands to be obeyed. Thus to compile and run a GINO program held on file USER/GINO/PROG and sending display file output via stream 6 to file USER/GINO/DF, we type
COMMAND(H* .ASA USER/GINO/PROG .LIBRARY CAD/GINOSAL/* .ENTER(06 USER/GINO/DF) * )
The final ) closes the environment of the COMMAND command and must be followed by a carriage return. The command must, of course, only be typed when in command status (i.e. when the system is READY).
The system responds immediately by echoing the first command (i.e. .ASA USER/GINO/PROG) and then, when it has finished the job it echoes the remaining commands and types any messages produced by the program. In this instance this will be
DFOUTR - n DISPLAY WORDS
followed by
READY
The user is then in a position to display his picture on the PDP or Elliott, following the instructions of Section 6.3.
If PLOTTERGINO is being used there is no need to set up output stream 6 with the .ENTER command. The message will be
PLOTTERGINO - END OF PLOT
and the plotted output will duly appear in the output area.
(1) Titan ASA FORTRAN System Manual (2 Volumes). UML, Cambridge. April 1969. Section IV of Volume 1 contains the current specification of MLS.
(2) The ATLAS-PDP Link (3rd Edition) by C.A. Lang and P. Cross. UML, Cambridge. June 1969.
(3) GINO Graphical Input/Output (1st Edition) by C.A. Lang, P.J. Payne, J.C. Gray, A.P. Armit and A.R. Forrest. University of Cambridge CAD Group. April 1968.
(4) SAL User's Manual (1st Edition) by H. Brown. UML, Cambridge. June 1968. For a description of SAL see SAL: Systems Assembly Language by C.A. Lang. SJCC 1969.
(5) New B-Core System for Programming the ESL Display Console by C.A. Lang. ESL Memo 9442-M-122. M.I.T., Cambridge, Mass. April 1965.
(6) Display Interface System, User's Manual by A. Mozley. TM67/l, UML, Cambridge, 1967.
(7) Fortran Package for Generating a PDP-7 Display File by J.W. Brackett, A.C. Kilgour and J.V. Oldfield. CAD Project, University of Edinburgh. November 1967.
(8) The Adage Graphics Terminal by T.G. Hagen, R.J. Nixon and L.G. Schaeffer. FJCC 1968.
(9) Coordinates, Transformations and Visualisation Techniques by A.R. Forrest. University of Cambridge CAD Group Doc. No. 23 (June 1969).
(10) Cambridge Multiple-Access System, Command Specifications. Ed. D.F. Hartley. UML, Cambridge. July 1969.
(11) Cambridge Multiple-Access System, User's Reference Manual. Ed. D.F. Hartley. UML, Cambridge, November 1968.
(12) 340 Display Programming Manual by Sanford C. Adler. DECUS No. 7-13, Maynard, Mass.
(13) GINO - Design and Implementation Features by P.A. Woodsford. University of Cambridge CAD Group Doc. No. 27 (October 1969).
(14) Specification of Display File Manager (PDP version) by P.A. Woodsford, University of Cambridge CAD Group. Doc. 43 (to appear).
(15) Specification of Display File Manager (Elliott version) by C. Litherland. Ministry of Technology CAD Centre, Cambridge. (to appear).
(16) The Interactive Handler (PDP and Elliott versions) by M. Newell. Ministry of Technology CAD Centre, Cambridge (to appear).
(17) Specification of Terminal - Mark 2 by R.P. Parkins. University of Cambridge CAD Group. Doc. 29 - Revised. (Nov. 1969)
(18) How to Use Interactive Computer Graphics in Engineering Analysis Programs by R.J. Pankhurst. University of Cambridge CAD Group. Doc. 32 (Nov. 1969)
(19) 928 Graphical Display by J.A. Monro. Elliott Brothers (London) Limited (Nov. 1967)
(20) GINO Graphical Input/Output (Second Edition) University of Cambridge CAD Group (June 1969)
This index indicates where to find the routine specifications. The comment (with X) means that the routine is grouped with routine X. Thus to find the specification of DIMETRIC look in Section 2.13a for ISOMETRIC.
SAVETRANSFORM (with SETTRANSFORM) Name Section ASSOCIATE 2.13 ATTNSET 5.2 ATTNWAIT 5.2 ATTNLOOK (with ATTNWAIT) 5.2 ATTNREAD (with ATTNWAIT) 5.2 AXONXYZ (with FROMXYZ) 2.13a BCDCHARS 2.13 BUFFERS 2.13 CABINET 2.13a CAVALIER (with CABINET) 2.13a CHARFPT (with CHARINT) 2.13 CHARINT 2.13 CHARREAL (with CHARINT) 2.13 CHARS 2.13 CHARTYPE 2.13 CIRCLE 2.13 CIRCLE3 2.13 COMPLOTGINO 2.13 CONTROL 2.13 CREATEDISPLAY 2.13 DEFOBJ 2.13 DEFSUB 2.13 DELETEOBJ 2.13 DEPTHOFF 2.13 DEPTHON 2.13 DFCONTIN 2.13 DFOUTB 2.13 DFOUTC 2.13 DFOUTR 2.13 DFPLOT 4.2 DFPLOTNS 4.2 DFPUNB 2.13 DFPUNC 2.13 DFREAD 2.13 DFTERMIN 2.13 DIMETRIC (with ISOMETRIC) 2.13a ELLIOTGINO 2.13 ENDOBJ 2.13 ENDSUB 2.13 EXPAND 5.2 FROMXYZ 2.13a GETOBJ 2.13 ILINE (with LINE) 2.13 ILINE3 (with LINE3) 2.13 ILINEP (with LINEP) 2.13 ILINEP3 (with ILINEP3) 2.13 INASC 5.3 INITGINO 2.13 IPOINT (with POINT) 2.13 IPOINT3 (with POINT3) 2.13 ISOMETRIC 2.13a LINE 2.13 LINE3 2.13 LINEP 2.13 LTNEP3 2.13 MAGNIFY 2.13a MODTRANS 2.13a NOSTRHEAD (with PLOTTERGINO) 2.13 OBJECT 2.13 OBJZDM 2.13 OFIX 2.13a OSHIFT (with OFIX) 2.13a OUTASC (with INASC) 5.2 PDPCR (with INASC) 5.2 PDPCW (with INASC) 5.2 PDPGINO ( with INITGINO) 2.13 PICTURE 2.13 PICTZCLIP 2.13 PLOTELL 2.13 PLOTEND 2.13 PLOTGRAPH 3.2 PLOTHIST 3.2 PLOTLIMITS 4.2 PLOTPAPER 3.2 PLOTPDP 2.13 PLOTSCALES 4.2 PLOTSHIFT 4.2 PLOTSTREAM 4.2 PLOTTERGINO 2.13 POINT 2.13 POINT3 2.13 PROJECT 2.13a PROJXYZ ( with FROMXYZ) 2.13a READPDP 5.2 RESETTRANS (with UNSETTRANS) 2.13a ROTATE 2.13a .SALCHARS 2.13 SAVEOBJ 2.13 SAVETRANSFORM (with SETTRANSFORM) 2.13a SELECTPDP,SELECTSAT 5.2 SELECTVIEW 2.13a SENDPDP, SENDSAT 2.13 SETTRANSFORM 2.13a SETWINDOW 2.13 SET3DWINDOW 2.13 SHEAR 2.13a SQUASH (with EXPAND) 5.2 STRHEAD (with PLOTTERGINO) 2.13 SUBPIC 2.13 TRIMETRIC (with ISOMETRIC) 2.13a UNSETTRANS 2.13a WRITEPDP 5.2 XACROSS (with PLOTTERGINO) 2.13 XALONG (with PLOTTERGINO) 2.13
This section is presented as an attempt to summarise some of the vocabulary of the manual. It also acts as an index, together with Section 9. Reference is made to the principle sections of the manual bearing on each topic.
Details of the hardware on which the GINO system is implemented will be of interest to readers unfamiliar with the machines available at Cambridge.
ATLAS is the ATLAS II computer, of which TITAN is the prototype. Both machines have 128K of 48 bit words and operate under a multiaccess system with background batch processing. ATLAS has hardware for paging.
These two computers are practically identical. They have 8K of 18 bit word store. The two PDP's used by GINO are equipped with DEC340 displays. A detailed specification of this display is to be found in Ref. (12).
This computer has 16K of 18 bit word store. It is equipped with a 928 display, the specification of which is to be found in Ref. (19).
The speed of the data links to the PDP's can be adjusted by the hardware. The PDP7-TITAN link operates at approximately 20000 baUd; the PDP9-ATLAS link at a rather higher speed.
The data links to the Elliotts operate at 4800 baud and use the Elliott 916 Modem Controller.
These are described in CAD Group Document 27 (13), which covers all but the most recent features of GINO. An article is in preparation which gives an up-to-date account.