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

[BlackHole]

Espero que podamos sacar algo de provecho de todo ésto e intentar hacer las primeras conversiones, para lo cual es inevitable adaptar (tal y como tú apuntas), tu Herramienta para crear los ".TZX" con el nuevo Bloque de Datos.

Hola chicos. No sé cómo me va a ir la semana, porque tengo jaleos con el banco, unos recibos y una cuenta que se me ha quedado a cero porque Hacienda no me ha hecho la devolución de la Renta, y me va a dar buenos quebraderos de cabeza en unos días que pensaba aprovechar el Black Friday y el Cyber Monday...

En fin, puntualizar solo que la herramienta TZX2WAV no crea los TZX. Es una herramienta que crea WAVs a partir de un TZX y que solo serviría para comprobar posteriormente que el juego carga correctamente desde el WAV "limpito" generado digitalmente, en vez del audio proveniente del volcado de la cinta "analógica" hecho por Pablibiris, u otras personas a tal efecto.

Por ahora, ante la falta de herramientas que creen TZX a partir de la modulación del MSX, las voy a tener que hacer a manita con un editor hexadecimal, ojo. De hecho, el domingo por la noche estuve haciendo pruebas con el "Auf Wiedersehen Monty" y el WAV de Pablibiris tuve que editarlo con Cool Edit Pro porque justo en el tono guía tenía un corte que hube que borrar. Después del primer bloque de BLOAD, el resto del juego tiene bloques de Spectrum que el programa "MakeTZX" detectó a la primera.

Habría que hacer alguna mezcla entre el código fuente disponible de algún software que genere ficheros CAS, con el de algún otro software que genere TZX o CDT.

[manolito74]

Hola @BlackHole:

Ok. Gracias por la puntualización y gracias de nuevo por tu aportación.

En la medida en la que puedes y of course dentro de tus posibilidades de tiempo ¿"libre"? y esas cosas cualquier ayuda será bienvenida. El caso es empezar por algún sitio y luego ir dilucidando, hacer pruebas y seguir avanzando.

Gracias & Saludetes.

[BlackHole]

Buenas noches,

Hoy he estado programando sobre este tema, y he llegado a la conclusión de que aunque factible, resultaría bastante extraño encontrar cargas protegidas cuyo último byte no fuese de 8 bits, sobre todo por la existencia de bits de parada posteriores en cada byte. He decidido quitarlo del esquema y en el hipotético caso que apareciesen, siempre tendríamos el antiguo bloque TZX que se usa para pulsos sueltos.

Para que en las especificaciones de este bloque KCS, no quede entonces un bit aislado para indicar una posible ordenación MSb de los bytes (recordemos que el estándar los ordena en LSb por defecto), lo paso al anterior byte de control de la cabecera y reduzco el número de posibles bits de inicio y parada a un máximo de 3. Recordemos que también por defecto se usan 1 bit de inicio y 2 bits de parada por cada byte, por lo que sería raro encontrar más.

Por lo tanto, si nadie está en contra, la proposición quedaría de la siguiente forma:

     

Hasta ahora, todas las "protecciones" que he observado en el MSX son susceptibles de ser codificadas con los bloques preexistentes en el formato TZX. Por supuesto, mi conocimiento de la plataforma sigue siendo mínimo, así que salvo que algún gurú en protecciones de MSX diga lo contrario, dejo fijado el código de TZX2WAV. Esta madrugada o mañana subiré ejemplos de funcionamiento.

[Pablibiris]

Yeah! Yo de cosas tecnicas no tengo ni idea..que impotencia no poder echarte un cable con esto,leñe.
Y lo que daria porque estuvieran por aqui Martos o Robsy

[BlackHole]

Buenas. Incluyo aquí como adjunto el Auf Wiedersehen Monty de MSX en ese formato propuesto para TZX 1.21:

monty.tzx.gz

Auf Wiedersehen Monty (MSX)

(39.68 KiB) Descargado 375 veces

monty.wav.gz

Auf Wiedersehen Monty (MSX)

(137.51 KiB) Descargado 749 veces

