Le RIM Loader  : démarrer une machine sans ROM

Dans la famille des machines DEC 12 bits, le Read-In Mode Loader apparaît avec le PDP-5, puis devient particulièrement connu avec le PDP-8, où il sert classiquement à charger le BIN Loader depuis un ruban perforé.

Le RIM Loader, pour Read-In Mode Loader, est un petit programme de chargement utilisé sur les ordinateurs PDP-8 de Digital Equipment Corporation. Il ne s’agit pas d’un système d’exploitation, ni même d’un moniteur complet, mais d’un programme minimal de démarrage.

Son rôle est très simple : permettre à la machine de lire un programme depuis un ruban perforé, généralement à l’aide d’un terminal ASR-33, puis de placer ce programme en mémoire centrale.

Le RIM Loader constitue donc une étape importante entre la machine nue, manipulée depuis le panneau de commande, et l’exécution de programmes plus complexes comme le BIN Loader, FOCAL, ou plus tard un système comme OS/8.

Pourquoi fallait-il un chargeur de démarrage ?

Sur les ordinateurs modernes, lorsqu’on allume la machine, un programme intégré dans une mémoire permanente — BIOS, UEFI ou firmware — initialise le matériel et lance le système d’exploitation.

Sur un PDP-8 des années 1960, la situation est différente. La machine ne dispose pas, dans sa configuration classique, d’une ROM de démarrage comparable à celle des ordinateurs actuels. Lorsqu’elle est arrêtée, le processeur ne sait pas automatiquement où aller chercher un programme.

L’utilisateur doit donc fournir à la machine un premier petit programme, appelé chargeur ou loader. Ce programme sert uniquement à amorcer le chargement d’un autre programme plus important.

C’est précisément le rôle du RIM Loader.

Un programme extrêmement petit

Le RIM Loader est volontairement très court. La documentation DEC le décrit comme une routine de taille minimale destinée à lire des rubans perforés codés au format Read-In Mode via le lecteur de ruban de l’ASR-33. Il occupe seulement 17 mots décimaux, soit 21 mots octaux, en mémoire.

Sur le PDP-8, les adresses sont généralement notées en octal, c’est-à-dire en base 8. Le RIM Loader est classiquement placé dans la partie haute de la mémoire, aux adresses proches de 7756. Dans les exemples de démarrage du simulateur PDP-8/E de Bernhard Baehr, le RIM Loader est saisi aux adresses 7756 à 7775.

Cette petite taille est essentielle : le programme doit pouvoir être saisi manuellement depuis le panneau de commande sans que l’opération devienne trop longue.

Le démarrage manuel depuis le panneau de commande

Le PDP-8 possède un panneau frontal avec des interrupteurs permettant de manipuler directement la mémoire. L’utilisateur peut indiquer une adresse, déposer une instruction, passer à l’adresse suivante, puis recommencer.

Pour installer le RIM Loader, on procède donc de manière manuelle :

• on place l’adresse de départ dans le registre de commutation ;
• on dépose la première instruction ;
• on dépose ensuite les instructions suivantes une par une ;
• une fois le chargeur en mémoire, on lance son exécution.

La documentation DEC indique explicitement que le RIM Loader peut être placé en mémoire depuis les interrupteurs de la console. Elle donne ensuite la procédure de démarrage : placer le ruban perforé dans le lecteur, mettre l’ASR-33 en ligne, placer l’adresse de départ 7756 dans le registre de commutation, charger cette adresse, puis appuyer sur START.

En apparence, cette opération peut sembler rudimentaire. Mais elle est fondamentale : elle permet de passer d’une machine presque vide à une machine capable de lire automatiquement un programme externe.

Le rôle du ruban perforé

Le support de chargement habituel est le ruban perforé. Il contient une suite de caractères codés qui représentent des adresses et des données.

Le RIM Loader lit ce ruban et interprète son contenu. Dans le format RIM, les informations sont organisées sous forme de couples : une adresse, puis le contenu à déposer à cette adresse. Le programme assemble les caractères lus deux par deux, reconstitue les valeurs en langage machine, puis les écrit en mémoire.

On peut résumer le principe ainsi :

