Entradas de agosto de 2012

Alguien, alguna vez, me dijo que yo era un tipo raro por el simple hecho de ser programador informático cuando, desarrollando un software de comunicación sobre redes TCP/IP, me dio por asignar el valor -1 al número ilimitado de licencias de uso. Fue algo espontáneo, instintivo, mecánico: si 0 significaba que no tenías licencia para utilizar el programa, 1 que disponías de una sola y 2 que tenías dos, -1 fue mi elección para el número infinito de permisos de utilización; algo así como una puerta trasera para depurar la aplicación con cientos de instancias al tiempo o, también, una gracia o prebenda para con aquellos clientes que compraban mucho y pagaban bien.

Cualquiera que haya conocido a un programador informático podrá asegurar con total rotundidad que, efectivamente, estos tipos son muy raros. Hablan de códigos ininteligibles, de instrucciones, de sentencias, de bucles, de saltos y de condiciones. Es tal la inmersión léxica en la forma de dirigirse a un ordenador, que sus cerebros no son cúmulos de neuronas en sinapsis, sino millones de líneas de código ofuscado relacionadas entre sí por gigantescos diagramas de clase.

De esta especie de individuos nació aquello que se dio en llamar hexspeak, una suerte de lenguaje informático cachondo para designar identificadores únicos de memoria a la hora de depurar el código de diversas aplicaciones, sistemas operativos o, incluso, procesadores. El hexspeak es muy parecido al leet (1337 en leet), un idioma originado en las antiguas BBS que fue durante muchos años medio de conversación cotidiano de hackers y gurús de la Red, y que hoy, por extremadamente difundido, en considerado más propio de lamers y de newbies o noobs.

La particularidad de hexspeak es que, mientras que leet utiliza números, letras y símbolos para sustituir los caracteres de las distintas palabras, hexspeak se ciñe exclusivamente a la notación hexadecimal, la cual incluye los números del 0 al 9 y las letras mayúsculas de la A a la F, dieciséis dígitos en total (0123456789ABCDEF). Esto restringe bastante las palabras que pueden ser formadas, por lo que el guiño satírico o el giro burlesco se hace necesario para crear términos inteligentes.

Con el 0 representando a la letra O, el 1 a la L, el 5 a la S o el 6 a la G, entre otros, las palabras que se inventan los informáticos vienen a ser valores mágicos de depuración, es decir, igual que los números mágicos que, de manera codificada, identifican a un tipo de archivo en su cabecera (como GIF89a a los ficheros GIF, FF D8 a los JPEG o %PDF a los PDF). En este caso, estos identificadores únicos son valores específicos que se escriben en memoria durante la asignación o la cancelación de asignación, de modo que, posteriormente, se pueda decidir si los datos alojados se han corrompido en el proceso o no.

Numéricamente los programadores prefieren los valores impares, por aquello de que los procesadores que no implementan direccionamiento de byte casquen cuando intenten utilizarlos como punteros. Además, estos valores deben ser elegidos lo más lejos posible de las direcciones de memoria de probable aparición, como las que pueden ocupar el propio código del programa, los datos estáticos, los datos de montículo (heap) o la pila. Por lo tanto, puesto que es muy poco probable (aunque no imposible) que un entero de 32 bits tenga un valor hexspeak bien formado, la aparición de un número así en un depurador o en un volcado de memoria indica, de manera casi segura, un error como un desbordamiento de búfer o una variable no inicializada.

Pero es que además, y como decíamos antes, el hexspeak lleva aparejado un jolgorio y una guasa inherentes propios del cachondeo más ingenioso de los desarrolladores informáticos. Y para muestra varios botones. Reproducimos, a continuación, algunos de los términos más famosos difundidos por los programadores de las más importantes compañías del mundo de la computación. Nótese que el prefijo 0x es utilizado comúnmente en el mundo de la programación para designar que lo que sigue es un número en notación hexadecimal.

