Aquí no hay ni una captura de pantalla. Las imágenes están dibujadas repitiendo lo que hace el cartucho: se sube a la memoria de vídeo lo mismo que sube él, con sus mismas direcciones, y las filas del río y de la carretera se montan con su mismo motor de carriles. Lo demás —el listado y las cifras— sale del binario y se reproduce con make.
No se parecen: son el mismo código. Los 163 bytes de 0x4111–0x41B3 de este cartucho y los de 0x4160–0x4202 de Time Pilot (RC-703) coinciden byte a byte salvo en tres, y dos de esos tres son el byte bajo de un puntero reubicado: 0x41A1 aquí y 0x41F0 allí, exactamente el desfase de 0x4F que separa las dos copias.
El tercero es el único que dice algo distinto: el registro 7 del PSG, la mezcla. Vale 0xA8 aquí y 0x98 allí, o sea que el ruido suena en el canal B en Frogger y en el C en Time Pilot. En los dos cartuchos el reproductor está colocado justo antes de INIT.
Cuando el juego se queda solo, la rana no la mueve ningún generador de números: se lee una lista. Está en 0x584F y son quince bytes, uno por movimiento y con el mismo formato que los mandos:
00 08 01 01 01 01 01 08 01 01 01 01 08 00 01
Es decir: espera, derecha, cinco veces arriba, derecha, cuatro arriba, derecha, espera y una más arriba. El puntero vuelve al principio al montar cada fase, y como solo se le incrementa el byte bajo, la lista no puede cruzar de página.
La fase se elige con (fase-1) mod 5 sobre una tabla de cinco palabras… pero la segunda y la tercera apuntan al mismo sitio, a 0x5CCD. Las fases 2 y 3 llevan exactamente el mismo trazado de río y carretera.
Lo único que las separa son dos retoques que hace 0x5493 cuando toca el tercer hueco: el primer objeto de la fila de arriba pasa a ser cocodrilo, y a la fila 15 se le pone el bit de «último» al segundo objeto, con lo que esa fila se queda con dos en vez de tres.
Hundirse no es una propiedad de ser tortuga: es un bit. El cuarto byte de la ficha lleva un contador, y solo se anima si tiene el bit 7 puesto. Al montar la fase, 0x5489 lo pone en exactamente dos direcciones: 0xE0C3 y 0xE0EB, o sea el primer grupo de la fila 5 y el segundo de la fila 9.
Y no arrancan iguales: uno empieza en 0x80 y el otro en 0x8A, para que no se hundan a la vez. A partir de la fase 6, 0x54D6 añade una tercera (0xE0E7, con el contador en 0x8F).
En todo el cartucho hay cuatro comparaciones contra el número de fase, y ninguna más: en la 2 ocho objetos del río suben dos de tipo (0x54A8), en la 3 aparece la rana que hay que rescatar (0x506A), en la 6 dos carriles pasan a moverse un paso por turno y se añade la tercera tortuga que se hunde (0x54C9), y en la 11 la fila 7 se queda con un solo objeto (0x54DB).
De ahí en adelante lo único que cambia es cuál de los cuatro trazados toca, y eso cicla cada cinco fases. La 11, la 47 y la 99 se juegan exactamente igual.
Y no hay final: en la fase 100 el contador vuelve a 1 (0x53F5) y el número del marcador, que es BCD, vuelve a 01. Sin rótulo, sin música y sin pantalla.
Las cinco casas están en las columnas 4, 8, 12, 16 y 20, y cada una tiene su bit en 0xE080. Cuando la rana entra en una, 0x528F mira ese bit; si ya estaba puesto, no hay aviso ni rebote: jp 0x5305, que es la rutina de la muerte.
El MSX1 solo puede enseñar cuatro sprites en una línea, así que Frogger los reserva para la rana y el cocodrilo. Todo lo demás son caracteres.
Para moverlos sin saltos, 0x473C guarda en la memoria de vídeo cuatro versiones de cada dibujo, desplazadas 0, 2, 4 y 6 píxeles: corre el juego entero de patrones dos bits y deja que los bits que se salen entren en el carácter de al lado. La posición de cada objeto va en cuartos de carácter, y sus dos bits de abajo eligen la versión.
SCREEN 2 tiene los patrones y los colores partidos en tres tercios de 2 KB, y el juego los quiere iguales. En vez de tres copias, 0x471A hace una de 4095 bytes con el destino 2 KB por delante del origen: al pasar del primer tercio ya está leyendo lo que acaba de escribir, así que el segundo se propaga solo al tercero.
En SCREEN 2 el color va por línea de patrón, no por casilla: dos casillas con el mismo carácter no pueden tener colores distintos. Así que INIT sube el juego de letras dos veces, a los caracteres 0x98 y 0xD8 (0x4235 y 0x4240 repiten los bytes que ya había subido el bloque anterior).
La tabla de color que se carga justo después da cian a los primeros y blanco a los segundos: por eso el menú del título sale en cian y el marcador de la partida en blanco.
En 0x57F7 hay seis bytes de código perfectamente formado: la versión para tablas de un byte del buscador de 0x57FF, que devuelve en B el byte número A de una tabla incrustada detrás del call y salta al byte de después del 0xFF que la cierra.
Funciona. Pero ninguna instrucción del cartucho la llama: las cuatro llamadas que hay van todas a la versión de dos bytes.
Cada una de estas imágenes es el cartucho repetido fuera de él: los caracteres se suben como los sube la ROM, con sus colores, y las filas se montan con el mismo motor de carriles. Debajo de cada pie está la dirección de donde sale.
