Entradas de la categoría ‘Cacharros antiguos’

Si utilizaste un PC durante los años ochenta o principios de los noventa, probablemente recuerdes el sonido característico del PC Speaker, aquel pequeño altavoz interno que tenía fama de producir únicamente pitidos; pitidos al arrancar, pitidos de error, pitidos en los videojuegos y, en general, pitidos para cualquier cosa que el ordenador quisiera comunicar al usuario. Comparado con una Sound Blaster o una AdLib, era poco más que una broma tecnológica.

Lo sorprendente es que, técnicamente, aquel insignificante altavoz era capaz de hacer bastante más de lo que parecía. De hecho, algunos programadores consiguieron reproducir voces digitalizadas, efectos de sonido complejos e incluso fragmentos musicales que parecían completamente imposibles para un dispositivo tan rudimentario. Y lo hicieron sin añadir hardware adicional.

Para entender el truco hay que comprender primero cómo funcionaba realmente el PC Speaker. A diferencia de una tarjeta de sonido moderna, no podía generar muestras digitales de audio ni reproducir varios canales simultáneamente. Estaba conectado a un temporizador programable Intel 8253 o 8254 presente en la placa base del PC, el cual generaba una onda cuadrada que encendía y apagaba el altavoz a una frecuencia determinada. Si configurabas una frecuencia de 440 Hz obtenías una nota La; si seleccionabas otra frecuencia distinta obtenías otra nota diferente.

Por eso los primeros juegos de PC sonaban como sonaban, porque el ordenador simplemente ordenaba al temporizador generar una frecuencia concreta y el altavoz vibraba siguiendo ese patrón. El resultado, pues, era esa onda cuadrada de la que hablamos, muy simple, rica en armónicos y bastante desagradable para los estándares actuales. Sin embargo, para una máquina de principios de los ochenta era una solución extraordinariamente barata y eficaz.

La limitación más importante era evidente, y es que el PC Speaker sólo conocía dos estados: encendido o apagado. No existían niveles de volumen, ni mezcla de sonidos, ni tonalidades complejas. A primera vista parecía imposible reproducir voz humana utilizando un dispositivo tan binario. Pero ahí entró en juego la creatividad de los programadores.

Algunos desarrolladores descubrieron que el cono del altavoz no respondía instantáneamente a los cambios eléctricos, sino que, como cualquier sistema mecánico, poseía una cierta inercia física. Si se activaba y desactivaba lo suficientemente rápido, el cono no llegaba a completar todo su recorrido y adoptaba posiciones intermedias, en otras palabras, aunque electrónicamente sólo existieran dos estados, mecánicamente podían obtenerse desplazamientos parciales. La técnica consistía en controlar aquel temporizador miles de veces por segundo y, en lugar de generar una simple nota musical, el programa modificaba constantemente la duración de los impulsos enviados al altavoz, cambiando con enorme rapidez el tiempo durante el cual permanecía activado o desactivado y haciendo posible simular diferentes amplitudes de señal. Este principio es muy parecido al que utilizan ciertas técnicas modernas de modulación por ancho de pulsos o PWM.

Desde el punto de vista matemático, lo que se hacía era aproximar una onda analógica mediante una sucesión extremadamente rápida de impulsos digitales. Cuanto mayor era la frecuencia de actualización, más convincente resultaba la ilusión acústica y, además, el oído humano actuaba como un filtro natural, integrando todas esas pequeñas variaciones en una forma de onda aparentemente continua. Por supuesto, aquello tenía un precio, y es que reproducir audio digitalizado mediante el PC Speaker consumía una cantidad enorme de tiempo de CPU. Mientras una Sound Blaster disponía de hardware específico para manejar el sonido, aquí era el propio procesador quien debía alimentar constantemente el flujo de datos y, por ejemplo, durante la reproducción de voz, una parte importante de la potencia de cálculo del ordenador quedaba dedicada exclusivamente a producir sonido.

