Google
 

Trailing-Edge - PDP-10 Archives - decuslib20-04 - decus/20-0135/doc/vista.man
There are 5 other files named vista.man in the archive. Click here to see a list.
 VISTA.MAN   1976-03-01  LAST UPDATE: 1979-02-15

Swedish National Defense Research Institute        FOA Report
S-104 50 Stockholm 80                              D10007-M3(E5)
SWEDEN                                             March 1976


VISTA - FOR FULL CONTROL OF TEXT DISPLAY TERMINALS

BY JACOB PALME


ABSTRACT

     VISTA is a program package for controlling the input and output
     to an alphanumeric display terminal from a SIMULA program on
     the DECsystem-10 computer.  VISTA allows full program control
     over the contents of the display screen.  The package can for
     example be used to produce "moving pictures" on part or whole
     of the display screen, or to allow the terminal user to move
     around the screen inputting data in various screen fields.  A
     special subpackage FORM allows data input by letting the user
     fill in fields in a "form" displayed on the screen.  Full
     validity check is done immediately for each field input from
     the user.  VISTA recognizes terminals of type INFOTON VISTA,
     VISTAR SATTELITE, INFOTON I 200, DEC VT52, TANDBERG TDV 2000,
     MINITEC, TELETEC, DATAMEDIA ELITE 2500, 1520, 3025, BEEHIVE B
     100, CDC 713-10, VOLKER 404, Volker 414H but will work on most
     other alphanumeric display terminals. The program may work
     on Hazeltine 1510 if initialized as for Volker 414H.


SEARCH KEY:  Computer, Terminal, Display terminal, Alphanumeric
     terminal, Conversational program, Dialogue program, Input,
     Output, Man-computer interaction, SIMULA programming language,
     Picture, Video, Graphic.


SWEDISH ABSTRACT

     VISTA {r ett programpaket f`r styrning av inmatning och
     utmatning till en alfanumerisk sk{rm fr}n ett SIMULA-program
     som k`rs p} datorn DECsystem-10.  VISTA m`jligg`r full
     programkontroll `ver inneh}llet p} sk{rmen.  Man kan t.ex.
     anv{nda paketet f`r att producera "r`rliga bilder" p} hela
     eller delar av sk{rmen, eller f`r att till}ta terminal-
     anv{ndaren att flytta sig runt sk{rmen medan han matar in data
     i olika f{lt p} sk{rmen.  Ett speciellt underpaket FORM till-
     }ter datainmatning genom att en blankett visas p} sk{rmen och
     anv{ndaren fyller i f{lt i denna blankett. Fullst{ndig validi-
     tetskontroll kan d} g`ras omedelbart efter varje inmatat f{lt-
     v{rde fr}n anv{ndaren.  VISTA kan anv{ndas p} de flesta
     textsk{rmsterminaler f`r vilka skrivmark`ren kan styras fr}n
     datorn.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 2


0. TABLE OF CONTENTS

     1.  INTRODUCTION
     2.  OUTPUT TO THE DISPLAY TERMINAL
     3.  INPUT FROM THE DISPLAY TERMINAL
     4.  DATA AVAILABLE TO THE USER
     5.  PREAMBLE FOR PROGRAMS USING THE VISTA PACKAGE
     6.  SWITCHING BETWEEN SEVERAL SCREEN CONTENTS
     7.  CAT AND SHIP - EXAMPLES OF USE OF THE VISTA PACKAGE
     8.  FORM - A SUBPACKAGE FOR FORM-FILL-IN DATA ENTRY
     9.  FORMT AND TABLE - EXAMPLES OF USE OF THE FORM
          PACKAGE
     10. DEBUGGING PROGRAMS USING THE VISTA PACKAGE
     11. MODIFYING VISTA FOR A NEW KIND OF TERMINAL
     Appendix A: NEW FEATURES IN VISTA RELEASE 1976-11
     Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED
     Appendix C: MOVING PICTURES SHOW SIMULATION TO USER


1. INTRODUCTION

     An alphanumeric display terminal allows the cursor to be moved
     freely around the screen, and information to be input and
     output at arbitrary positions on the screen.

     This can be used to produce pictures or tables on the screen,
     where objects or figure change or move during the execution of
     a program.  Data can also be input at arbitrary positions on
     the screen as guided by the terminal user.

     A special application of this is the "form fill-in" method of
     data entry into a program, where a form is displayed on the
     screen, and the terminal user fills in empty fields in this
     form.

     The VISTA package makes it simple to write such programs in the
     SIMULA programming language on a DECsystem-10 computer.

     The package is written for use with VISTA INFOTON alpha-numeric
     display terminals, but the package can be modified for use with
     other display terminals.  (The cursor control commands are
     unfortunately not yet standardized for display terminals.)
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 3


2. OUTPUT TO THE DISPLAY TERMINAL

     WARNING:  If you do any output to the terminal not
     using these procedures, the screen may be garbled.  You
     can then restore the screen by calling the procedure
     "restore_the_whole_screen".


PROCEDURE move_the_cursor_to(horiz, vertic);
     INTEGER horiz, vertic;
     COMMENT This procedure will move the cursor to the
     indicated position on the display screen.  The screen
     is indexed with [0,0] equal to the upper left corner of
     the screen, and with "horiz" increasing leftwards and
     "vertic" increasing downwards from this origin.


PROCEDURE home_the_cursor;
     COMMENT This procedure will move the cursor to position
     [0,0], that is the upper left corner of the screen.


PROCEDURE local_home_the_cursor;
     COMMENT will move the cursor to a terminal-dependent home
     position, usually [0,0] but the lower left corner on CDC 713-10
     in scroll mode.

PROCEDURE outchar(setchar);
     CHARACTER setchar;
     COMMENT This procedure will output the character
     "setchar" onto the cursor position on the screen.  The
     cursor is moved past the outputted character.


PROCEDURE set_char_on_screen(setchar,horiz,vertic);
     CHARACTER setchar;  INTEGER horiz, vertic;
     COMMENT This procedure will output the character
     "setchar" in the position [horiz,vertic] on the screen.
     The cursor is left referring to the [horiz,vertic]
     position (not the next position).


PROCEDURE breakoutimage;
     Breakoutimage should be called if the execution of your program
     is stopped or interrupted (e.g.  at end of execution, with the
     system procedure sleep, for conversation with another terminal,
     for a long timeconsuming task not including any terminal
     output) and you want to ensure that all text printed before the
     stop is output to the terminal.  It is  n o t necessary to call
     breakoutimage before inputting data from the terminal using the
     input procedures defined below, since all these input
     procedures will automatically commence with breakoutimage.
     This means that many programs never have to call breakoutimage.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 4
2. OUTPUT TO THE DISPLAY TERMINAL


PROCEDURE synchronize(horiz, vertic);
     INTEGER horiz, vertic;
     COMMENT This procedure is to be called if there is a
     risk that the correct cursor position on the screen,
     and the position where the program believes the cursor
     to be, is not the same.  The cursor is moved to the
     indicated position even if such was the case.  Such a
     risk is most often common after inputting data from the
     user terminal when "echoenabled" is TRUE.  In such
     cases, VISTA will usually automatically call
     synchronize.


PROCEDURE outtext(t);
     VALUE t;  TEXT t;
     COMMENT This procedure will output the text t on the
     terminal beginning at the cursor position on the
     screen.  The programmer must ensure that there is
     enough space left on the current line of the screen for
     the entire length of the TEXT "t".


PROCEDURE outfix(a,i,j);
     REAL a;  INTEGER i, j;
     COMMENT Almost same as standard SIMULA outfix on the
     screen.  The programmer must ensure that there is space
     for j more characters on the current line of the
     screen.


PROCEDURE outreal(a,i,j);
     REAL a;  INTEGER i, j;
     COMMENT Almost same as standard SIMULA outreal on the
     screen.  The programmer must ensure that there is space
     for j more characters on the current line of the
     screen.


PROCEDURE outfrac(k,i,j);
     INTEGER k, i, j;
     COMMENT Almost same as standard SIMULA outfrac on the
     screen.  The programmer must ensure that there is space
     for j more characters on the current line of the
     screen.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 5
2. OUTPUT TO THE DISPLAY TERMINAL


PROCEDURE outint(i,j);
     INTEGER i, j;
     COMMENT Almost the same as standard SIMULA outint on
     the screen.  The programmer must ensure that there is
     space for j more characters on the current line of the
     screen.


PROCEDURE outimage;
     COMMENT Will output any characters in the sysout.image
     and then move the cursor to the beginning of the next
     line on the screen.


PROCEDURE blank_line(vertic);
     INTEGER vertic;
     COMMENT Will make line "vertic" on the screen fully
     blank.  The cursor is left at the first position of the
     blanked line.


PROCEDURE make_blank(size);
     INTEGER size;
     COMMENT Will make size number of characters blank on
     the screen, starting at current position.  Trailing
     blanks in the screenfields are not reblanked, which
     means that the cursor is left at the first blank which
     need not be reblanked.  Cursor position after this
     procedure will thus depend on how much need be blanked
     on the screen.


PROCEDURE blank_the_screen;
     COMMENT Will make the entire screen blank.  This is
     done automatically when a new VISTA object is created.




PROCEDURE restore_the_whole_screen;
     COMMENT If there is any risk that the data on the
     screen does not agree with what the program belives to
     be there, this procedure will restore the screen to
     what the program belives to be there.  This risk can
     happen if you have input or output data with procedures
     not part of the VISTA package, or if "echoenabled" is
     TRUE and the terminal user has done "type ahead" on the
     terminal keyboard.  "restore_the_whole_screen" is
     called by the VISTA package if the terminal user pushes
     the FORMFEED (=CONTROL-L) key on his terminal keyboard.
     ALTMODE (ESCAPE) has the same effect as FORMFEED, but
     must be pushed twice on VT52 terminals.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 6
2. OUTPUT TO THE DISPLAY TERMINAL


PROCEDURE restore_one_char(horiz, vertic);
     INTEGER horiz, vertic;
     COMMENT Will restore the character in the position horiz, vertic on
     the terminal to what the program believes to be there.


PROCEDURE cause_real_time_delay(number_of_fillers);
     INTEGER number_of_fillers;
     COMMENT this procedure will transmit "number_of_fillers" fill
     characters to the screen. These characters are not output to the
     screen.  This procedure can be used to delay moving pictures from
     moving too fast on the screen.  The number of fillers transmitted
     depends on the speed of the terminal line - more characters for
     faster terminal lines.  Example: With a 2400 baud terminal line,
     120 fillers will cause a half-second delay.

     Note: The global variable trmspeed contains the transmission speed
     to the terminal. Thus, you can get a half-second delay by
     the procedure call "cause_real_time_delay(trmspeed/20);".

     Warning:  This procedure, and not the SLEEP procedure, is
     recommended if you want smoothly moving pictures on the screen.
     This procedure is however rather CPU-time-consuming.


PROCEDURE cancel_display;
     COMMENT The screen will be blanked.  Further calls on the output
     procedures in the VISTA package will only change the internal copy
     of the screen, nothing will be output to the terminal.

     This procedure can be used if you want to display another VISTA
     picture or if you want to talk to the terminal not using the VISTA
     package.

     WARNING:  The input procedures in the VISTA package may not be used
     on cancelled VISTA pictures.


PROCEDURE resume_display;
     COMMENT The screen is restored to the internal copy of the screen,
     and further output procedures in the VISTA package will affect both
     the terminal and the internal copy of the screen.

     Note that if you have used the VISTA output procedures on a
     cancelled picture, then the internal version of that picture is
     changed.  Thus, when you call resume_display, the modified picture
     is shown.

     WARNING:  If you are keeping several VISTA objects to switch
     between pictures, then  a l w a y s  cancel the previous display
     before resuming the next.  More than one VISTA object should never
     be resumed at the same time.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 7
2. OUTPUT TO THE DISPLAY TERMINAL


BOOLEAN PROCEDURE displaying;
     COMMENT Will return TRUE if this picture is displaying
     (not cancelled with the procedure cancel_display).


HOW TO CREATE BLINKING TEXT

     Blinking text is not available on all terminals.  The
     procedure for getting a terminal to blink is very
     different on terminals of different make.  If you want
     to write programs which create blinking text in a way
     which will work on most terminals, then follow this
     procedure:

   > Reserve a space immediately in front of and after the
     blinking text segment.

   > Move the cursor to the position after the blinking text
     segment and call the procedure stop_blink.

   > Move the cursor to the position in front of the
     blinking text segment and call the procedure
     start_blink.

   > Write the blinking text segment.

   > Call the procedure stop_blink again.

     If you want text on several lines to blink, then regard
     each continuous blinking text segment on each line as a
     separate text segment, and the procedure above must be
     followed for each such text segments.


HOW TO STOP BLINKING TEXT FROM BLINKING

     Rewrite the same or other text on top of each blinking
     text segment including the character immediately in
     front of and immediately after the blinking text
     segment.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 8
2. OUTPUT TO THE DISPLAY TERMINAL

PROCEDURE start_blink;
     COMMENT this procedure will start a section of blinking text on
     terminals where blinking text is allowed, and will sound the bell
     on terminals which have a bell. (Bell is optional on Infoton
     terminals, the VT52 does not allow blinking text.) The procedure
     will also output a space on the screen, since certain terminals
     require a space in front of blinking text.  Warning: On infoton
     terminals, start_blink need not be called when you are chanching
     the contents of the blinking text, but if you do not call
     start_blink in such cases, your programs will only work as intended
     on Infoton terminals.


PROCEDURE stop_blink;
     COMMENT this procedure will stop a section of blinking text on
     terminals where blinking text is allowed.  The procedure will also
     output a space on the screen, since certain terminals require a
     space after blinking text.
     Warning 1:  Call stop_blink after changes in blinking text if you
     want terminal-independent programs. (The infoton does not require
     this.)
     Warning 2:  Call stop_blink before every command to move the cursor
     on the screen.  (This is not necessary on some terminals, but is
     necessary on Infoton terminals.)


PROCEDURE specialtext;
     COMMENT some terminal models allow text to be displayed in
     different styles, e.g. in lower or higher intensity, underlined or
     in inverse video. This procedure starts output in some such special
     mode for terminals with this facility. The procedure has no effect
     with other terminal models.


PROCEDURE normaltext;
     COMMENT this procedure counteracts the action of the "specialtext"
     procedure and goes back to displaying text in normal fashion.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 9
2. OUTPUT TO THE DISPLAY TERMINAL

3. INPUT FROM THE DISPLAY TERMINAL

     WARNING:  If you do any INPUT from the terminal not using these
     procedures, then the screen contents may be garbled.  In that case,
     the screen can be restored by calling the procedure
     "restore_the_whole_screen".

     If the terminal user pushes the ALTMODE (ESCAPE) or FORMFEED
     (=CONTROL-L) button on his terminal, then the procedure
     restore_the_whole_screen will be called from the program, the next
     time the program tries to make input from the terminal through the
     routines described below.  (On VT52 terminals, the ALTMODE must be
     pushed twice.)

     A note on the DATAMEDIA ELITE 1520 terminal:  If you have this
     terminal without the optional "numeric" keyboard, then your
     terminal does not have the special keys for moving the cursor up,
     down, left and right which are often used as input from the user
     terminal.

     However, there are ways of inputting these codes from such ELITE
     1520 terminals.  Use the following keys:

     UP     = CONTROL-
     DOWN   = LINE FEED
     LEFT   = BACKSPACE
     RIGHT  = CONTROL-@ or CONTROL- (test yourself)
     HOME   = CONTROL-Y
     ERASE SCREEN = CONTROL-L


PROCEDURE echon;
     COMMENT will make echoenabled TRUE, which means that characters
     input from the terminal are echoed by the terminal control handler
     of the computer and not by the vista package.
     Advantage:  Faster echoing when the computer is heavily loaded.
     Disadvantage:  Risk that the screen contents do not agree with what
     the program believes to be there, especially if the terminal user
     has done "type ahead".

     WARNING:  With monitor echoing, the inputting of CR from the user
     will erase the next line on the screen, and inputting LF will erase
     part of the next line on the screen.  You can avoid this problem by
     either a) using program echoing (echoff), or b) keeping the next
     line blank when inputting data from the user or c) restoring the
     erased line in your program.

     The combination of monitor echoing and a Tandberg TCD 2000 terminal
     may also give problems if the "cursor up" key is pushed by a user
     on his terminal when the cursor is at the last line of the screen.


