Normalización de imágenes .z80

[Bubu]

Un ejemplo de lo que digo; abro un TZX cualquiera con el Spectaculator, y veo ahí los bloques mientras se cargan:



Cuando llega al final del último, el Spectaculator automáticamente apaga el cassete, por lo que este emulador sabe perfestamente cuándo ha finalizado la carga. Pues AHÍ es donde yo haría un volcado de los 48KB de memoria RAM, jiji

Fácil, ¿ein?

[antoniovillena]

Cada emulador tiene su propio criterio a la hora de parar la cinta, por lo que obtendrías distintos .z80 y por tanto ninguno "normalizado". La diferencia puede ser de unos pocos ciclos o de varios milisegundos, pero esto hace que los .z80 sean distintos.

Todo esto suponiendo que el juego sea monocarga, si es multicarga la cosa se complica. De hecho un mismo .tzx puede ser monocarga en 128k y multicarga en 48k. Spectaculator detiene la cinta varias veces, no hay forma (automática me refiero) de saber en cual de ellas empieza el juego. Es más, ni siquiera hay un método automático que te diga que el primer bloque es un cargador, porque bien podría tratarse de un juego en BASIC.

En resumen, puedes "normalizar" un juego si manualmente detectas mediante depuración que se ejecuta la primera instrucción en código máquina del mismo (tras haber pasado todos los cargadores, las desprotecciones, las descompresiones, etc...). Lo que no puedes hacer es tratar que un emulador haga automáticamente ese trabajo por tí.

[Bubu]

Sin saber mucho sobre esto de los formatos de archivos para emuladores, yo te diría que sí que el emulador sabe exácticamente dónde se debe parar la cinta. En la documentación sobre archivos TZX lo tienes:

http://www.worldofspectrum.org/TZXforma ... PAUSEBLOCK

Como verás, sólo tiene que detectar en el ID 20 un valor 0. Eso signfica parar el cassete.

[wilco2009]

Lo que te dice Antonio es que el emulador no sabe si el juego es multicarga o no, por lo que no puede saber exactamente si debe parar o esperar al siguiente bloque.

Esperar al final de la cinta sólo sería válido para los juegos de una sola carga, y aun así un tzx puede tener una pausa ligeramente más larga que otro.

[antoniovillena]

En ese caso el emulador sabría exactamente dónde parar la cinta, pero no te dice en qué instrucción y en qué ciclo exacto parar el snapshot. Algunos emuladores lo pararán en un punto y otros lo pararán en otro, por lo que el hash (MD5 ó SHA1) del fichero sería distinto. Es más, el formato z80 permite una especie de compresión RLE y un mismo archivo se puede comprimir de varias formas, por lo que dependiendo del codificador RLE del emulador el hash para un mismo snapshot sería también distinto. Esto se puede arreglar forzando a que los .z80 no tengan compresión RLE.

En cuanto a la instrucción "Parar la cinta" del formato .TZX, se pone de forma manual y no es obligatorio ponerla, de hecho nunca la he visto en un fichero monocarga. Se supone que es una marca que la pone manualmente una persona, el creador del .TZX. No existe por ejemplo en el formato TAP.

[antoniovillena]

Lo que tú pides se podría hacer añadiendo la siguiente información a un marcador "Parar la cinta":

• PC que indica donde comienza el juego, este podría bastante tiempo después, sobre todo si hay descompresión.
• Bloques de memoria relevantes para el juego. Esto excluye al cargador.

Así sí que podrías estar seguro de que el hash es siempre el mismo. Es más, probablemente también den el mismo hash la versión TZX original y la versión desprotegida. Esto sería interesante pero sería un trabajo de chinos, porque esa información hay que introducirla en el TZX de forma manual.

Con esto no necesitas almacenar el .z80 ya que todos los emuladores generarían el mismo, y además tendría muchas utilidades más: desprotectores automáticos, conversores TZX a TAP, ultracargadores, compresores, etc...

[Bubu]

¡¡¡¡¡OOOOOOOOOOOOHHHHHHHHHHHH!!!!!!

Eso sí, eso sí pué ser un poblema, efestivamenete, si el que genera un TZX ha dejado un poco de tiempo el cassette astivado... ufff...

Bueno, se me ocurre lo siguién: ¿y si hago una utilidad que cá vez que cargue un .tzx, grabe un volcado .z80 cá vez que deje de entrar datos por el EAR virtual (bit 6 del puerto 254)?
Así las cosas el último .z80 generado será el güeno del tó, ¿nor?

[antoniovillena]

Puedes hacer dicha utilidad, quizás te valga para tus propósitos. Pero no puedes llamarlos .z80 normalizados puesto que el snapshot estaría tomado al final del cargador, y si alguien saca una utilidad similar a la tuya, sacará snapshots diferentes (aunque el usuario no note la diferencia).

[Bubu]

Yo creo que sería exácticamenete el pispo .z80. Cualquier emulador que se trague los .tzx lo que hará será emitir por el puerto 254 sincronizadamente con la CPU, ¿nor? Por tanto cuando el emisor de datos por el puerto 254 ya no tenga nada más que emitir, parará la emulación justo en ese ciclo de reloj, y grabará el archivo .z80

Cualquiera que haga otra utilidad de estas generaría el mismo archivo .z80, siempre y cuando lo grabe en el primer ciclo de reloj sin puerto 254.

¿nor?


PD: Vuelvo a recalcar que esto no tié arsolutamente ninguna utilidad, no es más que un frikeo teórico para los que nos gusta hablar de estos jaleos, jiji.

[zx81]

Yo creo que sería exácticamenete el pispo .z80. Cualquier emulador que se trague los .tzx lo que hará será emitir por el puerto 254 sincronizadamente con la CPU, ¿nor? Por tanto cuando el emisor de datos por el puerto 254 ya no tenga nada más que emitir, parará la emulación justo en ese ciclo de reloj, y grabará el archivo .z80

Cualquiera que haga otra utilidad de estas generaría el mismo archivo .z80, siempre y cuando lo grabe en el primer ciclo de reloj sin puerto 254.

¿nor?


PD: Vuelvo a recalcar que esto no tié arsolutamente ninguna utilidad, no es más que un frikeo teórico para los que nos gusta hablar de estos jaleos, jiji.

Nada mejor que un ejemplo para demostrar que no es tan claro como piensas: Babaliba (el primer TZX, medium case). ¿Cual es ahí el último bloque del juego?