Editado: Debido a un serio bug encontrado en el TZX2WAV 0.4 Beta del 26 de Noviembre, se ha eliminado dicha versión.

El fichero WAV es el generado por la aplicación, para comprobar su perfecto funcionamiento en un emulador que acepte ficheros WAV. Por supuesto, al ser contenido completamente digital, se puede ver que comprimido apenas ocupa un 0.66% de su tamaño original, algo que no se podría conseguir con la digitalización desde la copia analógica de Pablibiris.

La creación del fichero TZX podéis presuponer que ha sido una odisea generarlo. La parte "protegida" fue la más sencilla, pues afortunadamente la herramienta MakeTZX 2.33 reconoció automáticamente los bloques de datos, al estar éstos en formato Spectrum. La parte MSX tuve que crearla a mano, a partir de los datos creados por la herramienta CASTools 1.3 y rellenar el resto de la cabecera necesaria con un editor hexadecimal.

La utilidad TZX2WAV 0.4 Beta está programada para reconocer este nuevo bloque y mostrar información simple (-i) o detallada (-v) sobre el mismo. Quedaría pendiente para una futura actualización la posibilidad de reconocer las cabeceras MSX y proporcionar información sobre el nombre del juego y tipo de carga (BASIC, binario, etc), pero por ahora la herramienta es perfectamente funcional.

Compartir vuestras impresiones, por favor.

Un saludo.

[jltursan]

Un gran avance por lo que se ve

De momento lo que es en el emulador openMSX, tras unos minutos de tensa espera, el juego carga sin problemas (usad bload"cas:",r). El tono guia inicial parece algo entrecortado pero no da problemas.

Otro emulador que creo recordar que soporta WAVs es el MESS, por si alguien quiere ampliar las pruebas.

chapeau!

[Pablibiris]

Jurrrrrrr...yo esta madrugada me voy un mes y medio a Brasil y la unica tecnologia que me va a acompañar,es el movil
Voy a estar bastante OFF en estos dias. Pero en cuanto vuelva echare una buena mano en testeos y lo que esté en mis manos

[manolito74]

Hola de nuevo:

En primer lugar @BlackHole, agradecerte una vez más tu ayuda y tu trabajo.

Esta información creo que ya la había puesto en algún otro Post pero por si acaso te sirve de algo lo vuelvo a poner aquí (que más vale que sobre que no que falte)



Así pues tenemos que en MSX hay 3 tipos de Carga/Grabación desde/en Cassette:

-CLOAD/CSAVE.
-LOAD/SAVE.
-BLOAD/BSAVE.


Hay 2 velocidades diferentes para grabar nuestros Programas:

- 1200 baudios.
- 2400 baudios.


Cada Byte se graba siempre añadiendo un bit por la Izquierda (un 0) que indica el comienzo, luego iría el Byte propiamente dicho, y al final se añaden dos bits (dos CEROS) que indican el final del Byte.


Los Ficheros-Programas para grabarse en Cinta se graban en 2 Bloques:

- Un primer Bloque (Descriptor de Fichero) que nos indica el tipo de Fichero.
- Un segundo Bloque que contiene los Datos propiamente dichos.


Cada Tipo de Fichero (CLOAD, LOAD, BLOAD) tiene sus peculiaridades:


1. Ficheros CLOAD --> (BASIC)

■ Descriptor de Fichero, formado por:
-Cabecera Larga.
-10 bytes con el valor "D3" (el valor "D3" nos indica que es un Fichero CLOAD)
-6 bytes que contienen el nombre del Fichero.

■ Datos propiamente dichos del Fichero, formados por:
-Cabecera Corta
-Caracteres del Programa BASIC "Tokenizados"
-7 bytes con el valor "00" que indican el final del Fichero.

2.Ficheros LOAD/OPEN --> (ASCII)

■ Descriptor de Fichero, formado por:
-Cabecera Larga
-10 bytes con el valor "EA" (ese valor "EA" nos indica que es un fichero de tipo LOAD/OPEN)
-6 bytes con el nombre del Fichero.

