El cartucho

16.384 bytes, anclados en la pagina 2 (0x8000-0xBFFF). Los 16.384 estan identificados, y se reparten asi:

tramobytesque es
0x8000-0x800F16la cabecera AB
0x8010-0xA3609.041el programa MSX-BASIC, tokenizado
0xA362-0xAFFF3.231la tabla de variables del interprete
0xB000-0xBF9F4.000los datos de campo: los nueve hoyos
0xBFA0-0xBFFF96nada: no los lee nadie

La cabecera declara TEXT y nada mas

41 42 00 00 00 00 00 00 10 80 00 00 00 00 00 00
 A  B   INIT   STATEMENT   TEXT=0x8010   DEVICE

INIT a cero, STATEMENT a cero, DEVICE a cero. Lo unico que dice el cartucho es TEXT=0x8010, o sea: "aqui hay un programa BASIC, ejecutalo". Y el interprete lo ejecuta desde la propia ROM, sin copiarlo a RAM.

El programa

246 lineas, 718 ordenes, 9.041 bytes tokenizados. Ni un CALL ni un USR a codigo maquina de verdad: la unica llamada, USR(0) en la linea 30000, apunta a la direccion 0, o sea que pulsar STOP reinicia la maquina.

La tabla de variables: el truco del arranque

Entre el programa y los datos de campo hay 3.231 bytes que no son ni codigo ni datos de autor: son las tablas de variables del interprete, tal y como quedaron en memoria en una sesion de verdad del juego. Ese es el truco que hace que un cartucho BASIC sin rutina INIT arranque: la ROM trae el programa y su estado ya montado.

tools/variables.py las lee. Salen 98 variables sueltas (de 0xA362 a 0xA728) y nueve arrays (de 0xA729 en adelante), en el mismo orden en que el programa las crea. Y la sesion que quedo dentro estaba jugando el hoyo 2:

H  = 2        el hoyo
ZM = 0xB37A   el puntero de lectura del campo, ya en el hoyo 3
HX = 60       la bandera del hoyo 2...
HZ = 139      ...con el metro de ajuste de la linea 117 ya restado
P  = 3        su par
S8 = 12       doce golpes en total, once de ellos en el hoyo 1

Que esas cifras cuadren con los datos de campo es una comprobacion de la lectura hecha desde fuera del programa, y esta puesta como test.

El ultimo array no cabe: C1() empieza en 0xAFA1 y necesitaria 25 bytes mas de los que quedan. A partir de 0xB000 estan los datos de campo, y se lo comen. No importa: el interprete rehace todos esos arrays al ejecutar el DIM de la linea 20.

Los datos de campo

4.000 bytes justos, de 0xB000 a 0xBF9F, con los nueve hoyos pegados uno detras de otro. Como se leen esta contado en Hallazgos.

hoyodireccionbyteshoyodireccionbytes
10xB00053260xB8BC444
20xB21435870xBA78438
30xB37A44680xBC2E408
40xB53845290xBDC6474
50xB6FC448