We have to consider Teletype Model 33 teleprinters, Creed teleprinters and GPO Telex. We must also bear in mind Flexowriter input, since it is desirable to retain compatibility with non-console input as far as possible.
We have to consider three types of communication.
We specialise class (a) to include only three signals:
All other control signals (e.g. Finish INPUT mode) are grouped with class (b).
The essential distinction is that class (a) and class (b) require supervisor attention, whereas class (c) involves compiler attention. To put it another way, we have to write supervisor program to deal with classes (a) and (b), but class (c) only requires us to lay down conventions to be followed by compiler writers.
It is proposed that BREAK should be used for the sole purpose of returning to command status, no matter what is happening. This implies that BREAK must be recognised even when the computer is sending output to the console. The teletypes and our own Creed teleprinters have a BREAK key that opens the line, and the software deals with this. On GPO Telex we cannot open the line, hence the following technique is suggested. If the line is in write state (i.e. computer sending output) break is generated by repeatedly hitting a key whose code includes several ones : this has the effect of flooding the line with ones. If the line is in read state then the otherwise redundant line-feed is used to signal 'BREAK'.
There are two forms of control possible. One is to generate a fault when a particular character comes in : this fault can be trapped if the program wishes to detect the control signal. The other form of control is to pass the character to the program as a "carriage control" character.
On the Teletypes we have available a number of characters in "control shift". At present, ALT MODE sets fault 65 (and is used to signify end of input in INPUT modes, and EOT, RUBOUT and WRU come through as "carriage controls". On Creed teleprinters and Telex we do not have such a control shift. We therefore nominate an "escape" character, which causes the next character to be regarded as a "control shift" character. If the escape character is followed by another occurrence of the escape character, it is passed through as an ordinary character. Suitable escape characters would be suffix 2 on Creed teleprinters and % on GPO Telex. The situation is summarised in the following table :
|XOFF||2X||%X||Erase last line|
|RUBOUT||2R||%R||Backspace (i.e. delete last character)|
|ALTMODE||2A||%A||End INPUT/ Set fault 65|
|WRU||2W||%W||Carriage control 6.3|
|---||22||---||Suffix 2 transmitted|
Note that RUBOUT has been chosen for logical backspace - this follows the existing PDP7 conventions. Note also that WRU has not been used on the TELEX, since there is likely to be a monitoring teleprinter on the line which would be activated by WRU.
XOFF and RUBOUT are non-printing characters. It is suggested that on receiving RUBOUT the system should delete the last character and output a left arrow. On receiving XOFF the system should output a word such as CANCELLED followed by newline. On receiving 2X or %X it should respond with carriage-return, line feed.
For the well route there are no complications regarding the erase last line/last character (except possibly in implementation). Ideally there ought to be an input mode in which these actions are suppressed, but this is of low priority.
The direct route presents some complications. It is essential that the same conventions about erasing should apply whatever system is being used, and in order to avoid an impossible multiplication of effort, this means that erasing must be done by the Supervisor rather than by the individual systems. Equally, it is necessary that the user should be able to switch off the automatic erasing. If input were always read a line at a time there would be no difficulty, but if input is to be taken by characters there has to be a way of indicating when a line or part line is to be processed. A solution can be found in the fact that the input buffering system works in terms of records, which usually correspond to lines, but need not do so. Therefore we can have two modes of input, NORMAL and ABSOLUTE.
In normal mode, input from the console does not become available to the program until a record separator appears, at which time the input is available either as a line or as single characters, deletions having occurred where necessary. Since carriage return is a perfectly good record separator we can work on a basis that each line is processed when the carriage return appears. But by introducing a dummy record separator (0. 0) we can get a partial line processed and made available to the program. From the Teletype we can introduce a dummy record separator by one of the control keys: EOT seems the obvious choice, and the fact that it is non-printing is a positive advantage.
From Creed and Telex it will be necessary to use 2E and %E respectively.
In ABSOLUTE mode the erasing is switched off, and characters are read one at a time exactly as they come from the console.
It is essential that compilers and systems which are publicly offered should be able to take their input from any console, and preferably from any input medium. In many cases this can be achieved by defining one-to-one equivalences between characters, as is already done, for example, in the Autocode system. An alternative is to be able to define multi-character sequences as equivalents for non-existent characters, e.g. GT for "greater than", etc. Further complications arise if, for example, one wishes to edit a document which contains composite characters from a console which does not have a backspace. In all these situations the onus must be on the compiler/system not the supervisor. That is, all printing characters must have distinct internal codes. For example, a compiler which accepts certain equivalences must be able to switch off the equivalencing within string quotes. It is recognised that not all problems of this nature can be solved elegantly.
It is desirable that if possible all systems which include one-to-one equivalences should use the same equivalences. We should decide on a set of standard equivalences and if necessary change existing systems to conform.
Following this idea further, we define a BASIC CHARACTER SET which can be represented on all devices with certain one-to-one equivalences. A suggestion for this character set is given as basis for argument. The character set consists of
A - Z 0 - 9 ) ) These are available + - . / ) ( ) = space ) on all devices.
All systems/languages should be capable of accepting input in the basic character set, though this does not prevent them using other characters when these are available. The main implication of this rule is that systems that make use of composite characters and lower-case letters should provide an alternative input mode.
The following equivalences are suggested as good practice.
|*||Suffix 10||*||* (in numbers)|
Updated internal code tables are attached: note that internal codes have been assigned for GPO Telex characters.
|A =||ASCII (On-line Consoles & PDP7 8-track tape)|
|F =||Titan Flexowriter (7-track tape)|
|T =||Titan Teleprinter (5-track tape)|
|P =||Line Printer|
|M =||Mercury Autocode Teleprinter (5-track tape)|
|C =||FORTRAN Card Code|
|G =||GPO Telex|
|ALL =||all devices at present available|
|(1)||These characters change to the other set of internal code and do not correspond to anything on the external device.|
|(2)||Redundant shifts are ignored during input. Appropriate shifts are automatically inserted on output, and it is never necessary to output an explicit shift character.|
|(3)||On output, run-out is upper-case on 7-track tape, blank tape on 8-track or 5-track tape (Titan or Mercury). On input 7.3 will only come from 5-track Titan code tape, (since blank tape is figure shift in Mercury code) or from 8-track tape.|
|(4)||Bogus characters not explicitly rejected are translated to 7.7 inner set.|
|(5)||These codes are identical with the corresponding inner set codes for upper case letters.|
|(6)||Erase will never occur on input from 5-track Titan code tape, since it is identical with figure shift.|
If no chacacter is indicated, the code is unassigned at present and should not be used.
(NL = Newline, CR = Carriage Return, LF = Line Feed)
|0.1||LF not immediately preceded by CR|
|2.0||CR not immediately followed by LF|
|2.1||NL or CR followed immediately by LF|
|4.0||FORMFEED||Consoles & 8-track tape|
|4.1||VT||" " " "|
|0.0||Dummy : may occur in binary streams, or streams from magnetic tape/disc, or from consoles.|
|0.1||*||*||No CR, 1 LF|
|0.2||*||*||" 2 LF|
|0.3||*||*||" 3 LF|
|0.4||*||*||" 4 LF|
|0.5||*||*||" 5 LF|
|0.6||*||*||" 6 LF|
|0.7||*||*||" 7 LF|
|1.0||*||*||" 8 LF|
|1.1||*||*||" 9 LF|
|1.2||*||*||" 10 LF|
|1.3||*||*||" 11 LF|
|1.4||*||*||" 12 LF|
|1.5||*||*||" 13 LF|
|1.6||*||*||" 14 LF|
|1.7||*||*||" 15 LF|
|2.0||Ignored||Ignored||CR, no LF|
|2.1||Print with 1 LF||1 NL||CR + 1 LF|
|2.2||" " 2 LF||2 NL||CR + 2 LF|
|2.3||" " 3 LF||3 NL||CR + 3 LF|
|2.4||" " 4 LF||4 NL||CR + 4 LF|
|2.5||" " 5 LF||5 NL||CR + 5 LF|
|2.6||" " 6 LF||6 NL||CR + 6 LF|
|2.7||" " 7 LF||7 NL||CR + 7 LF|
|3.0||Print with 8 LF||8 NL||CR + 8 LF|
|3.1||" " 9 LF||9 NL||CR + 9 LF|
|3.2||" " 10 LF||10 NL||CR + 10 LF|
|3.3||" " 11 LF||11 NL||CR + 11 LF|
|3.4||" " 12 LF||12 NL||CR + 12 LF|
|3.5||" " 13 LF||13 NL||CR + 13 LF|
|3.6||" " 14 LF||14 NL||CR + 14 LF|
|3.7||" " 15 LF||15 NL||CR + 15 LF|
|4.0||Advance to next page||Ignored||Ignored|
|For Teletypes and ASCII :||6.0||ALT MODE|
|For all other devices except plotter|
|6.0 to 7.7||Ignored||Ignored||Ignored|
|*||Equivalent to same code with 2 added|
|**||Equivalent to 4.0 at present, but should not be used|
|***||Equivalent to the
same code with 4 subtracted.|
(For Teletypes and ASCII, 4.1 gives VT)
Carriage control characters have a special significance for the plotter - see separate description of plotter software.
Copyright © 1966 University of Cambridge Computer Laboratory. Distributed by permission. Thanks to Barry Landy, Roger Needham and David Hartley for giving permission to distribute these documents. Thanks to Barry Landy for lending me the paper document from which this was scanned. Any typographical errors probably arose in the course of OCR.
Previous Planning Document: 16. Commands and Job
Organisation, AGF, 12 September 1966
Next Planning Document: 18. Further Thoughts on P.D. 17, MVW and DWB, 28 September 1966
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page