PLATO Terminal: Interfacing an Illinois plasma terminal to the ARPANET
Connecting a plasma display terminal to the ARPANET
Berggreen, A., "Interfacing an Illinois plasma terminal to the ARPANET", RFC 600, DOI 10.17487/RFC0600, November 1973, <https://www.rfc-editor.org/info/rfc600>.
@misc{rfc600,
series = {Request for Comments},
number = 600,
howpublished = {RFC 600},
publisher = {RFC Editor},
doi = {10.17487/RFC0600},
url = {https://www.rfc-editor.org/info/rfc600},
author = {A. Berggreen},
title = {{Interfacing an Illinois plasma terminal to the ARPANET}},
pagetotal = 3,
year = 1973,
month = nov,
} RFC text
Contents
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]
AI ELI5
On this page
§1The PLATO System and Its Terminal
The PLATO IV System at the University of Illinois was a sophisticated computer-aided instruction platform with a unique plasma display terminal: a glowing screen that displayed information in ways most computer terminals could not. The terminal could show graphics and had specialized capabilities for education applications.
However, connecting PLATO terminals over long distances required expensive long-distance telephone lines running at slow speeds. Since ARPA had already built the ARPANET as a cost-effective national network, the obvious solution was to connect these terminals through the network instead.
There was a special glowing computer screen for teaching that was hard to connect to faraway computers. Scientists wanted to use the cheaper network instead of expensive phone calls.
§2The Two-Mode Interface
The plasma terminal naturally sent and received data using Frequency Shift Keying (FSK) modulation over phone lines: 1200 bits per second in full-duplex mode on dedicated lines, or slower split speeds (1200 bits/sec receiving, 120 bits/sec sending) on dial-up.
To work with the ARPANET and its network nodes (called TIPs), the terminal needed to speak a different language: standard ASCII codes. The solution was to build an interface that could operate in two modes. In ASCII mode, it would send and receive standard 8-bit ASCII characters for normal network access, losing graphics capability. In PLATO mode, it could embed PLATO's proprietary data in 8-bit codes to pass transparently through the network while maintaining full functionality.
One challenge was preventing network nodes from misinterpreting PLATO codes. For example, the @ symbol is a TIP command prefix, so the interface had to escape or omit such codes to avoid accidental command triggers.
The interface was like a translator that could switch between two languages: network language (ASCII) for regular network use, and PLATO language when talking to the PLATO system. It had to be careful not to let special codes trick the network.
§3From Hardware to Flexible Software
The prototype interface built at UCSB in 1973 used dedicated hardware and provided the two-mode switching, though it sacrificed some capabilities in ASCII mode (it could only display 124 out of 128 ASCII characters).
Looking ahead, the team recognized that a fixed hardware solution was too rigid. They planned to replace it with a microcomputer-based interface, complete with ROM storage for the control program. This approach would let the interface be reprogrammed to emulate other terminal types, implement cursors, and eventually support network graphics protocols without replacing the hardware itself.
The first version was hardwired, but the team realized they could use a small computer instead. That way, they could reprogram it to do new tricks later without building new hardware.