Una cinta de cassette de 1988, desmontada instrucción a instrucción. Los 42.645 bytes del juego están explicados.
El juego en cifras
Que solo el 11% sea código no significa que falte nada: este juego es 89% datos. Los gráficos, seis tiras de nivel de 256 columnas cada una y sus fondos de parallax.
Lo que apareció al desmontarlo
El juego se carga encima de la ROM
Un MSX de 64 KB no tiene los 64 KB a mano: la página de abajo, de 0x0000 a 0x3FFF, la ocupa la ROM del BIOS. Lo habitual en un juego de cinta es no complicarse y cargar a partir de 0x4000.
Ale Hop! hace lo contrario. Mete los 42.645 bytes en la página 0, encima de donde está el BIOS, y después mueve tres trozos a RAM alta y vuelve a tapar lo que queda con la ROM. Los 35 KB de gráficos y mapas están escondidos debajo del BIOS casi todo el tiempo; el juego los destapa un instante cada vez que carga un nivel y los vuelve a tapar.
Es la decisión que da forma a todo lo demás, incluido que este desensamblado sean cinco listados en vez de uno.
Un mensaje que casi nadie llegó a leer
Al superar el sexto y último nivel pasa un texto haciendo scroll. La pantalla que lo enmarca tiene dos recuadros vacíos: el texto no está dibujado en ninguna parte. Está en ASCII en 0xC3F0, y una rutina lo lee letra a letra, saca el dibujo de cada una de la memoria de vídeo y lo desplaza un píxel por fotograma.
La despedida anuncia otro juego que Topo Soft había publicado el año anterior, que a su vez terminaba señalando a éste.
El parallax cabe en una instrucción
El fondo se mueve cuatro veces más despacio que la pista. Las dos rutinas de volcado leen la misma variable de columna de cámara, pero la del fondo le hace un and 0x3F y su mapa tiene 64 columnas, mientras que la de la pista usa el byte entero sobre un mapa de 256. Ese es todo el truco.
135 bytes que no se ejecutan nunca
Cuatro trozos de código Z80 perfectamente coherente a los que no llega ningún camino. Entre ellos, un efecto de color a pantalla completa que convierte todo el negro en transparente —3.673 de los 6.144 bytes de color— y que solo tiene sentido acompañado de un cambio del color de fondo. Medio fundido que se quedó fuera.
También está ahí el manejador de interrupción de la librería de sonido, sin usar porque el juego tiene el suyo. Es la mejor prueba de que el reproductor llegó como librería reutilizable y no como código escrito para este juego.
Sitio para dos niveles que no existen
Los mapas de fondo se buscan con 0x3000 + nivel * 0x200. Hay espacio para ocho, pero solo seis tienen datos: los 1.024 bytes que ocuparían el 7 y el 8 son relleno 0xFF, y el cargador corta en el sexto.
Los seis niveles
No son capturas de pantalla. Están dibujadas a partir de los datos del propio juego: descomprimiendo los gráficos con la misma regla que usa él y montando los mapas. Cada nivel es una tira de 256 columnas de las que solo se ven 32 a la vez.
Nivel 1·0x0000
Nivel 2·0x0800
Nivel 3·0x1000
Nivel 4·0x1800
Nivel 5·0x2000
Nivel 6·0x2800
Cómo se hizo
Se usó el propio cargador del juego como decodificador: en vez de reimplementar el formato turbo de Topo Soft, la cinta original se carga en openMSX y se vuelca la RAM en cada etapa. Lo que sale es exactamente lo que el juego ve en memoria, y coincide byte a byte con lo extraído del fichero de cinta.
A partir de ahí el código se traza siguiendo el flujo desde los puntos de entrada, nunca desensamblando en línea recta: 35 KB de gráficos leídos como instrucciones desalinean todo lo que venga detrás. Las zonas que se saben de datos se declaran prohibidas, porque una sola semilla mala mete al trazador en los dibujos e infla la cobertura con basura.
El resultado lo vigilan dos controles distintos. La reproducibilidad: cada listado reensambla al binario original, byte a byte. Y el presupuesto: cada byte tiene que ser o código trazado o un rango de datos con nombre en las notas. El segundo existe porque el primero no ve los errores de interpretación: si unos gráficos se marcan como código, los bytes siguen saliendo idénticos y el que miente es el listado.