¿Y por qué consumía tantos recursos? Pues básicamente por dos aspectos. El primero era la generación de interrupciones masivas (high overhead), pues para simular diferentes niveles de voltaje, la CPU tenía que cambiar el estado del altavoz (encendido/apagado) a frecuencias extremadamente altas (por ejemplo, a 8 kHz o a 11 kHz para audio digital de baja calidad). Esto significaba que el procesador debía interrumpir lo que estaba haciendo miles de veces por segundo solo para actualizar un bit del puerto. El segundo aspecto, se refería a los ciclos de reloj desperdiciados, ya que los procesadores de la época (como el Intel 8088 a 4,77 MHz del IBM PC original) no tenían potencia suficiente para procesar los gráficos de un juego y, al mismo tiempo, calcular los tiempos exactos de la onda de sonido. La CPU se veía obligada a entrar en bucles de espera (busy-waiting) midiendo los pulsos de máquina exactos para que el audio no se distorsionara, y los desarrolladores tenían que entrelazar el código del juego con el código de sonido de forma milimétrica, haciendo que cada instrucción de renderizado gráfico se calculara para que durara exactamente los ciclos de reloj idóneos entre pulso y pulso del altavoz.

Todo ello se traducía en congelaciones de juegos y ralentizaciones extremas la mayoría de las veces. Muchos usuarios descubrieron estas capacidades y sufrieron sus consecuencias gracias a juegos y demostraciones técnicas de la época en títulos como Castle Wolfenstein (versión de PC, en 1984), Space Quest III: The Pirates of Pestulon (1989), Pinball Dreams (1992), algunas conversiones de Prince of Persia (1989) o Street Fighter II para PC (1992). También diversas demos de la escena PC y numerosos programas shareware lograron reproducir voces sorprendentemente reconocibles utilizando únicamente el altavoz interno; escuchar una frase hablada salir de aquel pequeño transductor era casi magia para quien entendía las limitaciones del sistema. En España, el ejemplo más notable fue el de La abadía del crimen (1987), con su canto religioso del Ave María durante los rezos o aquel «Pirata, pirata…» enlatado cuando el juego detectaba que estabas ejecutando una copia ilegal o alterada.

Lo más fascinante es que el truco no explotaba una característica diseñada expresamente para ello, pues los ingenieros de IBM nunca imaginaron que aquel humilde altavoz destinado a emitir códigos de error terminaría reproduciendo frases digitalizadas, sino que fue una consecuencia inesperada de combinar física, electrónica y una alta cantidad de ingenio. Los desarrolladores observaron las limitaciones del hardware, comprendieron cómo vibraba realmente el altavoz y encontraron una manera de engañar tanto al dispositivo como al oído humano.

Hoy, cualquier teléfono móvil barato incorpora circuitería de audio millones de veces más sofisticada. Sin embargo, resulta difícil no sentir cierta admiración por aquellos programadores capaces de arrancar voces humanas a un componente diseñado básicamente para hacer «bip». Porque la historia del PC Speaker es, en el fondo, una de las historias más representativas de la informática clásica, aquella que dice que cuando el hardware era insuficiente, alguien siempre encontraba una forma ingeniosa de hacer lo imposible.

Hay una escena que el cine lleva décadas repitiendo mal: aparece un gran ordenador de los años cincuenta o sesenta, lleno de luces parpadeantes, y algún técnico con bata blanca pulsando interruptores de vez en cuando. La realidad era bastante más interesante, pues aquellos interruptores no estaban allí para decorar ni para impresionar a las visitas, y no se pulsaban cada media hora cuando el operario de turno hacía la ronda con una carpeta de pinza en la mano. En la mayoría de los casos eran literalmente «el teclado» de la máquina.

Las primeras computadoras electrónicas carecían de los sistemas de entrada que hoy damos por supuestos. No existían teclados ni ratones, no había interfaces gráficas ni terminales conectados permanentemente. Incluso antes de que una máquina pudiera leer una cinta de papel o una tarjeta perforada, había que cargar en memoria un pequeño programa inicial, y para introducir ese software se hacía necesario enviarlo bit a bit mediante los interruptores del panel frontal.

