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

[imulilla]

He actualizado el plugin del romcenter, ya soporta bastantes bloques, he probado desde el "007 a view to kill" hasta el "abu simbel" y los identifica correctamente. Probadlo y me contais.

Actualizado:Ya coge todos juegos menos el Break Out, pero creo que el algo del romcenter, porque el crc lo coge bien.
Esta subida la nueva version al ftp, lo pongo aqui tb

[zerobyzero]

Esta semana lo pruebo, imulilla y además te digo si tus CRC32 coinciden con los míos.

EDITO:

Todo en orden. Le he pasado un scan a las ROMs sin comprimir y no ha habido ningún problema.

tsx-romcenter.png (385.83 KiB) Visto 10146 veces

Y ahora un par de cosas en las que he estado pensando; a ver si me explico sin enrollarme demasiado:

1. La mejor opción es definitivamente usar el hash de los datos+metadatos de cada bloque. Así queda toda la estructura de la cinta cubierta y no nos dejamos nada por el camino. En tu plugin, imulillas, has incluído solo el contenido de los datos de cada bloque (al igual que los datos de tsxeslamejor).
2. Hay que omitir totalmente algunos bloques, como los que contienen información TOSEC y demás. Esos datos no vienen en la cinta original.
3. La cabecera del TSX y el bloque de metadatos TOSEC pueden tener longitud variable con lo que habría que a) borrarlos de los dumpeos, o b) restringirnos a ROMcenter y utilizar el plugin para saltarlos... pero queda una solución que creo que es más flexible...
4. Convertir los meta-datos de longitud variable a longitud fija. 256 caracteres por cada campo sería más que suficiente (imagino). Al tener longitud fija la cabecera es fácilmente saltable tanto en ROMcenter como en ClrMamePro sin ningún tipo de plugin.

Un saludo.

[imulilla]

Gracias por probarlo, te voy contestando/preguntando.

-Todo en orden. Le he pasado un scan a las ROMs sin comprimir y no ha habido ningún problema.

¿no te da "break out" como desconocido? ¿no te salen algunas duplicadas, (supongo que porque seran la misma)?

[*] Convertir los meta-datos de longitud variable a longitud fija. 256 caracteres por cada campo sería más que suficiente (imagino). Al tener longitud fija la cabecera es fácilmente saltable tanto en ROMcenter como en ClrMamePro sin ningún tipo de plugin.[/list]

Me parece bien, ya lo la gente diga

Un saludo.[/quote]

[zerobyzero]

¿no te da "break out" como desconocido? ¿no te salen algunas duplicadas, (supongo que porque seran la misma)?

No, no recuerdo ningún error. De todos modos luego le echo otra pasada a ver qué tal.

[imulilla]

Me ha pedido permiso el creador del Romcenter (que fue el que me paso el fuente del plugin del que viene) para incluirlo en la RC4, le he dicho que es una beta y que posiblemente falle, pero que encantado con que lo haga

[imulilla]

He estado trasteando con los .wav que hay en el FTP y muchos no cargan en el OpenMSX y el Maketsx detecta errores, sin embargo en un MSX real (mp3 a puerto de cassette) van perfectamente. ¿es por el fallo del Openmsx con las velocidades de algunos wav o es que el MSX recibe mejor señal?

[AlesteDX]

Buenas señores...

Me alegro mucho de que esto vaya avanzando, que se haya liado la gente a generar muchos TSX y que ya se esté hablando del soporte por emuladores e incluso en RomCenter.
Sin embargo, me gustaría dar mi opinión y hacer algunos comentarios sobre todo esto que se está hablando de los CRCs y de la identificación de los volcados.

Lo que habría que hacer es ver cómo lo hacen en otros sistemas que usen el formato, y en concreto en el formato originario: Spectrum y TZX. No olvidemos que nuestro TSX no es más que una ampliación de ese formato, y que todas las dudas y opciones que se están planteando ya las tuvieron en su momento esos usuarios, por lo que habrá unos procedimientos establecidos y unas soluciones a las que llegaran en su día para la catalogación y clasificación. Se trata de no reinventar la rueda.

Yo por mi parte soy partidario de incluir los metadatos en los cálculos de checksum, pero eso sí, estandarizando de alguna manera la información reflejada y extraida de la cinta, me explico un poco mejor a continuación.

En mis tiempos hice algunos volcados de cintas de Spectrum en TZX, y nunca una misma cinta producía un TZX idéntico. Ningún motor de casete normal (a lo mejor la NASA tiene uno que sí) es tan estable como para tener siempre la misma velocidad en todo momento, y las cintas tampoco están en las mismas condiciones después de dos pasadas que de veinte, si llevan tiempo sin usarse. Así que a veces un silencio era de 995 ms, y en otro intento ese mismo silencio era de 1003 ms. Sin embargo el estándar de grabación de Spectrum dictaminaba que ese silencio era de 1 s (1000 ms) y la lógica así lo indicaba también.
El tema de los baudios es el mismo caso, sin embargo aquí el MakeTZX sí que redondeaba habitualmente la cifra detectada y lo marcaba como carga estándar aunque fuera un poco más rápido o lento de la cuenta, corrigiendo él mismo las desviaciones del motor de la cinta.

