9. Controladores de dispositivo

9.1 Introducción

Nota: Documento por revisar

En este capítulo se tratan las formas en las que los dispositivos típicos se conectan al sistema operativo del QL. Como hemos podido apreciar en los primeros capítulos, el QL tiene un sistema de E/S redireccionable, bastante potente. Para que este sistema de E/S funcione igualmente bien con una gran variedad de dispositivos físicos, es necesario tener un mecanismo de interconexión eficaz. Este mecanismo de interconexión lo proporcionan los controladores de dispositivo.

El controlador de dispositivo se sitúa en medio de dos procesos. En una parte está el QL IOSS (subsistema de E/S). Este espera que el controlador de dispositivo abra y cierre los canales y mande o reciba datos por ellos. En la otra parte, el controlador de dispositivo debe ser capaz de controlar ciertas piezas de 'hardware'. El control se pasa normalmente siguiendo la interrupción de un dispositivo, o la interrupción de los 50/60 Hz del QL, o cuando lo invoca el planificador.

El controlador de dispositivo se puede considerar como un sistema de comunicación entre dos medios separados. El mediador de acceso, comunica con el IOSS. Se deben proporcionar tres puntos de entrada al IOSS. Uno para abrir un canal, uno para cerrarlo, y uno bidireccional que permite transferir datos entre el dispositivo y el IOSS. El otro mediador se llama el mediador físico, y su función esencial es el control del dispositivo físico y la comunicación de datos con él.

El mediador físico debe ser un dispositivo altamente especializado, ya que la mayoría de los dispositivos físicos son bastante similares. Sin embargo el procedimiento de interconexión del mediador de acceso es muy específico y debe seguir unas normas muy rígidas, independientemente del dispositivo que esté controlando.

El controlador de dispositivo debe mantener espacio en la RAM para almacenar cierto tipo de información. A cada controlador de dispositivo se le asigna un bloque de definición de controlador de dispositivo, que puede estar en el bloque de variables para los controladores de dispositivos integrados, o en otra parte de la memoria (con algunas restricciones en su localización) para los controladores adicionales. Este bloque de RAM está disponible como área de trabajo estática del controlador de dispositivo, y contiene información, como el número de canales abiertos a ese controlador, la dirección de estos canales (o un apuntador a una lista encadenada de canales - si el número puede ser infinito), el estado actual del dispositivo de E/S, etc. Este área es propiedad del controlador de dispositivo, y por lo tanto del sistema operativo del que forma parte.

