Ahora que Apple ha abierto las puertas de su jardín, los emuladores vuelven a estar de moda. No es que los emuladores de consolas retro sean algo nuevo (llevan en Android infinidad de tiempo), sino que Apple los ha vuelto a poner sobre la mesa con la llegada de Delta y, próximamente, Provenance. Lo cierto es que estas aplicaciones/programas parecen arte de magia y su funcionamiento es totalmente transparente al usuario: coges un juego de Game Boy, lo lanzas y ¡voilá!, estás jugando al ‘Pokémon Rojo’ en tu iPhone.
La pregunta es: ¿cómo funciona exactamente un emulador? ¿Qué pasa entre bambalinas para que esto sea posible? Vamos a verlo.
¿Qué es un emulador? Empecemos por el principio. En informática, un emulador es un software capaz de ejecutar código de una plataforma (por ejemplo, una aplicación de Android en formato APK) en otra plataforma para la que dicha código no ha sido desarrollado (por ejemplo, Windows). No solo corre el programa, sino que imita, simula, emula el dispositivo original y es más complejo de lo que parece.
¿Por qué? Para el caso, vamos a pensar en un emulador de Game Boy. ¿Qué tiene una Game Boy? Tiene un lector de cartuchos, una pantalla, un altavoz, unos cuantos botones, unos cuantos componentes… Todo eso debe ser emulado si queremos ejecutar un programa desarrollado para dicha plataforma. Hablamos de la CPU, la ROM, la RAM, la interfaz de entrada y salida… No es poca cosa.
Los diferentes niveles de emulación. Existen dos niveles: Low Level Emulation (LLE) y High Level Emulation (HLE). El primero consiste en recrear un hardware a partir de un software. Dicho de otra forma, es un programa que simula el funcionamiento de una Game Boy. El segundo busca replicar las funciones usando abstracción de hardware. Cuando hablamos de emuladores de videojuegos, sobre todo juegos retro, hablamos de Low Level Emulation y, aunque requiere de más recursos, es posible gracias a que las máquinas antiguas son bastante, pero bastante menos potentes que los dispositivos actuales.
¿Y cómo funciona? Aquí es donde está la miga. Cuando pulsabas la A en tu Game Boy para elegir a Charmander en el ‘Pokémon Rojo’, lo que estabas haciendo era enviar una instrucción a la CPU de la consola. Si usabas una Game Boy Color, la CPU era un Sharp SM83, que realmente era una mezcla entre el Zilogic Z80 y el Intel 8080. Pero en tu móvil no tienes ese procesador. Tendrás un Apple Bionic corriendo iOS o un Qualcomm Snapdragon, un MediaTek Dimensity/Helio corriendo Android… Son plataformas, arquitecturas diferentes y, por lo tanto, entienden instrucciones diferentes. Toca, por lo tanto, emular la CPU.
Una CPU hace, en esencia, tres cosas: buscar, decodificar y ejecutar. Busca dónde está la instrucción que queremos ejecutar, entiende qué tiene que hacer y, finalmente, lo hace. Eso es lo que llamamos «ciclo» y es lo que el procesador hará hasta el final de los tiempos. Por hacer una analogía, es como montar un mueble de IKEA:
- Buscar: ir a la página 1 del manual de instrucciones.
- Decodificar: ver cuántos tornillos ÑLIQNFVIH necesitas.
- Ejecutar: poner los tornillos ÑLIQNFVIH en la tabla CNKCNF.
Y repetir el ciclo hasta completar el mueble.
Unos y ceros. Sin embargo, cuando hablamos de ordenadores no hablamos de tornillos, Pokémon o procesadores. Hablamos de unos y ceros, de binario. Es el idioma que entienden los ordenadores. Así pues, podemos entender cada instrucción como un conjunto de unos y ceros que agrupamos en bytes, que son ocho ceros y unos en fila. Para una CPU, un byte se leería, por ejemplo, como 00100110. Nosotros podemos darle un valor hexadecimal, como x0Dx.
Idiomas diferentes. ¿Qué sucede? Que la Game Boy tenía un procesador Sharp SM83, pero en tu iPhone 15 Pro tienes un procesador Apple A17 Pro y resulta que la instrucción 00100110 en el Sharp SM83 no significa lo mismo en el Apple A17 Pro. ¿Qué hace un emulador? Funciona como un traductor. Convierte las instrucciones en binario de la Game Boy a instrucciones equivalentes y entendibles por el procesador del móvil, del ordenador o lo que sea.
No solo eso, sino que tiene que simular el resto de componentes para que el juego, por ejemplo, tenga sonido, se vea en la pantalla o entienda que al pulsar en cierta zona estamos moviendo el personaje hacia la izquierda. Por no hablar del resto de funciones, como la lectura de la memoria interna, la gestión de la RAM… Si a esto le sumamos que las consolas antiguas podían usar sistemas y formatos propietarios o patentados, apaga y vámonos. Emular la CPU, no obstante, es la parte más compleja.
El problema es que estas instrucciones no son ocho ceros y/o unos. Un juego está compuesto por miles y miles y miles y miles de ceros y unos y, desgraciadamente, no suele haber documentación pública de qué hace cada cadena. No se puede saber a simple vista que 00100110 hace que el personaje se mueva hacia arriba ni existe una tabla de correspondencia (porque el código de las consolas no es abierto), así que el desarrollador tiene que hacer ingeniería inversa para interpretar qué hace qué y cómo. No es sencillo, ni mucho menos, y además requiere de cierta potencia para funcionar. La emulación Low Level es muy precisa, pero también intensiva.
¿Ingeniería inversa? Es el proceso que consiste en obtener información o un diseño a partir de un producto. En el caso de los videojuegos, sabemos dos cosas: el principio (metemos un cartucho) y el final (el juego se reproduce), pero no sabemos qué hay entre medias ni cómo funciona el código de la consola. La ingeniería inversa consiste en investigar y hacer infinidad de pruebas para conseguir, en este caso un software, que sea capaz de traducir el código original y ejecutarlo en una plataforma diferente. Es hacer el camino al revés.
Un ejemplo, por fi. Mucho texto, ¿verdad? Vamos a imaginar una obra de comedia («Emulación letal», se llama) escrita en España por un autor español para la audiencia española. Como la obra la ha escrito un autor español para la audiencia española, «Emulación letal» tiene nuestros códigos, nuestros gestos, nuestro humor, nuestras referencias… que solo entendemos nosotros, los españoles, porque la obra se ha escrito por y para nosotros.
Ahora imaginemos que van a doblar «Emulación letal» al alemán para ponerla en Alemania. Próximamente en cines, «Tödliche Nachahmung», una película española llena de chistes sobre la tortilla de patatas con o sin cebolla. Ningún alemán entenderá la referencia y no se reirá, así que se hace una localización. Se cambian las bromas españolas por bromas y referencias alemanas, pero de manera que los diálogos doblados encajen en las escenas (misma longitud, tono…) para que la peli sea lo más parecida a la original. Eso requiere mucho trabajo, pero el resultado es lo más preciso posible. Pues ese es, en esencia, el funcionamiento de la emulación Low Level y de la inmensa mayoría de emuladores de videojuegos retro.
¿Y las consolas nuevas? Son todo un desafío, sin duda. Es relativamente fácil echar a andar un emulador de Game Boy en prácticamente cualquier dispositivo, ya que la consola original era poco potente y las máquinas actuales tienen potencia más que de sobra para emularlo. La arquitectura de la Game Boy era relativamente sencilla y eso permite que el emulador, es decir, nuestro «traductor de unos y ceros», pueda hacer su trabajo con soltura. Además, los sistemas solían usar más o menos los mismos chips, como los MOS 6502 o el Zilog Z80, por lo que esos componentes, actualmente, son más que conocidos.
El problema viene con las consolas actuales. La PS3, por ejemplo, es un caso conocido por ser muy difícil de emular debido a su arquitectura. La CPU tiene un núcleo principal y siete núcleos pequeños, una arquitectura que difiere de los procesadores multinúcleo encontrados en PC, lo que hace que emular su comportamiento sea complicado y requiera de mucha potencia. Por eso, aunque haya pasado tanto tiempo, sigue siendo una emulación compleja. Los componentes de la Game Boy, sin embargo están ya estudiados y requetestudiados, así que su emulación es totalmente factible.
Imagen de portada | Dim Hou
Author: Jose García