Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewPaper 1Paper 2Paper 3Paper 4Paper 5Paper 6Paper 7Paper 8Paper 9Paper 10Paper 11Paper 12Paper 13Paper 14Paper 15Paper 16Paper 17Paper 18Paper 19Paper 20Paper 21Paper 22Paper 23Paper 24Paper 25 revPaper 25Paper 26Paper 27Paper 28Paper 29Paper 30Paper 31Paper 32Paper 33Paper 34Paper 35Paper E
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLLiteratureProgress ReportsTechnical Papers :: Literature: FR80 Technical Papers
ACLLiteratureProgress ReportsTechnical Papers :: Literature: FR80 Technical Papers
ACL ACD C&A INF CCD CISD Archives
Further reading

OverviewPaper 1Paper 2Paper 3Paper 4Paper 5Paper 6Paper 7Paper 8Paper 9Paper 10Paper 11Paper 12Paper 13Paper 14Paper 15Paper 16Paper 17Paper 18Paper 19Paper 20Paper 21Paper 22Paper 23Paper 24Paper 25 revPaper 25Paper 26Paper 27Paper 28Paper 29Paper 30Paper 31Paper 32Paper 33Paper 34Paper 35Paper E

Paper No 28: Monitor Command Handler

D C Sutcliffe

21 August 1978

Layout of CH01TABLECM

CH01TABLECM contains all the monitor commands in character form and all their arguments in character form. It is used for two purposes.

  1. To recognise by comparison monitor commands read from the tape or teletype.
  2. To act as the data supplied to the HSCG to display the commands and their current values on the monitor.

The design of the table takes into account both these functions. A monitor command may be shortened (from its complete form) to any number of characters provided that at least the shortest unambiguous string is included. However, it was decided to check all characters input and to give an error if the total input string is not a substring of one of the commands. (The reasoning behind this is that the monitor commands will normally either come from a tape produced by a host package or be typed in by a trained operator on the FR80. In either case the shortest unambiguous strings will most commonly, if not always, be used. Hence, if a string is received which produces a mismatch from a command after the shortest unambiguous string, it is quite likely that the string received was thought to be a non-existent command and this ought to be errored).

The format of a command in the table is as follows:

<shortest unambiguous><one or more> <remainderof><slash><values as><crlfs>
         string           nulls        command          characters 

with characters packed two to a word and the terminating <crlf> in the same word. After the last command there is an extra <crlf> to signify there is no following command. The one or more nulls after the shortest unambiguous string are used to mark the end of it. Only one null is necessary but it is difficult to set up the table this way. A macro is used and this results in two or three nulls being inserted.

Nulls are used so that the monitor display is unaffected. Similarly, in the values part, number fields are filled out with nulls rather than spaces to improve their appearance on the monitor. (Of course, spaces are used after the slash and after commas to improve readability).

If the TITLE, BROADCAST, or MESSAGE commands have text string arguments which are longer than one line, the newline sequence is stored as a newline character, rather than <crlfs>, so that it will not be confused with the command separator (<crlf> in the same word) in the table.

Recognition of Command

A command is recognised by comparing it character by character with each command in the table until a match is found. The comparison is done on the least significant seven bits of the character since the teletype handler only returns seven bit characters but the HSCG uses the table and requires eight bit characters. If a terminator is found in the input command before the null in the table command has been reached, the input command is errored as ambiguous; if it is found at or after the null has been reached the command has been recognised. If a mismatch occurs between the table command and the input command, then the next table command is compared. If there is no next command (signified by the first word of the command being <crlf>) then the input command is errored as unrecognisable. Otherwise if a match occurs, the comparison continues with the next pair of characters. The search is performed by obeying the action corresponding to the first comparison which is true, in the following table.

Table Character       Input Character                      Action
null                  terminator (/:=)             Set "recognised" Advance ip ptr. Search completed
null                  anything                     Set "recognised" Advance ip ptr. Continue search
anything              terminator (/:=)             If "recognised". Advance t ptr. Search completed
                                                   If not "recognised". Error ambiguous command.
                                                   
anything = ip ch      anything = table ch          Advance ip and t ptrs. Continue Search.
anything ≠ ip ch      anything ≠ table ch          Mismatch. If next command set t ptr and reset ip ptr. Continue Search.
                                                   
                                                   If no next command. Error unrecognised.

Each time a new command is looked at, a counter is incremented. When a command has been recognised, the counter gives the position of the command within the table. This counter is then used as the index of an integer case statement, which selects the appropriate piece of code to obey the command. The exits of the case statement are named with names of the form CHEddl where dd are two digits and l is a letter. Initially all the exits will be of the form CHCddA, and the two digits will be in ascending order starting at 01.

Adding a command to the command set

A command may be added to the set as follows. The character form of the command together with the default arguments in character form terminated by a single word <crlf> are added to the table in their alphabetical place. If the new command alters the shortest unambiguous string of any other commands, then these commands must be altered in the table and suitable documentation released regarding the change in the operator and package interface. The table size will have increased and CH09TABLESIZE should be updated. If a long command has been added, some of CH31MAXSEARCH, CH32MAXLENGTH, CH37CLENGTH, and CH38VLENGTH may need to be updated. A new exit is made in the case statement in the appropriate place both in the selection part and in the list of exits. Its name is formed from the name of the immediately previous command by replacing the last letter by the next in the alphabet, e.g if the exit for the previous command is CHC11A, then the new exit will be CHC11B. This method means that the order of the exit names is the same as that of the commands in the table and little effort is needed to maintain this.

Displaying the command buffer

The command buffer containing the command input will also be displayed on the screen. For this reason it must follow the command table in core so that only one HSCG command need be given. It is also the reason why it is reset to nulls on receipt of CTRL X rather than just the pointer being reset.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site