Aqui no hay ninguna captura. Todas las imagenes estan dibujadas desde los bytes de la ROM, ejecutando en Python los dos interpretes de guiones que corre el Z80. El listado y las cifras se reproducen con make, y el reensamblado devuelve la ROM byte a byte.
En SCREEN 2 lo normal es poner los patrones en 0x0000 y los colores en 0x2000. Este cartucho lo hace al reves, y no se ve en ninguna direccion: se ve en los registros. tabla_registros_vdp (0x45C0) vale 02 E2 0E 7F 07 76 03 E4, y en SCREEN 2 los registros 3 y 4 no son una direccion sino base mas mascara: el bit 7 de R3 a cero pone el color en 0x0000, y el bit 2 de R4 a uno pone los patrones en 0x2000.
El propio codigo lo confirma sin ambiguedad: 0x4831 dibuja el logotipo con ld hl,06300h, y 0x6300 enmascarado a catorce bits es 0x2300, dentro de la tabla de patrones. Leerlo al derecho da formas correctas y colores a franjas.
La X no es un byte ni dos: son tres. 0x73F6 suma la velocidad con add hl,de sobre 0xE138/0xE139 y propaga el acarreo a 0xE13A con adc a,c. El byte de menos peso es la fraccion, en 1/256 de pixel, y los dos de mas peso son justo los que lee_celda_de_sala toma como X entera para mirar celdas.
Hace falta tanta X porque la sala es mas ancha que la pantalla: las salas pares miden 64 columnas, 512 pixeles, y no caben en un byte. Cuando el explorador sale por un lateral, la tarea 9 hace ld (0e139h),bc y le cambia el byte alto en uno: un salto de 256 pixeles, una pantalla entera.
Cinco recorridos de entidades hacen ld hl,<cierre> / push hl antes de despachar, de modo que el ret de la rutina despachada no vuelve al llamador: cae en el cierre, que sube el indice y repite el bucle. Un trazador estatico no puede seguir eso, porque la direccion viaja por la pila como si fuera un dato.
Por eso 87 bytes salian como "sin identificar". Los cinco cierres tienen la misma forma -ld hl,<indice> / inc (hl) / cp (hl) / jp nz,<cuerpo>- y el cuerpo al que saltan es exactamente la etiqueta que los apila.
0x4501 son diecinueve bytes que decodifican como otra variante de dibujar un guion en los tres tercios. 0x4542 son diez bytes que son la pareja de prepara_escritura_vdp para LEER de la VRAM: llama a SETRD y coge el puerto de lectura de 0x0007, igual que la otra coge el de escritura de 0x0006.
Ninguna se llama, y no es una impresion: los pares de bytes 01 45 y 42 45 no aparecen en ningun sitio de los 16.384, comprobado byte a byte. La segunda cuenta algo del diseno del juego: este cartucho nunca lee de la VRAM. Escribe y se olvida.
El juego lleva seis tablas paralelas de entidades y cada una tiene su propia rutina de acceso. No hay que suponer el tamano de cada entrada: esta en la multiplicacion. 0x6A12 hace i, 3i, 7i con B llevando las potencias de dos, o sea paso 7; 0x65A5 llega a 9i; 0x5AF6 entra a media cadena y llega a 17i; y 0x73D3 hace 2i, 6i, 22i.
Leer el descriptor de nivel byte a byte dice que hay en cada una: paso 7 las puertas de salida y las puertas giratorias, paso 9 las gemas y los muros trampa, paso 17 los cuchillos ya lanzados y paso 22 las momias. Las de paso 7 y 9 comparten indice, pero no son la misma entidad partida en dos: son las puertas y las gemas, y lo que comparten es una variable de contador.
actualiza_tabla_de_sprites escribe siempre los mismos cuatro sprites en la tabla de atributos, pero empezando cada fotograma por uno distinto de un anillo de cuatro entradas, que gira con un contador en 0xE061.
No es un adorno. En el MSX1 solo se ven cuatro sprites por linea y gana el de numero mas bajo; al girar el orden de escritura, el que se pierde cambia en cada fotograma y los cuatro parpadean por igual en vez de desaparecer siempre el mismo.
Las salas salian negras sobre negro hasta dar con quien pone el color de los tiles de pared y suelo. No es prepara_sala_nueva: es columna_decorativa (0x6DA0), y el guion que usa depende del grupo de cuatro niveles -0x6DC4 mas 9 por grupo, con el grupo sacado de (nivel-1) >> 2-.
Por eso las cuatro primeras salas son de piedra ocre y las siguientes cambian de color, con el mismo dibujo de ladrillo: lo unico que cambia son los ocho bytes de color.
Los rotulos del cartucho no estan en ASCII ni en una fuente propia con tabla: estan en ASCII desplazado 0x20 hacia abajo. Los bytes 2B 2F 2E 21 2D 29 mas 0x20 dan KONAMI, y con la misma suma salen SCORE, HI, REST, PUSH SPACE KEY, PLAY START, GAME OVER, SOFTWARE y PYRAMID. El 0x00 es el espacio y el 0x1A el simbolo de copyright.
Dos rutinas escriben dentro del propio espacio del cartucho, y corriendo desde ROM ninguna hace nada. No son codigo muerto: son proteccion anticopia, y que no hagan nada es la gracia. Un cartucho pirateado es una copia en RAM, y ahi las escrituras si cuelan.
0x403E machaca el primer byte de la tarea 1 con un pop hl + ret; 0x409C escribe DE encima de 0x43C0, que es el operando del jp nc de 0x43BF. Las identifico Manuel Pazos en su desensamblado de 2009; este proyecto tenia una escrita como parche fallido y la otra como direccion de relleno.
En 0x5817 nuestra ROM tiene las tres comparaciones sueltas que la segunda compilacion sustituye por dos restas, y la firma de la segunda no aparece en ninguno de los 16.384 bytes. Lo desensamblado aqui es la version 1, con sus fallos: lanzar un cuchillo mientras la puerta se abre corrompe sus tiles, lanzarlo pegado a un objeto lo atraviesa, y dos muros trampa estan mal colocados.
El pop de de 0x6B0E devuelve el puntero a la banda que se acaba de desempaquetar, asi que el cp 030h de dos instrucciones despues mira ESA banda y no la siguiente: la banda 0x3x se dibuja y ademas cierra la lista. Leido al reves se pierde una banda por sala.
El arreglo no es una opinion: el buffer de sala se comparo contra la RAM de una maquina de verdad en las quince piramides, 31.680 celdas sin una diferencia, y las pantallas dibujadas contra su VRAM -nombres, patrones, color y sprites-, tambien con cero.
Konami escondio su numero de catalogo y el titulo en katakana al final de muchos cartuchos; lo descubrio Manuel Pazos (@ManuelPazosMSX). Este lo lleva, cerrando en 0x7FFF: RC-727 y OU KE NO TA NI, que es el titulo japones del juego, 王家の谷, el Valle de los Reyes.
Debajo de cada imagen esta de donde sale y que se esta viendo.
rotulo_horizontal (0x76A7) escribe un tile de remate y va rellenando hacia un lado, bajando una fila y creciendo una celda en cada vuelta hasta pasar de la VRAM 0x3A80
prepara_sala_nueva (0x4FC9). Los tiles de pared ya estan cargados pero todavia sin color: ese lo pone columna_decorativa despues, y es lo que hace que cada grupo de cuatro salas tenga su piedra