Lo que no esta cerrado, dicho como lo que es.
DEFINT D y la vista 3DLa linea 3 acaba en DEFINT D, comprobado en los bytes (AC 44). Eso deja en enteras todas las variables que empiezan por D, DN() incluido - y DN() es donde la subrutina 5000 guarda el contorno ya rotado. La rotacion de las lineas 5140 y 5145 deberia, por tanto, redondearse a entero.
Al dibujar la vista de las dos maneras y compararla contra la VRAM del emulador sale lo contrario de lo esperado: sin redondear cuadran 18.011 de 18.432 pixels, y redondeando solo 17.756. Algo falta en la cadena. Queda escrito como pregunta, no como conclusion.
La tabla de variables congelada del propio cartucho confirma que DEFINT D esta activo -DX, DY, DZ, DD, DA, DB y D4-D7 estan guardadas como enteras de dos bytes, y DI() como array de enteros-, asi que la duda no es si la directiva funciona: es que falta entender por que el dibujo sale mejor sin aplicarla.
De los 18.432 pixels de la vista del hoyo 1, 421 no cuadran con el emulador. Todos son pixels de borde de las mismas lineas, desplazados uno: las lineas estan donde tienen que estar, pero el escalonado difiere. Se probaron seis variantes del trazado -error inicial a 0, a la mitad, a la mitad mas uno, al maximo, a uno, y con los extremos intercambiados- y todas se quedan entre el 97,4 % y el 97,8 %. Tampoco lo arregla emular la precision de seis digitos del interprete.
Se lee entera y encaja: 98 variables sueltas y nueve arrays, en el orden del programa, y el ultimo se corta a 25 bytes de terminar porque en 0xB000 empiezan los datos de campo. Lo que no se ha hecho es comprobar valor por valor que cada una de las 98 lleva lo que le tocaria en ese momento de la partida: se han comprobado las que sirven para atar la lectura del campo (H, ZM, HX, HZ, P), y las demas se han dado por buenas porque el patron encaja.
De 0xBFA0 a 0xBFFF hay 96 bytes que no lee nadie: el noveno hoyo termina en 0xBF9F y ahi se acaba todo lo que el programa consulta. No son cero -tienen contenido- pero ninguna linea llega hasta ahi. Lo mas probable es que sean lo que quedaba en memoria al grabar la ROM, como la tabla de variables, pero no esta comprobado.
Los nueve estan decodificados y dibujados, y las tres comprobaciones cruzadas cuadran en los nueve. Pero contra la VRAM del emulador solo se ha comparado el hoyo 1, porque para ver el 2 hay que embocar el 1, y no hay forma comoda de automatizarlo: el programa no tiene ningun atajo para cambiar de hoyo y la partida no se puede rebobinar.
Los otros ocho salen del mismo motor y de los mismos datos, y su lectura la respalda ademas la partida congelada del cartucho, que apunta al hoyo 3. Pero comparados byte a byte contra la maquina, uno.