RFC 600

RFC 600 🎀 Interfacing an Illinois Plasma Terminal to the ARPANET ✨

Title block: Network Working Group, Request for Comments 600, NIC 20884. Written by A. Berggreen of the Computer Systems Laboratory at UCSB, dated November 1973. It doesn't list a category, and it doesn't obsolete or update anything. 💅

INTRODUCTION 🌸

okay so the PLATO IV System at the University of Illinois at Urbana is seriously iconic for Computer Aided Instruction 😭 it's a super advanced setup with a plasma display terminal, which is a unique device with capabilities that regular computer terminals just don't have. a bunch of ARPA supported projects want to use that plasma terminal, either on a local connection to computer resources or over a long-distance connection to the PLATO IV System. 🧚

the big problem with using PLATO from any real distance is the communication cost. we're talking long-distance telephone rates for many consecutive hours, which is wild 💀 also, using the plasma terminal for other stuff is kind of hard because the communications scheme PLATO uses is non-standard. 🙈

so one way to cut those costs is to use the ARPANET for the long-distance part. the Network is potentially one of the most reliable and cost effective ways to send computer data, so it's giving main character energy ✨ this makes sense since there 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. plus there are more and more TIPs and IMPs on the ARPANET every day, so access is getting easier and more common. 🦋

the plasma terminals are built to connect directly to telephone lines using Frequency Shift Keying (FSK) modulation. on dedicated telephone lines, the plasma terminal can run at 1200 bits/sec in full-duplex operation. on dial-up lines, display information comes in at 1200 bits/sec, and data going back to the computer is sent at 120 bits/sec using a reverse channel scheme. 🌈

the data and command words the plasma terminal uses are different for input and output. input from the computer arrives in 20-bit words plus one start bit, and data sent to the computer goes out in 11-bit words plus one start bit. 💜

now, to make the plasma terminal more generally useful for standard communication, and to fit the ARPANET connection through a TIP, the terminal has to be interfaced so it can communicate using Teletype-like codes. and if the PLATO System is going to be linked through the Network with no changes to the system itself, then a special interface has to be built so the Network can talk to PLATO using the FSK communication scheme. 👑

APPROACH 🫶

so the plasma terminal needed to act like a Teletype when it's tied to a TIP, but still work with the PLATO System through the Network. the plan was to build an interface that could run in two modes. there would be an "ASCII" mode for sending and receiving Network oriented data, like TIP log-on or running at some arbitrary Network site. and there would be a "PLATO System" mode that lets data, embedded in 8-bit codes, pass through the Network transparently. 🎀

here's the tricky part 😭 when the terminal is in PLATO mode, the reformatted codes can look like standard ASCII characters, and then intervening TIPs or HOSTs might grab them. so the interface has to make sure no recognizable codes get sent. for example, a TIP recognizes @ as the start of a TIP command string. so the interface has to either "double-up" this code (@@) or not send it at all. ✨

with that requirement and some other limitations in mind, the prototype interface (the one in use at UCSB right now) works like this: 🍓

1. In ASCII mode, the plasma terminal has been made to send and receive 8-bit ASCII code. in this mode there's no graphics capability. the keyboard that comes with it can only send 124 codes, so 4 seldom used ASCII codes have been left out, and certain ASCII characters can't be displayed. 🙈
2. In PLATO mode, PLATO data is embedded in 8-bit codes. it's also possible to run the keyboard in ASCII mode while the display stays in PLATO mode. 💅

SUBSEQUENT WORK 🔥

after some discussion, it became super clear that the interface needs to be flexible. stuff like emulating standard graphics terminals, implementing a cursor, and responding to Network Graphics Protocols is highly desirable, no cap 🤩 so the team decided to re-package the original hardware around a micro-computer with a ROM for the control program. with more RAM and/or ROM added, the micro-computer can be programmed so the plasma terminal does a wide variety of tasks. work on developing this interface has already begun at UCSB. 🦋

here's the planned version of the plasma data format for Network use, in Figure 1 🌸

              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] 🧚