■ Datos propiamente dichos del Fichero, formados por:
-Cabecera Corta.
-Bloque de 256 bytes
-Cabecera Corta.
-Bloque de 256 bytes
-Cabecera Corta.
-Bloque de 256 bytes
..........................
..........................
-Cabecera Corta.
-Un último Bloque que contiene 256 bytes con el valor "1A" (ese valor "1A" indica el final del Fichero)

3.Ficheros BLOAD --> Código Máquina:

■ Descriptor de Fichero, formado por:
-Cabecera Larga.
-10 bytes que contienen el valor "D0" (este valor "D0" nos indica que es un Fichero de Tipo BLOAD)
-6 bytes con el nombre del Fichero.

■ Datos propiamentes dichos del Fichero, formados por:
-2 bytes, que contienen la Dirección de Inicio.
-2 bytes, que contienen la Dirección Final.
-2 bytes, que contienen la Dirección de Ejecución.
-El Volcado de los Datos del Programa que están en memoria.

-La Instrucción TAPION (Dir. &H00E1), hace un "Motor On" y lee una Cabecera del Cassette (tanto larga como corta).
-La Instrucción TAPIN (Dir. &H00E4), lee solamente un Byte del Cassette.
-La Instrucción TAPIOF (Dir. &H00E7), pone fin a la Lectura desde el Cassette.


Pongo aquí también, por si sirve de algo, un Programa en Ensamblador que teóricamente reconoce e identifica cada tipo de Carga. Según el Autor, este Programa ".Asm" parece funcionar con los bloques "Bsave" y "Csave" pero, curiosamente, aunque carga los bloques "Save" el código no aparece "tokenizado" en el debugger, de forma que no se puede Listar.

Código: Seleccionar todo

CSAVE_FILE      equ   0xD3      ; eof = n data hasta 7bytes 0x0
SAVE_FILE      equ   0xEA      ; eof = n bloques 256 bytes hasta CTRL+Z
BSAVE_FILE      equ   0xD0

INI_BASIC       equ   0x8001      ; lol!
INI_PRG         equ   0xF000

; --------------------------------------            
         .bios
         .basic
         .org INI_PRG
         .start MAIN            

MAIN:         di
         
         xor   a         ; limpiando la casa
         ld   hl, iniram
         ld   bc, endram-iniram-1
         call   CLSRAM   

         call   LHEADER         ; leemos una cabecera

         ret

; --------------------------------------            
; inicia o detiene el motor del cassette
MOTORON:      ld   a, 1
bmotor:         call   STMOTR     
         ret
MOTOROFF:      xor   a
         jr   bmotor

; --------------------------------------
; salimos (por error de lectura) o paramos el cassete
EXIT:         pop   hl
STOP:         call   TAPIOF     
         ret

; --------------------------------------            
; leemos datos (un byte) del cassete; C si se produce un error
READ:         exx               
         call   TAPIN     
         jr   c, EXIT
         exx               
         ret               

; --------------------------------------         
; leemos la cabecera larga del cassete; tipo = 10 bytes + nombre = 6 bytes
LHEADER:      call   TAPION
         jr   c, EXIT

         ld   b, 10            ; 10 bytes
         ld   hl, tipo_fichero
bucH:         call   READ   
         ld   [hl], a            
         djnz   bucH

         ld   b, 6            ; 6 bytes
         ld   hl, nom_fichero
bucN:         call    READ
         ld   [hl], a
         inc   hl
         djnz   bucN
            
         call    STOP
         
         ld   a, [tipo_fichero]      ; tipo de fichero

         cp   BSAVE_FILE
         jp   z, BLOAD         ; cargamos binario

         cp   SAVE_FILE
         jp   z, LOAD            ; cargamos basic SAVE
            
         cp   CSAVE_FILE
         jp   z, CLOAD         ; cargamos basic CSAVE

         ; TODO: fichero desconocido

         ; TODO: presentar informacion
         ; TODO: grabar fichero a disco

         ret

; --------------------------------------
; cload tiene una cabecera corta que leemos con TAPION y luego
; los datos hasta encontrar 7 ceros seguidos
CLOAD:         call   rstzeros
         xor   a
         ld   [INI_BASIC-1], a      ; 0 en 0x8000; requerido

         ld   hl, INI_BASIC         
         push   hl
         call   TAPION
         pop   hl
         jr   c, EXIT

