This note will look at ways or implementing the basic parts of an on-line system within the framework of the Cambridge supervisor and examine some of the problems associated with it. Some general principles were borne in mind:
There follows a brief description of some of the more important features of the Multiplexer. More detail is contained in the document "The Provisional Description of the Multiplexer".
The Multiplexer has a one character buffer for each of 64 lines. There is one Titan V-store line and one associated LAM. The multiplexer will be Data Channel 2 (interrupt priority group 3 - above tape readers but below card punch and line printer). The maximum usable information transfer rate is 640 characters/sec. (This corresponds to all 64 devices (i.e. typewriters) working at their maximum 10 characters/sec. rate.) Reading and writing are both two stage processes. Reading the V-store once gives the line number (or device number) and its status. The V-store then has to be switched (by writing to it) and then read again for the character. The following line states are possible.
| (1) Read | (2) Write | (3) Error | (4) Ignore ones |
| (5) Null | (6) Reflect read | (7) Reflect write |
Error Status can be set in a variety of ways:
Two routes are to be provided for data coming from the Multiplexer.
Stream Format: The information rate from the typewriters is so low that a simplified stream format could be adopted without incurring too heavy space penalties. The suggested format is one internal code character per half-word and one line of input per blocklet. In the case of route (2) the translation to normal stream format will be carried out by an SER.
This would enable a line of about 120 characters to be held. There is no problem with the Telex. It has no backspace, and if it were agreed that an overprinted character at the end of a line be ignored, the longest line could only have 60 characters. With a device possessing backspace a line of more than 120 characters is not impossible and a convention would have to be adopted as to what would happen if this were exceeded. It may be necessary to inform the user that this has happened and give him the option of deleting the whole line. (The facility of being able to delete a line is so important that the system itself will have to provide it.) The deleting facility would only be of use if data were being read by the read record extracode.
Link with the Object Program: The on-line stream will look to the object program just the same as any other input stream. It will be read either by the read character or by the read record extracode. These will give either character by character or line by line interactions. Because of the differing stream formats the extracodes will have to be switched according as to whether or not the stream is direct.
The input extracodes normally feed off blocklet streams hung from the Object Program's SOPIS base (the base itself being used as a working space dump for the extracodes), and the same method could be adopted for the switched extracodes. This would have the advantage of making the handling of the two types of stream compatible. There are several disadvantages, however.
Each line will have associated with it some fined area space (a genuine SER base?) to record fixed information about the line - such as its status and the type of device attached to it (probably in the form of a translation table pointer). Since there is only one direct input stream per line, while there might be several direct streams per object program, it seems more natural to associate the stream with the device base than with the object program to which it will eventually be routed. Further, it is desirable to make the transfer of a character from a device to the current blocklet as efficient as possible to minimise the number of orders on interrupt control, and it will take longer to chain through the object program's SOPIS base to store the character than to go via the device base.
It may be that this makes the reading of the stream by the object program more inefficient, but this matters less as it is done in Class 1 and Class 2. There will have to be an indication in the SOPIS base of the existence and location of any direct streams the object program may have - set up by the create and select stream extracodes.
The statement of which streams are in fact direct can be made either via the job description or direct from a console - making use of the proposed 'create stream' extracodes.
Its input is sent to an object program more slowly than it is being consumed, the program will be halted awaiting input, and a mechanism for freeing the program when more input arrives will have to be implemented. The interrupt routine could look to see if the object program associated with the line carrying an input character is in fact halted awaiting input, and if so queue an SER to free it (the freeing can only be done in Class 2). The freeing SER will be of the 'queued if inactive' type and could be queued on its own base (as a general service routine for all lines) or on a particular device base (assuming this has been set up as an SER base). In the former case a count of object programs halted for input could be kept to speed up the search for object programs in need of freeing. It might be possible to have a one way chain from the SER base through the OPSER bases of those object programs needing freeing. This would be most conveniently added to in Class 2 - there may be problems if the freeing SER were interrupted for an addition to be made to the chain in Class 3.
Would it be too restrictive to have only one chain of blocklets for input/output per device base? This would work in the normal case where the user is either typing and not expecting output, or receiving output and not typing. There may be times, however, when it is desirable to output without first clearing the input buffer. For example, a user could use the time between the start of execution of his object program and output of results, to type in data he knows will be required after the printing phase. This introduces the possibility of an untidy page layout as output from Titan will occur without warning. The danger is that the user will not be sure how much of his input has actually been received. It may be necessary for the system to tell him (if it detects that a clash between input and output has occurred).
Space Shortage: After a complete line of input has been received, a new blocklet will be requested for the next line. If this is unavailable the user will have to be told to stop typing until the new blocklet arrives. With one line per blocklet it is likely that the 'wait' message will occur at the beginning of a line. It is possible that this message will corrupt some of the users input and some form of safety mechanism is essential. One solution would be to print out the current blocklet (i.e.as much of the current line as had been received) before or after typing a 'continue' message.
It would be possible to keep a pool of blocklets for use by direct streams and to inform the user when this is running low. The same problems of corrupting input while in write status still occur.
It may also be desirable to set an upper limit to the amount of backlog on any one stream, though the space shortage mechanism described above is all that is strictly necessary.
Some means of interrupting the current activity at an unpredictable time is necessary. The user may wish to suppress printing or his program may be in a loop or he may be in input mode and wish to cease inputting. The only way of engaging the machine's attention in the first case is by causing error status to be set. This can be done by pressing the break key or by repeated typing of any character. The break key would be the most suitable method of interrupt. Project MAC uses it for this purpose and performs differing actions depending on the number of times it is pressed within a certain real time. The main disadvantage is that break is conventionally used by the Telex network as a 'disconnect line' signal. Thus the use of break as an interrput character would preclude the use of the on-line system via an external Telex line. The repeated pressing of some character, conventionally agreed for the purpose, is the alternative. A character which is not normally used and which contains a high proportion of 'ones' would be required. Different actions would now be needed depending upon whether the line was in read or in write status. When in read status (as the line might be when a program is running, or halted waiting for input) the character would have to be recognised by its specific value - it would not cause a line-status change.
The 'reading' V-store layout proposed in the document "Provisional Description of the Multiplexer" is as follows:
| 24 | Disengaged | ||
| 25 | Unused | ||
| 26 - 31 | Address | ) | or character |
| 32 - 34 | Status | ) | |
| 35 | Request Active |
The following arrangement, however, would seem to have several advantages:
| 24 | Disengaged | ||
| 25 | Request Active | ||
| 26 - 28 | Status | ) | or character |
| 29 - 34 | Address | ) |
If the sections of fixed area associated with each device were 4 words apart, they could be naturally addressed by the address (or device pointer) read direct from the V-store, No space will be wasted as at least 4 words of fixed area per device are likely to be needed. If more is required, it can be addressed by the device pointer + some suitable large parameter. Moreover, the status bits are in the most suitable position for a look-up table jump on their value - impossible (in the same number of orders) with the first-mentioned scheme.
JCV
9 November 1965
Copyright © 1965 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: 6. A Proposed File
Dictionary System: I - External View, DWB, 28 July 1965
Next Planning Document: 8. The hidden costs of
line-numbering systems, RMN, 11 November 1965
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page