Stuxnet fue un virus informático que se descubrió en 2010 por la firma de ciberseguridad bielorrusa VirusBlokAda, pero que se sospecha que estuvo activo desde al menos 2005. Su objetivo fue sabotear las centrifugadoras Zippe de Irán para el enriquecimiento de uranio. Aunque existen fuertes indicios de que se trató de un ataque clandestino conjunto de Estados Unidos e Israel, ninguno de estos países ha admitido responsabilidades, y las evidencias sólidas parecen provenir siempre de entidades enemigas. (Un caso de «no tengo pruebas pero tampoco dudas»)

El virus parece atacar específicamente sistemas SCADA (sistemas de supervisión, control y adquisición de datos) diseñados por Siemens, concretamente el modelo PSC7 con sistemas de control WinCC. Se trata de unos sistemas empotrados basados en Windows que controlaban las centrifugadoras usadas en las instalaciones de Natanz, que estaban fuertemente armadas y plagadas de armamento antiaéreo.

Lógicamente, unas instalaciones secretas estratégicas para Irán no venían en la guía telefónica ni tenían un centro de visitantes. De hecho, estaban fuertemente custodiadas a una profundidad de 40 metros bajo tierra, protegidas por más de 7 metros de hormigón¹. Naturalmente, como en toda instalación crítica, existe una política llamada air-gap (hueco de aire), es decir, una desconexión total de cualquier red de información del exterior. ¿Cómo se ataca una instalación así?

El ataque

La información que se tiene de una potencia enemiga suele venir principalmente de fotos de satélite, de modo que, al tratarse de unas instalaciones subterráneas secretas, poco se puede conocer de los detalles de sus sistemas informáticos. Irán está bajo un embargo estadounidense de armamento y tecnología desde la revolución islámica en 1979, de modo que la única forma de adquirir estos sistemas es el contrabando. Identificados por inteligencia los sistemas objetivos, Stuxnet fue programado para este fin.

¿Pero cómo introducir un virus en un sistema físicamente desconectado? Al parecer la idea más plausible fue alguien conectase un pendrive USB. Pero uno no simplemente entra caminando en Natanz. Según Mark Clayton², el vector con más posibilidades fue la entrada y salida de contratistas rusos. También indica que pudo ser Rusia quien introdujo los sistemas de control de Siemens. Kim Zetter y Huib Modderkolk de Yahoo! News³ informaron en 2019 que el agente pudo ser un topo holandés a instancias más que probables de la inteligencia americana e israelí. Daan Goodin de Ars Technica⁴⁵en 2012 declaró que el autor habría sido un agente doble iraní.

¿Quién o quiénes?

La práctica totalidad de informes apuntan a que los autores de los ataques fueron las fuerzas de inteligencias norteamericanas e israelíes. David E. Sanger del New York Times⁶ escribió en 2012 un artículo que revelaba que el presidente Obama ordenó acelerar la iniciativa de ciber-armas iniciada por la administración de George Bush, a instancias del General James Cartwright, llamada furtivamente «Operación Juegos Olímpicos.»

En 2013 se publicó en Wbur de Boston⁷ que un exvicepresidente del Estado Mayor Conjunto (el propio Cartwright) estuvo bajo investigación por presuntamente filtrar información secreta sobre los ciberataques en el marco de la operación Juegos Olímpicos bajo la administración Obama. Fue acusado de comportamiento indebido con una asistente en 2011, pero fue finalmente exonerado. Más tarde en 2016, en otro juicio⁸, se declaró culpable de mentir al FBI en relación con las filtraciones, aunque nunca se le llegó a acusar de ser el autor de las mismas. Fue condenado, aunque recibió el perdón presidencial de Barack Obama y se le restituyó en 2017.

Por su parte, Israel fue señalado en 2012 como coautor de los ataques por el New York Times en otro artículo de Sanger⁹.  En un paper de Security and Defense¹⁰ se concluyó que «La Operación Juegos Olímpicos fue una acción cuidadosamente planificada y sofisticada de las agencias de inteligencia de Estados Unidos e Israel en el ciberespacio», y que «[e]sto fue posible gracias a la combinación de capacidades e inteligencia de Estados Unidos e Israel».

Esta fuerza conjunta, denominada Equation Group, fue la que supuestamente planeó y ejecutó el ataque, según Forbes¹¹. El grupo Kaspersky cifra que los posibles ataques podrían ascender a unos 400¹², que tras catorce años fue identificado por agentes chinos¹³. De hecho, un grupo de hackers denominado Shadow Brookers  expuso en 2016 algunas de las ciberarmas utilizadas por Equation, información que tristemente fue utilizada en el ciberataque a nivel mundial Wannacry, el destructivo ransomware que se llevó por delante al Servicio de Salud Británico, entre otros. The Telegraph en 2011 informó¹⁴ que, en un vídeo mostrado en la jubilación del general Gabi Ashkenazi se hicieron referencias a sus éxitos operativos, haciendo mención a Stuxnet. En 2012 fue Wikileaks quien dio los indicios más sólidos de la autoría del virus¹⁵, publicando emails de la contratista STRATFOR, discutiendo sobre la publicación de información en el Times.

Sobre el virus

La primera vez que fue detectado por VirusBlokAda, en Junio de 2010, fue llamado Rootkit.Tmphider. Symantec, no obstante, lo llamó inicialmente W32.Temphid, cambiándolo a W32.Stuxnet más tarde¹⁶. Esto vino de la contracción de la palabra stub (esbozo), encontrada en el código del virus, y mrxnet.sys, uno de los ficheros que creaba¹⁷. El virus, si no desata su payload (carga útil o mecanismo dañino), tiene un comportamiento poco dañino: funciona como un gusano que se transmite al menos tres veces y luego se autoelimina¹⁸. Esto permite una propagación sin que se su reacción en cadena se descontrole. Su efecto dañino requiere que se detecten ciertas condiciones muy específicas, a saber: uno o más PLC S7 de Siemens funcionando en WinCC.

Es entonces cuando entran varias variables en juego: la primera es un exploit 0day de Windows (es decir, un modo de hackeo no divulgado) que permitía infectar una máquina con sólo abrir una unidad USB. Esto desencadenaba un proceso a nivel de rootkit (un proceso que se ejecuta por encima de todos los demás), otro exploit en la base de datos del software de control y al menos tres capas importantes: Una en el propio Windows, otra que infectaría a WinCC y otra para los propios PLC. Esta complejidad es muy inusual para un virus, que suelen ser diseñados de forma de infección generalista y no tan específica. Además, es igualmente inusual la cantidad de vulnerabilidades no divulgadas que explotaban, que son un recurso altamente codiciado por los hackers que programan software pernicioso¹⁹. Todo ello además, firmado con claves robadas a dos firmas de hardware en Taiwán²⁰.

El virus detectaba dichas centrifugadoras por la velocidad angular de las mismas, una velocidad inusualmente alta para el resto de procesos industriales. Cuando su víctima ha sido detectada emplea una técnica llamada man-in-the-middle, es decir, se coloca entre las señales de control y el software, y mientras engaña al software de control para asegurarle que todo va bien, emite órdenes alteradas al dispositivo. En este caso, las centrifugadoras de Natanz, a las que hacía girar más rápido de lo normal²¹ y luego más lento, durante un breve lapso. Las vibraciones resultantes no serían percibidas, pero acabarían dañando la maquinaria.

Repercusiones

El Washington Post informó²² que, a través de las cámaras de la Agencia Internacional para la Energía Nuclear, se evidenciaron que al menos 1000 centrifugadoras fueron reemplazadas en la época en que Stuxnet estuvo activo, aunque asímismo informa que el reemplazo fue rápido y que el proceso de enriquecimiento de uranio no se vio sustancialmente alterado. El periódico israelí Haaretz informó, no obstante, que un 30% de la actividad se habría visto afectada, y que se tuvieron que hacer paradas debido a que el virus hubiera dejado inoperativas demasiadas centrifugadoras.²³.

Sea como fuere, WikiLeaks informó²⁴ que la Organización para la Energía Nuclear en Irán habría obligado a renunciar a su jefe, Gholam Reza Aghazadeh, por «serios incidentes nucleares».  The Economist, en septiembre de 2010, relacionó²⁵ rápidamente el ciberataque con el virus Stuxnet.

Fue en 2010 también cuando el presidente de la República de Irán, Mahmoud Ahmadinejad, admitió que el país había sido víctima de ciberataques por parte de las potencias occidentales²⁶. Ese mismo día, dos científicos nucleares fueron emboscados y trágicamente asesinados, siendo gravemente herido un tercero²⁷. El presidente señaló que habrían sido asesinados por el «régimen sionista», y por su parte el Washington Post especularía²⁸con que pudieron haber sido asesinados por su propio país.

Palabras finales

He tratado ser tan neutral como me ha sido posible en este artículo, e incluido tantas fuentes como me he podido. Cabe aún hacerse preguntas: ¿Fue Natanz el objetivo real del virus o fue el terreno de prueba para objetivos más valiosos? ¿Existen ataques de guerra electrónica clandestinos en la actualidad de los que no tenemos noticia? En todo caso, parece que este es sólo el principio²⁹.

Referencias

La entrada La increíble historia del virus Stuxnet se publicó primero en Detrás del último no va nadie.

El código puede verse en: https://gist.github.com/axelei/dafd305213ed1b2655545f06edfbc905

# Programa para clonar prestashop
# Copyright Krusher 2015 - Licenciado bajo GPL3

paramfile="httpdocs/app/config/parameters.php"
extractDatabaseName="s/.*'database_name' => '\(.*\)'.*/\1/p"
extractDatabaseUser="s/.*'database_user' => '\(.*\)'.*/\1/p"
extractDatabasePassword="s/.*'database_password' => '\(.*\)'.*/\1/p"

if [ "$#" -lt 4 ]; then
  echo "Error: Se requieren 3 argumentos."
  echo "Uso: $0 dir_web_original dir_web_destino url_original url_destino"
  exit 1
fi

echo Traspasando de $1 a $2 \(urls: $3 -- $4 \)

databaseName=$(sed -n "$extractDatabaseName" $1/app/config/parameters.php)
databaseUser=$(sed -n "$extractDatabaseUser" $1/app/config/parameters.php)
databasePassword=$(sed -n "$extractDatabasePassword" $1/app/config/parameters.php)

echo Datos de la base de datos de origen: $databaseName / $databaseUser / $databasePassword

targetName=$(sed -n "$extractDatabaseName" $2/app/config/parameters.php)
targetUser=$(sed -n "$extractDatabaseUser" $2/app/config/parameters.php)
targetPassword=$(sed -n "$extractDatabasePassword" $2/app/config/parameters.php)

echo Datos de la base de datos de destino: $targetName / $targetUser / $targetPassword

if [[ -z "$databaseName" ]] || [[ -z "$databaseUser" ]] || [[ -z "$databasePassword" ]] || [[ -z "$targetName" ]] || [[ -z "$targetUser" ]] || [[ -z "$targetPassword" ]]; then
  echo "Error: Algunas de las variables no han sido extraídas, comprueba los errores y los directorios."
  exit 1
fi

echo URL de la instancia origen: $3
echo URL de la instancia destino: $4

read -p "Pulsa enter para continuar o CTRL+C para cancelar"
echo  "Procediendo con el traspaso."

echo Extrayendo base de datos
rm -f temp.sql
mysqldump -u $databaseUser $databaseName -p$databasePassword > temp.sql
echo Borrando base de datos objetivo
mysql -u $targetUser $targetName -p$targetPassword -e "drop database $targetName; create database $targetName"
echo Insertando la base de datos origen en la objetivo
mysql -u $targetUser -D $targetName -p$targetPassword < temp.sql
rm -f temp.sql

