¿BIOS? ¿Firmware? ¿Sistema operativo?

¿Qué significa que una videoconsola use Linux?

Por David Senabre Albujer. Septiembre de 2009.

http://www.consolasparasiempre.net/


Cada vez más en ámbitos profanos se escuchan los términos BIOS, firmware, y sistema operativo. Sin embargo, la falta de conocimiento lleva a malinterpretar estos conceptos, y a no entender su función. Por otra parte, Linux es un sistema operativo que sigue ganando popularidad, y que empieza a oírse cada vez más en el mundo de las videoconsolas. Pero mucha gente no sabe lo que esto significa. En este artículo intentaré explicar los conceptos e implicaciones, sin que el lector requiera conocimientos previos.


¿Ordenadores en los hogares?


Hace ya unas décadas, manejar un ordenador requería bastantes conocimientos. Su uso estaba casi restringido al mundo profesional, y el de la investigación. A mediados de los 70, y gracias a la aparición de los microprocesadores, empezaron a aparecer ordenadores asequibles al público general. Y aún así, los aficionados, tras desembolsar una suma nada despreciable de dinero, debían estudiar y conocer cómo funcionaba su equipo, tener una cierta destreza, y un gran interés. Aunque el dinero no fuera problema, las posibilidades que ofrecía la informática eran muy limitadas, y sin unos conocimientos, los ordenadores no dejaban de ser armatostes de poca o ninguna utilidad. Así pues, seguían estando al alcance de algunos pocos privilegiados.



Por poner un ejemplo, el TRS-80 (arriba), cuyo primer modelo salió al mercado en 1976, costaba no menos de 700 dólares de entonces, y como se puede ver, era bastante pequeño. No tenía ni disquetera, ni, por supuesto, disco duro. Únicamente un cassette, cuya velocidad de carga era más de 100 veces inferior a la de un módem. En otras palabras, para leer del cassette un texto corto de sólo 40 caractéres, sin formato (es decir, como se obtendría con una máquina de escribir, sin florituras), era necesario más de un segundo. Como anécdota, este párrafo tiene más de 700 caractéres, y si estuviera grabado en una cinta, habría que esperar cerca de 20 segundos para poder leerlo en la pantalla del ordenador.


El TRS-80 venía con una memoria RAM de 4 Kbytes. Si se quería, podía ampliarse a 16 Kbytes, por unos 300 dólares. Y con un una expansión, de otros 300 dólares, se añadían conexiones para usar disqueteras, impresoras, e incluso poder saber la hora. Pero eso no es todo. La disquetera no estaba incluída en el precio de la expansión, y por aquel entonces eran muy caras; casi tanto como el propio ordenador. Y no eran diskettes como los que se usaban hasta hace poco. Abajo se puede ver el tamaño de éstos, comparado con los enormes discos de 8 pulgadas que usaba el TRS-80. Y, sí, lo has adivinado, la impresoras tampoco estaba incluída. Parece que la factura podría sobrepasar fácilmente los 2000 dólares, que a finales de los 70, debía ser una pasta considerable.




¡Que bien! ¡Ordenador nuevo! ¿Qué se podía hacer con un ordenador como este?

Para un profano que sólo conozca Windows, se puede decir que prácticamente nada. La pantalla era en blanco y negro, y sólo podía mostrar texto o formas simples. No tenía ratón, ni ventanas. Para hacer cualquier cosa mínimamente útil, había que saber programar. Y al apagar el ordenador, se perdía todo lo que no se hubiera grabado en cinta. Aunque, como sucedería con el Spectrum años más tarde, hay quién lo usaba para jugar a videojuegos, grabados en cinta.


Por tanto, para los jugones, era un artículo de lujo muy valioso. Y para los informáticos, una máquina excelente para aprender a programar, y a comprender el funcionamiento de un ordenador.