• le ruban fournit une adresse mémoire ;
• le ruban fournit ensuite une valeur à stocker ;
• le RIM Loader place cette valeur à l’adresse indiquée ;
• l’opération se répète jusqu’à la fin du chargement.

Le RIM Loader ne comprend pas un format riche ou complexe. Il fait volontairement très peu de choses, mais il les fait avec très peu d’instructions.

Pourquoi charger ensuite le BIN Loader ?

Le RIM Loader est surtout utilisé pour charger un autre programme : le Binary Loader, souvent appelé BIN Loader.

La documentation DEC explique que les rubans au format RIM sont environ deux fois plus longs que des rubans équivalents au format binaire. Elle recommande donc d’utiliser le RIM Loader principalement pour charger le Binary Loader, puis d’utiliser ensuite ce dernier pour les programmes ordinaires.

Le processus typique est donc le suivant :

1. l’utilisateur saisit le RIM Loader depuis le panneau frontal ;
2. le RIM Loader lit le ruban contenant le BIN Loader ;
3. le BIN Loader est placé en mémoire ;
4. le BIN Loader sert ensuite à charger des programmes plus importants.

Ce fonctionnement peut paraître indirect, mais il répond à une contrainte pratique : le tout premier programme doit être minuscule, tandis que les programmes chargés ensuite peuvent utiliser un format plus efficace.

Le RIM Loader n’est pas un système d’exploitation

Il est important de ne pas confondre le RIM Loader avec un système d’exploitation.

Un système d’exploitation organise les ressources de la machine : fichiers, périphériques, mémoire, programmes, commandes utilisateur, parfois utilisateurs multiples. Le RIM Loader ne fait rien de tout cela.

Il ne fournit pas :

• de système de fichiers ;
• de gestion des utilisateurs ;
• de commandes interactives ;
• de gestion générale des périphériques ;
• de planification des programmes.

Son rôle est beaucoup plus élémentaire : lire un ruban et déposer son contenu en mémoire.

Mais il appartient malgré tout à l’histoire des systèmes, car il représente la première étape de la chaîne qui mène au chargement d’un environnement logiciel plus complet.

Une étape dans la chaîne de démarrage

On peut voir le démarrage d’un PDP-8 comme une succession de niveaux :

1. Le panneau frontal : l’utilisateur agit directement sur la machine.
2. Le RIM Loader : premier programme minimal entré à la main.
3. Le BIN Loader : chargeur plus pratique et plus efficace.
4. Les programmes utilisateurs : FOCAL, diagnostics, assembleurs, utilitaires.
5. Le système d’exploitation : par exemple OS/8 sur les configurations équipées des périphériques nécessaires.

Dans le tutoriel du simulateur PDP-8/E de Bernhard Baehr, cette progression est bien visible : on commence par saisir le RIM Loader, on charge ensuite le BIN Loader, puis on charge FOCAL-8 ; plus loin, le tutoriel montre aussi le démarrage d’OS/8 à partir d’un disque RK05 émulé.

Le RIM Loader est donc une forme d’amorce logicielle : il ne constitue pas le système, mais il permet d’y accéder.

Pourquoi ce mécanisme est historiquement important

Le RIM Loader illustre une époque où le démarrage d’un ordinateur n’était pas encore invisible pour l’utilisateur. L’opérateur devait connaître la machine, manipuler ses interrupteurs, comprendre les adresses mémoire et savoir charger les programmes depuis un support physique.

Cette proximité entre matériel et logiciel est caractéristique des mini-ordinateurs des années 1960. Le démarrage n’est pas seulement une opération automatique : c’est une procédure technique, presque un dialogue direct avec la machine.

Le RIM Loader montre aussi une idée fondamentale de l’informatique : pour charger un programme complexe, il faut souvent commencer par un programme plus simple. Cette logique d’amorçage existe encore aujourd’hui, même si elle est cachée sous plusieurs couches de firmware, de contrôleurs, de chargeurs de démarrage et de systèmes d’exploitation.

Source principale : documentation DEC du Read-In-Mode Loader, documentation DEC du système papier PDP-8, et tutoriel du simulateur PDP-8/E de Bernhard Baehr.