Para lograr este objetivo, mostraremos temas relacionados con el manejo y función de cada una (y casi siempre en combinación con otras) de las partes que componen todo el sistema operativo. Debido a que todos los ejemplos que se publicarán estarán escritos en C, los artículos quedan unidos estrechamente al curso del lenguaje C que nuestro amigo A.Moreno realiza en su sección de Amiga.InFo. Las dos secciones se escriben en paralelo y se relacionan para intentar que tanto el lenguaje C como el S.Operativo sean dos herramientas de aplicaciones en Amiga. Así pues, a la hora de escribir un ejemplo en C que ilustre algún punto concreto, las cuestiones propias de este lenguaje se dirigen a la sección de C. Aquí no se comentará propiamente el lenguaje, sino la programación y uso del S. Operativo a través de él.

UN POCO DE HISTORIA

Ocurrió en los años 80. Un grupo de ingenieros (por no decir dos o tres) tuvieron la idea de diseñar una máquina que no siguiese los esquemas de la época. Desarrollaron un hardware avanzado que permitía integrar imagen, sonido y programas en una misma máquina. Simplemente era una caja negra repleta de circuitos, pero que mostraba unas capacidades gráficas y sonoras fuera de lo común. El éxito como máquina de videojuegos estaba asegurado.

Pero no era suficiente. Se podía investigar más, y pasar de consola a ordenador. Y así lo hicieron. Nació el Amiga.

Todo el mundo comentaba sus excelentes gráficos y se sorprendían con la calidad del sonido, pero pocos observaban un aspecto que escondía un gran potencial. El sistema operativo.

En aquella época desarrollaron e implementaron ideas en el Amiga, que ahora, en 1994, están adaptando otros sistemas que se consideran modernos. Está basado en un entorno gráfico con diferentes pantallas y ventanas dimensionables, que coexisten con iconos, cajones de ficheros, y otras herramientas gráficas muy similares externamente a sistemas como X Windows (Unix) o OS/2 (IBM PC). La utilización de esta organización gráfica, unida al ratón, ofrece una facilidad inusual para realizar todo tipo de tareas y conseguir que cualquier usuario (de forma intuitiva) aprenda a deselvolverse en las más complejas. Este entorno está potenciado con la posibilidad de ejecutar simultáneamente todo tipo de programas que emplean y comparten todos los recursos del sistema".

Un usuario puede ejecutar al mismo tiempo varios programas e interactuar con ellos para obtener una productividad mayor. Por ejemplo, un programa de dibujo, uno de autoedición, uno de digitalización y un procesador de textos. Todos pueden estar ejecutándose de forma simultánea. Transferir los resultados de una foto digitalizada al programa de dibujo, retocarla a voluntad, añadir un texto que la acompañe y unir todo con el programa de autoedición para imprimir el resultado final, es posible hacerlo con el simple movimiento por pantalla del puntero del ratón y ¡todo esto mientras se escucha un módulo de música de Amiga!.

Evidentemente, esta capacidad multitarea no es posible sin el apoyo de un 'hardware' altamente especializado. Para ello, Amiga emplea varios 'custom chips' que incorporan, entre otros circuitos, coprocesadores para gráficos y sonido. (En la sección 'Amiga Interno' encontraréis más información sobre el hardware del Amiga).

CONCEPTOS PREVIOS

En este primer acercamiento al Sistema Operativo, al que llamaremos S.O. para abreviar, hay que introducir algunos conceptos que para algunos lectores resultarán desconocidos y, para otros, familiares, pero que al fin y al cabo siempre es conveniente recordar. Las tareas, procesos, dispositivos, memoria y un largo etcétera van a ser muy pronto parte de nuestro lenguaje de 'andar por casa', ya que son necesarios para comprender cualquier tema relacionado con el S.O. Pero no esperemos más, y entremos en materia comenzando por una definición del propio S.O.:

• S.O.: Un sistema operativo es un programa que actúa como interfaz entre la máquina y el usuario, facilitando a este último el acceso y ejecución de otros programas. Este interfaz está estrechamente ligado con el hardware de la máquina, y nos proporciona los recursos necesarios para poder realizar las tareas tan comunes como acceso a los discos, memoria, pantalla, impresora, etc. El S.O. no es un programa en concreto sino que, generalmente, se trata de diversos programas que unidos forman un entorno de trabajo para el usuario.