Aplicado esto al MSX, yo soy partidario de corregir los metadatos a las cifras "oficiales" del estándar o a lo que la lógica dicte para los resultados obtenidos. De esa manera 1150 o 1250 baudios serían claramente 1200 baudios, mientras que los tiempos de silencio o de tonos guía habrían de ajustarse a lo definido en el estándar. Claro, esto no se puede aplicar a todas las cintas ya que muchas tienen carga turbo o silencios de duración no estándar. Pero es un buen punto de partida y de esa manera obtendríamos una manera de estandarizar y unificar también los metadatos.
Por otra parte una vez que se hubieran volcado muchas cintas, ya se podría ir viendo la estructura habitual de las cargas turbo y las protecciones más habituales, aplicando entonces la estandarización o redondeo de baudios, silencios, etc...

En Spectrum ya hice muchas de estas preguntas que se están haciendo aquí, y las respuestas que me dieron es que había gente que lo hacía de una manera y otra gente que lo hacía de la otra: vamos que cada uno hacía lo que le parecía más correcto, sin que hubiera una manera de trabajar unificada.

Al principio lo importante era definir el formato y arrancar, pero ya que nos estamos poniendo serios quizás merezca la pena dedicarle un rato a todo esto que comento. Y prometo que cuando vuelva a tener tiempo empezaré a colaborar volcando mis centenares de cintas originales.

Un saludo

PD: por rizar el rizo, quizás estaría bien calcular y almacenar el checksum de las dos maneras posibles: solo los datos o datos+metadatos. De esa manera todo el mundo estaría contento y tendríamos la manera de identificar de manera inequívoca un mismo juego, y por otro lado ver si además es el mismo volcado u otro distinto.

[Bubu]

Ya planteamos hace unas semanas el tema este de los CRC's y cómo hacer que el mismo juego en distintas cintas, o incluso la misma cinta, diesen el mismo checksum, y vimos que lo único válido era considerar el "digital", no el "analógico", uséase, los datos en bytes que le llegan al ordeñador. Así sí se podría. Lo que no veo es el tema de las pausas esas en algunos sistemas de protección. Una pausa no es ni 0, ni 1. Es la nada. Y efestivamente podría darse el caso en que una cinta genere 37 nadas, p.ej., y cuando la vuelvas a pasar genere 38 nadas, y aun así cargar perfestamente. Esto es un problemón.

[AlesteDX]

Buenas...

Ya había leido todo lo que se ha planteado, mi mensaje es precisamente comentando sobre todo ese tema que se ha discutido.

De nuevo insisto en que no es nada inválido considerar los metadatos (la parte que tú llamas aquí como "analógica") además de los datos propiamente dichos para calcular el checksum. El objetivo primario de este proyecto es/era preservar fidedignamente las cintas de MSX, y por añadidura del Kansas City Standard, en un formato que preservara el formato original de los datos: silencios, pausas, tonos, etc, tal y como se hace desde hace mucho tiempo en otras plataformas con el TZX y sus derivados. Esta discusión concreta va más hacia la facilidad de catalogación y creación de dats para gestores de roms, que hacia propósitos de preservación fiel.

Respecto a la parte "analógica", no es tal realmente, un archivo TSX es completamente digital como cualquier otro archivo informático. Los metadatos lo que contienen son una descripción de cómo están contenidos los datos en la cinta, con sus pausas y silencios, baudios, tonos, etc... es una analogía de la parte analógica pero en datos digitales. Como tal es practicamente imposible, como ya decía, que dos volcados de la misma cinta, en el mismo reproductor y en el mismo momento resulten en dos volcados idénticos: los metadatos siempre van a cambiar.

La clasificación y catalogación de archivos de formatos de cinta lleva haciéndose mucho tiempo y es perfectamente posible, se consideren los metadatos o no (o se consideren las dos maneras posibles como proponía). No veo ningún problema en ello, y mucho menos el tema de las pausas como dices: que una pausa dure 37 ms y en otro volcado dure 38 ms es completamente trivial, al final el archivo que se publica es uno solo y no todos los volcados que se hacen durante el proceso. Y si otra persona vuelca la misma cinta y a él le salen 40 ms, si los datos son idénticos pues habrá que elegir uno u otro volcado para el dat, así de simple (normalmente el que primero se publica).

No obstante vuelvo a reiterar que la solución a estos problemas de catalogación es la estandarización del procedimiento y el calcular y mantener ambos checksums: el de los datos y el de datos+metadatos, y que cada uno utilice el que le parezca conveniente.

Un saludo

[imulilla]

Yo tambien veo bien mantener los 2 crc, el de datos+metadatos para identificar la "release" y el de solo datos para identificar el juego/edicion en si, por el ejemplo, los 2 tsx que hay de "Bounder" dan el mismo CRCDATA con lo que entiendo que el contenido de la cinta es el mismo.