Imaginemos una máquina con un bus de 16 bits. En el frontal encontrábamos normalmente dieciséis palancas alineadas horizontalmente, cada una de ellas representando un bit. Interruptor hacia arriba significaba 1; interruptor hacia abajo significaba 0. Si el operador quería introducir el valor binario 0001001000110100, debía colocar exactamente cada interruptor en la posición correcta y, después, pulsar una tecla o palanca de carga para escribir ese valor en memoria. Luego cambiaba la combinación y repetía el proceso para la siguiente instrucción.

En máquinas como el IBM 1130, aquellos interruptores servían además para indicar direcciones de memoria concretas. El operador podía seleccionar una dirección, visualizar su contenido mediante los indicadores luminosos y modificarla manualmente. Era algo parecido a abrir hoy un editor hexadecimal, sólo que en lugar de una ventana tenías una consola metálica llena de bombillas.

El proceso de arranque, además, era especialmente delicado. Supongamos que el ordenador debía cargar el sistema desde una lectora de tarjetas perforadas, pero esa lectora todavía no podía utilizarse porque el equipo no sabía cómo comunicarse con ella. Por lo tanto, primero había que introducir mediante interruptores una rutina extremadamente pequeña, de apenas unas instrucciones en código máquina, que era capaz de leer unas pocas palabras desde la tarjeta. Lo leído contenía un cargador más potente que, a su vez, volcaba en memoria el resto del software. Era un proceso escalonado que los ingenieros llamaban bootstrap (arranque, en castellano), término del que deriva el actual boot de los sistemas operativos.

Un error de un solo bit podía arruinar la operación. Si el operador pretendía introducir una instrucción con valor hexadecimal 3A pero por descuido colocaba un interruptor incorrectamente y escribía 3B, el programa podía dejar de funcionar inmediatamente. No había mensajes explicativos ni depuradores sofisticados, y la solución habitual consistía en volver a revisar una por una las posiciones de los interruptores y compararlas con la documentación técnica.

Las luces del panel frontal eran igualmente importantes, pues no estaban pensadas para mostrar actividad de forma decorativa, como sucedería décadas después en muchos ordenadores domésticos. Habitualmente representaban el contenido de registros internos, direcciones de memoria o líneas de datos. Un operador experimentado podía observar el patrón de luces y deducir si el procesador estaba ejecutando instrucciones, atrapado en un bucle o esperando una entrada externa.

Algunos fabricantes llevaron la idea todavía más lejos. Los llamados sense switches permitían que los programas consultaran directamente el estado de determinados interruptores físicos durante la ejecución. En el IBM 701, por ejemplo, el software podía comprobar si un interruptor concreto estaba activado y tomar decisiones distintas en función de ello. En ciertos sistemas IBM, incluso el lenguaje FORTRAN incorporaba instrucciones específicas para leer estos interruptores y controlar luces del panel frontal. Esto daba lugar a situaciones que hoy resultan difíciles de imaginar, en las que, por ejemplo, un programa científico que llevaba horas ejecutándose podía modificar su comportamiento porque el operador había cambiado la posición de una pequeña palanca. También era posible activar modos de diagnóstico, solicitar información adicional o alterar estrategias de cálculo sin recompilar absolutamente nada, solo moviendo interruptores. En cierto modo, eran las opciones de configuración de una aplicación moderna, pero implementadas directamente en hardware.

Los paneles frontales también eran herramientas de mantenimiento. Cuando una máquina fallaba, los técnicos examinaban las luces para localizar el punto exacto del problema. Muchos manuales de servicio incluían tablas completas indicando qué combinación de indicadores correspondía a determinados errores. Hoy conectamos un depurador o revisamos un registro de eventos; entonces se observaba el comportamiento de las bombillas.

Lo más fascinante de todo es que aquellos operadores desarrollaban una comprensión extraordinariamente profunda de sus sistemas. No trabajaban sobre capas de abstracción, leían directamente los bits, las direcciones de memoria y los registros internos. Cuando un programa no funcionaba, podían seguir visualmente el recorrido de los datos por la máquina. La informática moderna nos ha dado herramientas infinitamente más cómodas, pero también nos ha alejado de esa relación casi física con el hardware.

