Unit Record Controller

The Level 64 system was completely dependent on functions implemented in a separate special mini-processor, also used for unit record devices ((card devices and printers) control called the URC (Unit Record Controller). As far as customers are aware of it, it was known as Unit Record Processor.

Origin of URC

The concept of the URC was introduced during the summer of 1967 in the project Charlie. Until that time, in the GE group as in the majority of computer manufacturers, each peripheral was connected to the central processor channels by a special set of logic gates developed by independent teams. Sometimes, channels themselves were modified specially to accommodate peripheral features.
The perspective of VLIfication of the logic lead naturally to implement in   "software" distributed in separate processors most of the control logic, at least the functions that did not require a response time incompatible with that implementation. In addition to the channel interface -the PSI for this product line-, an additional interface was created, the DAI Device Adapter Interface that connected   the special logic (still required from some real-time functions) with the control processor.
Actually, as the PSI was planed to be common between large and medium systems, the DAI was common to medium systems and small systems (Level 62), but in Level 62 DAI was attached to the main processor that was time-shared between control tasks and software. This grandiose plan was not completely  accomplished in GE+ Honeywell for various schedule, technical and organizational reasons. Level 66 implemented a slightly different version of PSI. The performances of the then available technology did not allow the tapes and the disks to be controlled without a DMA (absent of the URC) and the schedule reasons made that MSC (mass storage controller) has to be designed simultaneously with the URC. Additionally, the repartition of tasks in separate organizations and separate countries help the designers to sacrifice the unified architecture to parochial interest.
The concepts behind that distributed hardware architecture originated from John Haanstra, who was probably inspired by concepts floating in IBM in the late 1960s.

After Project Charlie, the Medium Systems Department (of Bull-GE and Honeywell-Bull) got the "mission" for the medium processor system (code-named P7 during the development) and  -in conjunction with the Bull Peripheral Subsystems Department- the responsibility of the Unit Records devices connection to the NPL systems.

The URC was designed entirely within the Hardware division of the Medium Systems Department, under Georges Lepicard, by a team lead by Henri Verdier.

In this page, the code running in the URC will be called firmware as used at that time and not software. The instruction set of the URC was directly executed by the hardware, not through an additional level of abstraction. The "firmware" was a classical instruction set of a 16-bit mini-processor.

Architecture

As said above, the URC is primarily a multiplexed controller for the Unit record devices interpreting the Channel Programs commands sent by the central processor software (normally GCOS) across the PSI and transforming them into some internal actions and/or specific commands to device over the DAI.
The operating systems used on Level 64 and DPS-7 with the URC were chronologically the SCP (System Control Program) and later its stripped version SIP (System Initialization Program) introduced in 1972, the micro-OS used for running the functional tests of the CPU, the stand-alone emulator for the GE-100 (based on SCP), the 4ABack-up developed in Boston for the H-200 emulator, and GCOS64 introduced in 1974. GCOS64 will later be renamed GCOS7 and later evolved from the original design, supporting new peripheral subsystems. All the software used the URC in an identical manner.

Additionally in a given system there is at least one URC that is used for the initialization and the maintenance of the system hardware, it is the called SURP (System Unit Record Processor). In large configurations, there was two SURP (one operational and a back-up), both of them might be used for regular unit record devices. The SURP differed from the basic URC by its special connection to the CPU by a specific maintenance interface (MCSI) that gave access to the hardware registers of the main processor to the "firmware" running in the SURP.

Several types of devices were to be connected to the URC, the type and the number of them being specific to a an installation, so it was decided to carefully architecture the "firmware" to allow the generation and the maintenance of the configuration. The firmware was running the control of a micro-operating system MIOS for micro-programming operating system). The MIOS was actually a micro-kernel for the different processes running in the URC. Firmware modules were all programmed as non-writable code. The device and other code module were usually called "attachments", while this word covered often also the related data and even also the Device Adapters in the sales catalog.

Up to 7 hardware Devices Adapters (DA) could have been attached to the URC (including the Universal Communications Lines adapter UCLA that multiplexed up to 15 communications lines in a single DA). The DAI was a byte-parallel TTL interface, allowing the registers of the DA to be read or written by the DA attachment. Registers contained data, status and control. The design goal was to minimize the amount of the hardware into the DA, so the DA should have included essentially the analog electronics usually associated with the physical device, a one byte buffer, and the decoding circuitry controlling the mechanics of the device.
The cost of the device electronics fell down during the 1970s, while the cost of mechanics did not. So the amount of DA electronics grew up slightly to add local control and maintain the initial interface. The "software" became more difficult to change than the hardware...

URC location in Level 64 system

The list of URC attachments is the following:

