GEC 2050

The GEC 2050 was an 8-bit minicomputer produced during the 1970s, initially by Marconi Elliott Computer Systems of the UK, before the company renamed itself GEC Computers Limited. The first models were labeled MECS 2050, before being renamed GEC 2050.

The GEC 2050 was commonly used as a Remote Job Entry station, supporting a punched card reader, line printer, system console, and a data link to a remote mainframe computer system, and GEC Computers sold a complete RJE package including the system, peripherals, and RJE software. Another turnkey application was a ticketing system, whose customers included Arsenal Football Club. The system was also commonly used for road traffic control and industrial process automation.

The GEC 2050 supported up to 64KiB of magnetic-core memory (minimum 4KiB, expandable by 8KiB and 16KiB modules). Weighed 41 kg (90 lbs). The system had a single Channel Controller for performing autonomous I/O, and used the same peripheral I/O controllers as the GEC 4000 series minicomputer.

Instruction set
Although CISC, the instruction set is sufficiently simple to be tabulated in its entirety:

Using the opcode 29 as an illustration, the assembler code (AD X2,X1,offset) causes the contents of the memory location 'offset(X1)' to be added to register X2. Thus, register X1 is being used as the index register, and the offset, v, is specified in the second byte of the instruction. G is a dummy index register whose value is always zero, and hence causes the offsets to be treated as absolute addresses in the zeroth (global) segment. (Incidentally, since X3 is the standard index register, the assembler program allows ',X3,address' to be abbreviated to ',address'.)

The conditional jump instructions are listed in pairs, the former opcode is for a forward jump, and the latter one for a backward jump. Again, the offset of the jump is obtained from the second byte of the instruction. Thus, all instructions in rows 0 to 7 and row 9 consist of two bytes (the opcode and a data byte) while all the other instructions consist of just a single opcode byte.

The main accumulator register, A, can be set to be 1, 2, 3 or 4 bytes in length, using the SETL instructions. This controls how many bytes are loaded (or stored) in a memory-access instruction. The JIL instruction performs a Jump Indirect, like the JI instruction, but saves the value of the program counter, S, into index register X2. This allows very simple non-recursive subroutine calls to be achieved. More complex subroutine calls involve the use of the PREP instruction, which saves the return information in the first bytes of the current memory segment. Such calls, too, cannot be recursive.

User experience
This section describes a work session on this computer, at one typical installation in 1975. The programmer might arrive, to work on a Fortran-II program that he had already started writing in the previous session, carrying a teleprinter paper listing of that program that has been annotated with the new changes that are to be made, and the punch tape that contains the machine-readable source code of the program. He would first need to turn on the computer at the switch on the conventional mains socket on the wall, and then at the front-panel on/off switch. Since the magnetic core memory, which is non-volatile memory, would generally still contain the previous user's program, the programmer might need to load the punched tape called Minisystem (containing the object code of a small, memory monitor program). This tape, which was stored in a small cardboard box on a shelf near the computer, would be entered from the left of the tape-reader. The tape-reader was an integral part of the front panel of the computer, and would spill out the tape that it had read, on to the floor, on the right-hand side. Once read, the Minisystem could be started by flicking the Run switch on the front panel.

COMMAND >L

L      049A A      0522 D      063E LINK   0691 EDIT   1090 MAIN   155E 28A2   3FFF

>

The text editor program, EDIT, could then be called from the teleprinter keyboard, at the Minisystem's '>' prompt. The programmer would then load the source tape into the reader, and while this, too, was being read in, and spilled out all over the floor, the programmer could be busy winding up the Minisystem tape, into a tidy reel again, using a hand-turned winch.

Eventually, once the source tape had finished being read, the text editor program would prompt for a new command, which was the invitation to edit the program. Though having changed little in effect over the decades, editing has changed enormously in feeling: only one line of the program was 'displayed' at a time (physically printing it out on the paper); inserted text was printed below the point in the line where it was being inserted, and the rubout key merely crossed-out the text that was to be deleted; the string-find and string-substitute facilities were very rudimentary; and the teleprinter worked at 110 baud (making an enormous clunking and whirring racket as it did so).

At the end of the edit session, the new version of the source program would be output: both as a typed listing, and as a new punched tape. Whilst the paper-tape punch was doing this, again spilling out its product (albeit not so fast as the reader, and off to the left of the machine) from its front panel mounting, the programmer could be winding up the old version of the source tape, for it to be kept as a backup version. The free end of the new tape, which was still being punched out, could be labelled in pencil with its program name, version number, and date of punching.

Unfortunately, with only 16 KiBytes of core store, the Minisystem and Fortran compiler would not both fit in memory together, so the next stage would be to load the Fortran compiler tape (which was stored in another cardboard box on the shelf in the computer room). Whilst this was being read in, and spilling out the other side, the newly punched source tape could be torn off from the free end that was protruding out of the punch, and wound up using the hand winch. It would be loaded into the tape reader once the compiler had finished being read in, and the compiler tape would be wound back into a tidy reel.

The first pass of the source tape through the tape reader was generally used just for checking for syntax errors in the program, so the generation of the object tape from the tape punch would be suppressed. If any errors or warnings were detected, it would be necessary to load the Minisystem tape again, and to run the editor program to make the corrections, and to generate a new version of the source tape. Otherwise, the source tape could be wound up again, and loaded back into the tape reader for a second pass. This time, it would be read in, haltingly, whilst the paper tape punch worked flat-out to produce the corresponding object tape (usually two or three times longer in length than the Fortran source tape).

At the end, with two tapes all over the floor, the Minisystem would have to be read once again, whilst the object and source tapes were being wound up. The linking-loader program, LINK, could then be called from the keyboard, at the Minisystem's prompt, and the object tape fed through the reader. The linking-loader also required the library tape, containing the Fortran library functions, to be loaded into the reader. Both tapes would eventually need to be wound up, but this tended not to be done immediately, because of the programmer's eagerness at finally being in a position to run the program. The user's program (called MAIN) could be called at the Minisystem's prompt.

Depending on what happened during the program execution, the programmer might need to read the newest source tape back in to the editor program, yet again, ready to go round the software development cycle once more.