PROCEDURE echoff;
     COMMENT will make "echoenabled" FALSE.  See "echon" above.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 10
3. INPUT FROM THE DISPLAY TERMINAL


CHARACTER PROCEDURE insingle(echo);
     BOOLEAN echo;
     COMMENT will input one character directly from the
     terminal keyboard, bypassing sysin.image entirely.  The
     user need not push carriage return on his terminal, the
     program will get direct control every time the user
     pushes a terminal key.
     "echo" has effect only if "echoenabled" is FALSE.  In
     that case, if "echo" is FALSE, the input character is
     not echoed at all on the terminal screen.  The
     programmer must thus ensure that user input characters
     are echoed correctly.
     If "echo" is TRUE, but "echoenabled" FALSE, then the
     VISTA package will try to echo input characters.
     Terminal keys like the four keys for moving the cursor
     up, down, left and right, the carriage return, line
     feed, home and rub out(delete) keys are all echoed
     correctly.  (They are usually echoed correctly also
     when echoeanbled is TRUE.)
     Insingle will set the global BOOLEAN variable
     "controlchar" to TRUE if the character read was a
     terminal control character.  Thus, to test if the
     character read was the key with a downdirected arrow on
     the terminal, you can write "c:= insingle(TRUE);  IF
     controlchar AND c = down THEN".


PROCEDURE inimage;
     COMMENT inimage will input a line of text from the
     terminal into the buffer sysin.image.  IF "echoeanbled"
     is TRUE, inimage works just like the ordinary SIMULA
     inimage.  If "echoenabled" is FALSE, inimage is
     different in that every character with RANK less than
     32 will act as a "break" characters, that is signifying
     end of the data input with this call to the inimage
     procedure.


INTEGER PROCEDURE inint;
     COMMENT will search for and read an integer from the
     terminal.  If the data input from the terminal is not
     readable as an integer, then the input field is filled
     with question marks.

     Note:  Not identical to SIMULA inint, since only one
     integer can be read before the user pushes the RETURN
     key on his terminal.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS      Page 11
3. INPUT FROM THE DISPLAY TERMINAL


REAL PROCEDURE inreal;
     COMMENT will search for and read a real item from the
     terminal.  If the data input from the terminal is not
     readable as a real, the the input field is filled with
     question marks.

     Note:  Not identical to SIMULA inreal, since only one
     real can be read before the user pushes the RETURN key
     on his terminal.


TEXT PROCEDURE inword;
     COMMENT will search for and read a word from the
     terminal.  A word is any sequence of non-blank
     characters.


BOOLEAN PROCEDURE inyes;
     COMMENT will search for either "yes" or "no" from the
     terminal, and will return TRUE if "yes" is found.


4. DATA AVAILABLE TO THE USER

     WARNING:  Never change these variables directly.  Always use
     the procedures described above.


SCREEN CONTENTS:


INTEGER PROCEDURE horizontalpos;
     COMMENT Position of the cursor on the screen.


INTEGER PROCEDURE verticalpos;
     COMMENT Position of the cursor on the screen.


TEXT ARRAY screen[0:height-1];
     COMMENT contents of the display screen;
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 12
4. DATA AVAILABLE TO THE USER


CHARACTER PROCEDURE get_char_from_screen(horiz, vertic);
     INTEGER horiz, vertic;
     COMMENT will return the character in the indicated screen
     position.  Will return CHAR(0) if [horiz,vertic] is outside
     the available screen.


TERMINAL INTERFACE MODES:


BOOLEAN echoenabled;
     COMMENT if TRUE, input characters are echoed by the monitor,
     if FALSE by the VISTA package or by you.  See further the
     description of the procedure "echon" above.


USEFUL CHARACTER VARIABLES:

     up = what is input when user pushes the key with an upward
          pointing arrow (usually indicating wish to move the
          cursor upwards on the screen).
     down = same for downward pointing arrow.
     left = same for left-pointing arrow.
     right = same for right-pointing arrow.
     tab = same for tab key on terminal.  (On Tandberg TDV 2000,
          the blink key can be used instead of the tab key.)
     home = what is input when user pushes the home key on the
          terminal, (usually indicating wish to move the cursor to
          a "home" position on the screen. On most terminals, the
          home position is the upper left corner of the screen. On
          CDC 713-10 terminal in scroll mode, the home position is
          the lower left corner.)
     formfeed, carriagereturn, altmode, linefeed, verttab, null,
          fill, tab, startblink, stopblink = what is input when the
          user pushes these respective terminal keys.
     BOOLEAN controlchar = TRUE if the previous character input
          with INSINGLE was a terminal control character.  Thus, to
          check if the previous character was the key on the
          terminal to move the cursor down (with a downdirected
          arrow on it) you can write in your program:
          c:= insingle(TRUE);
          IF controlchar AND c = down THEN ...

     BOOLEAN scrollallow = TRUE stops the automatic inhibiting of
          screen scrolling when you push the CR och LF key at the
          bottom of the screen.  However, the internal screen copy
          is not scrolled properly.

     BOOLEAN addaltmode = TRUE if the type of terminal is of a kind
          where each special terminal control character is preceded
          by an altmode.  You need normally not trouble yourself
          with this, since the procedure "insingle" and the other
          input procedures in the vista package will remove this
          altmode (and make CONTROLCHAR = TRUE).
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 13
4. DATA AVAILABLE TO THE USER


DISPLAYING ON OTHER TERMINALS THAN THE CONTROLLING TTY

     It is possible to use the VISTA package to display pictures on
     other terminals than the controlling TTY.

     Important:  Ensure that you always make outimage on every
     picture displayed on different terminals, before any input
     break in your program.  Otherwise you may get half-finished
     pictures on some TTY:s.  Note that the procedure "outimage"
     built into the VISTA package should be used.

     Output to other TTY:s is no problem.

     Input from other TTY:s through the VISTA package causes some
     problems.  The echo parameter must be TRUE when creating VISTA
     objects, and insinglechar cannot be used.

     VISTA can be combined with the REALTIME package to allow
     simultaneous dialouge on more than one terminal.


5. PREAMBLE FOR PROGRAMS USING THE VISTA PACKAGE

     The following example of a very short complete program using
     the VISTA package shows what you have to do:

     BEGIN
       EXTERNAL CHARACTER PROCEDURE insinglechar, fetchar;
       EXTERNAL PROCEDURE depchar, forceout, outstring;
       EXTERNAL INTEGER PROCEDURE trmop, gettab, checkreal,
       checkint, iondx;
       EXTERNAL PROCEDURE echo, abort, outchr, outche;
       EXTERNAL TEXT PROCEDURE tmpin, scanto, storbokstav, maketext;
       EXTERNAL BOOLEAN PROCEDURE meny, tmpout;
       EXTERNAL CLASS vista, termty;
       INSPECT NEW vista(78, 19, sysin, sysout, FALSE,
       0, NOTEXT, NOTEXT) DO
       BEGIN
         INTEGER h, v, sign;
         blank_the_screen;
         FOR sign:= rank('A') STEP 1 UNTIL rank('Z') DO
         FOR h:= 1 STEP 1 UNTIL 10 DO
         FOR v:= 1 STEP 1 UNTIL 10 DO
         set_char_on_screen(char(sign),h,v);
         breakoutimage;
       END;
     END;

     The parameters in the "NEW vista" statement are:

   > Width of the screen.  Subtract 1 or 2 from the real width.

   > Height of the screen.  Subtract 1 from the real height.

   > Sysin = the infile connected to the terminal.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 14