Aquí se puede apreciar la evolución del aspecto gráfico de los juegos, desde la época del TRS-80, hasta la aparición de la primera videoconsola de gran éxtio de Nintendo, una década más tarde.


¿Y que pasa hoy?


Hoy, pocos años después, todo esto ha cambiado. Casi cualquiera puede aprender a usar un ordenador, sin haber estudiado una carrera, ni saber cómo funciona por dentro, o cómo está hecho. No es preciso saber programar, ni soldar. Ni ser un friki de la informática. Sin embargo, los sistemas actuales son muchísimo más complejos que antes, y aún así, están más al alcance de todos que nunca ¿Por qué?


Esto ha sido posible en parte a la evolución del software y los sistemas operativos, como el famoso Windows en los ordenadores PC, o el MacOS en los Machintosh. Gracias a esto, todo es mucho más intuitivo. Una sencilla pantalla de texto, de difícil manejo, ha pasado a convertirse en un entorno fácil, donde con pocos clicks de ratón se puede navegar por Internet, retocar fotografías, comunicarnos con alguien a miles de kilómetros de distancia, o escuchar nuestra música favorita.



Creo que hasta los menos entendidos podrán apreciar la evolución, ¿no?



¿Por qué motivo se querría usar un sistema operativo en algo que no sea un ordenador?


A día de hoy existen bastantes dispositivos electrónicos que funcionan con Linux. Lo curioso es que un usuario normal no va a percatarse de ello en ningún momento. Teléfonos, cámaras, sistemas de vigilancia y control de acceso, receptores de TV digital, robots, routers, discos duros y reproductores multimedia portátiles, así como otros tantos representantes del ocio digital, poco o nada nos recuerdan al aspecto de nuestro ordenador personal.




¿Qué motivos pueden haber para integrar un sistema operativo en aparatos como estos?

La inmensa mayoría de usuarios de ordenadores PC usa Windows como sistema operativo, debido a diversos motivos:


Pero Windows no es el único sistema operativo, ni muchísimo menos. Dentro de los ordenadores domésticos, destacan Linux y MacOS. La ventaja de Linux es que la mayoría de sus distribuciones son completamente gratuitas. Suelen ser desarrolladas por grupos de programadores repartidos por todo el mundo, y la cooperación de muchas personas. Es libre, y cualquiera tiene la libertad de modificar y distribuir tanto Linux, como gran parte de su software, “como si de una receta de cocina se tratara”, en palabras del propio Richard Stallman, fundador del movimiento de software libre.


A la izquierda Windows XP. A la derecha, una de las muchas distribuciones de Linux.


Precisamente por ser libre, existen muchas versiones de Linux, a las que se llama distribuciones. Las más famosas a fecha de hoy, son Ubuntu, OpenSUSE, Debian, Fedora y Mandriva. Aunque merecen mención Red Hat y SUSE, que actualmente son de pago.


La tendencia actual es hacer que cualquier aparato se parezca cada vez más a un ordenador. Quizá uno de los ejemplos más obvios lo constituyen los teléfonos móviles. Al principio servían para hacer y recibir llamadas y SMS. Podían incorporar funciones simples, agenda telefónica, alarma o calendario, pero poco más. Ahora, año 2009, para mucha gente, un móvil sin cámara digital no es un móvil. Y quien dice cámara dice bluetooth, navegador web, o reproductor multimedia. Y la misma metamorfosis sufrieron las ya arcanas agendas de bolsillo. Sí, aquellas que funcionaban con pilas de botón, con una pantalla poco mejor que una calculadora. Hoy se han convertido en complejas PDAs, casi tan potentes como algunos ordenadores portátiles. Y son muy buenos ejemplos, ya que es fácil para cualquier usuario comprobar que usan sistemas operativos (desde la aparición misma de la Palm Pilot 1000, quizá la primera PDA de éxito, en 1996. Su manejo y apariencia era, en esencia, muy similar al de un ordenador con, por ejemplo, Windows 95, el sistema operativo más usado en los hogares por aquel entonces).

