Compagnie Honeywell-Bull    

Ligne GCOS7

64-DPS

PÉRIPHÉRIQUES
PERIPHERALS

1976-1989

Appareils "unit record" (cartes et imprimantes)

Appareils de mémoire à disques magnétiques

Appareils à bandes magnétiques

Unit Record Devices

Magnetic Disk Devices

Magnetic Tapes Devices

 

Unit Record Processor

© 2002,2003  Jean Bellec

Histoire de l'URC-E

Le choix de la cassette pour le support des fonctions de service du Level64 n'était pas complètement satisfaisant. Il présentait des risques de mauvaise fiabilité dus à des rembobinages fréquents. La cassette ne répondait pas non plus aux espérances comme media de saisie de données. Aussi, la nouvelle version de l'URC (appelée URC-E) développée en 1976-1978 dans le cadre du 64-DPS s'orienta vers le remplacement de la cassette par une disquette 8 pouces, le standard émergent de la micro-informatique à l'époque, qui avait été choisi par IBM comme media de maintenance pour le S/370 au début de la décennie 1970.

Technologie de l'URC-E

L'URC-E différait du modèle précédent par un l'évolution de la technologie en TTL 74S (le 74N souffrant déjà d'un problème d'approvisionnement de circuits) et le remplacement des chips DRAM par le modèle 16Kbits, ce qui permettait à la fois de réduire l'encombrement du tiroir URC et d'étendre la mémoire à 64K octets.

Architecture de l'URC-E

Bien que l'URC ait été conçu comme un mini-ordinateur à usage général, on n'avait jamais envisagé que sa base architecturale soit directement programmable par l'utilisateur final. Lorsqu'on a envisagé son utilisation comme processeur de bas de gamme, l'"interior decor" considéré devait être un code d'instructions compatible avec celui du 64 (aligné octet, instructions de longueur variable...) interprété par du "firmware" et non le décor natif offert par le matériel (machine mot de 16-bits, adressage limité à 64KB, 2  registres de base - un pour le code, l'autre pour les données-). On a donc appelé "firmware de l'URC" le logiciel en mode natif, dont une partie, celle du "bootstrap", et les pilotes des périphériques de base  était réalisé en PROM.

L'URC comprenait un processeur, une mémoire DRAM et des adaptateurs (1 ou 2 adaptateurs de canal PSI -liaison avec le processeur central, adaptateurs de canaux DAI -liaison avec l'électronique des périphériques).
Les canaux DAI étaient un standard Honeywell et identiques pour tous les périphériques (parallèle sur 8-bits).

Les "device adapters" de communication étaient de types différents: un adaptateur de lignes asynchrones regroupant 8 lignes à basse vitesse avec un double tampon d'un caractère par ligne, un adaptateur de ligne asynchrone à "grande vitesse" , un adaptateur de lignes synchrones BSC puis plus tard un adaptateur de ligne synchrone HDLC. Ces adaptateurs étaient échantillonnés par le programme de gestion de lignes aussi appelé "MLA firmware".

Micro-Logiciel

Inspiré de la conception du processeur du Level 64, un "microprogrammed-OS" (MIOS) servait de système d'exploitation de l'URC. Il s'agissait d'un micro-noyau qui, non seulement gérait les interruptions, mais aussi assurait le dispatching des tâches et leur synchronisation au sein de l'URC. Ce MIOS faisait partie de la partie réalisée en PROM et était par conséquent chargé au début de l'initialisation de l'URC.

Les micro-tâches étaient les suivantes:

  • le pilote du lecteur de cartes (code en PROM)
  • le pilote du perforateur de cartes
  • le pilote de bande perforée
  • le pilote d'imprimante (PR71 et PR54)
  • le pilote du canal PSI de liaison avec le processeur central (code en PROM)
  • le pilote de la console (modèle pour le haut de gamme développé à Billerica)
  • le pilote de lignes asynchrone TTY (console bas de gamme GE Terminet 300 compatible TTY35)
  • le pilote de la trieuse de chèques
  • le programme de gestion des lignes de communication (MLA firmware)
  • l'interpréteur du programme de maintenance
  • l'attachement de diskettes ( nouveau, code en PROM)
  • l'attachement d'adaptateur canal à canal

La structure de ces micro-tâches était rigoureuse, la partie procédure était réentrante de façon à pouvoir supporter le multi-tasking (ex: support de plusieurs imprimantes) et se dérouler simultanément sous contrôle du MIOS multiplexant le matériel entre ces micro-tâches (appelées micro-process). C'est ainsi que le fonctionnement des lignes de communication pouvait être complètement indépendant et ces lignes allouées à des "logiciels" différents dans le central ou l'URC.