Es posible abrir un mismo dispositivo por varios canales a la vez. En este caso, el controlador del dispositivo debe ser re-entrante. Lógicamente, si el controlador del dispositivo intenta mantener el estado de cada canal por sí mismo, se hará un verdadero lío. Por esta razón, cada canal asigna un bloque de definición de canal, que se crea al abrirlo con IO.OPEN (TRAP#2 D0=l), y que es propiedad del Job que lo ha creado.

Ahora se tratarán más en profundidad los conceptos básicos que acabamos de ver.

9.2 Bloques de definición de controlador de dispositivo

Los controladores de dispositivo se suelen conectar al sistema operativo cuando se enciende la máquina. Disponemos de una serie de TRAPS del gestor (TRAP#1 con D0=1A al 23), para poder hacerlo. No es imprescindible conectar los controladores de dispositivo al sistema operativo a tiempo de encendido - se pueden añadir después si se requieren. El gestor mantiene varias listas encadenadas, para distintas operaciones, que siguen el formato estándar que se vio en detalle en la sección 5.4.5.

Existen cinco listas encadenadas. Tres de ellas son para el mediador físico que se invoca por:

1.     interrupciones externas
2.     interrupciones de los 50/60Hz
3.     bucle del planificador

Como se describió en la sección 5.4.5, una lista encadenada se produce reservando dos palabras largas. La primera forma la conexión a la lista, la segunda debe ser la dirección del código del controlador del dispositivo físico. Estas dos palabras largas se encuentran normalmente al principio de un bloque de memoria. El resto de los bloques están disponibles para que las use por el controlador del dispositivo. Alguno de estos usos son: almacenamiento de indicadores, apuntadores, memoria intermedia, etc.

El sistema operativo pasa, del dispositivo físico al controlador, varias piezas de información útiles. Estas van en los registros del 68008 como sigue:

A6 y A7 deben ser preservadas por el controlador del dispositivo.

Para las llamadas del mediador de acceso, A3, A6 y A7 tienen el mismo significado, pero los otros registros son diferentes (ver 9.4).

A3 apunta a la dirección base del bloque de definición. Este se refiere a una definición de un controlador de dispositivo estándar (ver debajo). Sin embargo, es posible tener una definición no estándar diferente (por ejemplo, algunas direcciones de entrada y apuntadores de conexión se pueden eliminar). Si se usa una definición no estándar, A3 no tendrá un valor adecuado.

9.3 Mediador de acceso

Para inicializar el mediador de acceso, se debe conectar un bloque de memoria en el IOSS, mediante MT.LIOD (TRAP#l con D0=20). Este bloque de memoria debe estar en el área de procedimientos residentes o en el área común. Debe tener cuatro palabras de longitud, desde el principio del bloque.

El gestor usa la primera, para formar la lista encadenada, la segunda, tercera y cuarta palabras largas son las direcciones de entrada para entrada/salida, abrir y cerrar el canal. El resto del bloque se puede usar para almacenar apuntadores, memoria intermedia, etc.

El formato del bloque es:

Todas las llamadas del mediador de acceso se hacen en modo supervisor.

9.3.1 Abrir un canal

Cuando se hace una llamada para abrir un canal, A0 contiene un apuntador al nombre del dispositivo y D3 contiene una clave. En A3 está la base del bloque de definición del controlador del dispositivo. A6 apunta al área de variables del sistema y A7 contiene el apuntador a la pila del supervisor. Los registros D0 a D7 y A1 a A6 se pueden tratar como volátiles.

La secuencia a seguir para una operación de OPEN es:

- Decodificar el nombre del dispositivo
- Asignar un bloque de definición de canal y memoria intermedia en el área común
- Inicializar el bloque de definición de canal (excepto las 6 primeras palabras largas)
- Devolver la dirección del bloque de definición del canal en el registro A0.

Todos los canales son bidireccionales. Es responsabilidad del controlador del dispositivo, el detectar las operaciones ilegales. Cuando se hace OPEN a un canal, pueden ocurrir cuatro tipos comunes de error, que se pasan en el registro D0. ERR.NF significa que el nombre del dispositivo no ha sido reconocido. ERR.IU significa que el dispositivo de E/S está siendo usado por otro Job y no se puede compartir. ERR.BN significa que se ha reconocido el nombre del dispositivo pero es incorrecta parte de la información que se ha pasado. ERR.OM significa que todo es correcto, pero el bloque de definición de canal o la memoria intermedia no se pueden asignar, debido a falta de memoria.

9.3.2 Entrada y salida de un canal

La llamada de entrada/salida se realiza primero durante el TRAP de E/S. Si el TRAP ha sido especificado como de esperar hasta completarlo, la llamada se hace una vez cada bucle del planificador. Esta operación continúa hasta que se ha completado, o hasta que se cumpla el tiempo de espera.

A0 debe apuntar al bloque de definición de canal, antes de hacer la llamada de E/S. D0 define la operación requerida (es una clave de un octeto y el I0SS limpia los tres octetos superiores). En D1, D2, A1 y A2 se pasa información adicional. El registro D1 lo pone el IOSS a ceros para las operaciones de cadena (IO.FSTRG, IO.FLINE, IO.SSTRG, FS.HEADS, FS.HEADR, FS. LOAD y FS.SAVE). Si una operación no se completa, se deben poner a la salida los valores de D1 y A1 de modo que se puedan usar en los siguientes reintentos. Para ayudar en este proceso, se pone D3 a ceros en la primera entrada, pero se va modificando a -1 en la segunda y siguientes. D0, D2 y A2 mantienen sus valores originales a través del proceso.

D0 define siempre la operación, A3 apunta a la base del bloque de definición de controlador de dispositivo, A6 apunta al área de variables del sistema y A7 es el apuntador a la pila del supervisor.

Dentro del controlador de dispositivo, se pueden modificar los registros D2 a D7 y A2 a A6.

9.3.3 Cerrar un canal

Una operación de CLOSE de un canal comprueba que todo está limpio y después libera el espacio que fue asignado para el bloque de definición del canal y la memoria intermedia. Si quedan todavía algunos octetos que transmitir, no es posible liberar el espacio inmediatamente. En estos casos, el bloque será borrado en una llamada posterior del planificador, cuando los datos hayan sido transmitidos.

A la rutina de CLOSE se le pasa la dirección del bloque de definición de canal, en el registro A0. La base del bloque de definición de controlador de dispositivo se pasa en el registro A3. A6 apunta al área de variables del sistema y A7 es el apuntador a la pila del supervisor. Los registros D1 a D3 y A0 a A3 pueden ser modificados. En D0 se debe pasar el código de error. Normalmente este debe ser cero (ej. sin errores) ya que la mayor parte del sistema asume que el CLOSE nunca falla.

9.4 Mediador físico

Como ya mencionamos en la sección 9.1, el mediador físico tiene como función el interconectar el controlador del dispositivo y el 'hardware' externo. Esta interconexión se puede realizar en cualquiera de los siguientes eventos:

1. Interrupciones externas

Las interrupciones externas son generadas por dispositivos externos particulares. Si un controlador de dispositivo espera interrupciones externas mientras se está ejecutando, primero debe comprobar el estado del 'hardware' para ver si la interrupción la ha mandado él. Si la interrupción no viene del dispositivo correcto, se debe hacer un retorno mediante la instrucción RTS. Si la interrupción es para él, se debe servir al 'hardware' y limpiar la fuente de la interrupción. Se debe retornar a la fuente de la interrupción mediante una instrucción RTS. Las operaciones atómicas (como las llamadas del mediador de acceso al mismo controlador) pueden ser interrumpidas por esta interrupción.

2. Interrupciones de 50/60Hz

Esta interrupción solo debe ser usada para operaciones de temporización crítica, u operaciones que no se deban mantener por periodos largos. Un ejemplo de operación de temporización crítica puede ser el incremento de un registro para controlar el tiempo, o la generación de envolventes de sonido. Si el 'hardware' externo no puede interrumpir al sistema cuando necesita servicio, se puede usar la interrupción de 50/60 Hz para comprobar si un dispositivo necesita servicio. Las operaciones atómicas (como las llamadas del mediador de acceso al mismo controlador) pueden ser interrumpidas por esta interrupción.

3. Bucle del planificador

Las llamadas del bucle del planificador llegan a intervalos irregulares (dependiendo de la carga de trabajo del sistema), por lo que no pueden usar este bucle las operaciones que que deban ser procesadas inmediatamente. Las operaciones atómicas no pueden ser interrumpidas por el planificador, por lo que las operaciones de asignación y liberación de memoria se pueden realizar, para mayor seguridad, con rutinas que se ejecuten fuera del planificador.

Notas generales sobre el mediador físico.

El mediador físico permite trasferir datos dentro o fuera de las colas o ejecutar funciones de control asíncronas con un Job que requiera E/S. Todas las rutinas del mediador físico son llamadas en modo supervisor, de forma que todo está en condiciones para que puedan inhabilitar las interrupciones. Cualquier error debe ser tratado mediante un indicador que entienda el mediador de acceso. Sin embargo, es posible usar las rutinas de utilidad UT.ERR y UT.MTEXT con A0=0. Después se hará un intento de escribir un mensaje al canal 0, o, si esto falla, al canal 1. El mensaje aparecerá en uno de estos canales si no están esperando por entrada. Si ambos están esperando por entrada, no aparecerá ningún mensaje. Las rutinas de manejo de colas han sido diseñadas para que puedan trasferir datos desde/hacia una cola asíncronamente.

9.5 Decodificación del nombre de dispositivo

La rutina de utilidad IO.NAME (vector $122) es muy útil para ayudarnos en la decodificación de nombres de dispositivos. Realiza dos operaciones, comprobar el nombre del dispositivo y evaluar cualquier parámetro opcional.

El nombre completo del dispositivo contiene cuatro componentes:

Cuando se llama a IO.NAME, A0 debe contener un apuntador al nombre real del dispositivo. A3 debe contener un apuntador a un bloque de memoria suficientemente grande para almacenar los valores de los parámetros. Si la rutina se ejecuta satisfactoriamente, el bloque se llenará con los parámetros dados o los asignados por defecto.

IO.NAME tiene tres posibles retornos:

La descripción del nombre de dispositivo comienza 6 octetos después de la llamada.

9.5.1 Descripción del nombre del dispositivo

La descripción está en la siguiente forma:

- Número de caracteres en el nombre, caracteres del nombre
- Número de parámetros

Por cada parámetro uno de:

- Espacio + separadores, valor por defecto (numérico)
- Número negativo, valor por defecto (número, no separ)
- Número de códigos, lista de códigos ASCII.

Todos los ítems se definen como palabras y todas las letras deben ir en mayúsculas. Ya que los códigos ASCII de los caracteres caben realmente en octetos, cualquier octeto impar al final, se rellena con cero. Por ejemplo:

DC.W  'ABC'

aparece en memoria así:

palabra 1   $00   03
palabra 2   $41   42
palabra 3   $43   00

Por cada parámetro numérico de la descripción, la rutina devolverá el valor dado o el asignado por defecto. Por cada lista de códigos en la descripción, la rutina devolverá la posición del código en la lista o cero.

Ejemplos

La descripción CON es:

La descripción de SER es:

9.6 Asignación de memoria

Es esencial que los controladores del mediador de acceso sean totalmente reentrantes. Esto significa que la información especifica del canal debe almacenarse en el bloque de definición de canal y no en el bloque de definición del controlador del dispositivo. Los bloques de definición de canal requieren dejar 6 palabras largas al principio para que las use el IOSS. El resto del espacio en el bloque lo puede usar el controlador de dispositivo.

El controlador del mediador físico nunca debe asignar ni liberar recursos de la máquina, a menos que lo haga en una llamada al planificador.

El espacio se debe asignar siempre en el área común. Se puede usar para ello la rutina MM.ALCHP. Este espacio se puede liberar con la rutina MM.RECHP.

9.7 Colas de E/S

Hay cinco rutinas residentes para el manejo de colas. Estas controlan la entrada y salida de datos de la cola, y comprueban el contenido de los bloques de definición, y las condiciones de fin de fichero. IO.QSET pone los apuntadores de las colas. IO.QIN pone un octeto en una cola. IO.QOUT saca un octeto de una cola. IO.QEOF pone el indicador de fin de fichero IO.TEST comprueba si hay algo en la cola, devuelve el espacio libre y el valor del siguiente octeto que va a sacar sin quitarlo de la cola.

Las colas se definen por bloques de 4 palabras largas al principio. El octeto más significativo de la primera palabra larga la usan las rutinas de las colas para identificar el fin del fichero. IO.QSET limpia la palabra larga completa. El resto (ej. sin bit más significativo) se puede usar para el controlador de dispositivos, para conectar colas, etc.

La longitud usable de una cola es un octeto menos de la longitud real. El mínimo espacio ocupado por una cola y su cabecera es por la tanto de 18 octetos.

9.8 E/S serie simple

La E/S serie simple se puede manejar con IO.SERQ. Para esta rutina, la séptima y octava palabra larga en el bloque de definición de canal deben apuntar a las colas de entrada y salida. Si una de ellas está prohibida, el apuntador correspondiente se pondrá a cero. Nos devolverá el error ERR.BP para las acciones indefinidas. Ver la descripción de IO.SERQ en el capitulo 8 para más detalles.

En los casos en que las operaciones de entrada y salida no sean tan simples se puede llamar a la rutina IO.SERIO. A la instrucción de llamada le deben seguir tres palabras largas, que son las direcciones de entrada para:

1. Comprobación de entrada pendiente (D1=siguiente octeto)
2. Tomar un octeto (octeto en D1)
3. Mandar un octeto (octeto en D1)

9.9 Controladores de dispositivo de directorio

Los controladores de dispositivos de directorio son más potentes en sus aplicaciones que los controladores de dispositivo puros. Los normales son responsables de las comunicaciones con otro dispositivo. Los de dispositivo de directorio son responsables de las comunicaciones con ficheros particulares dentro del dispositivo, como un disco duro winchester. El IOSS tiene un rango de operaciones extendido para estos controladores.

9.9.1 Bloque de definición de controlador de directorio

Los bloques de definición para controladores de dispositivo de directorio son similares a los de los controladores de dispositivos. Sin embargo, hay tres partes; el bloque de conexión del controlador de directorio (uno por controlador de directorio), el bloque de definición física (uno por controlador) y el bloque de definición de canal. El IOSS asigna los dos últimos.

El bloque de conexión

La forma estándar es una versión extendida de la que usan los controladores de dispositivo. La conexión del mediador de acceso es por lo menos de 10 palabras de longitud, y tiene el siguiente formato estándar:

9.9.2 Mediador de acceso de controlador de directorio

Como en los controladores de dispositivo, el mediador de acceso debe abrir, cerrar y sacar y recibir datos de los ficheros. Las rutinas de CLOSE y entrada/salida son las mismas que las de los controladores de dispositivo. Refiérase a las secciones 9.3.2 y 9.3.3 para más detalles. Sin embargo, abrir canales en un controlador de dispositivo de directorio es un poco más complejo.

Abriendo un canal

Antes de llamar a la rutina de abrir un canal, se deben asignar el bloque de definición de canal y el bloque de definición física. En este punto, el IOSS debe haber llenado parcialmente estos bloques. A la entrada de la rutina de OPEN, A0 apuntará al bloque de definición de canal y A1 al bloque de definición física. A3 apuntará a la base del bloque de conexión. El bloque de definición física puede haber sido asignado ya. Los ficheros se componen de bloques de 512 octetos de longitud cada uno. La posición real de un octeto es por lo tanto 512*número de bloque+número de octeto.

Bloque de definición de canal

Cabecera de definición de canal para todos los canales

Bloque de definición de canal del sistema de ficheros

La longitud viene determinada por la conexión del mediador de acceso.

* Inicialmente los bloques están llenos de ceros excepto los marcados con * que los llena el IOSS.

+ La rutina de OPEN no es llamada para abrir un fichero compartido a más de un canal. En este caso, FS.NBYTE se pone a $40 y la información fija se copia desde el primer canal abierto al fichero.

El ID de la unidad es un índice a la tabla de bloques de definición física, empezando en $100 desde la base de las de variables del sistema.

El borrado de ficheros es parte de la operación de apertura de ficheros. Los dos procesos se distinguen por la clave de acceso que es negativa para el borrado. Los bloques de definición se asignan de la forma usual para apertura de ficheros, pero el IOSS libera el bloque de definición del canal a su retorno. El bloque de definición de canal es liberado también por el IOSS si devuelve algún código de error en el registro D0.

9.10 Bloques dependientes

Toda la interacción con los dispositivos de almacenamiento se lleva a cabo a través de la memoria del QL, usándola como memoria intermedia. Este proceso pasa totalmente inadvertido al usuario. Si se accede a un fichero en microdrive, algunos sectores se leerán en memoria. Si se reescribe un sector al microdrive, no es necesario que se haga justo después del salvado, los datos pueden permanecer en memoria algún tiempo hasta que se vuelcan al dispositivo. A medida que el espacio usado por los programas transitorios, procedimientos residentes y el área común, aumenta, el área de bloques dependientes disminuye de tamaño.

El espacio en los bloques dependientes está definido en la tabla de bloques dependientes. Esta tabla es de tamaño variable, y depende de la cantidad de memoria disponible. Hay tres apuntadores a la tabla de bloques dependientes.

Cada entrada de la tabla tiene 8 octetos de longitud. El sistema operativo usa solamente el primer octeto como octeto de estado. Los otros octetos no son usados por el sistema operativo.

Ya que la asignación de bloques dependientes, es una forma muy simple de asignar memoria, sólo se debe realizar con llamadas al mediador de acceso o al bucle del planificador.

Será necesario buscar un bloque dependiente para usarlo como memoria intermedia de un bloque de fichero. Solamente se pueden usar los bloques vacíos o las representaciones auténticas. Cuando se asigna un bloque nuevo a un fichero, SV.BTPNT debe ser modificado.

¡No asuma nunca que los bloques que fueron asignados en una llamada están asignados aún en la siguiente, porque pueden no estarlo!. FS.CBLOK es una variable de aviso solamente. Comprueba siempre la entrada de la tabla de bloques dependientes, antes de proceder.

Algunas veces el gestor de memoria requiere el espacio asignado a un bloque actualizado o esperando por lectura o verificación. Si ocurre esto, la rutina dependiente de forzado es llamada para convertirla en una copia auténtica. La rutina no comprueba si el bloque es una copia auténtica,

pero inicia el proceso que lo hace. A la entrada de la rutina dependiente de forzado, A1 apunta al bloque depen­diente, A2 apunta al de definición física y A3 a la base del bloque de conexión (definición de controlador). Los registros D0 a D3 y A0 a A4 pueden ser alterados si se desea.

9.11 Un ejemplo con un controlador de impresora paralela

9.11.1 Introducción

Esta sección ilustra muchos de los puntos que se han explicado en las partes anteriores de este capitulo. Un ejemplo completo de un controlador de dispositivo para construir un interfaces Centronics estándar para impresora. El diagrama completo del circuito está en el Apéndice U.

Este controlador de dispositivo ha sido diseñado para contenerlo en una ROM en una tarjeta periférica. Esta tarjeta (con una ROM) se conecta al QL. En el momento de encender el ordenador. aparecerá en la pantalla el mensaje 'Interface Centronics Simple'. Desde este momento, existirá un nuevo canal llamado 'PAR'. Para listar un fichero de microdrive en la impresora, sólo debe teclear:

COPY MDV1_textfile TO PAR

Ya que es un simple ejemplo de controlador de dispositivo, no se ha previsto una memoria intermedia de impresora, por lo que el controlador intentará sacar un octeto y devolverá un 'ERR.NC' si no se puede mandar (debido a que a impresora está ocupada). Un controlador más sofisticado puede operar una memoria intermedia y mandar interrupciones generadas por el circuito de interfaces.

9.11.2 El programa controlador de dispositivo

*

* Interfaces Paralelo Centronics (sin interrupciones)

*

*

*

BASE

*

INIT

*

*

INIT–EXIT

*

*

OPEN

ALCHP

CLOSE

IO

*

*

OUT–BYTE

EXIT

9.11.3 Funcionamiento del programa

Para entender cómo funciona el controlador de dispositivo, es importante comprender cómo aparece el dispositivo físico en el mapa de memoria del QL. La puerta de salida de 8 bits a la impresora está situada en la posición $0800, desde la dirección base del periférico. La salida de 'strobe' está en el desplazamiento $1000, y la entrada 'BUSY' en el $1800.

Para los que no están familiarizados con el mecanismo de decodificación de las direcciones de periféricos (Apéndice F), aquí le damos una pequeña explicación. Se pueden conectar hasta 16 tarjetas periféricas en el QL. A cada una de estas se le asignan 16K octetos de memoria en la parte superior del mapa de memoria. La dirección base particular de cada tarjeta viene determinada por su posición. Por lo tanto, todas las direcciones de periféricos vienen especificadas en relación con la dirección base de la tarjeta. Cuando se enciende el QL, se comprueba si existe la identificación $4AFB0001 al principio de la dirección de cada periférico. Si se encuentra el código, asume que hay una ROM presente, conteniendo el controlador del dispositivo, funciones y/o procedimientos.

Para indicar al QDOS que la ROM contiene un controlador de dispositivo, debe tener unos datos de reconocimiento al principio (ver Apéndice C). Los datos que aparecen desde la etiqueta 'BASE' en adelante se deben colocar en los primeros octetos. La primera palabra larga identifica que es una ROM y no 'espacio libre'. La palabra que sigue indica que no hay procedimientos o funciones en esta ROM. La siguiente palabra apunta a la rutina de iniciación de la ROM, que debe ser ejecutada una vez, a tiempo de encendido. Finalmente, la longitud del nombre del controlador del dispositivo, suponiendo que lo tenga.

La rutina de iniciación 'INIT' asigna espacio en el área común para los bloques de conexión, rellena las direcciones y los datos importantes y encadena el bloque en la lista de controladores de E/S. A0 y A3 se salvan a la entrada de INIT, y son restaurados a la salida, ya que se modifican en la rutina.

Como en los controladores de dispositivo estándar, se proporcionan las tres rutinas de OPEN, CLOSE y entrada/salida.

OPEN

Abrir un canal consta de dos operaciones principales. Lo primero que hay que hacer es decodificar el nombre del canal. En este caso se ha usado IO.NAME para simplificarlo. Después, una vez que se ha reconocido el nombre, se asignan $18 octetos en el área común. Será necesario asignar más para ciertas aplicaciones, pero aquí usamos el mínimo. El canal está ahora abierto.

CLOSE

Cerrar un canal es muy sencillo. La operación consiste en eliminar el espacio asignado en el área común. En este caso se ha usado MM.ALCHP para hacerlo.

Entrada/Salida

Esta rutina usa las direcciones almacenadas desde $28(A3) en adelante, que apuntan a las rutinas de comprobación de entrada pendiente, recoger un octeto y mandar un octeto, respectivamente. La rutina de manejo general de cadenas, IO.SERIO, se usa para manejar la ES. La mayoría de las operaciones de E/S son válidas, excepto IO.SSTRG (ésta trata las operaciones con ficheros, pero no es importante para la impresora).

En nuestro controlador, las rutinas de entrada pendiente y de recoger un octeto devuelven el error 'Parámetros inválidos'. Sólo es válida la rutina de mandar un octeto a la impresora (OUT_BYTE)

OUT_BYTE comprueba, primero, si la impresora está ocupada (BUSY); si lo está, devuelve un error ERR.NC. Si la impresora no está ocupada, se escribe un octeto de datos. Después lo manda a la impresora y pone el STROBE durante >500ns. Después de esta secuencia de operaciones, los datos han sido transferidos a la impresora.