Las primeras PDAs ya eran mini-ordenadores, pero con poca memoria, y escasa potencia, comparados con los PC, y por eso no podían usar directamente un sistema operativo convencional. Por ello, Palm creó su propio sistema, el “PalmOS”, diseñado para sus dispositivos. Y unos años más tarde, Microsoft entró en juego con sus PocketPC, que usaba un sistema operativo “Windows CE”.



Izquierda, primeras versiones de PalmOS.

Centro, Windows CE de un PocketPC 2002, lanzado varios años más tarde.

Derecha, Palm OS 5.0, que competía en el mercado con el anterior.


Teléfonos móviles y PDAs han mejorado tanto y tan rápido, que empiezan a confundirse entre sí.

Y para seguir aprovechando sus nuevas capacidades, han seguido apareciendo nuevas versiones de sistemas operativos. Windows Mobile (de Microsoft), WebOS (de Palm), Symbian (creado por una alianza de empresas de telefonía móvil) y Android (de Google), son quizá los cuatro sistemas más importantes en el sector.


Windows Mobile, WebOS, Android y Symbian


¿Y qué hay de las videoconsolas? ¿Por qué Linux?

Empecemos por una de las veteranas, la Atari 2600.


Dejemos de lado móviles y PDA. Las videoconsolas, igualmente, pueden ser consideradas sin temor alguno, como ordenadores. Y así ha sido desde sus orígenes.


La Atari 2600 usaba un microprocesador de 8 bits basada en el MOS 65C02, muy popular en los ordenadores para hogares de aquel momento. La CPU de la máquina de Atari era una versión limitada del 65C02 original; sólo podía manejar una tercera parte de memoria, y carecía de líneas de interrupción (por las que recibir peticiones externas de atención por parte de otros componentes). Pero ¿usaba sistema operativo? Rotundamente, no. La escasa potencia de la consola se lo impedía. Y no era una cuestión de procesador. Éste funcionaba a 1,19 Mhz. El ordenador TRS-80 del que hablé al principio, sí era capaz, y usaba un Z80 a 1,77 Mhz, y eran equivalentes por término medio. Ojo, que una CPU no es necesariamente mejor por funcionar a más mega hercios. Una buena analogía se puede hacer entre los hercios (para una CPU) y los pasos (para un animal). No es lo mismo el paso de un cachorro, que la zancada de un gran carnívoro, ¿verdad?



¿Más “Mhz” = Más velocidad? No.

El rastro superior se compone de 10 pisadas (10 Mhz).

El rastro inferior, de 3 pisadas (3 Mhz ).

Sin embargo, ambos dinosaurios, que dejaron sus huellas en la provincia de Soria hace más de 100 millones de años, recorrieron una misma distancia. Un “hercio” es como un “paso” para un circuito digital. Pero en un paso, hay procesadores que son capaces de avanzar más que otros.

El término “ciclo de CPU”, representa uno de estos pasos.

Y cada “Mhz”, equivale a 1 millón de ciclos por segundo.


Los primeros sistemas operativos domésticos.


Las versiones del TRS-80 con disquetera, usaban un sistema operativo de la casa, el TRS-DOS, que por lo visto no brillaba por su calidad. De hecho, hubieron bastantes alternativas de terceros, como CP/M, NEWDOS/80 y DOSplus, entre otros. La opción más asequible de guardar programas en los ordenador domésticos de finales de los 70, y principios de los 80, era usar cintas de casete (como bien recordarán algunos), que había que rodar, poner en marcha y parar, y donde era imposible buscar algo concreto, o leer sólo partes de un programa. Y eran lentas con ganas. Una de las ventajas que aportaban estos sistemas operativos, era poder organizar los programas y archivos en los disquetes, de forma similar a cómo lo hacemos hoy en día. Así que quienes podían permitirse adquirir una disquetera, habían dado un gran paso.