A propos des pilotes, il faut noter que la lourdeur de la distribution des "releases" du micro-logiciel (Basic System Release BSR) conduisit le Département de Conception de Périphériques Unit Record de Belfort à réaliser des matériels rigoureusement compatibles avec des matériels antérieurs, même si le coût et la fonction de ces appareils en différaient sensiblement (ex: lecteur de cartes CR300 et lecteur de cartes Honeywell CR 1000).

Pour la liaison avec le processeur central, l'URC disposait du canal PSI et d'un canal spécial de maintenance. Ce dernier servait à lancer la réinitialisation du central, à accéder au contrôleur de mémoire centrale et à extraire le contenu des registres de l'unité centrale. Le pilote de canal PSI avait comme fonction d'assurer la communication entre le logiciel du central (via le contrôleur d'entrées-sorties du central et son firmware associé) avec les pilotes de contrôle de périphériques. Il maintenait un ensemble de "subchannels" entités logiques définissant des chemins de données (macroscopiquement asynchrones) entre les "processes" du central et des fonctions logiques sur les périphériques.
Cet asynchronisme avait des limites dues aux fonctions "temps réel" du sous-système d'entrées sorties. Ces fonctions pouvaient être réalisées, comme sur le IBM S/360, en synchronisant les "programmes canaux" du central avec les "interruptions" des entrées-sorties. Pour les opérations plus contraignantes, l'URC permettait au programmeur du central de prédéfinir des actions se déroulant dans l'URC  (actions sur caractères spéciaux de communications, actions sur les trieuses de chèques). Ces actions étaient soit définies par des déclarations transmises au programme de gestion de lignes de communication, soit par la génération d'un programme compilé pour la lecture et le tri de chèques.

Attachement de Périphériques

La spécification de l'URC, faite à un moment où la logique des devices adapters était coûteuse, n'avait pas prévu que ces devices adapters enregistraient le type d'appareil qu'ils reliaient à l'URC. Ainsi, il n'y avait pas de possibilité de reconnaissance automatique des appareils au moment de l'initialisation (Fonction Plug and Play).

Les "Device Adapters" spécifiques de chaque appareil étaient connectés à l'URC par une interface standard DAI (également utilisée sur Level 62 et Level 66). Cette interface parallèle sur un octet était directement contrôlée par les micro-programmes de l'URC.

disquette

lecteur de cartes

lecteur-perforateur de cartes

imprimante

La définition de l'attachement imprimante posa des problèmes particuliers dus à l'existence d'une phase off-line sur la PR71 qui était l'avance du papier. Cette avance était lancée par le micro-programme à la fin du transfert de données dans le tampon ligne de l'imprimante, mais la fin du saut de papier n'était détecté que lorsque le microprogramme se préoccupait de l'envoi de la ligne suivante. Un incident mécanique d'avance papier était donc détecté après que le logiciel du central ait reçu le signal de transfert de données. Dans le cas où le logiciel n'avait pas prévu de point de reprise au niveau de la page, ce problème risquait de provoquer un message d'erreur sur l'état d'impression "LINE MAY BE LOST"

trieuse de cheques

La connexion du lecteur-trieuse de chèques (modèle MICR ou OCR) posait des problèmes que la plupart des autres appareils unit-record. Les critères de sélection (champ des données, codage, type...) de la case de réception normale des chèques étaient sous-la dépendance du programmeur d'application. De plus, la trieuse de chèques rencontrait des cas d'impossibilité de lecture devait provoquer la sélection en case rebut sans ralentir le rythme de la machine. La lecture des chèques ne devait s'arrêter que dans le cas de case d'alimentation vide, de case sortie pleine ou de bourrage.

bande perforée

Multi-Line adapter (MLA)

Le MLA est composé de deux composants: un composant matériel l'UCLA (Universal Communication Lines Adapter) panier (card cage) recevant une carte de liaison avec l'URC (Common Board) via l'interface DAI et jusqu'à 15 adaptateurs de ligne, et un composant micrologiciel l'"attachement MLA". Plusieurs modèles d'adaptateurs de ligne ont été offerts (l'adaptateur de ligne asynchrone possédant une horloge bit programmable, l'adaptateur  de lignes synchrones et l'adaptateur HDLC , ces derniers étant synchronisés par le modem). L'interface entre adaptateur et UCLA est parallèle sur un caractère, l'interface entre adaptateur et modem est du type série. Les adaptateurs pouvaient indifféremment être utilisés via modem ou en connexion locale à courte distance.

L'attachement MLA reconnaît chaque caractères de contrôle, vérifie leur parité -s'il y a lieu-, interprète les caractères de contrôle de bloc et vérifie les contrôles d'intégrité (CRC) selon les protocoles de transmission, effectue -éventuellement- une traduction (ex: ASCII<>EBCDIC), et regroupe le contenu pour une transmission par blocs à l'unité centrale. En outre, l'attachement MLA interprète les caractère de Break qui interrompent la transmission et informe le central par une "attention" spécifique, pouvant interrompre le déroulement du programme canal. A chaque ligne est associée 1 ou 2 logical channels (selon half-duplex ou full-duplex).
Les options du MLA sont le mode TTY (avec support de bande perforée) , le mode Honeywell VIP (avec option de multi-point), le mode IBM BSC utilisé essentiellement en "remote batch", le mode HDLC X25 (compatible IBM SDLC). Un mode Télex 5 moments, code Baudot a été offert mais n'a guère eu d'applications. Essentiellement pour les pays nordiques,   un support de l'interface de commutation automatiques de circuits X21 a également été offert sur URC.

Presque tous les systèmes avec URC ont eu la console système connectée via le MLA.  La console la plus répandue avant 1981 fut le General Electric Terminet 300 (compatible TTY). Il a été ensuite remplacé par un écran du type VIP, utilisé par GCOS d'abord en mode TTY, puis en mode plein écran.

 

Attachement de Canaux

Canal PSI

L'interface avec le canal PSI était une interface parallèle sur un octet. L'URC pouvait recevoir un second canal PSI permettant de la partager entre deux unités centrales. Les sous-canaux correspondant aux périphériques étaient partagés statiquement (à la génération du firmware) entre les deux appareils ce qui limitait l'intérêt de la double connexion. Elle ne fut guère utilisée que pour connecter  l'ensemble des périphériques à l'une ou l'autre unité centrale, jouant un rôle identique à celui d'un switch de canaux PSI utilisé sur les autres sous-systèmes périphériques.

Canal de maintenance

Le CPU du central (et les autres contrôleurs de périphériques) était connecté via l' interface série MCSI.

Initialisation

On décrira ici, l'initialisation des prototypes complets à partir de la diskette .
A la mise sous tension du matériel, l' URC initialisait sa mémoire et effectuait des auto-tests (les POST d'aujourd'hui) de son processeur et de sa mémoire depuis ses "microprogrammes" en PROM. Le MIOS commençait le chargement et l'initialisation des micro-processes dont le code était résident en ROM et la mémoire de travail (dans la mémoire vive de l'URC) auto-initialisée. Après cela, il chargeait le "firmware" d'initialisation depuis la disquette  située dans le lecteur, puis sur le contrôle de cet "attachement d'initialisation", il lisait depuis le disquette le "firmware"  du processeur principal destiné à s'exécuter depuis la mémoire centrale vive. Ensuite, le processeur principal exécute un chargement du premier "logiciel" normalement le System Initialisation Program SIP. Une alternative au SIP -chargée le plus souvent depuis bande magnétique- est le logiciel de tests fonctionnels élémentaires du processeur principal (OPELs).
Le rôle du SIP consiste à examiner la configuration du système contenu dans des tables logiciel (SRT System Resource Table), de charger le "firmware" correspondant à ces tables dans le sous-systèmes périphériques et en particulier dans l'URC et de lancer définitivement la configuration opérationnelle. Il constitue aussi la table de ressources effectivement disponible au système d'exploitation GCOS (SRST) terminant ainsi le processus d'initialisation.

En fonctionnement normal opérationnel, l'initialisation a lieu depuis disque; le "boot-record" est logé sur ces média au lieu d'être sur diskette. Mais le lancement des tests (POST) des contrôleurs et le choix du périphérique d'initialisation reste commandé par l'URC -via l'interface de maintenance des MSC ou MTC.   Le SIP se charge dans la mémoire principale à partir du "boot-record" et les autres contrôleurs de périphériques sont initialisés. "L'image" de la mémoire URC comprenant le support des périphériques spécifiés dans la SRT est descendue ("downloadée" ) dans la mémoire URC depuis la mémoire centrale via le canal PSI. Les micro-tâches de l'URC sont lancées et les périphériques qui le doivent sont placés dans leur état initial par ces micro-tâches.

Dans le cas où le sous-systèmes disques -s'il n'y en a qu'un- doit faire l'objet de vérifications (Tests et Diagnostics du sous-système et d'un appareil), l'initialisation a lieu comme depuis disques, le système d'exploitation chargé étant le SCP

Maintenance

Un arrêt inopiné du processeur central (interruption au niveau 0 -déclenchée par l'interpréteur d'instructions 64 ou par le superviseur GCOS ou par un time-out sur la durée d'une instruction)  se traduisait par l'envoi d'une interruption à l'URC sur le canal de maintenance, interrompant les microprocessus en cours.
Le bootstrap résident de l'attachement de maintenance interprétait cette interruption et lançait l'attachement de maintenance complet écrasant d'autres attachements de l'URC, à l'exception de la diskette, de la console et de l'imprimante. Cet attachement comprenait l'interpréteur du décor processeur de maintenance et l'ensemble de drivers disponibles à l'initialisation.

Dans ce décor -un sous-ensemble réduit du décor GCOS62- étaient écrits un mini-système d'exploitation MPOS 'maintenance panel operating system" et un certain nombre de commandes interprétant les données entrées par l'opérateur à la console du système, telles que DUMP sur l'imprimante, DUMP registres du CPU sur la console, etc...MPOS peut accéder à plusieurs "devices" de l'URC, notamment la console, la diskette et l'imprimante. L'accès à la diskette permettra de créer des commandes non résidentes.

Génération

La programmation de tous les produits liés à l'URC fut faite jusqu'aux années 1980 sur des outils tournant sous GCOSIII sur GE-635, puis sur H-6000 dans les locaux de Bull. Il était, à l'époque, considéré comme stratégique que ni les filiales, ni à fortiori les clients eussent une quelconque de connecter des appareils non-Bull au système 64. La modularité de l'architecture permettait cette exclusion au prix d'une complexité logistique non négligeable  La distribution des Basic System Release (ensemble des micro-logiciels et des outils logiciels appropriés) était distribuée comme du "hardware" par l'usine d'Angers.

Le langage d'écriture du firmware de l'URC était un macro-assembleur. Lorsque le processeur de l'URC devint un 68000, le langage C  remplaça l'assembleur.

Evolution du projet

 

Système P7G (DPS/7-x0)

L'URC de P7G restait du point de vue matériel et micro-logiciel de base, celle du 64DPS. Par contre les fonctions de maintenance en différaient sensiblement. Bien que tous les systèmes Leo (P7G) furent dotés du frontal Level 6, le MLA devait être conservé pour les systèmes Taurus de bas de gamme, beaucoup de ces derniers étant des évolutions de Level64 sur parc.

Le système P7G différait essentiellement de celui du Level 64 du fait que le processeur central ne disposait d'aucun firmware en ROM. La procédure d'initialisation du processeur central était différente: les tests du central et les valeurs d'intialisation des registres devaient être alimentés par le SURP.

D'autre part, le système P7G étant un multiprocesseur capable d'un partitionnement en deux systèmes indépendants, il était nécessaire de disposer de deux SURP pour l'utilisation en bi-système qui par ailleurs pouvaient être basculer l'un sur l'autre en cas de panne.

URC vs Front-End Processor

Datanet-2000

Le Datanet-2000 était un processeur frontal de communications développé par Honeywell pour la série H-200/2000 à base du mini-ordinateur H-516. Pour reprendre la base de clientèle H-200 par le Level 64, il fut décidé de connecter ce frontal sur un canal PSI. L'existence de ce produit contribua à diminuer la pression pour le développement de l'URC6MLA vers le haut.

Frontal DSA

Après la fusion de CII et de Honeywell-Bull, CII-HB obtint de Honeywell la mission de réaliser "le frontal commun" de l'architecture DSA (Distributed System Architecture) pour les systèmes DPS-7 et DPS-8. Cette décision posa des problèmes à toutes les lignes de produits (GCOS4 qui s'en abstint, GCOS8 qui traîna des pieds et GCOS7 qui dut s'y contraindre mais devait assurer à la fois une coexistence et une évolution avec les systèmes URC.

Système Aquila (DPS/7-10x7)

En 1987, fut introduit par Bull, un système de haut de gamme DPS/1007 dont le processeur était celui du S/750 développé par NEC.

NEC avait dérivé son propre URP à partir du design initial Bull et il fut décidé de conserver le produit NEC pour l'initialisation et la maintenance du central. Le SIP fut adapté pour reconnaître l'existence de ce SURP, mais ce SURP ne fut pas rendu visible au logiciel GCOS et ne servait qu'aux interventions des techniciens Bull ainsi qu'au partitionnement éventuel d'une configuration multi-processeurs. Le support des imprimantes et de la console GCOS7 restèrent sur l'URC de fabrication Bull.

Eclatement du système de maintenance

Avec le système Auriga, l'architecture de maintenance du central fut sensiblement modifiée. Un microprocesseur Intel 386 sur une plaque montée dans le coffret de l'unité centrale effectuait les fonctions spécialisées de ce modèle de processeur

La console proprement dite était un micro-ordinateur PC 386 sous Windows 3.1 dont on utilisait l'écran, le clavier, l'imprimante et la diskette au lieu des appareils directement contrôlés par l'URC

Remplacement du Microprocesseur

En 1969-1974, il était prévu que le design du matériel du processeur URC soit "VLSIfié" lorsque la technologie deviendrait disponible. Cependant, une des limitations de l'URC restait la capacité d'adressage limitée que le dispositif d'extension introduit par l'URC-E ne résolvait qu'imparfaitement. Le coût de "VLSIfication" d'un mini-ordinateur vendu à quelques milliers d'exemplaires était relativement prohibitif et l'évaluation de microprocesseurs fournis à l'extérieur s'imposa naturellement comme alternative.

Au début des années 1980, apparaissaient des microprocesseurs du commerce à 32-bits. Le Motorola 68000 avait été choisi par Bull-SEMS et par HIS Italie pour ses systèmes UNIX.Ce fut donc lui qui fut sélectionné comme base du remplacement de l'URC d'abord pour le DPS-7000 bas de gamme (programme Libra), puis sur l'ensemble des DPS-7000 (Auriga et Artemis).
L'URC fut ainsi reprise sous forme d'un micro-ordinateur doté d'un bus -fond de panier- Multibus 2, comportant outre l'unité centrale basé sur 68000 un certain nombre de Devices adapters repris de l'URC.
Le MLA ne fut pas réincorporé étant remplacé par le Micro-FEP li aussi doté d'un 680x0 et doté d'un sous-ensemble du logiciel du nouveau frontal Mainway.

En pratique, l'architecture micro-logiciel de l'URC fut conservée et le processeur Motorola était sous le contrôle d'une version du MIOS recodée sur MC68000.

 

Notes

PROM ou ROM.
les premières réalisations furent faites en utilisant des PROM dont il était nécessaire au fabriquant de semi-conducteurs de fournir le masque de métallisation externe. Cette procédure -outre son prix élevé avait l'inconvénient d'un temps très long entre la correction d'un bug et le remplacement du chip défectueux en clientèle. Elle entraîna la création d'une "zone de patches" situés ne mémoire vive dans laquelle étaient placés le contournement du problème au prix d'un certain ralentissement.
A l'époque des années 1970, les PROM étaient plus rapides que les DRAM dans un rapport de 3. La DRAM posait de plus des contraintes de rafraichissemnt qui interrompaient le déroulement des micro-processus temps réel. L'architecture du "firmware" URC devait être très rigoureuse pour minimiser l'impact des corrections sur les performances.
Plus tard -sur l'URC-E-, des EPROM modifiables en usine par CII-HB et plus rarement en clientèle remplaceront avantageusement les PROM.

Attachement de URC.
Mot utilisé par développeurs et commerciaux pour désigner les "programmes se déroulant" sur l'URC sous-contrôle du MIOS. Ces programmes occupent une certaine place mémoire, sont normalement relocatables et peuvent dans quelques cas comporter des "overlays". Selon la configuration, ils peuvent être multi-tâches (multi-thread)..

Attachement canal à canal
L'architecture de l'URC fut utilisée pour réaliser un "channel to channel adapter" permettant l'interconnexion de deux systèmes Level 64DPS. Cette réalisation fut faite à la fin des années 1970 à une époque où CII-HB s'apprêtait à annoncer son architecture distribuée DSA dans laquelle le rôle essentiel était déplacé de l'URC vers le frontal Datanet. Aussi le CTC adapter npn supporté an standard par GCOS64 ne fut pas utilisé en clientèle
L'URC servant de liaison CTC (mais pouvant aussi recevoir d'autres appareils et même servir de SURP était connecté à chaque unité centrale par un canal PSI. Le CTC ne comprenait aucun matériel spécifique, les sous-canaux affectés au CTC étaient multiplexés sur le canal PSI et la mémoire tampon de l'échange était de la mémoire de travail de l'attachement dans la mémoire centrale de l'URC.

SCP et SIP
Le Suport Control Program (SCP) est un système d'exploitation primitif permettant l'exécution de travaux individuellement lancés par l'opérateur, soit un enchaînement séquentiels de travaux. Il n'offre pas de support de multi-programmation, permet le multi-tâches (défini statiquement). Il fut utilisé comme support de la première version de l'émulateur GE-100 sur Level 64 et resta utilisé comme support des tests et diagnostics "stand-alone" permettant les diagnostics de sous-systèmes disques et de discriminer pannes du central et problèmes logiciels de GCOS.
A l'origine conçu comme un travail (job step) séparé sous SCP, l'initialisation du système fut ensuite combinée avec le code de SCP, l'ensemble fut renommé System Initialization Program (SIP). cette intégration réduisait de manière significativela durée de la phase de lancement de GCOS.

 

 

Unit Record Processor

© 2003  Jean Bellec

The URC-E History

The choice of tape cassette to support service functions were not completely satisfactory. Frequent rewinds decrease the tape reliability. The usage of the tape cassette as a data entry system wa by far not so popular as expected. So, the new version of the URC (named URC-E) that was developed in 1976-1978 as part of 64-DPS replaced the cassette by a 8 inches diskette (the same media IBM used for S/370) that became the then emerging standard for the first generation of micro-computers.

Technology of URC-E

The technology was identical to that of the main Level 64 processor (MOS DRAM memory of 4Kbits per chip, switching components TTL 74N, SP10 Bull designed packaging).

URC-E Architecture

While the URC was deigned as  ageneral purpose minicomputer, it was never envisioned that its processor architecture was directly known and programmed by an end-user. When it was envisioned to be used as a low-end processor of the line, the "interior decor" was to be an instruction set identical or compatible with that of 64 (byte aligned, variable length instructions...) interpreted by "firmware" and not the native decor offered by the hardware (words of 16-bits, addressability limited to 32K words, 2 bases registers -one for code, the other for data).
The native software using the hardware architetcure was named "URC firmware", a part of which the "bootstrap" and some peripherals drivers  being implemented in PROM as in present microprocessor BIOS.

The URC included the processor, a DRAM memory and adapters (one or two PSI channel adapters -connection with the CPU(s)-, several identical DAI adapters -connection to the peripheral electronics). DAI channels were a Honeywell standard featuring a 8-bits parallel interface, data transfer one byte at a time were under the controller firmware control (URC for Level64).

The "device adapters " for data communications, implemented in same frame as URC were in different models: an adapter for asynchronous lines grouping 8 low-speed lines, each with a double buffer of one character and a detection of start-stop pulses, an adapter for a  high-speed asynchronous line, a BSC synchronous line adapter and later a HDLC synchronous line. Those adapters were sampled by the communications driver program in the URC also named "MLA firmware".

 

URC-E Firmware

Based on the design of the Level-64 processor micro-kernel, a microprogrammed-OS (named MIOS) was the operating system of the URC. That microkernel not only handles real time interrupts, but also did   dispatches drivers threads (micro-threads) and their synchronisation within URC. That MIOS was implemented in PROM and did also tests and initializes the URC

Other micro-threads were:

  • card reader driver (stored in PROM)
  • card punch driver
  • paper tape driver
  • printer (PR71 and PR54) driver
  • PSI channel driver (stored in PROM)
  • CRT console driver (developed in Billerica for high-end systems)
  • asynchronous Teletype driver (for GE Terminet 300 console, TTY35 compatibme)
  • check sorter driver
  • communications lines driver (MLA firmware)
  • maintenance language interpreter and driver
  • diskette adapter driver (new, stored in PROM)
  • channel to channel adapter driver

Those micro-threads were rigorously structured: the procedure part was reentrant to support multi-tasking (e.g. to support two or more printers) and operating entirely under the MIOS control that dispatched the hardware resources between those "micro-processes". The behaviour of each communication line could be completely independant allowing those lines to operate with different software programs in the CPU or even inside URC.

Magnetc Storage  Processors

 

L64 and DPS7/7000 Storage Controllers

Level 64 systems were to be configured with at lest a mandatory disc subsystem and an optional tape subsystem. As almost all system migrating to Level 64 were tape oriented, few disc only systems have been sold. The mass storage controllers evolved with time to support new devices and for cost reduction. Tape controllers evolved the same way. The introduction of a streaming tape connection to the URC in the early 1980s coincided with the abandon of removable discs on DPS-7

Attachment of new controllers was technically asynchronous with the introduction of new systems until the advent of DPS-7000 Ares phase 3 that initiated the evolution towards industry standard parts. Eventually complete subsystems ended to be sourced from independent manufacturers such as EMC.

DISC CONTROLLERS

The disc controllers were known under different acronyms in engineering and in the field. They have a very limited visibility in the field, some having been bound with the central processor in some cases. They have been called usually Mass Storage Processor emphasizing "distributed processing" as a distinctive Honeywell and Bull advertising feature.

MSC

Specifications

The original MSC was designed by Honeywell in Billerica in 1971-1972. It has to support state-of-the-art disc devices produced by Honeywell for the H-2000 product line and were, from the hardware point of view, clones of IBM 2314 and 3330 removable discs. The native mode of formatting had to be IBM variable CKD, allowing a data exchange for a migration from low-end S/360 systems. The IBM compatibility was extended to the file system (the IBM VTOC was also adopted)
In addition, the Honeywell H-200 fixed sector format had also to be supported for assisting in co-existence / migration with H-200/2000.
The combination of those requirements was a superset of the IBM disc subsystem architecture and the simultaneous support of several physical formats. A SEARCH DATA command was added to the SEARCH KEY with the believing that more and more data base functions will migrate closer to the physical device, a prediction that was not realized.
The GE-100 small removable drives also were attached to the MSC, but they were supported only by the GE-100 emulator and its special utilities. Their attachment was not raising specific constraints to the controller.

Supported devices

MSU-300

Architecture

The MSC was powered by a special processor optimized on byte searching and fast transfers from the DLI (device level interface) and the main memory (trough the PSI channel) and with a very limited amount of buffering inside the MSC.

The I/O architecture allowed "simultaneous" transfers on logical channels, i.e. block multiplexing. A single logical channel was allocated to each device, while it was contemplated to add fixed head devices that might have several partitions and one logical channel per partition.

The MSC was able to function in dual PSI mode; i.e. a couple of MSCs might be connected to up to 16 devices allowing a pool of 16 logical channels allocated transparently to software (except initialization and malfunction). Dual-PSI allowed dynamic file sharing between two independent GCOS systems, tanks to a software trick to implements shared locks between subsystems by writing a LOCKED status bit in the file entry inside the VTOC using an uninterruptable channel program performing a SENSE/SET if UNLOCKED chain of commands to the MSC. This feature with no hardware impact was known to customers as "coupled systems" feature.

The lack of buffer size in the MSC precluded the automatic recovery from data transfer errors. CRC was computed by the MSC but retries had to be performed by the operating system module (PIAR).

Technology

The MSC was implemented in the same technology as Level 64 (TTL 74N, SP10)

Tests and Diagnostics

The MSC was maintained with  a check-out program running under the free-standing operating system SCP and by functional tests (under SCP and later under GCOS). Those tests emphasized stress on transfer rates on one or several channels, but were not always able to anticipate real stress load caused by variations in CPU speed (creation of sub-models) or introduction of new formats.

MSC-E

The MSC project's maintenance was transferred from Billerica to Paris in 1973-1974. The most visible change was the discarding of 2314 family of disc pack and the support of larger discs. The MSC-E included cost-reduction features (denser memory, use of 74S technology, repackaging of card-cages). With MSC-E, coincided the transfer from Honeywell to MPI (a CDC joint venture) of the production of discs.

In addition to MSU-300, MSC-E supported non removable MSU-500 and MSU-555 fixed disks.

MSC-RV

MSC-RV was a complete reengineering of the MSC architecture by using a new processor (based on bit-sliced AMD processor) and the replacement of DLI disc drive interface for the more standard SMD interface. However, the paranoia against clones still subsist in Honeywell, the disc interface was a specially modified version of SMD named SMD-1 interface (also supported by DPS-4 and DPS-6). The discs connected to MSC-RV were MPI removable SMD 300, with a capacity of 300MB, while the SMD-80 (with 80MB per drive) connected to DPS-4 were also available for conversion purpose. SMD-80 were not available as a GCOS residency. They were only data and application discs.

MSC-RV differed functionally from MSC-E by the size of the volumes and by the restriction to a single CKD format.

MSC-H project

MSC-H was the code name for a project contemplated since he early 1980sthat was eventually discontinued. It would have supported fixed discs and tapes on the same subsystem, allowing off-line back-ups of disc files. The discs contemplated at the origin were CII developed Cynthia family used in fixed format. The cancellation of large capacity models and the eventual discontinuation of the Bull disc activity decreases the interest for the project. The specification of fixed sectors formatting needed a substantial software revamping that was not available until the second part of the 1980s and compromised the profitability of that project. A similar less ambitious project was  named (in 1981) MSC-RF but all those attempts were not successful.

MSC-4

The MSC-4 project differed from its predecessors by the integration of the controller (s) and of 8 in drives in the same cabinet. Instead of being sourced from a somewhat fledging MPI, the 500MB FSD-500 drives were sourced from Hitachi. A low-height cabinet was able to store up to 4 drives. The MSC-4 engine was a reimplementation of the MSC-RV engine.

MSC-4B

MSC-4B differed essentially from MSC-4 by introducing a PSI-S interface, a mode developed by NEC to increase the transfer rate on PSI. PSI-S was available on Aquila (from NEC origin), Ares phase 2 and Auriga. Acknowledgment signals were no more sent for each byte transfer to the IOC allowing to almost doubling the peak transfer rate.

Copernique project

Bull contracted with Copernique the realization of a high end subsystem with a distributed intelligence option as a development of the special realization of Copernique for the Level 6. Bull specified an interface expected to-be standard instead of the SCSI interface chosen by Copernique. The project was initiated in 1987. The device interface selected by Bull and Honeywell with Control Data was IPI-2 (Intelligent Peripheral Interface) instead of SCSI. Instead of IPI-3 interface used to support similar drives on DPS-8000, Bull was keeping the PSI connection

Eventually, the project was cancelled.

SCSI Controller on DPS-7000

When it was decided around 1985 to derive a low-cost version from the Ares system, it became obvious that its discs should use low cost competitive discs developed for the micro-computer industry. Simultaneously, Groupe Bull had chosen to use MC68000 as its choice microprocessor Multibus II as its small systems backbone. So, the connection of SCSI discs through a Multibus II was the base of the new storage subsystem for the Libra project developed around 1987-1988. A quest for an existing controller of this kind started, but Multibus II was not attractive to the OEM suppliers and it was eventually decided to work in cooperation with a British design company on such a subsystem. Bull had also developed an interconnect between Multibus II and DPS-7000 I/O bus that emulated the PSI channels software visibility. That board was used across the design of the new peripheral processors.
The SCSI discs were used with a fixed sector format (common to the microcomputer industry). Such format was already checked-out and was secure enough to avoid some of the burden found in the analog part of the device in first MSCs. It did not need the synchronization surfaces. A CKD emulation , such as that what made the success of EMC² later, was not adopted. So many components of GCOS 7 had to be revamped to support exclusively the new "fixed Sectors format". 

FIPS project

In the late 1990s, before plans for shelving off the extension of high range GCOS7 had materialized, it was contemplated to offer IBM or IBM compatible storage subsystems. A IBM channel adapter to the PSI channel had been realized by a joint work group between IBM Poughkeepsie and Bull-Phoenix. As few differences existed between PSI of DPS-7 and DPS-8000 product lines, this solution was prototyped on a DPS-7000 in Phoenix. But it was not introduced on the market.

 

EMC subsystems

In the mid 1990s, Bull renounced to build itself its own controllers and relied on external suppliers who had already penetrate the main frame market with subsystems, with RAID capability, based on microcomputer supplies. The same subsystems were offered on the UNIX product line and were also offered as Network Storage systems.

 

Magnetic Tape Processors

MTC

The original MTC was designed in Billerica to support the collection of tapes available in 1970 in GE, Honeywell and across the industry. Two recording formats were available NRZI IBM formats in 7 or 9 tracks available in densities (200 bpi, 556 and 800 bpi) and PE (Phase encoding) format also introduced by IBM in 800 and 1600 bpi. Several logical formats had been introduced by GE and Honeywell in GE-100 and H-200 product lines . Level 62 and Level 64 used the IBM format (including labels) as the native format. Other formats were supported by utilities and by the emulators.
The physical format of the tapes (density and speed) had to be "guessed" by GCOS as part of the "automatic volume recognition" procedure, that freed the operator of mandatory mounting on a specific drive.

Although also designed in Billerica the MTC used a different engine from the MSC. That engine was optimized towards minimizing the start stop time and to perform efficiently data chaining across different zones of memory. The processor did recognize end of blocks characters and was able to perform on the fly code conversion.

Two MTC could be associated to an extended crossbar allowing 16 tape units to be connected to each controller.7-tracks tapes support was an extra-cost option.

The technology was Level 64 based (TTL 74N and S, SP10 small boards).

MTC was supported by a collection of maintenance tools specially developed in Billerica. In addition of functional tests available for SCP and transferred under GCOS by Paris engineering (in 1976-1977), a programmed maintenance panel (in fact an interpreter for a  single or a batch of hardware level commands) was made available (under SCP and GCOS). Tape devices analog hardware electronics was hardly visible through the DLI interface and functional tests preceded oscilloscope investigations.

MTC-E

When Paris engineering took over the project in 1974, a new cost-reduced version of MTC was developed for Level-64-DPS. It eliminated rarely selected  options, like 7 tracks support and NRZI. The controller engine was the same as MTC, simply reimplemented in 74S technology.

ATP

An "Advanced Tape controller" was designed to support 6250 bpi tapes with GCR format developed by CII prior the CII-HB merger. In addition to GCR tapes, ATP provided a 2x16 crossbar that could be either be used as a dual channel tape subsystem in a single system or being shared between two independent software system. Actually, P7G (alais Leo, DPS-7-82) in a dual processor configuration could be partitioned in two systems under GCOS7 and the Siris8 emulator. ATP was used in high performances members of DPS-7 lines during the 1990s in conjunction with PENA-30 tape drives.
The subsystem was initially developed in Les Clayes, but the maintenance of it was transferred in Belfort.

MTC-G

Magnetic Tapes Attachment on  URC-E (MTA)

Cartridge Tapes Libraries

Cartridge tapes became popular at the end of the 1980s and customers of DPS-7000 large systems required the connection of Masstor and StorageTek libraries. 

 

Datanet Font End Processor