Card Reader
Card Reader/Punch
Paper Tape reader/punch (standard and Olivetti)
Magnetic (and Optical) checks reader/sorter
Line impact printer (Bull PR71 and PR54)
Philips Tape Cassette reader/writer
8 in diskette adapter
CRT Console (Honeywell special)
Multi-Line Adapter

    asynchronous character transmission (TTY)
    synchronous block transmission (Honeywell VIP protocol)
    synchronous block transmission (IBM BSC)
    synchronous HDLC transmission (X-25 and IBM SDLC)
Channel to Channel Adapter (RPQ)
PSI adapter
MCSI adapter

Operating System of URC

URC "micro interior decor" was a classical 16-bits instruction set with 2 base registers (one code base register and a data base register). The address space was limited to 32KB (the initial physical memory of the URC). Later, there were two successive expansions of the address space to 64KB (on URC-E) and 256KB (on DPS-7000) trough memory banks switch. The code of attachments had not to be modified due to those extensions.

The unit of execution, under the MIOS, were threads called micro-processes. In fact, when several peripheral of the same type were handled in the URC, the same attachment code was run in two independent micro-processes. Micro-processes synchronization was done through semaphores. Data was allocated statically and allocated at generation time.
Due to the paranoia against clones attachment to the Honeywell systems in the 1970s the configuration of the URC and the generation was made at the production plant in Angers.

The code portion of most of MIOS and of some attachments was located and executed from PROM. The implementation in PROM allowed the initialization checking of the URC prior to that of the rest of the system. The "boot device" of GCOS was done from disc because a disc was necessary to its operation. However SCP and Micro-OS were usually run from tape. But the SURP was nevertheless initiating the whole operation of bootstrapping, its console was needed to display the results of the tests. During the initial check-out if Level-64 in 2Q72 the boot device was actually the card reader of the URC, while the mass storage and the tape controllers were being debugged in Billerica.
Card images of the SCP were punched in Boston Multics system and ferried by plane each night to Orly. Source corrections were made in the morning from a remote console in Paris and the program was recompiled and relinked in the afternoon (EDT). That was the reason of the implementation of part of the card reader attachment in PROM. The   SCP factory was also duplicated on a GCOS III in Paris. but that too required a card boatload.

Architecture of the PSI as seen from the URC.

