Aquí no hay ni una captura de pantalla. Todas las imágenes están reconstruidas: las dibuja una herramienta que repite, instrucción a instrucción, las rutinas de carga y los dos intérpretes de dibujo del cartucho sobre una memoria de vídeo vacía, y luego revela esa VRAM como la revelaría el VDP. Que la mesa salga bien es la prueba de que las rutinas se han entendido bien. El listado y las cifras salen del binario y se reproducen con make.
La tabla de la mesa (0xE100) tiene ocho registros de dieciséis bytes, pero el bucle de la física sólo recorre siete: se para en 0xE16F. El octavo, 0xE170, es el punto al que se apunta, y de restarle la posición de la bola blanca sale el vector del tiro (0x4CA8).
Se dibuja como los demás —es ese punto pequeño que se ve a la derecha de la mesa— porque el refresco de sprites vuelca dos grupos de cuatro, o sea las ocho entradas.
0xE18F y 0xE1EA no guardan nada. Están colocadas para que su byte +7 y su byte +9 caigan justo encima de un par de variables sueltas, que es donde una bola de verdad tiene las dos componentes de su velocidad.
Con eso, la rutina que saca la pendiente y el ángulo de una bola (0x5430) sirve sin cambiarle una línea para medir el ángulo de la recta que une dos centros, en el choque, y el de la blanca a la mira, en el attract. Un puntero bien elegido en vez de una segunda rutina.
No hay código de juego aparte para la demostración. Lo que hace 0x5EEC es medir el ángulo de la blanca a la primera bola que quede en la mesa, compararlo con el de la mira y, cuando coinciden con un grado de margen, escribir 0x10 en 0xE009.
0xE008 y 0xE009 son las dos variables donde el juego deja las teclas del cuadro anterior y las de este; 0x10 es el bit del botón de tiro. La máquina no llama a la rutina de tirar: finge la pulsación y deja que el juego la lea como si fuera de una persona.
Las bocas de las troneras están achaflanadas en diagonal, y el cartucho las resuelve mirando la suma y la resta de las dos coordenadas: sobre una diagonal de 45°, una de las dos vale siempre lo mismo.
Y para rebotar en ella basta con intercambiar las dos componentes de la velocidad (0x5923), o intercambiarlas y cambiarles el signo si es la otra diagonal (0x593B). Reflejar en un espejo a 45° es exactamente eso, y sale gratis.
0x5376 saca la raíz por el método de los impares: resta 1, luego 0, luego 2 y 2, luego 4 y 4… y devuelve cuántas vueltas ha aguantado. Es una docena de bytes.
Pasada por los 65.536 valores posibles de entrada, devuelve exactamente round(sqrt(n)): la raíz redondeada al entero más cercano, no la truncada, que es lo que suelen dar estas rutinas. Se usa para la distancia entre la bola y la mira, y medio píxel importa cuando de ahí sale la dirección del tiro.
El indicador SPEED no responde a las teclas. La misma rutina que lo pinta (0x5314) lo adelanta un paso cada vez que se la llama, y cicla 1, 2, 3, 1, 2, 3… La llamada entra una vez cada sesenta y cuatro cuadros.
Así que la fuerza del tiro no se elige, se caza: hay que apretar el botón en el momento en que la barra está donde interesa. La máquina, en el attract, sólo dispara con la barra al máximo.
Manuel Pazos descubrió que los cartuchos de Konami de esta época esconden al final de la ROM su número de catálogo RC-7xx y el título en katakana. Aquí no está: no hay un solo RC-7 en ASCII en los 16 KB, y el final del chip son 8.269 bytes de 0xFF seguidos desde 0x5FB3.
El RC-706 de la ficha de esta página sale del catálogo, no del binario.
Debajo de cada pie está la dirección de donde sale. Todas son reconstruidas: se rehacen con make imagenes y no hace falta emulador.