Sin embargo, la Atari 2600 no tenía necesidad tales cosas. Sus juegos venían grabados en memorias ROM dentro de cartuchos, y el procesador podía leerlos directamente. Tampoco estaba pensada para trabajar, ni organizar o guardar información. Pero en cualquier caso, no habría podido usar ningún sistema operativo, ya que disponía de tan poca memoria, que no podría almacenar ni la primera frase de este párrafo. Y no exagero, pues su tamaño era de sólo 128 bytes. Y sus limitaciones no acababan ahí, ya que únicamente la mitad del tiempo de la CPU podía ser usado libremente por el programador. Este escollo tiene su origen en la forma en la que la consola generaba las señales de video y sonido.


Cuando dibujar la imagen en el televisor no era gratis...


Aunque ahora empieza a implantarse la televisión digital, o TDT, las emisiones han sido analógicas desde sus comienzos. La CPU es un circuito digital, que no es capaz de hablar en “analógico”. Por ello, la Atari 2600 contaba con un segundo chip, que llamaron Stella, y que disponía de conversores digitales-analógicos, para que el procesador, a través de ellos, pudiera transformar su lenguaje binario, en ondas de amplitud variable, que entendiera la circuitería del televisor.


Pero Stella era mucho más, y hacía la vida más fácil al procesador, pues era capaz de dibujar 2 sprites, 2 proyectiles, un objeto y parte del fondo, en cada línea. En los sistemas de televisión PAL, hay que dibujar la imagen 50 veces cada segundo, y 60 veces en los sistemas NTSC. Los televisores clásicos, de tubos CRT, usan un único haz de electrones para crear la imagen que vemos en la pantalla. Este “chorro” de electrones hace barridos horizontales, y de arriba a abajo, hasta rellenarla. Entonces vuelve hacia la parte superior, para comenzar un nuevo barrido (ver abajo).


1.- El haz de electrones barre de izquierda a derecha, formando la primera línea (verde claro).

2.- El haz vuelve al extremo izquierdo, pero inactivo, sin dibujar (rojo).

3.- Se forma la segunda línea, y así sucesivamente, y siempre de izquierda a derecha.

4.- Al final, el haz debe volver a la esquina superior izquierda, para empezar un nuevo fotograma.

A cada imagen completa, se le suele llamar “cuadro”, o fotograma.


Por supuesto ocurre tan rápido, que nos parece que la imagen se crea de golpe y porrazo, pero no. En realidad lo hace de arriba a abajo, línea a línea, y punto a punto. La Atari 2600 tiene que ir generando cada una de estas líneas horizontales sobre la marcha. Al comienzo de cada línea, dispone de tan sólo 68 ciclos de CPU (unos 57 micro segundos) para preparar todo lo necesario. Así que por aquí vamos a tener poco tiempo libre.


Aquí es donde Stella acude al rescate, ya que se le puede decir dónde dibujar cada uno de los objetos que comentaba antes, y realiza por hardware el trazado de la línea. Sí, la línea. Es decir, había que reprogramar Stella antes de cada una, o repetiría la anterior. No tenía memoria para más. Y aún así, era de gran ayuda, y relajaba la enorme presión a la que estaba sometida la CPU, que por sí misma, a penas habría podido cambiar de color un par de veces por línea. Pero Stella no tenía capacidades de DMA (acceso directo a memoria), y la CPU debía estar en todo momento atenta y dedicada, mientras durase la transferencia de cada fotograma.


Sin embargo, al acabar un cuadro, mientras el haz de electrones regresa hacia la parte superior ( retrazo vertical ), y unos breves instantes, justo antes (durante el sincronismo vertical, o Vsync), es cuando se puede usar la CPU para dar vida a los personajes, responder a los mandos, llevar la cuenta de la puntuación, la acción, etc. Y a penas dispone del 50% del tiempo para esto, ya que sólo durante el sincronismo y el retrazo vertical, la CPU queda liberada de su tarea de “pintor digital”. Así que hay poco tiempo, y no cuándo se quiere, sino cuando toca, respetando una estricta temporización.


