Lo que el cartucho dibuja
Debajo de cada imagen esta de donde sale y que se esta viendo.
Aqui no hay ninguna captura. Todas las imagenes estan dibujadas desde los bytes de la ROM, ejecutando en Python el mismo interprete de guiones que corre el Z80. El listado y las cifras se reproducen con make.
SCREEN 2 son tres tercios independientes, y para que los tres tengan lo mismo hay que escribirlo tres veces. 0x4485 copia de VRAM a VRAM byte a byte, y le mandan 4.095 bytes de 0x0000 a 0x0800: como el destino va 0x800 por delante, pasado el primer bloque esta leyendo lo que el mismo acaba de escribir. Un bucle, tres tercios iguales, 4 KB ahorrados. Se hace dos veces: colores y patrones.
Y se queda un byte corto: 4.095 y no 4.096, asi que el ultimo byte del tercer tercio no se llega a escribir nunca.
En SCREEN 2 el TMS9918 no lee R3 y R4 como una direccion, sino como un bit de base y una mascara. Con R4 = 0x07 los patrones quedan en 0x2000 y con R3 = 0x7F los colores en 0x0000, al reves de lo habitual.
La tabla de registros de este cartucho y la de King's Valley son identicas salvo un byte, el del color de borde: 02 E2 0E 7F 07 76 03 E1 contra ... E4.
La parrilla de eleccion no ensena nombres: ensena iniciales. Los doce bytes de 0x4649 son tiles, y dibujando la fuente desde la ROM se leen: C D G S T W para la Central -Carp, Dragons, Giants, Swallows, Tigers, Whales- y B Bu F H L O para la Pacific -Braves, Buffaloes, Fighters, Hawks, Lions, Orions-. Los doce equipos de la Nippon Professional Baseball de 1984, en orden alfabetico dentro de cada liga.
Y hay un tile hecho a proposito para esto: el 0xE8 es una "Bu" en un solo caracter, que existe solo para que los Buffaloes no se confundan con los Braves.
No hay una via aparte para el rival. 0x7d04 calcula que haria un jugador y lo deja escrito en 0xE011, que es el mismo byte donde 0x43e2 pone los bits recien pulsados del segundo jugador. La demostracion del menu hace lo mismo con 0xE00E, el del primero.
Por eso el resto del cartucho -el bateo, la carrera, el lanzamiento- no sabe ni le importa si le esta jugando una persona o el propio cartucho. Y por eso, cuando manda la demostracion, 0x6c0e se niega a hacer sonar nada: la partida automatica es muda.
Cada postura de jugador son tres guiones -uno por capa de color- y detras van seis bytes de desplazamiento. En 21 de las 22 posturas, el puntero a esos seis bytes apunta AL 0x00 QUE CIERRA EL TERCER GUION: ese byte hace las dos cosas a la vez, cerrar el guion y ser el desplazamiento en fila de la primera capa.
La unica que no lo hace es la de 0x50EC, y es porque su primer desplazamiento vale 1 y no 0. Un byte ahorrado por postura, veintiuna veces.
No hay escalado: hay cinco dibujos distintos en 0x6573, de siete filas a dos. 0x646b elige entre ellos restando la fila de la sombra menos la de la pelota -que es la altura- y comparando con 0x21, 0x0F y 0x06, y baja uno mas si la sombra esta por encima de la fila 0x40, o sea si la jugada va lejos.
El bote no se calcula: ocurre cuando la fila de la pelota alcanza a la de su sombra.
0x4582 no recibe nada en registros: hace ex (sp),hl, lee del propio codigo los dos bytes que siguen al call, adelanta la direccion de retorno para que no se ejecuten, y se pone a dibujar. Hay nueve sitios que llaman asi.
Sin saberlo, un desensamblador toma esos dieciocho bytes por instrucciones. El binario vuelve a salir identico -son los mismos bytes- pero el listado miente, y no hay manera de que el reensamblado lo cace.
Las quince fichas de los jugadores de campo ocupan 21 bytes en la ROM y 32 en RAM. Quince por 32 llenan exactamente 0xE180..0xE35F, justo hasta donde empieza el medidor: por arriba cuadra.
Por abajo no: quince por 21 son 315 bytes y de 0x5C03 a 0x5D3B hay 312. Los tres que faltan son los tres primeros de la rutina de 0x5D3B -21 00 E1, o sea ld hl,0e100h- y acaban dentro de la ficha numero quince.
99 bytes en 0x4AF0 que son un guion perfectamente valido: cargan cuatro patrones de sprite en la VRAM 0x1800, otros cuatro en 0x1D00 y cinco atributos, y acaban exactamente donde vuelve a haber codigo.
No los dibuja nadie. El guion de antes acaba justo ahi pero no encadena; en toda la ROM no hay un solo valor inmediato de 16 bits entre 0x4AF0 y 0x4B53; las dos tablas de punteros a guiones apuntan dentro de sus propios bloques; y los nueve call 0x4582 llevan su argumento escrito al lado y ninguno es este.
El borrado de la pantalla son tres pasadas con B a cero. No son pasadas vacias: el Z80 decrementa antes de comprobar, asi que un djnz con B a cero da 256 vueltas. Tres por 256 son las 768 posiciones de la tabla de nombres, escritas sin que la cuenta aparezca en ningun sitio.
La A es 0xDA, la B 0xD0 y la C 0xD6. No hay ningun orden: hay las 24 letras que el cartucho llega a escribir, puestas segun fueron haciendo falta. Y en medio, un regalo: los tiles 0xD8 a 0xDE son P L A Y E R S seguidos, que es lo que permite escribir "1 PLAYER" y "2 PLAYERS" sin tabla ninguna.
Las cifras si van seguidas, 0xF0 mas el digito, y por eso el marcador y la cuenta se escriben con un simple or 0f0h.
Konami escondia su numero de catalogo y el titulo en katakana al final de muchos cartuchos; lo descubrio Manuel Pazos (@ManuelPazosMSX). Este la lleva en 0x7FF6: RC-724 y YA KI U, que es 野球 (yakyu), beisbol.
Debajo de cada imagen esta de donde sale y que se esta viendo.