15 August 1966


Quarterly Technical Letter Report 2

Covering the Period 8 May through 7 August 1966

Stanford Research Institute ProJect 5890







D. C. Engelbart


Contract NAS1-5904


Prepared for

National Aeronautics and Space Administration

Langley Research Center, Langley Station

Langley, Virginia 23365, Mail Stop 126


Copy No. 14


0 (outqpr2) Quarterly Progress Report No. 2, ARNAS Project, covering period 8 May 1966 to 7 August 1966


1 Accomplishments During the Past Quarter


1a Basic Modifications to the COPE Assembler-Debugger System

1b Reorganization of NLTS (On-Line Text-Manipulation System)

1c Additions to NLTS

1c1 Structure study and alteration

1c1a Level Clipping

1c1b Statement Truncating

1c1c c*c use Q L or Q T to specify level, truncation

1c1d New text entities

1c2 Improved Feedback

1c3 Screen-Selection Experiments

1c3a Knee Control

1c3b Nose Pointer

1c3c Improved control coupling

1d Completion of FLTS (Off-Line Text-Manipulation System)

1e General Processing Tools





1g Trips, Visits, and Presentations

1h Demonstrations and explanations


2 Two Basic Needs Affecting Our Planning

2a Better System Organization

2b Display-Station Access


3 Basic, near-future plan.

3a Until about October.

3b After October.


4 Plans for the Next Quarter

4a Round Out Operating Features for NLTS

4al Statement Freezing

4a2 Indirect Referencing, or "Marking"

4a3 Automatic Renumbering

4a4 Disk-File, Semiautomatic Rewrite

4b Round Out Operating Features of FLTS

4c Develop a generalized output processor.

4d Equipment

4e Make new movies and slides.

4f Documentation on current systems.

4g Begin specification for a new system.

4h Trips planned:


5 APPENDIX--FLTS User's Guide


0 (qpr2) Quarterly Progress Report No. 2, ARNAS Project, covering period 8 May 1966 to 7 August 1966


1 Accomplishments During the Past Quarter

1a Basic Modifications to the COPE Assembler-Debugger System


1a1 COPE has been expanded so that it will serve as the underlying monitor system, in basic control at all times, for our on-line operating systems.


1a1a This allows on-line testing and debugging, under the COPE monitor, of all further additions and modifications to our on-line operating systems.


1a2 COPE has also been expanded to be able to handle program overlays and mixed-source programs.


1a2a This allows free growth of the operating systems, so that we can develop large repertoires of commands and/or more-sophisticated operations.


1a2b A COPE program may be written with parts of it designated for being stored on the disk and being "overlaid" onto specified sections of core when called by another part of the program.


1a2c FORTRAN and COMPASS routines, after translation into relocatable machine code by standard CDC translators, can be loaded by the modified COPE monitor, at the same time that it is assembling regular COPE code, so that processes written in these other languages can be mixed with COPE processes.


1b Reorganization of NLTS (On-Line Text-Manipulation System)


1b1 The version of NLTS as of about June 1 has been converted from COMPASS to COPE--i.e., all of its program instructions have been written in the form that will be translated into machine code by the COPE assembler.


1b2 This COPE version of NLTS is being reorganized internally so that parts of it can be stored, on the disk, as overlay processes to be brought in when needed.


1b2a This leaves room generally in core then, for overlay processes to be brought in; the further expansions for text manipulation thus have plenty of room to grow.


1b2b This version is the one that is being expanded, as




described below.


1b3 Especially for the RADC project, a means will be developed for storing arbitrary-data files, and for linking to them automatically from the stuctured-text files, so that there can essentially be numerical and graphical data embedded (and operated upon) within the text structure.


1c Additions to NLTS


1c1 Structure study and alteration--some additions designed as a next step in bringing power to these important user activities.


1c1a Level Clipping


1c1a1 This allows the user to specify a lower level to which the computer limits the statements displayed--which allows scanning over the text structure and seeing for instance only the first- and second-level statements (i.e. 1, 1a, 1b, 2, 2a, 2b, etc.).


1c1b Statement Truncating


1c1b1 This allows the user to specify the number of lines to which will be limited the display of each statement in whatever chain of statements might be displayed--which would allow quick, superficial scanning of many more statements per frame.