The PSI channel is a point-to-point channel connecting the central processor input-output controller to the peripheral controller (the URC). Each peripheral is known from the CPU software as one or several logical channels allowing a burst multiplexed transmission through the PSI. The PSI is a 1-byte parallel interface. The size of the burst is under the URC attachment and depends on the device.
The IOC (in fact, some CPU firmware for P7 architecture, the PCP firmware for P7G) interprets a channel program sequence of commands established by the driver programmer. Commands (CCE) may be device oriented (i.e. they cause some activities on the PSI. Other are local to the IOC (branch, test, analyze status) and are invisible from the peripheral controller. Some channel programs may loop and are interrupted by either a software command or by a device conditions. Channel programs were referencing a logical channel, the software ignoring the real mapping of LC on PSI channels. This mapping was established at hardware configuration (generation) time.
From the software interface point of view, a READ or a WRITE command deals with variable-length data, limited either by a byte count specified by the channel-program programmer. The dialog on the PSI was under the URC firmware that maintained for each "logical channel" the count of bytes remaining to transfer.

The main processor memory addressed is maintained by the IOC inside the central processor.
In 1967, there has been given consideration of having those addresses under the control of peripheral subsystems (i.e. a DMA-like architecture). There would have been some advantages in allowing the peripheral subsystem to recover from some errors (detected by CRC for example). However, it was judged that it was better for the integrity of the system to keep those addresses inside the CPU. Additionally, the use of virtual memory made impossible the access of page/segment control structures by the peripheral subsystems -actually, the IOC was knowing only real memory addresses. Virtual addresses inside channel programs were converted by software (with firmware assistance) into "absolute addresses" (physical addresses).

The software was instructed of the termination (normal or abnormal) of a channel program by a standard semaphore associated to a logical channel and posted by the IOC firmware. Additionally, another semaphore (attention semaphore) was posted when asynchronous events were detected by the peripheral subsystems in the absence of channel programs. Those semaphores (that were message-semaphores) were specified at software generation.
It was  possible to dedicate a device to a particular subsystem without any interference of the GCOS operating system. This feature  was used by emulators, but could have been more generalized.

Device attachments peculiarities

Card Reader

Card Punch

Impact Printer

A peculiar feature of the printers available on Level 64 was that the paper advance mechanism was performed in an off-line phase. That phase was under a local control (an emulation of the paper tape loop of preceding devices) within the URC. A normal status of  end-of-transfer of a WRITE command did not mean that the printing has been correct. A abnormal end of the off-line phase was reported in the subsequent WRITE (or STATUS REQUEST) command. Such a situation would require usually that the entire page had to be discarded and the main program (output writer or specific application program) had to return to a check-point.
The issue came from thn limited buffering then available inside the URC. Support people refer to it as a "LINE MAY BE LOST" message issued by GCOS first releases when that problem occurred.

Document Handler

The LD1 Magnetic Document reader has been connected to the Level 64. From a programmer and System engineer point of view, it was almost identical to the card reader attachment.

Document Sorter

Contrarily to the LD1, the DHU document sorter attachment raised many technical issues. The device had 12 stackers that could be selected by software. To allow a full speed continuous processing of checks, the application program was to do the selection of stackers in real time -a constraint that cannot be fulfilled in a multi-programming system within the normal job processing.
The solution adopted for GCOS64 was to distribute the stacker selection in a URC program interpreted by the DHU extension. That program synchronized with the host program. A  specific compiler was producing the URC program that was loaded into the URC at device allocation time (job step initiation).

Multi-Line Adapter

Most of the architecture of the URC and of its firmware vas due to the role of the URC as a data communications processor. In 1967, ot was decided to connect a multi-line communication controller, with functions similar to the IBM 270x. The alternative solution of having a separate computer as the Datanet 30 or 355 for the GE-600 was too expensive, not flexible enough for a medium-sized computer.
The type of communications available at that time were low-speed Teletype (typically less than 300 bps) and "high"-speed (2400 or 4800 bps) lines for remote batch transmissions. Those communications lines while
connected to a modem through  the same serial interface were divided in asynchronous and synchronous transmission depending of the presence of an independent clock in the modem. Serial to byte parallel conversion was made by a one-card line adapter. Up to 16 line adapters were multiplexed in  a card-cage named UCLA (Universal Communication Lines Adapter) interfacing with the URC through a standards DAI interface.

The UCLA attachment was named MLA (Multi Line Adapter or Attachment). This URC firmware performed some functions at character level and other at block level. It operated in conjunction with central processor software that interpreted application commands (such as SEND or RECEIVE message requests). The central processor modules that were used were Operator Message Handler (controlling the main console) and BTNS (Basic Telecommunication Network Supervisor). In addition to that GCOS software, the MLA -for the main operator console- was used by free-standing software (SCP and micro-OS) and by the maintenance "software" running inside the URC. 

Character level functions (the "byte machine") performed by the MLA were control characters detection, parity checking, CRC computation, break detection. It also performed code conversion (frequently, ASCII to EBCDIC and vice-versa) under software control.

Block level functions ( he "burst machine) were dealing with fixed length character strings (bursts) exchanged with BTNS software, depending on the communication procedure.

The interface included a communication control table loaded at system initialization that specified line type and speed (typically binding the terminals characteristics with the system). Some parameters could be changed dynamically -specially those terminal specifics on   switched lines. It has to be reminded that universal modems did not exist in the 1970s and that PTTs did retrain the use of auto-calls by the computer. Nevertheless, the system allowed auto-calls on classical modems and on X-21 modems. 

The communication with BTNS software took advantage of the loop capacity of the "channel program". BTNS was notified on a semaphore by termination of  burst transmission  (buffer exhaustion) and by the detection of the MLA of transmission related events. The channel program was continuing to fill (or empty) the alternate buffer without waiting BTNS could stop the channel program when needed. 
There was one logical channel per communication line for half-duplex lines (two on full-duplex lines). Polling / selecting functions were performed by MLA. Demultiplexing the messages per multi-point terminal was the responsibility of BTNS. 

If asynchronous lines supported usually by the Teletype protocole (while Baudot terminals had been planned), synchronous lines supported several procedures: IBM BSC, Honeywell VIP, HDLC. 

The original UCLA was updated in the early 1980s as the UCLA-R that had only 4 communications lines (for console and remote maintenance), customers terminals being serviced by the Datanet Front End Processor.

Cassette

 FDA (Floppy Disk Adapter)

The Diskette adapter was implemented as a small card cage of 3 boards able to connect two units.
The initial 8 in diskette was single face single density.

Paper tape

Magnetic Tape Adapter (streaming tape)

In the mid 1980s the attempt to sell low-cost DPS7000 lead to the decision to attach low-cost magnetic tapes to the URC. The performances of that device in start-stop time was extremely low and to achieve reasonable performances successive data transfers had to be made on the fly. The architecture of the URC was convenient for such a constraint. Double buffering  of a block (transparent to software) was performed within the URC by the streaming tape attachment. Gaps were generated on the tape at the end of the WRITE software command.
It has to be reminded that data chaining (scatter gather) was a IOC responsibility and was completely transparent to URC.

MTA devices were initially STC 1730 and 1740.

Maintenance Panel

While the firmware of the URC is "vertical" firmware, there was originally some consideration to write an interpreter to run a subset of the NPL Level 2 interior decor (that of the main processor of Level 64) inside the URC. The URC would have been the smaller member of the product line ( it was already a punched card machine to which another mini-processor controlling discs and a larger main memory would have been attached).
That intent floated in 1967-1968, but was finally killed with the assignment of the small system to HIS Italia. However,  a fall-back of those studies was the implementation of a interpreter for the "maintenance processor" decor.

The maintenance processor was offering a "byte-oriented" decor assumed to be simpler to program than the native URC decor to support non resident as well as resident software. It included a resident part named SPOS Service Processor Operating System that used the main console, a storage device and the MCSI adapter drivers. The storage device was initially a tape cassette drive, later replaced by a 8 in floppy drive. The SPOS took the control of the console and storage devices only when it was not in a quiescent state (i.e. when the main processor was not executing software -usually after a "system crash". So, the above mentioned devices were normally available to central processor software and have not to be dedicated to maintenance.

Channel to Channel adapter

The expected use of the Level 64 systems in transactional systems lead the system designers to think about ways of establishing a redundancy inside a couple of systems. That required a need for a low-latency communication between two different operating systems and a capability to assign devices to either system. The static sharing of a set of devices between two systems was easily provided under the modular MPOS architecture. What was simply needed was to have a second PSI adapter and to enlarge subsystem tables. That solution was cleaner than having a PSI mechanical switch (also available) that required a re-initialization of the system and did not allow an allocation at device level.

The connection of a second PSI adapter lead to its usage as a channel-to-channel adapter at no hardware additional cost. A new firmware attachment that implements a data mover between the two PSI attachments was the only feature to be needed. However, that option entered in competition against a front-end processor connected to several CPUs. That DSA solution was supported by FNPS software and no use was made of the faster channel-to-channel interface.

Technology

The technology used in the URC was that of the Level64 main processors : Medium scale integration TTL from Texas Instruments.

The packaging was Bull-GE designed SP10 small boards of that of the Level 64 processor. The URC was initially implemented in two separate card cages connected by DAI flat cables (one for URC itself, the other for UCLA). Later, in the late 1970s, slight modifications occur when 64Kb RAM chips allowed a single rack implementation. power supply

DC power of 5 volts  was standard but it had to be supplemented in the UCLA and for RAM memory. The power supply was also designed by Bull in two models one for USA and another one for the rest of the world.

Evolution of URC Architecture

The TTL/SP10  technology used in URC was no more in the 1980 the main technology used by computer manufacturers and some components were becoming scarce. The CML/micro packaging option that had been contemplated in the late 1970s was expensive and the only remaining option would have been to switch to CMOS. However, the original 7option to transform the URC building blocks in proprietary VLSI had been compromised by the evolution of the design. In another  way, only the DPS 7 designers had used URC an no other design teams had contemplated to use it. The rest of the company -except the GCOS8 designers-was switching to commercially available micro-processors from Motorola, National and Intel. The Bull DPS-7 people had just redesigned a mass storage controller (MSC-RV) using AMD bit-slice micro-processor VLSI. However, the use of a monolithic 16-bit processor made more sense -support chips for most URC devices existed already. The Motorola 68000 was selected, following many other company design teams.
Simultaneously, the Multibus 2 "standard" bus from Intel was selected as a standard 32-bits card cage bus as opposed to S-100, AT, VME alternates. The fact as Bull selected an Intel bus and a Motorola processor did not help too much and glue chips had to be designed.

Eventually, the DPS-7000 low-end systems were those that pioneered the new I/O processors. The new unit-record processor added the control of a low-speed streaming tape to the list of peripherals. The UCLA was removed from the URC and communication lines were then handled by  a micro-FEP being also built with MC68000 processor and supporting a subset of the MainWay evolution of the Datanet Network Processor. However, communications lines for the console and remote maintenance were maintained in the SURP/68000.

The architecture of the URC was nevertheless maintained for printers, console,... A manual port of MPOS and the remaining attachments to the 68000 architecture was made by the Bull designers.

Around 1990, with the new CPU design, the Auriga systems, a big change in CPU maintenance adapter was made. Instead of relying exclusively on SURP, the maintenance and initialization functions were exploded between a "maintenance board" located in CPU enclosure powered by a 386 processor and a standard PC/AT used as operator interface and related storage. The PC operated under Windows, while Auriga maintenance programs were running at console level interface. The maintenance board 386 was overseeing the specific maintenance interface of the CPU avoiding to design special hardware for the PC. It communicated with the PC on  a serial interface.

 

 

Back

Date modified: février 19, 2002