Quizá por eso cuesta no sentir cierta admiración por aquellos pioneros. Mientras nosotros nos quejamos cuando un IDE tarda siete segundos en arrancar, ellos cargaban el programa inicial de un ordenador colocando docenas de interruptores en la posición correcta uno por uno. Y si se equivocaban en el último bit, tocaba empezar otra vez desde el principio. Eso sí que era programación de bajo nivel.

Durante décadas hemos convivido con un pequeño drama tecnológico que todos compartimos en silencio, el de intentar conectar un USB (de los del tipo A) a la primera. Esa operación cotidiana, en apariencia inocente, se convirtió en una especie de ritual universal compuesto por tres pasos invariables. Primero lo intentas poner; no entra. Le das la vuelta; tampoco entra. Vuelves a ponerlo como al principio y, entonces, ¡SÍ!. La humanidad ha aceptado este fenómeno como algo natural, como si la física se pusiera juguetona sólo cuando se trata de un puerto USB.

Pero detrás de esta tragicomedia electrónica no hay magia, ni mala suerte, ni un complot internacional para vernos sufrir. La explicación es mucho más simple y más humana: alguien tomó una mala decisión. La asimetría del USB tradicional no responde a una razón técnica superior, ni a un avance de ingeniería, ni a una propiedad exótica. Se debe a un error de cálculo, a un «esto no va a dar problemas, seguro» que resultó ser menos profético que las predicciones del tiempo del siglo pasado.

Para entenderlo hay que viajar mentalmente a mediados de los años noventa, una era en la que los ordenadores parecían naves industriales con patas. El hardware estaba plagado de conectores gigantescos, lentos y extravagantes, y había puertos paralelo, serie, PS/2, SCSI y un montón de cables que daban miedo sólo con verlos. En ese caos nació el concepto de USB como un conector pequeño y universal que prometía terminar para siempre con aquel zoológico de interfaces incompatibles. El proyecto estaba liderado por Ajay Bhatt, ingeniero de Intel, que se propuso crear un estándar barato, fácil de usar y prácticamente indestructible.

El diseño inicial funcionó. El USB era pequeño, económico y soportaba futuras evoluciones, pero lo que no era, en absoluto, es un conector reversible. En aquel momento, la prioridad no era la ergonomía del usuario, ni la estética, ni la experiencia de enchufar algo sin pensar. La obsesión era reducir costes. Y aquí está el detalle que marcó a toda una generación. Y es que hacer el USB reversible requería duplicar los contactos internos del conector, lo que habría incrementado el precio del componente prácticamente al doble. En una época donde cada centavo de dólar contaba y donde el objetivo era fabricar cientos de millones de unidades, la idea quedó descartada por innecesaria.

Lo irónico es que los ingenieros sí valoraron la opción de un diseño reversible. No fue una idea descartada por imposibilidad técnica, sino por economía y, sobre todo, por falta de visión a largo plazo. Se asumió que la gente no tendría problemas en conectar el USB con la orientación correcta, que nadie se confundiría, que sería fácil. Y ya sabemos cómo terminó eso. El coste del error no se midió en dólares, sino en frustración global repetida miles de veces al día a lo ancho del globo.

Años más tarde, Ajay Bhatt reconoció públicamente que habría sido mejor hacerlo reversible desde el principio; lo dijo sin rodeos. Pero también habría sido más caro, y en 1996 la industria no estaba dispuesta a pagar esa diferencia. La decisión estaba tomada, y el destino del USB quedaba sellado, pasando a la historia como uno de los conectores más útiles jamás creados y, al mismo tiempo, como uno de los más irritantes.

