EL SITIO DEL CDT - Como funcionan las cintas en el Amstrad.

En la época del Amstrad, la tecnología de discos flexibles aún era cara. Por esa razón (cuestión de precios), los primeros modelos de CPC (464) usaron una clásica cinta de audio para almacenar la información.

Las cintas de audio no fueron diseñadas para ello. Sin embargo, resultaba muy sencillo de construir un chip que pudiera generar una señal electrica que fuera almacenable como audio.
Eso hace que haya bastantes limitaciones.
Más adelante contaré los problemas derivados de esto, aunque de momento me voy a concentrar en como funcionaba de manera más somera.

El sonido es una vibración. Para poner un símil, es como una ola en el agua. Piensa en una piscina. Las olas no dependen de la cantidad de agua que contiene la piscina, sino de las oscilaciones que hay en esta.
El sonido es similar, solo que en vez de ondas de subida y bajada tan visuales que se forman en el agua, se tratan de oscilaciones en el aire, hacia adelante y hacia atrás de la propagación del sonido.
Sin embargo, pensar en las oscilaciones del agua te ayudará a "ver" mejor de lo que estamos hablando.
Ahora, nosotros lo que queremos es transmitir datos (digitales, 0s y 1s) usando dichas vibraciones.
Las vibraciones tienen ciertas particularidades. Veámoslas. 1- Son ondas sinusoidales (como semicírculos para arriba y para abajo)

2- La onda tarda cierto tiempo en dar una "vuelta" (para arriba y para abajo antes de repetirse, conocido como "periodo"). Normalmente de lo que se habla es de cuantos periodos por segundo contiene una onda concreta. (o sea 1/tiempo de una vuelta). A esto es lo que se le denomina, freciencia de una onda. En sonido, la frecuencia es lo que determina cuanto de agudo o grave es dicho sonido. A mayor frecuencia, más agudo es el sonido. (Recuerda que mayor frecuencia es que la onda es más corta, o sea más rápida. Frecuencia=1/tiempo). Por eso, las cargas más rápidas del Amstrad tenían pitidos más agudos
3- La onda puede subir o bajar más o menos. La altura de la onda determina el volumen de esta. A este concepto se le denomina amplitud.
4- Las ondas al propagarse simultáneamente, se suman, aunque cada una conserva su propiedades (dirección, amplitud y frecuencia).
5- Cada medio de propagación provoca ciertos efectos a la onda de sonido. A veces puede acelerar o decelerar las ondas (y por tanto modificar sus frecuencias). A veces lo hacen según las frecuencias de estas. Las amortiguan (reducen la amplitud de la onda) más o menos a través de su propagación y según la frecuencia de estas...etc, etc.
De hecho, los medios que utilizamos permiten almacenar tan solo ondas de ciertas frecuencias máximas.
Ver (http://www.monografias.com/trabajos7/grabmac/grabmac.shtml)
De ahí que de la onda que aparentemente generemos a la hora de grabar y la que recuperemos en la lectura puede sufrir considerables modificaciones.

Bien... Sabido esto nos topamos con como vamos a almacenar nuestra información digital en el medio analógico...
Podríamos pensar en lo siguiente...



    *****            |
                     |
-------------------- | Onda de sonido
                     |
****     *********** |

11110000011111111111 - Bits

¿ Facil verdad ? PUES NO. NO VALE Eso no es una onda sinusoidal. Fíjate que pasa si son todo 0s
******************** |
                     |
-------------------- |
                     |
		     |

Eso se podría considerar una onda de una frecuencia bajíiiiisima. Una frecuencia tan baja que no hay medio que lo propague.

Tenemos por tanto que limitar las frecuencias que vamos a usar para codificar la información.

Bién. Entonces optemos por dar una frecuencia al 0 y otra al 1.
Entonces necesitamos una "vuelta" para cada bit.
  **             ****
 *  *          **    **
*    *        *        *
------*------*----------*----------*
|      *    *|           *        *|
|       *  * |            **    ** |
|	 **  |              ****   |
|            |                     |
++++++++++++++++++++++++++++++++++++
    Bit 0             Bit 1

Ahora si :-). Con este modo de enviar la información usamos X frecuencias concretas por lo que el medio lo admite perfectamente siempre y cuando sean frecuencias adecuadas para el canal.

