RFC 600 UNKNOWN TERMINAL · INTERFACE · HARDWARE

PLATO Terminal: Interfacing an Illinois plasma terminal to the ARPANET

An interface design for connecting a PLATO plasma terminal to the ARPANET.

On rfc-editor.org ↗
PUBLISHED
November 1973
AUTHORS
A. Berggreen
STREAM
Legacy
DEDICATED-LINE FULL-DUPLEX RATE
1200 bits per second
DIAL-UP RECEIVE RATE
1200 bits per second
DIAL-UP TRANSMIT RATE
120 bits per second
KEYBOARD CODES IN ASCII MODE
124
DOI
10.17487/RFC0600

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                       A. Berggreen
Request for Comments: 600              COMPUTER SYSTEMS LABORATORY--UCSB
NIC: 20884                                                 November 1973


         INTERFACING AN ILLINOIS PLASMA TERMINAL TO THE ARPANET

INTRODUCTION

   The PLATO IV System based at the University of Illinois at Urbana is
   a highly sophisticated and very powerful approach to Computer Aided
   Instruction.  The PLATO IV system makes use of a plasma display
   terminal that is a unique device with capabilities not presently
   found on computer terminals.  A number of ARPA supported projects
   intend to use the plasma terminal on local connection to computer
   resources or by long-distance connection to the PLATO IV System.

   One problem in using the PLATO System from any appreciable distance,
   is the communication costs involved (i.e. long-distance telephone
   rates for many consecutive hours).  Also, use of the plasma terminal
   in other applications is hampered since the communications scheme
   employed in the PLATO System in non-standard.

   One approach to reducing the communications cost is to use the
   ARPANET for the long-distance connection, since the Network is
   potentially one of the most reliable and cost effective means of
   transmitting computer data.  This approach is reasonable the is a
   Network node near the PLATO System, (the PDP-11/ANTS system at the
   Center for Advanced Computation at the University of Illinois at
   Urbana) and with the increasing number of TIPS and IMPS on the
   ARPANET access is becomming easier ad more widespread.

   The plasma terminals are designed to be connected directly to
   telephone lines using Frequency Shift Keying (FSK) modulation.  Using
   dedicated telephone lines, the plasma terminal may be run at a data
   rate of 1200 bits/sec in full-duplex operation.  Using dial-up lines,
   the terminal may be run with display information being received at
   1200 bits/sec and data to the computer being transmitted at 120
   bits/sec using a reverse chanel scheme.

   The data and command words used by the plasma terminal differ for
   input and output.  Input received from the computer arrives in 20-bit
   words plus one start bit.  Data transmitted to the computer is sent
   in 11-bit words plus one start bit.

   In order to make the plasma terminal more generally applicable for
   standard communication, and specifically adapted to the ARPANET
   connection by way of a TIP, the terminal must be interfaced in such a
   way as to communicate using Teletype-like codes.  In addition, if the
   PLATO System is to be linked by way of the Network with no changes to
   the system, then a special interface must be provided to allow the
   Network to communicate with the PLATO System using the FSK
   communication scheme.

APPROACH

   So that the plasma terminal would communicate like a Teletype when
   tied to a TIP, and still be able to work with the PLATO System
   through the Network, it was decided to build an interface that could
   be operated in two modes.  There would be an "ASCII" mode to send and
   receive Network oriented data (such as TIP log-on or running at some
   arbitrary Network site); and a "PLATO System" mode to allow data,
   imbedded in 8-bit codes, to pass transparently through the Network.

   Since there is a possibility that when in the PLATO mode, re-
   formatted codes can appear to be standard ACSII characters that will
   be seized upon by intervening TIPs or HOSTs, the interface must
   insure that no recognizable codes be sent.  For example, the @ is
   recognized by a TIP as the beginning of a TIP command string.
   Therefore the interface must either "double-up" this code (@@) or not
   send it at all.

   With the above requirement, and with other limitations, the proto-
   type interface, now in use at UCSB, operates as follows:

   1. In ASCII mode, the plasma terminal has been made to send and
      receive 8-bit ASCII code.  In this mode, there is no graphics
      capability.  The keyboard that is provided can only send 124
      codes, therefore 4 seldom used ASCII codes have been excluded, and
      certain ASCII characters cannot be displayed.

   2. In PLATO mode, PLATO data is embedded in 8-bit codes.  The
      capability of running the keyboard in ASCII mode while the display
      remains in PLATO mode has also been provided.

