La cinta no es una cinta de MSX

Un juego de MSX se graba en bloques KCS, que es el formato del sistema. Stardust no: sus cuatro bloques de datos son bloques del ZX Spectrum, con su bandera, sus datos y un XOR de comprobación al final, y los cuatro lo traen correcto.

Y el cargador tampoco es de aquí: es una reimplementación de LD-BYTES, la rutina de carga de la ROM del Spectrum, con su mismo interfaz de registros.

El cargador trae una puerta trasera para trainers

Antes de arrancar el juego, el cargador salva 94 bytes a memoria alta y les echa un vistazo: si empiezan por tres 0xC9, los toma por una lista de parches y los aplica sobre el juego que acaba de cargar, dirección y valor, uno detrás de otro.

Y la cuenta cuadra sola: tres bytes de firma, uno de contador y treinta parches de tres bytes, noventa y cuatro en total. Está pensado para treinta pokes exactos, que es justo lo que usaban los cargadores de las revistas de la época.

Dos juegos en una cinta

Al superar la última zona de naves, el juego vuelve al cassette a por una segunda parte en la que el protagonista sigue a pie. Y no usa la rutina del cargador para eso, aunque sigue viva en memoria: trae la suya, que enciende el motor de la cinta y lee el bit de datos por el chip de sonido.

Los dos programas ni siquiera comparten motor. En la primera parte cada objeto lleva una estructura de 8 bytes con la rutina que lo gobierna apuntada dentro; en la segunda, los enemigos viven en tablas ligeras de 5 bytes que mueven bucles fijos —cuatro andantes como mucho, y los voladores aparte—. Sí hay objetos de 46 bytes en la segunda parte, pero no son enemigos: son los tres canales del intérprete de sonido.

Lo que el MSX obligó a cambiar

El Spectrum escribe directamente en su memoria de pantalla, que es RAM normal. En el MSX la memoria de vídeo está detrás del chip gráfico, así que hay que mandársela por un puerto, byte a byte.

Por eso esta versión carga con un buffer de pantalla que el original no necesita: 3840 bytes en 0x4000-0x4EFF, de 24 de ancho por 160 de alto, que el volcado envía a la VRAM en tres bandas, columna a columna. Veinticuatro bytes son 192 píxeles, más estrecho que la pantalla, y por eso el marco de los lados no se mueve nunca: lo que sobra está a lo alto, que es justo por donde scrollea.

Y esos ejes son fáciles de leer al revés. El ld b,028h del volcado parece decir «40 columnas», pero es el bucle interior, el que recoge 40 bytes de una misma columna a saltos de 24. Lo caza dibujarlo: partido de 24 en 24 sale la tabla de récords, legible; de 40 en 40, ruido.

Sprites dibujados a mano

El MSX tiene sprites por hardware, pero aquí no se usan: se dibujan por software, a la manera del Spectrum, desplazando el dibujo bit a bit y componiéndolo con AND y OR.

Las dos partes del juego llevan la misma rutina para eso, copiada y reubicada de una a otra. El pintor de sprites mide 198 bytes, y si emparejas bien sus dos mitades las únicas diferencias son diez direcciones reubicadas y un solo byte suelto, el del recorte por abajo.

Ningún punto de entrada cae dentro de un gráfico

Sembrar el trazador con rutinas mal ancladas puede hinchar la cobertura de golpe sin que nadie lo note: el binario reensambla igual, porque son los mismos bytes y solo cambia cómo se leen; el presupuesto cierra igual; y una comprobación de trazado que solo mire un fichero de excepciones tampoco lo ve. Por eso hay una regla para exactamente esto, corriendo en el gate junto al resto: ningún punto de entrada puede caer dentro de un rango declarado como datos.

Y luego está la otra prueba, jugar la partida de verdad. Reproduciendo una grabación completa de 38 minutos —cortesía de Araubi— y anotando por dónde pasa el procesador, resulta que de las 1489 direcciones que el juego llega a ejecutar, el trazador ya alcanza 1444 por su cuenta; las que faltan pasan a ser puntos de entrada, cada una con su cuenta de muestras al lado. La cobertura real del bloque de naves acaba en 23,0 %, y la de la segunda parte, en 28,6 %.