5. PREAMBLE FOR PROGRAMS USING THE VISTA PACKAGE

   > Sysout = the outfile connected to the terminal.  (The package
     will probably only work if sysout is the controlling terminal.)

   > TRUE if you want automatic echoing of characters by the
     monitor, FALSE if you want echoing by the VISTA package. FALSE
     is usually safer.  If you only use the VISTA package for output
     to the terminal, not for input from the terminal, then TRUE has
     certain advantages.  TRUE may give special problems on TANDBERG
     terminals, see the description of the procedure "echon" above.

   > The next parameter indicates terminal type. IMPORTANT:  If you
     want the same program to be runnable on different kinds of ter-
     minal, then you should either ask the user for a value for this
     parameter, or (usually easiest) let this parameter be 0, so
     that the VISTA package will ask the user for his terminal make.

     If this parameter is 0, the user at the terminal will be asked what
     kind of terminal he is using.  The other valid values for this
     parameter are 1 for INFOTON VISTA terminals, 2 for DEC VT52
     terminals, 3 for Minitec terminals, 4 for ELITE 2500 with auto-lf,
     5 for ELITE 2500 without auto-lf, 6 for ELITE 1520 with auto-lf, 7
     for ELITE 1520 without auto-lf, 8 for TELETEC, 9 for VISTAR
     sattelite, 10 for TANDBERG TDV 2000, 11 for BEEHIVE B 100, 12 for
     CDC71310 in scroll mode, 13 for CDC71310 in page mode, 14 for ELITE
     3025, 15 for ELITE 1521, 16 for VOLKER-CRAIG 404, 17 for VOLKER-
     CRAIG 414H, 20 for ADM-3A, 19 for INFOTON I 200 and a large value
     for your own special kind of terminal.  If you are using a
     DATAMEDIA ELITE terminal, the version witout auto-lf is much better
     with the VISTA package.)

     A better way of indicating terminal type than by the parameter to
     VISTA is usually do include the terminal type indication in a
     TMPCOR file, with the name TRM.

     This TMPCOR file should include the terminal type formatted as in
     the answer to the initial question which VISTA will otherwise write
     to the terminal, e.g. "VISTA" or "I200". The TMPCOR-file can
     include the switches /DCA or /-DCA to control direct cursor
     addressing, and /ALF or /-ALF to indicate if the terminal has built
     in auto-lf at carriage return.

     Note the use of the classes TERMTY and GETVIS to find terminal type
     information from TMPCOR, SWITCH.INI or by asking the user.

     DIRECT CURSOR ADDRESSING

     Some terminals (e.g.  DEC VT52) allow the program to move the
     cursor directly to certain screen positions. Advantage:  A
     little faster and safer access to screen positions.
     Disadvantage:  Does not work on some installations where
     special character conversion is done.  (The program is however
     able to cope correctly with the TTY QZ character conversion at
     the QZ computer centre in Stockholm.  However, with TTY QZ,
     your programs will be much faster if you are NOT using direct
     cursor adressing.)
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 15
5. PREAMBLE FOR PROGRAMS USING THE VISTA PACKAGE

     You can tell VISTA to use direct cursor addressing by including
     the text /DCA in either TMP:TRM or the last text parameter
     in the NEW VISTA statement. /-DCA tells VISTA not to use
     direct cursor addressing.

     AUTO-LINE FEED

     Some terminals have an auto-line-feed feature when receiving
     carriage returns - that is, they will, when they receive
     carriage return, act as if they had received a line feed after
     the carriage return.

     VISTA works best without this feature. If, however, you still
     want to try to use VISTA with this feature, then include the
     text /ALF in the TMP:TRM file or in the last text parameter in
     the NEW VISTA statement.

     YOUR OWN SPECIAL KIND OF TERMINAL

     You can use the last two parameters to the VISTA package to
     specify the characteristics of another terminal than those
     which the package already knows about.

     Necessary is that there are keys on your terminal to move the
     cursor down, up, right, left, to home the cursor(move it to
     the upper left corner of the screen, and to erase the screen).
     Pushing these keys should transmit to the computer either a
     single ASCII character or an altmode(escape) character
     followed by a single ASCII character.

     (On some terminals these special keys can be simulated using
     other keys, often in combination with the CONTROL key.)

   > The next to last parameters to the CLASS VISTA should in this
     case contain the name of your kind of terminal.

   > And the last parameter should contain a text with the character
     codes to move the cursor down, up, right, left, home and to
     erase the screen (in that order, no blanks between them). If
     you include the switches /DCA, /-DCA, /ALF or /-ALF in this
     text parameter, then they should come after the character codes
     indicating cursor control.

     You can get the program to use your special kind of terminal
     in two ways.  Either let the third to last parameter to VISTA
     be 0, and the computer will ask the user at his terminal what
     kind of terminal he has.  Or let the third to last parameter
     to VISTA have a large value, and the computer will assume that
     the terminal is always of your special kind.

     The source programs of the VISTA package are at the QZ data center
     available on the FOA: area. The REL and ATR files are part of
     SYS:LIBSIM. FOA:LIBSIM may contain a newer version than SYS:LIBSIM.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 16


     A simple way of getting data for the parameters to the class
     VISTA is to call the procedure GETVISTAPARAMETERS. This
     procedure will find the parameters for you, looking in
     SWITCH.INI, TMP:TRM, the command string or asking the user at
     his terminal. GETVISTAPARAMETERS is available in SYS:LIBSIM.

**** PROCEDURE GETVISTAPARAMETERS(chars, lines, termnr, message);
     NAME chars, lines, termnr, message;
     INTEGER chars, lines, termnr; TEXT message;

     (Written by Mats Wallin, FOA 142, 78-07-25)

     This procedure is used to get values for some of the parameters
     before a call of the (external) class vista. The procedure
     tries to determine the TTY-type by looking in the following
     places: (in ascending priority order)

     1. File SWITCH.INI on user ppn, line labeled TERMINAL
     2. TMPCORE file TMP:TRM
     3. The monitorcommand starting the program, using rescan.
     4. If not yet found, or false info, ask the user.

     In addition, if there is no info on TMP:TRM or info is provided
     by the user via rescan or directly by this procedure the
     procedure creates TMP:TRM and writes on it the info found.

     NOTE: If you would like to use rescan in your program, instead
     of the expression:
     IF rescan THEN ...
     you should use the expression:
     IF Sysin.Image.Strip =/= NOTEXT THEN ...
     and then NOT call Inimage, as that is already done by this
     procedure. That is possible only if info was found according to
     1-3 above.

     Example of use:

      INTEGER a, b, c;
      TEXT t;
      getvistaparameters(a, b, c, t);
      vista (a, b, Sysin, Sysout, FALSE, c, t, NOTEXT) BEGIN


      Extra external procedures required: (not in vista)
      BOOLEAN rescan, INTEGER search, sscan,
      TEXT compress, conc, REF (infile) findinfile.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 17


6. SWITCHING BETWEEN SEVERAL SCREEN CONTENTS

     It is easy with the VISTA package to have several pictures,
     and switch between them.  You just allocate one object of the
     CLASS vista for each picture.  You can then have a reference
     variable referring to each picture.  Suppose that you have

          REF (vista) first_picture, second_picture;

     You can then switch from displaying the first to displaying
     the second picture on the screen by simply executing the
     statements:

          first_picture.cancel_display;
          second_picture.resume_display;

     Note:  More than one picture may never be active at the same
     time.  Therefore always cancel the previous picture before
     resuming the next.  VISTA objects just generated with NEW are
     always active, and if you do not want them active you should
     cancel them before generating the next picture.

     It is however legal to have no picture active.  This is what
     you do if you want to talk to the terminal without using the
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 18
6. SWITCHING BETWEEN SEVERAL SCREEN CONTENTS


     It is legal to use all the procedures in the VISTA package
     except the input procedures even on a cancelled picture.  The
     VISTA output procedures on a cancelled picture will then
     change an internal copy of the terminal screen, and this
     internal copy will be shown to the user again when the program
     calls the procedure "resume_display" on that picture.

     NOTE: If you use several terminals, handled using the
     realtime package for multiterminal handling, then
     you must call "forceout(terminalout)" both before and
     after a call to "waitforinput".

     Example of a complete, executable program using two pictures
     to switch between:

     BEGIN
       EXTERNAL CHARACTER PROCEDURE insinglechar, fetchar;
       EXTERNAL PROCEDURE depchar, forceout, outstring;
       EXTERNAL INTEGER PROCEDURE trmop, gettab, checkreal,
       checkint, iondx;
       EXTERNAL PROCEDURE echo, abort, outchr, outche;
       EXTERNAL TEXT PROCEDURE tmpin, scanto, storbokstav, maketext;
       EXTERNAL BOOLEAN PROCEDURE meny, tmpout;
       EXTERNAL CLASS vista, termty;
       REF (vista) first_picture, second_picture;
       INTEGER h, v, sign, casedifference;
       casedifference:= rank('a') - rank('A');
       second_picture:- NEW vista
       (78, 19, sysin, sysout, FALSE, 0, NOTEXT, NOTEXT);
       second_picture.cancel_display;
       first_picture:- NEW vista
       (78, 19, sysin, sysout, FALSE, 0, NOTEXT, NOTEXT);
       first_picture.blank_the_screen;
       second_picture.blank_the_screen;
       FOR sign:= rank('A') STEP 1 UNTIL rank('Z') DO
       BEGIN
         IF mod(sign,3) = 0 THEN
         BEGIN
           IF mod(sign,2) = 0 THEN
           BEGIN
             second_picture.cancel_display;
             first_picture.resume_display;
           END ELSE
           BEGIN
             first_picture.cancel_display;
             second_picture.resume_display;
           END;
         END;
         FOR h:= 1 STEP 1 UNTIL 10 DO
         FOR v:= 1 STEP 1 UNTIL 10 DO
         BEGIN
           first_picture.set_char_on_screen
           (char(sign),h,v);
           second_picture.set_char_on_screen
           (char(sign+casedifference),h+20,v);
         END;
       END;
       first_picture.outimage;
       second_picture.outimage;
     END;
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 19
7. CAT, SHIP AND VIDED - EXAMPLES OF USE OF THE VISTA PACKAGE


7. CAT, SHIP AND VIDED - EXAMPLES OF USE OF THE VISTA PACKAGE

     CAT, SHIP and VIDED are three demonstration examples to
     illustrate how the VISTA package can be used.

     CAT is a program in which a cat tries to catch a number of
     rats in a square cage.  The cage and the two animals are shown
     in a map of the cage on the terminal screen, where the user
     can see how they move about the cage.  The user at the
     terminal can guide the movement of the cat with four keys for
     up, down, left and right.  (On certain terminal without these
     keys, they can be simulated with combinations of other keys.)
     The program makes the rat more intelligent if the terminal
     user catches many rats.  A score of escaped and caught rats is
     caught on the screen.

     SHIP is a simplified simulation program.  A number of ships
     try to move soldiers from one side of a lake to the other
     side.  A number of destroyers hunt the ships.  The user can
     see at the terminal how the ships move across the lake, how
     the destroyers move, how troups accumulate on the other side
     of the lake, how ships and destroyers fight.  A portion of the
     screen shows the number of ships in various states:  Loading,
     unloading, moving, killed etc.

     VIDED is a very simple text editor for display terminals.  The
     screen will always show exactly the contents of the text you
     are editing.

     NOTE:  VIDED works at present (November 5, 1976) only on
     INFOTON VISTA terminals).

     CAT, SHIP and VIDED are at the QZ computing center available
     on [106,346] and if you have a VISTA terminal, you can run the
     programs by the command

     .RUN CAT[106,346] or

     .RUN SHIP[106,346] or

     .RUN VIDED[106,346]

     The source programs CAT.SIM and SHIP.SIM are at the QZ
     computing center available on DEC-tape H40I48.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 20


