Buenas tardes a todos,
A raíz de un reciente mensaje privado de manolito74, he vuelto a revisar un poco este tema olvidado.
Siento no haber sido más activo, pero estos últimos 18 meses he tenido muchos compromisos médicos.
En un principio creí, en mi ingenuidad, que el formato TZX era capaz de poder definir de forma lógica todos los formatos habidos y por haber que yo conocía, pues se podían crear ficheros de Spectrum, Amstrad, Commodore 64, ZX81, Apple II, Oric, Lynx y muchos otros. Sin embargo desconocía el MSX y la forma enrevesada de codificación que incorpora de serie.
TZX está diseñado originalmente para equipos que tienen una onda perfectamente definida para un bit a cero y otra onda perfectamente definida para un bit a uno. Hasta aquí también es el caso del MSX, pero la particularidad de este sistema es que para cada byte de 8 bits, se añaden un bit a cero de inicio por delante y dos bits a uno de parada por detrás, forzando a que
cada byte venga definido por 11 bits, es decir, por 22 pulsos (o semiondas). Aparte, se almacena en formato LSB (Least Significant Bit) con los bits dados la vuelta respecto a otros ordenadores.
En Commodore 64 también existen bits de inicio y parada que acompañan a algunas de las codificaciones, de ahí que en la especificación v1.14 del formato TZX hubiese dos tipos de bloques especialmente diseñados para ese ordenador. En un principio pensé que podría aprovecharlo, pero más tarde he visto que solo permiten definir bits de inicio o parada para cada byte,
pero no ambos simultáneamente.
Para enrevesar más las cosas, en la escena de Commodore 64 nunca se animaron a adoptar el formato TZX por la antigua rivalidad de ambos sistemas y considerar inferior todo lo proveniente de Spectrum, siguieron manteniendo sus TAP que recopilan los pulsos en bruto (RAW) con cierta compresión RLE, al estilo del formato CSW v1.0 de Spectrum (CSW v2.0 utiliza Zlib para comprimir). Por ello en la especificación v1.20 del formato TZX, oficialmente se declararon obsoletos los bloques diseñados para Commodore 64.
El formato TZX v1.20 introdujo un nuevo tipo de bloque generalista que permitía definir codificaciones extrañas de bits, bien con ondas asimétricas, con grupos largos de varias ondas (como el ZX81), o para los casos que una onda de determinada longitud codifica 2 bits a la vez. Esto es posible gracias a que ese nuevo bloque incluye un diccionario para definir los patrones de bits. Sin embargo, el problema con MSX subsiste, pues los bits están bien definidos, pero no así los bytes en su conjunto.
Si hemos de usar TZX v1.20, una solución podría ser la inclusión de un diccionario de 22 pulsos para cada una de las 256 combinaciones posibles de un byte. Eso provocaría que para cada bloque en formato MSX nativo, se incluyesen 22 x 256 = 5632 entradas de diccionario, con lo que tendríamos exactamente 11 KB de metadatos extra aunque solo necesitásemos cargar una cabecera de 16 bytes. Sería una burrada, pero radicalmente inferior al espacio consumido por un WAV.
Ante mi desconocimiento del otro formato PZX v1.0 de 2007 propuesto al principio del hilo, he echado un vistazo a las especificaciones y he visto que igualmente está muy orientado a Spectrum. Incluye la posibilidad de múltiples ondas para definir un bit cero o uno, pero al igual que TZX, solo plantea bytes de 8 bits. El poder incluir flujos indefinidos de pulsos no arregla la situación; para eso ya existía el formato CSW que impide la asociación rápida de un flujo de bits a los datos que realmente serían cargados después en memoria y editables en un programa como Tapir o
ZX-Blockeditor.
La solución por ahora, que permite usar editores y reproductores de TZX bien asentados (en PCs o móviles) parte por la inclusión de un diccionario extendido de 11 KB para cada bloque de carga, o modificar el formato TZX a nuestro libre albedrío fuera de las especificaciones oficiales, lo que obligaría a crear software completamente nuevo que lo soportase.
Voy a hacer pruebas estos días y os subo algún ejemplo lo antes posible.
