Cuando trabajaba en mi MSCS allá por los años 70, programaba tanto en un mainframe (Univac 1108) como en un minicomputador usado de 12 bits (PDP-8) con 4K de memoria central.
El PDP-8 estaba conectado a un teletipo modelo ASR-33 (envío-recepción automática). Aquí se puede ver el ordenador y el teletipo al lado:
El ASR-33 tenía tanto un lector de cintas de papel ASCII de 8 bits como una perforadora. El lector podía utilizarse para introducir tanto datos binarios como código fuente ASCII u otro texto plano. Para ejecutar un programa, primero había que cargar un programa «de arranque» en el PDP-8 utilizando los interruptores del panel frontal. Este programa era lo suficientemente largo como para activar el lector de cintas de papel y leer el contenido de una cinta que contenía la imagen binaria del programa.
El lector (y el punzón) trabajaban a sólo 10 caracteres por segundo – es decir, 110 baudios (compárese con los 115.200 baudios normalmente asociados a las interfaces RS-232 de hoy en día, o las interfaces de 10 MB o más rápidas a las que estamos acostumbrados con Internet – más de 100.000 veces más rápidas). Pero además, sólo cargábamos 4K de memoria de 12 bits, por lo que «sólo» se tardaba unos 10 minutos en cargar un programa que utilizara toda la memoria – normalmente un poco menos, porque el programa necesitaba tener algo de espacio para los datos.
Aquí hay un primer plano de sólo el Teletype con su lector/punzón a la izquierda, mostrando la cinta de papel más claramente.
Supongamos que quieres escribir un programa en ensamblador. Primero cargarías un editor, a partir de su imagen binaria como se ha descrito anteriormente. Sus capacidades serían similares a las de los editores de línea de comandos en UNIX o Linux, como vi. Usted escribiría su programa en el editor, probablemente lo imprimiría (también a 10 caracteres por segundo), y luego haría cualquier corrección. El programa editor era normalmente mucho más pequeño que 4K, porque querías tener el máximo espacio en la memoria para mantener tu código fuente mientras lo editabas. Como el PDP-8 era una máquina de 12 bits, podía contener dos caracteres de 6 bits en cada palabra. Eso significaba que no había minúsculas – todo estaba en MAYÚSCULAS.
Una vez que se tenía el programa como se quería, se ordenaba al programa editor que sacara una copia del código fuente en una cinta de papel. Luego se cargaba el ensamblador (desde su propio binario en cinta de papel). Se llamaba ensamblador de 2 pases, porque leía el código fuente que se había perforado antes dos veces – la primera vez para establecer la ubicación de todos los símbolos, y una segunda pasada para crear realmente la salida binaria. Este esquema permitía utilizar referencias hacia adelante en el código.
Cuando se hacía la segunda pasada, tanto el lector como la perforadora estaban activos – uno leyendo el código fuente, y el otro perforando el binario. Mientras se perforaba la cinta, la impresora se desconectaba para que no imprimiera basura.
Este era el escenario básico – había ensambladores más sofisticados con enlazadores reubicables que permitían ensamblar varios programas de forma independiente, y enlazarlos entre sí para producir una cinta binaria final.
Debido a que este proceso era tan laborioso, era un verdadero dolor si cometías un error en tu programa y necesitabas arreglarlo. Obviamente no querías tener que recargar todos estos programas y pasar por todo este procedimiento para arreglar un simple error. Así que uno se volvía bastante bueno creando parches binarios usando un programa de depuración. Después de probar el parche, uno podía decirle al depurador que perforara una nueva cinta binaria, ya fuera sólo con el parche, o con el programa completo para reemplazar la cinta original.
Más tarde, uno reunía todas las notas del parche, cargaba el programa editor de nuevo, y luego hacía que leyera la cinta de código fuente que había perforado mucho antes en el editor, y repetía el proceso.
También había lectores de cinta de papel de alta velocidad independientes, como el PC04 que se muestra a continuación, que podía leer 300 caracteres por segundo, y perforar 50 caracteres por segundo. Nunca tuve uno de esos disponibles.