8. FORM - A SUBPACKAGE FOR FORM-FILL-IN DATA ENTRY

     FORM is a subclass to VISTA to allow the writing of programs in
     which the terminal screen is made to look like a form with
     various empty fields.  The terminal user then inputs data by
     filling in the fields of the form.

     You define your form by generating an object of the CLASS FIELD
     for each field in the form.  For each field you indicate its
     position on the screen and the header in front of the input
     part of the field.  The order in which you generate the NEW
     FIELD objects is important.  They must be generated according
     to their position on the screen, left to right, top to bottom.

     You can also use any of the VISTA procedures on parts of the
     screen where you are not using the FORM package, e.g. you can
     use OUTTEXT to print a header on top of the form.

     When you have generated all the objects, you can call the
     procedure SHOW_PAGE which will display all the headers on the
     screen.  You can then call the procedure ASK_PAGE which will
     ask the terminal user input for each field in the form.

     If you want to allow the user a chance to change his form
     entries after completing the answer, you can write
     "RESUME(FIRST_FIELD);"

     If you want to put in extra data collection, reliability test
     etc. then you define subclasses to the class field.

     Four such useful subclasses are already available in the FORM
     package.  They are INTFIELD, REALFIELD, CHOICEFIELD, ALPHA-
     FIELD.  INTFIELD is for collecting integer input, REALFIELD for
     collection floating point input, CHOICEFIELD for inputting data
     which can only have a limited set of values, ALPHAFIELD for
     inputting alphabetic data.


CLASS field(h, v, header, length, stopchar, helptext);
     VALUE header;
     INTEGER h, v, length;  CHARACTER stopchar;  TEXT header;
     COMMENT H and V are the horizontal and vertical position on the
     screen for this field.  HEADER is the text to be displayed on
     the screen in front of the field.
     LENGTH is the maximum length of the accepted input text for
     this field, and STOPCHAR is a character which ends a message.
     By making STOPCHAR into CHAR(0), only terminal control
     characters or exceeded length can end a message.  By making
     STOPCHAR into ' ', a message is automatically ended with the
     first blank preceded by non-blanks.
     Helptext is a help message of maximum one line, which is
     displayed to the user if he types a questionmark (?) on his
     terminal.
     BEGIN TEXT answer; COMMENT what the user inputs comes here;
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 21
8. FORM - A SUBPACKAGE FOR FORM-FILL-IN DATA ENTRY


     PROCEDURE change_answer(new_answer);
          VALUE new_answer;  TEXT new_answer;
          COMMENT will change both the internal and
          screen-displayed answer.  Can be used for automatic
          correction of input values.


     PROCEDURE error(errmess);
          VALUE errmess;  TEXT errmess;
          COMMENT will write a blinking error message on line 18 of
          the screen;

     END of field;


field CLASS intfield(min, max, rangerror);
     VALUE rangeerror;
     INTEGER min, max;  TEXT rangeerror;
     COMMENT if the data input by the user is not an integer, then
     he is given an error message.  If the data is not between min
     and max, then the error message RANGERROR is given to him.
     BEGIN INTEGER intvalue;
     COMMENT INTVALUE will contain the data input by the user;
     END of intfield;


field CLASS realfield(min,max,rangerror);
     VALUE rangerror;
     REAL min, max;  TEXT rangerror;
     COMMENT same as INTFIELD for floating point input;
     BEGIN REAL realvalue;
     COMMENT realvalue will contain the data input by the user;
     END of realfield;


field CLASS choicefield(nonemessage);
     VALUE nonemessage;  TEXT nonemessage;
     COMMENT Will allow the user to chose between a limited number
     of alternatives;
     BEGIN
     CLASS choice(choicetext);
     VALUE choicetext;  TEXT choicetext;
     COMMENT you must yourself generate an object of the class
     choice for each alternative, e.g. "NEW choice("first
     alternative");  NEW choice("Second alternative");" etc.
     END of choicefield;
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 22
8. FORM - A SUBPACKAGE FOR FORM-FILL-IN DATA ENTRY


field CLASS alphafield;  COMMENT will only accept input containing
     nothing but letters and blanks;


PROCEDURE show_page;
     COMMENT All answers in all the fields will be erased and the
     form will be displayed on the terminal;


PROCEDURE ask_page;
     COMMENT the terminal user is asked to fill in the form on his
     terminal;


PROCEDURE stopasking;
     COMMENT this procedure causes the procedure ASK_PAGE to return
     from where it was called.  Can be used if you under certain
     conditions wish to allow partly filled-in forms;


     A complete example of a simple program using the FORM package:

     OPTIONS(/l);
     BEGIN
       EXTERNAL TEXT PROCEDURE frontstrip, upcase;
       EXTERNAL CHARACTER PROCEDURE insinglechar, fetchar;
       EXTERNAL PROCEDURE depchar, forceout, outstring;
       EXTERNAL INTEGER PROCEDURE trmop, gettab, checkreal,
       checkint, iondx;
       EXTERNAL PROCEDURE echo, abort, outchr, outche;
       EXTERNAL TEXT PROCEDURE tmpin, scanto, storbokstav, maketext;
       EXTERNAL BOOLEAN PROCEDURE meny, tmpout;
       EXTERNAL CLASS vista, termty;
       EXTERNAL CLASS form;
       form(79,19,sysin,sysout,FALSE,0,NOTEXT,NOTEXT) BEGIN
         REF (field) givenname, surname, nationality,
         birthyear, eyes;
         REF (intfield) height;
         givenname:- NEW alphafield(0,6,"given names:",60,char(0),"");
         surname:- NEW alphafield(0,8,"surname:",22,char(0),"");
         nationality:- NEW alphafield(35,8,
         "nationality:",10,' ',"");
         birthyear:- NEW intfield(0,10,"birthyear:",20,' ',"",1800,
         1975, "Birthyear should be between 1800 and 1975.");
         INSPECT NEW choicefield(35,10,"eyecolour:",10,' ',"",
         "Accepted eyecolours: brown, blue and grey.") DO
         BEGIN
           eyes:- THIS choicefield;
           NEW choice("brown"); NEW choice("blue");
           NEW choice("grey");
         END;
         blank_the_screen;
         outtext("INPUT OF PERSONAL DATA:");
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 23
8. FORM - A SUBPACKAGE FOR FORM-FILL-IN DATA ENTRY


         outimage;
         show_page;
         ask_page;
       END;
     END;


WRITING YOUR OWN SUBCLASSES TO FIELD:

     If you want to do your own validity checking of data input
     from the user, or your own automatic correction of data input
     from the user, then you write your own subclasses to FIELD.
     Include in the body of the subclass the error corrections you
     want.  If you want to display an error message to the user,
     then call the procedure "ERROR".  If you want to change the
     data input from the user, then call the procedure
     "CHANGE_ANSWER".

     By writing your own version of the virtual procedure HELP in
     the class FIELD, you can determine yourself what shall happen
     when the user inputs a questionmark (?) on his terminal.


Example of how you can write your own subclass to field:

     intfield CLASS evenmod10;
     COMMENT will give errors for odd numbers and
     take any input number modulo 10;
     BEGIN
       IF mod(intvalue,
       2) NE 0 THEN error("Odd number illegal.");
       answer.setpos(1);
       answer.putint(mod(intvalue,2),1);
       change_answer(answer.sub(1,1));
     END;

     FORM.REL and FORM.ATR are at the QZ computing center available in
     SYS:LIBSIM. Source file can be found on the FOA:area. FOA:LIBSIM
     may contain a newer version of the REL and ATR files.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 24


9. FORMT AND TABLE - EXAMPLES OF USE OF THE FORM PACKAGE

     FORMT and TABLE are two simple demonstration programs.  FORMT
     shows the use of FORM for input of a simple form from a
     terminal.  TABLE shows how a table of values can be input from
     a terminal in a similar manner.

     FORMT.SAV and TABLE.SAV are available for running at the QZ
     computing center on [106,346] and you can test it by writing

     .RUN FORMT[106,346] or

     .RUN TABLE[106,346]

     FORMT.SIM and TABLE.SIM are available at the QZ computing
     center on DSKE:[13,134,SIMDEM].


