Interactive service to MSU's CDC mainframes was provided by Interdata 7/32 minicomputers, starting around 1976. Prior to that, interactive service was provided by proprietary Control Data hardware.
The Interdata 7/32 was the first 32-bit minicomputer. (The better-known VAX came later.) Its instruction set resembled that of an IBM 360. I believe that, like the later Motorola 68000, its memory was 16 bits wide, but this fact was transparent to software. Interdata was acquired by instrument maker Perkin-Elmer subsequent to our purchase of the initial 7/32, so eventually we referred to the machines as Perkin-Elmer 7/32s.
Initially, we had only one front-end per host. It was attached to a CDC channel via an interface designed by MSU hardware engineer Peter Chen. Later, we devised a way of allowing multiple front-ends to connect to the same host. The front-ends shared information via shared memory.
On the host side of the interface, a PP program named 1FP handled communications with the 7/32. 1FP passed data to and from the host CPU program Manager; for more information, see Interactive Use.
The 7/32s ran an operating system developed entirely by MSU's Systems Development group. During development, the system was known as GREASY, for reasons I never knew. The production name of the system was FREND.
FREND was written entirely in COMPASS, CDC's assembler. A systems text (collection of macros and symbols) allowed cross-assembly. At boot time, the entire FREND was loaded over the channel. (There was no disk drive.)
Compared with CDC CPU and PPU coding, there was plenty of memory in the 7/32. This allowed us to program without overlays and without undue concern over code size.
7/32's were attached to Data Printer Corp printers via Data Products-style parallel ports, and to terminals via asynchronous serial lines. For terminals inside the Computer Center, the serial lines were hardwired directly to the terminals. This saved the cost of a pair of modems and a pair of phone lines, and allowed for faster terminal rates. Other serial lines were attached to 300 and 1200 bps modems.
Terminal I/O within FREND was very line-oriented. Each terminal had associated with it about two input buffers and five output buffers. Each buffer could hold 140 (?) characters. This allowed FREND to accomodate terminals with wide carriages; for instance, a DECwriter LA36 could print 132 characters per line. In some cases, I/O had to be done that was not line-oriented. For instance, output to a Tektronix 4010 graphics terminal was a continuous stream of ASCII characters. Also, a user might want to do binary file uploads or downloads. (This later capability became commonly used only in the later days of SCOPE/Hustler, when microcomputers started to become popular.)
FREND could be used with non-line-oriented applications, but internally it retained its line orientation. When a terminal needed to send binary data to the host, FREND was instructed to pass on the accumulated characters as a line when some preset character count <= 140 had been received. Likewise, when the host needed to send non-line-oriented data to the terminal, FREND was instructed to not send a carriage return / line feed after each line buffer received from the host.
For most interactive users, the presence of the front-end was transparent. They dialed up and logged directly onto SCOPE/Hustler without having to type in configuration commands or select a host. However, there were several dozen front-end commands available.
%BINARY
%TERMTYPE,CRT or LA36
%ECHO,ON|OFF
delay
FECMD
%INLEN
front end,