Extraer la informacion útil de los ficheros tap o tzx.

[decicoder]

En otro hilo se habló de convertir los .tzx a .snapshots .z80 justo acabada la carga. Cosa útil para los que utilizan sistemas +3e y/o ultracargas.

Se me ocurre otro planteamiento; a ver que les parece a los desarrolladores de emuladores.Se trata de observar como evoluciona la memoria ram y olvidarse de la entrada EAR o de llamadas a la rutina LOAD de la ROM .

Creo que lo más normal durante una carga es que sólo se cambian en RAM los datos que se están cargando.
Y además con una cadencia concreta que es lenta comparada con otras escrituras de ram, como la que se puede dar en una inicialización.
Un algoritmo podría detectar si se estan escribiendo continuamente y contiguamente en RAM x bytes en t tiempo.
Por ejemplo en C , si un emulador utliza un array de char para modelar la memoria del Spectrum, podría usar un array de struct para guardar el byte en memoria por un lado y el tiempo que fue modificado por ultima vez.
O hacer un especie de traza con cada modificación en RAM donde se apunte la direccion y tiempo

Con esto se tendría el primer paso para extrear la información que interesa de los .tzx: los bytes de hay en cada bloque del tzx y su dirección de inicio.
Ya solo quedaría averiguar el punto de entrada de ejecución un vez cargados los bloques y el registro SP, éste quizá menos importante porque la inicialización quizá ajuste el registro SP.

[mcleod_ideafix]

Creo que lo más normal durante una carga es que sólo se cambian en RAM los datos que se están cargando.

En realidad no. También cambia la RAM cada vez que se hace un PUSH, o un CALL, y ese tipo de instrucciones están practicamente en todos los cargadores (incluido el de la ROM) que conozco. Eso sin contar los cargadores que ponen contadores de tiempo en la pantalla mientras ocurre la carga, claro. En ese caso, las escrituras "aleatorias" a RAM se multiplican. Lo que pretendes es equivalente a un problema de extracción de información desde una fuente con ruido.

Con esto se tendría el primer paso para extrear la información que interesa de los .tzx: los bytes de hay en cada bloque del tzx y su dirección de inicio.

Pero esa información... ¿no está ya en los TZX? Al menos la información de la longitud del bloque sí que está, tanto en los bloques de carga normal como en los de carga turbo. Donde no estará, al menos directamente, será en los bloques de "señal pura".

Ya solo quedaría averiguar el punto de entrada de ejecución un vez cargados los bloques y el registro SP, éste quizá menos importante porque la inicialización quizá ajuste el registro SP.

Es que ese es el quid de la cuestión: el punto de entrada. Si se sabe eso, no hace falta nada de lo anterior. Se podría hacer con el algoritmo que comenté hace ya unos días en el hilo de WOS (y aquí). Basicamente, dejar correr al emulador leyendo el TZX, interpretándolo, y aplicándolo a EAR. Una vez que termina la carga, y en cuanto se detecta un intento de ejecución de instrucción en la dirección de comienzo, se para la simulación y se guarda el estado del emulador como un snapshot.

De hecho, estoy pensando que una aproximación heurística a la solución de este último problema podría ser esperar hasta que el emulador agote todo el fichero TZX. En ese momento, dejar que ejecute unos cuantos cientos de instrucciones, y entonces parar la simulación.

Otra aproximación podría ser, una vez agotado el TZX, esperar hasta que se ejecute una instrucción EI y entonces grabar el snapshot. Un EI indicaría que la rutina de carga ya no está usándose.

Otra posible consiste en esperar hasta que, una vez agotado el TZX, se haga una escritura en memoria de pantalla (una de las primeras cosas que hace un juego es borrar la pantalla de carga para sacar el menú de juego). Con algunos juegos, que esperan a que el usuario pulse una tecla antes de comenzar, esto no valdría, claro está.

Todo esto podrían ser opciones a elegir en la utilidad que convierte TZX a Z80.

También se puede dejar una opción en la utilidad para que el usuario especifique la dirección de ejecución (la dirección una vez que se alcanza, hace que se pare el simulador y se grabe el snapshot). Eso requeriría un esfuerzo colaborativo por parte de gente que fuera capaz de tracer una rutina de carga hasta el momento en que comienza realmente el programa y publicar esa información, igual que se publican otras como los POKE's. Conseguir esa información es muchísimo más sencillo que desproteger por completo la rutina de carga, y con las facilidades de depuración de los emuladores actuales, es pan comido.