No sería hasta dos décadas después cuando alguien volvió a plantear seriamente la necesidad de un conector verdaderamente universal. De ese replanteamiento nació el USB‑C, un estándar que no sólo es reversible, sino que también sirve para carga de dispositivos, trasferencia de datos, transmisión vídeo, alimentación de monitores, transporte de audio y casi cualquier cosa que se pueda transferir por un cable sin ofender las leyes de la electrónica. El USB‑C es, básicamente, lo que el USB siempre quiso ser pero no pudo ser por culpa de un recorte presupuestario noventero.

Lo divertido de todo esto es que la tecnología actual nos demuestra que aquello que era «demasiado caro» hace veinte años hoy resulta indispensable. El USB‑C se ha convertido en el estándar moderno precisamente porque soluciona el mayor defecto del de tipo A: su incomprensible orgullo por tener una sola forma válida de entrar.

Al final, la moraleja es sencilla y un poco reconfortante. La próxima vez que falles en algo simple o estúpido —como dejar las llaves dentro del coche o enviar un correo importante al destinatario equivocado— recuerda que incluso ingenieros brillantes arrastraron al mundo entero durante décadas por una decisión aparentemente insignificante. El USB no es simétrico porque alguien se equivocó o no quiso aportar más dinero al proyecto. Y gracias a ello, ahora tenemos un conector moderno que parece mágico en comparación con aquel. A veces, de los errores también se alumbra progreso. Aunque tardemos veinte años en arreglarlo.

El VESA Local Bus, más conocido como VLB, fue uno de esos inventos que solo pudieron nacer en los turbulentos años noventa, cuando la industria del PC estaba creciendo a un ritmo demasiado rápido como para esperar a que Intel lo resolviera todo con elegancia.

A principios de aquella década, la transición del 386 al 486 había disparado la capacidad de cálculo del procesador, pero el resto del sistema, especialmente el venerable bus ISA, seguía arrastrándose con sus 16 bits a 8 MHz y un ancho de banda que hoy haría sonrojar a un reloj digital de los chinos. El resultado era un cuello de botella monumental, sobre todo en un área que empezaba a adquirir importancia crítica: el vídeo. Los modos SVGA, las resoluciones superiores a 640×480 y el incremento del consumo gráfico exigían un canal más rápido entre el procesador y las tarjetas de expansión. El ISA no daba más de sí, y el EISA, aunque mejorado, era caro y orientado a servidores. La industria doméstica necesitaba una solución inmediata, barata y lo suficientemente potente para aguantar hasta que apareciera un estándar más serio.

Ahí entró en juego la Video Electronics Standards Association (VESA), una agrupación de fabricantes preocupados por la interoperabilidad de los estándares gráficos. En 1992 propusieron una solución atrevida y claramente transitoria: un bus que literalmente colgase del bus local del procesador 486, aprovechando sus líneas de datos de 32 bits y su frecuencia de reloj, normalmente entre 25 y 50 MHz. El resultado fue el VLB, un bus con un rendimiento teórico de más de 100 MB/s, lo cual rondaba entre diez y quince veces la capacidad del humilde ISA. La idea era tan simple como peligrosa, pues si el problema se concentraba en que el bus ISA era lento, ¿por qué no permitíamos a la tarjeta gráfica acceder directamente al bus del procesador? Era como dejar a un mecánico enchufar un turbo al motor sin avisar al fabricante del coche. Pero la necesidad era urgente, y el truco funcionó.

Físicamente, el VLB consistía en un conector adicional situado a continuación de la ranura ISA estándar. Por eso las tarjetas VLB eran tan largas, porque una parte ocupaba la ranura ISA tradicional y otra encajaba en la extensión VLB, como si hubieran injertado dos tarjetas en una. Esa longitud extrema no era un capricho, sino consecuencia del número de señales adicionales que el bus necesitaba para sincronizarse con el microprocesador. Y aquí empezaban los problemas, pues al depender directamente del reloj del CPU, cualquier variación en la placa base, cualquier imprecisión en las pistas o cualquier exceso de longitud podía provocar inestabilidad.