En resumen, la Atari 2600 sentó las bases, y sirvió de precedente para las consolas de 8 bits que estaban por llegar en la década de los 80, pero sus capacidades hardware estaban fuertemente limitadas. Era un diseño genial, inteligente e innovador, y con cierta pericia por parte del programador, se podía exprimir al máximo unos recursos muy escasos. Lo cual se tradujo en una consola de un precio asequible, que fue capaz de entrar en 10 millones de hogares. La Atari 2600 debía ajustarse a unos costes, en un momento en el que 1 Kbyte de RAM podría costar unos $200.

Haciendo una mala analogía, lo que hoy son 2 asequibles gigabytes de RAM, costarían más de 300 millones de euros.

NOTA: La analogía es, mala no, pésima, porque ni siquiera se trata del mismo tipo de memoria. La RAM que usaban las consolas de 8 bits era SRAM asíncrona, y la más habitual hoy en día es la DRAM síncrona. La tecnología no es (ni por asomo) la misma, y no he tenido en cuenta la inflación.



Este super cartucho, de más de medio metro de ancho, son 4Mbytes de RAM a finales de los 70.

En los recuadros rojos, se ven los chips individuales que la componían.

Muy barato no parece. Podría haber costado unos $20,000 sin correr demasiado.


Una época de 8 bits.


Las videoconsolas y ordenadores de 8 bits más famosos, guardaban muchas similitudes entre sí.

Como CPU solían usar un 65C02 de MOS, un Z80 de Zilog, o algún derivado de éstos. El rango de velocidades solía oscilar entre 1 y 4 Mhz. Valores muy alejados de los estándares actuales. Los Z80 solían funcionar a mayores frecuencias de reloj (Mhz), pero el 6502 rinde algo más en cada ciclo, y se defendió francamente bien. Su lenguaje máquina es sencillo, lo que lo hace atractivo y fácil de usar, pero el Z80 ofrece más recursos al programador, a expensas de una mayor complejidad. Actualmente sigue habiendo incondicionales de ambos micros. ¡Y el Z80 aún se vende!


En este punto, un sistema operativo amigable, sencillamente no tenía razón de ser. La necesidad de reducir costes al máximo, hacía que hubiera que aprovechar cada bit y cada hercio de la máquina. Y florituras las justas. Sistemas operativos de éxito, como el CP/M, eran controlados a través de una pantalla de texto, a base de comandos, y por tanto, sin entornos gráficos. No obstante, significaron un gran paso.


¿Qué aportaron? ¿y porqué no lo necesitan las consolas?

Hasta el momento, los ordenadores domésticos traían un pequeño programa monitor, con un intérprete de BASIC, que dejaba al usuario frente a una máquina vacía, una pantalla con un cursor parpadeante, donde sólo se podía teclear, y casi la única forma de hacer algo, era saber programar en BASIC, o, como supongo que hacían muchos, cargar juegos con un simple comando.


Los sistemas operativos también se controlaban a base de teclear comandos, y recibir respuesta en forma de texto, pero,...

Ventajas de los sistemas operativos

A) Simplificaban algunas tareas básicas.

B) Era posible usar disquetes de una forma sencilla, usando archivos, para mantener los programas y los datos ordenados, y acceder a ellos rápidamente.

C) Ofrecía apoyo a los programadores, de modo que resultara más fácil desarrollar software.

D) Si el sistema operativo era multiplataforma, como el CP/M, un programa escrito para él, funcionaría en cualquier ordenador donde pudiera correr ese sistema operativo.