[decicoder]

En realidad no. También cambia la RAM cada vez que se hace un PUSH, o un CALL, y ese tipo de instrucciones están practicamente en todos los cargadores (incluido el de la ROM) que conozco

Pardiez !! es cierto. Estaba obcecado con los cargadores que utlizo para cargas rápidas. La cosa se complica. ¿bastaría con que algoritmo descartese las escritura en ram coincidentes el registro SP?

Pero esa información... ¿no está ya en los TZX? Al menos la información de la longitud del bloque sí que está, tanto en los bloques de carga normal como en los de carga turbo. Donde no estará, al menos directamente, será en los bloques de "señal pura".

La dirección de incio no, y es vital. Luego el churro de bytes de cada bloque si está tal cual como va a quedar en memoria. Aunque segun el cargador se pueden añadri algunos pulsos que desplazan n bits toda la ristra.

Una vez que termina la carga, y en cuanto se detecta un intento de ejecución de instrucción en la dirección de comienzo, se para la simulación y se guarda el estado del emulador como un snapshot.

Pensemos en juego pequeñito (para 16 k) el jumpik Jack http://www.worldofspectrum.org/infoseek ... id=0002658 Está en formato tap , es decir utliza la rutina de ROM- Solo utliza un proteccion muy básica uno de los bloques no tiene cabecera. Es un poco despilfarro tener que tener guardado y luego cargar cargar todo un snap de 48k.

[mcleod_ideafix]

Es un poco despilfarro tener que tener guardado y luego cargar cargar todo un snap de 48k.

Si esto es para cargarlo desde un equipo +3E o un DivIDE, la memoria extra guardada es despreciable. Por otra parte, ¿existen snapshots de 16K? Que yo sepa, se hace distinción entre 48K y 128K, pero no entre 48K y 16K, y por último, si el sistema acepta snapshots de tipo Z80 comprimidos (que no sé si +3E o DivIDE lo admiten) entonces el snapshot se puede guardar así, y si el juego es de 16K, practicamente toda la memoria superior estará a 0, con lo que se comprimirá muchísimo.

[zxbruno]

No puedo añadir nada en términos técnicos pero creo que esto les podría ayudar. En mis interminables intentos de tratar de desproteger juegos para crear versiones "limpias" y con tan solamente rutinas de load de la rom, intenté usar el "debugger" de varios emuladores para tratar de encontrar la dirección de comienzo de los juegos. Como no sé codigo maquina, fue una labor llena de frustración que llegó hasta los oídos de Woody en #spin. Woody tuvo compasión de mí y concordó que el "trace" de los emuladores no es perfecto y no me ayudaría mucho en mi tarea. Por ese motivo añadió hace algunos meses atrás nuevas opciones a su emulador. El SpecEmu ahora permite cosas como:

-Elegir que el emulador se detenga justo cuando la cinta pare, o justo cuando comienza.
-Opción similar pero para el Plus 3 (útil para determinar a que dirección salta después de leer todo en el disco)
-Salvar el estado del emulador o exportar la memoria en ese momento, en el formato que querramos (otros emuladores solo permiten salvar en .szx cuando se está usando el debugger).
-PC Logging - Esto si que vino del cielo (¡gracias Woody!). Es mejor que el trace porque en el momento en que se comienza a hacer logging se guarda en un archivo de texto todo el codigo que el emulador ejecutó, absolutamente todo. Con esto se puede ver exactamente a que dirección saltó, que hizo el codigo, cuando, etc. Pero esta función de Specemu usa como 20MB cada 2 segundos...

Espero que esta información os sea util. Yo ya estaba cansado de tratar de hacer las cosas con trace y breakpoints. Las opciones que Woody me dió me han ayudado mucho, y creo que para quien sabe codigo maquina, mas utiles serán aún.

[zxbruno]

¿Alguna novedad sobre este tema?
También he querido hacer preguntas sobre el k7zx y proyecto otla, pero tengo que encontrar el archivo donde puse lo que quería preguntar.