Lorsque je travaillais sur mon MSCS dans les années 1970, j'ai programmé à la fois sur un ordinateur central (Univac 1108) et sur un mini-ordinateur 12 bits d'occasion (PDP-8) avec 4K de mémoire centrale.
Le PDP-8 était connecté à un télétype modèle ASR-33 (envoi-réception automatique). On peut voir ici l'ordinateur et le téléscripteur à côté :
L'ASR-33 possédait à la fois un lecteur de bande de papier ASCII 8 bits et un perforateur. Le lecteur pouvait être utilisé pour saisir à la fois des données binaires et un code source ASCII ou tout autre texte en clair. Pour exécuter un programme, il fallait d'abord charger un programme "bootstrap" dans le PDP-8 à l'aide des commutateurs du panneau avant. Ce programme était juste assez long pour activer le lecteur de bande papier et lire le contenu d'une bande contenant l'image binaire du programme.
Le lecteur (et le perforateur) fonctionnaient tous deux à seulement 10 caractères par seconde - soit 110 bauds (comparez cela aux 115 200 bauds normalement associés aux interfaces RS-232 d'aujourd'hui, ou aux interfaces 10 Mo ou plus rapides auxquelles nous sommes habitués avec Internet - plus de 100 000 fois plus rapides). Mais encore une fois, nous ne chargions que 4K de mémoire 12 bits, ce qui ne prenait "que" 10 minutes environ pour charger un programme qui utilisait toute la mémoire - généralement un peu moins, car le programme avait besoin d'un peu d'espace pour les données.
Voici un gros plan de seulement le Télétype avec son lecteur/poinçon à gauche, montrant plus clairement la bande de papier.
Supposons que vous vouliez écrire un programme en assembleur. Vous chargeriez d'abord un éditeur, à partir de son image binaire comme décrit ci-dessus. Ses capacités seraient similaires à celles des éditeurs de ligne de commande sous UNIX ou Linux, comme vi. Vous tapez votre programme dans l'éditeur, vous l'imprimez probablement (également à 10 caractères par seconde), puis vous faites les corrections nécessaires. Le programme de l'éditeur était généralement beaucoup plus petit que 4K, parce que vous vouliez avoir le plus de place possible en mémoire pour contenir votre code source pendant que vous le modifiez. Comme le PDP-8 était une machine 12 bits, il pouvait contenir deux caractères 6 bits dans chaque mot. Cela signifiait cependant pas de minuscules - tout était en TOUTES MAJUSCULES.
Une fois que vous aviez le programme comme vous le vouliez, vous commandiez au programme d'édition de perforer une copie de la source sur une bande de papier. Puis vous chargiez l'assembleur (à partir de son propre binaire sur bande papier). On l'appelait un assembleur à deux passages, parce qu'il lisait deux fois le code source que vous aviez perforé auparavant - la première fois pour établir l'emplacement de tous les symboles, et une deuxième fois pour créer réellement la sortie binaire. Ce schéma permettait d'utiliser des références avant dans le code.
Lorsque l'on effectuait la deuxième passe, le lecteur et le poinçon étaient tous deux actifs - l'un lisant le code source, et l'autre poinçonnant le binaire. Pendant le poinçonnage de la bande, l'imprimante serait déconnectée pour ne pas imprimer de déchets.
C'était le scénario de base - il y avait des assembleurs plus sophistiqués avec des linkers relocalisables qui permettaient d'assembler plusieurs programmes indépendamment, et de les lier ensemble pour produire une bande binaire finale.
Parce que ce processus était si laborieux, c'était une vraie douleur si vous faisiez une erreur dans votre programme et aviez besoin de la corriger. Évidemment, vous ne vouliez pas avoir à recharger tous ces programmes et passer par toute cette procédure pour réparer une simple erreur. C'est ainsi que l'on est devenu assez doué pour créer des correctifs binaires à l'aide d'un programme de débogage. Après avoir testé le patch, on pouvait dire au débogueur de perforer une nouvelle bande binaire, soit avec juste le patch, soit avec le programme entier pour remplacer la bande originale.
Plus tard, vous rassembliez toutes vos notes de patch, chargiez à nouveau le programme éditeur, puis lui faisiez lire la bande de code source que vous aviez perforée bien plus tôt dans l'éditeur, et répétiez le processus.
Il y avait aussi des lecteurs de bande papier autonomes à grande vitesse, comme le PC04 illustré ci-dessous, qui pouvait lire 300 caractères par seconde, et perforer 50 caractères par seconde. Je n'en ai jamais eu un à ma disposition.
.