SUBSEQUENT WORK

      After discusion, it became clear that the flexability of the
      interface to do such things as emulate standard graphics
      terminals, implement a cursor, and to respond to Network Graphics
      Protocols, will be highly desirable.  So it has been decided that
      the original hardware will be re-packaged using a micro-computer
      with a ROM for the control program.  With the addition of more RAM
      and/or ROM, the micro-computer will have the capability of being
      programmed to allow the plasma terminal to do a wide variety of
      tasks.  Work on developing this interface has begun at UCSB.

      Figure 1 shows the planned version of plasma data format for
      Network use.

              PACKING SCHEME FOR PLASMA TERMINAL DATA

                                               Data from Plasma
                 |Msb|x|x|x|x|x|x|x|x|Lsb|P|  <----------------
                   |  | | | | | | | |  |  *    Terminal
                   |  | | | | \ \ \ \  \    Parity for Keyboard
                   |  | | | |  \ \ \ \  \   data is regenerated
                   |  | | | |   \ \ \ \  \  at the PLATO System
                   |  | | | |    \ \ \ \  \ end.
                   |  | | | |     \ \ \ \  \
                   / / / / /       \ \ \ \  \
                  / / / / /         \ \ \ \  \
      Data to    | | | | |           | | | | |
      <-------- |x|x|x|x|x|1|1|0|<--|x|x|x|x|x|1|0|0|
      Network

   For the second part of Figure 1, please view the PDF version of this
   document.


   NOTE: NO-OP codes are removed from the data stream at the PLATO
   System end by the hardware.

         [ This RFC was put into machine readable form for entry ]
          [into the online RFC archives by Neil Philp 11/99]

ISO Plain Language

On this page
PROBLEMThe PLATO IV plasma terminal used a nonstandard communication scheme, making it difficult to connect through the ARPANET and use for other applications.
MECHANISMThe prototype interface offered an ASCII mode for network-oriented data and a PLATO mode for passing PLATO data in 8-bit codes through the network.
THE DESIGNThe RFC describes a prototype in use at UCSB and plans to repackage the hardware around a programmable microcomputer.

§1Why the Terminal Needed an Interface

The PLATO IV system at the University of Illinois used a plasma display terminal with a communication scheme based on frequency-shift keying. The RFC says long-distance telephone use cost money and the scheme was nonstandard, limiting use of the terminal in other applications. An ARPANET connection near PLATO offered another way to link the terminal to computer resources.

To connect through a TIP, the terminal needed to communicate using Teletype-like codes. Reaching PLATO through the network without changing PLATO itself also required an interface that could use its FSK communication scheme.

The PLATO terminal used a communication method that did not match the ARPANET's ordinary terminal interface. A special interface was needed to support both network access and communication with PLATO.

§2ASCII and PLATO Modes

The interface was designed to operate in two modes. ASCII mode sent and received 8-bit ASCII for network-oriented use, such as logging in through a TIP; it had no graphics capability, and the keyboard could send 124 codes. PLATO mode embedded PLATO data in 8-bit codes so it could pass transparently through the network. The interface could also use an ASCII keyboard while keeping the display in PLATO mode.

In PLATO mode, some code values could be mistaken for network commands. The RFC gives @ as a TIP command prefix and says the interface had to double such a code or omit it.

ASCII mode let the terminal handle ordinary network input but did not provide graphics. PLATO mode carried PLATO data, with special handling to prevent a code from being mistaken for a network command.

§3Planned Interface Development

The prototype was in use at UCSB. After discussion, the developers decided to repackage the original hardware using a microcomputer with a ROM control program. They expected added RAM or ROM to make it possible to program a wider range of tasks, including emulating standard graphics terminals, implementing a cursor and responding to Network Graphics Protocols. The RFC says development of this interface had begun at UCSB.

The document also includes a planned data-packing figure and notes that the PLATO System hardware removes NO-OP codes from the data stream at its end.

UCSB planned a programmable microcomputer-based interface to make the terminal more flexible. The proposed work included graphics-terminal emulation and support for network graphics protocols.