antoniovillena escribió:Vale, ya he visto el código:
http://sourceforge.net/p/zesarux/code/c ... out.c#l505Veo que haces el parche en el emulador, mi idea era hacer el parche en el juego pero vamos que al final es lo mismo. Yo de momento no me he puesto con esto, tengo algunos juegos con carga custom o reubicada que pasar a TAP hasta completar la lista de Uto. En el momento en que me ponga y encuentre alguna rutina te la paso por aquí. Gracias por compartir tus progresos.
Hola
Bueno, yo no lo veo como un parche en el emulador.
Por una parte, tengo que el emulador captura cuando se salta a la dirección 10H (el rst normal a la ROM). Y luego también captura otras dos direcciones (second trap y third trap) para las cuales se imprime texto en pantalla... para aquellos juegos que no usan rst 10h. Normalmente sólo con second trap es suficiente, pero por ejemplo el Hobbit usa dos direcciones de impresión de texto
Aquí lo complicado es saber ese second trap. Si miras el archivo sslfunctions.c, hacia el final, detecto la cinta cargada y si son algunas conocidas (Cozumel, jabato, etc) directamente establezco el valor de second trap y ya se muestra el texto en consola correctamente
Luego hay otro método, y es que esos conocidos, utilizan lógicamente una rutina de impresión de texto, es lo que ves en los patterns del archivo scr_stdout.c que me decías. Todos los juegos de AD utilizan la misma rutina. Por tanto, si hay algun otro juego, diferente de los que tengo identificado, pero que utiliza la misma rutina de los de AD, el emulador la detectará y establecerá el valor del second trap
Y luego he añadido otro método totalmente automático, y es el que comentaba el otro dia, que no hace falta lista de juegos conocidos, y para aquellos que no usan RST 10H. Lo que hago aquí es:
1) Busco desde qué direcciones (registro PC) se está escribiendo al tercer tercio de pantalla (la zona inferior). Establezco un rango de direcciones por donde podrá estar dicha rutina. Lo que hago es que ese rango puede estar unas 500 direcciones por debajo o por encima del registro PC leído. Esto lo voy haciendo hasta que he leido unas cuantas (unas 2500 aprox)
2) Cuando ya tengo un rango definido por donde puede estar dicha rutina de impresión, busco un pattern simple (que he visto en casi todas las rutinas), que en mi emulador llamo "Multiply by eight", que esté contenido en dicho rango. El pattern es:
ADD HL,HL
ADD HL,HL
ADD HL,HL
ADD HL,DE o ADD HL,BC
Esto lo que hace es multiplicar el valor de HL *8 y sumar un offset, que puede ser el registro DE o BC, que hará que HL apunte a la tabla de caracteres, exactamente al principio del sprite del carácter a imprimir
Previamente a esto se suele leer el registro A (el caracter a imprimir), pasarlo al registro L, y establecer el H con 0
He probado unos cuantos juegos y para la mayoría se cumple esto
En el momento que el emulador encuentra ese pattern, establece el valor de second_trap y listo... ya tenemos salida de texto, sin conocer el juego previamente
Aqui hay una particularidad, y es que a veces esa rutina tiene esta instrucción previa:
SUB 32
Para establecer que el principio de su tabla de caracteres cuenta desde el caracter 32. Esto no sucede en todas, en algunos se le suma un offset por debajo de la tabla, para que al sumar HL con DE, apunte a donde toca.
De todas maneras, el emulador también detecta ese caso de manera muy simple: en los casos que hay que sumar, tendremos que los caracteres estarán restados 32, y por ejemplo el caracter espacio (32) se convierte en 0, y las minusculas saldrian como mayusculas... lo que hago aqui es que si leo un caracter 0, cosa que podria indicar que realmente es un espacio (caracter 32),, activo un flag que indico que hay que sumar siempre 32. Y listo
Resumiendo, que con este método automático funcionan casi todas. Y las que no funcionan, se puede localizar de manera relativamente fácil
Saludos
César