La UNED va a matarme, pero ya casi ha terminado la primera tanda de exámenes. Cinco días más y volveré a estar más o menos libre.
Yo pasé una versión de Mutan Zone hace ya muchos años. Y reconozco que hice trampa. Siendo incapaz de lograr pasarla con el SAMP2CDT, opté por tirar de Wav, sacar los datos desde un WinAPE y montar el CDT a mano.
Una reconstrucción, vaya. Pero me tomé la molestia de acabar el juego para verificar que estuviera todo totalmente OK.
Por el montaje, esa versión tenía que ser por narices de pulsos dobles.
A falta de herramientas mejores, las trampas son necesarias... Yo he pasado muchísimas cintas difíciles mediante la función de "bytelog" de CPCE (abrir el depurador, ir a una dirección de memoria y escribir L <registro> para grabar en un fichero el valor del registro en un fichero; al completar el bloque, abrir de nuevo el depurador y pulsar K para detener la grabación del registro); de hecho la creé para esta clase de labores. Para calcular las constantes pertinentes examinaba el fichero CSW. Por ejemplo, "Está grabado a 44100 Hz y hay una cadena de 1000 valores que oscilan entre 12 y 16 antes del pulso corto de sincronización, luego el tono piloto está compuesto de N señales cuya media ponderada es ((sumatorio de esos 1000 valores)/1000)*(3500000/44100) T", que en los buenos casos encajaba con lo que saldría con la media aritmética, en este caso 14*35000000/44100 ~ 1111 T.
Terminarse el juego no siempre es garantía; puede colarse un error en los gráficos, un píxel o dos que cambian de color, y no nos daríamos cuenta, pero es un error y ahí está. A efectos prácticos la única forma de demostrar que un título de Opera está bien volcado es digitalizando dos cintas, codificando los ficheros y comparando los bits finales: muy inverosímil tiene que ser la mala suerte para que dos cintas distintas fallen en los mismos lugares.
Aunque asimétricos, los pulsos de las cintas de Opera son efectivamente dobles; cada bit necesita una señal alta (que no se mide) y otra baja (que sí se mide). Es un gran error de concepto por partida triple: la mitad de la señal contenida en la cinta es inútil, confiar solamente en uno de los niveles de la señal significa que la mitad de los magnetoscopios (empalmados "al revés" que los otros) perderán la señal útil y conservarán la inútil (de ahí la polaridad fija de estas cintas), y se desaprovecha el enorme factor de seguridad que proporciona el uso correcto de las señales dobles (si el DAC te da una señal durante menos tiempo, te da la opuesta más tiempo; si mides ambas garantizas valores confiables). Pero estoy repitiéndome.
Además me planteo permitirle generar bloques TZX de tipo #19
Ufff... En mi CDTMaster he implementado los tipos de bloque más usados, pero este en concreto no.
Estoy a tiempo pero...
Es como un formato dentro de otro formato. Me da una pereza hacer el código de reproducción de este bloque... (Tengo funcionalidad para generar un WAV)
¿Estás seguro de que otros emuladores lo implementan?
Aparte de tus CDT, ¿has visto otros CDT por ahí que lo usen?
Juraría que el TAPER no tiene soporte para él. Aunque el TAPER no implementaba toda la especificación del TZX.
De momento no hay emuladores que empleen los bloques #19 pero ya he metido la capacidad de interpretarlos (no de generarlos) en CSW2CDT, y he hecho algunos a mano para ver si la cosa podía ser interesante. Opino que vale la pena implementarlo para cintas como las de Opera con sus pulsos dobles desequilibrados, así como en todas las cintas de pulsos simples, hasta ahora solamente digitalizables con grabaciones directas (bloque #15) generadas proceduralmente. Un bloque grabado mediante Speedlock v1 se puede reducir a un solo bloque TZX: los bits son los mismos, pero en vez de 64 bloquecillos de PURE TONE y SEQ. OF PULSES sale solamente uno con los siguientes valores:
Tabla de símbolos de pilotos+sincros:
0: 0; 2363
1: 0; 715
2: 0; 3150
3: 0; 1130
4: 0; 565
Serie de pilotos+sincros:
0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 1, 2; 0, 226; 1, 2; 0, 222; 1, 2; 0, 220; 1, 2; 0, 218; 2, 2; 3, 6; 4, 2; 3, 2
Tabla de símbolos de datos:
0: 0; 565, 565
1: 0; 1130, 1130
(en este caso se trata del "Donkey Kong" de Ocean, que tras reescribirlo baja de 46942 bytes a 46458; la serie de pilotos es distinta en otros juegos, no siempre es el conjunto "226, 222, 220, 218" repetido ocho veces)
De todas formas se nota mucho que el "grueso" del trabajo de implementación del formato TZX se hizo hace quince años, cuando el formato alcanzó la versión 1.13; casi todos los emuladores y los útiles que interpretan y manipulan cintas TZX/CDT se escribieron entonces (mencionas el TAPER, la última vez que lo retocaron fue en 2001), y casi todos ellos no han recibido actualizaciones desde entonces (pobre CPCE, por la cuenta que me trae) a pesar del tiempo pasado y los problemas acumulados. Peor aún, una parte nada escasa de esa implementación era abiertamente defectuosa: por ejemplo, la mayoría de los intérpretes de TZX se limitan a hacer una división entera de las constantes en los bloques TZX y la frecuencia de interpretación, lo que conduce a desajustes nada despreciables entre lo que debía sonar y lo que sonaba. Y aún peor, herramientas como SAMP2CDT (sin retocar desde 2003) han hecho trampa y han estado forzando valores arbitrarios (los que el autor asumió que eran correctos, a saber de dónde los sacó) que han generado cintas que luego no se han podido utilizar. Al final, entre los volcados malos y las cintas aparentemente imposibles de volcar que siguieron apareciendo, decidí que había que empezar desde cero.
Lo más reciente en CSW2CDT es la implementación de una protección utilizada por Gremlin Graphics, que conoció tres versiones distintas. Una de ellas era un bloque turbo típico, pero merced a un error de concepto comparable al de Opera necesitaba una polaridad fija: el tono piloto debe tener una duración PAR. Así mide la duración de un bit el cargador de "Footballer of the Year 2":
Código: Seleccionar todo
...
ld c,0 ; contador a cero
inc c ; incrementa contador
in a,(0)
jp m,$-3 ; la primera mitad de la señal debe ser ALTA
...
inc c ; incrementa contador
in a,(c)
jp p,$-3 ; la segunda mitad de la señal debe ser BAJA
ld a,c
ret
Las otras dos versiones dividen el flujo de bits en minibloques (típicamente de 16 bytes) e insertan series de pulsos intermedios para hacer pausas y así mostrar un contador en pantalla mientras la cinta carga ("Mask"); el contador está deshabilitado en varios títulos pero el resto del código permanece intacto y sigue esperando encontrar pulsos intermedios ("Impossamole"); y de todas formas el error de concepto permanece, aunque de una forma diferente, que entre otras cosas exige un tono piloto de duración IMPAR. Así miden ambas versiones la duración de los bits:
Código: Seleccionar todo
...
ld c,0 ; contador a cero
in a,(c)
jp m,$-2 ; la primera mitad de la señal debe ser ALTA pero no se mide
in a,(c)
jp m,$-7
in a,(c)
jp m,$-12
in a,(c)
jp m,$-17 ; debe aguantar al menos 28 microsegundos
...
inc c ; incrementa contador
in a,(c)
jp p,$-3 ; la segunda mitad de la señal sí se mide y debe ser BAJA
in a,(c)
jp p,$-8
in a,(c)
jp p,$-13
in a,(c)
jp p,$-18 ; debe aguantar al menos 28 microsegundos
ld a,c
ret
Agradezco que Gremlin incluyese la rutina de grabación de la primera versión (sin pausas intermedias) en "Footballer of the Year 2": me ayudó a entender lo que estaba ocurriendo de una forma comparable al caso de Opera Soft, que también incluyó las rutinas para grabar casi todos sus juegos.
En fin, a seguir estudiando. Me examino de Complejidad+Computabilidad pasado mañana a las once y media.
.
Si ese Livingstone es el 1, sería el único de esos juegos con el método de grabación antiguo, el que no tenía CRC (o mejor dicho checksum); todos los demás son posteriores a 1988 (asumo que el "Hércules" es el "Ulises") y lo incluyen, lo que ahorraba algunas sorpresas desagradables.