echo borra ficheros contenido antiguo
rm -Rf $2/*
echo copia ficheros
cp -r $1/* $2/

echo Configurando base de datos objetivo con los datos originales

sed -i "s/'database_name' => '\(.*\)'/'database_name' => '$targetName'/g" $2/app/config/parameters.php
sed -i "s/'database_user' => '\(.*\)'/'database_user' => '$targetUser'/g" $2/app/config/parameters.php
sed -i "s/'database_password' => '\(.*\)'/'database_password' => '$targetPassword'/g" $2/app/config/parameters.php

echo Configurando la nueva URL en la instancia destino

mysql -u $targetUser $targetName -p$targetPassword -e "update prstshp_configuration set value = '$4' where NAME IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL')"
mysql -u $targetUser $targetName -p$targetPassword -e "UPDATE prstshp_shop_url SET domain = '$4', domain_ssl = '$4' WHERE id_shop_url = 1;"
sed -i s/\\^$3\\$/^$4$/g $2/.htaccess

echo Terminado.

Podría estar mejor hecho, en un lenguaje mejor o usar herramientas más avanzadas, pero es cómo me las tuve que apañar en un entorno que le faltaban muchas herramientas y comandos. Si te ha sido útil deja un comentario con tu experiencia.

La entrada De cómo clonar una instancia de Prestashop se publicó primero en Detrás del último no va nadie.

También es verdad que un éxito comercial puede llevar a grandes avances arrastrando al resto, o simplemente tener el mérito de llevarlas a las masas. Veamos.

ENIAC

Empezamos por el principio, casi literalmente. Completada en 1945, el Electronic Numerical Integrator and Computer, como se llamaba formalmente, se cita a menudo como el primer computador electrónico, digital, programable y de propósito general de la historia. ¹ Aunque quizá la característica más interesante es que se trataba de un ordenador Turing Completo, es decir, que puede comportarse como una máquina teórica de Turing. Aunque se trata de un concepto bastante abstracto, no deja de ser un «certificado» de que la máquina podía realizar cualquier cálculo si tenía los recursos adecuados.

Algunos autores han colocado a la máquina Colossus como la primera con estas características, construídas desde 1943 hasta 1945. Sin embargo no eran verdaderas máquinas de propósito general, dado que su cometido estaba orientado a descifrar máquinas de cifrado Lorenz, parecidas a las célebres Enigma. Otro hecho que no ayude es que este ordenador fue un secreto de estado hasta la década de los 60.

Hay que decir que, aunque cataloguemos a ENIAC como programable, no lo era al uso. El autor David Alan Grier (editor en Jefe de IEEE) la describe como una colección de sumadoras y otras unidades aritméticas controladas por una maraña de cables. ² Con todo, esta máquina de casi siete millones de dólares de 2024 (casi medio millón en 1946) era miles de veces más rápida que sus antecesoras hechas con dispositivos electromecánicos, estuvo al servicio del ejército norteamericano hasta 1955, principalmente calculando tablas balísticas de artillería.

Apollo Guidance Computer

Lo más destacado de este ordenador, entre otros tantos que llevaba la misión Apollo, era que nos llevó a la Luna, evidentemente. Pero también supuso un reto técnico muy importante: el miniaturizar un ordenador lo suficiente como para poder llevarse en la misión. Recordemos que los dispositivos de los años 40 y 50 eran tan grandes que llenaban una sala de armarios, y consumían grandes cantidades de electricidad.

No en vano, se trata de uno de los primeros ordenadores en usar circuitos integrados, un hito que disputa junto al IBM 360 ³ y el SDS 92 ⁴. Otro de los motivos de la reducción de tamaño de esta computadora fue su memoria de núcleos cableados, que fueron tejidos a mano, en un tedioso trabajo que costó ocho semanas. Contaba con 2.048 palabras de RAM y 36.864 de ROM. ⁵

Manchester Ferranti

El UNIVAC se suele referenciar como el primer ordenador comercial, pero fue esta Manchester Ferranti, también conocida como Mark I, la que se adelantó por un mes, en febrero de 1951. Hubo dos máquinas anteriores, BINAC y Z4, que pudieron considerarse anteriores, pero BINAC era electromecánica y no era de propósito general y la Z4 nunca funcionó bien tras ser instalada. ⁶

Esta Ferranti fue también el primer ordenador del mundo con sonido, puesto que incluía una instrucción para alertar al operador, variable en tiempo y frecuencia. En 1951, la BBC incluso grabó varias melodías reproducidas por este ordenador. ⁷ Otro logro muy interesante fue el de ser uno de los primeros computadores en tener un juego de ajedrez, aunque muy limitado. También se le programó un juego de damas en 1952. Comparte este singular logro con máquinas como la NIMROD, de aproximadamente un año antes. No obstante esta máquina sólo servía para jugar al nim.

PDP

Las máquinas PDP, de Digital Equipment Corporation, fueron pioneras en muchos sentidos. El primer modelo, el PDP-1 fue lanzado en 1959, y fue uno de los iconos de la cultura hacker más importantes. Fue también el hardware utilizado para uno de los grandes hitos de los videojuegos, el Spacewar!, en 1962. Fue la primera vez que un videojuego se ejecutaba en un minicomputador.

Desde luego eso de minicomputador suena a chiste, dado que se trata de aparatos que ocupaban varios armarios. No obstante su denominación no viene por su tamaño, sino por mínimo. También por ser más pequeños y baratos que los mainframes, no compitiendo con los grandes como IBM. Surgieron tras la revolución de los transistores y de las memorias de núcleos magnéticos, y el honor de ser el primero de su clase está discutido entre otros minis como el LINC, de la misma casa, o los TX, del Laboratorio Lincoln.

El modelo PDP-8 fue lanzado en 1965, fue el primer ordenador en costar menos de 20.000 dólares, tenía el tamaño de un frigorífico y vendió alrededor de las 50.000 unidades, una barbaridad para aquél entonces. Entre tantos sistemas operativos, se desarrolló el 8OS, que se cita como el pionero en usar la línea de comandos como entrada. Fue el que inspiró al sistema operativo CP/M en los ’70, que recordemos que fue la inspiración directa de MS-DOS y similares, que dieron el pelotazo en la arquitectura IBM PC. ⁸

Hablar de los PDP es hablar de UNIX, dado que este sistema operativo fue diseñado en principio para el PDP-7 por Ken Thompson y Dennis Ritchie en 1969. No contentos con eso, tras escribirlo en lenguaje ensamblador, Dennis Ritchie inventaría el omnipresente lenguaje C, un par de años más tarde. Prácticamente todos los ordenadores modernos derivan de las tecnologías desarrolladas para estos minis, ya sea UNIX, C o la línea de comandos, entre otras tantas.

Otro gran paso adelante se dió con el PDP-11, que fue el primero en construirse en UniBus, en 1969. Esto permitió que todos los dispositivos del ordenador pudieran comunicarse entre sí, incluyendo la memoria, por lo que fueron posible los accesos directos a memoria (DMA), usando el procesador central para otras cosas durante las operaciones. También facilitó el intercambio de datos y el desarrollo de controladores de dispositivos.

Xerox Alto

Los hitos de este ordenador de Xerox PARC, de 1973, no fueron pocos. Aunque no fue el primer ordenador personal de la historia, dado que este honor se concede al Kenbak-1, se parece mucho más a los ordenadores modernos que cualquier otro artilugio creado en esta época. Desde luego, si tenemos que buscar un antecesor directo de la filosofía de lenguaje que rige los ordenadores personales de hoy día, los hallamos en este ordenador.

Sus innovaciones no fueron pequeñas: fue el primer ordenador con interfaz gráfica, el primero en tener un ratón, el primero que usó la filosofía WYSIWYG⁹, la capacidad de ejecutar varias aplicaciones al mismo tiempo, y el primero que usó la metáfora del escritorio. También fue el primer ordenador con ethernet. Para quitarse el sombrero.

La famosa visita de Steve Jobs a Xerox PARC en 1979 encendió la chispa de los ordenadores personales de interfaz gráfica. El Apple Lisa, por parte de Apple Computers y el sistema operativo Windows, de Microsoft, fueron el fruto de esta «inspiración». No se hicieron a la primera, pero sí que acabó siendo la interfaz principal de la informática moderna de usuario.

Costó 32.000 dólares y no fue un éxito comercial, por tanto no es tan conocido como otros ordenadores de Apple o IBM, sin embargo es probablemente la mayor influencia en los ordenadores personales de hoy día. Tampoco ayuda que su tamaño fuera de un archivador pequeño.

Altair 8800

A veces ser el primero no lo es todo. Si bien el Kenbak-1 fue primero, y el Xerox Alto la referencia, fue el Altair 8800 de MITS el que inició la era de la computación casera en 1977, con la revolución del procesador Intel 8080. Este fue el primer microprocesador que se cita como de utilidad comercial real para computadores de propósito general, más allá de aplicaciones empotradas como calculadoras.  Recordemos que este procesador fue la «inspiración» de otros como el Z80 de Zilog.

Gran parte de su éxito se debe a que fue portada de la revista Popular Electronics en enero del 75, y que se vendiera como kit para montar. También gracias a que el primer lenguaje de programación disponible fue el Altair BASIC, desarrollado por unos fulanos conocidos como Bill Gates y Paul Allen, que tras este hecho fundaran una empresucha conocida como Microsoft. Este ordenador fue el primer estándar de facto en ordenadores personales, con su bus conocido posteriormente como S-100. Dado que una placa madre única hubiera sido demasiado grande, se optó por un diseño tipo backplane, en el que se insertaban tarjetas de forma paralela en el bus, un diseño que terminó siendo un estándar IEEE.

Un clon de este ordenador, el IMSAI 8080, incluyó un teclado y un monitor, que eran opcionales en el Altair. Fue el ordenador que usó el protagonista de Juegos de Guerra (John Badham, 1983).

Otros

El lector no me perdonará de no mencionar los siguientes aparatos.

• IBM 5150 – No fue el primer ordenador personal, pero sí el primer IBM PC de la historia, en 1981. La gran mayoría de los ordenadores personales usan aún esta vetusta arquitectura. No está mal, ¿no?
• IBM S/360 – El verdadero mainframe comercial, de 1964. Su arquitectura aún da coletazos en la actual serie Z de IBM, y fue de los primeros ordenadores en usar circuitos integrados. Un grán éxito de mercado. También fue de las primeras máquinas en ser emuladas, en los mainframes posteriores de la marca.
• TRS-80, Apple II, Commodore PET – La tríada del 77. Estos tres ordenadores fueron responsables de la popularización de la informática, al menos en Estados Unidos, donde la economía lo permitía. Se introdujeron en las escuelas, comenzaban los ordenadores para casa y la verdadera competencia en la informática personal.
• Commodore 64 – Aunque se trata de un título en disputa, desde 1982 se trata del modelo de ordenador más vendido de todos los tiempos. Ninguno de sus sucesores tuvo el arrollador éxito del C64, ni siquiera la línea Amiga, con sus destacadísimas capacidades multimedia.
• NeXtCube – El proyecto paralelo a Apple de Steve Jobs, lanzado en 1988. En él se inventó la WWW, y también el estándar PostScript. Cuajado de características y con un precio bastante alto, que hoy día lo hacen una pieza cotizadísima. Su sistema operativo fue la base del moderno Mac OS. (Entonces OS X)
• IBM 5100 – Considerado el antecesor del IBM PC, en 1975. Personal, portable y era considerado un mainframe de bolsillo por sus capacidades de emulación. Además es buscado por viajeros en el tiempo.
• Cray I – El concepto original de supercomputador, de 1976. Su unidad de procesamiento vectorial le valió muchos plácemes por parte de la industria, y fue uno de los primeros ordenadores con un diseño muy atractivo. A un precio de 5 a 8 millones de dólares no era para cualquiera.

Palabras finales

¿Qué os parece la lista? He intentado que sea cortita y que primen más valores como la innovación que el mero éxito comercial, pero al final el primero en venderse es el que se lleva (o se suele llevar) el mérito. Por último, agradecer a mis amigos expertos en informática el ayudarme con el artículo:

• El enchufe sátiro
• La memoria morsegona
• Don RAM y don ROM
• La válvula loca
• El circuito vietnamita
• Y por supuesto, don Ya Se Ha Colado Otro Bug En Producción.

¿Echas de menos algún ordenador o un dato interesante? Déjamelo en los comentarios.

Referencias

La entrada Los ordenadores más importantes de la historia se publicó primero en Detrás del último no va nadie.

No obstante y como mero entretenimiento, voy a tratar de discurrir sobre cómo sería hacer café en diversos lenguajes de programación, inspiración que me ha venido de mi locuelo compinche de fechorías retroinformáticas Ilgrim. También del famosísimo comic de Toggl, por supuesto.

Basic

No será rápido, pero será fácil. Eso sí, no podrás personalizar demasiado el café ni ver los entresijos de la maquinaria, dado que será un café para principiantes. Perfectamente válido para consumo ocasional, aunque seguramente quieras pasarte a un café mejor en cuanto hayas aprendido lo fundamental.

PASCAL

Muy parecido al café Basic, aunque los botones en la cafetera tienen símbolos parecidos aunque distintos, o pueden no estar exactamente en el mismo sitio.

COBOL

El café en COBOL es negro y sin azúcar. Ha sido así desde que el Hombre tiene memoria y lo será hasta el final de los tiempos. Esta tradición es tan sagrada que nadie se atrevería a cuestionarla, y aunque este café está más desactualizado que llevar el jersey por los hombros y tenga pocos adeptos, siempre existirá el café COBOL.

Java

A menudo se critica a este café por ser lento, pero afortunadamente ha mejorado con el paso de los años. Más recientemente, se ha descrito la incomodidad de pedirlo con cuidado, ya que si alguno de los ingredientes no está disponible, el camarero te interrumpirá con un guantazo. Por ello, a veces los clientes hablan en Kotlin, un idioma para pedir café Java que evita esta burocracia.

Dado que es mi especialidad de café, puedo explayarme mejor. De hecho hay tres formas fundamentales de hacerlo.

La primera es, por supuesto, usar la cafetera que ya trae Java, importándola de java.coffee. No es mal café, pero puede que no sea justo el que necesitas o que no sea posible ponerle sacarina.

Por supuesto, puedes hacer tu propia cafetera usando los componentes de java.coffee. Pero mejor heredar la cafetera anterior y ponerle un asa más chula o añadir un botón para ponerle sacarina, dado que hacer café no es algo fácil y lo necesitamos para ayer.

La tercera, la más fácil, es simplemente diciéndole al gestor de paquetes que compre una cafetera nueva en Maven o en Gradle. Hay multitud de modelos para elegir con montones de versiones y algunas hacen un café de primera, aunque puede resultar un proceso lento dependiendo de tu casa. Parece increíble, pero la mayoría son gratuitas y traen los planos de cómo se hicieron, aunque a veces los añadidos pueden costar un extra. El uso de estas cafeteras puede variar, y es mejor asegurarse de que la toma de enchufe sea la misma que la que tienes.

A pesar de todo lo anterior, por desgracia, cuando llegue el momento de hacer el café, te darás cuenta que ya hay una cafetera a medio construir. Empezó siendo una hoja Excel donde se anotaban los tiempos en los que los empleados consumían café, y ahora es una fábrica de cafeteras complicadísima, sin el menor atisbo de documentación de su intrincadísima ingeniería. Hay que tener mucho cuidado con estas cafeteras, ya que son tremendamente caras, lentas, ineficientes y a veces, al cambiar algún pequeño ajuste, dejan de funcionar partes sin relación alguna.

El café tiene que tener un grado de dulzor, acidez, tueste y molienda perfectamente iguales a los que el cliente quiere, pero lo que ha pedido es un café indo-etrusco, y nadie tiene la menor idea de qué significa eso. El café llegará frío, tarde y saldrá un 80% más caro, y la culpa siempre será del barista de inferior salario.

C#

Las malas lenguas dicen que no es más que una copia del café Java. Lo cierto es que el manual de instrucciones es ligeramente distinto, con mayúsculas donde antes esperabas minúsculas, y emplea referencias elegantes para definir tareas antes comunes y aburridas.

Aunque no tiene la comunidad de cafeteros que tiene el café Java, es el nuevo favorito de los jugadores. Además no necesita el aparatoso transformador de corriente que puede venir o no con las cafeteras de Java.

Lisp

Es el café favorito de las inteligencias artificiales. El café viene servido en una taza, dentro de un vaso, dentro de un plato, dentro de una bandeja, dentro de una tabla, en una mesa colocada sobre una tarima. Se dice que este café podría tener autoconsciencia.

C

Es el café de los sistemas operativos, y lleva siendo así desde los años 70. Normalmente el entorno ya proporciona los granos de café, pero a veces tiene que plantarlos uno mismo, regarlos y recolectarlos. La cafetera hay que montarla desde cero, aunque es posible usar piezas que hayas encontrado en una cuneta.

Aunque puede ser farragoso de hacer la cafetera, el café en sí es rapidísimo, y en principio no hay problema para hacerlo en cualquier hogar, siempre que el manual de instrucciones esté en el idioma local. Hay que tener mucho ojo, eso sí: si falta algún ingrediente lo normal es que la cafetera explote. Si se toca un cable pelado se puede ir la electricidad en toda la habitación, y si la instalación eléctrica es antigua, en todo el barrio. La forma de la cafetera es totalmente permisiva, y puede que haya ingredientes cuya localización sea otra habitación, estando totalmente inaccesibles, aun así ocupando espacio.

Con todo, este café a menudo es citado como una de las mayores hazañas en procesos de preparación de café de la historia. Su inventor, lamentablemente, falleció el mismo día que un conocido y carismático diseñador de cafeteras de diseño carísimas, de modo que no se le recuerda como le es merecido.

C++

Normalmente se piensa en este café como una mejora sustancial del café C, aunque esto es objeto de debate. La gran diferencia es que este café permite hacer referencia a la taza como un objeto, y no como una estructura de partículas cerámicas abstracta. Para hacer café no es necesario juntar todas las piezas al principio del proceso, sino que puedes cogerlas según las vayas necesitando.

Ensamblador

El café ensamblador difícilmente se define como una manera de hacer café. Todo lo que se proporciona es una tierra baldía. Se conoce como el café más rápido posible, siempre que la cafetera sea la correcta, aunque sólo funcionará en cierto lugar de la encimera de tu cocina. También es cierto que, antes de este café, sólo existían ciertas fórmulas para preparar diversas sustancias definiendo su forma molecular, de modo que podemos considerarlo un pionero.

Lo primero y más llamativo con respecto a los cafés descritos anteriormente es que uno debe buscar primero minerales para hacer sus herramientas, y luego refinarlos, fundirlos y montarlos con otras herramientas. Estas herramientas serán, probablemente, para construir las herramientas que se usarán en la elaboración del café.

Las semillas de café deben estar perfectamente definidas. Hay que realizar todo el proceso que toma hacer café C, pero el proceso se describe con palabras muy pequeñas en frases muy muy cortas que realizan pasos diminutos. No sólo hay que regar y cuidar los cafetos, el proceso debe estar perfectamente descrito sin atisbo a malentendidos en este lenguaje minimalista. El café debe cosecharlo uno mismo, a mano o construyendo herramientas al efecto siguiendo los pasos descritos anteriormente. Incluso el abono debe proporcionarlo uno mismo, y ya sabemos lo que eso implica: para hacer este café hay que estar dispuesto a llenarse las manos de mierda.

La cafetera, aunque parece robusta, tiene formas espartanas. Si no fuera por las recientes mejoras en las instalaciones eléctricas domésticas, el aparato podría hacer cualquier cosa, como encender la tele o hacer sonar el timbre. (aunque esto también es aplicable café C)

Es, probablemente, el café más complicado que existe de hacer, y es tan específico que sólo servirá para un consumidor. Eso sí, la satisfacción será del 100% si está correctamente realizado.

PHP

Hacer café en PHP es de lo más sencillo, pues simplemente se le pide a la cafetera que trae incorporada que te lo prepare.

Aunque la teoría es sencilla, la práctica nunca es lo que parece. La cafetera tiene dos botones de encendido, pero para apagarlo hay que usar una palanca. Puede que el café que prepare sea un moka, un cappuccino, un expreso, un cortado, un americano, un vaso de agua o un sándwich de morcón. Esto depende de la versión de la cafetera, de la situación dentro de la cocina, de sus ajustes, del usuario, de la casa donde se aloje, de cómo se pida o de las fases de la luna.

Otro problema de la cafetera es que, en caso de que algo no funcione, puede que el mensaje esté en inglés, en italiano, en klingon, que no haya mensaje alguno, que la cafetera deje de funcionar, que sólo eche azúcar o que explote. También puede que no ocurra nada en absoluto. Todo esto depende de las condiciones escritas anteriormente descritas, las cuales pueden cambiar (y cambiarán) en cualquier momento.

JavaScript

Todas las semanas hay una tecnología nueva para hacer este tipo de café, que es el favorito de la gente guay. El café es precioso. El problema es que todas las cafeteras se usan de forma distinta. Al menos en los hogares domésticos es prácticamente imposible hacerse daño al usarlas.

SQL, HTML, CSS, YAML…

Aunque a veces se hable de ellos como cafés resulta que no lo son, son líquidos para diversos usos, como desengrasantes domésticos, líquido para circuitos de freno hidráulicos o aceites para la piel. Algunos se pueden beber sin mayores consecuencias que un dolor de estómago, otros causan la muerte instantánea.

Etcétera

¡Gracias por llegar hasta aquí! Como siempre, agradezco cualquier comentario aportación, corrección o insulto en la sección de comentarios, aunque advierto que, en pro del humor (o lo contrario) me he permitido la licencia de usar hipérboles o chascarrillos que no son totalmente certeros. ¡Disfrutad! (si podéis)

Agradecimientos a mis amigos programadores que me han asesorado para escribir esta entrada:

• El puntero loco
• La función vietnamita
• La variable glotona
• Don Entrada y Don Salida
• El listener sátiro
• El paquete humano
• Y, por último, el señor Por-qué-no-compila-esto-odio-mi-trabajo-ah-era-este-punto-y-coma.

La entrada Cómo hacer café con distintos lenguajes de programación se publicó primero en Detrás del último no va nadie.

A diferencia de los ordenadores domésticos de la época, la arquitectura PC no usaba un chipset para gráficos integrado, sino que se valía de tarjetas de expansión para acometer la salida por pantalla. Esto, junto con su filosofía de ser una arquitectura más o menos abierta, propició que existiera a lo largo de su existencia toda una variedad de soluciones. He devorado un montón de páginas de revistas de informática antiguas y he aquí mis impresiones.

Cuando apareció el primer PC en 1981 se ofrecieron dos controladores gráficos distintos: Monochrome Display Adapter (MDA) y el Color Graphics Adapter (CGA). Ambas basadas en el Motorola 6845, un chip encargado de generar señales de vídeo, que acabaría usándose en ordenadores como el BBC Micro y el Amstrad CPC. De hecho, también se usó en otros adaptadores de vídeo para PC, que veremos ahora mismo.

Monochrome Display Adapter

La madre de todas las tarjetas gráficas de PC no es otra que la MDA, y se cita a menudo como una de las razones de su éxito en el entorno de los negocios. Se trata de, como su propio nombre indica, un adaptador de gráficos monocromo, con conexión ISA de 8 bits, y permite una matriz de caracteres en alta resolución de 80 por 25.

Bueno, la verdad es que gráficos es quizá decir mucho, por lo que el nombre de «tarjeta gráfica» le viene un poco grande, pero «tarjeta de texto» le viene pequeño (y naturalmente no la iban a llamar «tarjeta de pellizcos»). Aunque su resolución real era de 720×350 píxeles (80×25 caracteres de 9×14 píxeles) su memoria de tan sólo 4k no permitía direccionar cada punto por separado  (aunque sí atributos como subrayado o parpadeo), de ahí a que su único modo de pantalla fuera el de texto. Aún con todo, para un uso profesional como hoja de cálculo o procesador de textos era suficiente, de hecho su gran calidad de imagen la hizo incluso más popular que su hermana de leche.

El monitor y la tarjeta contaban con una conexión TTL, con dos pines para la señal de vídeo (ya que permitía un bit de intensidad) y dos para sincronía vertical y horizontal. El refresco de pantalla era fijo a 50Hz, y contaba con dos knobs para el contraste y el brillo. La pantalla de fósforo verde, imagen del ordenador desde los 60 y hasta bien entrados los 80, daba su nota de sobriedad.

Un hecho curioso y conocido es que el Monochrome Display and Printer Adapter, como se llamaba formalmente, incluía un puerto paralelo para la impresora.

Color Graphics Adapter

La CGA fue lanzada al mercado al mismo tiempo que el IBM PC y la MDA. No incluía el modo de texto en alta resolución de su hermana trajeada, pero sus 16 KB de memoria le permitían utilizar una resolución de 640×200 en blanco y negro o 320×200 a cuatro colores con tres paletas gráficas predefinidas. Incluía modos de texto con 16 colores, aunque no tan pulcros como los de la MDA.

Ni que decir tiene que era la opción lógica para las aplicaciones lúdicas, y salvo algunos juegos en modo texto casi todos dieron soporte a esta tarjeta para mostrar gráficos. De hecho durante al menos 10 años siguieron apareciendo juegos que, de una manera u otra, permitían usar este venerable hardware. De hecho Son of the Empire (Action Sixteen) soportó esta tarjeta en el año 1992 de Nuestro Señor, incluso Windows 3.0 (Microsoft, 1990) funcionaba con ella.

La tarjeta CGA podía usarse con el mismo conector DE9 que MDA, salvo que en lugar de tener dos pines TTL tenía cuatro (RGBi), lo que nos daba una conexión digital de 16 colores y sincronía. Todo ello con una frecuencia de refresco fija en 60 Hz. Curiosamente uno de los pines se usaba como una salida de 12V al monitor, aunque la mayoría no lo usó.

Además de la conexión TTL una de las características más interesantes de las tarjetas CGA era su salida analógica de vídeo NTSC, como una conexión RCA de vídeo compuesto. La verdad es que sus colores no eran una maravilla, y tendían a mezclarse unos con otros, al fin y al cabo se trataba de vídeo compuesto y codificado como «Never Twice Same Color» nada menos. No obstante esto podía usarse como una ventaja, y permitir muchos más colores aparentes al mezclar los adyacentes para generar «nuevos». El amigo 8-Bit Guy lo explica mucho mejor en su canal, si entendéis el idioma de Chaquespeare.

A lo largo de los años se han desarrollado técnicas complejas para sacar muchos más colores de los ideados inicialmente, hasta 1024 en la demo 8088 MPH (Hornet & CRTC & Desire, 2015). Al parecer, manipulando con mucho cuidado las sincronizaciones de vídeo, accediendo a modos no documentados y programando a muy bajo nivel, podemos hacer auténticas diabluras con este hardware. Naturalmente es poco práctico, pero ahí queda.

Debido a que MDA y CGA usaban recursos distintos técnicamente era posible usar las dos tarjetas al mismo tiempo, con dos monitores. La hoja de cálculo por antonomasia, Lotus 1-2-3 (Lotus Software, 1993) escribía directamente en la memoria de vídeo y consiguió que pudiera usarse el monitor monocromo para visualizar el texto y el monitor a color para gráficos, todo simultáneamente. Aunque esta característica no fue ampliamente utilizada, este software fue una de las razones del éxito del PC a medio plazo, y un importante punto de referencia para considerar un ordenador como «compatible».

Hercules Graphics Card

Esta tarjeta fue, si no la primera fabricada por un tercero, la primera en hacerlo con éxito comercial considerable. Básicamente se trata de una tarjeta compatible con la Monochrome Display Adapter de IBM con el interesante añadido, gracias a sus 64 KB de memoria, de direccionar punto a punto una resolución de 720×350, por lo que podía mostrar gráficos monocromáticos de alta calidad, todo ello en el monitor y la conexión suministrado con el PC. Técnicamente las dos últimas líneas no eran accesibles, por lo que la resolución quedaba en unos decentes 720×348 píxeles.

No fue una tarjeta tan ampliamente soportada como las «oficiales», pero sí que existió una cohorte de juegos que pudieron usarla, como muchos de LucasArts o los de Sierra On-Line, famosos por funcionar hasta en el microondas. El precio de lanzamiento de esta tarjeta era de 500 dólares americanos, equivalentes a unos 1300 en 2018.

Era posible, no obstante, emular una tarjeta CGA para aumentar la compatibilidad con programas y juegos que no soportasen directamente la tarjeta. Algunos modelos posteriores incluyeron compatibilidad por hardware, pero lo habitual es que se hiciera por software mediante emuladores como SIMCGA, que básicamente lo era por fuerza bruta: copiaba tan rápido como podía la memoria desde el área CGA (escrita por programas) a la memoria de Hercules en tiempo real. No funcionaba maravillosamente, especialmente con programas que escribieran directamente en la memoria en lugar de usar la BIOS, pero era mejor que nada. Los que lo hacían mostraban un tramado en lugar de colores, naturalmente. Pese a sus desventajas, ojalá hubiera tenido el SIMCGA cuando fue la primera tarjeta gráfica que cayó en mis manos…

Paralelamente a la Hercules aparecieron la Orchid Graphics Adapter y la Plantronics Colorplus, de similares características. En el caso de la Colorplus se añadía compatibilidad por hardware con CGA, pero ninguna de ellas gozó de un éxito comercial y apenas recibieron soporte de programas importantes.

IBM PCJr y Tandy 1000

El PCJr fue muy anticipado, y muchos profesionales y aficionados esperaban interesados un PC orientado al hogar en lugar de a los negocios. El resultado fue el PCJr, lanzado en 1984 y con mayormente compatible con el PC y el PC XT, sus hermanos mayores. Se diferenció de éstos por su teclado tipo chiclet, su chip de sonido y por tener sólo 128 KB de RAM, por lo que los programas más exigentes del PC no podían ejecutarse. En el apartado gráfico contaba con el Video Gate Array (no confundir con el VGA posterior), más conocido como CGA Plus.

Las diferencias con la Color Graphics Adapter era mayormente poder usar más colores en sus modos gráficos: 16 colores en el modo 320×200 y 4 en el 640×200 píxeles, siendo sus colores programables en lugar de las paletas predeterminadas. Otra característica, menos deseable, era que sus 128 KB de memoria eran compartidos con la memoria del sistema, haciendo que este ordenador fuera más lento que otros con el mismo procesador. Ninguna de sus características le salvó de ser uno de los fracasos más sonados de la informática moderna.

Salieron muy pocos juegos pensados para esta plataforma, y los más interesantes eran, por supuesto, las aventuras gráficas de Sierra On-Line. El ejemplo por excelencia es King Quest (1984), que salió en disquetes aunque el ordenador estaba pensando para usarse con cartuchos ROM.

El relevo natural de este ordenador lo tomó la compañía Tandy Corporation, con su Tandy 1000. Su tarjeta gráfica se llamó, por supuesto, Tandy Graphics Adapter. Si bien ofrecía las mismas características que el CGA Plus (incluyendo el hecho de compartir la memoria con el sistema), no eran directamente compatibles, y el software de uno ejecutando en el otro normalmente daba resultados no demasiado buenos: líneas que faltaban, otras que no debían estar ahí, etc. Pero no importa mucho: casi nadie echó en falta al PCJr y el software solía escribirse para esta TGA.

Professional Graphics Controller

Si bien el PC era una máquina competente en aplicaciones empresariales sus capacidades gráficas no eran algo del otro mundo. A partir de 1984, no obstante, IBM fabricó y vendió esta tarjeta, también conocida como Professional Graphics Adapter, Professional Graphics Array, o simplemente PGC, cuyas características orientadas a las artes gráficas miraba desde las alturas a prácticamente todos los ordenadores domésticos de la época. Eran realmente de infarto: 640×480 píxeles de resolución a 256 colores de una paleta de 4096, además de ser compatibles con los modos gráficos de la CGA.

Su aspecto era imponente: consistía en un sándwich de tres tarjetas de tamaño completo (una de ellas sólo para emular CGA por hardware) que ocupaban dos huecos en el IBM PC XT. No era para menos, ya que este producto incluía 320 KB (¡más que la mayoría de ordenadores!) y su propio procesador Intel 8088, por lo que escribir en memoria era mucho más rápido que en tarjetas de la competencia. Su precio era igualmente superlativo: 3.000 dólares de 1984 (equivalentes a unos 7.800 de 2018), y que sólo podía utilizarse con el monitor IBM 5175, que costaba en su día otros 1.300 dólares (unos 3.400 en 2018). La wikipedia cita, no obstante, que una estación de trabajo para diseño por ordenador rondaba por los 50.000 dólares (unos 130.000 en 2018), por lo que en perspectiva no era tan descabellado.

Sus modos especiales no eran accesibles mediante la BIOS, y no se conoce de ningún juego que los usase. No es una gran sorpresa, dado que era un producto orientado al CAD (Computer Aided Design, diseño asistido por ordenador), y su uso principal fue en el AutoCAD 2.5 (Autodesk, 1986). No tuvo realmente competencia, aunque en un par de años surgieron clones decentes, como la Everex EPGA, compatible también con la Hercules y CGA, ocupando una sola ranura de expansión. En lugar del 8088 incluía nada más y nada menos que un intel 80286, más poderoso aún, y 512 KB de memoria RAM. No he conseguido encontrar a cuánto se vendió, pero me atrevería a decir que no era barata. Actualización: Costaba 999 dólares (aprox. 2.400 de 2018), lo pone en grande en el anuncio. Veo menos que un gato de yeso.

Enhanced Graphics Adapter

El nuevo estándar de vídeo IBM llegó con esta tarjeta, que aunque no era totalmente retrocompatible con las anteriores incluía modos de vídeo para todos los gustos. Llegó en 1984, y mostraba una resolución de hasta 640×350 a 16 colores, a elegir arbitrariamente de una paleta de 64.

Este producto usaba un nuevo tipo de monitor, muy convenientemente llamado EGA. Se usó de nuevo el conector DE9 TTL, esta vez con 6 pines para la imagen. Su uso no se limitaba al flamante AT, el nuevo modelo de PC que IBM presentó ese año, pero sin duda fue su complemento ideal. Proporcionaba mucho mejores gráficos que ordenadores de la época como el Commodore 64 (1982) por un precio muy competitivo, que en 1986 era de 524 dólares. (unos 1.350 de 2018). Ni que decir tiene que se convirtió en la tarjeta que todos los juegos querían, y hasta 1994 siguieron saliendo juegos, como BlackThorne (Blizzard). No obstante, los modos de alta resolución no solían ser soportados…

La tarjeta EGA era compatible con los modos RGBi de la CGA, y cambiaba su frecuencia vertical de 15.7 a 21.8 kHz mediante conmutadores accesibles en la placa. Esto era un poco engorroso porque hasta que no aparecieron las primeras tarjetas autoconmutadas había que estar toqueteando el ordenador por detrás, así como eligiendo el modo en el monitor, pero valía la pena tener compatibilidad casi completa. Se perdió, no obstante, la conexión de vídeo compuesto NTSC, por lo que el software (¡los juegos!) pensados en este modo no se veían demasiado bien con la EGA.

Un cambio que sí fue muy bien recibido eran los modos lineales, en oposición a la Hercules y CGA cuyos modos gráficos eran entrelazados. ¿Qué significa esto exactamente? Pues que antiguamente la memoria tenía dos bloques: uno con las líneas impares y otro con las pares, de manera que uno iba escribiendo en la memoria y de repente saltaba dos líneas, no una. Con EGA por fin podíamos escribir desde el principio hasta el final sin tirones extraños. Otra característica muy deseable fue la de incluir en su ROM extensiones a la BIOS, de manera que el software podía usarla mediante la misma, a diferencia de la PGC, por ejemplo. Una de las formas más destacadas de explotar este hardware fue el scroll suave de Commander Keen (1990) programado por John Carmack, en la que hacía uso de píxeles no visibles (y del desplazamiento por hardware) de modos planares consiguiendo emular la visual de las videoconsolas de la época sin parpadeos ni artefactos de imagen. Qué son dichos modos planares lo expondré más adelante.

Al tiempo de existir el estándar comenzaron a surgir sus clones. Algunos incorporaban modos gráficos parecidos al MDA, otros tenían más resolución. Estos modos gráficos apenas tuvieron soporte por lo que no eran una característica demasiado interesante. Otras tarjetas en lugar de ello incluían autoconmutación, de modo que no había que ir tocando palanquitas minúsculas para cambiar de modo gráfico. Fue el caso de la Paradise EGA, en 1986. Por 500 dólares (1.300 en 2018) hacía todo lo que la estándar EGA, CGA, Hercules y MDA, con autoconmutación y soporte para lápiz de luz. Además, tenía dos conectores RCA que ni su padre sabía para qué fueron. Yo desde luego no tengo ni idea.

Multi-Color Graphics Array

En realidad, esta tarjeta nunca existió como tal. Era simplemente el nombre que recibía el chipset de vídeo del IBM PS/2 Model 30, un interesante ordenador lanzado en 1987 del que deriva, por ejemplo, el conector de ratón y teclado que se usó hasta hace relativamente poco. También se introdujo el bus MCA (Micro Channel Arquitecture), que fue un intento de IBM de recuperar el timón de la arquitectura PC. Fue un duro y caro revés para IBM.

El chipset MCGA sin embargo vino para quedarse, o mejor dicho sus modos gráficos lo hicieron. En especial el de 320×200 a 256 colores a elegir de entre 262.144, que fue usado extensivamente en juegos. También ofrecía soporte para 640×480 en monocromo. Su mayor desventaja era no ser compatible con EGA, por lo que los juegos que no soportaran estos nuevos modos se veían obligados a mostrarse en los modos CGA, mucho más feos. La solución era simplemente usar el modo a 256 colores y usar los 16 que más se pareciesen a los de EGA, pero el software tenía que estar programado para ello y lógicamente ello excluía a todos los programas anteriores a MCGA. Aún con todo es a partir de entonces cuando los PCs comenzaron a tener capacidades gráficas superiores a prácticamente todos los ordenadores domésticos de la época.

El conector y monitor que empleaba esta tecnología eran analógicos, al contrario que los estándares anteriores (salvo la Professional Graphics Adapter) que eran basados en señales digitales TTL. El conector era un DE15 que portaba señales RGB y sincronía vertical y horizontal, y en esta ocasión podía tener una frecuencia de refresco de 50 a 70 Hz dependiendo del modo gráfico. A la postre este conector se denominó VGA, y aún en 2018 sigue dando coletazos pese a estar obsoleto. Su nombre es evidente para los aficionados a la informática, como ya veremos.

Este MCGA murió con los primeros modelos de la línea PS/2 de IBM, que dejaron de fabricarse en 1992. Ni que decir tiene que también desapareció el bus MCA, aunque curiosamente el conector para teclado y ratón se quedó con nosotros hasta bien pasados los años ’10 del siglo XXI.

Una alternativa al MCGA en la línea PS/2 fue el menos conocido estándar IBM 8514, muy parecido al Professional Graphics Adapter de unos años antes en prestaciones al soportar también una resolución de 640×480 a 256 colores. Se trataba no sólo de una tarjeta gráfica sino de toda una CPU moderna, ya que permitía aceleración gráfica (en 2D, obviamente) al permitir instrucciones como dibujar primitivas o transferir memoria. Al ser compatible con Windows 3.X (posteriormente también con Windows 2.X) fue el estandarte de la calidad de vídeo de IBM, que mostraba el Microsoft Excel luciendo como en ningún sitio. La tarjeta costaba 1.290 dólares, más 270 si queríamos la ampliación de memoria a 1MB (necesaria para el modo gráfico 640×480 a 256 colores) eran otros 270 y el monitor a juego nos lo vendía IBM a 1.550. En total: 3.110 dólares de vellón, alrededor de 6.600 dólares de 2018. Esta tarjeta no fue tan clonada como otras de IBM, por lo que el soporte de software fue limitado y no se conoce su uso lúdico.

Video Graphics Array

Si hubiera que elegir un adaptador gráfico por excelencia para el PC podemos parar de buscar. Apareció en 1987 y sus modos gráficos son soportados aún hoy, y utilizados cuando falla todo lo demás. Fue y es el denominador común en gráficos de prácticamente todos los PCs y compatibles, y es con mucho el estándar gráfico más clonado que haya existido. Se puede escribir un libro tocho sobre el VGA (y hay no pocos), pero vamos a tratar de discurrir sobre lo más importante.

En sus especificaciones estándar está el incluir prácticamente todos los modos de vídeo de EGA, CGA y MCGA, además de uno de 640×480 con 16 colores definibles. La mayoría, no obstante, soportaba también los modos de alta resolución de hasta 800×600 puntos, aunque dependiendo del dinero que nos gastásemos la tarjeta o el monitor podrían no soportar los modos más altos, y dependiendo también de su memoria RAM que, aunque se especificó en 256 KB, algunos modelos más baratos traían menos. Dada su naturaleza programable era capaz de usar una resolución prácticamente arbitraria con combinaciones locas, así como nuevos modos de texto que se hicieron muy populares en entornos como el desarrollo de software.

La desde entonces ubícua VGA tenía unas características técnicas muy interesantes. Su frecuencia de refresco variaba de 50 Hz para los modos de alta resolución hasta los 70, y su sincronía vertical era fija en 31.46875 kHz. Este número no es casual: era exactamente el doble que una señal NTSC, por lo que era relativamente sencillo construir un adaptador para mostrar imágenes en un televisor normal. Gracias a su memoria RAM se podían definir hasta 4 planos, que podían modificarse aunque no se estuvieran visualizando en ese momento y conmutarlos cuando nos fuera conveniente. La guinda del pastel era que casi todos sus modos gráficos eran accesibles por la BIOS por las extensiones que incluía para ésta.

Este adaptador de vídeo tenía, no obstante, algunos pequeños inconvenientes. No era compatible con los modos especiales del PCJr o de Hercules, y la compatibilidad no era del 100% con EGA. Tampoco incluía salida de vídeo compuesto como CGA. En realidad ninguna de estas desventajas eran gran cosa, dado que prácticamente todos los modos gráficos podían emularse en VGA fácilmente. Por último, programar los modos gráficos más complejos (múltiples planos, operaciones complejas) no era sencillo y no podía hacerse mediante la BIOS sino que había que manejar el hardware directamente. Esto más adelante fue casi tanto una ventaja como una desventaja, ya que la flexibilidad de este estándar permitió desarrollar toda una suerte de modos gráficos exóticos y algoritmos específicos.

La VGA no era una verdadera GPU como tal, dado que no tenía capacidades de aceleración de vídeo. Sin embargo sí que contaba con ciertas operaciones que podían aprovecharse para mejorar mucho el rendimiento gráfico, como poder establecer 4 píxeles de golpe o copiar regiones de la RAM de vídeo sin intervención del procesador. Esto, junto con los modos multiplanares, mejoró considerablemente la capacidad en juegos de lo conseguido con EGA, consiguiendo no sólo scroll suave sino el poder usar sprites de forma parecida a los sistemas de videojuegos dedicados (aunque no directamente con soporte de hardware).

El PC en Japón

Dado que el estándar PC estaba pensando para utilizar el alfabeto latino (o el cirílico o el griego si cambiábamos los glifos del modo de texto) y no soportaba caracteres japoneses (más complejos y numerosos) nunca fue popular en Japón. En 1986 se introdujo una variación de EGA, llamada JEGA (Japanese EGA) que usaba una BIOS especial con caracteres de doble ancho, pero no fue suficiente para competir con la arquitectura PC-98 de NEC. Tampoco lo fue el AX-VGA, su equivalente actualizado a los estándares VGA.

La solución fue más sencilla de lo que parecía: Microsoft lanzó versiones específicas de su MS-DOS a partir de 1990, al que llamó DOS/V que funcionaba en las máquinas japonesas con una VGA estándar y permitía usar texto con caracteres japoneses.

Modo X

Si bien la mayoría de trucos de este hardware se conocían de antes, en 1991 Michael Abrash publicó un artículo sobre un modo gráfico no documentado por IBM, acuñando el nombre de modo X. No era inédito y se usó anteriormente en algunos juegos, pero fue a partir de entonces cuando adquirió identidad en el mundo de la programación de videojuegos por aunar todas las características deseables de los modos gráficos. Excepto por una cosa: era bastante complejo de programar.

Este modo proporcionaba una resolución de 320×240 píxeles con 256 colores arbitrarios. En la relación de aspecto de los monitores de PC (4:3) esto significaba que los píxeles eran cuadrados, a diferencia de casi todos los demás modos de vídeo, lo que simplificaba enormemente el cálculo de distancias «reales» en la pantalla respecto a la diferencia en píxeles. El tener 256 colores significaba que cada píxel de la pantalla era representado por un único byte en memoria, por lo que se eliminaba la necesidad de leer y realizar máscaras de bits para dibujar en pantalla. Pero sobre todo, al ser un modo planar (llamado en su artículo «no encadenado») permitía escribir en varios planos y conmutarlos a voluntad. De su mayor virtud también su defecto principal: la forma de escribir en memoria era muy compleja, dado que cada byte contiguo estaba en un plano distinto. Con cuatro planos, por ejemplo, cada 4 bytes contiguos representaban cuatro píxeles en pantalla, uno en cada plano.

Fabricantes

Los primeros ordenadores en incorporar una tarjeta gráfica VGA fueron la línea PS/2 de IBM, al principio integradas en la placa base y luego como una tarjeta independiente. De hecho el principal alegato de la empresa era que ya no se trataba de un conjunto de chips, sino que se prescindió del controlador MC6845 que tenían otras tarjetas y se integró todo en un único procesador, salvo por la memoria y la electrónica auxiliar. (cristales, electrónica pasiva, etc.) Su alta escala de integración fue lo que permitió el lujo de poder incluirla en la propia placa base.

No tardaron en salir tarjetas con una alta compatibilidad, que rondaban los 500 dólares en 1987 (unos 1.100 dólares en 2018). De hecho es probablemente la tarjeta de vídeo más clonada en los PCs, y la Wikipedia cita como los principales a S3, Ati, Matrox, Tseng, Trident, NEC y otros muchos más. Todos tenían en común los modos estándar y normalmente los de alta resolción, así como otros tantos modos y características particulares de cada casa. Esto permitía dos cosas: que la industria progresara añadiendo nuevas capacidades y que IBM perdiera el control sobre el estándar, por lo que cada tarjeta terminó siendo de su padre y de su madre, dando paso al siguiente capítulo del culebrón.

XGA y lo que te rondaré, morena

Tras el éxito arrollador de la VGA, el siguiente estándar propuesto por IBM fue el Extended Graphics Array, abreviado como XGA. Sus características sobre el papel no eran muy arrolladoras para 1990, aunque sí se añadió un modo de 640×480 a 65.536 colores, algo que dejaba poco que echar en falta frente a soluciones profesionales. Añadía también compatibilidad parcial con la 8514 de IBM, en particular con su modo de 640×480 a 256 colores y el modo 1024×768 píxeles a 256 colores, que en esta ocasión permitía direccionar todos los píxeles individualmente a diferencia de la 8514 que sólo permitía texto en este modo.

Sin embargo, la mayor baza de esta tarjeta era una supuesta mejora de hasta un 50% en Windows frente a VGA. Realmente no era para tanto, porque el software no solía estar programado para usar todos los recursos de la tarjeta, por lo que soltar los 1,095 dólares de 1990 (más de 2.100 dólares de 2018) difícilmente justificaba esta mejora de rendimiento. Era una buena opción, eso sí, para sustituir al carísimo sistema 8514 en el sistema operativo OS/2 de IBM o en el propio Windows de Microsoft.

Esta nueva tarjeta gráfica tuvo dos problemas fundamentales: primero que fue presentada para su línea de ordenadores PS/2 con un bus MCA, y puesto que era propietario y caro de implementar por terceros fracasó. Además, en aquella época terceros fabricantes simplemente añadían extensiones a las especificaciones VGA para alcanzar prestaciones arbitrarias, siendo esta especificación XGA poco atractiva para ellos. Los juegos y programas en alta resolución, en particular para MS-DOS, lo tuvieron difícil a finales de los 80 y principios de los 90 ya que debían soportar toda una plétora de variopintos estándares, por lo que la mayoría se quedaron estancados en el común denominador que eran los modos VGA.

Super VGA

Justo a continuación de salir las primeras VGA al mercado comenzaron a establecerse los primeros retazos de esta especificación, que nunca se materializaron en ninguna tarjeta en concreto. De hecho, técnicamente no se trata ni siquiera de una especificación formal, ya que no había una autoridad que hubiera publicado un estándar fuera del camino que IBM o los principales fabricantes fueron abriendo. En este contexto, incluso la XGA de IBM acabó siendo considerada como parte del comistrajo de Super VGA.

Esto cambió alrededor de 1990 con la publicación por consorcio VESA (Video Electronics Standards Association) de las VBE: VESA BIOS extensions. A partir de entonces comenzó, poco a poco, a existir una interfaz común en para acceder a los modos de alta resolución a la postre denominados Super VGA, todo mediante dichas extensiones en la BIOS. Las primeras especificaciones definieron modos de vídeo que las tarjetas implementarían, en especial los de alta resolución. En 1994 se publicó su especificación 2.0 que añadía soporte de páginas, modos planares, modos de 16 y 24 bits de color, modos lineales y todo ello en el modo protegido de la CPU, lo que permitió por fin que los juegos en alta resolución se hicieran realidad en el PC sin tener que programar para cada tarjeta específica.

Otra de las especificaciones de VESA fue el VLB, VESA local bus, en 1992. Esta interfaz alternativa al bus PC (a la postre llamado ISA, Industry Standard Architecture) hacía que el microprocesador estuviera mucho más cerca de la gráfica, lo que permitía un rendimiento superior. Se trataba en realidad de un añadido a ISA, y permitía por ejemplo que la tarjeta gráfica accediese a la memoria principal mediante canales DMA, o memoria gráfica mapeada en la memoria principal en el modo protegido. No era un estándar exento de problemas: primero estaba diseñado fundamentalmente alrededor del procesador 80486 de Intel, lo que resultó en una solución no escalable y no demasiado fiable. Su uso, salvo excepciones, se limitó al de las tarjetas gráficas, y las placas base solían incluir a lo sumo dos ranuras que soportasen VLB. Por último, su factor de forma hacía las tarjetas difíciles de instalar, ya que era un conector enorme y que aplicaba cierto estrés a los componentes al instalarse. La puntilla fue la aparición del bus PCI ese mismo año, y tarjetas gráficas compatibles al año siguiente.

Finale

Super VGA, o lo que vino siendo mediante estándares y consorcios, fue el último gran (no) estándar gráfico de la era PC, ya fuera de los designios de la empresa IBM. En 1990 una tarjeta Super VGA decente costaba alrededor de 400 dólares (770 de 2018), frente a los más de 1000 (más de 1.900 de 2018) que costaban las soluciones de IBM, por lo que fuera de aplicaciones gráficas profesionales fue el gran triunfador.

A partir de entonces es otra película. Con el ocaso de MS-DOS, el inicio de la era Windows 95 y el modelo de drivers pasó algo parecido a con las tarjetas de sonido, y las peleas se centraron en aplicaciones específicas como el 3D o la decodificación de vídeo. Pero esto es otra historia.

Agradecimientos a mis amigos gráficos, que me acompañan y me asesoran en esta exposición:

• El píxel loco
• La tarjeta humana
• Doña Resolución Horizontal y doña Resolución Vertical
• La enana en alta resolución
• El monitor morsegón
• La ranura glotona
• El señor Estándar
• Por último, don Aquí No Se Ve Na.

Como siempre, tendré a bien recibir comentarios, apuntes y añadidos sobre lo ya dicho, así como experiencias personales de quienes se gastaron más dinero del debido en tener 10 o 12 colores más en pantalla.

La entrada Tarjetas gráficas de la era IBM se publicó primero en Detrás del último no va nadie.

No ha sido jugar en el betis, por desgracia, dado que mi habilidad con el balón es la misma que la de Paquirrín con el violín: no sé ni qué hacer con él. Sí que he podido, sin embargo, agenciarme una NeoGeo MVS, la placa para recreativas de SNK. Conocidísima entre cualquiera que haya sido joven en los 90, por la altísima calidad de sus juegos y por haber sido la base para la consola NeoGeo AES, con el que compartía hardware y juegos.

Bueno, lo de tener una recreativa es aproximado, dado que mi piso tiene el tamaño de un cuarto de las escobas promedio. En su lugar me he agenciado un invento para poder usar estas placas en un tele normal, así como los cables y cacharros necesarios para poder jugarla. Estos aparatos son conocidos genéricamente como Supergun, y voy a explicar cómo usar uno.

Para empezar, las placas de arcade no tienen un cable para enchufarlas al televisor de tu vieja, ni siquiera para enchufarle electricidad. ¿Cómo demonios funcionan? La mayoría a partir de mediados de los ’80 usan el conector JAMMA (Japanese Amusement Machine and Marketing Association), en el que se suministra energía y controles y tiene como salida vídeo analógico en formato RGBS. La mayoría de las televisiones europeas desde finales de los 80 admite esta señal de una forma u otra, sea vía euroconector o por un puerto VGA si es moderna, pero la alimentación es un poco complicada porque es necesario 12V por un sitio, 5V por otro y a veces -5V.

En una recreativa de verdad  es necesario un monitor multifrecuencia, una fuente de alimentación que de todos estos voltajes y un montón de cables y conmutadores para controles y monederos. Con un mueble al efecto, por supuesto, y si está todo pelado, lleno de mugre y pelusas mejor. Ni que decir tiene que como toques donde no debes (en concreto en el monitor) te puede dar un calambrazo que vestirá a tu familia de negro, así que mejor déjaselo a un profesional.

Aquí es donde entra en juego la placa Supergun. En lugar de tener una plétora de cables pelados y llenos de cochambre podemos usar elementos mucho más comunes: un televisor, un mando de consola y una fuente de alimentación ATX, que son las que llevan los PCs. Además proporciona un botón para «echar dinero» y otras muchas características útiles. Algunos modelos se adaptan a extensiones del estándar, como el de NeoGeo (que tiene un par de botones más y sonido estéreo) o CPS2 de Capcom (que tiene un chorro de botones y sonido estéreo también).

Este Supergun concretamente tiene algunas características interesantes. Primero, es capaz de generar aproximadamente un watio de -5V, necesario para algunas placas antiguas (aparentemente la NeoGeo no lo necesita).  También permite regular la sincronía de vídeo, así como los canales rojo, verde y azul individualmente. Tiene incorporado un voltímetro, para saber de antemano que la fuente de alimentación está dando valores correctos. Se supone que tiene auto-disparo, pero o bien no funciona o soy un melón y no se ponerlo. Para los controles tiene dos puertos DB15 macho para los controles y un DB9 hembra para los botones extra, también conocido como «kick harness».

Lo bueno es que, por medio de un adaptador, podemos usar un mando de 6 botones de Mega Drive, o de otras consolas más comunes ya que los mandos de NeoGeo son caros de cojones. También tiene conector de audio estéreo por jack y RCA, de modo que podemos conectar unos altavoces si queremos.

Muchos de los modelos de las placas de NeoGeo MVS permiten conectar mandos de NeoGeo directamente. Parecen conectores DB15 estándar, pero lamentablemente el conector es más profundo y no sirve uno estándar. Otros modelos de SuperGun admiten directamente mandos de Mega Drive, pero ojo porque sólo suelen soportar dos botones por jugador, tres como mucho.

Este modelo de Supergun, así como el adaptador de mandos, se puede encontrar en eBay, por ejemplo. Haciendo la búsqueda adecuada se pueden encontrar otros muchos modelos y cacharros. Algunos vienen sin montar, otros traen caja… hay modelos para todos los gustos. Como siempre que se compra en eBay fíjate bien en la reputación del vendedor, y lee bien las características del anuncio. El precio suele estar entre los 40 euros para modelos más básicos a 70 para los más completos. También sale alguno de vez en cuando con caja desde 100 euros, o incluso con mandos y fuente de alimentación a precio de alfombra persa.

Otra posibilidad es, por supuesto, construiros vosotros mismos un Supergun. Normalmente no vale la pena porque es un trabajazo, pero quien quiera hacerlo por hobby tiene a su disposición conectores a buen precio también en eBay. Ninguna de las señales va multiplexada, por lo que no hace falta codificar nada. Los controles se registran (es decir, se envía la información de que se pulsa) cuando el pin preciso conecta con tierra, y dejan de hacerlo cuando están en alta impedancia, y la señal RGBS puede ir directamente a un monitor o televisor, sea por conectores BNC, RCA o por euroconector. Algunos modelos tienen salida VGA a 31Khz, y se ven genial en un monitor analógico de ordenador.

Algunas placas, en especial algunas de Konami antiguas y muchas de principios de los 80, necesitan adaptar la conexión porque no siguen el estándar JAMMA. Esto añade una capa más a la instalación, pero para los juegos que no sean antediluvianos no suele ser necesario.

Un consejillo más: en mi tinglado uso un múltiple de euroconector. No lo recomiendo a no ser que no haya más remedio (porque los cables no lleguen, por ejemplo) dado que añadirán ruido a la imagen. Con este conector normalmente no obtendremos sonido estéreo ya que el estándar JAMMA es mono, pero algunas placas (como mismamente la NeoGeo) usan el conector de señal de sonido negativa para un segundo canal de audio, algo que debe gestionar el Supergun. Si no, la placa tendrá algún conector de audio directo.

Los juegos de NeoGeo existen en dos formatos: MVS y AES. Los de MVS son los de recreativa, algo más grandes y los de AES sirven para la versión doméstica y tienen bloqueo regional. No tienen el mismo conector, y es necesario un adaptador para usarlos en un sistema para el que no estuvieran diseñados, pero técnicamente son el mismo cacharro y contienen los mismos datos. Bueno, es hora de probarlo todo.

Una vez conectado todo ya podemos jugar. Este modelo de Supergun tiene más luces que Las Vegas (las de Nevada, no las de Sevilla), indicando que el hay voltaje en las líneas de 12V y 5V. Acuérdate de darle al botón de monedas, dado que esto no suele ser posible desde los mandos. De ser así sería un ruinazo para el dueño de los recreativos, ¿verdad?

Ya sólo queda disfrutar nuestros juegos. Una ventaja de la NeoGeo MVS frente al modelo doméstico es que, aunque en origen era más cara, dado que se vendió más es más fácil y barato de conseguir hoy día. Hay que armar un follón para poder usarla, pero con él podemos usar casi cualquier placa de arcade que queramos. Podemos conseguir una placa base de NeoGeo por unos 40 o 50 pelotes,  y los juegos van desde los 30 para los más comunes hasta cientos de euros para los más difíciles de conseguir.

Espero que este artículo, describiendo mi experiencia, pueda resultar de ayuda a alguien. En todo caso cabe avisar que no tengo ninguna relación con los vendedores de eBay, y no puedo responsabilizarme de nada que compres o hagas, aunque sí es cierto que algunos enlaces son patrocinados. Es decir, me dan una miseria si alguien compra algo. Si vas a intentar algo de lo aquí descrito ten un poco de sentido común: no toques con tus sucias manos los conectores, no juegues con la electricidad y ten cuidado de no hacer un cortocircuito, puedes quedarte sin juego y sin alfombra.

Edit: Al parecer a Ibáñez, dueño de eBay, no le gustan los enlaces, así que los he tenido que quitar.

La entrada De cómo usar juegos de recreativas en casa se publicó primero en Detrás del último no va nadie.

Sin embargo y poco a poco estos ordenadores barrieron con todo. Durante su apogeo los Macintosh fueron minoritarios, y tanto los Amiga como los ST de Atari  se apagaron y desaparecieron. ¿Qué tal les fue en el aspecto sonoro como para competir con ellos? Fue el momento de las tarjetas de sonido para PC y compatibles.

El primero de los PC era un ordenador modesto. Sus características no eran mejores que las de, por ejemplo, un Commodore 64, pero estaba orientado a los negocios de manera correcta: un teclado y un monitor de mucha calidad, una arquitectura relativamente abierta, un microprocesador decente y amplia documentación sobre su BIOS, que fue replicada por terceros para disgusto del gigante azul. Esto y muchos otros discutidos detalles contribuyeron enormemente a su popularización, pero esto es otra película.

En este artículo voy a tratar de dar una visión sobre cómo evolucionó el sonido en los PCs, cuál fue el hardware detrás de ello y por supuesto de cómo impactó en el mundo de los videojuegos, a través de la edad de oro del PC y su omnipresente MS-DOS. Por ahora no conozco suficiente el mundo de los MSX, por ejemplo, para extenderme a otras plataformas, pero confío que en un futuro me toque la quiniela y tenga tiempo de sobra para hacerlo. Voy a intentar, no obstante, explicar la jerga y los términos empleados para tratar de hacer el texto inteligible. Prometo ser breve.

El pitito, o PC Speaker

Todo lo que tenemos en el estándar PC sobre el sonido es el que acompañó al primer modelo, llamado sencillamente PC Speaker. Se trata de un pequeño altavoz de dos pulgadas y un cuarto montado en el chasis de la máquina. Un elemento que se ha mantenido en las placas base de PC incluso hoy, siendo sustituído por un menos aparatoso buzzer piezoeléctrico.

El funcionamiento de un altavoz de membrana magnética es de sobra conocido: el sonido analógico, transmitido mediante una corriente eléctrica, actúa sobre un electroimán que hace moverse una membrana magnética. Las vibraciones de esta membrana, transmitidas como ondas de presión en el aire, constituyen los sonidos que podemos oír.

El caso de los altavoces piezoeléctricos es algo más interesante: aprovechan la capacidad de ciertos cristales para vibrar en función de la corriente eléctrica que los atraviesa para generar directamente ondas de presión en el aire. Esto permite miniaturizarlos al máximo y hacerlos muy baratos, a costa por supuesto de que la calidad del sonido sea ínfima. En todo caso adecuada para las características del PC Speaker.

Pero ya basta del Mundo de Beakman. Siguiendo con lo que nos ocupa, las características técnicas del sonido del PC Speaker son realmente pobres: tan sólo es capaz de emitir una señal cuadrada de 1 bit con una frecuencia arbitraria. Es decir, sólo pitidos a todo volúmen con la frecuencia que queramos, lo cual nos deja en pelotas frente a prácticamente cualquier otro sistema.

El funcionamiento del PC Speaker es igualmente sencillo. El controlador es un Intel 8253, un temporizador programable que controla la tensión del altavoz. El ordenador simplemente le dice cuándo pitar y cuándo parar, comunicándose con éste a ¹⁰⁵⁄₈₈ MHz. Esta extraña medida se debe a que corresponde con un tercio de la frecuencia de la ráfaga de color de NTSC, y dividido por el mayor número entero de 16 bits corresponde a la frecuencia de las interrupciones por software de MS-DOS. ¡Qué bien! ¿Verdad?

A principios de los 90 comenzó a usarse una técnica que permitía obtener sonido digital, la modulación por anchura de pulsos, o PWM (pulse width modulation). Esta técnica consiste en aprovechar las características físicas de un altavoz mediante pulsos TTL en alta frecuencia. Básicamente las partes físicas de un altavoz poseen inercia, de modo que si un pulso es lo suficientemente corto esta inercia puede amortiguar el movimiento y conseguir estados intermedios. Como todo esto debe hacerse por software hace falta comunicarse muchas veces por segundo con el controlador, de modo que hace falta mucha CPU para hacer algo a derechas. El resultado no era espectacular tampoco se ha calculado (personas más listas que yo, fíjate) que es equivalente a un DAC de 6 bits, con una frecuencia de respuesta de unos 11 KHz.

Con todo, dado que todos los PCs contaban con este dispositivo fue ampliamente soportado a lo largo de toda su historia, y a menudo bien entrados en los 90 existieron juegos que sonaban fundamentalmente con otras tarjetas que daban soporte de una forma u de otra al PC Speaker. El mejor ejemplo de ello fueron los juegos de Digital Illusions CE (ahora DICE) como Pinball Fantasies (1992). Los trackers, populares programas de producción musical amateur, también solían dar soporte, como Impulse Tracker (1995) o Fast Tracker II (1994) entre otros.

Los periféricos de audio en el PC

El sistema operativo por excelencia de estas máquinas es el MS-DOS y sus variantes, y no fue hasta la segunda mitad de los años 90 cuando las tornas empezaron a cambiar. Incluso entonces y hasta al menos el año 97 siguió siendo muy popular para los juegos de PC. Siendo que este sistema no daba soporte a nada que no fuera el PC Speaker, ¿cómo se usaban las tarjetas de audio?

Como se suele decir, con cuidado. Dado que el sistema operativo no daba soporte, cada software que se hiciese debía construirse para manejar cada una de las tarjetas que quisiera hacer funcionar. Además, como cada una empleaba una tecnología de su padre y de su madre, probablemente usaría distintas fuentes. (audio digital PCM, secuencias MIDI, programas para un generador de sonido…)  Por ello no todos los juegos soportaban todo el hardware, dado que no todas eran populares.

Una forma popular de que un programa usara muchas tarjetas de audio distintas era a través de un middleware, y el más común por mucho fue el Miles Sound System, a partir de 1991. A través de estas librerías era posible programar sistemas de audio para juegos que aprovecharan todas las tarjetas de sonido de consumo, y a menudo ayudaba unificando los recursos musicales del juego para que sirvieran a todas ellas. Además solía ser mucho más sencillo configurar los ajustes de hardware mediante los asistentes que se solían incluir. (¿Quién se acuerda de SETSOUND.EXE?)

Configurar una tarjeta de sonido no siempre fue una tarea sencilla. En sistemas operativos como Microsoft Windows todo era manejado por éste, y con el driver adecuado cualquier programa sonaba como es debido. En MS-DOS el programa debía acceder al hardware directamente, y los recursos del sistema no siempre se encontraban en el mismo lugar. ¿En qué puerto debía escribirse? ¿Qué interrupción es la que controla la tarjeta? ¿Tendré un conflicto con el puerto de impresora?

La forma más popular de hacerlo es, por supuesto, mediante programas que podían configurar nuestro hardware, asignándoles recursos libres. Luego podríamos indicar a nuestro juego qué recursos hemos asignado, o podrían averiguarlo ellos mismos mediante variables de entorno. No obstante, y sobre todo al principio, sólo se podía modificar los recursos a la tarjeta manipulando físicamente. Esto se hacía mediante jumpers que cerraba puentes en distintos contactos de la placa, pero a principios de los 80 muchas veces el usuario se veía en la necesidad de coger soldador o cúter para modificar las pistas de la tarjeta. Afortunadamente, no solía ser el caso en los tiempos del PC.

¿Qué tarjetas exactamente fueron las más vendidas o las más usadas en los juegos de PC? ¿Cómo funcionaban? Intentemos ver las más comunes y las más interesantes.

PCjr y Tandy 1000: SN76489

Ya he escrito sobre este chip de audio. Creado por Texas Instruments a principio de los 80, fue usado en multitud de sistemas a lo largo de la década y llegó al PC mediante el PCjr a mediados de 1984, un ordenador (parcialmente) compatible con el PC de IBM. Más orientado al ámbito doméstico incluyó un modo de vídeo mejorado, un teclado chiclet y un sistema de sonido que incluía el SN76489.  Unos meses más tarde surgió el Tandy 1000, un clon del PCjr con compatibilidad parcial que trató de mitigar los problemas tanto del PC original como del PCjr, aunque al mismo tiempo introduciendo nuevas incompatibilidades con ambos.

Este es un hardware con unas capacidades más bien modestas: tres voces de ondas cuadradas y una de ruído blanco, dando lugar a una salida mono. Claro que comparado con el sonido del PC Speaker era una gran mejora. El éxito de este sonido fue limitado, ya que aunque el Tandy 1000 se vendió razonablemente bien ningún otro compatible volvió a incluir este chip, y no se vendió ninguna tarjeta de sonido que lo tuviese.

En ambos casos este chip de sonido se podía programar escribiendo a la dirección C0h, modificando así sus registros. Estro contribuyó aún más a que su éxito fuera limitado, ya que a partir del IBM AT (1984, el tercer modelo de PC, después del PC y el XT) esa dirección de memoria estaba reservada para otros menesteres. Además pronto surgirían las tarjetas de audio propiamente dichas, pero con todo recibió soporte de algunos juegos interesantes, como King Quest (1984, Sierra On-Line) en el PCjr. Como veremos, los juegos de Roberta Williams fueron siempre punteros en las tecnologías del PC.

A principio de los 90, con la llegada de la línea PS/1 de IBM, se lanzó al mercado una tarjeta de sonido con capacidades sospechosamente similares al PCjr y el Tandy 1000. Fue llamada simplemente PS1-Audio, y tenía también tres voces y generador de ruido, con un sonido idéntico a lo escuchado en los dos ordenadores mencionados anteriormente. Además del sonido particular del SN parecía tener un DAC para sonido digital e incorporaba un puerto de joystick/MIDI. Desconozco la calidad de este audio digital, pero para cuando despegó ya existían alternativas mucho más interesantes.

Este humilde chulón sólo conoce un puñado de juegos que lo soportara, como una edición especial del Silpheed realizada por Sierra en 1990. Otro fue el King Quest 4 por la misma compañía y en el mismo año. Ambos soportaban las tres voces musicales y el DAC para los efectos de sonido.

Roland MPU-401

El que probablemente fue el primer periférico de audio profesional en PC fue el Midi Processing Unit 401, fabricado por Roland a partir de 1984. En realidad no proporcionada capacidades de audio al PC en absoluto, «sólo» comunicaciones en el estándar MIDI. Se fabricaron variantes para casi todos los sistemas, como el Commodore 64 o el MSX.

El estándar MIDI (Musical Instrument Digital Interface) establece un protocolo para comunicarse con instrumentos musicales, así como una norma para los conectores. Se creó en 1983 por un comité a propuesta de la empresa japonesa Roland, y permitía a partir de entonces que todos los instrumentos que la siguieran pudieran comunicarse y cooperar entre sí. Un aparato podía servir de secuenciador, otro de sintetizador, un tercero de caja de ritmos y así. El hecho de que un ordenador cumpliera con este estándar permitía usarlo como estación de trabajo, y a menudo se cita  como la razón hizo triunfar al Atari ST en el mundo de la producción profesional musical durante muchos años.

Volviendo al MPU-401 y al PC, existieron varias variantes, cada una con capacidades ligeramente distintas, incluso algunas tenían hardware adicional con sintetizadores MIDI populares. Básicamente consistía en una tarjeta de expansión con un enorme conector al que debíamos enchufar una caja externa con la mayoría del hardware. En ésta podíamos encontrar conectores MIDI IN (entrada), OUT (salida) y THRU (a través de), pudiendo enchufar cualquier instrumento o aparato que compartiera la norma MIDI. También tenía un conector de metrónomo y uno de sincronización de cinta.

Existieron dos modos de funcionamiento para este aparato: normal y UART (conexión de serie). El modo normal (también llamado modo inteligente) proporcionaba ocho pistas MIDI, metrónomo y sincronía para cinta. El modo UART era una conexión midi sin más, y era la que soportaban la mayoría de clones y hardware similar. El modo inteligente cayó en desuso en unos años, ya que era más sencillo implementar sus funciones con el propio PC.

Este hardware por sí solo no servía de gran cosa, ya que sólo servía para controlar otros aparatos. Si teníamos un módulo sintetizador o similar, no obstante, podíamos conseguir un sonido tan bueno como proporcionara nuestro cacharro. El modo UART era ampliamente soportado por los juegos, ya que era relativamente sencillo. Tan sólo escribir en el puerto 330h (300h en algunos casos) las notas y ya se encargaría de recibirlo lo que tuviéramos conectado. Como veremos, existieron algunos artilugios realmente notables que podían usar esta interfaz.

Covox Speech Thing y variantes

En 1986 apareció un aparatito muy sencillo que permitía al PC reproducir audio digital de 8 bit, y era tan fácil de instalar como conectarlo al puerto de impresora.

El funcionamiento de este aparatito era realmente sencillo, siendo una mera escalera de resistencias de valor creciente para las ocho salidas digitales del puerto de impresora. Para obtener un sonido más limpio algunas variantes usaron condensadores electrolíticos. Ni que decir tiene que, aunque no era un hardware caro (80 dólares) casi de inmediato surgieron clones baratísimos, incluso uno podía fabricarse uno con un poco de soldador y maña.

Su mayor virtud era también su mayor defecto. Al ser un dispositivo completamente pasivo todo quedaba bajo el control de la CPU. El sonido de 8 bits que salía podía tener la frecuencia que queramos, aunque la arquitectura de los puertos de impresora hacía difícil llegar a la calidad CD de 44,1 KHz. Además, la técnica requerida para hacerlo funcionar consumía muchísima CPU, ya que este aparato no tenía acceso a memoria ni buffer de ningún tipo. Era necesario escribir valores al puerto de impresora constantemente, y tanto esto como el control de los intervalos debía hacerse «a mano» por nuestro programa.

Una de las variantes más populares fue el Disney Sound Source, lanzado al mercado por la ubicua compañía del ratón Mickey a principios de los 90. Externamente se diferenciaba en que incluía su propio altavoz, alimentado por pilas, pero en sus tripas se hallaba una diferencia fundamental: se incorporó una pequeña memoria intermedia que hacía muchísimo más sencillo programarlo, requiriendo además mucho menos control por parte de la CPU. A cambio de esto, el sonido debía tener una frecuencia de muestreo que no era posible ajustar.

El Covox no tuvo mucha aceptación, aunque de nuevo los juegos de Digital Illusions CE daban un soporte bastante bueno, además de los trackers que hablamos en el apartado del PC-Speaker. Mejor suerte tuvo el Disney Sound Source, que recibió mejor soporte por parte de los creadores de juegos, empezando por las producciones de Roberta Williams. También existió un emulador por software del SN76489, que si disponíamos de una CPU decente dotaba del audio del PCjr (o del Tandy 1000) a algunos juegos. No obstante no tenía muy buena compatibilidad, y no muchos juegos podían usarlo sin más.

AdLib

Todo lo visto anterior se parecía poco a una tarjeta de sonido tal como lo conocemos, pero la canadiense AdLib Inc. lanzó en 1987 una exitosa tarjeta de sonido, la AdLib Music Synthesizer Card, conocida simplemente como AdLib. Con ella, el concepto de tarjeta de sonido para uso doméstico nace como tal.

Esta tarjeta proporcionaba síntesis de audio FM mediante el chip OPL2 de Yamaha, pero nada de sonido digital. Proporcionaba nueve voces, cada una con su envolvente ADSR con varias formas de onda y operadores distintos. La síntesis de audio por modulación de frecuencia es un poco más difícil que un simple generador de sonido programable, ya que intervienen varias ondas cuya frecuencia modula el sonido de la onda principal, que puede tener varias formas: cuadrada, sinusoidal, triangular, diente de sierra y alguna más. Efectivamente: es tan complicado como suena, e idear un sonido chulo es un verdadero infierno.

Y ya metidos en tecnicismos, ADSR parece una sigla super complicada pero no es más que «attack-decay-sustain-release», o «ataque-caída-sostenido-relajación». Son cuatro parámetros que definen el volumen de un instrumento en sus fases fundamentales, también llamado envolvente: el ataque (el inicio de la nota), tanto antes como después de ejecutarse, el volúmen al mantenerla y lo que tarda en desvanecerse. Es abstracto tratar de explicarlo con palabras, con un gráfico se entiende mucho mejor.

La tarjeta tuvo una gran acogida y fue ampliamente soportada en la mayoría de juegos de PC, estableciéndose como el primer gran estándar de sonido para la mayoría de aplicaciones domésticas. Obtuvo soporte durante toda la vida del MS-DOS, incluso algunos juegos de Windows (3.X fundamentalmente) funcionaban con ella. Sin embargo las ventas no acompañaron en los 90, dado que casi todas las tarjetas y clones posteriores disponían del mismo chip de Yamaha y, o bien eran más baratas, o bien añadían más características.

Ciertamente las capacidades de síntesis de audio de esta AdLib, que era poco más que un envoltorio para el OPL2, eran mucho más ricas y más que notables para 1987. Los juegos de PC podían contar con una música parecida a los famosos sintetizadores de Yamaha a un precio muy competitivo, unos 130 dólares. A partir de la popularización de los middleware, no obstante, la calidad de la música para AdLib de los juegos descendió, ya que la mayoría de las veces simplemente se usaba la tarjeta para tocar instrumentos General MIDI con una fuente de sonido dada por el programador de dicho middleware. Dado que no contaba con sonido digital, esta técnica era rápida pero con resultados pobres.

¿Qué era eso de General MIDI? Básicamente es una norma adicional al protocolo MIDI que exige hasta 24 voces simultáneas y 128 instrumentos definidos en el estándar. Surgió a partir de 1991, y desde entonces la mayoría de los sintetizadores de audio y tarjetas de sonido con capacidad MIDI cumplían esta especificación.

En 1992 la empresa comercializó un segundo modelo, la AdLib Gold 1000. En lugar del chip OPL2 contaba con el mejorado OPL3, que permitía más voces simultáneas y más formas de hacer sonidos diferentes, además de incluir un DAC de 12 bit. Por desgracia fue víctima del éxito de su hermana menor, y no vendió una escoba. Recibió soporte de algunos juegos destacados como Dune (Cryo, 1991), pero terminó llevando a la bancarrota al fabricante.

Roland MT-32

Una de mis superfavoritas, y las de muchos aficionados a los videojuegos. El  Roland MT-32 Multi-Timbre Sound Module, conocida simplemente como MT-32, se lanzó al mercado como un sintetizador MIDI asequible para músicos amateur, pero adquirió rápidamente una gran popularidad entre los jugadores de PC. Sólo podía usarse a través de conexiones MIDI, por lo que hacía falta una interfaz MPU-401 o un hardware con dicha funcionalidad.

El principio de operación del MT-32 se llamó LA, linear arithmetic (aritmética lineal).  Combinaba muestras digitales de instrumentos (instrumentos grabados) con síntesis de audio sustractiva, obteniendo voces de gran calidad sin gastar miles de dólares en cartuchos ROM y carísimos muestreadores de sonido. En su memoria se hallaban muchas muestras parciales de instrumentos que, combinadas con sonido sintético, filtros y DSP se generaba su banco de 128 instrumentos y 30 efectos de sonido y de batería. Este aparato no era exclusivo de PC, podía usarse en cualquier sistema que contara con una conexión MIDI, caso del ordenador X68000, de Sharp.

Este aparato no era compatible con el estándar General MIDI, que no apareció hasta cuatro años más tarde, por lo que Roland lo dotó de compatibilidad parcial vendiendo un añadido. No obstante, su uso en juegos se limitó mayormente a su equipamiento base, que costaba unos 700 dólares, precio al que había que añadir la interfaz MIDI, típicamente una MPU-401 que partía de los 550. Como instrumento musical era muy competitivo, pero como solución de audio para juegos era muy caro.

Su precio fue la razón de que, cuando aparecieron sistemas más baratos basados en wavetable (básicamente bancos de muestras digitales de instrumentos) acabó en desuso, no sin antes dejarnos alguna de las bandas sonoras de más calidad del PC. De nuevo, Sierra On-Line fue pionera en su uso, con juegos como King Quest IV en 1988. A principios de los 90 las mejores bandas sonoras estaban compuestas para este aparato: Monkey Island 2 (LucasArts, 1991), Dune II (Westwood Studios, 1992) y muchos otros.

Este sistema de audio carecía de sonido digitalizado, pero la mayoría de los juegos permitían usar en paralelo una tarjeta de sonido que sí tuviera esta capacidad, de modo que un jugador que estuviera en el taco (es decir, con unos bolsillos bien pertrechados) podía disfrutar del sonido digital y de la mejor música al mismo tiempo.

A medida de los años este aparato tomó diferentes formas, como la LAPC-I de 1989. En lugar de un módulo MIDI consistía en una tarjeta de expansión que aunaba las características de una interfaz MPU-401 y del MT-32, que sonaba de forma muy parecida pero era mucho más cómoda.

Otras tantas y variadas

A finales de los 80 existió todo un despliegue de tarjetas de diferentes características, precios y tiempos de vida. He tratado de detallar los más destacados, pero ni que decir tiene que hubo algunos otros que no vendieron un pimiento.

Una de estas tarjetas fue la primera creada por IBM. La única, si no contamos la del PS/1 que era más bien una expansión para ese sistema. Se trata de la IBM Music Feature Card, producida en 1987 con un diseño similar a la LAPC-I: una interfaz MIDI con un sintetizador, esta vez el YM2164 de Yamaha, usado en algunos sintetizadores de la época. Costaba 500 dolarinos, y no era mucho mejor que una AdLib. Fue enfocada al mercado semiprofesional, pero no encajó en ningún sector concreto y fue barrida por la competencia.

Este mismo año, Creative Technology Limited (conocida como Creative Labs en Estados Unidos) comenzó a comercializar su primera tarjeta de sonido: la Creative Music System. Consistía básicamente en dos chips Philips SAA1099, de características similares a los SN76489 pero superiores: estos generadores de sonido programables dotaban a nuestro PC de 12 voces estéreo, pudiendo usar cuatro de ellas como generadores de ruido. La popular cadena RadioShack la vendió como Game Blaster un año más tarde, y aunque su chip de audio estuvo soportado por cierta cantidad de juegos la tarjeta fue ensombrecida rápidamente por las siguientes creaciones de la empresa.

En 1989 una empresa llamada Innovation Computer Corporation desarrolló algo que, sobre el papel, les pareció buena idea. La SSI 2001 era una tarjeta de sonido que incluía el ya consagrado chip SID, del Commodore 64. La demoscene de este ordenador era popular, pero en el PC existían productos mucho mejores y sólo obtuvo soporte de un puñado de juegos. Al menos incluía un puerto de juegos para conectar nuestro joystick.

Finalmente, Sound Blaster

La creación más exitosa de Creative, y con mucho la línea más popular de tarjetas de sonido domésticas de la época, es sin duda Sound Blaster. La práctica totalidad de los juegos incluyó soporte para esta tarjeta, cuya primera versión data de 1989. Las razones de su éxito fueron un lanzamiento en el momento justo, unas características completamente enfocadas a los juegos de ordenador. Además, como la compatibilidad con la AdLib era perfecta, no había razón para no decantarse por la Sound Blaster.

La Sound Blaster, conocida como 1.0 a posteriori, era capaz de reproducir sonido digital mono de 8 bits muestreado (PCM y ADPCM) hasta 22 KHz. Además, podía grabar sonido mono de 8 bits hasta 11 KHz. Era retrocompatible también con la Game Blaster, de modo que podía usar sus chips SAA1099 para hacer sonar música, pero esta característica fue poco usada dado que también era compatible con la AdLib, al disponer también de un OPL2. Esta verdadera todo-en-uno se convirtió en un año en la tarjeta de expansión más vendida para PC. Además de todo, incluía un puerto de juegos y MIDI.

Un año más tarde, para abaratar costes, la tarjeta comenzó a venderse sin los chips SAA1099, aunque conservaba los huecos por si querías añadirlos más tarde. Esta versión fue conocida como 1.5 a posteriori.

En poco apareció la tercera revisión: Sound Blaster 2.0, en 1991.  La calidad del sonido aumentó hasta los 44 KHz, el puerto MIDI era ahora full-duplex (podía transmitir y recibir al mismo tiempo), y ahora el DMA soportaba la extensión «auto-init», lo cual permitía que fuera ahora totalmente compatible con Windows 3.X.

¿Por qué triunfó Sound Blaster en el mercado de tarjetas de sonido para juegos? Una de las razones es el uso de DMA, direct memory access (acceso directo a memoria). En la mayoría de dispositivos de hardware doméstico era necesario usar la CPU de forma síncrona con el dispositivo de audio, mandando la información en el momento preciso, gastando nuestro preciado tiempo de CPU. Gracias al DMA podemos indicar a la tarjeta de audio en qué sitio de la memoria está el sonido que tiene que reproducir, y ella sola se encargará de ir tomándolo cuando lo necesite. Naturalmente bajo la atenta mirada de la CPU, pero que ahora puede limitarse a enviar estas órdenes a la tarjeta de audio.

En el mismo 1991 fue lanzada al mercado un modelo distinto a los anteriores: la Sound Blaster Pro. Se aumentó la frecuencia máxima de muestreo de audio de salida a 44 KHz en mono (22KHz en estéreo), y se añadió un segundo chip OPL2, de modo que teníamos el doble de voces y encima en estéreo. Además esta tarjeta venía con un añadido más que bienvenido: una controladora de CD-ROM de interfaz Matsushita.

No tardó en salir una segunda revisión que sustituyó a la segunda, que cambió la pareja de OPL2 por un OPL3, de características mejoradas. Además, ahora era posible comprar la tarjeta con una controladora de CD-ROM para otros estándares, como Sony o Mitsumi. Esta tarjeta es una de las más clonadas de la época, y algunas tarjetas de sonido semiprofesionales incluían un emulador por software para poder usarlas en los juegos.

¿Cómo es eso de la controladora de CD-ROM de nosequé tipo? Antes de popularizarse el estándar ATAPI en los PCs, existieron diferentes estándares de unidades de CD-ROM. Incluso entonces este estándar convivió con el SCSI, de uso más profesional, por lo que a menudo era necesaria una tarjeta controladora extra si queríamos tener una unidad de CD-ROM. El hecho de que esta controladora estuviera integrada en nuestra tarjeta de sonido era un factor muy importante, pero tenía que ser la adecuada para nuestra unidad de CD-ROM. Cualquiera de estas unidades leía cualquier disco, eso sí.

En junio de 1992 llegó la que, para muchos, fue la tarjeta de sonido definitiva para juegos: Sound Blaster 16. Con todas las características de la Sound Blaster Pro 2.0, pero además su interfaz MIDI era ahora totalmente compatible con el MPU-401 UART.  Era posible adquirir una tarjeta hija para otorgarle capacidades wavetable, pero no fue una característica muy usada, ya que no era tan común en los juegos. Con todo, la característica estrella de este producto era otra: ¡Calidad de CD (44,1 KHz a 16 bit) tanto en reproducción como en grabación! Esto era otro mundo.

Las revisiones de la Sound Blaster 16 no añadieron ni quitaron nada, dada la tremenda popularidad de esta tarjeta de sonido. Tan sólo se rediseñó su factor de forma para incluirla en una placa base o para el mercado OEM, tomando el nombre de ViBRA 16. Nunca fue retrocompatible del todo con la Sound Blaster Pro en cuanto a sonido digital, pero sí en su sintetizador FM. De todas formas casi la totalidad de los programas a partir de 1992 soportaban ambos.

Windows Sound System

Era prácticamente imposible competir con las Sound Blaster, pues se había convertido en un estándar de facto. No había apenas lugar para la innovación, y desarrollar un estándar distinto era un suicidio porque nadie le daría soporte. Microsoft creó en 1992 una especificación con este nombre, de modo que cualquiera pudiera construir una tarjeta de sonido compatible con Windows 3.X y con cualquier programa que usara el estándar.

Existieron varios niveles de esta especificación, y el primero y más usado requería una calidad de sonido de 48KHz a 16 bit, y un OPL3 para síntesis musical. La Sound Blaster Pro cumplía con esta especificación, pero curiosamente no así la Sound Blaster 16. Cualquier tarjeta que se ajustara a la norma WSS, por chusquera que fuera, se podía usar en Windows y además emular una Sound Blaster Pro. Aunque hubo multitud de juegos que dieron soporte a este estándar en MS-DOS hubo algunos desarrolladores importantes, como Apogee, que no lo incluyeron en sus juegos. Tampoco lo soportó id Software, por lo que se quedó sin el imprescindible Doom (1993).

Este estándar quedó completamente obsoleto en 1997 con la introducción del AC97 de Intel, ideado mayormente para Windows. Nunca tuvo soporte para MS-DOS, aunque de todas formas para entonces la práctica totalidad de los desarrolladores se había centrado ya en Windows 95.

Gravis Ultrasound

El caso de la GUS es interesante. Cuando en 1992 todo el mundo compraba la Sound Blaster, esta compañía canadiense comenzó a vender esta tarjeta junto con el Gravis Gamepad, un mando para PC inspirado en el de la Super Nintendo. La razón no es otra que la de ofrecer una tarjeta con un diseño más parecido a las del ámbito profesional y a precio de derribo.

Esta tarjeta no tenía un DAC como el de la Sound Blaster, y tampoco incorporaba ningún chip de síntesis de audio por FM. En su lugar su hardware era un motor de síntesis de audio mediante muestras digitales, muy parecido si no igual que el concepto de wavetable. Tenía una memoria RAM dedicada en la que se cargaban los sonidos e instrumentos, y mediante su mezclador podía reproducir hasta 32 sonidos (hasta 14 en calidad CD). La calidad de reproducción era la misma que la de la Sound Blaster 16, 44 KHz y 16 bit en estéreo. No obstante, para grabación se requería una placa hija.

Diferentes revisiones de esta tarjeta proporcionaron más o menos memoria RAM, casi siempre actualizable mediante módulos SIMM de 30 contactos. Otras añadieron una controladora de CD-ROM o mezcla por hardware y grabación en calidad CD sin necesidad de placa hija. Una de las revisiones, la Gravis Ultrasound ACE, directamente eliminó todo lo accesorio y se comercializó como una tarjeta para usar en paralelo a las Sound Blaster.

Su funcionamiento hizo que el software de Amiga fuera relativamente fácil de traer al PC, ya que el manejo era similar, con la ventaja de la RAM dedicada. Los ya citados trackers y la demoscene también acogieron con entusiasmo las bondades de la GUS, ya que se podía trabajar en tiempo real en una música sin tener que invertir mucho dinero en una CPU potente.

El caso de los juegos fue complicado. Algunos de los lanzamientos más importantes, como Doom (id Software, 1993) dieron soporte nativo desde el primer momento, pero no todos los desarrolladores se subieron al carro. No ayudaba que no tuviera siquiera un chip OPL, y menos que no tuviera una interfaz MIDI de fábrica. Además, como es lógico, ningún juego de antes de otoño de 1992 daba soporte a esta tarjeta. Nada de esto era un problema para la producción musical pero, ¿cómo se exprimió su uso lúdico?

La respuesta estaba en la capacidad de las Gravis Ultrasound de imitar o emular otras tarjetas de sonido. De forma más o menos directa era capaz de emular un dispositivo General MIDI mediante un banco predeterminado de sonidos, así como imitar los instrumentos de un MT-32. Esto ya de por sí le daba soporte musical a la mayoría de los juegos de la época, pero el sonido digital seguía sin resolverse. Aparecieron algunos parches para juegos existentes o los que hubieran sido lanzados sin soporte para Gravis, pero dependíamos de que la revista de turno lo regalara con su CD, o tener acceso a Internet, lo cual era muy poco común antes de 1994. La respuesta llegó (más o menos) con el uso de emuladores.

IWSBOS y MegaEM fueron los dos programas más usados por los jugadores usuarios de Gravis. Estos permitían emular una Sound Blaster 2.0 y una AdLib, aumentando notablemente la cantidad de juegos que podían usarla. Esto no era ni mucho menos una solución completa, y dependía si un juego usaba un modo protegido, si requería memoria EMS, si necesitaba mucha memoria convencional… todo ello además echado a suertes ya que la compatibilidad era una lotería. Sólo la Gravis Ultrasound Extreme, de 1996, dio soporte por hardware a la emulación de Sound Blaster Pro, un poco tarde.

En todo caso, las Gravis Ultrasound proporcionaron un hardware estupendo para músicos amateur, costando no mucho más que una Sound Blaster. Si bien el soporte para juegos fue irregular era una forma de salirse del camino común. Su memoria de a bordo permitía mucha más variedad de sonido que los módulos MIDI, y al poder usarse de dispositivo General MIDI con sonidos cargados por nosotros teníamos una calidad musical en los juegos que la Sound Blaster ni soñaba sin su placa hija Wave Blaster.

Sound Blaster AWE32 y lo que te rondaré, morena

La Sound Blaster 16 era indiscutiblemente la tarjeta de sonido estrella para 1994, pero sus características más allá del sonido estéreo digital estaban más que estancadas. Creative Labs dio el paso con la AWE32, introduciendo muchas mejoras en la capacidad musical como memoria RAM dedicada, un procesador wavetable de 32 voces, un mezclador por hardware con  ecualizador integrado y un procesador de efectos digitales. El precio, eso sí, estaba acorde con todo lo ofrecido.

Ni que decir tiene que era perfectamente compatible con el sonido digital de la Sound Blaster 16, y que como también incluía el chip OPL3 lo era con la síntesis de audio FM de ésta y de la AdLib. Algunos modelos más baratos, no obstante, decidieron integrarlo en su procesador o simplemente no incluirlo y dar soporte mediante emulación. El sonido en este caso no era 100% el mismo, pero mantenía la compatibilidad. Por todo esto, a partir de su salida, estas tarjetas se consolidaron nuevamente como el estándar para uso doméstico, juegos sobre todo. Para los juegos antiguos se podían usar sus capacidades retrocompatibles, y los nuevos comenzaron a dar soporte en seguida.

Para un jugador de PC esta tarjeta aunaba todas las características deseables: funcionaba con todos los juegos y la música sonaba muchísimo mejor que una Sound Blaster 16, con soporte completo MPU-401 UART. Además fue una patada en sus partes a las Gravis Ultrasound, ya que se metía de lleno en su territorio gracias al chip EMU8000. Dotaba de síntesis wavetable de 32 voces usando su memoria RAM dedicada, que podía ampliarse en algunos modelos hasta unos increíbles (y carísimos) 32 megas. Curiosamente los populares trackers no dieron soporte directo a este increíble hardware (sí mediante compatibilidad Sound Blaster, por supuesto), tan sólo algunos reproductores especializados.

Los juegos que soportaban la AWE32 directamente ofrecían un sonido tremendo. No sólo por su sonido digital en calidad CD o su música compatible con General MIDI, también por sus efectos digitales como reverberación o flange. Además, como podíamos cargar en memoria instrumentos mediante el formato SoundFount, no todos los juegos tenían que sonar igual. Pese a todo, no hubo demasiado juegos que aprovecharan esta tarjeta, y la mayoría se limitó a usar el sonido digital heredado de la Sound Blaster 16 y reproducir música General MIDI de su banco de sonidos predeterminado.

Aunque la mayoría de las revisiones de la AWE32 consistieron en cambiar o quitar cosas (como la memoria disponible de fábrica, caso de la Sound Blaster 32), en 1996 se lanzó otro modelo que iba más allá de una simple revisión: la Sound Blaster AWE64. Las mejoras incluían un sonido más limpio gracias a una mayor relación de señal-ruído, un notable aumento de su polifonía (a 64 voces). El hardware era una ampliación de lo visto anteriormente, por lo que la compatibilidad estaba más que asegurada.

Las revisiones de la AWE64 fueron interesantes. La versión Gold nos acercaba al ámbito profesional al incluir un DAC profesional de 20 bits, así como salida por conectores RCA chapados en oro y una salida digital S/PDIF. La revisión Value, en cambio, se quedó sólo con lo concerniente al uso doméstico-lúdico a un precio muy competitivo, y aunque prácticamente no hubo soporte para AWE64 en los juegos era una forma más que asequible de jugar a los que soportaran AWE32 y compatibles, aunque sin posibilidad de ampliar la RAM. De todas formas, en AWE64 esto se volvió más difícil ya que se pasó del soporte de SIMMs estándar de 30 contactos a una memoria propietaria de Creative, más cara y difícil de encontrar. El dinero manda.

Las tarjetas profesionales: Turtle Beach

El mercado de tarjetas de audio para PC no estaba limitado a los juegos y las aplicaciones domésticas. Aunque a finales de los 80 y hasta bien entrados los 90 el vetusto Atari ST siguió siendo el rey de los estudios musicales (con los Macintosh a la zaga) los PCs también fueron una plataforma viable para la producción de audio profesional. Una de las casas más conocidas fue Turtle Beach, con una línea de tarjetas profesionales que empezó a venderse a partir de 1991.

El producto estrella de Turtle Beach en la era MS-DOS era la Multisound. La calidad de sonido de esta tarjeta estaba a otro nivel, que era naturalmente el uso en el ámbito profesional. Su corazón era un sintetizador profesional E-MU con hasta 4 MB de ROM, con capacidad de grabación en calidad estudio a 24 bit y entradas y salidas de sonido digital, todo ello en 1991, cuando la Sound Blaster se arrastraba para poder conseguir un sonido de 22 KHz mono en 8 bit. Incluso con la aparición de las AWE32 en 1994 seguían siendo competitivas, costando no mucho más que éstas por aquél entonces (alrededor de 400 dólares).

Naturalmente las aplicaciones de esta tarjeta eran muy especializadas, funcionando sólo con software específico. No eran en absoluto compatibles con el estándar de facto que era Sound Blaster, ni siquiera con MPU-401. La única forma de usarlas con juegos de la época MS-DOS fue a través de Windows NT, y sólo con un emulador tipo VDMsound, algo completamente desaconsejable y fuera del ámbito de este artículo. (además ocurrió mucho después)

Otros módulos y tarjetas General MIDI

Si bien todo el mundo estaba muy contento con las Sound Blaster, su calidad musical en juegos dejaba mucho que desear para los años 90. La solución era tener un MT-32, claro, pero eso requería un desembolso importantísimo. Además, al no cumplir la norma General MIDI no todos los juegos lo podrían usar correctamente o en absoluto.

El primer dispositivo destacable en este ámbito vino en 1991 y fue la Roland SC-55 (Sound Canvas), un módulo sintetizador MIDI que cumplió con General MIDI y con un nuevo estándar propietario de Roland, el General Standard, en el que al parecer se estrujaron bien el cerebro para darle nombre. Las bazas de este dispositivo eran notables: no sólo era compatible con General MIDI, haciendo funcionar muchos juegos de la época, sino también emulaba el MT-32 con su banco básico de sonidos. No sonaba igual, pero mantenía mucha calidad en los instrumentos y fue percibido como un sustituto bastante bueno. Una factor de forma popular en el PC fue la Roland SCC-1, con forma de tarjeta interna en lugar de módulo MIDI que ya incluía la funcionalidad del MPU-401.

No muchos juegos la soportaban directamente, aunque su compatibilidad con los estándares musicales de entonces hacía que funcionase razonablemente bien con programas que no estuvieran específicamente diseñados par ella. No obstante en 1993 el mismísimo Doom de id Sofware no sólo dio soporte específico, sino que su genial banda sonora metalera fue ideada para ser reproducida en este cacharro.

¿Dónde estaba Yamaha? Posiblemente trabajando en su estándar XG, eXtended General MIDI. En 1994 se lanzó el primer módulo que cumplía con esta norma, el MU80 Tone Generator. Superior al Sound Canvas y permitiendo mucha más variedad de modulación de los instrumentos, a lo largo de sus años fue vendiéndose como módulo MIDI o incluído en tarjetas de audio con capacidad de sonido digital.  Entramos no obstante en el pantanoso terreno del bus PCI, más moderno pero prácticamente incompatible con todas las tarjetas anteriores, que usaron el bus ISA. Durante muchos años, distintas versiones de Windows usaron un emulador de este estándar para dotar de sonido MIDI a su sistema operativo sin necesidad de un hardware de síntesis musical.

Los juegos de MS-DOS no se molestaron en dar soporte directo a las tarjetas y módulos XG, por lo que debía usarse simplemente como un módulo General MIDI controlado por una MPU-401 o compatible. El resultado era un sonido bastante bueno, pero que desaprovechó completamente las ingeniosas capacidades de este hardware.

Una cosa más (otras tarjetas interesantes)

Competir en la era de la Sound Blaster era más difícil que hacer gárgaras con polvos de talco. No obstante, a partir de que se popularizaran los middlewares y el software de Windows 3.X era medianamente posible ofrecer tarjetas alternativas.

Pro Audio Spectrum

Esta familia de tarjetas fabricadas por Mediavision comenzó su andadura en 1991, con la PAS original. Ofrecían compatibilidad con AdLib al incluir una pareja de chip OPL2 en su configuración, así como audio digital totalmente incompatible con el «estándar» Sound Blaster. También incluía una controladora de CD-ROM, pudiendo adquirirse modelos con diferentes estándares. Su sonido era de 8 bits, y no llegó a cuajar durando sólo un año, en el que fue sustituida por su sucesora.

Hoy es una tarjeta difícil de encontrar, con escasa literatura al respecto, aunque con soporte moderado en juegos ya que el driver las usaba igual. Existió una revisión que usaba un puerto ISA de 16 bits, que sustituía la parte de síntesis FM por un chip OPL3, pudiendo igualmente reproducir sonido a de 16 bit. Fue conocida como Pro Audio Spectrum Plus. Ambas tarjetas además podían emular el módulo MPU-401 en su conector para joysticks.

Al año siguiente aparece la Pro Audio Spectrum 16, hoy día más común y con características interesantes: sonido digital estéreo de 16 bits en calidad CD, similar al ofreció la Sound Blaster 16 en ese mismo año. Para los amantes de los juegos que no querían perderse nada incluyó compatibilidad completa a nivel de hardware con la Sound Blaster 1.5, de modo que ahora podía usarse con prácticamente todos los juegos del mercado, eso sí con una calidad inferior de sonido si no se incluía soporte para la PAS16. Estas características le permitieron venderse moderadamente bien y obtener soporte para la mayoría de juegos que usaran un middleware mayoritario.

Thunder Board

Además de la Pro Audio Spectrum la empresa Mediavision comercializó otra tarjeta más, sin relación con las PAS. ¿Qué razón habría para arriesgarse dos veces en este mercado? Bueno, no del todo: Thunder Board es un clon de Sound Blaster 1.5, pero a precio de estudiante.

Con ella se podía hacer lo mismo que con el producto de Creative con mucho menos dinero, y aunque en 1992 existían mejores tarjetas, la Thunder Board se erigió como una alternativa para gente tiesa de parné. Es más, en plena vorágine ahorradora se sacaron de la manga un producto muy singular: la Thunder and Lightning, que no incluyó mejoras en sus circuitos de sonido. Incluyó… ¡una tarjeta gráfica SuperVGA!

Es verdad que construir un PC era más barato gracias a estos dispositivos, pero uno se pregunta si es una buena idea acercar tanto los circuitos de audio y vídeo. No se ha podido encontrar más información.

Soundman Wave

En el mercado de producción amateur ya teníamos las Gravis Ultrasound, y un año más tarde apareció esta creación de Logitech. Un producto a caballo entre el hardware orientado a juegos y el sonido dirigido a pequeños estudios domésticos. Sus características no estaban nada mal para 1993: sonido en calidad CD tanto en reproducción como en grabación, controladora de CD-ROM y algo muy interesante: un chip OPL4 en lugar de los comunes OPL3. Además de las características de síntesis FM presentes en casi todas las tarjetas tenía capacidades wavetable, cuyo banco se hallaba en una memoria ROM de 2 megas.

Esta tarjeta tenía, sin embargo, dos problemas. Primero que, aunque era compatible con las Sound Blaster Pro, fallaba más que la Esteban en Cifras y Letras. O bien sonaba demasiado agudo, o no funcionaba uno de los canales o no sonaba en absoluto. Al final, a pesar de lo que aseguraba el fabricante, había que usar la compatibilidad con Sound Blaster 1.5, y el soporte nativo en juegos fue muy escaso. El segundo problema me duele más aún: al no tener memoria RAM a bordo el sonido wavetable se limitaba a los bancos proporcionados por su, por otro lado «enorme» ROM.

El fin de la edad de oro de MS-DOS

MS-DOS y sus derivados (PC-DOS, DR-DOS, 4DOS, etc) comenzaron como una interpretación sui géneris de CP/M, y se mantuvieron tremendamente obsoletos la mayor parte del tiempo en que permanecieron en activo. Tan sólo la omnipresencia de la arquitectura PC, la cantidad de software y hardware disponible y la facilidad de comercializar PCs clónicos hizo posible que viviera tanto tiempo. Pero la segunda mitad de los años 90 vio su reino caer, y con él la forma en la que entendíamos las tarjetas de sonido.

Con la aparición de Windows 95 por fin los desarrolladores comenzaron a abandonar MS-DOS, y gracias a su modelo de drivers era posible utilizar prácticamente cualquier tarjeta de sonido en todos los programas. Al no ser necesario que un programa diera soporte específico las tornas cambiaron. Además el bus ISA fue reemplazado progresivamente por el PCI, y el hecho de que los juegos sólo fueran capaces de manejar el primero creó un importante cisma en la tecnología de las tarjetas de audio.

El bus ISA estuvo presente desde la primera hornada de PCs, y con él era posible escribir en la memoria o usar los recursos del ordenador mediante interrupciones por software o canales discretos. Con PCI se pasa a un modelo de arbitrador de bus, más avanzado tecnológicamente pero totalmente diferente, y el soporte se limitó en la práctica a sistemas Windows o, como mucho y durante un tiempo, un driver que proporcionase compatibilidad ISA para juegos diseñados para MS-DOS. Dado que Windows 98 terminó por incluir compatibilidad por software con Sound Blaster, era posible usar casi cualquier tarjeta de sonido, por lo que se acabó dando la puntilla a la hegemonía de Creative.

Tras la parrafada

Dado el (muy) relativo éxito de mi artículo sobre los chips de sonidos más importantes de los videojuegos me decidí a hacer uno centrado en la era MS-DOS. Provoca menos nostalgia fácil, entre otras cosas porque no hay juegos de Nintendo o similares y a veces manejar y configurar estas máquinas era un soberano coñazo.

Lo de que prometía ser breve era broma, naturalmente. Se podrían escribir libros tan sólo de la AdLib, y podría haberme extendido en la historia del PC hasta haber caído rendido. He tratado, eso sí, de condensar lo más importante del mundo de las tarjetas de sonido sin dejar técnicas y tecnicismos sin explicar. Me he limitado a la era MS-DOS, aparte de por ser la que más interés me suscita porque se trata de una época con una idiosincrasia única, que por suerte o por desgracia me tocó vivir.

No me despido sin antes agradecer a mis amigos del sonido, que me han acompañado en esta larguísima disertación:

• La interrupción inquieta
• El sonido hiriente
• La enana en frecuencia modulada
• El enchufe sátiro
• Don MIDI In y don MIDI Out
• La compatibilidad loca
• El señor Kilohertzio
• El TSR morsegón
• La tarjeta humana
• Por último, don Hace Falta Más Memoria Convencional

Ni que decir tiene que comentarios o correcciones son más que bienvenidos, y si alguien quiere aportar sus bandas sonoras favoritas para estos importantísimos aparatos estaré encantado de leerlo.

La entrada La edad de oro de las tarjetas de sonido se publicó primero en Detrás del último no va nadie.

Entre los circuitos que han hecho posible el aspecto sonoro del entretenimiento digital se cuentan algunos realmente notables. Por las melodías que se han compuesto, por su impacto en la cultura, por sus capacidades o simplemente por el salto que han supuesto. Como buen aficionado a hacer listas chorra, voy a enumerar los que, a mi juicio, son más interesantes y merecen ser recordados.

Los albores del sonido

Los primeros computadores, enormes máquinas dedicados a investigación y cálculos militares, eran esencialmente mudos. Algunos daban algún que otro pitido, pero en 1961 llegó un paso de gigante y oímos al IBM 7094 no sólo tocar música, sino cantar. No fue sin embargo hasta 1971 que por fin aparecieron los videojuegos comerciales con Spacewar! (Steve Rusel), que incluía entre sus circuitos algunos generadores de ruido para amenizar el programa.

Tras esto, recordemos que se comenzaron a comercializar las consolas (empezando por la Magnavox Odyssey en 1972) que o bien eran mudas o con un sencillo buzzer como audio. En 1977 Atari lanzó al mercado su VCS, conocida más tarde como Atari 2600. Entre sus tripas encontramos el chip TIA, creado por el tito Jay Miner más tarde mejorado en sus ordenadores Atari 400 y 800.

Cualquiera que haya tenido una recordará su sonido crudo y desafinado. Tenía una salida mono, con dos osciladores con varios modos, cada uno con 32 niveles de tono y 16 de volumen. Era un generador de sonido programable (PSG) bastante pobre, pero fue uno de los primeros en ser reconocibles, fabricado en grandísimas cantidades y con varias revisiones. En los 80 derivó en el chip POKEY, usado en arcades famosos como Tetris (Atari, 1988) o incluido en algunos cartuchos de consola para ampliar sus capacidades de audio.

TIA, POKEY y muchos otros no eran un hardware dedicado realmente. Estos chips normalmente cumplían varios propósitos, como generar señales de video, caso del TIA; o servir de muestreador de potenciómetros y otras señales analógicas, caso del POKEY.

Texas Instruments SN

Uno de los primeros chips dedicados al audio que pudimos ver en un porrón de consolas fueron los de la familia SN de Texas Instruments. Nacidos a principios de los 80, estos chips contaban con unas características modestas: tres generadores de onda cuadrada y uno de ruido blanco, pero esta vez era más fácil modular el tono y el volumen.

La lista de sistemas que usan los SN es muy grande: Game Gear, Master System, Mega Drive, Sega SG-1000, Tandy 1000, IBM PCjr, Coleco Adam, BBC Micro, NeoGeo Pocket, multitud de recreativas… y muchos otros. Las consolas de SEGA, salvo la SG-1000, integraron este chip en sus procesadores de audio/vídeo. Se usaron en tantos sitios que fue uno de los sonidos más reconocibles de los 80, aunque era fácil confundirlo con su competidor directo: el General Instrument AY.

General Instrument AY

Este chip de audio nació un par de años antes que los SN, su competidor directo. Sus características son calcadas: tres osciladores de onda cuadrada y un canal de ruído.  No obstante, y aunque no es una característica para la que fue diseñado, es posible reproducir sonido digital PCM mediante técnicas por software, con un alto consumo de CPU. Además, al ser sus registros de mayor tamaño, era posible ajustar de forma más fina las frecuencias y otras características del audio de salida.

Las principales plataformas que usaron chips AY para reproducir sonido fueron el Amstrad CPC, Intellivision, Vectrex y Atari ST. Caso de este último todo un pesar de sus usuarios al ser comparado con las capacidades de audio del Amiga. 

Yamaha YM (OP)

La familia YM de Yamaha es variopinta y prolífica, y se ha usado en multitud de ordenadores y consolas, entre ellos multitud de tarjetas de sonido de principios de los 90. En general se trata de chips con capacidad de síntesis de audio modulado por frecuencia y varios canales PCM o ADPCM.

La serie OPL fue usada en cartuchos de expansión para ordenadores como el Commodore 64 y los MSX, pero sobre todo en las tarjetas de sonido para PC. Comenzando con la AdLib, y luego en casi todas las Sound Blaster de Creative Labs desde finales de los 80 a mediados de los 90. Caso de esta última acompañando a uno o varios DAC, pero conservando el sonido característico de los sintetizadores FM de Yamaha. De hecho, la gran mayoría de juegos de PC de esta época daban soporte a estos chips para reproducir música en sus juegos.

La familia OPN, en cambio, fue usada mayoritariamente en consolas de videojuegos,  aunque también en ordenadores japoneses de NEC, conocida como PC-88. También fue usada en alguno de los teclados de la época, con compatibilidad parcial con alguno de sus modelos más altos de gama, como la serie DX de Yamaha. El uso principal, no obstante, fue en consolas de videojuegos como la Mega Drive o la NeoGeo. En caso de la consola de SEGA con un sólo canal PCM y en el de la de SNK con varios ADPCM.

Otros sistemas se apoyaron en el audio digital, pero en la Mega Drive, así como en arcades de SEGA de 16 bit, se apostó fuerte por la síntesis FM en su chip Yamaha YM2612. Esto hizo que los sonidos de los juegos fueran menos realistas, pero que la música sonara como un sintetizador propiamente dicho. En las manos apropiadas se hicieron auténticas virguerías.

El resto de sus chips, con denominaciones mucho más variadas (OPN, OPP, OPZ, RYP4, PCMD8, SCSP…) fueron usadas en consolas como la Sega Saturn, pero la mayoría eran el corazón de sus famosos teclados y cajas de ritmos.

SPC700

La Super Nintendo era un sistema muy capaz en el aspecto sonoro. Esto era debido a un subsistema de audio particularmente bien diseñado y potente, el S-SMP. Este sistema incluía un DAC, una memoria SRAM de 64KB, una ROM de 64 bytes, un DSP y el chip SPC700, cerebro del sistema de audio. Fue diseñado por el ingeniero Ken Kutaragi, conocido por ser el padre de PlayStation.

Al contrario de muchos chips contemporáneos no se trataba de un generador programable de sonido, ni un sintetizador FM: era todo un motor wavetable de 8 canales digitales de 16 bit y 32KHz. Además se trataba de todo un sistema programable, ejecutando estos programas desde su memoria estática. El SPC no era capaz de leer la memoria RAM de la Super Nintendo, pero era posible transferir de la RAM principal a la SRAM del sistema de audio mediante la CPU, de modo que algunos juegos aprovecharon esto para intercambiar samples al vuelo y superar la barrera de los 64K.

En plena guerra de las consolas de 4ª generación el SPC700 supuso uno de los grandes argumentos a favor para la SNES. Con sólo un canal digital la Mega Drive difícilmente podía ofrecer efectos sonoros convincentes e instrumentos como baterías al mismo tiempo, algo que la Super Nintendo manejaba con solvencia. Al coste, eso sí, de no tener una síntesis de audio real, por lo que muchas veces 64Kb de SRAM se quedaban muy cortos para sonidos más largos, modulados o dinámicos.

APU

1983 eran unos tiempos convulsos para la industria de los videojuegos. Nintendo entonces hizo una gran apuesta con su NES, entre ellas encargar a Ricoh un chip de audio programable a un precio muy competitivo, y unas características superiores al AY y al SN. Cinco osciladores de ondas triangulares, sinusoidales y cuadradas, un generador de ruido y un canal en el que era posible reproducir audio PCM. Al no tener un canal DMA moderno era necesario el uso activo del procesador, cuando se reproducía audio de esta manera no era posible hacer mucho más.

Al principio, Ricoh era reticente a proporcionar estos chips al precio que Nintendo quería, pero tras la promesa de comprar grandes cantidades aceptaron con acierto, ya que se venderían muchísimos millones de consolas. Así nació el 2A03, designación comercial del Audio Processing Unit. (Por si el intrépido lector no se ha dado cuenta, APU no tiene nada que ver con Los Simpsons)

Aunque la Master System era un sistema más potente la consola de Nintendo se llevó el gato al agua, y hoy muchas personas identifican el particular sonido de su APU como el de la estética 8 bit. Además resulta evidente las capacidades superiores de este chip, más moderno y más enfocado a videojuegos.

Paula

Llegados a la época de los Amiga, éstos no tenían rival en cuanto a capacidades multimedia. En 1985 competía incluso contra maquinaria musical profesional, gracias a sus increíbles capacidades de audio. Gracias a una arquitectura orientada a multimedia y, por supuesto, de un chip llamado Paula.

Este chip era encargado de controlar la disquetera, las comunicaciones del puerto paralelo y por supuesto del audio. Sus capacidades eran asombrosas para la época: cuatro canales digitales de 8 bit o dos de 14 bit controlados por DMA. Gracias a este hardware comenzó la popularidad de los ficheros mod, que aprovechaban todas las características de audio del sistema.

El funcionamiento de este chip era más parecido a las tarjetas de sonido modernas que a lo visto hasta ahora. En lugar de que la CPU tuviera que ir mandando información al procesador de audio, sencillamente se le decía al chip Paula dónde estaba almacenado el sonido en la RAM, cómo queríamos reproducirlo y a qué volumen, cuándo parar… y él solito hacía su trabajo. Gracias a ello teníamos disponible la CPU completa para los juegos mientras sonaba música digital multicanal que barría a todo lo visto hasta entonces.

Otra característica de este chip, aunque poco usada, era usar un canal como modulador de otro, permitiendo una rudimentaria síntesis de audio modulado por frecuencia o filtrando los canales digitales, pero no fue muy utilizado porque sus resultados no eran tan impresionantes. Sí que se usó mas la mezcla por software, popularizándose los reproductores de audio de 8 canales digitales, pero consumía tanta CPU que no era práctico hacerlo en mitad de un juego.

SID

Para el final, y como siempre, mi superfavorito. El Sound Interface Device, más conocido como SID, es el chip de audio del ordenador más vendido de todos los tiempos: el Commodore 64. No es un sofisticado reproductor de audio digital ni nada de eso, sino un humilde sintetizador de audio programable mono de tres voces que sonaba como el diablo. Se le considera uno de los artífices de que en este ordenador naciera la demoscene.

Cada una de las tres voces tiene su propio oscilador programable, con curva ADSR (attack-decay-sustain-release) independiente y también puede controlarse con la CPU directamente.  También incluye partes analógicas externas como filtros de paso bajo, de ranura y de anillo independientes en cada canal, lo cual lo convierte en un verdadero sintetizador de audio moderno, todo en 1982 e incluido en un ordenador de precio más que competitivo.

Este chip, además, tiene más trampas que una película de chinos. Por ejemplo, resulta que al modificar uno de los registros a la frecuencia adecuada es posible reproducir sonidos digitales, a baja resolución, eso sí. Lamentablemente esto no estaba contemplado en el diseño, y fue «corregido» en la segunda revisión del chip haciéndolo casi inaudible. Por fortuna también era posible programar esta segunda versión de una forma particular para hacerlo reproducir audio digital, bajo coste de perder una de las tres voces.

En el papel este chip no parece gran cosa, y de hecho en los primeros años no fue explotado como se mereció. A lo largo de los años, autores como Jeroen Tel o Ron Hubbard exprimieron el potencial del SID en los juegos dotándolos de unas de las músicas más memorables de la época. La demoscene hizo el resto, sacando un sonido que rivalizaría con sintetizadores profesionales. Todo ello contribuyó a que incluso hoy día se le considere un sonido de culto, y aún sea muy valorado entre músicos y coleccionistas. También ayuda que sea una de las partes más delicadas del ordenador, requiriendo una línea de 12V AC (9 en el segundo modelo) dedicada y jodiéndose a la primera de cambio si la fuente de alimentación no hacía bien su trabajo.

El autor de este chip fundó la empresa Ensoniq, dedicándose a la fabricación de teclados sintetizadores. El segundo de ellos, el ESQ-1, fue lo que sus autores quisieron haber hecho del SID.

Alguno que otro más

Fue muy interesante que la PC-Engine, una modesta consola de 8 bits, tuviera unas capacidades gráficas y sonoras tan interesantes en 1987. Gracias a su CPU (que hacía el trabajo de audio también) poseía unas capacidades de audio muy buenas, mezcla de síntesis PSG y wavetable. Teniendo en cuenta el alcance de esta consola de 8 bits es para quitarse el sombrero.

En PlayStation pudimos oír audio digital de CD, pero no hay que olvidar el trabajo de PSU, Playstation Sound Unit. Este chip permitió 24 canales de audio digital ADPCM en calidad CD y música MIDI. Sí, el audio CD estaba muy bien, pero seguro que recuerdas las músicas de los Final Fantasy y similares… aquí Nintendo y su poderosa CPU de 64 bits no tuvieron mucho que hacer. PlayStation 2 incorporaba una mejora de este chip con más canales, más calidad, más efectos… y en fin, más de todo.

Sí que fue un gran contendiente el YMF295 de Sega Saturn, que permitía esto y más: síntesis FM, filtros mediante DSP, y una RAM dedicada. Todo ello además de un microprocesador Motorola 68EC000 para liberar a la CPU del trabajo. Por desgracia este complejo conjunto de tecnología no tenía capacidad de descomprimir audio.

Notas finales

En el mundo de la síntesis de audio ocurre algo curioso. Me encanta el sonido cálido de los sintetizadores analógicos antiguos como el Minimoog, y el poderío de los modernos sintetizadores digitales actuales. No obstante, de los 80 a los 90 tenemos un vacío de música pop mediocre. Pese a esto, una de mis aficiones es la música de los videojuegos de esta época, usando precisamente esa clase de tecnología.

Bueno, esto puede haber ayudado a que el estereotipo de música de videojuego (al menos de los clásicos) sea el de melodías muy pasadas de moda, o directamente pueriles. Pero los jugadores veteranos estaremos de acuerdo en que son una parte inseparable de la cultura digital.

No he querido entrar en el tema de las tarjetas de audio (Sound Blaster, Covox Speech Thing, etc) o de sistemas de propósito general dedicados al audio (MT-32) ya que no serían chips de audio propiamente dichos, pero sí que merecen un artículo largo y tendido. Tendrá que ser en otra ocasión.

He tratado de reunir y describir los mejores ejemplos (y los que más me gustan) de chips que dieron forma al sonido de los videojuegos en su mejor época, aunque reconozco que es raro hacerlo de una forma tan técnica. Quizá un día me anime y escriba algo sobre esta jerigonza de siglas y tecnologías incomprensibles. Oh, por supuesto aquí faltan muchísimos chips de todas las formas, colores y sabores, pero eso lo dejo de deberes.

La entrada Los chips de sonido que dieron forma a los videojuegos se publicó primero en Detrás del último no va nadie.

La tecnología tras esta demo no es inaudita. Sí que es cierto que el uso del rotoscope es muy interesante, pero por lo demás pasaría inadvertida. Sin embargo es atrevidamente rompedora en algo: fue una de las primeras demos que incorporaba una temática generalista, techno concretamente. Era una de las primeras demos que podías mostrar a una persona que no perteneciera al círculo de los raritos esos con el ordenador y que exclamara: «¡Qué guapo, tío!»

En su tiempo la demo recibió críticas muy duras por parte de la comunidad de demoscene. A la mayoría de los grupos no les agradaba la intrusión mainstream en su mundillo, y menos con música de malotes. También hay que decir que generó mucha envidia, ya que fue una demo que se llevaba todas las miradas, y no hay grupo de la demoscene que no desee eso. ¡Hasta salió en la MTV! Ni que decir tiene que los fanáticos de Atari se tiraban de los pelos con esto.

El núcleo duro de la escena puede seguir diciendo hoy día que no es más que no es más que un videoclip de música pop, pero una gran mayoría de los aficionados al mundillo tiene una gran impresión de esta demo. Las razones son más que obvias: es ver esta demo y parece que fueran a entrar Michael Jordan a hacer un mate en la habitación y el príncipe de Bel-Air a cantar rap. Más de los 90 imposible, con claras inspiraciones en artistas del momento como Technotronic.

Lejos de dormirse en los laureles, los artistas produjeron al año siguiente otra demo muy similar, 9 Fingers. Menos conocida, al carecer del impacto de la primera, pero no deja de ser una secuela algo más refinada. Aunque la música (que pudo oírse por adelantado) gustó mucho, la opinión de la demoscene seguía siendo hostil, al no representar mejoras técnicas apreciables desde State of the Art.

Hace unos años un payo subió el video del making of,  en el que pueden verse las escenas originales de las que se tomaron los bailecitos de las mozas.

Pasados ya más de ¡¡25 años!! de esta demo, en retrospectiva se le considera una de las más destacas producciones jamás hechas. No han faltado homenajes, y en 2015 el veterano grupo Fairlight presentó en la party Revision una demo con la que ganó en la categoría de PC: Ziphead.

No se trata de una segunda parte y carece de oficialidad, claro, pero los paralelismos están claro. La estética del momento, la música techno machacona, el texto imperativo centrado en pantalla… y los bailecitos, que en esta ocasión no son rotoscope sino renders en tiempo real en 3D. Más oscura, pero trae una estética mainstream de una forma muy similar.

Curiosamente, esta demo ha recibido críticas de los sectores conservadores muy similares a los que ya recibió State of the Art en su día: que sólo es un videoclip comercial, música mainstream típica de la guerra del volumen, sólo artificio y nada de técnica… mientras alaban a la original. Parece que hasta en los sectores más eruditos no sobra la memoria o el criterio. Los aficionados menos puristas, no obstante, estuvieron encantados con esta demo, y muchos no dudan en catalogarla como State of the Art de 2015.

En resolución, hay un par de cosas que podemos sacar en claro: lo que para los puristas hoy es una caca comercial, mañana puede ser un clásico. Lo otro es, por supuesto, que la nostalgia vende, incluso a mí.

La entrada State of the Art: recuerdos se publicó primero en Detrás del último no va nadie.

Existieron versiones en un mogollón de plataformas, desde el Macintosh (la original) hasta GameBoy Advance, pero mi favorita es la de MS-DOS y es sobre la que trata este artículo. Hay dos ficheros interesantes: el ejecutable (SC2000.EXE) y el fichero de datos (SC2000.DAT). Lamentablemente, la versión de Windows no salió en español, y la versión Network Edition que permitía juego en red funciona fatal (y también está sólo en inglés).

SC2000.EXE

El ejecutable del juego no parece contener muchos recursos, pero sí que tiene algunos textos de la interfaz. En el editor hexadecimal se pueden ver algunas etiquetas de ancho fijo.

También hay algunos de ancho variable que corresponden a más etiquetas de la interfaz. También parece haber algunos ficheros empotrados, en los que por ejemplo se describen los escenarios del juego.

Por ahora desemsamblar un ejecutable de hace cerca de 25 años no está entre mis especialidades, por lo que no he averiguado gran cosa. Los punteros no son evidentes en el ejecutable, por lo que dejado ahí. Pero la chicha está en el fichero de datos.

SC2000.dat

Este es el principal fichero de datos del juego. No tiene cabecera, pero un vistacillo en el editor hexadecimal arroja bastantes pistas sobre su estructura.

Resulta que desde el byte 0, lo primero que nos encontramos son bloques de 16 bytes que describen los ficheros contenidos en el paquete. El primer campo es evidente: son 12 bytes con el nombre del archivo (8 + 3 caracteres de los ficheros de MS-DOS más el punto). Si sobran caracteres, el resto de bytes son 00h.

Los cuatro restantes no tanto, pero resulta que el juego es original de Macintosh, que en aquella época usaba procesadores Motorola. Estos procesadores, a diferencia de los Intel, son Little-Endian (siendo Big-Endian los de Intel). Esto significa que los números de más de un byte se guardan ordenados del byte menos significativo al más significativo, en lugar del ordenamiento «natural». Se trata, pues, de un entero de 32 bits sin signo en formato Little-Endian en el que se codifica el offset (desplazamiento) del fichero cuyo nombre está justo antes.

La idea feliz sobre el offset se la debo a Brett Lajzer, un ingeniero de software de Albany que empezó antes que yo a investigar este fichero. Le escribí para intercambiar información y me advirtió sobre este punto, que no llegó a describir en su artículo.

El desempaquetamiento y empaquetamiento, sabido esto, resulta relativamente sencillo. He escrito un pequeño programa en Java que realiza esta operación:

package sce2000;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

import org.apache.commons.io.FileUtils;

public class Sce2000 {
	
	public static final String SC2000DAT = "G:\\dos\\sce2000\\sc2000.dat";
	public static final int NUMFILES = 399;
	
	public static class Filestrut implements Serializable {
		private static final long serialVersionUID = 1L;
		public String filename;
		public int offset;
		public int targetOffset;
	}

	public static void main(String[] args) throws IOException, ClassNotFoundException {
		
		if (args.length == 0) {
			info();
		} else if ("x".equals(args[0])) {
			extract();
		} else if ("c".equals(args[0])) {
			create();
		} else {
			info();
		}

	}
	
	public static void info() {
		System.out.println("Usage: x to eXtract or c to Create (after eXtract) + sc2000.dat file");
	}

	public static void create() throws IOException, ClassNotFoundException {
		
		File sc2000dat = new File(SC2000DAT);
		File metafile = new File(SC2000DAT + "!/meta");
		ObjectInputStream ois = new ObjectInputStream(new FileInputStream(metafile));
		List<Filestrut> files = (List<Filestrut>) ois.readObject();
		
		List<Byte> targetFile = new ArrayList<Byte>();

		for (Filestrut file : files) {
			byte[] fileNameBytes = file.filename.getBytes(StandardCharsets.US_ASCII);
			for (Byte myByte : fileNameBytes) {
				targetFile.add(myByte);
			}
			for (int i = 0; i < 16 - fileNameBytes.length; i++) {
				targetFile.add((byte) 0);
			}
			//sourceFile.length();
		}
		
		int i = 0;
		for (Filestrut file : files) {
			byte[] binary = Files.readAllBytes(Paths.get(SC2000DAT + "!/" + file.filename));
			int fileOffset = targetFile.size();
			for (Byte myByte : binary) {
				targetFile.add(myByte);
			}
			int filePointer = 12 + (16 * i);
			
			byte[] offsetBytes = fromInt(fileOffset);
			targetFile.set(filePointer, offsetBytes[0]);
			targetFile.set(filePointer + 1, offsetBytes[1]);
			targetFile.set(filePointer + 2, offsetBytes[2]);
			targetFile.set(filePointer + 3, offsetBytes[3]);
			
			i++;
		}
		
		byte[] binaryFile = new byte[targetFile.size()];
		for (i = 0; i < targetFile.size(); i++) {
			binaryFile[i] = targetFile.get(i);
		}
		
		FileUtils.writeByteArrayToFile(sc2000dat, binaryFile);

		
		System.out.println();
		
	}
		

	public static void extract() throws IOException {
		
		Path sc2000dat = Paths.get(SC2000DAT);
		byte[] data = Files.readAllBytes(sc2000dat);
		
		int vector = 0;
		List<Filestrut> files = new ArrayList<Filestrut>();
		for (int i = 0; i < NUMFILES; i++) {
			
			Filestrut currfile = new Filestrut();
			
			currfile.filename =  convertFilename(Arrays.copyOfRange(data, vector, vector + 12));
			vector += 12;
			
			currfile.offset = fromByteArray(Arrays.copyOfRange(data, vector, vector + 4));
			vector += 4;
			
			System.out.println("Found file " + currfile.filename + " at " + currfile.offset);
			
			files.add(currfile);
			
		}
		
		File dir = new File(SC2000DAT + "!");
		if (dir.exists()) {
			FileUtils.deleteDirectory(dir);
		}
		
		dir.mkdir();
		
		Iterator<Filestrut> fileIt = files.iterator();
		
		Filestrut file = fileIt.next();
		Filestrut fileNext = null;
		
		boolean stop = false;
		while (!stop) {
			
			File extracted = new File(SC2000DAT + "!/" + file.filename);
			
			int init = file.offset;
			int end = -1;
			if (fileIt.hasNext()) {
				fileNext = fileIt.next();
				end = fileNext.offset;
			} else {
				end = data.length;
				stop = true;
			}

			System.out.println("Writing: " + extracted.getAbsolutePath());
			FileUtils.writeByteArrayToFile(extracted, Arrays.copyOfRange(data, init, end));
			
			file = fileNext;
			
		}
		
		File metafile = new File(SC2000DAT + "!/meta");
		
		ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(metafile));
		oos.writeObject(files);
		oos.close();
		
		System.out.println("OK!");
	}
	
	public static byte[] fromInt(int number) {
		byte[] bytes = ByteBuffer.allocate(4).putInt(number).array();
		swapEndianess(bytes);
		return bytes;
	}
	
	public static void swapEndianess(byte [] bytes) {
		byte temp1 = bytes[0];
		byte temp2 = bytes[1];
		bytes[0] = bytes[3];
		bytes[1] = bytes[2];
		bytes[2] = temp2;
		bytes[3] = temp1;
	}
	
	public static int fromByteArray(byte[] bytes) {
		// Change endianness
		swapEndianess(bytes);
		return ByteBuffer.wrap(bytes).getInt();
	}
	
	public static String convertFilename(byte[] data) {
	    StringBuilder sb = new StringBuilder(data.length);
	    for (int i = 0; i < data.length; ++ i) {
	        if (data[i] < 0) { 
	        	throw new IllegalArgumentException();
	        }
	        if (data[i] == 0) {
	        	break;
	        }
	        sb.append((char) data[i]);
	    }
	    return sb.toString();
	}


}

Este programa está hecho rápidamente y no está precisamente optimizado. He podido permitirme cargar o gestionar los ficheros enteros en memoria ya que el tamaño del DAT completo es de pocos megas. Además, tiene hardcodeado (incrustado en el código) el número de ficheros y la ruta al DAT. Mejorarlo lo dejo de deberes para el lector.

¿Por qué en Java? No es un lenguaje muy indicado para manejar binarios, y desde luego el no disponer de tipos sin signo no ayuda. Sencillamente lo hice en Java y no en C porque es el lenguaje con el que me gano la vida y con el que tengo más soltura, y llevo casi 8 años sin programar nada en C.

Usando el código anterior (o cualquier otro que el intrépido lector codifique) podemos ver los siguientes tipos de fichero:

• RAW, con imágenes sin cabecera.
• PAL, con la paleta de colores que se usa en el juego.
• Ficheros de texto, algunos TXT* sin extensión y otros con extensión RAW.
• XMI, con la música.
• VOC, con los efectos de sonido.
• FNT, con las fuentes del juego.
• Etc, etc…

Hablemos un poco de cada uno.

Ficheros VOC

Los efectos sonoros del juego se almacenan en ficheros VOC. Bueno, ésta es fácil, ya que se trata de un formato no común pero ampliamente soportado por muchos editores de audio. Es un formato de Creative Labs que almacena principalmente audio codificado en PCM y ADPCM, aunque de forma puntual ha servido para otras codificaciones.

Se puede abrir y guardar con Adobe Audition perfectamente. La frecuencia de muestreo varía de un fichero a otro, pero la reconoce sin problemas.

Ficheros de texto

Existen tres tipos de ficheros de texto. Los más sencillos son los ficheros in extensión TXT*, siendo * un número. Se pueden abrir con el Notepad++ y editar sin problemas.

Bueno, no del todo. La codificación no es ASCII, ni ANSI, ni tampoco UNICODE porque aún no era común. ¿Cuál entonces? Pues, dado que el juego se programó para Macintosh, la codificación es Macintosh Roman. Esto es un problema porque Notepad++ no da soporte a esta codificación. Está pedido, pero no parece prioritario, por lo que si quieres editar cómodamente hay que convertirlo antes.

Otros ficheros de texto son los STR*.RAW y *.RAW, siendo * un número. Su formato no es tan bonito.

Al parecer el primer byte es siempre 00h, y el segundo parece almacenar el número de cadenas que hay en el texto. Las cadenas no son como las de C: en lugar de ser cadenas terminadas en 00h son cadenas precedidas de su longitud, codificada en 1 byte. Lo ideal para editar estos ficheros sería construir una utilidad al efecto, pero parece más que viable.

El tercer tipo de ficheros corresponde únicamente al fichero PPDT1003.RAW, que contiene una de las características más divertidas de SimCity 2000: los periódicos.

Lamentablemente este formato es una pesadilla. Comienza con un diccionario de términos separados por 00h, y luego tiene una ristra de textos para generar los artículos. Esta codificación personalizada es de ancho variable (por ejemplo, 5C96h representa la letra ñ) y usa los términos definidos anteriormente, y naturalmente contiene marcadores de posición para los términos del artículo. Éstos se generaban proceduralmente, y un artículo que denunciaba la desaparición de un animal tenía como protagonista un gato o un rinoceronte, de la señora Dwight o del señor Martínez.

Antiguamente existían editores, como Thingy, que daban soporte a ficheros TBL. En ellos se podía especificar un diccionario de términos (o toda una codificación) y editarlos «cómodamente». De todas formas sólo nos servirá si mantenemos el ancho de las cadenas, así que habría que descifrar el número que las precede (y su codificación) para poder editarlas como es debido. Parece bastante complicado, por lo que lo he dejado para mejor ocasión.

Editado: Al parecer, los punteros para los textos de los periódicos están en el fichero PPDT1004.RAW. Consisten en conjuntos de 4 bytes en Big-Endian. Menudo lío.

Ficheros de imagen

Con la excepción de algunos ficheros usados para texto (descritos en el apartado anterior), los RAW son las imágenes usadas en la interfaz del juego. Los edificios y otros elementos están en unos ficheros DAT que quedan fuera del ámbito de este documento ya que se pueden editar mucho más fácilmente con el SimCity Urban Renewal Kit (SCURK), una herramienta que se incluía con versiones posteriores para editar ciudades «a manubrio» y modificar el aspecto de los edificios.

En lo que nos ocupa: estos ficheros RAW son mapas de bits con 8 bits por pixel (256 colores) con una cabecera de 4 bytes. No parece haber información sobre la resolución o los colores, pero para esto último existe un fichero, MINE.PAL, que especifica la paleta que usa el juego. No es un fichero de Microsoft Palette, como sugiere su extensión, sino una paleta en bruto tipo ACT. Casualmente, es el formato que usa preferentemente Adobe Photoshop.

En cuanto a la resolución, no parece haber forma fácil de averiguarla simplemente mirando el archivo. Lo más sencillo es factorizar el número (menos 4 bytes) en dos múltiplos, cosa en la que el propio Photoshop nos puede asistir al abrir el archivo, al menos en versiones modernas. Por el nombre del fichero podemos más o menos discernir para qué sirve si no tenemos una idea, y si hemos jugado al juego (¡deberías!) podemos conocer más o menos su relación altura/anchura. Algunas son fáciles: la pantalla de título (TITLE.RAW) es una imagen de 640×480 pixeles. Todas las imágenes usan la misma paleta, dado que el juego maneja 256 colores en todo momento.

Para editar los ficheros con color indexado en 8 bits siempre uso la misma técnica: las convierto a color de 24 bits + 8 de canal alfa y las edito cómodamente. Después, antes de salvarlas, las cambio a color indexado cargando la paleta del juego nuevamente. Sorprendentemente, salvando en formato Adobe RAW el juego las lee bien, dado que Photoshop permite conservar los 4 bytes de la cabecera. ¡Qué alivio!

Nota: ni que decir tiene que este formato RAW no tiene nada que ver con los formatos de datos en bruto de las cámaras digitales.

Ficheros XMI

En los ficheros XMI se almacena cada una de las músicas del juego. El formato XMI soporta varias canciones por fichero, pero no parece ser el caso. La estructura es diferente a los MIDI, pero hacen prácticamenente lo mismo: almacenar notas y eventos musicales. Se pueden reproducir en Windows cómodamente con Foobar2000, y es posible convertir ficheros MIDI a XMI (y viceversa). MIDIPLEX parece hacerlo desde Windows, pero no se ofrecen binarios compilados y lo hice con herramientas más antiguas para MS-DOS, usando DOSBox. De todas formas, el propio SimCity 2000 necesitará DOSBox para funcionar en sistemas modernos.

Ficheros FNT

Presumiblemente las tipografías del juego, al juzgar por los nombres, los números que los acompañan y la extensión. No parece que sea mismo formato de fuentes en mapa de bits FNT para Windows, por lo que no he podido abrirlo con ningún editor.

Otros

Otros ficheros presentes en el paquete son fuentes General Midi para chipsets OPL, diversos índices y cabeceras para los conjuntos de gráficos de edificios… nada demasiado interesante para modificar el juego. Todo lo demás parece estar incrustado en el propio ejecutable, algo que está fuera de mi alcance.

En Windows

Como apunte, la versión de Windows es mucho más fácil de modificar. Los recursos de imagen y sonido están presentes en formato WAV y BMP, que son mucho menos oscuros que los descritos anteriormente. El resto de recursos se encuentra incrustado en el ejecutable del juego, pero con un editor de recursos se pueden extraer y modificar sin problemas, y en formatos más accesibles que los de MS-DOS. (Yo uso Resource Hacker, que es gratis y funciona bastante bien)

Los periódicos, sin embargo, parecen conservar el calamitoso formato de la versión de MS-DOS. Una pena porque hubiera sido interesante traducir esta versión al español.

Pues hasta aquí. Espero que haya sido muy educativo todo, aunque tras tanto tiempo no parece que el juego suscite mucho interés para ser modificado de ninguna forma. Siempre he querido tocar el juego y hacer mi propia versión, SimCity efecto 2000, un poco más gamberra, pero otra vez será.

La entrada Desmontando SimCity 2000 se publicó primero en Detrás del último no va nadie.