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

[nataliapc]

Que bueno!

Llamamos a este bloque "Protección Opera"?

Estaba pensando que se podría añadir una opción al makeTSX para que buscara este tipo de bloques con algun parametro tipo /pOpera

Buscando datos sin cabecera solo con ese parametro para evitar que interfiera en la generacion del resto de cintas sin proteccion.

Qué os parece?
Se os ocurre alguna otra forma de reconocer este tipo de bloques sin que afecte al resto?

[PabloMarmol]

Se os ocurre alguna otra forma de reconocer este tipo de bloques sin que afecte al resto?

Pues por lo que dice BlackHole,

Código: Seleccionar todo

IF  lo_primero_que_encuentro_tras_un_silencio_entre_bloques_son_256_bytes_a_FF_y_no_un_tono_guia
THEN  debe_ser_un_bloque_de_los_locuelos_operísticos()


[nataliapc]

Ja ja ja xDDD
Algo de comprensión lectora tengo, pero gracias por la traduccion castellano-castellano xDDD

Me refería a la forma de integrarlo en el makeTSX, como busqueda exclusiva de ese tipo de bloques o intentar que lo detecte todo al mismo tiempo con el riesgo de dar falsos positivos.

[TINGIS53]

Hola @NataliaPC
Dado que parece tratarse de una protección exclusiva o casi exclusiva (siempre hay sorpresas) de Opera creo que la primera opción es la mejor haciendo una lectura del codigo solo para Opera.
Por supuesto como la programación no es lo mío , el metodo lo dejo a tu elección pues hasta ahora lo haces muy bien.
¡Saludos!

[PabloMarmol]

Me refería a la forma de integrarlo en el makeTSX, como busqueda exclusiva de ese tipo de bloques o intentar que lo detecte todo al mismo tiempo con el riesgo de dar falsos positivos.

Uhmm, no pillo lo de los falsos positivos. ¿Como podrían producirse?

[nataliapc]

Por ejemplo. ahora el programa distingue entre bloques 4B (MSX estandar), bloques 10 (standard data de spectrum), bloques 20 (de silencio), bloques 12 (tonos puros), y bloques 13 (secuencias de pulsos)... al menos en la versión de desarrollo que tengo yo (v0.8.1)

Habría que hilar fino para distinguir por ejemplo entre un bloque 4B sin pulsos piloto ("protección Opera") y un bloque 13 (secuencia de pulsos) que se implementa cuando todos los demás bloques dan reconocimiento negativo.
Sobre todo porque en un bloque 4B determino inicialmente los baudios sacando la media de los pulsos piloto y en la "protección Opera" no hay pulsos piloto, habría que detectarlo de otra forma.
Tampoco sabemos si este tipo de protección es siempre igual en todos los juegos, si es algo estandarizado en esta marca, o si es algo puntual de un par de juegos y en otros de sus juegos en vez de ser una serie de 255 '1's y luego un '0', es otra cosa distinta...

[PabloMarmol]

Habría que hilar fino para distinguir por ejemplo entre un bloque 4B sin pulsos piloto ("protección Opera") y un bloque 13 (secuencia de pulsos) que se implementa cuando todos los demás bloques dan reconocimiento negativo.

¿Pero quieres meter ese "bloque opera" en un bloque 4B ?
El "bloque opera" tiene 256 bytes FF delante, pero no son "bytes de datos", es una cabecera / tono guía.
Un tono guia raro, pero tono. No son "datos que vaya a cargar el msx".

No se si me explico. Si guardas el tono guia "como bytes" puede que dé el pego, pero va un poco en contra del espíritu de estas cosas, no?

Sobre todo porque en un bloque 4B determino inicialmente los baudios sacando la media de los pulsos piloto y en la "protección Opera" no hay pulsos piloto, habría que detectarlo de otra forma.
Tampoco sabemos si este tipo de protección es siempre igual en todos los juegos, si es algo estandarizado en esta marca, o si es algo puntual de un par de juegos y en otros de sus juegos en vez de ser una serie de 255 '1's y luego un '0', es otra cosa distinta...

Antes de plantearte siquiera como hacerlo en el maketsx (del que tampoco podemos entrar en muchos detalles ya que su desarrollo es cerrado) habría que ver si el .tsx como formato permite guardar estos bloques
("si permite guardar" en el sentido que se le dio al crear el formato, con un bloque propio. Porque claro que se podría guardar, en un bloque de pulsos, como todo, pero pa'eso se queda uno con el formato TZX y nos ahorramos este viaje)

[nataliapc]

Según he entendido a @Blackhole ese bloque de datos Opera es un bloque con el mismo formato que los MSX estandar pero sin pulsos piloto estandar y con una "cabecera" en los datos a base de 255 bytes a uno y 1 byte a cero que harían las veces de "cabecera piloto custom".

Este formato, evidentemente, no es un bloque 4B MSX Standard, pero la norma KCS (Kansas City), que es lo que en realidad representa el bloque 4B, es mucho más abierta que el pequeño subconjunto que representa la norma MSX y da la posibilidad de albergar este tipo de bloques y muchos otros más, aunque no sean bloques estandar de ninguna norma de microordenadores.

Un tono guia raro, pero tono. No son "datos que vaya a cargar el msx".
No se si me explico. Si guardas el tono guia "como bytes" puede que dé el pego, pero va un poco en contra del espíritu de estas cosas, no?

Sería un bloque exactamente con los mismos parámetros que un 4B MSX Standard pero con cero pulsos piloto estandar y albergando la cabecera de unos y el cero como datos. No veo el problema con esto...

Los pulsos piloto MSX estandar no son reproducibles como datos porque no cuentan con start y stop bits y además la norma KCS permite tener pulsos piloto de tamaño distinto a los pulsos usados para ceros y unos. Pero en este caso considero que la linea entre piloto y datos esta bastante difuminada, entre otras cosas porque estos "bytes piloto" si tienen esos bits de inicio y parada y porque el cargador de Opera (loader) los lee como si fueran otros bytes más.

Resumiendo: la gente de Opera alteró la especificación MSX KCS en estos bloques para hacerla no legible por los MSX de forma normal, pero aún así la mantuvieron dentro de la especificación KCS y como tal puede ser descrita por un bloque 4B.
Yo considero los bytes iniciales como datos ya se vayan a usar por el cargador como cabecera, como checksum, o como comprobación de sincronismo... eso ya depende y es cosa del cargador de Opera y cómo se lo monten.

Que me corrija @Blackhole si resulta que no lo he entendido bien...

[PabloMarmol]

albergando la cabecera de unos y el cero como datos. No veo el problema con esto

Ok. Ese es (o era) el meollo de la cuestión. Si no supone un problema todo arreglado.

Pero como decía, creo que hacer "esa ñapa" no es bueno para el formato tsx.
La separación de conceptos, lo que son datos y lo que es "el formato en cinta", debería mantenerse.

[nataliapc]

Entiendo lo que dices y estoy decuerdo en esencia, pero en cuanto a definición no hay diferencia entre esa cabecera y los datos...

Nada me impediría a mi crear un juego en cinta cuyos bloques no tuvieran piloto y usar los primeros 256 bytes de datos como yo quisiera.

Según mi opinión lo importante sería mantener lo más sencillo posible los TSX y creo que esta es la forma más sencilla reproduciendo el bloque de datos original sin perdidas con un solo bloque TSX.

De todas formas (de confirmarse que he entendido bien lo que explicaba @Blackhole), ¿cual sería tu propuesta para codificar este tipo de bloques?