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.
Date modified: février 19, 2002