16.384 bytes, anclados en la pagina 2 (0x8000-0xBFFF). Los 16.384 estan identificados, y se reparten asi:
| tramo | bytes | que es |
|---|---|---|
| 0x8000-0x800F | 16 | la cabecera AB |
| 0x8010-0xA360 | 9.041 | el programa MSX-BASIC, tokenizado |
| 0xA362-0xAFFF | 3.231 | la tabla de variables del interprete |
| 0xB000-0xBF9F | 4.000 | los datos de campo: los nueve hoyos |
| 0xBFA0-0xBFFF | 96 | nada: no los lee nadie |
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.
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.
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.
4.000 bytes justos, de 0xB000 a 0xBF9F, con los nueve hoyos pegados uno detras de otro. Como se leen esta contado en Hallazgos.
| hoyo | direccion | bytes | hoyo | direccion | bytes | |
|---|---|---|---|---|---|---|
| 1 | 0xB000 | 532 | 6 | 0xB8BC | 444 | |
| 2 | 0xB214 | 358 | 7 | 0xBA78 | 438 | |
| 3 | 0xB37A | 446 | 8 | 0xBC2E | 408 | |
| 4 | 0xB538 | 452 | 9 | 0xBDC6 | 474 | |
| 5 | 0xB6FC | 448 |