10. DEBUGGING PROGRAMS USING THE VISTA PACKAGE

     VISTA programs are difficult to debug for two reasons:

   > DEBUG output will destroy the picture on the screen.

   > VISTA usually stops echoing characters from the terminal,
     which means that characters input to SIMDDT will not be
     echoed.

     Here are some ways to overcome these problems:

     You can direct the debugging output to another device than the
     terminal, for example to another terminal or to a disk file.

     A good way to DEBUG programs using the VISTA package is to use
     the controlling terminal for SIMDDT and a second terminal for
     the VISTA package.  Add the following code to your program:
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 25
10. DEBUGGING PROGRAMS USING THE VISTA PACKAGE


       REF (infile) newsysin;
       REF (printfile) newsysout);
       IF debug THEN
       BEGIN
         newsysin:- NEW infile("sysin *");
         newsysout:- NEW printfile("sysout *");
         newsysin.open(blanks(80));
         newsysout.open(blanks(80));
       END ELSE
       BEGIN
         newsysin:- sysin; newsysout:- sysout;
       END;
       INSPECT NEW vista(width,maxheight,
       newsysin,newsysout,
       NOT debug,terminaltype,NOTEXT,NOTEXT) DO

     After a debugging session, you can restore the screen by
     calling the procedure restore_the_whole_screen.  There are two
     ways to get the VISTA package to call this procedure.  One way
     is to write the SIMDDT statement "INPUT BADSCREEN:= TRUE".
     The next time a call is made on the procedure
     "MOVE_THE_CURSOR_TO" the screen will be restored.

     Another way is push the ALTMODE(ESCAPE) or FORMFEED (=^L)
     character on your terminal, the next time when your program
     tries to make input from the terminal using the input
     procedures within VISTA.  This will also cause the screen to
     be restored.  (On VT52 terminals, ALTMODE must be pushed
     twice.)

     The problem that SIMDDT does not echo its input can be
     overcome by changing the switch on your terminal to local
     echo.  Do not forget to set it back to no local echo before
     typing the SIMDDT "PROCEED" command.

     Another way to know what you have typed to SIMDDT is to push
     the CTRL-R combination on your terminal.

     COMMON CAUSES OF ERROR:

     The most common cause of bad picture on the screen is that
     your program tries to make some kind of input from or output
     to the terminal screen without using the input and output
     procedures which are part of the VISTA package.  Your program
     may for example contain statements like "INSPECT SYSOUT DO" or
     "SYSOUT.SETPOS(0)" or "SYSOUT.OUTIMAGE".

     Another common trouble is that you are accepting input from
     the user on the last line of the screen.  This may in certain
     cases cause the picture on the terminal screen to roll.

     If you are using a DEC VT52 terminal, then a common cause of
     error is that the monitor is doing some kind of character
     conversion when transferring characters from the your program
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 26
10. DEBUGGING PROGRAMS USING THE VISTA PACKAGE


     to the terminal.  Since ordinary characters are used as screen
     addresses, this will cause screen addressing to go wild.
     Example:  At the QZ computing center in Stockholm, the .TTY QZ
     setting will cause this kind of problem, but the VISTA package
     has been modified to handle the TTY QZ problem by TRMOP-ing
     away the conversion before direct cursor addressing is done.

     If you have this problem, use positive terminal numbers to
     disable direct cursor addressing or modify the VISTA program
     package in a way similar to the modification to cope with the
     TTY QZ problem which is already done in the program.

     11. MODIFYING THE VISTA PACKAGE FOR A NEW KIND OF TERMINAL

     The simplest way to make the VISTA package usable on a new
     kind of terminal is either

   > let the terminal type number in the NEW VISTA statement be 0,
     and let the user at his terminal input his terminal
     specifications, or

   > use the two last parameters in the NEW VISTA statement to give
     the terminal characteristics.  The next two last parameter
     should include a text with the name of the terminal.  The last
     parameter should include a text containing in sequence the
     character codes to move the cursor down, up, right, left, home
     and to erase (clear) the screen of the terminal.


     If, however, you want to change the VISTA source program to
     permanently include a new terminal, then read the following
     text.  This may be necessary to get VISTA working on certain
     terminals, and this is also the only way to be able to handle
     blinking text on new kinds of terminals.


     The VISTA package will not work on terminals on which there are
     no character codes to be sent from the computer to the terminal
     to move the cursor down, up, right, left, to home the
     cursor(move it to the upper or lower left corner of the screen)
     and to erase (clear) the screen (either the whole screen or the
     part of the screen following the cursor position will do, since
     the VISTA package always outputs the home character before the
     erasescreen character.)


     You should adjust the following sections of the source code in
     the SIMULA source code of the VISTA package:
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 27
11. MODIFYING THE VISTA PACKAGE FOR A NEW KIND OF TERMINAL


     In the NOT HIDDEN PROTECTED and INTEGER declarations of the
     variables "infoton, vt52, minitec, elite, kthelite, newelite,
     kthnewelite" in the preamble of the source code, add an INTEGER
     for your new kind of terminal.

     In the "PROCEDURE start_blink" you should adjust depending on
     how your terminal works.  INFOTON VISTA has a special character
     on the screen, and everything after this character is blinking
     upto a stopblink character on the screen.  Most other
     terminalsi (e.g.  MINITEC) have a special character sent from
     the computer before outputting blinking text and before
     outputting steady text again.  Follow the example in the code
     for these terminals.

     In the "PROCEDURE stop_blink", corresponding change to the
     change in "start_blink".

     In the "PROCEDURE move_the_cursor_to", insert special code for
     Direct Cursor Adressing if your terminal has this feature.
     Follow the examples of previously known terminals.

     Add your terminaltype to the meny in the separately compiled
     class "termty" used by vista to check which terminal type the
     user has.

     In VISTA, INTEGER variables infoton, vt52, minitec, elite,
     kthelite, newelite, kthnewelite are given initial distinct
     values.  Assign new distinct values to your new kind of
     terminal, corresponding to its position in the "termty" meny.

     IF your terminal cannot handle ".TTY FILL 0", then change this
     "trmop" to the acceptable setting.  Warning:  Only .TTY FILL 0
     will work on terminals with a built-in "auto-lf" function for
     carriage returns from the computer.

     In the menu "Input terminal type..." add your new terminals.

     In the special code to initialize variables for different kinds
     of terminals (beginning with the text
     "COMMENT Infoton Vista Standard") initialize the variables
     down, up, right, left, home and erasescreen to the
     corresponding character codes on your terminal.  If any of
     these six character codes must be preceded by the escape
     character, then set the Boolean variable "addaltmode" to TRUE.
     IF all except down and left must be preceded by altmode, then
     also make "halfaltmode" true in addition to "addaltmode".
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 28
11. MODIFYING THE VISTA PACKAGE FOR A NEW KIND OF TERMINAL


     Also initialize the variables startblink and stopblink if
     there are such character codes on your terminal.


     If your terminals has a built-in "auto-lf" function (that is
     that every carriage return from the computer causes an
     implicit line feed to be generated in the terminal, then you
     will have to set the Boolean variable "allow_cr" to FALSE.
     Otherwise, make this variable TRUE, since this gives much
     faster execution and less i/o.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 29
Appendix A: NEW FEATURES IN VISTA RELEASE 1976-11-05.

MINIMAL NECESSARY CHANGES TO GET OLD PROGRAM WORKING WITH THE NEW
     PACKAGE

  1) Change "EXTERNAL INTEGER PROCEDURE trmop" into "EXTERNAL INTEGER
     PROCEDURE trmop, gettab" in the preamble of your program.  Also
     change "EXTERNAL CHARACTER PROCEDURE getch" into "EXTERNAL CHAR-
     ACTER PROCEDURE getch, fetchar" and add "EXTERNAL PROCEDURE
     depchar, forceout, outstring;".

  2) There are two new TEXT parameters to the CLASS VISTA.  Thus, for
     every "NEW VISTA" or "NEW FORM" statement in your program, you
     must add ",NOTEXT,NOTEXT" immediately in front of the ")".

     If you have written your own subclasses to the classes VISTA or
     FORM, corresponding changes must be made in NEW statements
     generating your subclasses.

  3) Only for users of the class FORM:  There is one new TEXT
     parameter to the class FIELD (and its subclasses).  The new
     parameter can be given the value NOTEXT in "NEW field", "NEW
     alphafield" etc.  statements in your program.

  4) All program modules using the VISTA package must be recompiled.

NEW FEATURES IN THE VISTA PACKAGE

  1) The package is much more independent of terminal make.  It works
     on INFOTON VISTA, DEC VT52, MINITEC and DATAMEDIA ELITE 2500 and
     1520 terminals.  It will also work on many other kinds of display
     terminals, since the program can query the user about his
     terminal characteristics.  With the pushing of just 7 keys on the
     terminal, the user can tell the program how his terminal works,
     and the program can then work on almost any terminal having
     special functions for moving the cursor around the screen.

  2) The two new text parameters to the class VISTA can be used by a
     user programmer to describe the characteristics of his special
     kind of display terminal.

  3) The new parameter to objects of the class FIELD in the FORM
     package is a help text, which is displayed automatically to the
     user when he types in a questionmark on his terminal.  By writing
     your own version of the virtual procedure HELP in the FIELD
     class, you can handle help texts longer than one line or other
     special help facilities.

  4) To get machine-independent handling of blinking text on the
     screen, two new procedures start_blink and stop_blink have been
     added.  Always use these procedures to create blinking text.  See
     the manual for further explanations.  Whenever you call
     start_blink, the bell will also be sounded on terminals which
     have a bell function.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 30
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED

Swedish National Defense Research Institute        FOA Rapport
S-104 50 Stockholm 80                              C 10075-M3(E5, H9)
Sweden                                             September 1977


                                       (1)
HOW I FOUGHT WITH HARDWARE AND SOFTWARE    AND SUCCEEDED

By Jacob Palme


(1) DEC, INFOTON, TEC, TANDBERG, CDC, DATAMEDIA, BEEHIVE, SIMULA


ABSTRACT:

     This is the story of the development of a utility program to
     simplify the writing of programs using alphanumeric display
     terminals.

     The basic program is very simple, and most of the programming
     time was not spent on this, but in a cloak-and-dagger game with
     other hardware and software products involved, trying to induce
     or cheat these products into doing what was needed, and not
     perform various unwanted and disruptive "niceties".


SEARCH KEY:

     Computer, Program, Computer program, Programming, Computer
     Programming, Software, Software development, Software
     engineering, Terminal, Computer terminal, Conversational
     terminal, Display terminal, CRT terminal, Alpha-numeric
     terminal, Cursor control, Man-Computer interaction.


