To avoid this double overloading of TSS, a DEL program will
         run on the user-host.  It will handle all the immediate
         feedback, much like a complicated echo table.  At appropriate
         button pushes, message will be sent to the server-host and
         display updates received in return.

      One of the more difficult, and often neglected, problems is the
      effective simulation of one nonstandard console on another non-
      standard console.

         We attempt to offer a means of solving this problem through
         the co-routine structure of DEL programs.  For the
         complicated interactive systems, part of the DEL programs
         will be constructed by the server-host programmers.
         Interfaces between this program and the input stream may
         easily be inserted by programmers at the user-host site.


UNIVERSAL HARDWARE REPRESENTATION

   To minimize the number of translators needed to map any facility's
   user codes to any other facility, there is a universal hardware
   representation.

   This is simply a way of talking, in general terms, about all the
   hardware devices at all the interactive display stations in the initial
   network.

   For example, a display is thought of as being a square, the
   mid-point has coordinates (0.0), the range is -1 to 1 on both
   axes.  A point may now be specified to any accuracy, regardless of
   the particular number of density of rastor points on a display.

   The representation is discussed in the semantic explanations
   accompanying the formal description of DEL.

INTRODUCTION TO THE NETWORK STANDARD TRANSLATOR (NST)

   Suppose that a user at a remote site, say Utah, is entered in the
   AHI system and wants to run NLS.

   The first step is to enter NLS in the normal way.  At that time
   the Utah system will request a symbolic program from NLS.

      REP   This program is written in DEL.  It is called the NLS
      Remote Encode Program (REP).

      The program accepts input in the Universal Hardware
      Representation and translates it to a form usable by NLS.

      It may pack characters in a buffer, also do some local
      feedback.

   When the program is first received at Utah it is compiled and
   loaded to be run in conjunction with a standard library.

   All input from the Utah console first goes to the NLS NEP.  It is
   processed, parsed, blocked, translated, etc.  When NEP receives a
   character appropriate to its state it may finally initiate
   transfers to the 940.  The bits transferred are in a form
   acceptable to the 940, and maybe in a standard form so that the
   NLSW need not differentiate between Utah and other NET users.


ADVANTAGES OF NST

   After each node has implemented the library part of the NST, it
   need only write one program for each subsystem, namely the
   symbolic file it sends to each user that maps the NET hardware
   representation into its own special bit formats.

      This is the minimum programming that can be expected if 
      console is used to its fullest extent.

      Since the NST which runs the encode translation is coded at the
      user site, it can take advantage of hardware at its consoles to
      the fullest extent.  It can also add or remove hardware 
      features without requiring new or different translation tables
      from the host.

      Local users are also kept up to date on any changes in the system
      offered at the host site.  As new features are added,
      the host programmers change the symbolic encode program.  When
      this new program is compiled and used at the user site, the new
      features are automatically included.

   The advantages of having the encode translation programs
   transferred symbolically should be obvious.

      Each site can translate any way it sees fit.  Thus machine code
      for each site can be produced to fit that site; faster run
      times and greater code density will be the result.

      Moreover, extra symbolic programs, coded at the user site, may
      be easily interfaced between the user's monitor system and the
      DEL program from the host machine.  This should ease the
      problem of console extension (e.g. accommodating unusual keys and
      buttons) without loss of the flexibility needed for man-machine
      interaction.