bcld:         call   READ
         ld   [hl], a
         inc   hl
         cp   0
         call   nz, rstzeros
         call   z, inczeros
         ld   a, [temp1]
         cp   7            ; termina con 7 ceros   
         jr   nz, bcld

         jr   STOP

rstzeros:      xor   a
         ld   [temp1], a
         ret

inczeros:      ld   a, [temp1]
         inc   a
         ld   [temp1], a
         ret

; --------------------------------------
; load contiene multiples bloques de 256 bytes hasta 0x1a (ctrl+z)
; cada bloque tiene su cabecera corta que leemos con TAPION
LOAD:         xor   a
         ld   [INI_BASIC-1], a      ; 0 en 0x8000; requerido

         ld   hl, INI_BASIC            

bld1:         push   hl            
         call   TAPION
         pop   hl
         jp   c, EXIT

         ld   b, 0            ; carga bloques de 256 bytes         
bld2:         call   READ
         cp   0x1a            ; ctrl + z
         jp   z, STOP
         ld   [hl], a
         inc   hl
         djnz   bld2            ; fin de bloque
            
         push   hl
         call   TAPIOF
         pop   hl
         jr   bld1

; --------------------------------------
; bload tiene una cabecera corta seguida de 6 bytes con
; las direcciones de inicio, fin y ejecución del programa
; a continuación va el bloque de datos, todo seguido
BLOAD:         xor   a
         ld   hl, inifile
         ld   bc, finfile-inifile-1
         call   CLSRAM            ; borra dirs fichero
      
         call   TAPION
         jp   c, EXIT
            
         ld   b, 6            ; 6 bytes
         ld   hl, inifile
bblh:         call    READ
         ld   [hl], a
         inc   hl
         djnz   bblh
            
         call   MOTOROFF         
         call   calclng            ; calculamos longitud
         push   hl
         call   MOTORON
         pop   bc            ; longitud
         ld   hl,INI_BASIC         ; inicio (temporal)

bbld:         call   READ
         ld   [hl], a
         inc   hl
         dec   bc
         ld   a, b
         or   c
         jr   nz, bbld

         jp   STOP

calclng:      ld   ix,inifile
         ld   e, [ix+0]
         ld   d, [ix+1]         ; de = ini (real)
         ld   l, [ix+2]
         ld   h, [ix+3]         ; hl = fin (real)
         sbc   hl, de            ; longitud = fin - ini
         ret
            
; -------------------------------------
; rellenamos bc+1 bytes de ram con el valor de A
CLSRAM:         ld   [hl], a            
         ld   d, h
         ld   e, l
         inc   de
         ldir
         ret

; --------------------------------------
iniram:         defb   0

tipo_fichero:      defs   1            
nom_fichero:      defs   6

inifile:      defs   2
finfile:      defs   2
exefile:      defs   2

temp1:         defs   1

endram:         defb   0


Como comentaba en otras ocasiones hay un Documento que explica-recoge bastante bien el tipo de Cargas que nos podemos encontrar y cómo "desprotegerlas". Vienen varios ejemplos de diferentes Cargas de tipo "Turbo". Por ejemplo hay una peculiaridad con los Juegos de la Compañia "GREMLIN" ya que todos todos TODOS sus juegos siguen el mismo patrón de carga Turbo, por lo que todos sus Juegos se desprotegían de la misma manera. El Documento también recoge otro tipo de Carga Turbo (la que usaba por ejemplo "Topo Soft" en sus Juegos).

Podéis descargar dicho Documento desde aquí: ---> Curso de Desprotección de Programas


Gracias & Saludetes.

[manolito74]

Hola de nuevo:

Acabo de probar el ".Wav" del "Monty" y carga sin problemas en Open MSX (yo usé la Configuración de MSX-2, Philips 8245)