SWEDISH ABSTRACT:

     Detta {r historien om programmeringen av ett hj{lpprogram f`r
     att underl{tta skrivandet av program som anv{nder sig av
     textsk{rmsterminaler.

     Det grundl{ggande programmet {r mycket enkelt, och huvuddelen
     av programmeringsarbetet {gnades inte }t det, utan }t en
     gerillakamp med annan maskinvara och programvara som var
     inblandad, f`r att f`rm} eller lura dessa produkter att g`ra
     vad som beh`vdes, och inte utf`ra skilda icke `nskade och
     skadliga "v{nligheter".
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 31
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


0. TABLE OF CONTENTS.

     1.  WHAT IS THIS?
     2.  HOW IT ALL STARTED.
     3.  MYSTERY: SUDDEN UNEXPECTED CURSOR MOVEMENTS.
     4.  MYSTERY: SUDDEN SMALL SHIFTS IN THE PICTURE.
     5.  INPUTTING OF CONTROL CODES FROM THE TERMINAL.
     6.  TRYING OTHER TERMINAL MODELS.
     7.  BLINKING TEXT AND BELL FUNCTION.
     8.  THE HORIZONTAL TAB CHARACTER CODE.
     9.  AUTO LINE FEED FEATURE.
     10. BLOCK MODE TERMINALS.
     11. DIRECT CURSOR ADRESSING.
     12. THE TYPE AHEAD PROBLEM.
     13. PROGRAM OPTIMIZATION.
     14. CONCLUSION.
     15. BIBLIOGRAPHY.


1. WHAT IS THIS?

     This report is the story of the development of a computer
     program. The goal is not to tell you about technical details of
     the program or application. Rather, the goal is to tell you
     about the problems I met, and how I overcame them. Central to
     these problems were the interface between my program and
     hardware and software modules produced by various
     manufacturers.

     This is not a paper about the beautifully logical development
     of a program through perfect applications of structured
     programming techniques. But it is a true story. I made many
     mistakes through ignorance, and I intend to admit them candidly
     in this report.

     My hope is that many programmers will recognize that they have
     met similar problems. This recognition may help to give a
     better understanding of the role of existing hardware and
     software in program development.

     This report will name the manufacturers and software and
     hardware products involved. Problems associated with them will
     be mentioned. This should  n o t  be construed as meaning that
     these named manufacturers and products are especially bad. My
     experience is the opposite, that the named products are very
     good compared to some other similar products. The fact that I
     tested them indicates that they were common in my work
     environment.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 32
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


2. HOW IT ALL STARTED.

     In 1973, we got our DECsystem-10 computer together with a
     number of Infoton VISTA alphanumeric display screens. These
     screens had 20 lines of 80 characters per line.

     The terminal has a so-called "cursor", which indicates the
     position on the screen where forthcoming text will be placed.
     The terminal can receive control codes from the computer to
     move the cursor around the screen. When new text is inserted at
     the cursor position, previous text at that position will be
     erased.

     On the Infoton VISTA, the cursor can be moved through controls
     to move it up one line, down one line, left one character and
     right one character. There are also codes to move the cursor to
     the upper left corner of the screen (the "home" position on
     most terminals) with or without simultaneous blanking of the
     screen.

     This terminal is typical of many other terminals, with small
     technical differences. (See further Palme 1977B.)

     By moving the cursor around the screen, erasing and replacing
     existing portions of the screen, many nice applications are
     possible. You can have a table on the screen, where the user
     and the computer can continously update entries in the table.
     You can create a "moving picture" on the screen etc. This is
     further described in Palme 1977A.

     To simplify the writing of various application programs using
     this technique, a useful utility package would take commands
     from the application program to move the cursor to given
     positions on the screen, input or output data at that place
     etc. I began to write such a utility package.

     The basic principle of such a package is very simple. To move
     the cursor to a given position, the program generates the
     proper number of up, down, left, right or home codes to get
     there. The program need not be very long or complex.


3. MYSTERY: SUDDEN UNEXPECTED CURSOR MOVEMENTS.

     My first problem was that the cursor suddenly moved to the
     beginning of the next line on the screen. This happened now and
     then in the middle of the execution, with disastrous results to
     the screen picture.

     I simply could not understand why the cursor moved in this way.
     But after some time I found the cause. The DECsystem-10
     operating system has a built-in facility to protect users from
     outputting too long lines. Thus, the operating system keeps a
     count of on which horizontal position it believes the writing
     position to be. When this count becomes larger than the line
     length of the terminal, the operating system outputs a carriage
     return and a line feed to the terminal.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 33
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     Thus, the operating system just tries to be nice to you. It
     tries to help you out of trouble, if your program by mistake
     outputs too long lines. But of course the operating system does
     not know about the cursor controls on display terminals. So its
     cursor position count will be wrong, and the carriage return-
     line feed produced by it will occur at unpredictable times
     destroying the picture.

     My solution to this problem was simple, but not very neat. I
     counted the number of characters being output to the terminal.
     Before this count exceeded 80, I output a carriage return
     myself, and then moved the cursor back again to where my
     program knew it to be.

     In this way I cheated the operating system into believing that
     the cursor never was more than 80 characters from the beginning
     of a line.

     When I had written and tested the code for this solution,
     someone told me "Why don't you just make a TTY NO CRLF". TTY NO
     CRLF is a command which can be given from a user or program to
     switch off the monitor facility which caused my trouble. A
     simple addition of a monitor call to the program, and all the
     newly written code for my ingenious solution could be removed
     from my program!


4. MYSTERY: SUDDEN SMALL SHIFTS IN THE PICTURE.

     My next problem was that suddenly, now and then, the text I
     output was shifted just a little on the screen, one or two
     screen positions, but enough to cause double images, ghost
     pictures and other problems.

     After some time I found the solution. The SIMULA procedures for
     outputting text, "outimage" and "breakoutimage" were programmed
     in such a way that blanks at the end of output lines were never
     output. The SIMULA system thus omitted blanks when these
     happended to be at the end of what SIMULA believed to be output
     lines. (In fact, my applications were based on the idea of not
     outputting whole lines of text at a time. But the SIMULA system
     did not know this.)

     Another case, where a software product, in this case SIMULA,
     tried to be nice to me, with disastrous results.

     I solved the problem, again by cheating the system I was using.
     Before outputting a line, the program always checked if the
     last position to be written was a blank. If so, the program
     changed the output so that the last character to be output was
     a "NULL" character code (this is ignored by the terminal).
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 34
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     Sometime later, other users complained of the same problem, and
     the definition of the "breakoutimage" procedure in SIMULA was
     changed so that the program could indicate if ending blanks
     were to be output (with the "image.pos" setting). This was a
     much neater solution, and again I could remove some code which
     I had inserted to cheat the system. How happy I felt when, for
     the second time, I removed code which I had spent a lot of time
     inventing.


5. INPUTTING OF CONTROL CODES FROM THE TERMINAL.

     All 128 codes in the ISO-ASCII character set are not printable.
     Therefore, when you push a terminal key which causes the
     terminal to send a non-printable code, this cannot be directly
     printed on the terminal. However, the DECsystem-10 operating
     system again tries to be nice to you. To enable you to see
     these characters, the operating system outputs the character "^"
     followed by another character, so that you can see on your
     screen what has been input. For example, the character with
     numerical value 1 is output as ^A, 2 as ^B etc.

     Exceptions from this are the control codes "carriage return",
     "line feed" and "form feed". But the special terminal control
     codes, such as "up" or "home" are not known to the monitor.

     A similar problem was caused by the DELETE (RUB OUT) and NAK
     (Control-U) characters. To help people correct small typing
     errors, the monitor interpreted these as to take back the last
     character (DELETE) or the last line (NAK). These were thus
     never transmitted to my program, so the program did not know
     that the cursor was not where it believed it to be.

     My first crude solution to this problem was to reserve certain
     lines in the application programs for input from the terminal,
     and to always synchronize the cursor after terminal input. (By
     synchronizing the cursor I mean ensuring that the cursor is
     where the program believes it to be. This is done by moving the
     cursor first to the home position, and then to the desired
     position. On some terminals, direct-cursor-addressing can be
     used instead.)

     However, I was now aware that many times, when the monitor
     caused trouble by being too "nice", the niceties could be
     switched off through various monitor switches. So I went
     through the list of terminal control monitor switches to see if
     there was one I could use. All these switches are set by the
     TRMOP supervisory call, I believed. So I looked through the
     list of options to the TRMOP supervisory call.

     There was one switch which looked nice. TTY NO ECHO it was
     called. Just my problem - switch off echoing of characters.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 35
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     Happily, I tried TTY NO ECHO. It nicely suppressed monitor
     echoing of all printable characters. But - the echoing of
     non-printable characters, which I wanted to suppress, was not
     suppressed.

     The complete information on all the options in the operating
     system can be found in the "DECsystem-10 Software Notebook",
     consisting of eleven very thick volumes and costing about a
     thousand dollars a year to keep.

     Sometime later, I learned that there was an obscure table in
     quite another part of the notebook, indicating a different
     setting, which did just what I wanted. It could either cause
     all input characters to be echoed unchanged by the monitor,
     without any "nice" modifications, or it could suppress all
     echoing even of non-printable characters, so that my program
     could do the echoing instead.

     Why this setting was not part of the TRMOP supervisory call,
     which handles other switches controlling terminal handling, is
     a mystery to me.


6. TRYING OTHER TERMINAL MODELS.

     Now came the time when I wanted to run my programs on terminals
     of other makes than the INFOTON VISTA terminal. I happily ran
     my programs, and a curious mixture of jumbled characters
     appeared on the screen.

     Apparently, the control codes to move the cursor up, down,
     left, right and to the home position, and to erase the screen,
     are not standardized. I found out that even two different
     models from the same manufacturer often have different control
     codes! (This is true for example for some DEC, TEC and ELITE
     terminals.)

     This means that every program must be different for each
     terminal model. A way to alleviate this problem would be if all
     terminal differences could be collected into my utility
     package, so that no modifications would be necessary in the
     application packages.

     I have tried to achieve this goal, but the terminal differences
     are so cleverly devious that I have not always succeded. As
     one of many examples of curious terminal behaviour, the line
     feed character on the TANDBERG TDV 2000 terminal blanks the
     rest of the next line on the screen.

     There are other subtle differences between terminal types. For
     example, what should happen if you send an "up" character on
     the first line of the screen, a "down" character on the last
     line, a "left" character at the beginning of a line or a
     "right" or any printable character at the end of a line.

     Some terminals do nothing in these cases, other terminals "wrap
     around" to the other end of the screen.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 36
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     On some terminals, the control codes to move the cursor are
     one-character codes. On other terminals, they are two character
     codes, first the ESCAPE character, and then a second character.
     (The latter practice is more in accordance with the standard
     for those controls which do not have single character
     representations in the standard.)

     This is mostly a problem when inputting these codes from the
     terminal. To get the application programs totally independent
     of terminal type, these programs cannot themselves check if the
     input character was e.g. an "up". This checking must be done
     indirectly through the utility package, which requires a change
     in all existing application programs. (And you know how happy
     application programmers are when changes in utility packages
     they use force them to change their application programs. I
     have not yet dared to make this change!) But application
     programs that wish to be terminal independent can achieve this
     by writing the checking code in this way:
     "IF controlchar AND c = up" instead of just "IF c = up".

     To get terminal independence, I invented what I thought was a
     very clever solution. I let the characters go through a
     conversion table, so that only the conversion table need be
     different for different terminal models.

     Later I skipped the conversion table, since I found during
     optimization that direct code was much faster.


7. BLINKING TEXT AND BELL FUNCTION.

     Some terminals allow you to mark special sections on the screen
     by blinking text. Many terminals allow you to send the bell
     character, which causes a beep at the terminal to catch the
     attention of the terminal user.

     Since the purposes of both are similar, and some terminals have
     one of these features, some the other, I made a single "alarm"
     procedure which sent both the bell character and the blink
     control depending on terminal model. In this way most
     application programs will be more terminal independent.

     However, the logic of the blink control was different in a
     devious way. On some terminals, all characters  s e n t  to the
     terminal between "start blink" and "stop blink" are blinking.
     On other terminals, all characters  p o s i t i o n e d
     between "start blink" and "stop blink" on the screen are
     blinking.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 37
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     My package does not yet enforce complete terminal independence
     here. Application programmers who desire terminal independence
     can get it by ensuring that they call "start blink" before each
     element of text to blink, and "stop blink" after each such
     element.


8. THE HORIZONTAL TAB CHARACTER CODE.

     One character code causing much trouble is the HT or
     "horizontal tab" code. On some terminals, this character code
     is ignored. On other terminals, the cursor moves to fixed tab
     positions. On still other terminals, the cursor moves to
     settable tab positions. The worst terminal is MINITEC, where
     the cursor moves to the next settable tab position on the whole
     screen, and scrolls the screen if there is no such position.

     Thus, on MINITEC, I had two possibilities. One was to let my
     program set 240 tab positions all over the screen, the other
     was a monitor switch to control the echoing of the HT character
     code (TTY NO TAB).

     This monitor switch causes the monitor not to send or echo any
     HT characters to the terminal. Unfortunately, the monitor
     instead moves to where it believes the next tab position to be,
     using blanks to get there and thus erasing part of the screen.
     Therefore, after each HT I have to let my program correct the
     wounds which the monitor has caused on the screen.


9. AUTO LINE FEED FEATURE.

     The standardized character set does not include any character
     to do what the RETURN key does on type-writers: move to the
     first position of the next line. The carriage return code only
     moves to the first position of the current line.

     Thus, an extra line feed has to added. Sometimes this line feed
     is added by the computer, sometimes by the terminal, just to
     make things more difficult.

     A connected problem is that some terminals (mostly printing
     terminals) cannot perform carriage return and line feed as fast
     as other functions. The DECsystem-10 operating system solves
     this problem by repeating a received carriage return character
     several times.

     If the terminal adds a line feed to each such extra carriage
     return character, then the screen will begin to scroll because
     of all the line feeds, and the picture is destroyed. Happily,
     there is a supervisory call to set off also this nicety of the
     operating system.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 38
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


     For my application, it is better if the computer does this
     adding of a line feed, since then the action is easier
     controlled by the program than if the addition is done by the
     terminal.


10. BLOCK MODE TERMINALS.

     Some terminals are mainly constructed for block mode
     transmission, where text is edited locally on the terminal and
     then sent as a block to the computer. Some such terminals are
     also marketed for character mode transmission. Beware of such
     terminals. (Example: INFOTON VISTAR II, some models of STANSAAB
     ALFASKOP.)

     On such terminals, cursor control wholly or partially acts only
     locally on the terminal. This is the only problem I have not
     been able to overcome at all. My package cannot be made to work
     on such terminals at all.


11. DIRECT CURSOR ADDRESSING.

     Some terminals have a so-called "direct-cursor-addressing"
     feature. By this is meant that the computer can send a special
     control code, which tells the terminal that the two next
     characters are not to be printed. Instead, the two next
     characters are to be interpreted as horizontal and vertical
     screen adresses, to move the cursor directly to this position.

     This feature has two advantages. The first is that you are
     always sure where your cursor is after this terminal command.
     The second is that fewer codes have to be sent to the terminal.
     The second advantage is only important for lines slower than
     120 characters/second.

     However, the algoritm to decide which character means which
     screen adress is of course different for each terminal model,
     although BEEHIVE B 100 and DEC VT52 by a curious circumstance
     have happended to chance on the same algorithm.

     Another problem with direct cursor addressing is that some of
     the characters used for screen addressing are characters which
     are reserved for national use in the ISO character set. And
     often, these characters are converted in different ways by
     networks and transmission system, causing jumbled screens
     again.

     This is again a case where the systems try to be nice to you -
     helping to convert between different national character sets -
     but instead causing trouble when the characters are used as
     screen addresses.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 39
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


12. THE TYPE AHEAD PROBLEM.

     The DECsystem-10 computer has a nice feature allowing
     "type-ahead". By this is meant that the terminal user can type
     input before the program has asked for it. This allows advanced
     users to save time by typing while the program is doing things
     for them.

     Unfortunately, this nicety again causes problems for my
     program. The problem is that when the user types characters
     ahead, these are not received by my program when they are
     needed. Thus, the program does not know when and where on the
     screen they will appear.

     One solution to this is to let all characters go through my
     program before echoing them to the screen. This solution has
     the disadvantage that echoing will be rather slow, since at
     rush hour time, the program may only get swapped in every five
     seconds or so.

     In the most advanced of my application programs, this problem
     is circumvented by switching back and forward between program
     and monitor echoing of characters. When the package smells
     trouble, it switches to program echoing. When the package
     smells really bad trouble, it has to restore the whole screen.
     In some cases, the program has to skip existing type ahead to
     avoid this problem.


13. PROGRAM OPTIMIZATION.

     Finally, I found that the CPU time for some of the application
     programs which I and other people had written using the utility
     package was rather long. By performance measurement tools the
     critical sections were identified. It was found that the SIMULA
     procedures for terminal input and output were rather slow.

     For example, the output procedure always blanks the text which
     is output. In this way, the text is cleared for the next line
     to be output. Unfortunately, I want to keep a copy of the
     screen in memory, so I do not want the text to be cleared. To
     avoid unnecessary copying, special output procedures in
     assembly language were written. The CPU time was lowered 25% by
     this single change!
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 40
Appendix B: HOW I FOUGHT WITH HARDWARE AND SOFTWARE AND SUCCEEDED


14. CONCLUSION.

     The conclusion to this story might be: Beware of niceties! My
     story can be seen as a series of cases where I banged my head
     into walls put up by hardware and system designers who just
     wanted to be nice to me. My first problem was to recognize that
     I had banged my head into such a wall. The second problem was
     to find a way to remove or get around the wall. In most cases I
     succeeded.

     The execution of a program on a computer will usually involve
     many different modules. There may be a network, a terminal
     control system, a file handling system, compilers and prog-
     ramming language systems, other operating systems, the app-
     lication program itself, utility software used by it etc. All
     these modules are programmed to perform their own tasks, but
     without full knowledge of the other tasks. And most of the
     modules have various checks to prevent misuse.

     Very often, a module will, because of its lack of knowledge of
     the actual usage, not do what is required. Other modules using
     it can then in various ways correct or circumvent this. In the
     worst case, we will have a series of modules not helping each
     other, but doing and undoing and circumventing and cheating the
     actions of each other. In my case, the mayor task of the prog-
     rammer was not to solve the basic programming task, which was
     rather simple, but rather to be successful in this new kind of
     cloak-and-dagger game. Programming has then become quite a new
     kind of art!


15. BIBLIOGRAPHY

Digital Equipment Corporation: DECsystem-10 Software Notebook.
     (eleven volumes.)

DECsystem-10 SIMULA Language Handbook, part I, II and III.

Palme, Jacob 1976: VISTA - For Full Control of Text Display
     Terminals. To be submitted to the DECUS program library.

Palme, Jacob 1977A: Moving Pictures Show Simulation to User. FOA 1
     Report C 10068, April 1977. (A presentation of the uses of the
     program, the development of which you have just read about.)

Palme, Jacob 1977B: Conversational Computer Terminals. FOA 1 Report
     C 10074, August 1977.

Technical user's manuals for the following terminal models: Infoton
     Vista, Infoton Vistar II, Infoton Vistar Sattelite, Tandberg
     TDV 2000, Minitec, Teletec, Elite 1520, Elite 2520, Beehive
     B100, CDC 713-10 (published by the terminal manufacturers).
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 41
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER



ABSTRACT

     One of the most difficult problems with a simulation program is
     to gain confidence in the accurateness and reliability of the
     model. If the program is to be used for important decisions,
     the decision makers must feel sure that they can depend on the
     model. To do this, they have to understand what is happening in
     the program.

     One way of making the users of the simulation more sure about
     what is happening in the program is to show what is happening
     during a simulation as a "moving picture" on a terminal. This
     can easily be done on a simple standard alphanumeric display
     terminal.

     Our experience is that the extra programming effort is small
     and that the gain in understanding of the model is high both
     for the programmer himself and for other users.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 42
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

METHODOLOGY

     An ordinary simple alphanumeric terminal is used. There must be
     codes which can be sent from the computer to the terminal to
     move the cursor (writing position) around the screen. Most
     terminals have such codes.

     A picture is designed for the terminal which shows what is
     happening during the simulation. The terminal screen can be
     divided into several areas, containing tables, written text and
     simplified pictorial information.

     During the simulation, all information on the screen is
     continually kept updated, so that the screen at each instant
     shows the status of the simulation at that time.

     The user can start and stop the simulation instantly by
     inputting CONTROL-S (=STOP) and CONTROL-Q (=CONTINUE) from his
     terminal.

     Some application programs also allow the user to take part in
     the simulation from his terminal. Sometimes, a special area on
     the terminal screen is reserved for interaction with the user.


PROGRAMMING

     A package of utility routines is included in a separately
     compiled CLASS, itself almost entirely written in the
     programming language SIMULA on a DECsystem-10/20 computer. This
     package will simplify the addition of moving-picture output
     to a simulation program.

     Unfortunately, the codes to move the cursor are not the same
     for all kinds of terminals. However, the package recognizes
     eight wellknown terminal types, and will work for most other
     terminals after inputting a simple input sequence from the
     user. The package can easily be modified for new terminal
     makes.

     The programmer writes on the screen by using a few simple
     procedures. Examples of these are "move_the_cursor_to(i,j)"
     which moves the cursor to a certain position on the screen, and
     commands to output a character, a number or a text beginning at
     the current cursor position on the screen.

     To cause an object on the screen to "move" geographically, you
     erase it in its previous position and write it anew at the new
     position. This is done so fast that the terminal user percieves
     it as fluid motion.

     A value which changes with time moves by rewriting it with new
     values at the same place of the screen whenever the value is
     changed or at constant time intervals.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 43
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

     The program also allows switching between several pictures
     (controlled by the program or the user) on the same terminal or
     outputting pictures on several terminal screens simultaneously.

     Our experience is that to add "moving picture" output to an
     existing simulation program does not have to require more than
     about 5 days of work.


APPLICATIONS

     The package has been used for several simulation programs.

     These include:

   - A simulation of ships transporting troups across a lake, with
     enemy destroyers combatting the troup transport ships

   - A simulation of a military aerodrome, showing the position of
     the aircraft and the effect of bombing on the aerodrome

   - A simulation of icebreaker operations in the northern part of
     the Baltic. The positions of icebreakers and ships requiring
     assistance is shown on a simplified map on the screen

   - Several game programs in which the user interacts with the
     simulation. One cat-and-mouse game, one football-type game with
     two simultaneously used terminals, one for each side, and one
     chess game.

   - Nonsimulation applications, for example a budgeting
     application in which the budget table is shown on the screen, the
     user being able to change and to input data to the table, and all
     the sums in the table are updated every time the user changes a
     number on the screen.

   - A text editor based on the idea that the terminal screen always
     shows exactly the text being updated. The effect of each
     editing operation directly changes the text shown on the
     screen.

EXPERIENCE

     Our experience is that this is a very powerful way of making it
     easier for people to understand what is happening in a
     simulation model.

     In a very short time, users understand enough to ask question
     they could not ask before, like:

     Why is that aeroplane so seldom attacked?

     That ice-breaker seems to get hung at that port. Why?

     Faults in the simulation models show up very clearly as curious
     or inconsistent events on the "moving picture screen".
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 44
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

EXAMPLES

     This example shows part of the screen for the ship-and-
     destroyer simulation. To the left is a list of the ships, to
     the right a map of the lake, simplified to a rectangle.

     ----------------------------------------------------------------
     ! SHIP NO 1, SPEED  2.0  !           1                         !
     ! SHIP NO 2, SPEED  4.0  !                 ***   2&            !
     ! SHIP NO 3, KILLED      !                 ***                 !
     ! SHIP NO 4, UNLOADING   !                 ***                4!
     ! SHIP NO 5, UNLOADING   !                                    5!
     ! SHIP NO 6, UNLOADING   !                &                   6!
     ! SHIP NO 7, KILLED      !                                     !
     ! SHIP NO 8, KILLED      !                                     !
     ! SHIP NO 9, SPEED-18.0  !                     9               !
     !---------------------------------------------------------------
          Table of ships                   Map of the lake

     Each digit in the map is the position of a ship. Each "&" is
     the position of a destroyer. The square of asterisks is shown
     for one second each time a ship is sunk by a destroyer.

     The screen also includes (not shown above) an area for
     inputting commands, a clock for simulated time, and areas
     showing troup transport results and a summary table of ship
     states.

     Below is an excerpt from the picture for the icebreaker
     simulation. The arrow indicates a convoy of three ships moving
     upwards on a simplifed map of the Baltic. Ship no. 37 is
     destined for the port of Lule}, ships no. 36 and 38 for the
     port of Pite}.

        '!|   37
         !    36  38
         !

     Below is an excerpt of the airport simulation. The airport is
     divided into several areas where airplanes can be placed, the
     front area, the forest area, the underground shelter area.

     In each area, there are several airplane platforms, and on each
     platform a code indicates the status of the plane. During the
     simulation, the user can see the airplanes move from shelter to
     shelter, see them being bombed and repaired.

     Front:          VU         VU = Sheltered platform under repair
          -       -             VB = Blocked sheltered platform
     Forest:                    A1 = Atack plane no. 1
          -       -             R48 = Will be repaired in 48 hours
          -       -             AJ5, AJ2 = Hunter aircrafts no. 5
          VB      VU            and 2
     Rock:
          V A1 R48   V
     Flying:  AJ5  AJ2
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 45
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

COMPLETE SCREEN SAMPLES

THE TROUP TRANSPORT APPLICATION

                          Here is a pictorial description
                          of the lake, with freighters.          Here you
                          1 = position of ship no 1              can see
Here is     These data    & = position of destroyer              a ^ for each
a table     show the      ***   when a ship is killed,           unloaded
of the      status of     *** = this is shown for one            shipload of
ships.      each ship.    ***   second on the screen             troops
-----------------------------------------------------------------------------
SHIP NO 1, SPEED  2.0  !           1                         !   Troops moved
SHIP NO 2, SPEED  4.0  !                 ***   2&            !   ^
SHIP NO 3, KILLED      !                 ***                 !
SHIP NO 4, UNLOADING   !                 ***                4!
SHIP NO 5, UNLOADING   !                                    5!
SHIP NO 6, UNLOADING   !                &                   6!
SHIP NO 7, KILLED      !                                     !
SHIP NO 8, KILLED      !                                     !
SHIP NO 9, SPEED-18.0  !                     9               !   TIME:  0:05

                 Commands: START new ship                 NO OF SHIPS:
GIVE COMMAND:              DESTROYER start                 9 STARTED
START                      KILL old ship                   0 LOADING
Speed of new ship?         HOLD ship                       2 FORWARD
20                         RANDOM ship speed               3 UNLOADING
                           WAIT delay time                 1 BACKING
                           BEGIN new run                   0 HOLDING
                           <CR> for intetrupt              3 KILLED
                           <FF>(=CONTROL-L) for bad picture
                           CONTROL-S and CONTROL-Q for stop-start
-----------------------------------------------------------------------------
The area above is used to input commands from the       This table (above)
terminal and give error messages for unacceptable       shows the number of
input data.                                             ships each of various
                                                        states.

In this example, the user can input commands in the lower left
part of the screen, and a short list of the available commands is
shown on the screen. <CR> is short for the carriage-return key,
<FF> for the form-feed key, CONTROL for the CONTROL key on the
user terminal.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 46
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

THE ICEBREAKER SIMULATION

(Programmed by @rjan Leringe)

Har-     Each number represents a freighter
bours    * indicates a freighter ready-to-go                 Clock
-------------------------------------------------------------------
Lule}    30*                                                 12 23

Pite}    31* 34

Skell    26* 32*

        '!|   33  35
         !
         !

                                       !    28
                                       !    29  27
                                      |!'

        '!|   37
         !    36  38
         !
Holm`
Gadd     39  40
--------------------------------------------------------------------

Freighters arrive at Holm` Gadd and wait for asistance in
entering one of the northern harbours. After loading or
unloading they need assistance back to Holm` Gadd, where they
vanish from the screen.

The large arrows represent convoys of freighters, assisted by
an icebreaker, moving through the ice. To the left in the
screen are two icebreakers with convoys moving to the north,
and to the right in the picture is a southbound icebreaker with
convoy.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 47
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

THE MILITARY AERODROME

(Programmed by Lars-$ke Larsson)

                                      Clock and day
---------------------------------------------------------------------
Front:                                          Day      15:45  OP  4
   _              _              _              VU             VBA6
Forest:
   _              _              _ A4   Cl      _ A3   Cl      _
   _              _              _              _              _
   VB             VU             VB             VB             V
Rock:
   V A1   R48     V              V              V
Flying:    AJ5   AJ2
---------------------------------------------------------------------

Planes on front platforms can start immediately after an
alarm.

_ is an unsheltered platform.
V is a sheltered platform.
B is a platform blocked after an attack.
  Example: VBAC is attack-plane number 6 which is blocked in a
  shelter after bombing.
U identifies a platform under repair at time shown (15:45).
A4Cl says that attack plane 4 is cleared from obstructions and
  can be used for attack missions.
R48 is a plane under repair, to be ready in 48 hours.
OP 4 says that there are 4 operative planes on the base at
  time shown.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 48
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

A SIMULATION OF A DOCTOR'S RECEPTION

This simulation can be used to test different algorithms for calling
the patients to a simple doctor's reception. Two receptions are run
simultaneously in time, to clearly show the user the difference
between the two algorithms used.

The screen shows pictures of the waiting room and the doctor's
office, with letters abcd for the patients. You can actually see
patients arrive at the reception through the entrance door, find an
empty seat, wait, go into the doctor's office, wait there for the
treatment time and then exit through the back door.

SCREEN EXAMPLE                             COMMENTS

Simmulated time  8:17                      These parameters are input
Open time 8.00      Close time 12:00       when running the program.
Mean treatment time 15 min/patient         The "FORM" package is used
  10  min  Arrival interval 20  min        for data entry from the
  25   Number of pat. called   25          terminal.
   1   Number of pat. at open  13
-------   -------   ------- n -------      Patient n is just coming.
!b              !   !jbcdef   ghiklm!      Patients waiting in the
!               !   !               !      waitingroom.
!               !   !               !
------- a -------   -------   -------      Left: Patient to the doctor.
! *O            !   ! *O  a         !      Right: Patient in doctor's
-------   -------   -------   -------      office.
Value of doctor's time:  100  $/hour       Parameters input by the
Value of patient's time: 70   $/hour       user when running the program.
    $    min  Wait time    min     $
     0     0   Doctor        0      0      Continously updated statistics
     0     0  Patients      10    700      during the execution of
-------------------------------------      the program.
     0     0     Sum        10    700
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 49
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

A CHESS GAME

(Programmed by Mats Wallin)

         -----------------------------------------
      8  ! :: !    ! :: !    ! :: !    ! :: !    !
         -----------------------------------------
      7  !    ! :: !    ! :: !    ! :: !    ! :: !
         -----------------------------------------
      6  ! :: !    ! :: !    ! :: !    ! :: !    !   Ra6-a4
         -----------------------------------------   Your move:  b3
      5  !    ! :: !    ! BK !    ! :: !    ! :: !
         -----------------------------------------
      4  ! WR !    ! :: !    ! :: !    ! :: !    !
         -----------------------------------------
      3  !    ! :: !    ! :: !    ! :: !    ! :: !
         -----------------------------------------
      2  ! :: !    ! :: !    ! :: !    ! :: !    !
         -----------------------------------------
      1  ! WK ! :: !    ! :: !    ! :: !    ! :: !
         -----------------------------------------
            a    b    c    d    e    f    g    h

Many chess programs have been written. The TORN program can at
present only handle a special kind of end game. The interesting
part is that the program illustrates
a) How a user can play a part in the simulation,
b) How the chess board can be displayed on the screen and
updated with each move.

