El cartucho guarda todo lo que dibuja comprimido, con dos formatos que se parecen pero no son el mismo.
El de rachas (0x983C) mira el nibble alto de cada byte: si vale 0xA, es una racha -el nibble bajo más dos dice cuántas veces y el byte siguiente qué valor-; si no, el byte se escribe tal cual. El de parejas (0x97FF) usa el nibble alto a cero para abrir un bloque, y entonces el byte siguiente dice cuántas veces se escribe la pareja que viene detrás.
Los dos paran por el puntero de destino, no por la fuente: el llamador deja en BC la dirección de VRAM donde hay que parar. Eso es lo que permite que una misma tabla sirva para tres destinos distintos, y también lo que hace que las tablas cortas se pasen de largo.
El nibble bajo del formato de parejas sería un contador exterior, pero en los 128 bloques de las tres tablas del cartucho vale cero, así que el bloque nunca se repite: no hay ningún dato aquí que distinga entre las dos lecturas posibles de ese bucle.
Ni el marcador, ni el título, ni el campo se dibujan con código: los tres se recorren como pequeños lenguajes.
0x9505 es or 0AFh -los bytes F6 AF- y hay quien lo llama por su primer byte y quien lo llama por el segundo. Por el primero se ejecuta el or y el flag Z queda a cero; por el segundo se ejecuta el operando, que suelto es xor a, y Z se levanta. Ese flag es el que deciden las seis llamadas de detrás: tablas largas o tablas del rótulo.
El trazador sigue el flujo desde INIT, pero hay dos sitios a los que no puede llegar solo y van declarados a mano en src/holeinone.entries: el gancho de BASIC de 0x8010, al que sólo se entra escribiendo GOLF, y el manejador de interrupción de 0x94CB, que el propio juego instala escribiendo un jp en H.TIMI.
Todo lo demás sale del trazado. De los 16.384 bytes, 6.065 son código alcanzado de verdad y 10.319 son datos declarados uno a uno, con su formato y su prueba.