Las placas base tenían que diseñarse como si fueran instrumentos de precisión, porque las señales de VLB no toleraban retardos significativos. Los fabricantes solían anunciar compatibilidad con 40 MHz, pero muchos equipos se desplomaban al intentar usar el bus por encima de 33 MHz. Además, aunque el estándar permitía hasta tres ranuras VLB por placa madre, pocas se atrevían a implementar más de una y, cuando incluían dos, hacerlo funcionar todo a la vez y sin errores era casi un acto de magia.

El propósito principal del VLB fue acelerar las tarjetas gráficas. En 1992 y 1993, cuando los chips de Cirrus Logic, S3, Tseng Labs o Trident dominaban el mercado SVGA, disponer de un bus rápido podía marcar una diferencia sustancial en operaciones de transferencia de vídeo, escritura en framebuffer y uso de aceleración 2D primitiva.

Pero las gráficas no fueron las únicas beneficiadas. Muy pronto comenzaron a aparecer controladoras IDE y SCSI con interfaz VLB, aprovechando el mayor ancho de banda para transferencias de disco. También surgieron tarjetas de red y adaptadores multi-I/O que, sobre el papel, prometían un rendimiento superior al de sus equivalentes ISA. La realidad era más ambivalente, ya que no todas estas tarjetas lograban beneficios tangibles, pero cuando lo hacían, el salto era apreciable. Para un PC doméstico de mediados de los noventa que dependía del 486, el VLB era, sin exagerar, la única vía práctica para obtener un rendimiento gráfico competitivo.

El motivo de su caída fue, precisamente, su propia naturaleza improvisada. El VLB estaba diseñado alrededor del 486 y no tenía futuro más allá de él. Pentium introdujo cambios sustanciales en el bus del procesador y exigía una arquitectura completamente distinta para la comunicación con dispositivos de expansión. Intel llevaba años desarrollando un estándar más sofisticado, independiente del reloj del procesador, más estable, más escalable y más apto para un ecosistema en expansión: el bus PCI, que comenzó a imponerse hacia 1994 y se convirtió en el estándar dominante apenas un año después. Frente al PCI, el VLB parecía lo que realmente era: un puente improvisado. No soportaba bien mayores frecuencias, no era compatible con arquitecturas posteriores, carecía de mecanismos avanzados de arbitraje y su dependencia directa del procesador imponía restricciones insostenibles. Cuando las placas base para Pentium empezaron a llegar en masa, prácticamente todas eliminaron el VLB y adoptaron PCI de forma contundente.

Podría parecer que el VLB fue un fracaso, pero sería injusto. Cumplió exactamente la función para la que fue creado: ofrecer una interfaz de alta velocidad en los meses en los que no existía otra alternativa viable. Permitió que los 486 exprimieran todo su rendimiento gráfico justo cuando más se necesitaba, mantuvo viva la competitividad de los PC compatibles frente a estaciones propietarias y, de paso, evitó que el ISA siguiera lastrando al mercado un par de años más. Fue un invento efímero pero crucial, una pieza de ingeniería pragmática que resolvió un problema urgente a pesar de ser frágil, caprichosa y tremendamente sensible a las particularidades del hardware.

Hoy, ver una tarjeta VLB es casi un ritual arqueológico: largas, pesadas, con el conector doble característico; recuerdan una época en la que la informática de consumo avanzaba tan deprisa que los estándares nacían con fecha de caducidad incorporada. El VLB no sobrevivió a su tiempo, pero dejó una huella decisiva en la transición tecnológica de los primeros noventa. Fue un puente, sí, pero un puente que sostuvo todo el peso del mercado mientras la industria corría a construir algo mejor.

Hubo un tiempo en que los ordenadores eran mudos, silenciosos, como si estuvieran enfadados con el mundo o no tuvieran nada interesante que decir. A lo sumo, un triste bip monofónico salía del altavoz interno al encenderlos, como un bostezo electrónico. Y gracias, porque para muchos juegos de la época ese altavoz de la placa era el único intérprete disponible: chasquidos metálicos, pitidos que simulaban disparos y melodías reducidas al rango más pobre.