BK = Black king
WK = White king
WR = White rook

Ra6-a4 = Computer move, rook from square a6 to square a4.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 50
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

A SIMPLIFIED FOOTBALL GAME


         HSPEED:  1   VSPEED:  1
             -------------
             !           !
   GOAL 1    !           !    GOAL 2
                  1 o
                       2

             !           !
             !           !
             -------------
                0 -  1

This very simple program will just illustrate a combination of
the DECsystem-10 SIMULA Real Time package with the display
package. The simulation contains three processes, one for the
ball and one for each of two players.

Codes in the picture: 1 and 2 are the two players, o is the
ball.

Two users can run the program simultaneously, at two different
terminals. Each terminal shows the same picture. Each user can,
whenever he wants, input commands on his terminal to move the
player controlled by him. There are keys on the terminal for
moving the player up, down, left and right.

Note that there is no requirement that every second move should
be made by one and every other second move by the other player.
Both can make moves as fast as they wish. The program handles
the commands in the order in which they are typed by the users.

This is only a test program to show that it works. No real
application has yet used this combination of the real time
package and the display package.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 51
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

TABLE FILL-IN BUDGETING

The screen shows a table. The user can input data to the fields in
the table in arbitrary order, and change previous data at wish. The
totals are updated for every new or changed field value. The user
can thus adjust the table to a desired total by succesively
modifying the individual field values.

