Las unidades de cinta o de casete se basaban en el uso de cintas de audio convencionales para almacenar programas en ellos. En consolas, no se utilizó jamás y, desde el primer momento hasta la llegada del CD, la ROM fue el estándar de facto, independientemente de si hablamos de cartucho tradicional o tarjeta. En ordenadores fue típica de los ordenadores de 8 bits, ya que los de 16 bits adoptaron los discos magnéticos o más conocidos como disquetes. Sin embargo, una generación entera consumió sus juegos en cintas. Por lo que vamos a hacerle un pequeño homenaje a este formato de almacenamiento.
El casete, un formato que no nació para almacenar datos
Hoy en dia la transferencia de información entre dos ordenadores no es problema, ya sea a través de internet, una red local o a través de dispositivos de almacenamiento portátiles, es posible el intercambio y la reproducción masiva de programas a gran escala, la realidad a mediados de los años 70 era muy distinta. Para empezar, no existía una industria del software que pudiese almacenar y distribuir sus programas a gran escala, por el hecho de que no existía un formato de almacenamiento para ello.
En 1975, la revista Byte reunió a varias figuras destacadas de lo que terminaría siendo el mundo de la informática doméstica. La idea era crear un estándar de almacenamiento común para poder usar las cintas de audio convencionales para almacenar datos. Claro está que no podemos olvidar que, al contrario que otros formatos, las cintas de casete no se idearon originalmente para ser un formato de almacenamiento digital sino analógico, por lo que se acordó una forma de codificar la información en las dichas cintas para que los sistemas informáticos la pudieran interpretar.
Para almacenar la información en el caseta se usaban señales de audio moduladas, codificadas en forma de una onda seno a una frecuencia determinada. Para leer la información, el ordenador, simplemente, a través de un conversor analógico a digital, leía las ondas sonoras y las interpretaba como 0 y 1. En cambio, si quería grabar la información, el proceso era como un conversor analógico a digital que convertir los bits de digital a las señales de audio correspondientes para una posterior recuperación.
Barato y popular
Debido al bajo coste de las cintas de casete, el formato fue rápidamente aceptado como el estándar para almacenar y distribuir programas, reemplazando sistemas mucho más caros e incómodos que se usaban en el mundo de la informática. No obstante, el primer estándar que se creó, el llamado Kansas City System o KCS, en honor a la ciudad donde se hizo la primera reunión, nació un año antes de la aparición de los primeros ordenadores domésticos.
El concepto era sencillo, se pactó en que la codificación en binario sería la siguiente:
- 4 pulsos de una onda seno de 1200 Hz = lectura a 300 baudios (bits por segundo).
- 8 pulsos de una onda seno de 2400 Hz = escritura a 300 baudios (bits por segundo).
No obstante, pronto se descubrió que el formato era demasiado lento y se tardaba mucho tiempo en volcar los datos desde la cinta a la memoria RAM del sistema, por lo que se optó por una mejora sobre el KCS a la que llamaron CUTS, siglas de Compatible UART Tape System. El cual estaba pensado para adaptarse mejor en su funcionamiento a las interfaces UART utilizadas para comunicar entre sí periféricos con ordenadores. En dicho caso, se pactó reducir los pulsos de onda seno a 1 a 1200 Hz para la lectura y a 2 a 2400 Hz para la escritura, aumentando la capacidad a 1200 baudios (bits por segundo).
Sin embargo, no se pusieron de acuerdo
El puerto para periféricos externos más utilizado en los primeros ordenadores era el RS-232, el cual era un bus de datos en serie, por lo que enviaba un bit por ciclo de reloj. Su velocidad de transferencia podía llegar a una velocidad de hasta 9600 bits por segundo. Si bien muchos ordenadores tenían un minijack (hasta 20000 bps) para conectar una unidad de cinta convencional, otros, en cambio, conectaban unidades de reproducción de cinta a través de un puerto propietario o una variación del RS-232. Fuera cuál fuera la interfaz de transferencia de datos, no era un cuello de botella por aquel entonces para transmitir la información.
La cosa se complica cuando tenemos en cuenta que hay una disparidad enorme de un sistema a otro. Por ejemplo, todos los programas para un sistema en concreto usaban una cabecera de datos concreta. La cual es una secuencia de datos que precedía al programa principal y que cambiaba de un sistema a otro. Si esta no era la correcta, entonces el ordenador no cargaba los datos en memoria y paraba el programa. No solo eso, sino que la forma en la que estaban codificados los datos y la capacidad de almacenamiento cambiaban de un sistema a otro.
Métodos de codificación
No obstante, cada sistema utilizaba un método de codificación de los datos distinto para sus casetes de datos, es importante conocerlas para saber más o menos la capacidad de almacenamiento real de las cintas de casete en los diferentes sistemas de 8 bits. Los más comunes eran:
- GCR: codifica bloques de 4 bits de datos en 5 bits añadiendo un bit de paridad para la corrección de errores.
- Manchester: no depende de una frecuencia de reloj concreta, sino que mide las variaciones de frecuencia entre dos ondas. Esto hace que su velocidad de transferencia sea la mitad que la frecuencia de la onda. Se usó en sistemas de muy bajo coste donde no se proveía una señal de reloj separada para la unidad de cinta.
- NRZ (Non Return to Zero): el más simple de todos, pero requiere de hardware externo para sincronizarse. No obstante, es el más eficiente en cuanto a volumen de datos, ya que cada bit transmitido es un bit de datos.
- Ohio: 11 bits, 1 bit de inicio, 8 bits de datos y 2 bits de parada.
Aunque parezca una banalidad, precisamente por esto las versiones de disco magnético y cinta usaban binarios totalmente distintos, por no hablar de las versiones de cartucho de algunos juegos. En todo caso, no deja de ser una curiosidad, pero que viene por el hecho de que el casete no era un método pensado originalmente para el almacenamiento de datos en binario. De ahí a tener que usar estos métodos de codificación de datos, que en otros formatos no eran necesarios.
Capacidad de almacenamiento
En la siguiente tabla os dejamos la capacidad bruta de transferencia en audios o bits por segundo de los diferentes sistemas, así como el método de codificación usado en cada una.
| Sistema | Baudios (bits por segundo) | Codificación | Baudios reales | Capacidad (cinta 30 mins) |
|---|---|---|---|---|
| Amstrad CPC | 1000/2000 | Manchester | 500/1000 | 54.93 +59-93 KB |
| Apple II | 1500 | GCR | 1200 | 131.84 +131.84 KB |
| Atari 400/800 | 600 | NRZ | 600 | 65.92 + 65.92 KB |
| Commodore 64 | 300 | NRZ | 300 | 33.75 +33.75 KB |
| IBM PC (5150) | 1500 | NRZ | 1500 | 164 + 164 KB |
| MSX | 1200 | Manchester | 600 | 65.92 + 65.92 KB |
| ZX Spectrum | 1500 | Manchester | 750 | 82.40 + 82.40 KB |
| Altair 8800 | 300 | KCS | 218.18 | 23.97 + 23. 97 KB |
Tal y como se puede ver las cintas superan de mucho en capacidad el máximo de memoria RAM soportada por las CPU de los sistemas de 8 bits, quizá la excepción aquí es el IBM PC, ya que el 8088/8086 puede direccionar hasta 1 MB de datos, pero para la gran mayoría de sistemas incluso la codificación KCS a 300 baudios es suficiente. Claro está que esto implica que el uso de velocidades de codificación más altas es para reducir realmente los tediosos tiempos de carga, puesto que el programa no puede operar desde la unidad de cinta.
Había juegos que eran lo suficientemente complejos como para venir en 2 mitades o varias partes y, cuando se llegaba a cierto punto de la partida, se tenía que dar la vuelta a la cinta o se cargaba desde una sección concreta, medida manualmente desde un contador externo. Esto hacía que se tuviese que volcar de nuevo los datos desde la cinta a la RAM del sistema para poder continuar la partida. Sin embargo, el 99 % de los juegos no procuraban ocupar más que la RAM disponible de serie en el sistema, ya que en este caso era necesario volcar el programa a la RAM.
Las desventajas del casete como formato de datos
El primero y más claro de ellos es que es imposible acceder a un determinado punto de la cinta sin recorrerla de nuevo del todo, todo al contrario de las unidades de disco donde solo es necesario mover el cabezal al sector deseado, o las ROMS donde solo es necesaria acceder a una dirección de memoria. Esto hace que sea necesario volcar todo el programa en la memoria RAM, lo que conlleva los clásicos y eternos tiempos de carga. En conclusión, que si bien el casete era un sistema barato para almacenar y distribuir programas, en realidad dependía de que los sistemas tuviesen una gran cantidad de memoria RAM disponible, lo que lo hizo inviable para consolas de videojuegos.
A esto hay que sumarle el deterioro físico de la cinta, el polvo y los daños mecánicos que podían provocar errores de lectura y las interferencias de todo formato analógico que podían llevar a errores. No eran pocas las veces en que una cinta en mal estado o una unidad de casete defectuosa impedían cargar los programas bien. Todo ello se convertía en una enorme frustración que hizo que, tan pronto como fue posible, el formato de cinta dejó de usarse, en pro de otros mucho mejores a la hora de manejar datos en un ordenador como lo son los disquetes.