● 0x8BADF00D (fonéticamente ate bad food), algo así como «comió mala comida» o «se alimentó mal». Utilizado por Apple en los informes de fallos de su sistema operativo iOS cuando una aplicación tarda demasiado en correr, terminar o responder a los eventos del sistema.

● 0xABADBABE (a bad babe), traducido como «una chica mala». Lo utiliza también Apple como número mágico para el sector cero o área de arranque de un disco (Boot Zero Block).

● 0xBADDCAFE (bad cafe), «mal café» o «café malo». Usado por OpenSolaris para designar la situación de memoria asignada pero no inicializada.

● 0xDEADBEEF (dead beef), «carne muerta». Normalmente utilizado para indicar un fallo de software en sistemas embebidos. Originalmente se le dio el uso de marcar áreas de memoria recientemente asignadas pero todavía sin inicializar. Fue un término típico en sistemas IBM RS/6000, PowerPC 32-bit y Commodore Amiga.

● 0xDEADDEAD (dead dead), literalmente «muerto muerto». Es el código de comprobación de errores que se muestra al ser invocada una Pantalla Azul de la Muerte (Blue Screen of Death) utilizado para obtener un volcado de memoria en sistemas basados en Windows NT.

● 0xDEFEC8ED (defecated), «defecado». Es el número mágico para los volcados de memoria en OpenSolaris.

● 0xB16B00B5 (big boobs, ahí es nada), «tetas grandes». Requerido por el software de virtualización Hyper-V de Microsoft para ser utilizado por los clientes Linux como firma invitada. Menuda guasa tienen algunos.

● 0xFEE1DEAD (feel dead), así como «me siento muerto». Usado como número mágico en las llamadas de reinicio de sistema de Linux.

● face:b00c (facebook), pues eso. Se utiliza en la dirección de protocolo IPv6 para www.v6.facebook.com.

Estos términos, entre otros muchos, representan el habla hexspeak de los programadores, esos locos cuyas mentes forman un conjunto de bases de datos distribuidas, de modelo eventualmente consistente, que ríete tú de Cassandra.

Los que dimos nuestros primeros pasos en esto de la informática delante de un ordenador de 8 bits aún recordamos con nostalgia las maneras en las que había que tratar a aquellos arcaicos cacharros y a sus periféricos. En los años ochenta la computación doméstica era todo un propósito de buenas intenciones, parca exactitud y mucho trabajo de campo. No existía Internet, ni amigos expertos en la materia ni, por supuesto, la ingente cantidad de información a la que tenemos alcance hoy día por diversas vías.

La mayoría de ordenadores de aquella época tenían la mala y sufrida costumbre de aceptar datos externos hacia su memoria desde dispositivos tan avanzados como ellos, esto es, desde delgadas cintas magnéticas enrolladas y encerradas en carcasas rectangulares de plástico; lo que toda la vida se ha conocido como cintas de casete. Para almacenar programas se servían del mismo método, pero haciendo viajar los bits en sentido contrario.

El ZX Spectrum (que en él nos vamos a centrar), en sus primeros años, codificaba todo su software en cintas de casete como una secuencia de pulsos que producían sonidos similares a los de los módem analógicos actuales (¿actuales?). Aquellos mágicos pitidos, hoy mitificados por muchos, se reproducían en un aparato lector de casetes común y corriente, haciendo pasar los baudios al computador por medio de un cable de sonido, mono o estéreo, de conectores tipo minijack clásicos.

Los molestos, y a la vez que encantadores, chirridos del Spectrum se grababan en las cintas magnéticas haciendo uso de una modulación muy fiable y, al tiempo, inusualmente simple, similar a la modulación por ancho de pulsos, pero sin una frecuencia de reloj o período constate. Los impulsos de diferentes duraciones se correspondían con ceros o unos, a saber: un 0 se representaba por un pulso de, aproximadamente (aquí la exactitud brillaba por su ausencia), 244 µs (microsegundos), seguido por un espacio de la misma duración (855 golpes de reloj cada uno a 3,5 MHz), haciendo un total de 489 µs. Un 1, por su lado, ocupaba el doble de tiempo, es decir, un total de 977 µs. Esto permitía el registro de 1.023 unos y 2.047 ceros por segundo. Por lo tanto, la velocidad de carga de un Spectrum venía a ser, de media, de unos 1.535 bits por segundo, lo que hacía que un programa de sólo 48 KB tardara alrededor de cinco interminables minutos en entrar en memoria.

