RomHacking con IA Proyectos, métodos y aprendizaje compartido
Abro este hilo para recopilar en un solo sitio los proyectos de romhacking hechos con ayuda de IA —traducciones, parches de mejora, arreglos de jugabilidad, lo que se os ocurra— y para que sirva además como lugar de aprendizaje, donde quien sepa comparta y quien empiece pueda preguntar sin sentirse fuera de lugar. La idea no es hacer un escaparate, sino tener un punto de encuentro: qué estáis haciendo, cómo lo estáis haciendo, dónde os habéis atascado y qué habéis aprendido por el camino.
Trabajar así ya no es ninguna rareza. Cada vez somos más los que sacamos adelante proyectos apoyándonos en una IA para la parte técnica, y me parece que va siendo hora de compartir método en lugar de que cada uno vaya descubriendo lo mismo por su cuenta. Yo llevo un tiempo en ello y he aprendido bastante a base de equivocarme, así que abro con lo que tengo y espero que esto se llene de aportaciones de otros.
Cómo funciona esto en la práctica
Conviene aclarar el reparto de trabajo, porque suele malinterpretarse en las dos direcciones. La IA hace el trabajo técnico duro: desensamblar, localizar tablas de punteros, analizar formatos de compresión, escribir parches de código, reubicar assets. Es capaz de sostener un análisis de ingeniería inversa durante días y de escribir las herramientas que hagan falta para ello, y ahí no le llego ni de lejos.
Ahora bien, sola no llega a ninguna parte. Alguien tiene que dirigir el proyecto: decidir qué se traduce y cómo se redacta, marcar prioridades, descartar lo que no merece la pena. Alguien tiene que probar cada versión en el emulador, porque la IA no ve la pantalla y te dirá "verificado, todo correcto" sobre algo que está completamente roto. Y alguien tiene que aportar intuición cuando el análisis se atasca, que es más decisivo de lo que parece.
Dos ejemplos concretos. En el Nekketsu Soccer los nombres de los equipos estaban como gráficos y no cabían por 390 bytes; el primer enfoque generaba 146 tiles únicos y era un callejón sin salida, hasta que se planteó tratarlos como texto en lugar de como gráficos, alineando cada letra a su celda: de 146 tiles a 35, con 1.466 bytes de margen. En el Momotaro, más recientemente, la IA sostuvo que cierta función no se podía implementar; al insistir y explicar por qué debería poder hacerse, fue a medirlo y resultó que la rutina necesaria ya existía en la ROM y ya se estaba llamando. La intuición humana y el músculo técnico de la máquina se complementan, y ninguno de los dos sobra.
Lo que he aprendido a base de equivocarme
Hay unas cuantas cosas que ojalá me hubieran contado al empezar, y que creo que ahorran bastante tiempo.
La primera y más importante: la IA se equivoca con una seguridad pasmosa. Te dará por bueno un cambio que rompe el juego entero, porque ha comprobado que escribió los bytes que pretendía escribir, no que el resultado en pantalla sea correcto. Por eso hay que probar siempre en el emulador, y por eso las capturas de pantalla son la prueba definitiva: la IA analiza bytes, tú ves píxeles, y cuando ambos no coinciden manda lo que se ve.
De ahí se deriva la segunda: si crees que se está equivocando, insiste. En mi experiencia, cuando he discutido de manera terca he acabado teniendo razón muchas más veces de las que esperaba. Lo útil es pedir la medición, no la conclusión; que explique cómo lo ha comprobado, no que repita que está bien.
Y hay un caso particular de esto que me ha costado varias sesiones aprender: no basta con que la IA "verifique" su propio trabajo, porque a veces verifica contra su propia idea equivocada en lugar de contra la máquina. En el Momotaro, un bucle que colgaba el juego había pasado una comprobación automática porque esa comprobación estaba escrita con el mismo malentendido que el código. Cuando algo falla pese a estar "verificado", merece la pena preguntar contra qué se ha verificado exactamente.
Luego está el ritmo. Un cambio cada vez, se prueba, y sólo entonces el siguiente. Meter cinco cosas juntas y que algo falle es la garantía de no saber cuál de las cinco fue, y en un proyecto largo eso se paga carísimo. En la misma línea, conviene guardar cada versión con su hash y no sobrescribir nunca: suena a manía, pero cuando algo se rompe, poder volver exactamente al último estado bueno es fundamental.
Y por último, exigir que se apunte todo, incluidos los errores. En mis proyectos hay un diario donde las hipótesis descartadas no se borran, sino que se anotan con el motivo por el que resultaron falsas. Eso evita dar tres veces vueltas al mismo callejón, que es algo que pasa más de lo que parece cuando el proyecto se alarga.
Compartir también los atascos
Me parece tan útil contar lo que sale mal como lo que sale bien, y en un proyecto largo los atascos son el pan de cada día. Van dos del Momotaro, uno ya cerrado y otro todavía abierto.
El cerrado tenía a todo el mundo desconcertado: una palabra del inventario mostraba una letra suelta como un símbolo japonés, mientras el resto de la palabra salía perfecto. Se descartaron cuatro teorías, todas medidas y todas falsas. La explicación resultó ser que el juego no convierte un carácter en un paso, sino en tres, y sólo conocíamos el último: hay una tabla de sustitución previa, guardada además como dos listas separadas que si las lees seguidas parecen basura, y precisamente por eso se había descartado tiempo atrás. Reconstruida la cadena completa, el arreglo fueron dos bytes. Lo cuento porque el patrón se repite mucho: cuando algo no encaja de ninguna manera, a veces no falta un dato sino un paso entero del proceso.
El abierto es más gordo. Al entrar en las tiendas aparecen restos gráficos por toda la pantalla. Mi primera hipótesis, y la de la IA, fue que nos pasábamos del límite de sprites por línea que tiene la consola. Al medirlo con calma resultó que no: las tiendas se quedan en once de dieciséis, ni se acercan. La causa real parece ser que los códigos que usamos para las minúsculas son los mismos que el juego usa para el silabario japonés, de modo que el texto que aún no hemos traducido se dibuja con la fuente latina y sale convertido en galimatías. Si es eso, se arreglará solo conforme avancemos con el guion, pero todavía está por confirmar.
Lo cuento porque es exactamente el tipo de cosa que me gustaría ver en este hilo. Un atasco bien explicado le ahorra semanas a otro que se encuentre lo mismo, y de vez en cuando alguien pasa por aquí y lo resuelve de un vistazo.
Por qué creo que esto importa
Durante décadas el romhacking ha sido territorio de unos pocos con conocimientos muy específicos, y muchísimos juegos se han quedado sin traducir no porque no hubiera interés, sino porque no había suficiente gente capaz de hacerlo. Los que había, con todo mi respeto y admiración, tienen un tiempo limitado y sus propias prioridades, que es completamente legítimo.
Lo que la IA cambia no es la calidad del resultado, que sigue dependiendo del criterio y la paciencia de quien dirige. Lo que cambia es quién puede intentarlo. Alguien que se sabe un juego de memoria, que tiene buen oído para redactar un diálogo y aguante para probar cien versiones, ahora puede sacar adelante un proyecto que antes le habría resultado impensable. Y eso significa más juegos rescatados, más gente metida en esto y una escena más viva.
Quiero dejar claro que este hilo no va contra el romhacking tradicional, sino a favor de que haya más romhacking en general. El conocimiento de quien lleva veinte años en esto sigue siendo insustituible, y muchas veces un apunte suyo desatasca en dos minutos algo que llevaba días parado. Si alguien con oficio ve que estamos planteando algo de forma equivocada, que lo diga sin reparos: se agradece infinitamente más una corrección que un silencio educado.
Proyectos
Aquí iré recopilando los proyectos que vayamos compartiendo en el hilo, tanto los míos como los de quienes se animen a participar. Los dejo plegados para no ocupar media página.
Nekketsu Koukou Dodgeball-bu — Soccer Hen MD · TERMINADO
Mega Drive · Technos Japan · 1992 · Exclusivo de Japón · Proyecto de Psicopompo
El fútbol de Kunio-kun, con placajes, patadas voladoras, bombas y campos con minas. Nunca salió de Japón: ni versión americana, ni europea, ni una traducción al inglés en más de treinta años, así que no había ninguna versión occidental que sirviera de base y hubo que ir directo al japonés y reconstruirlo todo.
Está traducido por completo: los 86 bloques de diálogo de la historia, los menús, la pantalla de clave, los trece nombres de equipo, la pantalla de alineación, el marcador de resultados, los rótulos de escena y los créditos. Además se redibujaron todos los gráficos que contenían texto japonés, incluido el rótulo del título y una fuente gruesa nueva para los nombres de equipo.
El dato que me sigue pareciendo más llamativo es el tiempo: entre dos y tres días de trabajo intenso para un juego con texto comprimido, sin versión occidental de referencia y con gráficos que había que rehacer. Un romhacker en solitario habría tardado meses, y eso teniendo ya el oficio. No lo digo para restar mérito a nadie, sino porque creo que ilustra bien de qué estamos hablando.
PC Engine · Hudson Soft · 1990 · Exclusivo de Japón · Proyecto de Psicopompo
Este va bastante más despacio y es técnicamente más duro que el anterior. Vamos por la versión 272, lo cual da una idea del ritmo: muchísimas iteraciones pequeñas, cada una probada en el emulador antes de seguir.
Ya funcionan la intro, el tutorial y los diálogos principales, con los bocadillos ampliados y remaquetados para que quepa el castellano. Los bocadillos originales llevan escritura vertical japonesa, de arriba abajo y de derecha a izquierda, y convertirlos a horizontal fue la pieza central del proyecto: resultó que el orden de las casillas no estaba programado sino en dos tablas de datos, así que se resolvió con 72 bytes bien colocados. Lo caro vino después, arrastrando el marco, el rabillo y todo lo que se movía por su cuenta.
El sistema de contraseñas del Jizo, que fue la pelea más larga, está resuelto: la parrilla de kana se sustituyó por una latina de 64 casillas (que es justo lo que suman mayúsculas, minúsculas, dígitos y dos símbolos), y las contraseñas del juego original siguen siendo válidas porque los valores internos no cambian. También se recuperaron las flechas de los menús, que se perdieron al reestructurar los bocadillos de tres a cuatro líneas, y que resultaron no ser sprites sino dibujos escritos directamente en memoria de vídeo.
Traducción al castellano, todavía en fase temprana. Poco que contar por ahora más allá de que está empezado. Como veis, aún no están las tildes, la Ñ ni los signos de apertura de interrogación y exclamación. Las cajas de texto tampoco están ensanchadas. En fin, casi todos diálogos ya están traducidos, pero el trabajo de verdad viene ahora.
Double Dragon II · TERMINADO
Arcade · Technos Japan · Proyecto de Psicopompo
Double Dragon II (Arcade): Arreglo de los botones de ataque (PARCHE) es una modificación técnica para la mítica placa recreativa de Technōs que soluciona el comportamiento original de sus controles. En el juego base, los dos botones de ataque funcionan de manera direccional dependiendo de hacia dónde mire Billy, lo que provoca que el puño y la coz (sí, es una coz, no una patada normal 🤦🏻) se intercambien constantemente al cambiar de orientación y rompa la memoria muscular de cualquier jugador habituado a los beat 'em ups modernos.
El parche reescribe la gestión de la rutina de entrada de la CPU para que cada botón responda siempre al mismo movimiento de forma fija, independientemente de la dirección en la que esté enfocado el personaje. La modificación se extiende de manera uniforme a lo largo de todo el repertorio de golpes del título, abarcando desde los ataques básicos en tierra y las patadas aéreas hasta la gestión de armas u otras acciones específicas, preservando intactos el resto de elementos originales del juego como gráficos, niveles o valores de daño.
Otro parche de jugabilidad. La versión occidental tiene un jefe final absurdamente más difícil que la japonesa. Se pasaron mil pueblos. Es cierto que en la versión japonesa es un paseo, pero es que la occidental es completamente injusta. Al final te lo pasas, pero depende más de la suerte que de la habilidad.
La idea es implementar el jefe final japonés en la versión occidental y dejar el tramo final como debería haber sido.
Super 8-in-1 · EN PROCESO
Famiclone / NES · Proyecto de altbrian
Experimento realizado a partir de una ROM multijuegos 52-in-1 para famiclones. La elección vino por la nostalgia de este tipo de cartuchos de los años 90 y, en concreto, de su característico menú con sonido de "clic" al seleccionar un juego.
A partir de varias iteraciones, Claude consiguió aprender cómo funciona la estructura del menú y generar una ROM nueva con varios cambios: se eliminaron los tiles de cabecera y pie de página, se dejó una sola página con ocho juegos escogidos, se sustituyó "Section X" por "Super 8-in-1", se añadieron colores a los textos, se corrigieron problemas con la selección de juegos y se dejó una única columna centrada.
El objetivo es recrear un cartucho que tuvo en su día con un listado concreto de juegos, pero aún queda trabajo por delante: añadir un texto en la parte inferior y optimizar el tamaño de la ROM, ya que parece conservar datos de los otros 44 juegos que no se utilizan.
También está previsto crear un script de Python que permita generar cartuchos multijuegos utilizando ese mismo mapper y menú a partir de una carpeta con ROMs.
Mazinger Z · EN PROCESO
Super Famicom · Proyecto de Cebolleto
Cebolleto ha estado realizando modificaciones técnicas en diversos videojuegos con el apoyo de herramientas de inteligencia artificial para abordar aspectos complejos del código. En el caso específico de Mazinger Z, se ha modificado el sistema de fuentes tipográficas en todas las secciones del juego y se ha reubicado el guion en una zona de memoria extendida con el fin de evitar limitaciones de espacio.
Para resolver las restricciones de visualización, donde cada diálogo se limita originalmente a cuatro líneas de quince caracteres, se ha duplicado la capacidad modificando la gestión de los glifos: los caracteres que antes se representaban mediante una matriz de 16x16 píxeles se han reestructurado para mostrar dos elementos de 16x8 píxeles. Asimismo, se ha intervenido el apartado del karaoke, aunque sin sincronización de tiempos, ya que el código encargado del ritmo está estrechamente vinculado a la escena global; cualquier intento de reubicación de este bloque provoca fallos críticos en la carga del mapa de tiles del nivel, lo que genera un bucle de movimiento en el personaje.
Todo el espaciado actual tiene carácter preliminar, por lo que el proceso requiere una revisión exhaustiva línea por línea para ajustar la anchura de los textos de forma adecuada.
BATTLE MANIA CO-OP TROUBLE · EN PROCESO
Mega Drive · Proyecto de Fill Espectro
El usuario Fill Espectro se encuentra finalizando una modificación de tipo cooperativo (hack two players) para el juego Battle Mania de Mega Drive, titulado subtitularmente CO-OP TROUBLE en referencia al nombre occidental del título, Trouble Shooter.
A pesar de no contar con conocimientos previos de programación, el desarrollo técnico se ha llevado a cabo mediante el uso de inteligencia artificial. Por otro lado, el diseño de la jugabilidad cooperativa, así como la creación de nuevas animaciones y sprites, se han realizado de forma manual.
El proceso de desarrollo ha permitido profundizar en el funcionamiento técnico de las consolas de 16 bits, sus limitaciones y los recursos técnicos empleados en la época, además de familiarizarse con el uso de los depuradores Exodus y Emuhawk.
El seguimiento detallado del proyecto se encuentra disponible en su hilo correspondiente, donde próximamente se publicarán un vídeo final y el script definitivo del proyecto. Asimismo, se ofrece disponibilidad para resolver dudas y prestar ayuda a la comunidad.
Alex Kidd in Miracle World (Master System): Corrección de colisión del puñetazo y mapeo de botones es una modificación técnica para el clásico de SEGA que soluciona uno de los problemas de control más frustrantes del juego. En el título original, la colisión del puñetazo contra los bloques es sumamente imprecisa debido a que sólo se comprueba una vez en el instante exacto de pulsar el botón y contra un único punto de 8x8 píxeles, lo que provoca que romper bloques en pleno salto o por las esquinas sea una auténtica lotería.
El parche implementa una comprobación de colisión continua en cada frame mientras el puño permanece extendido, utilizando la hitbox real de los ataques con un margen adicional de un píxel. Además, se intercambian de forma nativa los botones del mando, pasando el botón 1 a ser el puño y el botón 2 el salto para adaptarlo a un estándar más cómodo. Todo ello ocupa únicamente 121 bytes en el espacio libre del banco fijo del cartucho, sin alterar el header ni el checksum.
Si tenéis un proyecto entre manos, terminado o a medias, traducción o parche, contadlo aquí con el detalle que os apetezca. Y si tenéis un juego atragantado desde hace años, uno que nunca llegó a España, o simplemente algo que siempre quisisteis arreglar de un juego que amáis, este es buen sitio para plantearlo aunque no sepáis por dónde empezar. Nos leemos.
Así muchos aprenderemos y se harán mas traducciones
Sobre todo la parte técnica sobre ingeniería inversa con la IA. Muchos juegos japones no están traducidos por los problemas de compresión y el formato que tienen los caracteres japones. Bueno que te voy a contar a ti, ya vez los problemas que estas teniendo con el juego que estas haciendo ahora "Momotarou Katsugeki"
eknives
Nerevarine
2.414 mensajes desde jun 2017
Editado 3 veces. Última: 19/08/2026 - 09:22:04 por eknives.
Yo tengo una duda sobre como poner un watchpoint (o un breakpoint) en exodus, como interpretarlo, etc. Estoy haciendo una modificación a veces Claude me lo pide pero nunca estoy seguro de si lo hago bien. Si alguien la puede responder se agradece. Esto es muy importante para mí porque es algo de lo que no suele haber muchas explicaciones.
Respecto a lo que puedo aportar, no es mucho pero por experiencia propia, imagina que en tu modificación quieres poner un nuevo modo de juego, la lógica te dice vamos a ver si puedo poner esta función, todo bien hasta ahí, pero empiezas a desarrollarlo y cuando ves que avanza te dices que tienes que separar los modos de juego en un menú, pues siento decirte que separar los modos de juego cuando ya has alterado tanto la rom es problemático, de primeras empieza separando los modos de juego y sobre eso trabajas.
Otro detalle, también imagina que por el motivo que sea necesitas poner otro personaje, por muy parecido que sea a uno ya existente da muchos muchos menos problemas que tenga sus propios sprites, aunque vaya a ser un "cambio de paleta", el otro problema es que te quedes sin sitio pero si que puedes antes de empezar a añadir cosas pedirle a la IA que amplíe el tamaño de la rom para tener más espacio disponible, hazlo si los límites del hardware lo permiten y quieres meter más sprites.
Estoy modificando un juego de Mega Drive, espero que esos mini consejos basados en la experiencia ayuden.
wah_wah_69
(o_o)
8.590 mensajes desde dic 2003
Editado 1 vez. Última: 19/08/2026 - 10:01:48 por wah_wah_69.
eknives escribió:Yo tengo una duda sobre como poner un watchpoint (o un breakpoint) en exodus, como interpretarlo, etc. Estoy haciendo una modificación a veces Claude me lo pide pero nunca estoy seguro de si lo hago bien. Si alguien la puede responder se agradece. Esto es muy importante para mí porque es algo de lo que no suele haber muchas explicaciones.
Respecto a lo que puedo aportar, no es mucho pero por experiencia propia, imagina que en tu modificación quieres poner un nuevo modo de juego, la lógica te dice vamos a ver si puedo poner esta función, todo bien hasta ahí, pero empiezas a desarrollarlo y cuando ves que avanza te dices que tienes que separar los modos de juego en un menú, pues siento decirte que separar los modos de juego cuando ya has alterado tanto la rom es problemático, de primeras empieza separando los modos de juego y sobre eso trabajas.
Otro detalle, también imagina que por el motivo que sea necesitas poner otro personaje, por muy parecido que sea a uno ya existente da muchos muchos menos problemas que tenga sus propios sprites, aunque vaya a ser un "cambio de paleta", el otro problema es que te quedes sin sitio pero si que puedes antes de empezar a añadir cosas pedirle a la IA que amplíe el tamaño de la rom para tener más espacio disponible, hazlo si los límites del hardware lo permiten y quieres meter más sprites.
Estoy modificando un juego de Mega Drive, espero que esos mini consejos basados en la experiencia ayuden.
Yo no la he probado, pero según veo tiene la herramienta set_breakpoint y debería utilizarla el propio claude para añadir lo que necesite.
Si lo quieres de forma manual, que tp está mal para ir aprendiendo:
*Edit, abriendo exodus, de forma manual*
Pero no he visto que tenga la opción de añadir breakpoint desde la call stack u otros puntos del emulador, debería tenerlo, tampoco he mirado muy a fondo.
eknives escribió:Otro detalle: también imagina que, por el motivo que sea, necesitas poner otro personaje. Por muy parecido que sea a uno ya existente, da muchos menos problemas que tenga sus propios sprites, aunque vaya a ser simplemente un "cambio de paleta". El otro problema es que te quedes sin espacio, pero antes de empezar a añadir cosas puedes pedirle a la IA que amplíe el tamaño de la ROM para disponer de más espacio, siempre que los límites del hardware y la arquitectura que uses lo permitan. Estoy modificando un juego de Mega Drive, espero que esos pequeños consejos basados en la experiencia ayuden.
Aquí ya depende de si te basta con mover o editar datos, reutilizar zonas libres de la ROM, que suelen ser bastante escasas, o pasar a un esquema de bank-switching, como hacía Super Street Fighter II.
El límite clásico de una ROM de Mega Drive no se debe exactamente a que el Motorola 68000 solo pueda direccionar 4 MB. El 68000 dispone de un bus de direcciones de 24 bits, es decir, puede direccionar 16 MB de espacio de memoria. Lo que ocurre es que, en la arquitectura normal de la Mega Drive, el espacio asignado directamente al cartucho es
$000000-$3FFFFF
, es decir, 4 MB (32 Mbit). ([Plutiedev][1])
Para superar ese límite se puede utilizar bank-switching o mapeo de bancos. La idea es bastante sencilla: la ROM física puede ser mayor de 4 MB, pero la consola solo ve simultáneamente una ventana de 4 MB. Esa ventana se divide en bloques de 512 KB, y los bloques que se muestran en esas ventanas se pueden cambiar mediante registros del mapper. ([Plutiedev][1])
¿Cómo funciona el Bankswitching en la Mega Drive?
El mapper estándar de Sega es conocido habitualmente como Sega Mapper o SSF2 Mapper, porque Super Street Fighter II fue el único juego oficial que utilizó este sistema para acceder a una ROM superior a los 4 MB. Otros proyectos y dispositivos utilizan variantes o implementaciones compatibles. ([Plutiedev][1])
[*] Páginas y bancos: la ROM física se divide en páginas de 512 KB. Al mismo tiempo, el espacio visible del cartucho se divide en ocho bancos de 512 KB, formando los 4 MB que puede ver directamente la CPU. ([Plutiedev][1])
[*] Primer banco fijo: la zona
$000000-$07FFFF
permanece apuntando a la primera página de la ROM. De esta forma, el código de arranque y los vectores de interrupción siguen siempre accesibles. ([Plutiedev][1])
[*] Bancos conmutables: las otras siete ventanas, desde
$080000-$0FFFFF
hasta
$380000-$3FFFFF
, pueden apuntar a distintas páginas de la ROM mediante los registros del mapper. ([Plutiedev][1])
tiene funciones relacionadas con el control de SRAM, por lo que no debe contarse como un octavo banco de ROM conmutable. ([manualzz.com][2])
Ejemplo de código en ensamblador 68k:
Si el juego mide 5 MB, la página 8 empieza en el offset
$400000
de la ROM física. Esa zona queda fuera del espacio lineal normal de 4 MB, pero podemos hacer que aparezca, por ejemplo, en la ventana
$300000-$37FFFF
:
MapperBank6: equ $A130FD ; Banco $300000-$37FFFF
move.b #8, (MapperBank6) ; Mostrar la página 8 en esa ventana
; A partir de aquí, una lectura de $300000 ; accede a los datos de la página 8 de la ROM.
La clave está en que
$300000
sigue siendo una dirección dentro de los 4 MB visibles para la consola. Lo que ha cambiado es qué parte de la ROM física se encuentra detrás de esa ventana. ([Plutiedev][1])
Pasos para expandir un juego normal a Bankswitching
Convertir una ROM convencional de 2 o 4 MB para utilizar bank-switching no consiste simplemente en aumentar el tamaño del archivo. Hay que adaptar el código que accede a los datos que se van a colocar fuera de la zona fija.
Preparar la ROM para el mapper: En determinados emuladores y flashcarts es necesario indicar en la cabecera que la ROM utiliza el mapper de Sega. Plutiedev documenta el cambio del campo de sistema situado en
$000100
a
SEGA SSF
, rellenando con espacios cuando sea necesario. Esto permite que dispositivos y emuladores compatibles activen el mapper. Algunos emuladores pueden autodetectarlo al detectar accesos a los registros del mapper. ([Plutiedev][1])
Expandir el archivo físico: Hay que aumentar realmente el tamaño de la ROM, por ejemplo, de 4 MB a 8 MB, 10 MB, etc. El tamaño máximo dependerá del mapper y del hardware utilizado.
Relocalizar los assets grandes: Los gráficos, muestras de sonido, mapas u otros datos pesados pueden moverse a páginas altas de la ROM física.
Por ejemplo, un bloque de 512 KB colocado en
$400000
pertenece a la página 8. Para acceder a él desde el 68000 habrá que mapear esa página en una de las ventanas conmutables y acceder a ella mediante la dirección correspondiente dentro de esa ventana.
Actualizar los punteros y rutinas de acceso: Cualquier código que acceda a un recurso que hayas movido debe tener en cuenta que su dirección física ya no es directamente accesible. Normalmente necesitas seleccionar primero el banco correspondiente y después acceder al recurso mediante la ventana donde lo hayas mapeado.
Oportunidades y problemas técnicos
Más espacio para assets: Puedes añadir más gráficos, animaciones, mapas, música o muestras de sonido sin intentar encajarlo todo dentro de los 4 MB visibles de forma lineal.
Menos necesidad de reutilizar espacio: En un hack grande, disponer de páginas adicionales puede ser mucho más cómodo que intentar exprimir hasta el último hueco libre de la ROM original.
Gestión de bancos: El coste real está en que el programa debe saber qué banco está actualmente mapeado. Cambiar el mapper demasiado a menudo puede complicar el código y añadir sobrecarga, aunque el problema depende mucho de cómo esté diseñado el acceso a los datos.
Interrupciones y código: Aquí hay que tener especial cuidado. Si una rutina cambia el contenido de una ventana y después una interrupción intenta ejecutar código o leer datos que dependían de la configuración anterior, puedes terminar accediendo a otra página distinta de la esperada.
Por eso conviene mantener el código crítico, las tablas necesarias y las rutinas de interrupción en zonas que permanezcan siempre accesibles, o controlar cuidadosamente cuándo se cambia cada banco.
Código y direcciones: No basta con convertir una dirección física de la ROM en una dirección de CPU. Una vez que un recurso está en una página conmutable, hay que mapear esa página antes de utilizarlo y asegurarse de que el código no se queda ejecutándose desde una ventana que acabas de cambiar.
¿Y merece la pena para un hack?
Para un hack pequeño, normalmente es más sencillo aprovechar primero el espacio libre existente, reorganizar datos o comprimir mejor los assets.
Cuando empiezas a añadir personajes completos, más animaciones, nuevas fases, música, voces o cantidades importantes de gráficos, el bank-switching puede convertirse en una solución mucho más limpia que intentar meterlo todo a martillazos dentro de los 4 MB originales.
Eso sí: ampliar la ROM no significa automáticamente que el juego pueda utilizar el espacio adicional. Hay que modificar el código para que sepa dónde están esos datos y cómo acceder a ellos.
Es probablemente la referencia más práctica para implementar el Sega Mapper en un proyecto moderno. Documenta el sistema de páginas de 512 KB, los siete registros de bancos conmutables y el uso de
SEGA SSF
en la cabecera para plataformas compatibles. ([Plutiedev][1])
Hay bastante documentación y discusión técnica sobre el SSF2 mapper, el mapa de memoria y sus implicaciones con otros dispositivos. En particular, se explica que el sistema dispone de siete bancos de ROM conmutables de 512 KB más el primer banco fijo, y que los valores de los registros permiten seleccionar diferentes páginas de la ROM. ([gendev.spritesmind.net][3])
Documentación técnica de Sega: También existe documentación de hardware de Sega que describe la división del espacio de cartucho en bancos de 512 KB y los registros de selección de banco. ([manualzz.com][2])
Así que sí: se puede ampliar una ROM de Mega Drive más allá de los 4 MB, pero no consiste simplemente en hacer el archivo más grande. Hay que utilizar un mapper compatible y adaptar el programa para trabajar con ventanas de memoria conmutables.
@wah_wah_69 tiene buena pinta el debugging de Exodus, no lo conocia. Yo suelo usar el Gens_KMod
@psicopompo Si no me equivoco tu usas el Retroarch con el core genesis_plus_gx_libretro. ¿Cierto? ¿Como pones el modo debugging o es un core diferente modificado para el debugging?
wah_wah_69
(o_o)
8.590 mensajes desde dic 2003
Editado 1 vez. Última: 19/08/2026 - 14:21:45 por wah_wah_69.
psicopompo escribió:@wah_wah_69 ¿Qué tal ese Exodus? Yo es que uso macOS y ni lo conocía.
DeVlL escribió: @wah_wah_69 tiene buena pinta el debugging de Exodus, no lo conocia. Yo suelo usar el Gens_KMod
Exodus desde hace años es el emulador más recomendado para romhacking de megadrive, yo lo estuve probando hace un tiempo (antes de empezar a usar LLM), para intentar hacer un hack de soporte de 6 botones para Alien soldier, encontré la rutina de manejo de entrada estuve tonteando un poco y no lo logré terminar.
Al año o meses de que me olvidara de eso sacaron este parche:
Recuerdo que usé un plugin para ghidra para hacer el desemsamblado, tampoco llegué a profundizar mucho, la verdad.
La verdad que para meterle mano al Shadowrun igual debería haber añadido soporte de MegaCD a Exodus (que ojo igual en el foro o repo oficial hay plugins para eso, tp me he puesto a investigar). Me puse con el genesis plus por tenemos más mano y tb con la idea de que la mayoría de la gente que luego juegue al hack posiblemente lo haga con él.
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 1 vez. Última: 19/08/2026 - 14:25:28 por psicopompo.
@DeVlL La verdad es que con el Nekketsu Soccer MD no necesité breakpoints ni nada, pero es cierto que el core de Retroarch en ese aspecto va bastante cojo. Tendré que buscarme una alternativa cuando retome el Lord Monarch. Para el Momotaro Katsugeki uso el Messen CE, que armado hasta las cejas. Con él puedo hacer breakpoints, volcados, tiene Sprite Viewer, Tilemap Viewer, Memory Viewer y un montón de cosas más, pero no emula Mega Drive, y eso que emula un montón de consolas.
@wah_wah_69 Pues no tenía ni idea, pero es que llevo sin tocar Windows desde hace más de 20 años. Sólo uso macOS y Linux. Además llevo en esto del romhacking menos de un mes. 😄 Gracias por la información.
gjfjf escribió:@psicopompo ¿ Pero que se le pregunta a una IA para que haga todo esto ? podrias poner un tutorial
¿ se podria usar una IA para que implemente nuevos mappers de NES en emuladores ?
Tienes que hablarle exactamente como lo estás haciendo ahora, explicándole lo que quieres. Eso es Vibe Coding. Y sí, puedes meterte en el follón que quieras, mappers o lo que sea. Simplemente dile que quieres implementar nuevos mappers en el emulador que sea, y a partir de ahí os ponéis a hablar. En mi caso, empiezo diciéndole el juego que quiero traducir, en qué idioma está, le paso la rom entera (si la IA que uses te lo permite, yo uso un agente local y algunos otros LLM online) y le digo que intente localizar los textos de las capturas que le adjunto. Entonces se pone a buscar, y al final lo encuentra. Es cuestión de tener paciencia. Luego te puedes ir enfocando en partes concretas del juego, como el menú de inicio, una introducción, los diálogos, etc. Tendrás que ir probando los resultados e indicarle todo aquello que veas mal. Si crees que sabes a lo que se debe un error, indícaselo, aunque te parezca una tontería. En muchos casos no lo es y sirve para salir del atasco. Enviarle capturas de casi cualquier cosa siempre ayuda, y los states aún más. Con el tiempo no tendrás ni que esperar a que te pida nada, ya sabrás qué es lo que puede necesitar. Si te pide algo como un breakpoint, y no sabes lo que es o cómo hacerlo, simplemente pregúntale y te guiará. No es necesario que sepas leer los datos de esas cosas, con pasarle una captura se apañará.
Lo ideal es tener un agente tipo OpenClaw o Hermes, con una api vinculada, pero entiendo que no todo el mundo gasta 20€ mensuales en Claude u otro LLM. Yo mismo no gasto nada. Uso Hermes Agent con Gemma 4 y unas cuantas IAs online a las que les suelo consultar cosas. También tienes agentes online con uso limitado diario. La versión gratuita de Claude se come lo que le adjuntes (al menos yo le he pasado roms de Mega Drive y de PC Engine), pero la cuota dura un parpadeo (se restablece cada 6 horas, más o menos). Aún así, a veces te soluciona cosas que tu LLM habitual no.
bruce_jk escribió:Hola Psico Gracias por la info, Consulta que herramientas usas para empesar a revisar desde cero? Alguna herramienta exadecimal? O algun ide?
Con la IA no necesitas nada de eso. De hecho, la IA se crea sus propias herramientas cuando las necesita, o le pides que se cree alguna para algo muy concreto. Yo mismo le he pedido que se creara varias que le ahorraron trabajo y le sirvieron para diagnosticar problemas. Ahí ya tienes que estar pendiente de lo que pueda necesitar. En un solo proyecto se crea ella solita unas cien herramientas sin despeinarse.
eknives
Nerevarine
2.414 mensajes desde jun 2017
Editado 1 vez. Última: 20/08/2026 - 00:44:44 por eknives.
@wah_wah_69 a ver, seguramente me pierda en los motivos técnicos pero me vi obligado a aumentar una rom de 1 MB a 2 MB por problemas de espacio con ciertos sprites, por suerte no tuve que vérmelas con ningún mapper y este tamaño de rom está tan lejos de los límites de la consola tampoco me preocupa mucho que sea una rom de 1 o 2 MB.
eknives escribió:@wah_wah_69 a ver, seguramente me pierda en los motivos técnicos pero me vi obligado a aumentar una rom de 1 MB a 2 MB por problemas de espacio con ciertos sprites, por suerte no tuve que vérmelas con ningún mapper y en esta trabaja de rom tan lejos de los límites de la consola tampoco me preocupa mucho que sea una rom de 1 o 2 MB.
En ese caso más simple en teoría no es más que ampliar el archivo, recalcular el checksum de la cabecera y luego apuntar a la dirección de memoria correspondiente de los nuevos datos en el código que sea.
@psicopompo: espero el hack del Wonderboy V como agua de Mayo, macho. Qué falta le hace a ese juego. Es un juegazo y lo jodieron con esa tontería de jefe al final. Mi pareja se lo intentó pasar hace dos años y no hubo manera por ese estropicio que le hicieron en occidente al juego.
Alien_crrpt
Adicto
139 mensajes desde dic 2024
Editado 1 vez. Última: 20/08/2026 - 11:25:37 por Alien_crrpt.
Alien_crrpt escribió:@psicopompo si hicieras un video de youtube esplicando los pasos para empezar mucha gente aprenderia y podriais hacer grupos de trabajo.
O nos pusieras una lista de videos de youtube ( en español si es posible ) con los que aprendistes.
Pues sí, la verdad es que ver un directo aunque no salga nada a derechas en él estaría genial para entender de qué va el tema
Alien_crrpt escribió:@psicopompo si hicieras un video de youtube esplicando los pasos para empezar mucha gente aprenderia y podriais hacer grupos de trabajo.
Los videos son para ganar dinero , no hace falta verse un video de una hora por algo que se puede explicar en pocos minutos
Estuve haciendo mis experimentos en Claude con una ROM multijuegos de 52-in-1 para famiclones. Escogí esta ROM porque era de la época en la que crecí (90s), tiene el típico menú de juegos con sonido de "clic" al seleccionar un juego (que por alguna razón me parece nostálgico) y porque tiene cabecera y footer personalizables.
Por ahora logré que Claude aprendiera como funciona la estructura del menú y después de varias iteraciones generé una ROM nueva con los siguientes cambios.
1. Eliminé los tiles de la cabecera y pie de página 2. Dejé solo una página, para 8 juegos escogidos 3. Personalicé el título de "Section X" a "Super 8-in-1", muy al estilo de los cartuchos chinosos 4. Le di colores a los textos 5. Corrigió bugs con la seleccion de juegos y dejé una única columna centrada
Me enfoqué en dejarlo solo con 8 juegos porque quería recrear un cartucho aún no dumpeado que tuve en su día con un listado específico de juegos.
Aún falta por hacer:
1. Añadirle un texto en la parte inferior 2. Optimizar el tamaño de la ROM porque sospecho que aún tiene datos de los otros 44 juegos no usados
También planeo crear algún script de Python que genere cartuchos multijuegos usando ese mapper y menú, a partir de una carpeta con ROMs. Veremos como avanza todo esto para terminarlo de documentar y subirlo a RomHacking y GitHub.
@psicopompo ponerse terco con la IA normalmente no lleva a nada bueno. No es una cuestión de terquedad humana. La IA es un algoritmo que no tiene sentimientos. Pensar que has ganado la “discusión” es solo importante para un humano. No te dejes llevar por su lenguaje. Utiliza el comando /rewind de la IA.
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 2 veces. Última: 21/08/2026 - 06:02:18 por psicopompo.
Dartanyan escribió:@psicopompo ponerse terco con la IA normalmente no lleva a nada bueno. No es una cuestión de terquedad humana. La IA es un algoritmo que no tiene sentimientos. Pensar que has ganado la “discusión” es solo importante para un humano. No te dejes llevar por su lenguaje. Utiliza el comando /rewind de la IA.
Creo que aquí hay una pequeña confusión. Cuando digo "discutir de manera terca" no me refiero a intentar convencer a la IA ni a pensar que he ganado una discusión con una persona. Me refiero justo a lo contrario: no aceptar una conclusión porque la IA la diga con seguridad y hacer que vuelva a medir lo que está afirmando. En el ejemplo que pongo del Momotaro, la IA decía que una función no podía implementarse; insistí en que comprobara la hipótesis y acabó encontrando la rutina que ya existía en la ROM. No había nada que "ganar": había una afirmación que comprobar. De hecho, ésa es precisamente una de las ideas que intento transmitir en el hilo: pedir mediciones y pruebas, no conclusiones.
@altbrian Buen trabajo. En cuanto tenga tiempo añado tu proyecto a la lista del mensaje de inicio.
Dartanyan escribió:@psicopompo ponerse terco con la IA normalmente no lleva a nada bueno. No es una cuestión de terquedad humana. La IA es un algoritmo que no tiene sentimientos. Pensar que has ganado la “discusión” es solo importante para un humano. No te dejes llevar por su lenguaje. Utiliza el comando /rewind de la IA.
Creo que aquí hay una pequeña confusión. Cuando digo "discutir de manera terca" no me refiero a intentar convencer a la IA ni a pensar que he ganado una discusión con una persona. Me refiero justo a lo contrario: no aceptar una conclusión porque la IA la diga con seguridad y hacer que vuelva a medir lo que está afirmando. En el ejemplo que pongo del Momotaro, la IA decía que una función no podía implementarse; insistí en que comprobara la hipótesis y acabó encontrando la rutina que ya existía en la ROM. No había nada que "ganar": había una afirmación que comprobar. De hecho, ésa es precisamente una de las ideas que intento transmitir en el hilo: pedir mediciones y pruebas, no conclusiones.
@altbrian Buen trabajo. En cuanto tenga tiempo añado tu proyecto a la lista del mensaje de inicio.
Sí yo te entendí. Precisamente muchas veces no hay que insistir hasta que lo encuentre o lo arregle, porque el barullo de código puede ser espectacular. Muchas veces es mejor tirar atrás, la IA deshará el circo de código que habrá montado, se olvidará de los prompts que le digas y puedes volver a reformular el prompt.
@Dartanyan llevas razón aunque yo si he entendido a @psicopompo , de hecho a veces le digo a la IA que revierta los cambios. Sacar una metodología de trabajo lleva un tiempo y pasar por algunos problemas para saber lo que no puedes hacer, aunque lo de "discutir" lo entendí muy bien cuando por ejemplo le pedía a la IA que borrase algo y en su lugar lo que hacía era ocultarlo pero precisamente eso generaba un problema y era peor porque el problema se mantenía pero al no verse dificultaba identificarlo.
El dummy que vi en el la pista 1 de Shadowrun de mega cd, hoy me he molestado en montarlo como video:
Y una de las varias fuentes que tiene el juego, estoy intentando hacer el render estáticamente desde los archivos originales del juego para comprender el código original cuando tenga que insertar la fuente custom, por ahora algo va sacando pero no tengo el formato controlado todavía al 100%:
Parece que hubiera algún problema en la forma en la que se interpretan el orden de las líneas horizontales de cada glifo...
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 4 veces. Última: 22/08/2026 - 00:44:25 por psicopompo.
@wah_wah_69 Una cosa que llevo pensando al leer todo lo que estás haciendo con Shadowrun: creo que estamos enfocando el romhacking con IA de maneras bastante distintas, y precisamente por eso me parece interesante comentarlo.
Todo lo que estás contando de desensamblados, extracción de la ISO, trazas, decoders, formatos, debug, etc. es muy interesante y, evidentemente, tiene cabida en un proyecto de romhacking. Pero en mi caso hay una diferencia bastante grande: yo no he necesitado saber ni preparar prácticamente nada de eso antes de empezar.
En los dos juegos que ya he terminado y en el que tengo ahora mismo en marcha, he partido de la ROM y he ido dejando que el agente vaya descubriendo cómo funciona el juego a medida que lo necesita. Le doy los archivos, el emulador, capturas, states, breakpoints cuando hacen falta, y voy interviniendo cuando veo que se está metiendo por un camino equivocado. Yo no necesito saber previamente cómo están organizados los datos, qué rutina carga los gráficos, cómo funciona la compresión o dónde está cada tabla. Es la IA la que tiene que averiguarlo.
Y de hecho, ayer estuve un rato con Codex, el agente de programación de OpenAI, y creo que ahí se ve bastante bien la diferencia entre nuestros enfoques. Partiendo simplemente de los archivos descomprimidos de Shadowrun, le dije que quería traducir el juego, que buscara los textos, que habría que añadir tildes, Ñ, signos de apertura de exclamación e interrogación y que seguramente habría que ampliar las cajas de los textos debido a la mayor extensión de los diálogos en castellano. En poco más de veinte minutos ya había localizado los módulos que contienen el guion, identificado miles de entradas, reconstruido parte de la codificación, localizado los bancos de fuentes, extraído 5.342 bloques y más de 23.000 líneas, encontrado espacio para las tildes, la Ñ y los signos de apertura, y empezado a reconstruir el formato gráfico de los ".K". Y yo no había preparado previamente nada de eso.
Para mí, esto ilustra bastante bien lo que comentaba antes, y por eso creo que cuando me ponga realmente con Shadowrun voy a poder obtener resultados bastante rápidos en algunas partes. Luego vendrán los problemas gordos, por supuesto —ya me conozco a estas alturas las hostias que puede pegarse la IA—, pero precisamente ésa es la gracia: que el trabajo de ingeniería inversa lo vaya haciendo el agente mientras yo le voy indicando qué necesito y comprobando que lo que encuentra tiene sentido.
No te lo digo porque crea que una forma sea mejor que la otra. Al contrario: si ya tienes conocimientos de ingeniería inversa, trazas, arquitectura y herramientas de debug, puedes hacer cosas muy potentes con un LLM. Lo que me interesa es otra cosa: comprobar hasta dónde puede llegar alguien que no domina previamente toda esa parte técnica.
Y creo que esto es bastante importante para el propósito del hilo. No hace falta saber romhacking para empezar a hacer romhacking con IA. Hace falta saber dirigirla, proporcionarle información útil, comprobar lo que hace y tener criterio para detectar cuándo se está equivocando. El conocimiento técnico sigue siendo tremendamente valioso, pero ya no tiene por qué ser el requisito de entrada.
Por eso me gustaría que aquí fuéramos contando no solo qué hemos descubierto de cada juego, sino también cómo hemos conseguido que la IA lo descubra. Ahí creo que está la parte diferencial respecto a un hilo de romhacking convencional.
Terminé de corregir los detalles el multicart 8-in-1 recreación de uno que tuve en los 90s. Quedó prácticamente perfecto y los 8 juegos funcionan a la perfección.
Lamentablemente no podría ser reutilizado sino con pocos juegos de la primera hornada por el soporte de Mappers. Los piratas de esos años le metían mucho la mano a las ROMs para que corrieran con otro Mapper.
Tengo una decompilación inicial del menú, lo siguiente sería probar qué tan bien se compila con ROMs diferentes.
@psicopompo 100% de acuerdo. Parte de la gracia es que la IA haga el trabajo sucio y una vez sabe qué tiene entre manos entonces ir guiándola con los cambios.
De hecho descubrí que Claude es capaz de correr una ROM en un emulador por su lado y hacer el debugging
En mis experimentos usó FCEUX con roms de NES y le pedía que me mostrara pantallazos de lo que iba viendo, le pedía que quitara cosas y visualmente las comprobaba.
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 1 vez. Última: 23/08/2026 - 05:49:12 por psicopompo.
altbrian escribió:De hecho descubrí que Claude es capaz de correr una ROM en un emulador por su lado y hacer el debugging
En mis experimentos usó FCEUX con roms de NES y le pedía que me mostrara pantallazos de lo que iba viendo, le pedía que quitara cosas y visualmente las comprobaba.
Eso esta interesante. ¿Se instala el solo el FCEUX y hace después el debugging con la rom que tu le pongas, así sin mas? Si es así voy a probar hacer lo mismo con un juego de master system y el emulador mekaw
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 6 veces. Última: 24/08/2026 - 23:10:25 por psicopompo.
Eso es un malentendido bastante común sobre cómo funciona la IA por dentro. En el chat normal de Claude no hay ningún FCEUX ni emulador corriendo, básicamente porque esa interfaz estándar no tiene entorno gráfico, sonido ni capacidad para ejecutar juegos en tiempo real.
Lo que la gente confunde con pantallazos del emulador son en realidad imágenes estáticas que la propia IA genera sobre la marcha con scripts de Python. La IA abre el archivo de la ROM, lee directamente los datos de los gráficos (los tiles, las paletas de color, etc.) y genera un archivo PNG para enseñártelo. Cuando le pides que cambie o quite algo, modifica esos bytes en el archivo y te vuelve a renderizar una imagen fija con el resultado visual. Parece que está jugando o haciendo capturas, pero en realidad sólo está leyendo el código binario a ciegas y dibujando el resultado. Eso no significa que no te pueda servir igual, aunque habrá momentos en los que necesitará pedirte capturas reales, breakpoints, volcados y otras cosas. Y sí, Claude puede generarte parches IPS/BPS o incluso devolverte la ROM parcheada. Pero no hay que olvidar que la versión gratuita no te da margen para hacer casi nada porque en apenas dos mensajes se agota la cuota.
Ojo, esto aplica al chat web estándar. Si hablamos de herramientas más avanzadas tipo Claude Code (cuya suscripción de 20€ —que es la más barata— te da mucho más contexto, más mensajes, herramienta CLI, sandbox local, etc.), entornos con agentes como OpenClaw, Hermes o scripts conectando LLMs locales y APIs, ahí la cosa cambia. Esos entornos sí tienen acceso a sandboxes completos donde la IA puede ejecutar comandos de terminal, instalar paquetes y montar lo que haga falta. Pero en la ventana de chat normal, lo que está haciendo es puro procesamiento de datos e imágenes generadas en el acto, sin emuladores de por medio.
MrNutz escribió:@psicopompo: espero el hack del Wonderboy V como agua de Mayo, macho. Qué falta le hace a ese juego. Es un juegazo y lo jodieron con esa tontería de jefe al final. Mi pareja se lo intentó pasar hace dos años y no hubo manera por ese estropicio que le hicieron en occidente al juego.
¿Tienes un .srm? He probado el .srm de mi EVERDRIVE, que guarda la partida en la nave espacial del final del juego, poco antes del jefe final, pero al usarlo en Genesis Plus GX me carga en una posada casi al principio del juego. No me apetece demasiado llegar hasta el final. Si lo tienes y me lo pasas, me pongo a ello. También me valdría un .state de Retroarch para Genesis Plus GX.
¡ACTUALIZACIÓN!
He actualizado el mensaje inicial con los proyectos finalizados de Momotaro Katsugeki en castellano y Double Dragon II (Arcade): Arreglo de los botones de ataque. Podéis descargar los parches en sus respectivos hilos.
MrNutz escribió:@psicopompo: espero el hack del Wonderboy V como agua de Mayo, macho. Qué falta le hace a ese juego. Es un juegazo y lo jodieron con esa tontería de jefe al final. Mi pareja se lo intentó pasar hace dos años y no hubo manera por ese estropicio que le hicieron en occidente al juego.
¿Tienes un .srm? He probado el .srm de mi EVERDRIVE, que guarda la partida en la nave espacial del final del juego, poco antes del jefe final, pero al usarlo en Genesis Plus GX me carga en una posada casi al principio del juego. No me apetece demasiado llegar hasta el final. Si lo tienes y me lo pasas, me pongo a ello. También me valdría un .state de Retroarch para Genesis Plus GX.
¡ACTUALIZACIÓN!
He actualizado el mensaje inicial con los proyectos finalizados de Momotaro Katsugeki en castellano y Double Dragon II (Arcade): Arreglo de los botones de ataque. Podéis descargar los parches en sus respectivos hilos.
Qué va, mi pareja lo intentó jugar hace mucho y no tenemos partida guardada de aquello, lo siento Si me da por intentarlo a mi y llego al "mostro", te aviso.
Buenas, por mi parte, como ya he comentado en el glorioso hilo del Momotaro, he estado modificando algunos juegos con ayuda de una IA, cosas técnicas que a mí se me escapan de las manos, entre otros, este Mazinger Z, básicamente he cambiado las fuentes de letra de cada una de las partes del juego y he movido el guion a zona extendida para no tener problemas de espacio, el único problema de espacio real es que cada diálogo tiene 4 líneas de 15 caracteres, lo he doblado haciendo que donde antes mostraba un glifo de 16x16, ahora muestra 2 de 16x8. He modificado el karaoke, pero sin timing pues el código que controla el ritmo parece formar parte de la escena entera, intentar moverlo de bloque hace que no cargue el tilemap del nivel y Mazinger cae por abajo y reaparece por arriba ad infinitum, como dice Psicopompo, cada cosa que arreglo, rompe 3 y así estoy, un juego de 170 líneas de texto me lleva por la calle de la amargura jaja.
Ni que decir que todo el espaciado es preliminar y, en este caso, hay que revisar línea a línea para ajustar el ancho.
Cebolleto escribió:Buenas, por mi parte, como ya he comentado en el glorioso hilo del Momotaro, he estado modificando algunos juegos con ayuda de una IA, cosas técnicas que a mí se me escapan de las manos, entre otros, este Mazinger Z, básicamente he cambiado las fuentes de letra de cada una de las partes del juego y he movido el guion a zona extendida para no tener problemas de espacio, el único problema de espacio real es que cada diálogo tiene 4 líneas de 15 caracteres, lo he doblado haciendo que donde antes mostraba un glifo de 16x16, ahora muestra 2 de 16x8. He modificado el karaoke, pero sin timing pues el código que controla el ritmo parece formar parte de la escena entera, intentar moverlo de bloque hace que no cargue el tilemap del nivel y Mazinger cae por abajo y reaparece por arriba ad infinitum, como dice Psicopompo, cada cosa que arreglo, rompe 3 y así estoy, un juego de 170 líneas de texto me lleva por la calle de la amargura jaja.
Ni que decir que todo el espaciado es preliminar y, en este caso, hay que revisar línea a línea para ajustar el ancho.
Muy interesante, imagino que poco a poco lo podrás ir controlando y arreglando el tema. De las capturas que muestras se ve muy bien, no sabía que la parte superior del juego se mostraba el karaoke de la serie. El juego lo jugué hace 25 años o más y no logro recordar ese detalle.
Yo justo estoy terminando un hack dos players para el BATTLE MANIA de Mega Drive, un juego que me encanta. Lo he subtitulado como CO-OP TROUBLE ya que el titulo occidental fué TROUBLE SHOOTER y pensé que sería una buena referencia.
No tengo ni idea de programar, lo he hecho todo con IA. También he hecho algunas animaciónes y sprites nuevos, eso sí, a mano, además de diseñar el game play para el modo cooperativo. Me ha encantado el proceso, he aprendido mucho a usar Exodus y Emuhawk para debugging ( que buenos programas!). También he aprendido muchas cosas de como funcionaban estos increibles juegos de 16 bits, todas sus limitaciones y todo lo que conseguían con tan poco.
Logré traducir yo el Castlevania al gallego con IA, pero al querer hacer lo mismo con Sweet Home me soltó un montón de errores pero me gusta como avanzas este tema, seguro que a medida que avancen los modelos será mucho más fácil y directo. Igual con Fable 5.1 o el Astra nuevo ya lo es, pero esos no entran en las subs todavía.
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 11 veces. Última: 8/09/2026 - 10:25:46 por psicopompo.
¡Gracias a los dos, @Cebolleto y @Fill Espectro! Los proyectos encajan perfectamente en el hilo, así que ya he actualizado el primer mensaje con la info. @Cebolleto, si al final abres hilo propio, avísame y lo meto en la ficha.
Edito:
SuperPadLand escribió:Logré traducir yo el Castlevania al gallego con IA, pero al querer hacer lo mismo con Sweet Home me soltó un montón de errores pero me gusta como avanzas este tema, seguro que a medida que avancen los modelos será mucho más fácil y directo. Igual con Fable 5.1 o el Astra nuevo ya lo es, pero esos no entran en las subs todavía.
Perdona, no te había leído. ¿Llegaste a publicar el Castlevania en algún sitio como RomHacking.net? Me suena haber visto uno hace poco. Vale, ya he visto que era el tuyo (Calculín). 👏🏻👏🏻👏🏻 ¿Qué usaste? ¿Y cómo llevas ese Sweet Home?
Yo me acabo de poner con un proyecto pequeño (de hecho, le acabo de dar las primeras instrucciones a la IA y ya me ha hecho un informe —os lo dejo abajo, en un spoiler, por si os interesa— que me lleva jodiendo décadas: el puñetazo en Alex Kidd in Miracle World. Siempre me ha parecido muy impreciso y que lastraba (al menos para mí) completamente el juego. Tienes que golpear los bloques justo en el centro (por el lateral) para poder romperlos y, si no es así, el puño los atraviesa. Mi idea es que se rompan con la mínima colisión (pero tiene que haberla, claro).
Aquí podéis ver una imagen del delito (y no, el bloque no se ha roto):
También aprovecharé e invertiré los botones de Salto y Puño para que estén como Puño y Salto, que es el orden al que todos estamos acostumbrados. Sé que ya hay parches para esto último, pero no cuesta nada añadirlo. Lo que no creo que haga será traducirlo al castellano porque ya hay varias traducciones, como las de @wave y @jackic .
Informe de la IA:
¡Buen proyecto! Voy a montarlo y a descargar la ROM y los dos states para analizar la colisión del puñetazo.
The state files are Genesis Plus GX libretro save states (RZIP-compressed). I've decompressed them. Now I need a Z80 disassembler to analyze the collision code. Capstone 5.x dropped Z80 support and the 4.x install is broken, so I'll write my own.
My disassembler has decode bugs in the x=0 block. Let me rewrite it correctly using proper Z80 opcode structure.
Let me look at the Genesis Plus GX state format source to extract the RAM correctly.
I now understand the state format. The layout is: outer "RASTATE" header → Genesis Plus GX core version string → then the SMS work RAM (8KB). Let me extract and compare the RAM between the two states.
Let me verify the exact RAM offset by checking the libretro port's serialization wrapper.
I've confirmed the state format and extracted the SMS work RAM correctly (io_reg[0]=0xC0 confirms the US/EU region). Let me save the RAM and look at what differs between the two punch states.
This is a substantial reverse-engineering task. Let me check for existing disassembly/documentation of this game to guide the analysis efficiently.
Excellent — there's a complete disassembly project (`lhsazevedo/akmw`). Let me clone it to use as a reference.
This is a fully-labeled disassembly. Let me examine the collision code and the Alex punch mechanics.
The punch handler is clearly labeled. Let me examine the collision routine `_LABEL_7C4F_` which computes the metatile at the punch position.
The collision code is clear now. Let me confirm the metatile structure and check a couple more details, then verify against the two states.
Now I have the full picture. Let me verify the collision math concretely against the two save states to confirm the root cause.
I've found and verified the root cause. Let me capture the exact ROM addresses for reference, then write up the analysis.
The ROM checksum matches the known-good dump exactly (SHA1 `6d052e0c...`, CRC32 `AED9AAC4`), and my disassembly matches the reference disassembly byte-for-byte. Everything is verified. Let me write up the analysis.
Sí, detecto el problema, y es exactamente lo que sospechabas. Lo he localizado en el código y lo he verificado byte a byte.
Qué he encontrado
Tu sospecha era cierta. La colisión del puñetazo contra bloques no usa una caja de colisión (hitbox): es una comprobación de un único punto, evaluada una sola vez en el instante en que pulsas el botón. Ese punto se redondea a una única celda de 8×8 píxeles del mapa. Si no cae justo en una celda "rompible", no rompe nada — aunque el puño esté visualmente tocando el bloque.
El código (ROM `$455E`–`$4577`) hace esto:
``` puntoX = xPos + 23 (mirando a la derecha) o xPos − 7 (a la izquierda) puntoY = yPos + 12 ← altura del puño EN REPOSO ... lee el atributo de UNA celda de 8×8 en (puntoX, puntoY) si (atributo & $C0) != $C0 → NO se rompe ```
Por qué encaja con lo que describes
1. Cero margen vertical. El desplazamiento `+12` es la altura del puño parado. En un salto, `yPos` cambia y el punto sube/baja contigo; si no aterriza exactamente en la fila de 8 px del bloque, falla. No hay barrido vertical.
2. Cero margen horizontal. Un bloque de 16×16 son 4 celdas de 8×8. El punto debe caer dentro de una de ellas; a un píxel del borde cae en la celda vecina (suelo/vacío) y falla.
3. Se comprueba una sola vez. Mientras el bit de "golpeando" está activo, no se vuelve a evaluar; da igual que el puño pase "a través" del bloque durante la animación.
Confirmación con tus dos states
Ambos estados tienen `v_alex.state = $03` (ALEX_IN_AIR) y el bit de puño activo: los dos ejemplos son puñetazos en el aire, justo el caso que mencionas. Calculando el punto de colisión de cada uno:
- golpe 2 → el punto cae dentro de un bloque (atributo `$E0`) → rompe. - golpe 1 → el punto cae en una celda con atributo `$82` (no rompible) → no rompe, aunque el puño toque el bloque.
(Sobre la interpretación píxel a píxel de los states hay algo de incertidumbre con el espacio de coordenadas/scroll; lo sólido y verificado es el código, que no deja lugar a dudas.)
Recursos que he dejado en el workspace
- `analisis_colision.md` — el análisis completo (abierto ahora). - `tools/z80d.py` — desensamblador Z80 propio (capstone 5 ya no trae Z80). - `tools/ram_golpe1.bin` / `ram_golpe2.bin` — RAM del SMS extraída de tus states (formato Genesis Plus GX / RZIP). - `akmw/` — el desensamblado de referencia de este juego (`lhsazevedo/akmw`), que confirma mi ROM (SHA1 `6d052e0c…`, CRC32 `AED9AAC4`).
Siguiente paso
El arreglo natural es cambiar el punto único por una caja que cubra el puño (~16×16 px): comprobar 2×2 celdas alrededor de `(xPos+e, yPos+12)` y, si cualquiera es rompible, romper el bloque. Eso daría el margen vertical y horizontal que hoy no existe, sin hacer que los bloques se rompan solos.
Edito 2: Aunque el informe pinta bien, parece que la cosa no es tan sencilla y nos vamos a tener que pelear más de lo esperado. Edito 3: Pues, ya está. Alex Kidd in Miracle World por fin tiene un ataque fiable. Ahora incluso nos podemos cargar dos o tres bloques en hilera mientras descendemos de un salto. Tranquilos, no es que dejes el botón pulsado y lo rompas todo: el puño dura lo que dura. Voy a crear un hilo propio para el parche y luego añado el proyecto al mensaje inicial de este hilo. Edito 4: Hilo propio creado, subido a RomHacking.net y GitHub e incluido en el mensaje inicial de este hilo.
psicopompo escribió:@wah_wah_69 Una cosa que llevo pensando al leer todo lo que estás haciendo con Shadowrun: creo que estamos enfocando el romhacking con IA de maneras bastante distintas, y precisamente por eso me parece interesante comentarlo.
Claro, es que yo realmente no lo planteo únicamente como traducción, si no como acto de ingeniería inversa completa del juego. Normalmente para traducir un juego es suficiente con cambiar glifos, cambiar alguna rutina de texto/menus, editar algún gráfico que otro y ya.
Tanto con el otro proyecto como con Shadowrun, tras el dissasembly inicial me he puesto a hacer preguntas sobre el engine del juego, planteando preguntas de forma vaga como:
"¿Cómo funciona exactamente el sistema de menús? ¿Qué formato usan los savegames?"
De primeras analizando los dissasemblies de forma estática va adquiriendo un conocimiento más o menos general del código, pero llega un punto en el que empieza siempre a pedirte ver el código en ejecución, ahí ya tiene más sentido tirar de trazas o debugger. Dejar que el LLM controler el debugger nunca me ha dado buen resultado porque el LLM no es capaz de reaccionar al ritmo de ejecución del juego (si no es capaz ni de diferenciar si estoy en modo headless o no, si el emulador ha crasheado o no...).
Lo interesante es que el propio modelo a veces empiezar a hablar en términos del engine del juego que tú nunca le has planteado, como también muchas cosas las entiende mal... te deja la duda de si se está inventado todo o sí realmente ha "descubierto" partes nuevas del juego, yo normalmente a cada paso siempre le pido que documente todo en un .md dedicado a cada área, sonido, eventos, script... según toque, cuando termina le echo un ojo y si veo un disparate le digo que vuelva a revisar, a veces es un acto de fe.
De todas formas estos días no he podido meterle mucho tiempo a esto, creo que sí conseguí por fin decodificar correctametne las fuentes, aunque mapear todos los glifos aún no, parece que el juego no usa JIS/SJIS si no su propio encoding (o eso es lo que me cuenta el modelo de turno).
Una cosa con la que me pelee bastante fue con algo tan tonto como lanzar el emulador para que hiciese las trazas, a veces me lo lanzaba headful cuando lo quería headless y viceversa aún cuando le pedía explicitamente como lo quería, el propio modelo se hacía un lío sobre si estaba en Wayland o X aún cuando ya había lanzado el emulador sin problemas montones de veces antes, cambia configs que no debe, usa el directorio que no toca... etc. Lo normal con el no determinismo de los LLMS.
Me quedo con la duda de si no usar mejores modelos de pago obtendría mejores resultados, pero al final no puedo justificar el gasto... esto no deja de ser un experimiento por pura diversión, no un trabajo. He estado usando todos los modelos que he visto gratis por Opencode, Openrouter y Tokenrouter.
Por otro lado no se si abandonarlo o seguir con él como proyecto secundario porque acabo de leer que hay una traducción ya publicada a modo de beta/demo que permite llegar hasta el final (aunque algunas cosas aún están por traducir).
En los mismos comentarios de ese post de reddit hay otra persona que lo estaba traduciendo al francés de Canada (con sus fuentes con acento y todo eso...) y también creo que había un grupo de traducción que llevaba años con el proyecto parado.
psicopompo
MegaAdicto!!!
1.820 mensajes desde abr 2017
Editado 2 veces. Última: 11/09/2026 - 05:22:52 por psicopompo.
wah_wah_69 escribió:Lo interesante es que el propio modelo a veces empiezar a hablar en términos del engine del juego que tú nunca le has planteado, como también muchas cosas las entiende mal... te deja la duda de si se está inventado todo o sí realmente ha "descubierto" partes nuevas del juego,
Sí, a veces pasa, pero yo lo veo más como un error mío por falta de contexto o claridad.
wah_wah_69 escribió:yo normalmente a cada paso siempre le pido que documente todo en un .md dedicado a cada área, sonido, eventos, script... según toque, cuando termina le echo un ojo y si veo un disparate le digo que vuelva a revisar, a veces es un acto de fe.
wah_wah_69 escribió:Me quedo con la duda de si no usar mejores modelos de pago obtendría mejores resultados, pero al final no puedo justificar el gasto... esto no deja de ser un experimiento por pura diversión, no un trabajo. He estado usando todos los modelos que he visto gratis por Opencode, Openrouter y Tokenrouter
Los modelos de pago están a años luz de las versiones gratuitas. Mucha gente vive aún con la idea de que la IA es como en 2023, cuando lo cierto es que en los últimos 6 meses ha avanzado más que en todos los años anteriores. Un modelo como ChatGPT 6 Astra es una brutalidad lo que es capaz de hacer sin que le tengas que ir tirando de las orejas. Ahora bien, para mí no justificaría el gasto si fuera sólo para romhacking, pero es que hoy en día tener una herramienta así es una ventaja bestial por todo lo que puedes llegar a hacer.
En cuanto a lo de los modelos que has visto gratis, te voy a recomendar (y a todos los que nos lean) Freebuff —quizá ya lo conocías—. Básicamente es un agente de IA de escritorio que accede a una carpeta local de tu ordenador para editar y probar código usando diferentes modelos de lenguaje. Tiene su propio modelo gratuito, varios de pago pero con cuota diaria gratuita de 100 puntos (dependiendo del modelo que escojas, esos puntos te pueden conceder más o menos tiempo de uso) y otros que son directamente de pago. Aún no lo he probado a fondo porque ya tengo una suscripción, pero mi hermano lo usa y dice que está realmente bien. Si alguno de vosotros lo prueba, que nos dé sus impresiones.
INFORMACIÓN:
Freebuff es una plataforma de programación gratuita impulsada por inteligencia artificial que ofrece herramientas para crear aplicaciones web y sistemas de chat de manera sencilla. Esta plataforma se destaca por su acceso sin suscripciones, claves API ni límites, haciendo que el desarrollo y la programación estén al alcance de todos.
• No se requiere suscripción ni claves API. • Proporciona las mejores herramientas de código abierto. • Incluye Freebuff CLI y Freebuff Web, ofreciendo un flujo de trabajo de código sin costo alguno. • Permite construir aplicaciones integrales y chatear con inteligencia artificial de forma gratuita.
Freebuff es ideal para desarrolladores, estudiantes de programación y cualquier persona interesada en aprender y construir aplicaciones web sin enfrentarse a barreras económicas. Es una solución adecuada para quienes buscan herramientas alternativas a servicios pagos como GitHub Copilot CLI.
• Acceso a Freebuff CLI, un agente de codificación gratuito desde el terminal. • Construcción de aplicaciones web con Freebuff Web, desde la idea hasta la implementación. • Freebuff Chat, que ofrece un chat de IA para responder preguntas y explorar ideas. • Compatibilidad con diversos modelos de IA de última generación, como DeepSeek v4 Pro/Flash, Kimi K2.6 y MiniMax M2.7.
Una de las consideraciones de Freebuff es que está respaldado por anuncios de texto, lo cual es importante tener en cuenta para aquellos que prefieren experiencias completamente libre de publicidad. A pesar de ser una alternativa gratuita a muchos servicios pagos, los usuarios deben estar conscientes de que este modelo de negocio puede influir en la experiencia de uso.
wah_wah_69 escribió:Por otro lado no se si abandonarlo o seguir con él como proyecto secundario porque acabo de leer que hay una traducción ya publicada a modo de beta/demo que permite llegar hasta el final (aunque algunas cosas aún están por traducir).
A ver, lo vi en los foros de RomHacking.net, pero yo no lo abandonaría. Por bien que me pueda desempeñar con el inglés, si un juego no está en castellano, no lo considero traducido. Está muy bien saber inglés (lo digo por todos aquellos que suelen saltar a la yugular con el rollo de que hay que saber inglés por cojones), pero para mis momentos de ocio prefiero mi propio idioma.
CONSULTA ¿Debería poner Freebuff en el mensaje inicial dentro de una sección de 'herramientas recomendadas'?
![[looco]](/images/smilies/nuevos2/borracho.gif "loco")
![[amor]](/images/smilies/nuevos/enamorado.gif "enamorado")
Gracias 
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
pero me gusta como avanzas este tema, seguro que a medida que avancen los modelos será mucho más fácil y directo. Igual con Fable 5.1 o el Astra nuevo ya lo es, pero esos no entran en las subs todavía. 
