Diferencias entre la ROM original de Golden Axe de Megadrive y la versión 1.1

Del juego ni idea, apenas si he jugado al golden axe

Pero sobre el picodrive, unos meses atras estuve dando algunos toques a la version de PSP, y compilando diferentes versiones usando core musashi y cyclone

No se que core usa la build de Pi, si podes usar entre los dos, o si usa otro tipo de core

Fijate eso, porque depende el core, cambia la compatibilidad


Sinceramente, poria probar diferentes cores, pero sin un savestate del punto jodido, es dificil, porque tendria q jugar al juego, y ni ganas

saludos

theelf escribió:Del juego ni idea, apenas si he jugado al golden axe

Pero sobre el picodrive, unos meses atras estuve dando algunos toques a la version de PSP, y compilando diferentes versiones usando core musashi y cyclone

No se que core usa la build de Pi, si podes usar entre los dos, o si usa otro tipo de core

Fijate eso, porque depende el core, cambia la compatibilidad


Sinceramente, poria probar diferentes cores, pero sin un savestate del punto jodido, es dificil, porque tendria q jugar al juego, y ni ganas

saludos

Lo de la Pi es anecdótico. He probado a compilarlo todos los cores de emulación de las CPUs, como ya he dicho, y el problema aparece con todos.
También lo he compilado tando en PC como en la Pi, aunque eso da igual.
El error aparece indistintamente.

Menos mal q el problemilla sale en la demo, porque ni ganas de jugar al juego

Efectivamente da igual el core del 68k q uses el problema sigue ahi, por lo que asumi que o es el tema del vdp, o los parametros que le pasa el emulador al/los core

No tenia pinta de problema del vdp (no directamente), asi q enfoque en los parametros q se le pasa al 68k


A tu primera pregunta, no tengo la megadrive conectada, pero a la segunda, creo que el problema viene que para parchear la rom, deven haber usado "codigo" de una rom PAL (o es una rom PAL parcheada a NTSC..)

Como en PAL necesita un timing diferente, probablemente esa parte que copiaron/pegaron, espera mas ciclos por linea al estar usando el codigo en NTSC, de ahi el error


Estuve echando un vistazo al codigo del picodrive, y encontre la solucion. Mira, probe la rom con el picodrive normal, y el problema q dices






Y aca arreglado, basicamente extiendo los ciclos, para que le de suficiente tiempo a completar las instrucciones, como si fuera PAL




Como jugar a la rom en PAL es un palo, podes hacer un hack del codigo, para que si se carga este juego (comproba la CRC) le de mas ciclos por linea al 68k

Calculando asi por arriba, teniendo en cuenta la diferencia de PAL/NTSC (262/312 lineas) diria que con unos 520/530 ciclos seria mas que suficiente para el juego, aunque habria que jugarlo completo para ver si salen errores

Cambia ese parametro en codigo, y compilalo de nuevo




Probablemente otros emus, sean mas generosos con los ciclos y no dan el error


Saludos

Joder, TheElf, muchas gracias tio! Eres un máquina.
Yo del funcionamiento interno de los emuladores no tengo ni puta idea, sólo de los backends externos.
Si te he entendido bien, el problema es la ROM y no el emulador en sí, que estaría haciendo lo correcto al dispensarle solamente los ciclos por línea que todo juego NTSC necesita, y este juego, como está mal (probablemente una ROM PAL parcheada), muestra errores. ¿Estoy en lo cierto?

Pero claro, si ajusto los ciclos por línea del 68K a, digamos, 520 o 530 para compensar el problema de la ROM ¿no aparecerán errores en otros juegos como resultado? Es decir, no puedo probarlos todos pero ¿podría ocurrir?
Lo que me deja pillado es que en pico_cmn.c tenemos originalmente:

Entonces no parece que haga falta un número de ciclos distintos para PAL que para NTSC, según el autor original (notaz).
Lo que busco, una vez que tenemos la causa acotada gracias a ti, es qué valor sería el "bueno" para todos los casos, o si este 488 es correcto después de todo.

También quería preguntarte si has encontrado algún define similar para los ciclos por línea del Z80, ya que esta ROM 1.1 también hace cosas raras con el audio que la normal no hace.

Hola, en un principio no es problema ni de la rom ni del emulador, parece se run problema del tio que la armo

A ver, estoy haciendo supociciones, ya que no investige la rom... mi idea es que o esa rom era PAL, o parchearon algunas partes usando el codigo de una rom PAL (que se yo.. por ejemplo la desensamblaron y le dieron a la maquinita de copiar/pegar)

Los 488 ciclos son los mismos en PAL o NTSC (bueno, casi, los cristales varian un pelin la frecuencia) porque las lineas son diferentes... asi que si, es un valor correcto

En PAL tenes 312 lineas (vblank+hblank) y en NTSC 262, pero en ntsc 60hz y en PAL 50hz, asi que se compensan (lineas/hz da el mismo resultado)

El problema es cuando tenes un juego programado para PAL, y lo forzas en NTSC que le da menos lineas, si el juego espera poder ejecutar codigo en esa parte del hblank que ya no existe dara un problema. Ahi los 488 ciclos no son "correctos"... no se si me hago entender... porque estas creando una situacion que no deveria darse



Tuve bastantes de esos dramas cuando estuve programando el emulador de MasterSystem para la PSP, ya que la mayoria de los juegos son PAL, cuando la portatil de sony, tiene un TFT de 60hz, asi que lo que hice fue extender las lineas, basicamente crear un modo PAL virtual

Eso en hardware real imagino es "imposible" va no... habria que cambiar el cristal...


Volviendo al tema, si aumentas los ciclos en teoria no deveria ser un problema, luego en la practica, es muy dificil decirlo, ya que cada juego es un mundo, y en esa epoca los programadores usaban muchos trucos


Teniendo en cuenta que arreglar la rom deve ser dificil (sabra dios que hicieron...), y que no parece ser un dump demasiado fiel.... lo mas logico seria meter un trozo de codigo que cuando detecte el CRC de esa rom, use mas ciclos, y si no, lo normal

Cada rom tiene un CRC unico, asi que no seria problema, no se algo tipo esto






Sobre el Z80, en un principio imagino la variable PicoSyncZ80 seria una buena candidata para comenzar. El tema es que el z80 es mas dependiente en este caso, ya que el 68k le pasa las instrucciones. Veo en el archivo "pico_int" una variable #define cycles_68k_to_z80 que habria que comprobar



Sinceramente, como no es un tema de mi interes, no lo he visto a profundidad, siento que no te pueda dar mejor informacion

Saludos

Que no lo has visto en profundidad?? Joder macho, menos mal que no lo has visto en profundidad!
Muchísimas gracias por tu ayuda!

Por cierto, he conseguido parchear la ROM original (no la 1.1) con esto:
http://www.romhacking.net/hacks/2082/
.. que es la razón por la que quería usar esta ROM 1.1 chunga. Así que voy a dejar el PicoDrive como está, sabiendo que para MegaDrive es un emulador muy fiel (32X falla con muchos juegos, pero la MegaDrive pelada va genial) y que el problema es más del chapuzas que hizo esa ROM V1.1.

Gracias, TheElf!

Me alegro que encontraras una solucion

Si efectivamente, el picodrive esta haciendo bien su trabajo, se le podria achacar alguna falta de opciones de video para portatiles con pantallas fijas a 60hz, pero no que no este emulando correctamente

Bueno, si encontras alguna otra falla en alguna rom PAL o modificada, ya tenes una opcion mas a probar para encontrar una solucion

Saludos