Metal Gear — partidas en el Yamanooto

Metal Gear graba en cinta. El parche desvía las 20 llamadas del juego a la BIOS de la cinta hacia una cinta virtual en la flash del cartucho: el nombre del fichero, el SKIP/FOUND, el VERIFY y los reintentos siguen siendo los del juego. Caben 3 partidas.

109 bytes cambiados en 34 tramos · driver de 8 KB · un sector de 64 KB · no se distribuye ninguna ROM

Cómo se juega

Como con la cinta: pausa (F1), F5 graba y F4 carga; también se carga desde el Game Over. El nombre que se teclea (hasta 6 letras) es el slot: con un nombre que ya existe se sobrescribe esa partida; con uno nuevo va al primer slot libre, y si no queda ninguno el juego dice SAVE ERROR.

Ojo, esto es del juego y no del parche: lo que se graba es la foto de la partida que el juego toma en los puntos de control (los ascensores). Lo recogido después del último ascensor no está en la partida grabada, igual que con una cinta de verdad.

Lo que hace falta

• La ROM del juego, que este repositorio no distribuye: Metal Gear (Konami, 1987, RC-750), 131.072 bytes, sha256 999b5a97488d0dd479aab8c467be14233eb7437cbd1d37cf348765dfeed8429d. Es el volcado con el que se probó; el parcheador comprueba cada sitio, así que con otro volcado se niega en vez de estropearlo.
• Python 3.
• Un Yamanooto de 2 MB o de 8 MB.

Montar la imagen

python tools/imagen.py metalgear.rom

Sale metalgear_yamanooto.rom (256 KB), lista para grabar en el cartucho desde el principio de la flash: arranca el juego solo, sin menú. Grabarla sustituye el menú y los juegos que tenga el cartucho. En openMSX:

openmsx -cart metalgear_yamanooto.rom -romtype Yamanooto

make test pasa los 4 tests: los .bin salen de sus .asm, el parcheador rechaza otra ROM y, con la ROM en la raíz, fuera de los tramos que declara el parcheador el juego es el original byte a byte y la imagen es la de referencia.

Cómo funciona por dentro

• Los 13 cambios de banco del juego (ld (6000h/8000h/0A000h),a, todos en el banco 0) pasan a los registros Konami SCC de la misma ventana (7000h/9000h/B000h): es el modo con el que arranca el Yamanooto, así que el juego arranca solo desde el principio de la flash.
• Las 20 llamadas a la BIOS de la cinta (TAPION, TAPIN, TAPIOF, TAPOON, TAPOUT y TAPOOF) están en el banco 0x0F, el de grabar y cargar. Cada una se reapunta a una de seis entradas escritas en el relleno de ese banco: 56 bytes en 0xBFA7.
• Esas entradas ponen el driver (launcher/mg1_driver.asm, 8 KB añadidos como banco 0x10) en la ventana 0x8000 con las interrupciones cortadas, porque la interrupción del juego cambia de banco para el sonido.
• El driver hace de cinta: sirve los bloques de las partidas grabadas y recoge los que el juego escribe. Cada slot es [0xA5][nombre de 6][largo de 2][0x301 bytes de datos], cada 0x400 bytes de un sector de 64 KB de la flash (banco relativo 0x18). Al cerrar el bloque de datos se copia el principio del sector a la RAM (0xD800), se borra el sector y se vuelve a programar desde un motor en RAM (0xF100). El VERIFY del juego lee luego la flash de verdad.
• Las direcciones salen del desensamblado comentado de Manuel Pazos (GuillianSeed/MetalGear), comprobadas byte a byte en el volcado de arriba.

De dónde sale

Sale de nPackR, que lo usa para meter el juego en una colección. Aquí va suelto: la imagen arranca el juego directamente, sin menú. Licencia GPL v3 (LICENSE) y una nota de uso no comercial (NOTICE.md).

Probado

En openMSX el 2026-07-05: grabar en un ascensor, apagar y cargar.