Histoire de l'URC

Origine:

A une revue du programme Charlie à la fin de 1967, John Haanstra suggéra l'adoption d'un mini-ordinateur pour effectuer le contrôle des entrées sorties. A cette époque, ni Bull-GE, ni General Electric ne disposaient de matériel semblable - le Datanet-30 était construit en une technologie obsolète et son successeur le Datanet 355 était plus puissant, mais trop cher pour être utilisé à plusieurs exemplaires sur un système moyen.
L'équipe de Georges Lepicard avait déjà commencé à faire les spécifications d'un contrôleur de lignes de télécommunications micro-programmable qui évolua au cours de l'année 1968 en ce qui devint plus tard connu sous le nom de URC (Unit Record Controller).
La raison pour laquelle ce mini-ordinateur s'appelle Unit Record, est que Bull-General Electric avait obtenu la "mission" des appareils Unit Records (appareils à cartes et imprimantes) pour le groupe, les appareils étant confiés à Belfort, les sous-systèmes NPL devant être conçus à Paris dans le Medium Systems Department.
Cet URC, essentiellement optimisé pour le système moyen -futur Level 64- devait servir aussi de sous-système unit record pour le haut de gamme et l'établissement parisien ne faisait pas trop mystère de son souhait de voir utiliser cette plate-forme comme un processeur de bas de gamme, réglant ainsi un vieux compte avec leurs amis transalpins.
Le système en cours de conception n'était pas -en principe un système transactionnel- mais il semblait désirable de le doter d'une configuration minimale de ligne de communications (support de Teletypes et de ligne haute vitesse 4800 bps pour le remote batch). Un système doté d'un processeur 16-bits   fonctionnant à une fréquence de 6 MHz -celle du CPU- devait être capable de multiplexer un ensemble d'appareils à cartes, une imprimante et 16 lignes à 110 bps en plus d'une ou deux lignes remote batch, moyennant la dotation de mémoires tampon adaptées.
L'idée d'un processeur de maintenance faisant les diagnostics off-line de la logique du processeur principal et capable de suppléer aux procédures manuelles d'initialisation du système se fit jour en 1969-1970 et comme ce processeur était susceptible d'utiliser off-line les périphériques unit record, il apparut judicieux de combiner ces fonctions avec celles de l'URC. Le seul appareil manquant était une mémoire de masse permanente pour laquelle l'utilisation des cassettes de ruban magnétique était -en 1970- une solution acceptable, qui devint encore plus attrayante lorsque les augures annoncèrent que ce media pouvait remplacer avantageusement la carte perforée comme véhicule de saisie de données.

Projet URC

La conception et la réalisation de l'URC a été réalisée dans la division Périphériques de la direction hardware des Systèmes Moyens de Honeywell-Bull sous l'autorité de Henri Verdier.

Les outils logiciels étaient développés dans la division Software de la Direction hardware, initialement dirigée par Michel Rocher, puis par Jean-Jacques Pairault.

Les "device adapters" de périphériques étaient conçus par l'équipe de Henri Verdier et réalisés par les constructeurs des périphériques -ils se trouvaient dans l'armoire du périphérique et packagés avec l'électronique analogique spécifique de celui-ci, à l'exception des adaptateurs de communication (MLA) , intégrés dans un tiroir voisin de l'URC, réalisés par l'équipe de Jean Akriche chez Henri Verdier.

Architecture de l'URC

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".

Technologie de l'URC

La technologie était identique à celle du processeur principal Level 64 (mémoire MOS 4Kbits, technologie TTL 74N, packaging SP-10.

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 cassettes de bandes magnétiques  (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

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.

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.

lecteur de cartes

• PCR80
  
  Le lecteur de cartes perforées PCR80 était de conception Honeywell, mais sa fabrication fut transférée à Belfort en 1972.
  

lecteur-perforateur de cartes

• PCP80
  
  Le perforateur de cartes PCP-80 utilise la même base mécanique que le PCR80.
  

lecteur de documents

• LD1
  
  Le lecteur de documents OCR ou MICR de fabrication Bull Belfort avait déjà été commercialisé sur les GE-100 et GE-400. Il fut reconnecté sur le Level-64

imprimante

• PR71
  
  Les imprimante à bande d'impression PR46 et de la PR71 furent les première imprimantes Bull à disposer d'un ensemble de caractères interchangeable par l'opérateur du client. La bande était auto-reconnaissable par le pilote de l'URC.
  Ces imprimantes possédaient un mécanisme de saut de papier variable suivant un mécanisme firmware émulant le fonctionnement des bandes pilotes. Cette émulation se faisait dans le pilote de l'URC et pouvait être rechargé par le logiciel GCOS.
  
• H112
  
  L'imprimante Honeywell H-112 fut essentiellement utilisée pour la reprise des systèmes récents Honeywell 3200.

La définition de l'attachement imprimante posa des problèmes particuliers dus à l'existence d'une phase off-line,  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

• H234X
  
  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. Seuls font exception des systèmes de haut de gamme ayant reçu un adaptateur spécial pour une console conçu à Boston à base de CRT. 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

La mise au point initiale du système Level 64 commença à Paris Gambetta en avril 1972. Les contrôleurs de bandes magnétiques et de disques étaient développés à Billerica et n'étaient pas encore disponibles. Aussi, le système central et sa mémoire devaient être initialisés à partir d'un deck de cartes perforées lues dans l'URC. Cette fonction de durée assez longue (de l'ordre de 15 minutes) fut utilisée seulement avant la connexion du MSC et du MTC. En fait, le lecteur de cassette et son "device adapter" (produit par Honeywell Italia) n'étaient pas non plus disponible, ce qui fait que le paquet de cartes -en mode binaire- émulait la future cassette du point de vue fonctionnalité d'utilisation. la cassette inversement émulera le lecteur de cartes en adoptant des blocs de 120 octets (960 bits) .
A noter que le système prototype du Level 64 possédait une mémoire à tores magnétiques comme aussi le prototype de l'URC, bien qu'il soit prévu d'utiliser des mémoires DRAM dès le début (seul le premier prototype était équipé de mémoire à tores).

On décrira ici, l'initialisation des prototypes complets à partir de la cassette.
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 cassette située dans le lecteur, puis sur le contrôle de cet "attachement d'initialisation", il lisait depuis le cassette 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 cassette. 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 cassette, 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 cassette et l'imprimante. L'accès à la cassette 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.

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'URC-MLA vers le haut.

Commutateur d'interface DAI

Ce switch permettant de connecter un appareil (par exemple une imprimante) à deux URC fut construit. Il ne possédait pas de support système et son action nécessitait la réinitialisation du système auquel était reconnecté l'appareil.