Una de las grandes ventajas era ésta última. Actualmente es tan habitual, que pasa desapercibido. La idea es que un programa para Windows, funciona en cualquier ordenador (o debería hacerlo), aunque tengan distintos componentes, siempre y cuándo tenga instalado una versión de Windows compatible. Esto es porque en lugar de empezar el programa desde cero, se ha echado mano de características propias de Windows.


Para ilustrar la idea, voy a exponer un caso práctico, de forma simplificada; acceder al disco duro para leer o escribir información. Es una tarea muy habitual, sin embargo, en un PC sin sistema operativo, el programador debe conocer cómo funciona, o al menos, como se comunica con la placa base (en otras palabras, su interfaz). Los discos pueden ser IDE, SCSI, o más recientemente SATA. No se trata de discos duros internamente distintos, sino de diferentes interfaces, o formas de comunicarse con ellos.


Disco duro moderno (2009)

Un disco duro es en realidad un conjunto de discos superpuestos, con un hueco entre cada uno, por donde “vuelan” unas cabezas lectoras/escritoras. Cada disco tiene dos superficies, y hay una cabeza para cada una. La información se graba en cilindros, que se asemejan a las calles de un circuito de atletismo. Cada cilindro, se divide en sectores de tamaño fijo, donde residen los datos.


Cada dispositivo está dotado una electrónica de control, que por una parte, se encarga del manejo físico y mecánico, como la rotación de los discos, el movimiento de las cabezas, los impulsos eléctricos, etc. Cada fabricante tiene cierta libertad a la hora de implementar este apartado. Y por otra parte, dicha electrónica de control se debe entender con la placa base del ordenador, aceptando sus peticiones, y reportando el estado de cuanto sucede “a bordo”. Sin embargo, ahora el fabricante no tiene libertad para hacerlo como le venga en gana. Eso desembocaría en incompatibilidad entre distintas marcas, lo que habría sido un cachondeo. Por ello se definen interfaces estándares, al que todos acuerdan ceñirse, como el ATA (informalmente llamado IDE), el SCSI o el SATA. Son incompatibles entre sí, y debido a la rápida evolución de la tecnología, van aparecido versiones mejoradas, si bien dentro de cada familia, suelen ser retro-compatibles.


IDE ha sido el interfaz por excelencia en entornos domésticos, y actualmente es reemplazado poco a poco por el SATA. Algunos estándares de interfaces IDE, por orden cronológico y fecha aproximada, son IDE (1986), ATA (1994), EIDE (1996), UltraATA/33 (1998, comúnmente llamados UDMA33) y sus versiones ATA/66 (2000), ATA/100 (2002) y ATA/133 (2005).

Por suerte, las unidades IDE viejas siguen funcionando en placas base actuales. Pero las placas viejas son incapaces de sacar partido a discos duros basado en estándares más nuevos, o son incapaces de manejarlos en absoluto.


¡Vale! Nuestro programador tiene un disco duro IDE, y ya sabe cómo entenderse con él. Sin sistema operativo, esto último es vital, como vamos a ver. La controladora IDE dispone de varios registros que el ordenador puede leer y escribir, y que tienen funciones dispares. Para leer un archivo, nuestro “héroe” tendrá que asegurarse de que el disco duro está encendido y listo para recibir comandos, leyendo adecuadamente el registro de estado. Luego, tendrá que enviar la petición de lectura, escribiendo en el registro de control. Pero eso no es ni mucho menos suficiente, pues hay que indicar la posición precisa desde la que se quiere empezar a leer. Este valor se da habitualmente en bloques (si se dispone de modo LBA). Pero la controladora de disco no entiende de archivos, ni mucho menos carpetas o particiones. Lo único que sabe es “bloque 0”, “bloque 1”, “bloque 2”,... y así hasta el último. Como los bloques físicos son de 512 bytes, un dispositivo de 120 Gbytes, tendrá unos 250 millones de bloques. Habrá que averiguar en qué bloque comienza el archivo que deseamos leer. Supongamos que se trata del “bloque 21,254,321,220”. ¿Cuántos bloques leemos? Si, por ejemplo, nuestro archivo tiene un tamaño de 4 Mbytes, serían necesarios 8192 bloques (4*1024*1024 / 512) para almacenarlo. Vamos a suponer, una vez más, que sólo nos interesan los primeros 20 bloques, y que éstos son consecutivos. Le enviamos estos datos la controladora, sin olvidar en ningún momento que hay que comprobar que el disco no se queja ni reporta errores.


