Formato de Cinta "Universal": Spectrum-Amstrad-Commodore-MSX

[BlackHole]

El TOSEC está diseñado para catalogar ROMs inamovibles de consolas. Tiene un objetivo determinado y no es catalogar cintas.

Que la herramienta MakeTSX permita incluir un comentario sobre el contenido del volcado, obviamente modifica el fichero final resultante, aunque no la parte de los datos. Pero claro, es más complejo, ya que realmente al ser la cabecera de metadatos que describe las frecuencias del sonido en la cinta, parte del propio fichero TSX/TZX, basta con que el cassette tenga menos pilas para que la cinta vaya más lenta y esos metadatos sean diferentes, aún siendo los mismos volcados válidos. Hasta las pausas entre bloque y bloque medidas en milisegundos son susceptibles de cambiar entre volcado y volcado, con el mismo ordenador y el mismo cassette y la misma cinta.

Lo importante sería aislar los datos de los metadatos, eliminar la cabecera de ese cálculo y calcular solo el CRC/MD5/SHA1 de la "carga útil" (payload). Ni siquiera en webs como CPC Power (de Amstrad) que son exhaustivas a tope, lo están haciendo. ¿Se podría hacer? Se podría calcular el CRC de cada bloque de datos reales, pero como un juego de cinta puede tener hasta docenas de ellos, ¿cuál elegimos? ¿Una suma de todos ellos? Quizás, pero el trabajo para hacerlo sería tedioso (bueno, un programa lo puede calcular, tampoco exageremos) y debería de ser por consenso de una comunidad.

En fin, que las cintas a mi modo de ver no son susceptibles de compararse con las ROMs y ese "problema" del TOSEC lo vamos a tener con cualquier formato que tenga un origen analógico. Pasa en los TAP del Commodore 64, en los CDT de Amstrad CPC y en los TZX de Sinclair ZX Spectrum. La forma de querer "catalogar" cintas tendría que ser otra y TOSEC no creo que a estas alturas modifique sus algoritmos.

[nataliapc]

Buenas, una duda que me surge viendo la estructura del TSX. Si tenemos 2 ficheros del mismo juego, generados con versiones diferentes o bien con el nombre modificado en la cabecera, cambiaria el CRC. ¿daria esto problemas a la hora de catalogarlos, por ejemplo en TOSEC?

Para eso estamos usando dos tipos de HASH (CRC/MD5/SHA1 o el que uses), los File Hash y los Data Hash.

Con los File Hash tendríamos los problemas que indicas, que por modificar cualquier byte, incluyendo info, los baudios de la cinta, o las pausas entre bloques, cambiaría el HASH.

Para eso hemos creado y estamos usando el Data Hash, el cual para generarse, utiliza solamente los bytes de los bloques que contienen datos efectivos (sin sus cabeceras), para así poder ser más fácilmente catalogables y comparables.

Puedes ver esto que te cuento en los listados de la web http://tsx.eslamejor.com

[BlackHole]

Ah! Pues mira... es lo que comentaba en mi mensaje anterior. Sin saberlo ya se estaba haciendo.

La verdad es que no sigo muy de cerca el proyecto, mea culpa

[Bubu]

Respecto a identificar las cintas mediante hashes, realmente es imposible hacerlo análogo a un cartucho, por el simple hecho de que un cartucho es información digital (exacta) y una cinta es analógica (inexacta). Pero sí que se podría hacer lo siguiente: si vuestro método es capataz de generar un TSX a partir de una cinta, como si de un TZX se tratara, ese TSX ya tendría un hash, y además y lo más importante es que si lo vuelvo a generar una segunda vez a partir de otra cinta, me daría el mismo hash, ¿nor?
Es que si esto es así no veo qué poblema habría con considerar que el archivo tsx sería como la "digitalización" de la cinta.

[nataliapc]

... y además y lo más importante es que si lo vuelvo a generar una segunda vez a partir de otra cinta, me daría el mismo hash, ¿nor?
Es que si esto es así no veo qué poblema habría con considerar que el archivo tsx sería como la "digitalización" de la cinta.

Es que no tiene por qué dar el mismo HASH porque también se están guardando pausas entre bloques y velocidad de reproducción entre otras cosas... y eso puede depender de algo tan tonto como de la velocidad de cada motor de reproductor de cassette al crear el WAV.

Por eso mismo estamos distinguiendo entre File Hash y Data Hash.
Lo tienes arriba mejor explicado...

[Bubu]

Vamos, en resumidas cuentas: 2 cintas del mismo juego pueden y normalmente harán producir 2 archivos TSX distintos, ¿nor?

Por tanto, lo que quedaría es un proceso de "limpieza" del TSX, uséase, alguna utilidad que coja el TSX generado desde la cinta, y genere un TSX único y limpio, y por supuesto que el juego cargue y funcione. Así, 2 cintas distintas del mismo juego darían el mismo TSX limpio final.

[imulilla]

Por lo que comenta Natalia yo no me complicaba y solamente tendria en cuenta el data hash para catalogar.
¿el data hash se puede calcular con el fichero? Estoy intentando crear un .dat para romcenter

[Bubu]

Pero es lo que digo, que para catalogar un juego de cinta, por mucho datahash que uses, te tienes que asegurar que ese datahash sea el mismo para 10 cintas diferentes del mismo juego, con volúmenes diferentes, etc. Como creo que esto no es así, el datahash debería de pasar por un proceso previo de "depuración" de tal manera que las 10 cintas queden con el mismo datahash, y entonces ya sí se puede catalogar.

Digo yo

[imulilla]

Segun lo que comentaba Natalia, entendi que el "Data hash" siempre es el mismo siendo el mismo juego, porque son los datos reales del software. Por ejemplo si fuera un programa en basic, ese hash se calcularia en base al listado del programa; que daria igual si el programa sie cargara de cinta o de disco, tendria el mismo hash. Al menos eso es lo que yo he entendido

[Bubu]

Ah, pos yo no lo veo tan claro... Pensaba que el TSX era análogo al TZX, no al TAP. El TAP sí que son direstamente los bytes que van a la RAM, pero el TZX está relacionado con el sonido que genera el cassette.
A ver si el personal nos lo aclara.

Y tengo otra duda: ¿este sistema es válido también para el ZX81?