En aquella era prehistórica del audio digital, algunos pioneros se atrevieron a meter tarjetas de sonido en los PC. Una de las primeras fue la AdLib, canadiense ella, que usaba un chip Yamaha OPL2 para ofrecer síntesis FM. Sintetizar música, sí, pero con matices. Aquella tarjeta fue como pasar del ruido de una impresora matricial a una cinta de casete de los 40 Principales. Pero la AdLib, por rompedora que fuera, tenía una limitación importante: sólo podía generar sonidos, no reproducir muestras digitales. No podías escuchar una voz grabada, ni un disparo realista, ni el grito de un personaje pixelado, por ejemplo. Y entonces llegó Creative Labs, desde Singapur, y lo cambió todo.

La primera Sound Blaster apareció en 1989 y era, literalmente, una AdLib vitaminada. Compatible 100 % con los estándares de moda, pero además con capacidad para reproducir audio digitalizado, algo que en aquel momento sonaba (nunca mejor dicho) a ciencia ficción. Y como guinda, incluía un puerto de joystick integrado, lo que hacía que los adolescentes ya no tuvieran excusa para no jugar a Wing Commander como se debía.

Aquel movimiento fue brillante: Creative no sólo sacó una tarjeta mejor, sino que la hizo compatible con lo que ya existía, facilitando su adopción por desarrolladores y usuarios. En muy poco tiempo, Sound Blaster se convirtió en el estándar de facto del sonido para PC. Si un juego era serio, tenía que soportarla. Y si no la tenías, te sentías medio cojo.

Los años noventa fueron el reinado absoluto de la familia Sound Blaster. La Pro, la 16, la AWE32, la AWE64…, cada una mejoraba a la anterior con más canales, más calidad, más memoria para soundfonts, en general, más cacharrería para que los juegos sonaran a gloria. Aquellos que recuerden el salto de un Commander Keen en speaker a un Doom con música MIDI y efectos PCM sabrán de lo que hablamos. Era como pasar de una maqueta a una película de verdad.

Eso sí, instalar una de estas tarjetas no era tarea para cobardes. Había que lidiar con puertos I/O, canales DMA, las IRQ que se peleaban con la controladora IDE o con el módem de 14,4 kbps. Te pasabas más tiempo configurando el autoexec.bat y el config.sys que jugando. Pero cuando lo conseguías… Escuchar la voz digitalizada de Guybrush Threepwood en Monkey Island o el rugido de una ametralladora en Duke Nukem 3D valía cada minuto perdido.

El impacto fue tal que, hasta en la demoscene, la Sound Blaster se convirtió en pieza clave. Los ficheros MOD, la música tracker, las demos de 64K que metían tecno ochentero con sincronización visual…, todo se apoyaba en esa tarjeta, en esa capacidad de reproducir samples a distintos tonos, en ese chip que parecía sacado de una radio pirata del futuro.

Pero todo reinado llega a su fin. Con la llegada de Windows 95 y DirectSound, muchas cosas cambiaron. El sistema operativo empezó a abstraer el hardware, los fabricantes de placas base comenzaron a integrar audio suficientemente bueno y la necesidad de comprarse una tarjeta dedicada fue desvaneciéndose. Creative resistió durante años con las gamas Audigy y X-Fi, incluso flirteando con los jugadores hardcore con latencias bajas y efectos envolventes, pero el mercado ya no era el mismo.

Hoy en día, las Sound Blaster viven en el recuerdo, en los foros de retrohardware, en los emuladores como DOSBox y en los corazoncitos de quienes alguna vez escuchamos por primera vez una voz digitalizada en un PC y dijimos «¡esto habla!». Algunos entusiastas aún las usan para revivir máquinas antiguas y jugar como en los viejos tiempos, con drivers que hay que buscar en disquetes, en páginas abandonware, o en archivos ZIP con nombres como sb16drv.zip.

La Sound Blaster no fue sólo una tarjeta de sonido, fue la primera vez que un PC tuvo alma, que dejó de ser un robot mudo y se convirtió en una máquina capaz de emocionar. Nos enseñó que los bits también pueden cantar. Y eso, para quienes lo vivimos, es un algo que ya no se olvida.