1c1c c*c One uses Q L or Q T to specify level or truncation numbers. For each command, a SPACE clears the old setting (and establishes the no-clipping and no-truncating status if followed by the CA), and up to four digits may be entered to set a new number.


1c1d New text entities--to facilitate designation of structure-alteration commands:


1c1d1 BRANCH: composed of one "top" statement, plus all of the substatements that lie under it.


1c1d2 LIST: designated by one "top" statement, and composed of the sublist of branches that lie under it.


1c1d3 GROUP: a list of branches, designated by two statements (which must belong to the same list), and composed of these two branches, plus all of the branches that lie between them.




1c1d4 c*c Move, copy, and delete operations may be executed on a whole branch (or list); and in the command specifications, only the branch's (or list's) top statement need be designated.


1c2 Improved Feedback


1c2a In the left region of the CFL (the Command Feedback Line) there now appears a four-character register that always displays the last four characters entered by the user--either from the keyboard or the keyset. There are special overbar and underbar combinations to indicate such as CA and CD operations.


1c3 Screen-Selection Experiments


1c3a Knee Control


1c3a1 We wanted to give a better try to the knee-control idea that was tested briefly over a year ago. One problem was that the mechanism was hard to adjust for different users and for different working positions of a given user.


1c3a2 We found an easy way to implement a more flexible version.


1c3a2a The rho-theta (radial-rotary) Grafacon transducer (which we had previously tested for horizontal, table-top coupling), was mounted on its side under the table.


1c3a2b A wire hook that could clamp lightly over one's knee (from the side) was attached to its slider arm.


1c3a2c Vertical knee motion now couples to the rotary potentiometer, and sideways knee motion couples to the radial potentiometer.


1c3a3 The control technique works, but it feels awkward and needs more testing. It will be evaluated further along with the nose pointer, etc.


1c3b Nose Pointer


1c3b1 One of the possibilities for new screen-selection devices that was considered during the 1964-65 NASA project was one operated by nodding or rotating the head (moving the bug by "pointing the nose").




1c3b2 An easy way to make a trial implementation was conceived and carried out.


1c3b2a Our old joystick mechanism was mounted on top of a construction-worker hard hat, with the stick pointing forward so that it could be moved up and down and side to side.


1c3b2b A long, light stiff metal tube was fixed over this handle, extending from the hat (when the user sits in front of the display) through a swivel-slider holder centered over the top of the display housing.


1c3b2c Turning or nodding the head causes the joystick mechanism to produce the two corresponding potentiometer voltages, which are used by the computer to move the bug on the screen just as for the mouse.


1c3b3 The nose pointer has been given only cursory evaluation trials, but it does work.


1c3b3a A user has his hands free for keyboard action while he moves the bug on the screen with nose-pointing motions.


1c3b3b After a few minutes one's head motion seems to get a little jerky (especially on small horizontal motions); it becomes a little hard to make accurate character selections, --which we attribute to cramping up due to being unpractised.


1c3b3c The hat should be lighter, and should not sit so high on the head.


1c3c Improved control coupling between transducers and the bug (for mouse, knee control, nose-pointer, etc.).


1c3c1 We put together some potentiometers and some adjustable, floating power supples, with which the user can independently adjust the centering and bug-displacement scaling for each axis.


1c3c2 Dave Hall, who works on another display-computer project, became interested in improving the control of the nose pointer by means of automatic scale changing.


1c3c2a We had considered this in our earlier NASA project, but never got around to giving it a fair test.




1c3c2b He has written some FORTRAN test routines to provide a step-change in incremental-displacement scaling at a certain head-rotation velocity.


1c3c3 It will be interesting to see how this works. We propose that it will be even better to use a smooth, monotonic functional relationship between nose-pointing velocity and the bug velocity.


1c3c3a In fact, one might introduce a dynamic relationship, involving more than just the first derivative of transducer position, that could give a ballistic response which, when mastered by means of suitable practice, might produce improved speed and accuracy.


1c3c4 This nonlinear-bug experimentation currently represents a bit of donated work by Mr. Hall, as he practices with basic programming techniques of on-line systems--but if we experiment much further, we would expect to carry it on this project.


1d Completion of FLTS (Off-Line Text-Manipulation System)