Cada cinta original venía grabada de aquella manera y, aunque en un principio parece lógico pensar que todas ellas estaban codificadas igual, la verdad es que cada grabadora era de su padre y de su madre, y el volumen, el tono, el balance o la situación física de los sonidos en la cinta magnética podían diferir bastante de unas a otras. Ni te cuento cuando la grabación era pirata, no ya proveniente de las afamadas piezas de software de la época conocidas como copiones, sino de la copia casera en equipos de doble pletina o de la más socorrida y rudimentaria de todas: el duplicado desde tu casete al de tu vecino en una habitación sin ruidos y aguantando la respiración hasta que terminara (¡qué tiempos aquellos!; y, cuidado, algunos juegos copiados así hasta funcionaban y todo).

Con la aparición de los ordenadores ochobiteros, comenzaron a proliferar los reproductores-grabadores de cinta diseñados específicamente para estos menesteres. Los que hasta entonces habíamos tirado del casete Philips de toda la vida conectado al Spectrum, alucinamos con la aparición de los nuevos modelos de lo que se dio en llamar «datasetes», por aquello de ser casetes diseñados para la emisión y recepción de datos. Panasonic, SANYO, Commodore (sobre todo para sus máquinas), DYNADATA (muy típico también en MSX), PhoneMark y, sobre todo, el muy reconocido y extendido Computone fueron algunos de aquellos instrumentos tecnológicos que hacían de la carga de nuestros juegos y programas un auténtico suplicio o la más grata de las experiencias.

Todos (o casi todos) ellos venían con funciones muy útiles para la carga y el salvado de datos como, por ejemplo, contador de vueltas de cinta, reguladores varios, diversas salidas y entradas de audio, lucecitas de estado y, sobre todo, el famoso regulador del azimut. El azimut era un concepto directamente traído de la cartografía, la topografía o la geodesia, en lo que al ángulo (contado en el sentido de las agujas del reloj y a partir del norte geográfico) se refiere.

Las unidades de casete para Spectrum (otros también) disponían de un cabezal lector que se encargaba de interpretar la polaridad de las partículas magnéticas de la cinta, convirtiéndola en sonidos que, posteriormente, el aparato transformaría en bits. Dicho cabezal era basculante, esto es, era capaz de, anclado en un punto fijo, subir y bajar por el otro extremo una determinada cantidad angular. El lado móvil montaba un muelle de sujeción (que le posibilitaba ascender y descender con un control más o menos preciso) y un tornillo diseñado para ejecutar la acción de basculación. Básicamente lo que se observa en la siguiente ilustración.

Este tornillo del que hablamos es el que se conocía como tornillo del azimut o, por extensión, simplemente como azimut. Era el tornillo que nos traía de cabeza a los jovenzuelos de aquella época y el que terminó, en muchos equipos, destrozado, quebrado, destruido, golpeado, sacudido, apaleado y, en algunos casos, hasta incinerado.

En la era dorada del «gomas», como se le conocía a nuestro querido ZX Spectrum, no era para nada infrecuente recibir el típico y fatídico mensaje R Tape loading error, 0:1 al momento de intentar cargar un juego o programa. Aquel temido fallo de carga presagiaba una de las tardes más largas del fin de semana. El primer movimiento pasaba por toquetear los controles habituales como volumen, tono (graves y agudos), balance, cambio de mono a estéreo, etcétera. Las cintas, como decíamos anteriormente, estaban grabadas por equipos distintos, por lo que los diferentes mandos habían de regularse prácticamente para cada carga, siendo la práctica más típica un volumen del 75%, un 100% de agudos y 0% de graves. Además se aconsejaba desactivar los diversos filtros de audio (volumen, Dolby…) y no utilizar equipos Hi-Fi para cargar programas. Aunque todo esto muchas veces servía de bien poco.