“Antiguamente” en lugar del modo LBA para acceder a los bloques por su posición, se debía conocer la geometría del disco, y usar el modo CHS, dando la posición en “cilindro”, “cabeza” y “sector”.


Y todo esto es el principio. Cuando la controladora sepa lo que el ordenador quiere, se encargará de hacerle llegar la tarea al disco duro, que tardará un tiempo en leer los 20 bloques que le pedimos. Será también tarea del programador averiguar el momento a partir del cual los datos están disponibles. Y luego, de transferirlos desde el buffer del disco duro, hasta la memoria RAM del ordenador, a través del el registro de datos de la controladora.


El buffer es una pequeña memoria donde se ha ido colocando la información según se leía, y permite un mayor rendimiento del que se obtendría si se transfiriera cada bloque conforme llegan. Este mecanismo se usa en muchísimos dispositivos, como grabadoras, impresoras, etc.


Pero sí, la aventura acaba de comenzar. Un archivo no tiene porque estar grabado seguido, en bloques consecutivos, sino que puede estar fragmentado, o disperso a lo largo del disco. De hecho, “desfragmentar el disco duro”, es, entre otras cosas, reordenar los bloques que ocupa cada archivo, para intentar que sean consecutivos.


Si imaginamos que cada cuadrado representa un bloque de un disco, y cada color su contenido, hay tres archivos, pero sólo el rojo es físicamente consecutivo. Los otros han ido ocupando otros bloques, por diversos motivos, y están, por tanto, fragmentados.



Después de desfragmentar, los archivos ocupan posiciones consecutivas.


Muchos usuarios relacionan “desfragmentar el disco duro” con “el ordenador va más rápido”. Esto no es del todo exacto. El problema de un disco duro muy fragmentado, es que leer y escribir se torna ineficiente, porque hay que hacer una mayor cantidad de búsquedas para leer la misma cosa. Cada salto entre bloques, implica que las cabezas deben moverse al cilindros correcto, y esperar a que los datos pasen por debajo, ya que los discos siempre giran a la misma velocidad y en el mismo sentido. Si hay que leer bloques consecutivos, no se pierde tiempo en buscarlos. Basta con buscar el primero, y leer de seguido.


Pero saber donde comienza un archivo, y cómo saltar de un bloque al siguiente, requiere conocer el sistema de ficheros de la partición (FAT32, NTFS, ext3, reiserFS, o la que sea ). Es decir, saber navegar a través suyo, entenderlo, y modificarlo.


Reconozco que todo esto puede ser un poco abstracto para alguien que no sepa programar. Pero hacer una sencilla aplicación, capaz de leer un disco duro a tan bajo nivel, puede ser un infierno incluso para un programador con experiencia. Además de requerir un tiempo de desarrollo y depurado considerable. De forma simplificada, hemos atacado el problema así:




Por supuesto, ¡esto no es práctico en absoluto! Y no es la forma en la que suele hacerse. ¿Qué, entonces? Programar para un sistema operativo, ¡y decirle que haga todo esto por nosotros! A esta acción se la conoce como hacer “llamadas al sistema”. Y la forma en la que se hace uso de todas las funcionalidades que nos ofrece, es el “API”, o simplemente interfaz, del sistema operativo.


