Aquí no hay ninguna ilustración. El rótulo, el marcador y los dieciocho hoyos están dibujados desde los bytes de la ROM, ejecutando en Python los mismos descompresores y el mismo intérprete de guiones que corre el Z80, y comprobados contra la VRAM del emulador: 13.655 de 13.664 bytes idénticos —los nueve que bailan son los dígitos del marcador, que el juego escribe en marcha— y las 480 celdas de cada hoyo clavadas en seis volcados de partida. La única captura de pantalla de esta página es la de CALL GOLF, porque ahí lo que se enseña es justamente el cartucho corriendo. El listado y las cifras salen del binario y se reproducen con make.
Las dieciocho pantallas no son dieciocho decorados sueltos: son ventanas de un mismo campo de 20 × 415 casillas. El hoyo 1 está en el extremo sur, el 18 en el norte, y dos hoyos seguidos comparten una fila: la de arriba del hoyo n es la de abajo del n+1. Por eso el lago con el que acaba el hoyo 1 está al pie del 2, y el mar que corona el 2 es el que baña el 3.
Lo vio theNestruo. Aquí está medido: la fila que comparten coincide en el 70.9 % de sus veinte casillas, frente al 41.6 % de dos filas pegadas cualesquiera dentro de un mismo hoyo —que es la línea base que hay que superar— y al 21.0 % de dos filas sueltas. Las diecisiete junturas la superan, una a una. Y el solape es de una fila exacta: probando de una a seis, la de una gana en las diecisiete parejas.
Apilado al revés —el hoyo 2 debajo del 1, que es como se publicó aquí primero— da el 35.9 %: por debajo de la línea base. Lo que fallaba era la medida, no el mapa.
En el guión de un hoyo no hay ni una coordenada: la continuidad está dibujada, no calculada. Y el sentido lo dice el propio juego, porque los dieciocho tees caen en las filas de arriba y las dieciocho banderas en las de abajo: cada hoyo se juega de norte a sur, y el campo se recorre de sur a norte.
Un hoyo entero ocupa unos trescientos bytes, y el truco está en los tres primeros. El cartucho los copia a 0xE451 y ahí se quedan: son la paleta del hoyo. Después, en el guión, un byte 0x3n, 0x4n o 0x5n repite n+1 veces el primero, el segundo o el tercero de esos materiales.
Lo que engancha las dos cosas es una cuenta de tres. El índice de la paleta es el nibble alto del opcode, y la tabla empieza en 0xE44E —tres bytes antes de la cabecera—, justo para que el 3, el 4 y el 5 caigan encima de ella. Así que no hay tabla de paleta: hay una resta que hace que la cabecera del hoyo sea la paleta.
El SCREEN 2 del MSX son tres tercios independientes, y para que los tres tengan lo mismo hay que escribirlo tres veces. 0x9505 hace las seis llamadas —tres de patrones y tres de color— pero 0x9834 vuelve a poner DE=0xB324 en cada una, así que las tres descomprimen la misma fuente.
Salen 2 KB de cartucho por 6 KB de tabla, y lo mismo con el color. La tabla de patrones entera del juego cabe en 1.613 bytes comprimidos.
0x9505 es un or 0AFh, o sea los dos bytes F6 AF: llamando ahí, el flag Z se va a cero y las seis llamadas de detrás cargan las tablas largas. Pero 0x8829 llama a 0x9506, que es el segundo byte de esa misma instrucción, y 0xAF por su cuenta es xor a: entrar por ahí ejecuta el operando, pone A a cero y levanta Z, y entonces las seis cargan dos tablas cortas que sólo pisan los tiles 0x10 a 0x1D de cada tercio.
Esos catorce tiles son las letras de HOLE IN ONE. El resto de la pantalla —el fondo a rayas, los créditos— se monta con la misma rejilla de 20×24 que usa el campo.
Los dos descompresores paran cuando el puntero de VRAM llega a su tope, no cuando se acaba la fuente. Y las dos tablas del rótulo se quedan cortas: dan 104 de los 112 bytes que hay que escribir.
Así que siguen leyendo. Los ocho últimos bytes del tile 0x1D salen de la cabecera de la tabla de color que viene detrás, y los de la de color, del principio del código de 0xBE0D. Los dieciséis bytes están así en la VRAM del emulador. Sale gratis porque el tile 0x1D no lo nombra nadie: las dos mitades del rótulo sólo llegan al 0x1C.
No hay una tabla con la ficha de los hoyos. El par lo dice el propio tile que dibuja el tee: 0xD9 es un par 3, 0xDD un par 4 y 0xE3 un par 5, y de paso el intérprete apunta dónde está para colocar la bola. La longitud son tres dígitos ASCII pegados detrás del 0x21 que cierra el mapa, y el marcador los escribe tal cual con su «m» al lado.
Sumados los dieciocho, el campo da par 72 y 6.430 metros, con cuatro pares 3, diez pares 4 y cuatro pares 5. Un campo de campeonato, y ni un byte gastado en decirlo.
0x9571 escribe diez celdas por fila y salta veintidós para caer en la siguiente, veinticuatro veces: eso deja el panel de TOP, SHOTS, HOLE, PAR, POWER, CURVE y CLUB ocupando las columnas 1 a 10 de la pantalla.
El campo entra justo detrás. 0x9A66 vuelca las 480 celdas del hoyo en veinte columnas por veinticuatro filas desde 0x180B, que es la columna 11. Las dos mitades no se pisan nunca porque ninguna se dibuja centrada: cada una sabe su ancho.
Debajo de cada imagen está de dónde sale y qué se está viendo.
CALL GOLF. Dibujados con el mismo intérprete y los mismos tiles que los del cartucho, porque es el mismo formatotools/campo.py en el formato del propio cartucho: calle de arena, un lago que cambia de lado, y una barra de agua arriba de tantas casillas como el número de hoyo. Están dibujados con el mismo intérprete que dibuja los de la ROM —si el formato estuviera mal entendido, aquí saldría ruido—CALL GOLF tecleado en el BASIC: la exhibición dibuja el hoyo 2 generado —480 de 480 celdas— y el marcador lee su PAR 4 y sus 302 m, que no son los 168 m par 3 de la ROM. Capturado de openMSX por tools/omsx_call_golf.tcl