1d1 This system has been made operational, in a quite useable stage of development.


1d2 The basic features are described in our rough-draft user's guide, which is included (unedited) as Appendix A.


1e General Processing Tools


1e1 INDEX. A routine that will pick up a specified linked-statement disk file, extract the NAME and LOCNUM of each named statement, sort these alphabetically by name, and create another disk file in which these names are listed, together with the LOCNUMS of their statements. Also listed are the LOCNUMS of all statements that link to this name.


1e2 LIST ORGANIZER. A routine that will pick up a specified linked-statement file off the disk and produce a new file deposited in a designated file. The new file consists of a "list" ordering of the input file--i.e. each list is printed independently, headed by its source statement.


1e3 FILE DIRECTORY. A routine that will scan through the internal file directory of a disk and generate a user's "file directory" which it deposits in a file named "FD."




1e3a Currently, for each file found in the directory, a new statement is put on FD, composed as follows: LOCNUM of "O," the name under which that file is listed in the directory, and asterisks to the end of the line. Then this line is followed by several lines copied from the start of the file as found in the disk.


1f EQUIPMENT: Our Dura Mach 10 arrived and is installed in Pat Conley's office. FLTS will handle it's paper-tape code on both input and output. NLTS (Tom's version) will within a week.


1g Trips, Visits, and Presentations


1g1 Engelbart attended and gave a presentation at the ARPA meeting at Project MAC (MIT), May 16-17, 1966.


1g2 On the same trip, Engelbart visited at Rome Air

Development Center for a technical discussion and presentation

(Mr. A1 Barnum)


1g3 Engelbart gave a presentation at a seminar at the IBM Graphics Systems Laboratory, Palo Alto, California, June 30, 1966.


1g4 Engelbart visited Lawrence Radiation Laboratory (George Michael) and gave a presentation, June 9, 1966.


1h Demonstrations and explanations were given at SRI to:

1h1 E. Herold and Kenneth Fishbeck, RCA


1h2 Jerry Harris, McCalls


1h3 Accounting and Purchasing Personnel, SRI


1h4 Robbin Hough, Oakland University (Michigan)


1h5 Dr. Herbert Kauch, Heidelberg Institute


1h6 Roger Gillette, SRI, Washington, D.C.


1h7 General Kemp, USAF


1h8 Professor Robert North, Stanford University


1h9 Paul Frost, CSIRO, Australia


1h1O Dr. David A. Thompson, Stanford University


1h11 Lawrence Bennigson, Stanford University




1h12 Richard Smith, IBM, Yorktown Heights, New York


1h13 Barry H. Gross, ADFSC, Fort Belvoir, Virginia


1h14 Raymond Millican, System Sciences, SRI


1h15 Professor Harry Huskey, University of California, Berkeley


1h16 Professors Paul Martin, Arthur Hopkin and Mike Harrison, University of California


1h17 Donald Lincicome and James Laushine, Control Data Corporation, Burlington, Massachusetts


1h18 William Peet and Richard Powell, Electronic Associates, Inc.


1h19 Dr. Gene Merchants, Cincinnati Milling Machines


1h20 Dr. Paul Friedel and Graphics Group, IBM, Palo Alto


1h21 Rix Maurer and associates, Pederal Reserve Bank of San Francisco


1h22 A. E. Gribble and John Page, NASA, Langley Station


1h23 Dr. Carlos Cuadro, Systems Development Corporation


1h24 Dr. McKim, Stanford University


1h25 Professors Bowman and Boyle, Stanford University


1h26 John McConnell, University of California, Berkeley


1h27 J. Thompson, T. Cassidy, L. Bernstein, B. Farrell, G. Hammer, N. See, and D. Jones, Merrill Lynch, Pierce, Fenner and Smith, Inc.


1h28 Dr. R.D. Rogers, Stanford University


1h29 Robert Forester, Fairchild Semiconductor


1h30 George Michael and associates, LRL, Livermore


1h31 E. Cooper, McCalls


1h32 Group of 20 SRI Engineering Sciences and Industrial Development Division


1h33 Arthur Murphy, McCalls




1h34 J. Lamarca, Appleton Century Crofts


1h35 Representatives of SRI Chicago, Detroit and New York Offices


1h36 Victor Rosenberg, Donald Chesarek, Walter Jessel and Dwight Brown, IBM


1h37 Frank Coyne, Southern Pacific


1h38 Robert Taylor, ARPA


1h39 Professor William Bowman, Stanford University


1h40 Jeannette Hitchcock, Richard Johnson, David Weber, Allen Beaner, and J. Pooler, Stanford University


1h41 Ray de Saussure, LRL, Livermore


1h42 L. Earnest, Stanford University




2 Two Basic Needs Affecting Our Planning


2a Better System Organization


2a1 The on-line system we now have (on the 3100) was produced under the limited support conditions of last fall, and its basic organization largely a direct mapping of the system we had on the CDC 160A. Its shortcomings are becoming evermore apparent.


2a1a For instance, the labor involved in developing new operations and commands is getting to be quite high, and we have in mind some definite changes to remedy this.


2a2 We do NOT contemplate developing a special programming language, such as CORAL and AED.


2a3 For a reorganization, we would probably:


2a3a Use a mixture of FORTRAN and assembly language to do the actual programming.


2a3b Reorganize the data structure.


2a3c Carefully specify the standards for subroutines, functions, and operators, developing an interpretive-like calling system for executing these.


2a3d Develop a syntax-driven compiler for setting up all of the user commands--including conventions for specifying the computer feedback actions during the various stages of command specification and execution.


2a3d1 A compiler of this basic kind recently implemented for one of our new processes (see xx), required only three weeks elapsed time and a part-time effort of one man (Jeff Rulifson). These compiler writing techniques seem to be well in hand; the general "command language" compiler contemplated above is not considered to be a particularly adventuresome or big task--and it most certainly would improve the time and cost involved in developing and modifying our research tools.


2b Display-Station Access


2b1 Basic Experimental Progress


2b1a The general plan of our "bootstrapping" approach is to develop computer-augmentation tools and techniques, and then apply them meaningfully within an experimental community where each member is seriously trying to do the multiple job






2b1a1 Using the new tools and techniques as they evolve, for as much of his work as possible--living with the stress of awkwardness, system bugs, new ways of doing things, etc., as part of his contribution to the research.


2b1a2 Contributing constructive criticisms and suggestions to the general working system, as composed of the mix of old and evolving-new tools and techniques.


2b1a3 Contributing specifically, as a researcher or supporting-staff member, to the necessary tasks involved in analyzing and improving the working sytem, directing and managing the research, or administering and serving the working procedures.


2b1b We are learning, however, that the expected benefits of this approach--realism, orientation, and stimulus--are not being realized because there is insufficient availability of computer service.


2b1b1 One is often reluctant to sign up to use the CRT station for normal study and work because of such as


2b1b1a the large usage demand by personnel debugging new system features,


2b1b1b the inherent feeling that the debugging is more important than sitting at the console trying to get experience in learning how to work with it, and


2b1b1c the difficulty in knowing just when one will be ready for a certain bit of hard think work (preparatory thinking and composing often don't get done by "on-line" time).


2b1b2 One cannot freely commit his working files to computer store, since he cannot depend on getting to them when he needs them for reference or modification.


2b2 We are convinced that, to be successful, this "bootstrapping" experiment should have a time-sharing system, using a medium-sized computer (such as the CDC 3300 or the SDS 940), oriented completely to give fast priority service to its CRT-station users.


2b2a This could provide enough service to allow each member of this community to actually do all of his daily work on






2b3 Accordingly, we have decided to aim our long range planning and promotion toward this goal, and expect soon to submit an appropriate proposal to NASA and ARPA.




3 Basic, near-future plan.


3a Until about October.


3a1 Push hard on the addition and testing of new user features.


3a1a The minimum possible changes will be made in the basic system machinery--governed by two considerations:


3a1a1 providing reasonable service to the new features we wish to experiment, and


3a1a2 giving us experience and insight into possible new ways to organize the system.


3a2 Work seriously at the techniques of getting realistic usage out of the system (first stages of bootstrap feedback). Mainly in documentation and management areas.


3a3 c*c Several presentations are slated for early Fall, which help provide target dates for the above work.


3a3a September 22-23, the ARNAS semi-annual oral progress report, at Langley (perhaps a version in Washington, too).


3a3b October 4 (or thereabouts), a special one-hour presentation at the Annual Meeting of the American Documentation Institute (ADI), in Santa Monica.


3b After October.


3b1 Try to arrange for moving to a new, time-sharing computer by Spring 67, since combining the reorganization and the move would be maximally efficient.


3b2 For several months, concentrate upon specifying the design of an improved on-line operating system.


3b2a By then, we plan to have a much better, integrated view among us of the needs and possibilities for such a system. Our specific plans for the summer have been slanted at helping to get a good mix of experiences for this purpose.


3b3 Then reprogram, for whichever computer we will be using.




4 Plans for the Next Quarter


4a Round Out Operating Features for NLTS


4al Statement Freezing


4a1a This will allow the user to designate one or more individual statements (as he scans along a given chain of statements) which until further specification are to be "frozen" on the display.


4a1b This means that they will be moved to the top of the display, and remain unchanged while the rest of the display space is used for normal scanning.


4a2 Indirect Referencing, or "Marking"


4a2a This will allow a user to assign (or reassign) any one of a number of special reference codes (or markers) to any given character point in his text structure.


4a2a1 Thereafter (until that marker is reassigned to another statement) he may use this special (abbreviated) reference code to refer to that point for any command--especially such as Hop Place, Move Statement, etc.


4a2a2 For example, he may, in a Forward Statement command in which he designates the statement which he next wants to see at the top of the screen, substitute for the selection of a statement on the screen the designation of any of the marker positions. The computer will use this marker position for the command operand, and thus present a new display with the statement at the top of the screen being the one in which the associated marker was positioned.


4a2b This is to provide for very quick hopping back and forth between these "marked" points--more or less paralleling the situation at one's desk when he places various pages about his work surface for ready visual reference.


4a2c It also provides help for the process of collecting items into one location, as one scans through the rest of his material, by allowing an abbreviated reference to that location in a Move or Copy command.


4a3 Automatic Renumbering




4a3a Upon any Delete, Insert, Move or Copy operation on Statements, Branches or Lists, the statement structure will be immediately and automatically renumbered.


4a3a1 There will be a feature included in the specification procedure for each of these commands to allow the user to indicate the relative level that any newly located structure elements are to be assigned.


4a3a2 The new numbers will be assigned on the basis of relative level and ordinal position within the string of statements.


4a3a3 The structure will thus always be in a "logically numbered" condition.


4a3b This promises to give considerable aid to the user, but we anticipate some drawbacks.


4a3b1 Sometimes it is useful to the user (at least, with the present system) to leave fragments of the structure in odd numbering sequences, to help him remember the whereabouts of his different thought components.


4a3b2 This won't be possible any longer--but the new capabilities for studying the structure and making quick structural changes should outweight this potential disadvantage.


4a4 Disk-File, Semiautomatic Rewrite


4a4a Currently, one must type in the name of the disk file onto which he wishes the current contents of core to be written (usually "over-written").


4a4b The new output-to-file feature will be coupled to the convention (optional) of having the name of the file appear as the name of the first statement in the file (as held in core).


4a4b1 When the user specifies "rewrite disk," the computer will offer (displayed on the CFL), as the name of the file onto which to write out this core-held data, the word (if any) it finds in parentheses just after the location number of the first statement in this data.


4a4b2 The user may either accept this file destination (by hitting CA), or may replace it with a LIT entry, which costs him no more effort than it now does.




4a4c This will make much faster and safer the (frequent) rewriting of working files.


4b Round Out Operating Features of FLTS


4b1 These generally are in reasonably good shape. There probably will be work required to smooth out rough edges discovered as the system becomes more heavily used.


4b2 We expect to use this system quite heavily in developing our documentation and specifications over the next quarter.


4c Develop a generalized output processor. Elton Hay has been gathering together all of the features which seem reasonably desirable to include in a text-printout processor. He has a big flow chart developed, and has done much of the coding. In about two weeks it should be checked out and ready to integrate into a general package available both to NLTS and FLTS. General features are:


4cl There will be conventions for embedded directives that will cause changes in any of the many parameters--such as line length, line spacing, lines per page, etc.--as well as to designate such things as Start New Page Here, Establish Running Header (with content xxx), Start Numbering Pages (with first number to be xx), etc.