Computer history: Data communication (1978 – 1983)
Data communication (1978 – 1983)
CDC 2551 data communication processor
The period 1979-1980 was marked by the rapid expansion of the number of asynchronous Newbury terminals. In the selection by a user committee, things such as function keys, screen colour (green), and low-noise fans played a role. The old and slow CDC 6671 data communication controller was replaced by a CDC 2551, a minicomputer with 96 16-bit words. This computer had 32 slots for Communication Line Adapter boards (CLAs). The Laboratory had four synchronous CLAs and 28 asynchronous CLAs. After the transition, it turned out that the 110/300 baud dial-in modems no longer worked. After the ‘scooping’ of the electric signals in the modem – system programming had to have many skills – the problem became clear. Due to the much faster processing of data communication signals by the CDC 2551, the system was sensitive to non-stabilised call indicator signals. The relay to detect a dial-in signal in the 110/300 baud EMA modems made contact, bounced off and made definitive contact. The data communication software, however, detected a dropped line. The solution consisted of modifying the modem with a large capacitor over the relay contacts.
The serial number 2550 started as a joke. The designers of the cabinet of Cyber 18 (the successor of the CDC 1700) crammed 1.5 times as many logic plates in the system causing it to be ‘50% better than a 1700’. That resulted in the system name 2550 (1700 x 1.5). (with special thanks to Tim Roberts who provided this inside information)
The system software of the 2551 was very complex. It consisted of some 700 pages of code in a Pascal-like programming language, several hundred pages of microcode and an assembler. Because the CYBER worked with 6-bit/60-bit word code, the PPs with 12-bit code and the 2551 executed the software in 16-bit code, rather complex cross-compilation and data compression had to be performed. Finally, the 2551 had to be loaded by a PP program. Compilation, loading and reformatting of a new version of the data communication software, for example, to patch an error, took three to four hours on the CYBER 74.
In early 1981, an attempt was made to switch to a new version of the interactive part of the operating system (INTERCOM). The transition from INTERCOM 4 to version 5 did not go smoothly. The synchronous links with the PDPs of the LEOK, Prince Maurits Lab TNO (PML) in Rijswijk, and the TNO Institute for Sensory Physiology (IZF) in Soesterberg failed to work. The MUX200 emulated card jobs gave the error message ‘slipped card’. At the Physics Laboratory side, it was not visible that a card job had been received. Even after adding extra logging code, we could not pinpoint the problem. The error message could not be found in the system software. Reason to rent a data analyzer. After examining the protocol blocks of a batch job that was read by the CDC 734 batch terminal punchcard reader that also used the same Mode-4 UT-200 protocol as the emulator, the problem became clear. A so-called end-of-record card that acted as the separation between jobs required two communication bytes for the record level mapped into column 1 (Escape E4). The UT-200 emulation code in the PDP supplemented the card image with 78 spaces, a total of 80 characters. Under INTERCOM 4, the remainder of the card image was discarded after receiving the E4 code.
INTERCOM 5, however, counted the number of card columns -or tokens- read. In this case, the E4 code plus 78 spaces, a total of 79 tokens. One short, hence the message ‘slipped card’. After this analysis, the problem was soon resolved by colleagues at TNO PML where the emulation code was maintained. A so-called end-of-record card as a separation between jobs required two bytes for the record level in map column 1 (Escape E4). The UT-200 emulation code in the PDP filled the card with 78 blank characters, a total of 80 characters.
DATUS 5810 port selector
In order not to match the rapidly growing need for asynchronous terminals with the same amount of ports on expensive Communication Line Adapters (CLA) boards in the CDC2551 and also to be able to access more computer systems from the workplace, a 32 port DATUS 5810 port selector was installed at the end of 1982 / beginning of 1983. The DATUS port selector worked as a kind of telephone exchange for data communication connectivity. At one’s desk, one could choose the desired connection with one of the central systems or reach external telecommunication services, in our case Datanet-1 packet assembly/disassembly (PAD) and dial-out modems. The DATUS has eventually evolved into a system with many dozens of incoming and outgoing lines. The DATUS post selector was in use until 1993. After that date, the built-in dial-up security module (DUS) was kept operational until 1995.
Single Board Computers (iSBCs)
Many graduated students, who had to fulfil their military duty at the Laboratory, were involved to develop code for the Intel Single Board Computers (iSBCs) with 8085/85 microprocessors. These iSBCs were used as interface/controller for the special I/O equipment that required connection to the CYBER 74 via asynchronous lines. Examples: the magnetic cassette reader, the papertape reader, the papertape puncher, a PROM programmer, and a photo plotter (belonging to the Synthetic Aperture Radar group). All the data ‘communication’ software was developed at the Laboratory. Much later, the main controller was changed and connected to the Data conversion station, a DEC system.
To demonstrate the proper working of the photoplotter, 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 on that system. 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 the calculation of the grey values, this computer-genetically manipulated beauty was given a photo-realistic reality (thus we faced the first “AI” modified photo).
Data conversion station (DCS)
To couple and drive CYBER-strange equipment, the PDP 11/34 Data Conversion Station (DCS) was installed in 1981. This DCS was the replacement of the very old Cyber 18-17. The DCS supported nine data streams, two for input to the Cyber 74 and seven for driving output equipment. These streams were: papertape read (Facit 4020), papertape punch (Facit 4070), printing on the DAISY-wheel printer and the C.ITOH-matrix printer, controlling the Calcomp 1051 plotter (May 1983), reading floppy-disks (14″ !), reading magnetic data cassettes (Facit 4203), the Micro Development Station, and data streams to/from the PDP 11/60 for exchanging graphics data. The PDP 11/34 minicomputer operated under the RSX 11/M operating system, had 256 KB memory and two exchangeable RL02-disks of 10.4 MB each. The total system costs were Dfl 200.000.
The CYBER – DCS interconnection was based on the HASP protocol. HASP (Houston Automatic Spooling Program) is an by IBM developed communication protocol for synchronous lines. HASP could drive multiple data streams at the same time over the same line. After successful initial tests with data transport based on card and printer images (columns and lines) in March 1982, the project leader read, that HASP supported transparent streams as well. Once again, the laboratory’s Computer group detected a less-tested part of the INTERCOM system. As soon as the transparent buffers exceeded the (line printer limit) of 137 characters, the CDC 2551 data communication controller restarted with a fatal error message. At the same time, all unsaved typed-in 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 long). As transparent HASP supported a simple data compression mechanism, an effective line utilisation of over 100% could be achieved.
Micro Development Station (MDS)
The Electronics development group started developing code for microprocessors in the early eighties. They required support for developing microprocessor software. The Micro Development System (MDS), an INTEL MDS 231, was bought. It supported software development for the 8080, 8085/8086 and 2920 microprocessors. The compilers available on the MDS system were: PL/M, Fortran80 and Assembler.
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 were stored on the CYBER as well. The expensive and large CYBER 74 became a front-end for the DCS, 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.
The TAB 132/15 terminal/model Physics Laboratory TNO
The requirements imposed by the Laboratory on the ‘standard terminal’ could not be satisfied by the market. The terminal had to allow ‘on-screen’ editing, whereby the terminal had to offer the same possibilities in combination with the CYBER, PDPs and Data General computers. Series of characters and function codes had to be stored under function keys, whereby a ‘self-learning’ mode and downloading from the computer should be possible. In agreement with the manufacturer, TNO modified the TAB 132/15 microcode to fulfil the set of requirements. Our microcode programmers changed the microcode source. Thereafter, they translated the code on the MDS into executable microcode. The locally adapted version was then ‘baked’ into EPROM and installed in the TAB 132/15 terminal. However, the programming features of the new terminals resulted in security problems. For example, complete login messages including the passwords could now be stored by users under a function key. A message could also be sent to another terminal with escape codes. Security code had to be developed to block messages such as ‘<escape code go to the top of screen>, logout, <escape code send screen>’.