Regresemos al CPC. El CPC disponía de una circuitería de I/O a la cinta, pero este lo enviaba como un flujo eléctrico capaz de oscilar tan solo entre dos posibles valores. O's y 1's.
Cuando esto se traduce a sonido hay que tener en cuenta que la resultante tan solo va a ser una función que solo puede ser resultado de la suma de ondas del tipo anterior. Nos vemos, por tanto, limitados por el canal a un conjunto de ondas de unas frecuencias determinadas. Por tanto, debemos dedicarnos a conmutar entre 0s y 1s a frecuencias adecuadas para el canal usado. Normalmente se usaban frecuencias entre 400 y 6000 ciclos (periodos) por segundo también conocido como Hertzios.

Por tanto en escritura el resultado era:
 0       1       0     1    0    - Estado del chip 

+++++----------++++++-----++++++ - Duración del estado

*****|        |******|   |******
     |        |      |   |
-------------------------------  - Onda eléctrica generada
     |        |      |   |
     **********      *****
     
 *****              *          *
*     *            * **       * **
-------*----------*----*-----*----*  - Onda de audio final (aprox.)
        *      ***      *   *
	 ******          ***
Como puede observarse, la onda cuadrada original queda deformada. Esto es debido a que para crear dicha onda cuadrada se requieren la suma de infinitas ondas sinusoidales de frecuencias que van desde la frecuencia principal hasta el infinito. (En su momento proporcionaré el enlace a una explicación para esto).
El canal, al destruir las frecuencias altas, la onda se deforma quedando "ondulada" pero la frecuencia principal (la de los cambios entre 0s y 1s) se respeta (aunque queda añadida una latencia a la escritura pero esto es de poca importancia ya que la información como tal está contenida en las frecuencias.

Veamos ahora el proceso inverso.


 *****              *          *
*     *            * **       * **
-------*----------*----*-----*----*  - Onda de audio 
        *      ***      *   *
	 ******          ***

++++++++----------++++++-----++++++  - Valores devueltos por el chip
   0         1      0     1    0
   
En este caso, el chip informa de un 0 cuando la componente de audio es positiva(la gráfica está por encima del punto medio), y 1 cuando es negativa. Como se puede ver, los tiempos de 0s y 1s se han mantenido (exceptuando el comienzo que quedaba antes fuera de la gráfica).

Debo recordar que estos 0s y 1s no son la información que vamos a grabar. Tan solo son información del chip del audio. Como decía antes, si usasemos antes esto para guardar directamente los 0s y 1s proporcionaríamos sonidos con frecuencias muy diferentes y las frecuencias que cayesen fuera del rango admitible por el canal este sufriría deformaciones y los valores no cuadrarían. De hecho, este es un caso "perfecto". En la realidad, el canal sufre además de ruido y otras imperfecciones. Pero si nosotros usamos frecuencias suficientemente separadas dispondremos de suficiente margen como para que una distorsión no fuera suficiente para cambiar nuestra valoración de las frecuencias que consideramos 0s y las que consideramos 1s.
Por tanto, para recuperar los bits de información lo que se hace es contar cuanto tiempo se tarda en conmutar entre 0 y 1 del chip de audio, que es en realidad el periodo de la onda original ( y 1/tiempo -> frecuencia ). Y según dicho periodo/frecuencia, se determina si es un 0 o un 1.

Esto es de lo que disponemos en un CPC, y usando ensamblador podemos aprovechar la cinta por completo. Ahora bien, el Amstrad proporcionaba ciertas rutinas en ROM que, aprovechando estas capacidades, las usaba de un modo concreto.
La mayoría de juegos optaron por proporcionar cargadores alternativos para poder crear efectos como barras de color durante la carga, aunque la mayoría aporta poco en cuanto a la codificación de 0s y 1s.

Las rutinas del firmware permiten trabajar con archivos, pero también como subbloques directos. Los archivos estaban construidos de estos subbloques.
Estas son las propiedades del subbloque:
  1. La rutina permite que se pueda usar diferentes frecuencias base. Por tanto la misma rutina nos permite por igual usar velocidades más lentas (tonos graves) o más rápidas (tonos agudos). Basic permitía cambiar la velocidad de escritura entre 1000 Baudios (=Hertzios) y 2000 Baudios.
    Desde ensamblador y llamando al firmware (&BC68) podían establecerse otras velocidades. La lectura era automática.
  2. Los bits 0s se representan con una frecuencia doble respecto de los 1.
  3. Antes del comienzo del bloque hay un gran conjunto de 1s. Eso sirve para que la rutina prevea que comienza un bloque con frecuencia X para los 1s, y 2X para los 0s. A esta zona se le denomina "PILOT".
  4. Después de la zona "PILOT" hay un bit 0 que indica la finalización de dicha zona. A este bit se le denomina bit de sincronización.
  5. Después del bit de sincronización, existe un byte (8 bits) de tipo de subbloque. La rutina firware cargaba solo un bloque cuyo byte de tipo coincidiese con uno concreto especificado. (Algunos lo llaman byte de sincronización aunque puede confundirse con el bit de sincronización)
  6. Después del byte de tipo, estaban los datos almacenados, de manera secuencial e incremental. Cada 256 bytes, se agregaban 2 bytes con un cálculo (CRC-16) para verificar la correción de los datos cargados anteriormente.

Estas rutinas son accesibles a través de las llamadas a las direcciones &BCA1 (lectura) y &BC9E (escritura).

Pero, normalmente, se utilizaban las rutinas de archivos.
  1. Los archivos hacían uso de los subbloques de tipo anterior.
  2. Los datos salvados se dividían en zonas que almacenaban un máximo de 2048 bytes de datos.(* La rutina de lectura admite bloques mayores, pero la rutina de escritura respeta esto. Es factible usar rutinas de uso directo de subbloques para crear cintas sin esa limitación )
  3. Cada zona comenzaba por un subbloque con byte de tipo &2C. Este subbloque contiene 256 bytes de datos donde se almacena el nombre del archivo, tipo de archivo, número de bloque, si es el primero (y por tanto puede cargarse inicialmente independientemente del número del bloque), si es el último (y entonces finaliza la carga), posición original de carga de los datos, tamaño total del archivo, tamaño de la zona, posición de comienzo de ejecución para binarios, etc. etc.
  4. Después del subbloque anterior, hay otro de tipo &16 que contiene los datos correspondientes de la zona.
  5. Lo que hemos llamado "zonas" el Amstrad lo llama "Bloque".
    Loading KSJDJ Block 1
  6. Cada zona está precedida por un silencio.
  7. Durante la carga, si el subbloque se cortaba por ser más corto de lo esperado, mostraba el error como "Read Error a". En caso de que se detectase corrupción en los datos gracias al CRC se mostraba un error como "Read Error b".


Luego, la mayoría de los programas optaron por usar sus propios métodos de carga para poder mostrar colores durante esta así como evitar el sistema de bloques (zonas) de los archivos tradicionales. Al ser más rápidos se les solía conocer como "cargas turbo"
Algunos carecían de algunas de las propiedades del sistema original proporcionado por el firmware como puede ser diferentes frecuencias (la mayoría de los sistemas de cargas "turbo" tenían prefijadas las frecuencias de 0s y 1s) o detección de errores.
Otros proporcionaban nuevas características no disponibles en el sistema del firmware como carga de "trozos" de datos de manera continua (servían, entre otras cosas, para cargas de pantallas de arriba a abajo), contadores, e incluso juegos.

Enlaces de Interés:
http://andercheran.aiind.upv.es/~amstrad/docs/manual/s968se08.pdf
http://andercheran.aiind.upv.es/~amstrad/docs/sound.html