Si el protocolo básico fallaba, tocaba girar el azimut, es decir, controlar el ángulo que formaba el cabezal magnético con la cinta. Parece mentira que dicho ángulo fuera tan importante para que el Spectrum escuchara bien al casete, y es que la música se puede oír mejor o peor, pero en una secuencia de datos, como se pierda uno, date por jodido.

El tornillo del azimut, comúnmente el de la derecha del cabezal (por llevar la contraria al esquema anterior), solía aceptar destornilladores planos y de estrella. El ajuste debía hacerse con el casete reproduciendo (modo PLAY) sobre todo, por aquello de regular a oído, pero también era posible girarlo en parado (modo STOP o PAUSE). Lo malo es que algunos modelos de casete, en los que los cabezales no sobresalían de la carcasa al reproducir, no disponían de un agujero practicado al efecto de acceder al azimut, por lo que muchos adolescentes de los ochenta tuvieron que recurrir al bricolaje casero, taladro y broca en mano, para agujerear la carcasa en el punto exacto del dichoso tornillo. También era importante hacer una marca en la posición original del azimut para, en cualquier momento, retornar a los ajustes de fábrica del aparato.

Regular el azimut en tiempo de reproducción mientras se cargaba un juego ─realmente─ era una tontería de rango aleatorio, pues el Spectrum vomitaba errores de carga en cuanto los primeros datos del proceso no le fueran gratos. En este caso, habría que rebobinar la cinta y volver a comenzar la carga mientras se gira el tornillo de nuevo, esperando cualquier cosa. Para evitar este tedioso cometido, se recurría a programas de software que permitían monitorizar los valores de entrada de audio de una manera gráfica hasta dejarlos perfectos, aunque esto no quisiera decir que para determinada cinta funcionaran.

Los programas de monitorización eran una especie de carta de ajuste de audio que, tras ser cargados en memoria, permitían visualizar de un modo intuitivo cada uno de los pulsos que el Spectrum recibía, a saber: ceros, unos o el denominado leader; este último se refiere a la señal inicial piloto, antes de la propia carga, acompañada por bandas rojas y cian. Los tres ajustes gráficos mostraban, por medio de unos pequeños cuadros, una vibración mayor o menor en función de la uniformidad y de la claridad de los impulsos recibidos desde el casete; a menor elongación de vibración, mejor calidad. Por medio del tornillo del azimut podíamos regular ese movimiento hasta ajustarlo al máximo. En teoría, el ajuste más preciso debería permitir la carga correcta de la cinta. En teoría.

Según sus diseñadores, el espectro de pulsos en el que trabajaba el Spectrum debía ser compatible con casi cualquier reproductor de cintas de casete y la verdad es que, pese a las diferencias en la reproducción y en la fidelidad del audio, el proceso de carga de software era bastante confiable. Pero, como comentábamos, no era nada extraño recibir en algún momento un error de carga y tener que empezar a tirar de giro de azimut.

Otro método más rudimentario para cambiar el ángulo de la cinta con respecto al cabezal era hundir físicamente con los dedos la casete hacia abajo, ejerciendo más o menos presión hasta que la señal llegara a la perfección. No pocos eran aquellos que iban introduciendo, poco a poco, trocitos de papel doblados de mayor o menor grosor entre la cinta y la tapa hasta que la inclinación del ángulo fuera el deseado. Por supuesto, estos casos eran exclusivos de los reproductores que carecían de azimut y su tornillo, o de aquellos usuarios que nunca descubrieron este mecanismo, que también los hubo.

Aquellos maravillosos años ya no volverán, gracias a Dios. Sin embargo, nadie puede negar el romanticismo que suponía girar un simple tornillo para que pareciera que acababas de solucionar el más complicado algoritmo informático de la historia. Romanticismo visto desde la distancia temporal, claro; en aquel tiempo era una puta jodienda.