— Original Author: Paul Koning
Overview
This article describes an outline of how the PLATO NIU1) works, based
on CERL 2) documents and reverse engineering of PLATO code. It also
describes the communication protocol used by the NIU emulator in DtCyber .
The NIU has TWO channels, one for input, one for output. These are given equipment names IC3) and OC4) respectively.
Function codes
0 deselect input
40 select input
0 select output
7000 deselect output
input data:
output data:
data 4140b,0064b load char mode (mode rewrite)
data 4200b,0420b load x=136 (column 18)
data 4201b,1600b load y=448 (line 4)
data 5777b,1640b (uncover)(uncover)(20)
data 5555b,1332b (space)(space)(space)
NIU timing:
On the real NIU, the timing is as follows:
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:
byte 0: 1/0, 7/first 7 bits
byte 1: 2/2, 6/next 6 bits
byte 2: 2/3, 6/low order 6 bits
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:
byte 0: 5/0, 3/first 3 bits
byte 1: 1/1, 7/low order 7 bits
Examples:
Touch screen input X=1, Y=2 comes in as:
5/0, 3/002
1/1, 7/022
The output shown above goes out as:
1/0, 7/014
2/2, 6/000
2/3, 6/032
1/0, 7/020
2/2, 6/002
2/3, 6/010
1/0, 7/002
2/2, 6/017
2/3, 6/000
1/0, 7/177
2/2, 6/077
2/3, 7/020
1/0, 7/155
2/2, 6/055
2/3, 6/055
Input coding (from polls):
keycode con 1r0 000b
con 1r1 001b
con 1r2 002b
con 1r3 003b
con 1r4 004b
con 1r5 005b
con 1r6 006b
con 1r7 007b
con 1r8 010b
con 1r9 011b
con kmult 012b
con kdiv 013b
con tab 014b
con kassign 015b
con 1r+ 016b
con 1r- 017b
con ksup 020b
con ksub 021b
con ans 022b
con erase 023b
con micro 024b
con help 025b
con next 026b
con edit 027b
con back 030b
con data 031b
con stop 032b
con copy 033b
con micro1 034b (temporary for square)
con lab 035b
con extra1 036b
con extra2 037b
con klt 040b
con kgt 041b
con klbrack 042b
con krbrack 043b
con 1r$ 044b
con kpct 045b
con kunder 046b
con kapost 047b
con 1r* 050b
con 1r( 051b
con kdot 052b
con kroot 053b
con kcr 054b
con kup 055b
con ksigma 056b
con kdelta 057b
con upsup 060b
con upsub 061b
con term 062b
con erase1 063b
con font 064b
con help1 065b
con next1 066b
con edit1 067b
con back1 070b
con data1 071b
con stop1 072b
con copy1 073b
con access 074b (square1)
con lab1 075b
con extra3 076b
con extra4 077b
con 1r 100b
con 1ra 101b
con 1rb 102b
con 1rc 103b
con 1rd 104b
con 1re 105b
con 1rf 106b
con 1rg 107b
con 1rh 110b
con 1ri 111b
con 1rj 112b
con 1rk 113b
con 1rl 114b
con 1rm 115b
con 1rn 116b
con 1ro 117b
con 1rp 120b
con 1rq 121b
con 1rr 122b
con 1rs 123b
con 1rt 124b
con 1ru 125b
con 1rv 126b
con 1rw 127b
con 1rx 130b
con 1ry 131b
con 1rz 132b
con 1r= 133b
con ksemic 134b
con 1r/ 135b
con 1r. 136b
con 1r, 137b
con kbksp 140b
con upa 141b
con upb 142b
con upc 143b
con upd 144b
con upe 145b
con upf 146b
con upg 147b
con uph 150b
con upi 151b
con upj 152b
con upk 153b
con upl 154b
con upm 155b
con upn 156b
con upo 157b
con upp 160b
con upq 161b
con upr 162b
con ups 163b
con upt 164b
con upu 165b
con upv 166b
con upw 167b
con upx 170b
con upy 171b
con upz 172b
con 1r) 173b
con kcolon 174b
con kquest 175b
con kexclam 176b
con kquote 177b
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):
*** prms message format.
*
* 12 / network address.
*** plato key message format.
*
* 12 / network address.
* 64 / key data.
* 8 / reserved for the network.
*** supervisory message format, excluding the ncrspm
* message.
*
* 12 / 1, host to network supervisory bit.
* 1 / 1, start bit.
* 1 / 0, first blockette bit.
* 1 / 0, blockette type bit.
* 1 / 0, a (up) bit.
* 4 / high bits of network address.
* 8 / low bits of network address.
* 72 / 8 bit bytes 2 - 10 of the message.
* 8 / reserved for the network.
*** ncrspm message format.
*
* 12 / 1, host to network supervisory bit.
* 1 / 1, start bit.
* 1 / 0, first blockette bit.
* 6 / high bits of micro-node address.
* 8 / low bits of micro-node address.
* 72 / 8 bit bytes 2 - 10 of the message.
* 8 / reserved for the network.
*** data messages (blocksets) are received a data
* block at a time. each data block contains 1 to
* 8 twenty bit data bytes, and a blockset consists
* of 1 to 16 data blocks. the data blocks are re-
* cieved in sequential order. the data blocks have
* two formats - the last data block of a blockset
* and not the last data block.
*** not the last data block format.
*
* 12 / network address.
* 1 / start bit.
* 1 / 0, 1st blockette bit.
* 1 / 1, blockette type.
* 1 / 1, up/down bit.
* 1 / 0, supervisory/data bit.
* 1 / 0, spares bit.
* 10 / low bits of network address.
* 1 / last blockette start bit.
* 1 / 2nd blockette bit.
* 1 / 0, last block bit.
* 1 / unused.
* 4 / block sequence number.
* 160 / 8 twenty bit data bytes.
* 2 / 0.
* 4 / high bits of network address.
* 2 / 0.
* 48 / padding to make length 21 pp words.
*** last data block format.
*
* in the last data block, the last block bit is
* set, and the low bit of the last 20 bit data byte
* received is always set.
*
* 12 / network address.
* 1 / start bit.
* 1 / 0, 1st blockette bit.
* 1 / 1, blockette type.
* 1 / 1, up/down bit.
* 1 / 0, supervisory/data bit.
* 1 / 0, spares bit.
* 10 / low bits of network address.
* 1 / last blockette start bit.
* 1 / 2nd blockette bit.
* 1 / 1, last block bit.
* 1 / unused.
* 4 / block sequence number.
* 160 / 1 to 8 twenty bit data bytes.
* 2 / 0.
* 4 / high bits of network address.
* 2 / 0.
* 48 / padding to make length 21 pp words.
**** pcn message type values.
These go in data byte 3 of the supervisory message.
alcalm0 equ 0 all call message (types 0 - 5)
alcalm5 equ 5
alclrm0 equ 8 all call response (types 8 - 13)
alclrm5 equ 13 all call response (types 8 - 13)
alcgrm equ 16 all call group response
solr equ 17 solicit response
estl equ 18 establish link
nav1 equ 19 node available (1)
nav2 equ 20 node available (2)
busy equ 21 busy
no equ 22 no
drpl equ 23 drop link
abortr equ 25 abort response
abortm equ 32 abort
pts equ 36 permission to send
abortr equ 25 abort response
abortm equ 32 abort
ncrdm equ 33 network control read
ncwrm equ 35 net control write
pts equ 36 permission to send
ncrspm equ 37 network control response
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):
*** abortm message format.
*
* 12 / network address.
*** plato key message format.
*
* 12 / network address.
* 64 / key data.
* 8 / reserved for the network.
*** data message (blockset) format.
*
* 12 / network address.
* d*20 / d 20 bit data bytes, 0 < d < 129.
*** supervisory message format, excluding the ncrdm
* and ncwrm messages.
*
* 12 / 1, host to network supervisory bit.
* 1 / 1, start bit.
* 1 / 0, first blockette bit.
* 1 / 0, blockette type bit.
* 1 / 0, a (up) bit.
* 4 / high bits of network address.
* 8 / low bits of network address.
* 72 / 8 bit bytes 2 - 10 of the message.
* 8 / reserved for the network.
* 24 / padding to make the length 11 pp wds.
* abortr path rate codes.
prt1200 equ 7 1200 bps
*** ncrdm message and ncwrm message format.
*
* 12 / 1, host to network supervisory bit.
* 1 / 1, start bit.
* 1 / 0, first blockette bit.
* 6 / high bits of micro-node address.
* 8 / low bits of micro-node address.
* 72 / 8 bit bytes 2 - 10 of the message.
* 8 / reserved for the network.
* 24 / padding to make the length 11 pp wds.
*** host to network output protocol.
*
* messages sent to a network address associated with
* a path connecting a call origin and call destina-
* tion adhere to the following protocol.
*
* 1 supervisory and key messages may be output at
* any time.
*
* 2 data messages may be output only if -
*
* since the last data message was sent,
* a prms has been received and an abortm
* has not been sent
*
* or
*
* since the last abortm was sent, an
* abortr has been received.
*
* 3 the value in the high order 4 bits of the orgtyp
* field of the solr and estl messages indicates
* the type of link being established -
*
* 0 host to host interactive link.
* 1 host to host bulk data link.
* 2 host to host loopback link.
* 3 host to host diagnostic link.
* 4 interactive pcn dialed link.
* 5 host to host interactive simulator link.
* 6 get remote host name link.
* 7 get nodes available link.
*
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.