TraysiaROMFix v2.0.0: desensamblando el sistema de guardado de Traysia para Mega Drive

Hace un año os contamos cómo habíamos empezado a investigar los reportes de partidas corruptas en la reedición física de Traysia que Shinyuden lanzó en 2025 para Mega Drive, y publicamos una primera versión de TraysiaROMFix. Ya avisábamos entonces de una limitación importante: no habíamos podido reproducir el bug en condiciones reales. Ese fleco no nos dejaba tranquilos, así que decidimos ir hasta el fondo: desensamblar por completo el sistema de guardado de la ROM y auditar, byte a byte, todo lo que la edición de Shinyuden cambia respecto a las versiones originales. Lo que encontramos nos obligó a replantear el proyecto entero — y el resultado es TraysiaROMFix v2.0.0.

Lo que Traysia hace de verdad al guardar

La primera sorpresa fue descubrir que el juego original de 1992 tiene un sistema de guardado sorprendentemente robusto para su época. Nada de estructuras frágiles: la SRAM de 8 KB se organiza con una firma de validez escrita por triplicado (" SRAM_save_data "), y cada uno de los 4 slots de partida guarda tres copias redundantes de unos 600 bytes con suma de verificación. Al escribir, cada byte se verifica y se reintenta hasta 15 veces; al leer, las tres copias se comparan con voto por mayoría. Si todo falla, pantalla de error.

La segunda sorpresa: el sistema de guardado de la ROM de Shinyuden es idéntico byte a byte al de la versión USA. La adaptación española no tocó ni una sola instrucción de las rutinas de guardado. De hecho, el motor completo deriva de la build americana: apenas ~10.400 bytes cambian en el primer megabyte, casi todos texto traducido y punteros.

Entonces, si las rutinas de guardado son las originales… ¿de dónde puede venir la corrupción?

El hallazgo: un monitor de depuración fantasma apuntando a la SRAM

Los desarrolladores de 1992 dejaron en el juego los ganchos de su monitor de depuración, que en las placas de desarrollo vivía en la dirección $100000, justo después del ROM de 1 MB. Cualquier excepción de la CPU (14 vectores: bus error, address error, instrucción ilegal, división por cero…) salta ahí. Y el motor de texto comprueba, antes de leer cada byte de diálogo, si su puntero se ha salido del ROM — y en ese caso, también salta ahí. En el cartucho original aquello era el vacío: si algo llegaba, el juego ya estaba colgado.

Al expandir la ROM a 2 MB para la traducción, esas 16 referencias se reubicaron mecánicamente de $100000 a $200000. El problema es que en el cartucho físico $200000 ya no es el vacío: es la ventana de la SRAM donde viven las partidas guardadas. Con la ROM actual, cualquier excepción de CPU o cualquier puntero de texto defectuoso hace que la consola se ponga a ejecutar como código el contenido de la SRAM, con la CPU corriendo dentro de memoria escribible y un comportamiento que depende del contenido de la partida de cada jugador. Eso encaja con todo lo observado: fallos esporádicos y difíciles de reproducir, solo en hardware real, y esos misteriosos «textos en japonés» (el motor de texto sigue siendo el japonés por dentro — la traducción usa códigos Shift-JIS para ¡, ¿ y las tildes — y un estado corrupto hace que renderice glifos japoneses al azar).

El nuevo parche: Anticrash SRAM

El parche de la v2.0.0 es quirúrgico: 34 bytes en 15 puntos, sin tocar ninguna lógica del juego. Los 14 vectores de excepción pasan a hacer un reinicio limpio a través del bootstrap oficial de Sega (se pierde lo no guardado, nunca la partida salvada), y el guard del motor de texto pasa a comportarse como un fin de cadena: un puntero defectuoso corta el diálogo en vez de ejecutar la SRAM.

Podéis aplicarlo con Lunar IPS o con el script Python del repositorio, y verificar el resultado:

Y recordad el detalle que ya contamos en su día: la PCB de Shinyuden es reprogramable por USB, así que la ROM corregida puede flashearse directamente en el cartucho físico.

Honestidad ante todo: qué falta por validar

Como en la primera entrega, seremos claros: esta hipótesis está verificada a nivel de desensamblado, pero sigue pendiente de validación empírica. Es el único defecto estructural que aparece al auditar todos los cambios de la ROM, y saltar a la SRAM nunca es correcto — pero aún no hemos capturado el bug ocurriendo en vivo. Si queréis ayudar, en el README del proyecto hay un plan de validación detallado: desde poner un breakpoint en PC=$200000 con un emulador con depurador hasta lo más valioso de todo — conseguir el archivo .srm de un cartucho afectado sin pasarlo antes por ninguna herramienta.

El parche anterior queda retirado y la release v1.0.0 marcada como obsoleta; todo el material de aquella fase se conserva en el historial de git como registro del camino recorrido. Así avanza esto: cada iteración más profunda que la anterior.

Descarga y análisis técnico completo: TraysiaROMFix v2.0.0 en GitHub

Como siempre, nos tenéis en redes para dudas, hallazgos o cualquier .srm sospechoso que queráis compartir. Habrá más RetroFix.