• Programa y Proceso: Los programas que ejecutamos, es decir, el conjunto de instrucciones que forman el código y los datos necesarios, son, desde el punto de vista del S.O., procesos. Para nosotros un programa se compone de un código y unos datos, pero para el S.O. no es suficiente tener esa información. Necesita también otro tipo de datos para poder integrar el programa dentro del sistema, y ejecutarlo. Información, como pueda ser la zona de memoria donde se carga, ficheros que maneja, recursos que utiliza y otros aspectos que puedan aparecer a la hora de ejecutar el programa, son indispensables y están contenidos internamente en los procesos. Normalmente, esta información adicional es añadida automáticamente a nuestro programa por el compilador o ensamblador que utilicemos. Para el usuario esto es invisible y transparente, puesto que sólo observa como su programa se ejecuta y se le presenta en pantalla con tan sólo un par de toques en el ratón. Sin embargo, para el S.O. y el programador, ese programa se convierte en un proceso con todo lo que conlleva.

• Tarea: Los procesos, internamente, tienen asociadas otras entidades ejecutables más primitivas, de nivel más bajo, denominadas tareas. Todo proceso contiene una tarea, además de la información adicional que hemos comentado antes, que permite principalmente el acceso al sistema de ficheros. La tarea está compuesta interamente por un conjunto de instrucciones a ejecutar (el que forma nuestro programa) y sus datos, así como una zona de memoria reservada, donde se almacenan datos temporales, denominada pila. Una de las razones de trabajar con procesos y tareas, es la de diferenciar qué parte de un proceso es la que va a ser ejecutada por el procesador, es decir la tarea, y que parte es simplemente de datos. Es más, pueden existir tareas que se ejecuten en el procesador y formen parte de procesos, o tareas independientes que no esten asociadas a ningún proceso. Estas últimas, por ejemplo, son el caso de rutinas sencillas que no tienen necesidad de acceder a ficheros. La figura 1 nos puede ayudar a ilustrar el concepto de tarea y proceso.

• Multitarea: El S.O. de Amiga es multitarea o multiprograma, es decir, tiene la capacidad para controlar la ejecución simultánea de múltiples e independientes tareas. El usuario normal tiene la visión de poder trabajar con varios programas a la vez. Para el S.O. y el programador, esta visión es bastante diferente: el procesador es compartido en el tiempo por las tareas, de forma que cada una tiene su propio procesador virtual. En un determinado instante, únicamente una tarea está ejecutándose en el procesador. Cuando transcurra un tiempo, esta tarea deja de ejecutarse y entra otra. De esta forma cíclica, cada tarea toma un tiempo de procesador, lo deja y entra la siguiente. Evidentemente, el acto de cambiar de una tarea a otra es rapidísimo (de 10 a 100 milisegundos), tanto que como resultado final, el usuario tiene la ilusión de que todos sus programas están corriendo simultáneamente. Pero... ¿quién controla el cambio de tareas? La respuesta es simple: El S.O. Pero éste, que es un tema tan apasionante como extenso, perece un próximo artículo.

• Procesador: Es el componente físico* que ejecuta el código de las tareas. Tiene acceso a todo el sistema hardware, recibe y atiende a las interrupciones, controla la comunicación física con otros componentes, el acceso a los buses y muchas más cosas que hacen que sea el eje central de todas las actividades que se realizan dentro del ordenador. Para que nos sea más familiar, también lo nombraremos 'M680X0', ya que en Amiga únicamente se han implementado procesadores de la familia Motorola 68000 (Para más información, ver sección Amiga Interno).

• Memoria: Es el componente físico que almacena los programas y los datos. Está dividida en casillas (posiciones dentro de la memoria) donde se almacena individualmente cada dato de tamaño 8 bits. Cada casilla tiene un dirección única (valor numérico) que la identifica. Si queremos almacenar un dato, se le envía la dirección de la casilla y la orden de lectura, después la propia memoria nos dará el dato que contiene esa casilla.

El S.O. está basado en direcciones relativas de memoria, es decir, las funciones y estructuras de datos, así como los programas, pueden residir en cualquier parte de la memoria y no necesariamente en una posición única y fija. Incluso pueden reorganizarse dinámicamente dentro de ella según las necesidades y circunstancias. Como resultado, cualquier programa que necesite un bloque de memoria, debe solicitarla al sistema operativo, y este se encargará de buscar una zona libre. Normalmente, los atributos de la memoria son determinados por el tipo de memoria que el programa necesite. Efectivamente, en Amiga existen diferentes conceptos de memoria, los principales son:

Memoria CHIP: Esta memoria es la única direccionable por los 'custom chips' (comentados en la sección Amiga). Este tipo es necesitado cuando existen datos que han de ser accedidos por los canales DMA* de estos chips especiales. Generalmente son datos de gráficos y sonido, así como cualquier dato relacionado con el manejo de los coprocesadores (programas de 'copper*', por ejemplo), aunque también se incluyen los 'buffers*' de disco y los 'sprites*'.

Memoria FAST: Es la memoria a la cual únicamente puede acceder el procesador. En este caso, los 'custom chips' no tienen acceso a ella, quedando totalmente libre para almacenar código y datos de los programas. El Término 'FAST' (rápida) se debe a la arquitectura de los buses del Amiga. Mientras que la memoria CHIP puede ser accedida pro el procesador y los custom chips, con prioridad para estos últimos en caso de acceso simultáneo, en la memoria FAST no se produce esta 'colisión', permitiendo al procesador MC680X0 funcionar con la máxima eficiencia. Evidentemente, un Amiga sin memoria FAST únicamente puede disponer de la CHIP, que se comparte tanto para programas como para los datos de los 'custom chips'. Por este motivo, hay que notar la desventaja que en cuestión de eficiencia se obtiene entre un mismo Amiga ampliado con FAST y otro sin ella (diferencia que se acentúa aún más cuando se utilizan DRAM's de 16 bits frente a los de 32 bits).

El sistema mantiene una lista de los bloques de memoria utilizados y los libres, siendo posible añadir nuevos bloques a esta lista de forma dinámica*, ya que se reconoce automáticamente la cantidad de memoria física que el sistema posee.

• Dispositivos E/S: Una parte importante del sistema son los dispositivos o 'devices' que permiten acceder al hardware del Amiga. Los dispositivos permiten al programador operar, por ejemplo, con la impresora, un módem, el motor de la unidad de disco, temporizar un suceso, emitir un sonido, etc.. Un dispositivo es un módulo dentro de la jerarquía del sistema operativo que actúa como interfaz. Acepta órdenes y datos y realiza operaciones de entrada/salida basándose en los comandos que recibe. En la mayoría de los casos, interacciona con el hardware interno o externo y tiene una tarea ejecutable asociada que es capaz de procesar comandos mientras nuestras aplicaciones quedan libres para realizar otros trabajos. No son parte del hardware, es decir, son código y datos de control, y por tanto, susceptibles de modificación por parte del programador.

Desde el punto de vista del usuario, los dispositivos se muestran como simples nombres que van ligados a periféricos, por ejemplo, la unidad de disco (DF0:), disco duro (DH0:), impresora (PRT:), puerto serie (SER:), etc. (Muy a menudo, a estos y otros componentes, los llamaremos en general 'recursos físicos'). El S.O.: reconoce automáticamente algunos de ellos y los activa al arrancar el sistema.

Para el S.O. y el programador, los dispositivos son tareas independientes que están a la espera de recibir cualquier comando para activarse y pasar a ejecutarlo, o a la espera de que un suceso ocurra y comunicarlo al S.O. La filosofía empleada en los dispositivos es que las operaciones de E/S deben ser efectuadas de forma consistente, uniforme y estándar. Se puede imprimir un fichero de la misma forma que se puede emitir un sonido digitalizado, tan sólo con mandar a cada dispositivo correspondiente (el paralelo y el de audio) un comando WRITE (escribir) y la dirección del buffer donde se almacenan los datos. El resultado es que el interfaz presentado al programador es esencialmente independiente del recurso físico a controlar y accesible desde cualquier lenguaje de programación. Esta característica expande de forma increíble las posibilidades que el Amiga provee al programador y, finalmente, al usuario.

Los dispositivos soportan dos tipos de comandos: Los estándar, como READ (leer) o WRITE (escribir), y los específicos del recurso físico a controlar, como por ejemplo MOTOR, que activa el motor de la unidad de disco (trackdisk.device), o el comando READMATRIX, que retorna el estado de cada tecla del teclado (keyboard.device).

Esta estructura de dispositivos es compartida por otros sistemas operativos modernos, puesto que proporciona al sistema modularidad y acceso sencillo, así como una organización eficiente de los recursos disponibles. Es posible añadir dispositivos de forma dinámica, característica poco común en los sistemas operativos como Unix, donde para añadir un dispositivo nuevo hay que ¡recompilar todo el sistema!

• Sistema de ficheros: Es la parte que se encarga de gestionar la información que se puede crear, leer, escribir, borrar, etc. en los dispositivos de E/S. Esta información pude ser ficheros, directorios, protecciones, fechas de grabación atributos (ejecutable, borrable, escritura, etc.), Mantiene un control de acceso a ellos, y maneja los errores que puedan existir.

Llegados a este punto, ya tenemos una idea, más o menos clara, de algunos de los conceptos que a partir de ahora aparecerán muy a menudo en esta sección. Sin embargo, estos conceptos por sí solos no representan gran cosa, hay que unirlos para poder tener una visión global del sistema al cual nos enfrentamos.

GESTIÓN, CONTROL, PLANIFICACIÓN

Si reflexionamos un poco, nos daremos cuenta inmediatamente de que la vida se nos haría insoportable sin ciertas cosas tan necesarias como la electricidad, luz, agua, aire y como no, nuestro Amiga. Pero sería más que insoportable si cuando conectaramos el ordenador tuviéramos que teclear los programas que queramos que ejecute, activar los periféricos uno a uno para poder leer o escribir en ellos, manejar la memoria y tener cuidado que no se llene, controlar donde está situado el ratón y el cursor en pantalla... ¿Quién tendría entonces un ordenador? Algún masoquista. Afortunadamente, esta no es la situación, ya que las anteriores y muchas más tareas las realiza automáticamente el propio ordenador, y para nosotros, sus usuarios -y a veces esclavos- la vida se nos hace menos pesada.

No es muy difícil averiguar que el S.O. es el encargado de controlar, gestionar y planificar el 90% de todo lo que sucede en un ordenador. El restante 10% queda para nosotros, los usuarios y programadores.

• ¿Qué controla?

Prácticamente controla las actividades de todos los componentes internos o externos electrónicos. Su control es absoluto, puesto que ha de proporcionar una estabilidad y seguridad a todo el sistema.

• ¿Qué gestiona?

Maneja toda la comunicación y movimiento de la información entre los diferentes módulos que lo componen. Avisa y es avisado de los acontecimientos que suceden en su entorno.

• ¿Qué planifica?

Organiza, coordina y prevé todas las situaciones que se puedan dar en el Amiga, para poder usar todos los recursos de una forma óptima y eficiente.

Pero veamos realmente por qué el S.O. tiene tanta importancia, a veces un poco infravalorada por no tener conocimiento. Lo haremos con un ejemplo muy sencillo y que hemos realizado miles de veces: conectamos el Amiga, tras unos segundos en los que se activa lo necesario, aparece en nuestra pantalla el WorkBench; desplazaos el ratón hacia el icono del programa que más usamos (¡seguro que la mayoría ha pensado en el Directory Opus!) y pulsamos dos veces el botón izquierdo; tras el instante que dura la carga en memoria, se ejecuta y aparece, en una nueva ventana, el programa. Hasta ahora no ha pasado nada que no conozcamos, por lo menos desde nuestro punto de vista de usuario normal.

Pero imaginemos ahora que pasamos de usuario a superusuario, y que podemos observar cada detalle de la actividad del S.O., desde que encendemos el ordenador hasta que nuestro programa aparece en pantalla.

1. ¡Click! Interruptor ON
2. Se inicializan los registros de los diferentes chips con los valores adecuados.
3. Se verifica y testea la cantidad de memoria disponible.
4. Se comprueba si el 'kickstart' (es una parte del S.O) está en ROM* o hay que cargarlo de disco.

   FIGURA 2. Ilustración de las funciones principales de un S.O. Se puede observar como estas funciones de manejo de la memoria, procesos, dispositivos y ficheros están por encima del hardware, es decir, no son parte de él. Así mismo, el usuario normal está por encima del S.O y "teóricamente" no puede acceder al hardware sin pasar por él. En la práctica, se saltan del nivel de usuario al nivel de hardware muy frecuentemente, sin respetar al S.o y accediendo directamente a los registros de los chips. Esta forma de acceso siempre ha traído problemas de compatibilidad de código, pero hay que reconocer que se gana velocidad y flexibilidad. Este método es utilizado por los programadores de demos y juegos, pero nosotros seremos 'más legales' y consideraremos al S.O como un puente entre nuestros programas y los componentes electrónicos del Amiga. Respetaremos las reglas de programación que Commodore aconseja y el acceso directo lo dejamos para la sección 'Amiga Interno'. Algunos S.O tienen protegido totalmente el hardware, y no permiten a los usuarios ningún tipo de acceso que no sea contemplado por el sistema. En Amiga no existe esta protección, y cualquiera puede acceder directamente a zonas reservadas y 'colgar' el ordenador.

5. Se comprueba si existe un disco en la unidad 0.
6. Si no hay disco y hay que cargar el kickstart, se solicita un disco de tipo 'kickstart' para cargarlo.
7. Si no hay disco y el kickstart está en ROM (o se ha cargado ya en memoria RAM)m el procesador ejecuta el código que reside en el 'Kickstart0, es decir, el S.O. inicia su control del sistema.
8. Se verifica e inicializa el teclado.
9. Se comprueba la existencia de expansiones autoconfigurables (memoria, aceleradoras, discos duros...)
10. Si no se ha introducido un disco, se presenta la pantalla de introducir disco (la típica mano del WB o la animación del disco introduciendose en la unidad). En caso de no haber detectado la existencia de ningún otro recurso físico que pueda arrancar el sistema (Disco duro, RAD...) se mantiene en espera hasta que se introduzca.
11. Si existe un disco en la unidad, se comprueba de que tipo es. Si es reconocible por el S.O., se intenta arrancar cargando la primera pista (sector 0 y 1) y pasando el control al programa almacenado en él. Si es un disco no reconocible, por ejemplo, uno no formateado, se vuelve a presentar la pantalla solicitando disco y comienza de nuevo el proceso 10.
12. Si el disco es de tipo DOS, se intenta ejecutar el fichero de inicio 'startup-sequence' del directorio 's/'.
    Si no existe este fichero, se abre una ventana y aparece una ventana para teclear comandos (Shell).
    Aparece en pantalla el cursor y se inicializa el 'sprite 0' para que aparezca el puntero del ratón. A partir de ahora, cada vez que utilicemos el teclado o variemos la posición del ratón, así como si se pulsa algún botón del mismo se ejecutarán unas rutinas. Estas rutinas avisan al S.O. de los sucesos que ocurren, y este actualiza la pantalla según estos avisos.
13. Si existe el fichero de inicio 'startup-sequence' (ya sea en el disco, o en algún otro recurso físico como el disco duro) se carga y se ejecutan los comandos escritos en él. Se realizan asignaciones de directorios, aparece el disco virtual 'RAM', se montan los restantes dispositivos, y se cargan algunas librerías del directorio 'libs'. También se configuran las preferencias y finalmente aparece la pantalla del Workbench. Se cargan los iconos de los directorios, ficheros, y dispositivos montados correctamente y se muestran en ella.
14. Se detecta un movimiento del ratón en dirección a un icono, y cuando está situado sobre él, se detectan dos pulsaciones seguidas, del botón izquierdo delratón. Se intenta cargar el fichero que tiene el mismo nombre que el presentado en pantalla por el icono. En este caso es el 'Directory Opus'. Se reserva un bloque de memoria del tamaño del fichero y se carga del dispositivo al cual pertenece ese icono.
15. Se ejecuta el código que existe en el fichero y aparece en pantalla el 'Directory Opus'.

Como podéis comprobar, el S.O. tiene que estar atento a todos los sucesos que ocurran, y actuar en consecuencia. Estos 15 son algunos pasos deducidos, ya que si tuviéramos que entrar realmente en hacer un seguimiento exhaustivo, descubriríamos que hay más de 200 puntos que nos hemos olvidado. El S.O. está para ejecutar esos puntos y resumirnos el trabajo de tal forma que únicamente 2 de esos 200 puntos dependen directamente de nosotros: introducir el disco (si no hay disco duro, claro) y pulsar dos veces el icono del porgrama que queramos ejecutar.

Si generalizamos, es decir, no entramos en detalles, podemos ver que las funciones principales de cualquier sistema operativo son las siguientes (ver figura 2):

• Manejar los procesos (crearlos, destruirlos, bloquearlos...)
• Manejar la memoria (reservar y liberar bloques de memoria...)
• Manejar los dispositivos (leer/escribir información a través de ellos..)
• Manejar los ficheros (crearlos, abrirlos, cerrarlos, borrarlos, actualizarlos...)
• Protección y detección de errores (situaciones de escasa memoria libre, accesos ilegales, gurus...)
• Administración de los recursos del sistema con eficacia y seguridad (coordinar los acceso simultáneos a los dispositivos, compartir la memoria, comprobar las protecciones de los ficheros...)

Todas estas funciones fueron incorporadas por los ingenieros al Amiga. Sin embargo, para ellos, existían más, puesto que añadieron ideas clave que tenían como meta conseguir la integración total del S.O. y el hardware. Se propusieron facilitar al máximo cualquier actividad que pudiera realizar el usuario o programador, creando un entorno de trabajo basado en la intuición y la lógica humana. Dividieron el sistema en partes y se les asignó programas de control, es decir, crearon un conjunto de módulos que al unirse formaban lo que conocemos como el S.O.

¿UN S.O. MODULAR?

En Amiga, el S.O. está compuesto por una gran cantidad de módulos formando una jerarquía en función de los trabajos que desempeñan. Estos módulos se comunican y están relacionados entre sí. La información pasa directamente de un módulo a otro utilizando paquetes de datos o 'mensajes'.

Para un usuario normal todos estos módulos son invisibles a excepción de, por ejemplo, los que se encargan de presentar los datos en pantalla o el encargado del acceso a disco. Sin embargo, para un programador de aplicaciones y para el usuario curioso, el conocimiento y la forma de acceder a ellos es indispensable.

Estos módulos se crearon a partir de la necesidad de controlar cada componente electrónico del Amiga y por otro lado, proporcionar una gran flexibilidad a la hora de desarrollar y adaptar nuevos componentes. El acceso a ellos se realiza mediante llamadas a funciones. Estas funciones son rutinas preprogramadas y residentes en memoria (la mayoría de ellas en ROM). El conjunto de dichas funciones se denomina 'librería' (Ver figura 4 en página siguiente).

A modo de ejemplo de función y librería, podemos imaginarnos que queremos dibujar en pantalla un círculo. Podríamos programar una rutina que lo dibujase, pero no hay necesidad ninguna, puesto que ya existe una preparada en una librería denominada 'graphics.library'. Con sólo llamar desde nuestro porgrama a la función 'DrawEllipse()' y pasándole los parámetros correctos, aparecerá en pantalla un círculo. En esta misma librería existe un centenar de funciones dedicadas exclusivamente a gráficos y hay una docena de librerías de todo tipo ¡listas para ser usadas!

Pero a las librerías ya les dedicaremos un artículo completo en otro momento, donde entre otras cosas, descubriremos que los dispositivos son un tipo de librería especial. Ahora veamos que tal se muestran estos módulos en el esquema de la figura 3.

En esta figura, observamos dos elementos diferentes, pero ya conocidos: las librerías y los dispositivos. Los enmarcados en rectángulos son librerías, y los elípticos son dispositivos. Las líneas verticales representan que módulos se comunican entre ellos. POr ejemplo, el 'Workbench' se comunica con el dispositivo 'Consola', y éste, a su vez, con el de 'Entrada de datos0, y sigue hasta que por último se llega a nivel del hardware. La comunicación es bidireccional, es decir, se puede enviar y recibir información de uno o más módulos. Cuando hablamos también de la posibilidad de que un módulo utilice las funciones de otro para conseguir un propósito.

¿QUE MÓDULOS COMPONEN EL S.O.?

Los dispositivos ya han sido comentados (ver la tabla de dispositivos del Amiga), así que introduciremos brevemente las librerías principales.

• Librerías:

  • DOS: Responde a las iniciales de 'Disk Operating System', es decir, sistema operativo de disco. Contiene todas las rutinas relacionadas con el tratamiento de ficheros (abrir, leer, escribir, cerrar ficheros, etc.)
    
    Controla los directorios y toda la información relacionada con el almacenamiento de datos en disco, por ejemplo, los atributos de un fichero (ejecutable, escritura, borrable, legible, fecha, comentario, etc.). Los programas son cargados en memoria a través de funciones de este módulo, donde pasan a ser procesos. Es utilizado por la SHELL principalmente para ese propósito (a la hora de ejecutar comandos) y el WorkBench (al manejar iconos).

  • Intuition (Intuición): Contiene las funciones en las que se basa el interfaz gráfico del usuario. Como su nombre indica, uno de los propósitos de este módulo es conseguir que el usuario utilice al máximo su intuición a la hora de trabajar con el ordenador, empleando para ello el ratón e imagenes gráficas que representan acciones. Las pantallas (screens), ventanas (windows), menús, solicitudes (requesters), botones (gadgets), etc. son manejadas aquí, en colaboración con las librerías de planos y la gráfica y del dispositivo de entrada de datos. Las dos primeras proporcionan las funciones que permiten coordinar y dibujar los gráficos en pantalla, mientras que el dispositivo proporciona los datos que el usuario introduce a partir del teclado y ratón.

  • Layers (Planos): Permite crear los planos que componen una pantalla. Una misma pantalla puede ser utilizada por varios programas gracias a la creación de capas o planos rectangulares e independientes donde se dibujan los gráficos. En el caso de que se produzca un solapamiento de capas al compartir la misma pantalla, se crean zonas invisibles y zonas visibles de la capa, según prioridades. Estas capas pueden moverse, reescalarse, y desaparecer o aparecer en pantalla, dando la sensación de trabajar con varios niveles de profundidad. La librería 'Intuition' está muy ligada a ésta para la creación y manejo de las ventanas, menús, etc.

  • Gráficos: Principalmente contiene rutinas de creación de pantallas y dibujo de gráficos primitivos, como rectas y polígonos. Utiliza características como la resolución, número de colores, posición, tamaño, etc, para formar la pantalla. Por otro lado, maneja todos los objetos gráficos permitiendo animaciones y control de colisiones entre ellos.

  • Exec: Su nombre proviene de 'Executive' (ejecutivo) y posiblemente es la parte más importante del S.O. Es el módulo que controla totalmente las tareas, la memoria, los mensajes, las interrupciones y los dispositivos de entrada y salida. Contiene rutinas para la coordinación, planificación y ejecución de las tareas, para solicitar bloques de memoria libre o liberar los ocupados, para enviar o recibir información entre los módulos mediante mensajes, para el control de sucesos que puedan interrumpir al procesador, y para el manejo de las entradas y salidad de datos en los dispositivos. Esta librería es la encargada de manejar la multitarea y es utilizada principalmente por el módulo AmigaDOS.

Todas estas librerías son las más importantes dentro del S.O., pero no son las únicas. Existen otras 'secundarias' que proporcionan un gran número de funciones de todo tipo al programador (funciones matemáticas, interfaz de ficheros, manejo de iconos, carga de fuentes de carácteres, etc.). También es posible crear librerías con nuestras propias funciones, y añadirlas al sistema cuando las necesitemos.

¿QUE RELACION EXISTE ENTRE LOS MODULOS?

Una de las ideas clave para comprender el funcionamiento de estos módulos es saber como se relacionan entre ellos y por qué motivo lo hacen.

'Divide y vencerás' son las dos palabras con las que podríamos definir la filosofía empleada a la hora de crear las partes del S.O. Cada trabajo es dividido y realizado por un módulo distinto, y cada uno de ellos recibe o envía la información con la que trabaje a otro módulo. Separados controlan cada uno una parte del Amiga, pero unidos consiguen crear una base activa que nos permite controlar la totalidad del sistema.

Algunas de las ventajas de este esquema modular son importantes:

- Existe más flexibilidad a la hora de programar los módulos.

- Un módulo puede ser reemplazado por otra versión más eficiente, sin necesidad de cambiar todo el S.O.

- El programador puede utilizar uno o varios de estos módulos independientemente para sus aplicaciones, o unirlos para conseguir un resultado concreto.

La desventaja principal es que también hay que crear un sistema de comunicación común y fiable entre todos los módulos, y esto implica principalmente pérdida de velocidad del S.O. Sin embargo, en Amiga se ha diseñado un sistema de comunicación rápido y seguro, utilizando puertos y mensajes, que cargan mínimamente al procesador. Este sistema será comentado cuando hablemos detalladamente de la librería 'Exec'. También hay que parametrizar cuidadosamente cada función dentro de las librerías, definiendo qué registros y valores hay que pasar en las llamadas, y los resultados que devuelven.

La idea principal a tener encuenta es como se relacionan los módulos en algunos de los trabajos propios de un S.O., como pueden ser, por ejemplo, los siguientes:

• Presentación en pantalla: La pantalla, con sus ventanas, menús, gadgets y demás herramientas gráficas es uno de los aspectos del S.O. que el usuario puede ver directamente. Normalmente, la primera pantalla con la que trabajamos es la del Workbench. ¡Ojo! El Workbench en sí no es parte del S.O., es un programa de aplicación, que abre una pantalla pública a la que otros programas pueden acceder y utilizar. Permite a los usuarios usar el sistema de ficheros a partir de iconos y ofrece al programador un conjunto de funciones para manejarlos. Está situado en la parte más alta de la jerarquía, y podemos ver en la fig.3 como se comunica con AmigaDOS e Intuition. El primero lo utiliza para tratar con los procesos y los ficheros que son representados por los iconos, y el segundo crea el entorno de pantallas, ventanas y menús cuando estos mismos procesos son ejecutados.

• Interfaz con el usuario: El contacto directo con los ficheros lo obtenemos normalmente al abrir una Shell (También llamado CLI o Command Line Interface). El usuario puede escribir y dar ordenes en forma de comandos (dir, list, type... etc). Para introducir estos comandos se utiliza el dispositivo Consola, donde son interpretados los códigos ASCII, es decir, los caracteres que escribimos en la ventana de la Shell y después de ser procesados se envían al módulo AmigaDos. Este a su vez carga en memoria el fichero del conmando e intenta ejecutarlo, tratando los errores en caso de que ocurran (por ejemplo, cuando no existe el comando que hemos escrito). La Shell actúa de intermediaria entre el módulo AmigaDos y el dispositivo Consola.

• Emisión de sonido: La producción de sonido es manejado exclusivamente por un único dispositivo, el de audio. El se encarga de controlar directamente el hardware para conseguir emitir sonidos sintetizador o digitalizados por los cuatro canales.

• Manejo de los puertos de comunicaciones: También los puertos paralelo y serie son controlados por sus respectivos dispositivos, proporcionando un interfaz entre el usuario y el exterior del ordenador. Podemos controlar la configuración de los puertos y enviar/recibir información a través de ellos.

• Manejo del teclado y ratón: Cuando pulsamos las teclas del teclado, o movemos el ratón o joystick, el dispositivo correspondiente se pone en marcha recibiendo el código de las teclas pulsadas o las coordenadas del puntero del ratón, por ejemplo. Estos códigos y coordenadas no son porcesados todavía, sino que son preparados para ser utilizados por otro dispositivo que combina las dos informaciones para producir lo que se llama eventos o sucesos. Estamos hablando del módulo llamado 'Input' o 'Dispositivo de entrada de datos0. Por ejemplo, algunos de los eventos que procesa son el cierre, cambio de tamaño y profundidad de las ventanas. Cuando nos situamos con el ratón sobre el gadget de cierre de ventana (o cualquier otro gadget) y pulsamos el botón izquierdo, el dispositivo lee la información, en este caso del puerto del ratón, y la envía al otro dispositivo 'Input'. Este a su vez, recoge los datos y avisará a otro módulo de que se ha producido un evento de tipo cerrar ventana, y que actúe en consecuencia y cierre esa determinada ventana (La librería intuition es la encargada de esta tarea).

• Manejo de los ficheros: El método más directo para observar como el S.O. maneja los ficheros es abrir una Shell y escribir comandos en ella. Un simple 'dir' es interpretado por la shell como un comando y es enviado al módulo AmigaDOS para que sea ejecutado como un proceso, e inmediatamente se creará una tarea manejada por el módulo 'Exec'. Cuando esto ocurra, se utilizaran varios dispositivos como el 'trackdisk' o el 'scsi' para leer el directorio de los ficheros contenidos en un disco o disco duro, y se enviará esta información a la shell, para que nos la presente por pantalla.

EN EL PRÓXIMO ARTÍCULO...

Hasta aquí hemos introducido el S.O. Ahora ya sabemos su forma general, y como se estructura internamente. Tenemos una idea global que nos permitirá en el próximo artículo abordar de una forma exhaustiva y profunda todo lo relacionado con las librerías, su composición, como se abren y cierran, como podemos construirnos una propia, como las maneja el S.O., etc. Incluiremos ejemplos en C que traten con ellas, y resumiremos las funciones más importantes que cada librería posee.

Avisamos de que para poder compilar nuestros ejemplos, son necesarios un compilador de C (¡como el que hemos incluído en el disco del mes de la revista!) y los ficheros de descripción llamados "Includes" de la versión 2.x o 3.x del sistema operativo. Estos ficheros son propiedad de Commodore, y al no tener licencia para distribuirlos nos ha sido imposible incluirlos en el disco. Para conseguirlos existen varias formas:

1. Comprarse un compilador comercial. Existe la versión 3.0 de DICE a la venta y la versión 6.5 del SAS C. Ambos incluyen todo lo necesario para poder programar de una forma profesional con un entorno multiventana, compilación y edición directa de uno o más fuentes, manejo automático de errores, debugger, ensamblador, documentación muy extensa de todas las funciones y utilidades, etc.

2. Ponerse en contacto con Commodore a través de CATS (ver la sección curso de C para más información).

3. Existe la posibilidad de que consigamos contactar con el autor del compilador de C DICE 3.0 y proponerle que nos envíe una licencia de uso colectiva. Contacta con nosotros si estás interesado en este tema.

Por último, recuerdo que ante cualquier duda, problema, crítica o simplemente comentario que se plantee, os podéis poner en contacto con la revista.