------------------------------------------------------------------
 TABLE FILL-IN DEMONSTRATION EXAMPLE:            (Type ? for HELP)

 Type of        Number of   Price per       Total
 unit           units       unit            price

 Chairs            35       123.00 Kr      4305.00 Kr
 Tables             4       789.00 Kr      3156.00 Kr
 Lamps              7       134.00 Kr       938.00 Kr
 Curtains           6       five
 Beds              35       456.00 Kr     15960.00 Kr

 ----------------------------------------------------
 Sum               87                     24359.00 Kr

 -> Integer input was expected.
------------------------------------------------------------------

When the user wrote "five" in a field where a number was expected,
the error message above was automatically displayed.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 52
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

A DISPLAY ORIENTED TEXT EDITOR

     The great advantage with a display terminal for text editing is
     that the computer can so easily change and erase the
     information on the screen. This means that after each edit
     operation, the user can immediately see on the screen the text
     as it will appear after this edit operation.

     VIDED is such a text editor based on the same basic package as
     the other programs described in this report.

     Example; The screen contains the text:

     Jack and Jill went up the hill. Jack fell down, and Jill
     came tumbling after.

     Now, you might want to change the second phrase to "Jack fell
     down from the hill". You move the cursor to the position of the
     insertion and make an insertion command, and you get:

     Jack and Jill went up the hill. Jack fell down from the hill, and Jill
     came tumbling after.

     But now, the first line is too long, so you make a "justify"
     command to adjust the line lengths of the paragraph, and get:

     Jack and Jill went up the hill. Jack fell down from the
     hill, and Jill came tumbling after.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 53
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

     VIDED simplifies the production of character drawings, which
     are almost impossible to produce with many other text editors.

     Examples:

     (1)  ^          (2)                    __________
         ' |                                !        !
        ' o |            --------<---NO-<---! READY? !--->-YES---
       ' o o |           !                  !________!          !
      ' o o o |          V                      !               V
     '_________|    _________      ________     !           ________
     ! O O O O !    !       !      !      !     !           !      !
     ! O O O O !    ! START !----->! EDIT !-->---           ! STOP !
     ! O O O O !    !_______!      !______!                 !______!
     ! O O O O !        ^                                       !
     ! O O O O !        !                                       V

     (3)
             !
       1.00 -!- - - - - - oooooo  - - - - - - - - - - - - - - - - - -
             !          oo      oo
             !        oo          oo
             !       o              o
             !     oo                oo
             !    o                    o
             !   o                      o
       0.00 -!-------------------------------------------------------
             !                           ^o                      o
             !  The curve intersects     ! o                    o
             !  zero at this point ---->--  oo                oo
             !                                o              o
             !                                 oo          oo
             !                                   oo      oo
      -1.00 -!- - - - - - - - - - - - - - - - - -  oooooo - - - - - -
             !


     The curve above was originally produced by a plotting program,
     but without axes or explanations. The axes and the explaining
     text was thereafter added to the plot using the VIDED text
     editor.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 54
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

EXAMPLES OF HOW TO USE THE PROGRAM

     The program is controlled from the application by simple
     procedure calls. Examples:

     MOVE_THE_CURSOR_TO(h,v) will move the cursor to the screen
     position with the address (h,v), as counted from the upper left
     corner of the screen.

     OUTCHAR, OUTTEXT, OUTINT, OUTREAL etc. will work as standard
     SIMULA output procedures, but the text is output at the place
     of the screen where the cursor is. Thereafter, the cursor will
     be at the screen position following the output text.

     OUTIMAGE will move the cursor to the first position of the next
     line of the screen.

     At first, we found debugging of application programs using this
     facility difficult, since the debugging output mixed up the
     picture. The solution was to use two terminals, one for the
     picture and another for the debugging output.

TERMINAL CHARACTERISTICS

     Unfortunately, there is no standardization at all of the codes
     to control a conversational display terminal. Each terminal has
     its own set of control codes.

     The VISTA program package has (in november 1977) built-in
     knowledge of the following terminals:

     INFOTON VISTA
     INFOTON VISTAR SATTELITE
     MINITEC AND TELETEC
     DEC VT52
     DATAMEDIA ELITE 2500 AND ELITE 1520
     TANDBERG TDV 2000
     BEEHIVE B 100
     CDC 713-10

     In addition to this, the program is easy to adjust to other
     terminals, since on most terminals there are keys for trans-
     mitting to the computer the codes to move the cursor around the
     screen. By pushing these keys you can from an unknown terminal
     tell the computer program which codes to send to move around
     the screen.
PALME: VISTA - FULL CONTROL OF TEXT DISPLAY TERMINALS       Page 55
Appendix C: MOVING PICTURES SHOW SIMULATION TO USER

BIBLIOGRAPHY

Dahl, Myhrhaug and Nygaard 1970: SIMULA information Common Base
          Language. Norsk Regnesentral, Forskningsveien 1b, Olso
          3, Norway, Publication no. S-22.

Birtwistle and Palme 1974, 1975: DECsystem-10 SIMULA Language
          Handbook Part I. Swedish National Defense Research
          Institute, S-104 50 Stockholm 80, Sweden, Report no.
          C8398-M3(E5).

Arnborg, Bj`rner, Enderin, Engstr`m, Karlsson, Ohlin, Palme,
          Wennestr`m and Wihlborg 1974, 1976: DECsystem-10 SIMULA
          Language Handbook Part II. Swedish National Defense
          Research Institute, Report no. C8399-M3(E5).

Arnborg, Enderin, Ohlin, Oldgren and Palme 1976: DECsystem-10
          SIMULA Language Handbook Part III. Swedish National
          Defense Research Institute, Report no. C10045-M3(E5).

Palme 1975: Interactive Software for Humans. Swedish National
          Defense Research Institute, Report no. C10029-M3(E5).

Ohlin 1976: Safe Conversational SIMULA Programs Using Class
          SAFEIO. Swedish National Defense Research Institute,
          Report no. C10044-M3(E5).

Palme 1976: VISTA - For Full Control of Text Display Terminals.
          Swedish National Defense Research Institute, Report no.
          D10007-M3(E5). (Contains a programmers manual to the
          program described in this report.)

Jennergren, Lundh and Wandel 1976: Icebreaking operations in the
          Northern Baltic - A Simulation Study. FOA 1 report
          88-8246:1/1976.

Palme 1977, 1978: VIDED - A Display-oriented Text Editor. FOA 1
          report C10096, December 1978.