— Original Author: Paul Koning

• PLATO IV terminal manual
• NIU output controller

The NIU has TWO channels, one for input, one for output. These are given equipment names IC³⁾ and OC⁴⁾ respectively.

Function codes

• input channel:

     0   deselect input
    40   select input

• output channel:

     0   select output
  7000   deselect output

input data:

• input comes in a pair of words.
• first word: 4000 plus station number.
• second word: keycode « 1.
• If there is no more input, this is indicated simply by the fact that the channel doesn't become full when selected.

output data:

• output data comes in three words.
• first and second words: data.
• third word: station number.
• first word contains 4000 plus first 10 bits of the output data.
• second word contains the last 9 bits of the output data, left
• shifted by one. For example (from pio sourcecode):

• third word has 2000b flag set for last station in the current frame.

NIU timing:

On the real NIU, the timing is as follows:

• Output data: 1260 bps per terminal.
  
  Terminal output words (including start and parity bits) are 21 bits each, the data stream is 60 words per second continuous. If no PLATO data is present for a particular 1/60th second time slot, the NIU supplies a NOP word (all zero).
  
  In the program interface seen by the PP, the NIU is ready for additional output (3 word sets) so long as it has not been told to end the frame. Once the frame end flag is given to the NIU, it remains busy (does not answer Empty to the next output word) until the frame has been transmitted, i.e., after 1/60th of a second.

• Input data: 126 bps per terminal.
  
  Terminal input words (including start and parity bits) are 12 bits each, so the maximum possible keyboard data rate is about 10 characters per second. The terminal data is muxed by the site controllers. At the NIU, it appears as a single data stream encoded as described above.

Timing considerations:

The PLATO software design is fairly tightly tied to the hardware timing of the NIU. Input buffering is extremely limited, and if character arrival is substantially faster than the 10 cps limit of the original hardware, overrun is likely. For character output, the data flow from framer to PIO to NIU is dependent on the 60 frames per second timing. If the NIU were to become ready for new frame data much more quickly than 1/60th of a second after end of frame, output data loss will occur. There are software changes to PLATO made as part of the Cyber1 project to cure these assumptions; see decks/ipl871 in this repository. Alternatively, an NIU emulator can obey the original hardware timing to work with unmodified software.

Protocol for NIU to Plato terminal emulator program:

The protocol runs over TCP, by default socket 5004. It carries the input and output data streams.

Both input and output streams carry the PLATO codes. Since the code words are not multiples of 8 in length, they are split up with flag bits in the high order. This allows each end to resynchronize if somehow a byte is misplaced.

PLATO output (NIU to terminal):

The data word is 19 bits – start bit and parity bit are not carried. The TCP stream carries these as sets of 3 bytes, encoded as:

NIU NOP codes are never sent, of course, but Plato NOP codes are, just in case the terminal emulator wants to emulate the operation of the word count register. Actually, that might make sense; a standard PLATO abort sequence would be a sensible way to handle loss of TCP stream sync.

Plato input (terminal to NIU):

The data word is 10 bits – start bit and parity bit are not carried. The TCP stream carries these as byte pairs, encoded as:

Examples:

Touch screen input X=1, Y=2 comes in as:

The output shown above goes out as:

Input coding (from polls):

The NIU has TWO channels, one for input, one for output. These are given equipment names NI and NO respectively.

Function codes (on output channel)

 0	deactivate network
 1	activate network

Input data:

Input data arrives in blocks. The block length is the primary identifier of what type of data the block carries. The PP is expected to post a long read; the device will disconnect at the end of the block.

   Length  Type
     1	   Permission to send
     7	   Key
     9	   Supervisory
     21	   Data block

Message layouts in detail (from plftext):

Output data:

Output data also goes in blocks. Each message type has a block length, which along with the first word indicates what the block type is. Each block is transmitted by Output instructions ending with a channel disconnect.

   Length  Type				First word
     1	   Abort			Network address
     7	   Key				Network address
     11	   Supervisory			1
     n	   Data				Network address

Data messages contain some number of 20-bit words, and the block size in PP words is X*20/12 + 1 rounded up, for X words. X is at most 128, so that yields a max data block size of 215 PP words including the network address at the start.

Note that the supervisory message size outbound is different from the size inbound.

Message layouts in detail (from plftext):

Doelz exchanges:

PLF expects to hear an All Call message periodically – the timeout is 50 ms. Go figure. It doesn't seem to do anything useful with these, but it insists on them. Any All Call message (ALCALM0 through 5) will serve.

Protocol for Doelz over TCP:

The protocol by default uses socket 5005. It carries the input and output data streams.