I'm trying to learn more about how the PLATO system worked with respect to communications. I've read some of the specs, but coming from a web-background I'm unfamiliar with the underlying way that the mainframe and terminal communicated. Did the terminal send data which got a response from the mainframe (like an http call), or did the mainframe have the ability to push data to the terminal at any point? (more like websockets)

  • 1
    I always assumed it just worked like any terminal - it's an output device on the computer. When the computer wants to write to the output device, it writes. It's not different in principle to a VT100, except that it has a richer set of commands it can execute. – another-dave Feb 26 at 20:13
  • @another-dave Later PLATO terminals had an 8080 and could download software and run it locally, in tandem with the mainframe. I believe that was mostly used for graphics. – RETRAC Feb 26 at 20:28
  • @RETRAC - oh, I don't doubt there were onboard smarts, but that doesn't mean it wasn't just a terminal from the computer's point of view. – another-dave Feb 27 at 0:01
  • @WalterMitty - Robin: Z80 – another-dave Feb 28 at 16:30

As comments have suggested, it was quite a bit like other smart terminals such as a VT-100. The terminal had an RS-232 connection to the mainframe. But (at least as of the Plato V) it also have an 8080 in the terminal, with its own 8-bit expansion bus, so in many ways it was similar to something like an Apple II or TRS-80 (etc.) with a serial card--able to run programs locally on the terminal, act purely as an I/O device for a program running on the mainframe, or timeshare between the two.

enter image description here

[As an aside: note the figure number. Anybody who spent much time around Control Data products quickly learned to see all numbers as floating point.]

To address your questions directly: either the terminal or the mainframe could send data to the other at an arbitrary time, without the far end having to request the data.


Plato Manual



A Plato terminal is kind of a character mode terminal on steroids. As such it supports of course any output by the connected host (push) without prior request from the terminal (after beeing connected ofc.).

A Bit of History

What you call 'push' is the natural way any classic terminal works. No matter if interactive or a printer (*1). It's a device connected to a computer who can send information toward the terminal or receive from there.

There is no predefined sequence, an interactive terminal can connect to an application, or an application can connect to a terminal. Basically a reverse direction logon. Useful for fixed function workstations like a cashier or a booking counter were no other application is to run. This is possible as terminals are known to their hosts ahead of opening a connection :))

In general classic terminals fall in two cathegories:

  • Block Mode Terminals and
  • Character Mode Terminals

A block mode terminal

is comparable to early interactive web pages, that only worked thru CGI and server side scripts plus very limited kind of dynamic content handling/update.

  1. The user connect to an application (Browser: does an HTTP request)
  2. The mainframe answers with a form (Browser: sends a page)
  3. The user
    • fills some fields and sends the data back, which results in a new form -> Step 2
    • or initiates a new request (Browser: klicking on a link/button) -> Step 2
  4. The user disconnects from an application (types in another URL)

In web terms, think of them as as browsers before addition of ECMA-script (Everything before Netscape Navigator 2.0 in 1995), somewhat intelligent fixed function device.

A character mode terminal

is a bit more like a printer and a keyboard. Whatever the host sends gets displayed on the screen. Special commands can be used to select position and attributes (like colour, size or character set), or even output graphics/line drawings. Any character typed on the keyboard (or other input devices) is send directly to the host.

In web like terms, think of them as a free form canvas with host side output (push) drawing thereon. The terminal is only meant to channel that output to the canvas and input from the user back to the host, itself not providing any processing capabilities.

The Plato terminal

Is basically a character mode terminal, in the sense that it receives output commands from a host and returns input data. It's based around a set of output types, like

  • Line Drawing
  • Character Output
  • Direct Memory Write
  • User Data Output

a set of input messages, like

  • Key Typed
  • Touch Coordinate
  • Data Transfer
  • Status and Exception Message

In general the output was received and drawn as received from the host, and input (keypress or touchpad coordinates) forwarded to the host. So far this is quite similar to a (fancy) character mode terminal.

The real addition is the ability to run local 8080-software (think of that as scripts). Programms can originate from

  • A minimal build in set of functions (ROM)
  • Downloaded from the host (using the write memory mode)
  • Loaded from local media (like floppy disk)

With that ability possibilities become endless - well, almost considering the rather limited RAM size :))

So long story short, the Plato terminal are like a canvas that can be drawn from the host but anything could as well be handled by local scripts. In web terms they can be seen like a more modern Browser (past Netscape 2.0), with ECMA-script but without CSS.

*1 - In mainframe terinology every connected (remote) is a terminal. No matter if a card reader, a card punch, a printer,or well, a CRT based interactive terminal. An interactive terminal is just one (specific) kind.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.