The period 1979-1980 showed a fast expansion of the number of asynchronous
terminals of the Newbury brand. During the selection of the standard Laboratory
terminal, the users' commission took into account many aspects like function
keys, screen color (green) and the noise production of the terminal.
The CDC mainframes' CDC 6671 data communication controller was replaced by a CDC 2551, a mini-computer with 96 Kwords, 16 bits. This system had 32 slots for Communication Line Adapter boards (CLA's). The Laboratory had four synchronous CLA's (2 lines each) and 28 asynchronous CLA's (2 lines each) boards. After the installation, the 110/300 baud dial-up modems refused to do their work. After using an electronic scope - system programmers had to know about many different perks! - the problem became clear. The very fast processor sampled the data communication signals much faster than before. The ring-signal (ring-indicator) of the ENA-modems had many spikes causing the 2551 to switch off the lines. Modifying the modem by adding large condensers stabilising the modem solved the problems.
Note that the 2550 was derived from the Cyber 18, which was actually the semiconductor
version of what had originally been the discrete-transistor CDC 1700. The CDC
team working on the 2550 started talking about how they would decide on a name.
One of them pointed out that they had crammed so much extra stuff in it that
it was "half again better than a 1700". This resulted in the type
number 2550 as it equals 1700 x 1.5. (with special
thanks to Tim Roberts who provided this inside infromation)
The system program running in the 2551 was very complex. It consisted of about 700 pages of code written in a Pascal-like programming language, several hundreds of pages microcode (state tables) and assembler code. As the CYBER usually used 6-bit code, the PP's used 12 bits code and the 2551 used 16-bits code, very complex cross compilations were required to obtain a byte of 2551 executable code. At the end, the 2551 was started by a PP-program that loaded the 16-bit based executable code. A simple compilation could last three to four hours at the CYBER 74.
In the beginning of 1981, we tried to upgrade to a new version of the total interactive operating system (INTERCOM). The upgrade from INTERCOM 4 to version 5 did not went smoothly. The synchronous links with the PDP's minicomputers at the LEOK, PML and IZF did not work. The MUX200 emulated "card jobs" gave at their side the message "slipped card". However, at our Laboratory side, we could not see or even find the text of that message. No card jobs were found either. Even additional trace code did not show irregularities. Reasons enough to rent a data analyser. And yes, after studying the protocol blocks of a batch job on the CDC 734 and a batch job of the LEOK, the cause of the problem became clear. An end-of-record card required the indication (punches) of two bytes to signal the record level in card column 1 (Escape E4). The UT-200-emulation code in the PDP minicomputer padded the Esc-E4 with 78 blanks. Under INTERCOM 4 the rest of the card was ignored, thus no problem. Intercom 5, however, was much stricter in reading 'cards' and required 79 additional card columns. The emulator generated already for years one card column less. PML, maintainer of the emulation code, made a small change in the PDP-code in order to solve this problem.
To demonstrate the proper working of the photo plotter, several members of the Computer group developed an unusual test. At that time, computer experts collected so-called "printer pictures". Those were pictures being built-up from repeatedly overprinted lines. Specific combinations of overprinted characters gave another impression of the "grey value". The new photo plotter was reason enough to plot one of the "pin-up girl" printer pictures. That required some manipulation of the grey-values. That was not enough. Almost without visible discontinuity, a female picture was constructed having four breasts. After calculation of the grey values this "computer genetic-manipulated" beaty was given a photo-realistic reality.
The CYBER - DCS interconnection was based on the HASP-protocol. HASP (Houston Automatic Spooling Program) is a by IBM developed communication protocol for synchronous lines. HASP could drive multiple datastreams at the same time over the same line. After initial tests with data transports on basis of card- and printer images (columns and lines) the project leader read in March 1982, that HASP supported transparent streams as well. Once again, the Laboratory's Computer group detected a less tested corner of the INTERCOM system. As soon as the transparant buffers exceeded the (line printer limit) of 137 characters, the CDC 2551 restarted with a fatal error message. At the same time, all unsaved typed characters and command results were lost. Using another test sequence that tried to explore the data compression part of the transparent HASP protocol, the 2551 software went into a loop. Time for systematic tests and analysis of dumps and code. We finally figured out that a combination of two errors in the microcode resulted in the "eating" of memory buffers, causing the 2551 to become slower and slower. After solving these problems, we increased the transport of the information blocks to the highest limit allowed by the protocol (some Kbytes). As transparent HASP, supports a simple data compression mechanism, an effective line utilisation of over 100% could be achieved.
To make effective and efficient use of this expensive system, it was decided to edit all programs on the CYBER 74. At the same time, all libraries and data was stored on the CYBER as well. The expensive and large CYBER 74 became a front-end for the Data conversion station, which in turn was a front-end for the MDS system. Command Control Language procedures (CCL) were developed to put jobs into the MDS-queue on the CYBER. Other procedures that could be called from within the MDS loaded files and libraries from the CYBER onto the MDS.
Reason enough to obtain the source of the TAB 132/15 microcode and to
write the feature code ourselves. The program was adapted by several microcode programmers
and compiled on the MDS system. The localised version was baked into an
EPROM and put into TAB 132/15 terminals.
The programming features of the new terminals introduced new security problems. Complete login-commands including the passwords could be found under the function keys.