Lo que queda abierto, separando lo MEDIDO de lo SUPUESTO.
Las otras paginas: Empezar · El juego · La cinta · El codigo · Hallazgos Lo medido lleva al lado la medida; lo supuesto va marcado como tal y no se ha escrito en el listado como si fuera un hecho.
DEMON: un ASCII (el cargador BASIC), un BIN de 249 bytes en 0x8180 y un BIN de 24.576 bytes en 0x8000. Entre los dos BIN van siete bloques SIN cabecera.BLOAD"CAS:DEMON",R:RUN. Como la cinta es secuencial, la primera vez encuentra el BIN pequeno y la segunda -despues del RUN- el grande. Los dos se llaman igual a proposito.make verify reconstruye el .cas entero, sha256 69031ee25099df0703332ca74a64b52e6dd9909e4cfded4c3699be153adc5fc9.tools/cuerpos.py comprueba que cada entrada cuadra con el tamano de su bloque y aborta si no.tools/coteja_ram.py), y tambien con las instantaneas de RAM que lleva dentro el replay Demonia.omr, que se grabo en otra maquina (un Sony HB-20P). Dos medidas independientes.0xFF <baldosa> <cuantas>. Descomprimidos dan 640 baldosas (32x20) cada uno y terminan exactamente donde empieza el siguiente. El descompresor es 0x819D.El juego se llama DEMONIA, y lo pone su propia portada: el mapa comprimido de 0x4281, descomprimido y dibujado con sus patrones (tools/mapas.py, PNG en docs/imagenes/portada-titulo.png), lleva DEMONIA en letras enormes ocupando las ocho primeras filas. Debajo, en letras pequenas, L'INTRUSION en la fila 17 y (C) 1986 PAR SABLATOU CLAUDE en la 19.
Esas dos filas de abajo son las unicas que se leen si el mapa se vuelca como TEXTO, porque el titulo esta hecho de baldosas graficas y no de ASCII. Un volcado asi engano una vez y de ahi salio la idea de que el juego se titulaba L'INTRUSION: es el subtitulo. La cinta tambien se llama DEMONIA.
ld hl,(0x8078) del tampon de paso a paso de 0xCC5F sea el fosil de una sesion de depuracion de este juego. Lo medido son los cuatro bytes y que 0x8078 cae en la pagina de variables. Encaja, pero no lo dice el binario.Demonia.omr se grabo en un Sony HB-20P y openMSX pide su ROM por sha1 (63050d2d21214a721cc55f152c22b7be8061ac33). Esa ROM no esta en esta maquina y no se puede descargar.
Se intento tres veces:
tools/prepara_replay.py. La ruta se corrige (24 referencias), pero el fallo era otro.filepool propio, sin tocar la instalacion del usuario. openMSX resuelve las ROM de sistema por sha1, no por nombre, y la rechaza..omr para que apunte a la sustituta. El replay carga y corre los 926 segundos, pero con otra ROM la carga de cinta se desincroniza: el 100 % de las 1.854.327 muestras del PC caen en las rutinas de casete de la BIOS (0x046F, 0x047B, 0x1B2A...) y el juego no llega a arrancar. La medida no vale y no se ha usado.Lo que si se saco del replay, sin emulador: abriendolo con gzip y descomprimiendo sus doce instantaneas de RAM. Desde la cuarta (t=256 s) el bloque del juego coincide al 99,5 % con el de la cinta, y los cinco trozos escondidos bajo la ROM coinciden al 100 %. O sea que en la partida de verdad el reparto de memoria es exactamente el que dice este proyecto. Las instantaneas estan en work/replay/ram_snapNN.bin si se vuelven a extraer.
Para cerrarlo hace falta: el fichero hb-20p_basic-bios1.rom con ese sha1 en ~/Documents/openMSX/share/systemroms/. Con eso, tools/omsx_replay.tcl da el muestreo del PC de una partida entera y la seccion 6 de Hallazgos deja de ser un dato flojo.
Ya se ha jugado, y esta contado en El juego: una partida en openMSX sobre un Philips VG-8020 con la cinta de verdad. De ahi salen medidos el mando (cursores por GTSTCK, barra espaciadora por GTTRIG), que el jugador se mueve -su X, en 0x8049, va de 128 a 152 y vuelve-, el marcador con SCORE=, RECORD= y la barra FORCE=, y la comprobacion buena: la primera pantalla que pinta el emulador es identica al mapa que tools/mapas.py dibuja desde los bytes de 0x43DE, sin emulador ninguno.
Lo que sigue abierto es la partida ENTERA: visitar las 24 pantallas, ver morir al personaje y llegar al GAME OVER, y atar cada pantalla con su ficha de 88 bytes y sus cuatro rutinas de conducta. Sintetizar pulsaciones sirve para andar un rato, no para jugarse un juego; para eso el camino bueno sigue siendo el replay del punto 1.
Se sabe que son 24 fichas de 88 bytes en 0xD0C0-0xD8FF y que el byte 84 de cada una lleva la marca FF <numero de pantalla en ASCII> FF. No se ha desmenuzado el resto de los 88 bytes campo a campo. Se ve que hay grupos de tres bytes que empiezan por 0x06, 0x0E, 0x15 y 0x1B -numeros que crecen y que podrian ser posiciones- pero eso es una impresion, no una medida, y por eso no esta en el listado.
Quedan doce tramos de datos con nombre pero sin uso explicado, porque se sabe QUIEN los lee pero no PARA QUE. Son: 0x89F1, 0x8C58, 0x9B47, 0xA5E4, 0xA7FF, 0xB4F0, 0xB540, 0xBA64, 0xBDB1, 0xDAD7 y las dos de baldosas 0xA830 y 0xDAA3. En el listado estan con la direccion de la instruccion que las carga, que es lo que se sabe.
De 0xB4F0 si se sabe la forma: siete registros de diez bytes, y los campos avanzan a paso fijo de un registro al siguiente (+0x18 en el tercer byte, +0x300 en la pareja siguiente, +1 en el octavo). Parece una tabla de siete cosas iguales colocadas en fila; que cosas, no se ha medido.
El reproductor de 0x7F90 cambia de nota cada 14 llamadas (0x7F9B). No se ha medido a cuantas llamadas por segundo va, asi que no se puede dar un tempo en notas por minuto ni decir si eso depende de PAL o NTSC. Lo que si esta medido son los periodos del PSG: el primer paso da 679 en el canal B y 339 en el C, o sea 329,5 Hz y 659,1 Hz con el reloj del MSX (3.579.545/16), la misma nota a una octava.
En 0x823A hay tres RET NC seguidos donde con uno bastaba: el primero ya vuelve. No se ha encontrado explicacion. Puede ser un salto relativo que se cambio por un RET y dejo dos bytes detras, pero eso es una suposicion.