Aquí no hay ninguna ilustración. Las pantallas son capturas del cartucho corriendo en openMSX, tomadas por un guion que solo cambia el número de prueba que el propio juego usa como índice; el logotipo y la hoja de la fuente están dibujados desde los bytes de la ROM, ejecutando en Python el mismo intérprete de guiones que ejecuta el Z80. El listado y las cifras salen del binario y se reproducen con make.
El rótulo de la primera prueba tiene una R de más. No es la captura, ni el emulador, ni el recorte: está escrita en los datos. El rótulo de 0x64B1 lleva, detrás de su byte de cabecera, la tira de glifos
0A 01 01 00 0A 12 1E 1B 0E 16 0F 1B 1C 0A
y en la fuente del cartucho (0x6197) esos índices son 110 HURDLERS . La captura solo enseña el resultado.
Las cuatro pruebas son nuevas, pero solo dos motores lo son. El de las 110 vallas y los 1500 metros es el mismo que movía las carreras del cartucho anterior. Y el del salto de altura (0x6A2C) es el que allí hacía girar el martillo: tomar impulso, marcar el ángulo con el botón y soltar.
Cambia lo que se dibuja, no la mecánica. Lo que este cartucho añade de verdad son 2.227 bytes, y sus cuatro tramos mayores son: el salto de la valla, el motor de la jabalina, el del salto de altura y el dibujo de la valla.
Es una comparación de columnas en un instante concreto. Mientras el atleta salta —postura 13, diez cuadros contados en 0x5A34—, 0x5A5B compara su columna con la de la valla que le toca. Si al acabar el salto están a menos de ocho columnas, se pone el bit 4 de 0xE028 o de 0xE029.
Ese bit es la caída: 0x5AA5 le pone la postura 14, le borra los cuatro bytes de velocidad y le mete 0x14 cuadros de levantarse. Fuera de ese instante, la valla y el atleta no se tocan.
Un actor normal monta su figura en el papel de 0xE230 y la sube de una vez. La valla no cabe en una fila, así que 0x7AB3 monta la mitad de arriba en 0xE230 y la de abajo en 0xE270, y las sube por separado, cada una a su fila de la tabla de nombres.
Es el único actor del cartucho que hace esto.
0x517B lleva 00 12 93 / 00 96 72 / 00 02 36 / 00 03 31, que INIT copia a 0xE040. Los cuatro son récords del mundo de verdad, pero tres ya estaban batidos cuando el cartucho llegó a las tiendas: Petranoff tiró la jabalina a 99,72 en mayo de 1983, Zhu Jianhua saltó 2,37 el 11 de junio, y Ovett bajó el 1500 a 3:30,77 en septiembre.
El que aguanta es el más antiguo de todos, los 12,93 de Nehemiah de 1981. Las fechas no salen del cartucho: son un cotejo con las progresiones públicas. Del cartucho sale la cifra.
Los 51 glifos de 0x6197 van ordenados: 0..9, el espacio, y luego el alfabeto de la A a la Y saltándose la Q, la X y la Z. Con la A en el índice 0x0B, la P cae en 0x1A y la siguiente ya es la R.
Y sin embargo la Q existe: está al final, en el índice 0x2C, fuera del alfabeto. El motivo es la única palabra del juego que la necesita, el rótulo QUALIFY del marcador, que en 0x611E es la tira 2C 1E 0B 16 13 10 21.
Esto es de lo que solo se ve dibujando: leyendo el bloque, los 51 glifos son 408 bytes iguales. La hoja está más abajo.
El 86,9 % de los comentarios de este cartucho son idénticos a uno del hermano: vienen portados con el código compartido, y eso los coloca en la dirección buena sin cambiar lo que dicen.
Dos guardianes lo vigilan y los dos han cazado algo. repasa_el_porte.py comprueba que toda dirección citada exista aquí: encontró nueve que no. Y cifras_portadas.py comprueba que, cuando el comentario es idéntico, la instrucción anotada también lo sea: encontró los dos comentarios de 0x4389, que decían «32 sprites» cuando aquí el ld bc,01afeh carga 26.
En 0x4E64, pegados a los ocho registros del VDP, hay tres grupos de cuatro bytes con pinta de filas de la tabla de atributos de sprite: 00 70 38 70 / 00 A0 38 70 / 00 F0 38 F0. Ningún puntero de la ROM cae ahí y nadie los lee.
Están también en el cartucho anterior, byte a byte iguales y tan muertos como aquí. Los dos heredaron el mismo cadáver.
Comparando el código con los operandos de dieciséis bits puestos a cero —para que una rutina reensamblada en otro sitio también se vea—, este cartucho comparte 6.298 bytes, el 63,8 %, con su hermano. Con cualquier otro cartucho Konami de MSX de esta serie no llega al 2 %, y sus tramos comunes más largos van de 21 a 42 bytes, frente a los 681 seguidos que comparte con el hermano.
O sea que los dos Hyper Olympic no son ni el armazón de unos ni el de los otros. Son un tercero, y de momento solo tiene dos miembros. Las cifras completas están en Hallazgos.
Muchos cartuchos de la casa esconden al final de la ROM su número de catálogo RC-7xx y el título en katakana, detrás del relleno; lo descubrió Manuel Pazos (@ManuelPazosMSX).
Aquí no está: los dos últimos bytes son 0xFF y delante hay código del reproductor de sonido. Se comprobó con tools/marca_konami.py, que en el mismo tiro sí la encuentra en otro cartucho de la casa. El RC-711 viene del catálogo, no del binario.
Debajo de cada imagen está de dónde sale y qué se está viendo.
pantalla_del_menu y las cuatro líneas del menú. La que se elija deja en 0xE01B un número del 1 al 4, y de ahí salen el número de jugadores y el mando
tools/graficos.py. Se ve de un vistazo lo que el listado afirma: no hay X ni Z, y la Q está al final, fuera del alfabeto. Son byte a byte los mismos 408 bytes que en el cartucho anterior