Aquí no hay ninguna ilustración ni captura. Los gráficos están dibujados desde los bytes de la ROM, ejecutando en Python el mismo descompresor de rachas que corre el Z80. El listado y las cifras salen del binario y se reproducen con make.
El número de patrón de cada sprite del atleta no está en ninguna tabla de posturas. Lo clava una sola vez 0x618E al montar la prueba, con un ld (hl),a / add a,004h que va dejando 0x00, 0x04, 0x08… en los siete sprites. El sprite 1 pinta el patrón 0x04 y lo pintará siempre.
Lo que cambia cada cuadro son los patrones. 0x65AD saca de la tabla de 0x65F6 el guión de la postura; ese guión son ternas (dy, dx, color) que 0x65BE deja en las fichas de 0xE0D0, y lo cierra un byte 0x8N cuyo nibble bajo dice cuántos bloques de dibujos van detrás. 0x65D9 apunta el VDP a la VRAM 0x1800 —la tabla de patrones de sprites— y 0x65E5 los sube con el descompresor de 0x69F9.
De ahí salen las ropas. El sprite 1 es siempre el patrón 0x04, pero en unas posturas ese patrón trae unas zapatillas blancas y en otras no trae nada. Y como en el MSX1 manda el sprite de número más bajo, el orden de las ternas dentro del guión es lo que decide qué pieza tapa a cuál.
Los cuatro rótulos están seguidos en la ROM desde 0x6F08 en el orden DIVING, TRAMPOLINE, LONG HORSE, HORIZONTAL BAR. Ése no es el orden en que se juegan. Quien elige es la tabla de cuatro punteros de 0x6F00, que 0x6E38 indexa con 0xE052 y 3, y esa tabla los reordena: 0 DIVING, 1 LONG HORSE, 2 TRAMPOLINE, 3 HORIZONTAL BAR. Leyendo los textos en vez de la tabla salen la segunda y la tercera cambiadas, que es exactamente lo que decía esta web hasta que se comprobó en el emulador leyendo la tabla de nombres como texto mientras la atracción juega las cuatro.
0xE052 no se reinicia entre vueltas: sigue subiendo, y la prueba sale de sus dos bits bajos, así que la quinta vuelve a ser DIVING con el STAGE subido.
El marcador escribe letras y cifras como números de casilla en ASCII directo, y esas casillas no las dibuja el juego: 0x43BF toma el puntero CGTBL de 0x0004 —la tabla de caracteres de la ROM del MSX—, se salta 0x180 bytes para empezar en el '0' y sube 48 caracteres a la VRAM. El cartucho sólo pone de su bolsillo seis, con dos guiones comprimidos: los tiles 0x3A y 0x3B (de ahí sale el guión del 1P-000000) y los 0x5C a 0x5F. Cotejado: la fuente de la BIOS más esos retoques da los 384 bytes de la VRAM en los tres tercios, sin una diferencia.
Las gradas se animan alternando sobre la VRAM 0x2158 dos guiones seguidos del cartucho, 0x4976 y 0x498E. El primero no es un bloque aparte: es la cola del flujo común que 0x4891 descomprime al montar cualquier prueba, y que además se vuelca suelto para animar. 431 volcados en los primeros 60 segundos, medidos con un punto de ruptura en 0x440D.
INIT engancha la interrupción a 0x402C y cae en un jr a sí mismo. A partir de ahí el programa principal no hace nada: cada cuadro la interrupción lee 0xE000 (el estado), salta por la tabla de manejadores de 0x40C2, y dentro de cada uno el byte 0xE001 reparte los subestados. El bit6 de 0xE002 marca la demo.
El cartucho no guarda pantallas: guarda guiones. Uno, en 0x405E, copia byte a byte a la tabla de nombres con saltos de destino (0xFE) y un fin (0xFF); el otro, en 0x440D, descomprime por rachas con un byte de cuenta cuyo bit alto distingue copia literal de relleno. Las figuras de esta web salen de ejecutar ese segundo en Python.
El motor de 0x7C3D recorre tres fichas de once bytes (0xE010), lee las melodías con su intérprete de órdenes y escribe el PSG por la BIOS. Es el mismo armazón de reproductor que Konami repartía entre sus cartuchos de MSX, con su tabla de tonos y sus efectos.
El estado de la prueba vive en 0xE050 para el jugador 1 y en 0xE080 para el 2. Al cambiar de turno, 0x413E intercambia los dos bloques enteros con una sola rutina de 32 bytes, así que el resto del código siempre trabaja sobre el mismo sitio sin enterarse de a quién le toca.
Muchos cartuchos de la casa esconden al final de la ROM su número de catálogo y el título en katakana; lo descubrió Manuel Pazos (@ManuelPazosMSX). Aquí no está: los últimos bytes son datos del reproductor de sonido, sin el 0xAA que cierra la marca. El RC-715 viene del catálogo, no del binario.
Debajo de la imagen está de dónde sale y qué se está viendo.
TIME: su guión de rótulos (0x4560) es el único que escribe esa palabra, y sólo se vuelca para esta prueba
tools/graficos.py descomprimiendo sus rachas con el mismo formato que el Z80. Son las piezas del ESCENARIO: el atleta no está aquí, porque sus dibujos no viven en esta tabla —el guion de cada postura reescribe la tabla de patrones de sprites cada cuadro—