En Windows, o Linux, no necesitamos conocer nada acerca del disco duro, ni tan siquiera si de trata de un disco, un pendrive USB, o de una tarjeta SD. Y tampoco el sistema de ficheros que usa la partición, siempre y cuándo la soporte el sistema operativo. Basta con unas pocas líneas de código en un lenguaje de alto nivel como C, C++ o Java. Resulta fácil incluso en ensamblador (representación directa del código máquina).



Todo esta historia debería haber dejado más clara la tremenda importancia de los puntos A,B y C de la lista “ventajas de los sistemas operativos”, y lo mucho que aportan a nivel de software en ordenadores complejos. Este ejemplo ha sido sólo una pequeña muestra de lo que ofrecen. Y como recordatorio, el punto D de la lista, era la ventaja de la portabilidad entre máquinas con distinto hardware.


Pero no todo el monte es orégano, claro. Precisamente por todo esto, los programas de Windows no funcionan en Linux, y viceversa. Y lo mismo se aplica al resto de sistemas, como MacOS, Solaris, etc..., pues cada uno tiene su propio API.



Volviendo a los 8 bits....


La Atari 2600, la NES/Famicom o la Master System, no necesitaban sistema operativo. Volviendo a la lista de “ventajas de los sistemas operativos”:


A) Simplificaban algunas tareas básicas.

No había nada que simplificar. Todo cuánto se podía hacer con la consola era introducir el cartucho, y encenderla.


B) Era posible usar disquetes de una forma sencilla.

Los cartuchos se pueden leer sin necesidad de software adicional, pues están directamente conectados al procesador a través del bus principal. Merece mención el caso del “Disk System”, un periférico para Famicom, que cargaba los juegos desde disquetes de 3”, como hacían los ordenadores Spectrum+3, o el Amstrad CPC6128, entre otros. Se conectaba por medio de un adaptador al conector de cartuchos, y contenía un software de control en su interior, que de forma automática, controlaba la carga del disco a la memoria.


C) Facilitaba el desarrollo de software.

Mejor prescindir de ello. Cualquier sistema operativo hubiera consumido unos recursos valiosísimos. Era preferible escribir los juegos accediendo directamente al hardware de la máquina, y aprovechar al máximo su escasa potencia. Por supuesto, escribir todo en ensamblador era mucho más complejo y tedioso, que hacerlo en un lenguaje de alto nivel como el C, y sobre un sistema operativo, pero en aquel momento no existía alternativa. Cada ciclo de CPU, y cada byte de memoria, eran importantes.


D) El software es portable entre distintas máquinas, si éstas corren el mismo sistema operativo.

Originalmente, no había necesidad de dar soporte a distintas configuraciones de los mismos modelos, porque las videoconsolas no eran a priori ampliables, ni variaban sus capacidades gráficas, ni de sonido, como tampoco de memoria, ni procesador. En cambio, sí que era un problema la portabilidad de los juegos multiplataforma, que debían salir para consolas distintas. Aunque en ocasiones muy parecidos, como ocurre con muchos juegos de Super Nintendo y Megadrive, eran en esencia programas distintos. Todo en ellas era distinto; el procesador, el sistema gráfico, el de sonido, las cantidades de memoria, la lectura de los controles, etc... Así pues, hacer una versión a partir de una existente, exigía reescribir y adaptado mucho código, lo que suponía un esfuerzo considerable.


Por tanto...


Los sistemas operativos no eran necesarios en las primeras videoconsolas de 8 bits. En el próximo artículo, explicaré como tampoco lo fueron en la generación de los 16 bits, ni en la de las primeras 32 bits, y cómo, cuándo y porqué empezaron a entrar en el juego.


Mi plan es hacer tres entregas, y en la última, centrarme en ejemplos de videoconsolas donde corren, o pueden correr, sistemas operativos, sobretodo basados en GNU/Linux.


Espero que la lectura haya resultado amena o cuanto menos instructiva. Un saludo a todos.

David Senabre Albujer, 2009.

VOLVER