Por cierto, @jltursan, yo nunca usé el MESS y ni siquiera sabía que también podía cargar Wav. De ser así es otra herramienta útil para hacer pruebas. Estoy muy perdido con ese EMU. ¿Puedes hacer un mini Tutorial rápido para saber cómo usarlo?, ¿qué versión del MESS usas?, ¿usas algún Front-End?, ¿desde dónde los descargas?

Ya te digo que con ese EMU estoy muy pez y por lo que veo ahora MESS está incluido dentro del MAME por lo que no sé si para usar el MESS hay que usar versiones antiguas o cómo va el tema...

Gracias & Saludetes.

[BlackHole]

manolito74: Esa información que comentas ahora, ya había sido comentada en anterioridad. Pero ten en cuenta que es completamente indiferente con el formato TZX porque la estructura de los datos pertenece a una capa superior. Es como en el modelo OSI de interconexión de redes, que está compuesto por capas, pero que la gestión de cada capa es independiente de las que tenga por encima o por debajo.

Explicándolo más claro, para neófitos en la materia, el TZX vendría a ser como la capa física: tú defines que unos cuantos ciclos de una onda de determinada frecuencia forman un bit a cero, y otros cuantos ciclos de determinada frecuencia ponen un bit a uno. Que un byte necesita un cero por delante y dos unos por detrás y los 8 que realmente van a ir a memoria están dados la vuelta.

Ya está. Nada más. El problema de lo que hagas tú con esos bits y bytes cargados es cosa tuya: pertenecería a una capa superior. En este caso sería la rutina de carga de la ROM de la máquina quien interpreta una determinada secuencia como indicativo de BASIC, BASIC tokenizado o datos binarios... pero eso al TZX le da igual y sobrepasa su cometido.

Me podría servir a mí, como programador de una aplicación, para informar al usuario si se carga un tipo de datos determinado o el nombre que aparecería en una cabecera, pero eso sería una ayuda adicional y no el propósito del formato. Recordemos que la intención de todo esto es disponer de un mecanismo que defina de manera sencilla cómo se expresan físicamente (la cinta) los datos que luego van a memoria, de tal manera que solo necesitemos disponer de los datos y unos metadatos que expliquen cómo están dispuestos.

El fichero WAV peca de exceso: ahí tenemos todos los sonidos, pero no hay nada inteligible que nos ayude a manipularlo. El fichero CAS peca por defecto: solo tenemos los bytes realmente cargados en memoria y no cómo se expresan en la cinta. ¿Resultado? Que si queremos obtener el CAS hay que quitar la protección del juego original para que cargue con las rutinas de carga propias de la ROM, las cuales son a su vez parcheadas y aceleradas en los emuladores.

El TZX está a medio camino. Su objetivo es describir fielmente la cinta original. Por lo tanto hay que volver a identificar 2000 juegos como si los estuvieses desprotegiendo de nuevo, pero aparte de guardarte los datos que irían a memoria, necesitas explicar cómo estaban dispuestos en la cinta. Así no tienes que cambiar el código del juego: mantienes su integridad que es lo que se pretende conseguir.

Esta labor la tendréis que hacer vosotros. Yo puedo hacer 2 ó 3 pero no es mi lucha, es la vuestra. Tendréis que encontrar a gente que se implique y que sepa cómo volver a desproteger los juegos, para saber no solo qué se espera cargar, sino también el cómo.

Hemos visto que las protecciones de Topo Soft (Stardust) o Gremlin (Auf Wiedersehen Monty) no son otra cosa que usar la modulación del Spectrum que ya estaba definida desde el primer día en el formato TZX. Eso fue fácil. Otras no lo serán, por ejemplo el Livingstone Supongo es bien extraña y no tiene nada que ver con lo que conozco. Habría que investigarla porque podría ser incluso que no fuese "convertible".

Con eso quiero decir que el trabajo de análisis de cada juego llevará montones de horas-hombre y que aparte de ser difícil, deberá ser hecho por gente que controle estos temas. En el futuro quizás alguien haga una aplicación que consiga reconocer los patrones en un WAV y lo saque con dar a un botón... pero ese momento está lejos.

Si los impulsores que conozco (manolito74 y Pablibiris), no se acompañan de crackers de la plataforma, no creo que esto avance.

Un saludo.