Resumen

  • El programa que Alan R. Katz documentó en septiembre de 1981 decodificaba archivos del Rapicom 450 y producía mapas de bits monocromos que otros dispositivos podían mostrar o editar.
  • El trabajo exigía deshacer transformaciones de octetos, invertir ciertos campos sin invertir otros, recuperar el estado al principio de cada bloque y registrar la imagen resultante con el encabezado sencillo propuesto en RFC 797.

El archivo decía «fax recibido». La pantalla preguntaba «¿y dónde está la página?». Es una pregunta distinta. Un bloque de datos puede cruzar una línea de terminal intacto y seguir sin ofrecer una imagen que otro programa entienda. Alan R. Katz se enfrentó a esa diferencia en la RFC 798, publicada en septiembre de 1981. Su decodificador tradujo la peculiar conversación interna del Rapicom 450 a píxeles ordinarios; la RFC 797 propuso un recipiente corto para esos píxeles.

La instalación que describe Katz tenía un programa L10 dentro de NLS, en TOPS20. Entre el fax y la línea de terminal había una interfaz con microprocesador llamada FAXIE. El Rapicom enviaba bits en serie y FAXIE los agrupaba de ocho en ocho. Ya en esa primera frontera aparecía una trampa: los valores lógicos de MARK y SPACE en el aparato eran los inversos de RS232, por lo que FAXIE complementaba cada bit. Al guardar los datos conforme al formato del archivo Rapicom, el programa también invertía el orden de los bits dentro de cada octeto de datos y los complementaba. El decodificador tenía que deshacerlo.

Los octetos que indicaban longitud y comando no participaban en esa danza.

Cada bloque físico traía 585 bits. Siete ceros de relleno completaban 592 bits, es decir, 74 octetos de datos; longitud y comando llevaban el registro normal a 76 octetos. Había comandos de preparación, datos y fin. Esa estructura explicaba cómo conservar la transmisión. No explicaba aún cómo convertirla en una página. Para ello Katz reconstruyó el modo en que el dispositivo comprimia líneas blancas y negras.

Según la descripción, una hoja corriente tenía unas 2.100 líneas de 1.726 puntos. El modo Fine Detail codificaba todas; Quality saltaba una de cada dos; Express conservaba una de cada tres. Al mostrar la imagen, las líneas ausentes se repetían. El aparato trabajaba con pares de líneas: cada columna podía ser blanco-blanco, blanco-negro, negro-blanco o negro-negro. Las transiciones entre esos cuatro estados tenían códigos de longitud variable. Las rachas uniformes de blanco o negro se contaban con palabras que podían crecer de dos a siete bits. Quien leyera los bits como puntos sueltos obtendría una página imaginativa y falsa.

Además, «invertir» no era una instrucción única. El tratamiento del octeto almacenado era una cosa. En el encabezado interno del bloque, la cuenta de bits válidos, la posición horizontal y el tamaño de las rachas blanca y negra llegaban con el orden de sus bits invertido. El número de secuencia y el estado actual no. Las propias palabras de longitud de las rachas también venían invertidas dentro de su campo. Katz recalcó que invertir un campo de n bits era independiente de invertir y complementar un octeto. Un programador podía acertar la primera inversión y arruinar la segunda sin que el archivo dejara de parecer formalmente correcto.

El bloque daba pistas para salir de un tropiezo. Sus 585 bits incluían sincronización, encabezado de 37 bits, zona de datos de 512 y suma de comprobación. La cuenta de datos decía cuántos de los 512 bits importaban; un cero descartaba el bloque. Si la nueva posición horizontal adelantaba la anterior, se rellenaba el hueco con blanco; si retrocedía, los datos recién llegados sustituían la zona solapada. El número de secuencia recorría 0, 1, 2, 3 y permitía advertir una ausencia. Katz hacía reiniciar el estado, los tamaños de racha y la posición a partir del encabezado de cada bloque, aun si contradecían el final del anterior.

Así se podía seguir decodificando después de una pérdida; las partes perdidas no reaparecían por cortesía del encabezado.

Una vez resuelto el laberinto, la RFC 797 era casi refrescante. Cuatro octetos para anchura, cuatro para altura, uno para incremento horizontal y otro para vertical. Los datos empezaban en el undécimo octeto; las filas se leían de izquierda a derecha y de arriba abajo, con ceros a la derecha hasta completar el último octeto. Un incremento vertical de uno, dos o tres reflejaba los tres modos del Rapicom, y el visor repetía las filas al dibujar. La siguiente aplicación recibía una imagen de un bit por píxel en vez de heredar los secretos de la máquina.

Katz también puso precio de cómputo al resultado: alrededor de dos minutos de CPU en un DEC KL10 con TOPS20 para un documento medio en Fine Detail. El mapa de unos 1.726 por 2.100 puntos ocupaba cerca de 204 páginas de disco. Un terminal gráfico HP mostraba partes de la hoja, con zoom, porque la hoja entera no cabía. La victoria tenía ese tamaño concreto: ya no era solo un archivo entregado, sino una página que se podía mirar.