archivo

Sistema

HOTKEYS es una extensión que forma parte de “Pointer Environment” (PE), el entorno de ventanas creado por Tony Tebby para el Sinclair QL. Podríamos definirlo como un sistema para declarar combinaciones de teclas que cuando se pulsan dan lugar a una acción que es independiente de la tarea que se está realizando.

Lo primero que tenemos que tener presente es que, para poder disfrutar de las facilidades de HOTKEYS en nuestro QL, necesitamos cargar en nuestro sistema el “Pointer Environment” completo. Este entorno de ventanas consta específicamente de tres módulos residentes PTR_GEN, WMAN y HOT_REXT. Otro componente que podríamos catalogar de indispensable en el QL sería también el Toolkit 2, el cual viene de una manera u otra en la mayoría de los QL que incorporan expansiones de disquetera y ampliaciones RAM.

El programa más simple para cargar en nuestro QL un entorno mínimo para empezar a trabajar con HOTKEYS sería el siguiente:

100 TK2_EXT : REMark en algunos sistemas esta línea es esencial
110 LRESPR FLP1_PTR_GEN
120 LRESPR FLP1_WMAN
130 LRESPR FLP1_HOT_REXT
140 HOT_GO

Comentemos brevemente el las líneas del programa SuperBASIC anterior.

En la línea 100 se ejecuta el comando TK2_EXT que es usado para activar el Toolkit 2 en algunos sistemas. Esto nos permitirá usar a su vez el comando LRESPR, empleado en las líneas siguientes para cargar cómodamente el resto de extensiones necesarias para usar el PE. Si no tuviéramos el Toolkit 2 (que es el que aporta el comando LRESPR) tendríamos que cargar el resto de módulos averiguando primero el tamaños del archivos, y con los comandos LBYTES y CALL cargar cada uno de los módulos en modo residente. LRESPR nos ahorra esfuerzo ya que nos permite cargar las extensiones que necesitemos de una forma más automática.

En la línea 110 cargamos el primer módulo del PE llamado PTR_GEN. Este módulo controla la interfaz de puntero; una flecha en pantalla a modo de cursor que es controlada por un ratón o por las teclas del cursor del teclado. Al igual que otros sistemas GUI, podemos indicarle al ordenador lo que debe hacer desplazando el puntero hasta los “comandos” representados en la pantalla y haciendo “clic” sobre ellos.

El ratón en los QL tiene generalmente 2 botones. La presión sobre el botón izquierdo se llama HIT, y la presión sobre el botón derecho se llama DO. Esas acciones (HIT y DO) tienen equivalentes también en el teclado. Como hemos mencionado anteriormente el puntero se puede mover con las teclas del cursor del teclado, HIT se ejecuta con la barra espaciadora y la acción DO con la tecla ENTER.

WMAN es una abreviatura de “Window Manager” (el gestor de ventanas). Este gestor de ventanas es un sistema mediante el cual se proporciona un aspecto ‘estandarizado’ a la apariencia y funcionamiento de los menús, desplazamiento de las ventanas, etc. En la línea 120 de nuestro ejemplo cargamos WMAN con el comento LRESPR FLP1_WMAN.

HOT_REXT es la parte que controla las “Hotkeys”, las teclas de acceso rápido, que formalmente se denomina “Hotkey System II”. En nuestro ejemplo cargamos este módulo en la línea 130 con LRESPR FLP1_HOT_REXT, lo cual ejecuta un pequeño Job (o tarea residente) llamado Hotkey el cual se ocupa de controlar teclas de acceso rápido.

El comando HOT_GO de la línea 140 es el encargado de activar las teclas de acceso rápido (Hotkeys). En otras palabras, una vez que un comando HOT_GO ha sido ejecutado, las teclas de acceso rápido que se hayan programado comenzarán a funcionar.

Existe también un comando relacionado llamado HOT_STOP el cual desactiva las teclas de acceso rápido que se hayan definido. Es importante recordar este comando porque hay ocasiones en las que no podemos cargar extensiones adicionales mientras Hotkey está funcionando y una forma de hacerlo es desactivando temporalmente las Hotkeys con HOT_STOP y luego volverlo a activar una vez cargadas las extensiones necesarias.

Otra cosa importante a tener en cuenta es el uso de CTRL C (la pulsación conjunta de las teclas CTRL y la letra C). Este combinación de teclas permite conmutar el foco entre varios programas que están ejecutándose al mismo tiempo. Esta es una de las formas más habituales de conmutar entre los distintos programas que están ejecutándose en nuestro QL.

Para comprender la importancia de la Hotkeys en un sistema de la época del QL pongamos un ejemplo. Supongamos que estamos tecleando algo en un procesador de textos y queremos comprobar algo en nuestra base de datos sin tener que salir del procesador de textos. En un ordenador personal de principios de los años 80, nosotros tendríamos que grabar en un fichero el trabajo que estuviéramos haciendo en nuestro procesador de textos, a continuación salir del procesador, arrancar la base de datos, chequear la información, salir del sistema de base de datos y volver a arrancar el procesador de textos con el fichero en el que estuviéramos trabajando.

Pero en un QL con su multitarea y el Hotkeys, las cosas se podrían hacer de otra manera.

Supongamos que hemos definido una combinación de teclas como la vía para arrancar un programa, sin tener que parar el programa actual sobre el cual estamos trabajado. Más aún, si ese segundo programa ya estuviera en ejecución, nuestra combinación de teclas provocaría que se activara ese programa que aún está en memoria. Luego, mediante otra combinación de teclas (Hotkeys) que también hayamos definido, podríamos regresar al primer programa en el que estábamos anteriormente.

Todo esto puede sonar muy complicado al principio, pero podemos acostumbrarnos rápidamente después de verlo en acción.

Este es el principio básico detrás de las Hotkeys: definimos teclas para realizar “acciones”. Independientemente de lo que estábamos haciendo, estas teclas permiten que hagamos algo más al instante sin tener que pasar por la molestia de grabar el programa actual, salir de él e ir al SuperBASIC, teclear comandos para ejecutar otras acciones y así sucesivamente. Lo bueno de este sistema es que una vez que hayamos configurado la pulsación de una determinada acción según nuestras necesidades, podemos ir y definirlas en el programa de arranque de nuestro QL (boot) para que se ejecuten cada vez que arrancáramos el sistema.

En la definición de Hotkey anterior hemos hecho referencia al término “acciones”, pero ¿Qué son exactamente esas acciones?

Las acciones pueden ser:
– Cargar un programa en memoria para iniciarlo de forma rápida posteriormente.
– Cargar un programa desde disco.
– Seleccionar un programa (saltar directamente a él desde otro programa)
– Relleno de texto, o lo que sea, en un búfer especial (como una especie de portapapeles) para pasar en otro programa
– Enviar comandos al SuperBASIC
– Listar las teclas que se han definido
– Activar o desactivar definición de teclas individuales

Exploraremos esta acciones a medida que avancemos en el tema.

Las Hotkeys se definen como una pulsación de varias teclas donde se usa siempre la tecla ALT junto con otra tecla. Esto no es nuevo en el QL y de hecho el Toolkit II tiene algo muy parecido llamado ALTEKEYs. Veamos cual es la diferencia mediante un ejemplo sencillo.

Supongamos que hemos definido un ALT key del Toolkit II para cargar un programa llamado MIPROGRAMA_BAS desde la unidad de disco flp1_. Para ello utilizaremos el siguiente comando:

ALTKEY 'a','LOAD FLP1_MIPROGRAMA_BAS'

Bien, supongamos que estamos en SuperBASIC y pulsamos ALT junto con la tecla ‘a’. Efectivamente, aparecerá en el canal #0 (area de comando en la zona inferior de la pantalla) la orden LOAD FLP1_MIPROGRAMA_BAS. Pero supongamos que estamos editando un documento con el procesador de textos Quill, ¡vaya …!, ahora aparece LOAD FLP1_MIPROGRAMA_BAS como parte del documento que estábamos editando y esto no es lo que queremos. Tendríamos que regresar al SuperBASIC para que este altkey sea de utilidad.

El sistema HOTKEY nos permite hacer esto mucho mejor. Por ejemplo, con el comando HOT_CMD de HOTKEY podemos definir una combinación de teclas para indicarle al ordenador que queremos un comando destinado al SuperBASIC. Esto nos aseguraría que el control del ordenador “salta” al BASIC primero y luego ejecutal el comando por nosotros. El proceso de saltar al BASIC o a otro programa se conoce como “PICKING” en la terminología del sistma de Entorno de Ventanas del QL (PE). Esto evitaría el incoveniente de ALTKEY que hemos mencionado anteriormente.

Así podemos ver que el sistema HOTEKY nos da más versatilidad y potencia que el sistema ALTKEY usado por el Toolkit II.

Podemos elegir cualquier tecla a la hora de definir una acción con HOTEKY pero hay algunas teclas reservadas que deberíamos evitar.

Las letras y números son buenos candidatos. Las teclas de función se pueden definir también pero son más difíciles de recordar. Entre las teclas a evitar están la tecla ENTER (ALT ENTER tiene un significado especial para HOTKEY, nos recupera la última línea de ordenes que hemos tecleado), las teclas de cursor, la tecla CAPS LOCK y la telca TAB. Tampoco es buena idea usar las teclas de apóstrofe o las teclas de símbolos (por ejemplo \).

¿Cómo definir combinaciones de teclas y acciones?

Veamos ahora cómo definir combinaciones de teclas y sus correspondientes acciones.

Los comandos para definir HOTEKYs están incluidos como extensiones SuperBASIC para hacer uso de ellos. La mayoría son funciones en lugar de comandos, esto significa que al ejecutar esas funciones nos devolverá un valor de retorno el cual nos indica si todo se ha ejecutado bien o si ha habido algún error.

Por ejemplo, ejecuta los siguiente desde la línea de comandos SuperBASIC:

PRINT HOT_CMD('a','LOAD flp1_MIPROGRAMA_bas')

Esto imprime el número 0 si todo ha ido bien en la definición del HOTEKY. Si ha habido algún error entonces la función retornará un valor distinto de 0 que representa al código de error, por ejemplo “In Use” error (-9).

Existe un pequeño comando para manejar esos números de retorno pasados por la función que define el HOTEKY, llamado ERT, que significa Error ReporT. Si todo ha ido bien no hace nada, pero si algo ha fallado ese comando emite un sonido o nos da un mensaje descriptivo del error. Un ejemplo de cómo usarlo sería el siguiente:

ERT HOT_CMD('a','LOAD flp1_MIPROGRAMA_bas')

El primer parámetro de la función HOT_CMD define la tecla a la cual será asociada el comando. Presionando la tecla ALT junto con esa tecla (en nuestro ejemplo la tecla 'a') se ejecutará el comando especificado en el segundo parámetro (en el ejemplo, 'LOAD flp1_MIPROGRAMA_bas'). Un aspecto importante a tener en cuanta es que HOTEKY es sensible a las mayúsculas y minúsculas. Se puede definir una acción distinta para la tecla en mayúscula con lo cual tendremos dos definiciones para la misma tecla, pero existen particularidades y ciertas reglas en su uso.

Si defines una HOTEKEY con una tecla en minúscula y no existe otra definición para esa tecla en mayúsculas entonces ambas teclas provocarán en mismo resultado (en el ejemplo anterior ALT a , SHIFT ALT a , o ALT A producirán el mismo efecto).

Los usuarios QL suelen aplicar patrones en la definición de las teclas que resultan útiles.

Por ejemplo, para acciones que involucren la carga o la selección (picking) de programa:

a) usa teclas en mayúsculas para la carga de programa.
b) usa la tecla en minúscula para la selección de programa.

Esto parece lógico, la carga de un programa desde disco es una acción típicamente menos común durante una sesión de trabajo, así usamos las teclas SHIFT ALT y la tecla deseada (tenemos que pulsar tres teclas). Sin embargo, una vez cargado los programas en memoria podría ser muy habitual conmutar entre ellos con una combinación más simple de teclas, la tecla ALT y la tecla deseada (sólo pulsamos dos teclas).

Bien, veamos ahora cómo cargar y seleccionar programas.

Hay varias formas de cargar un programa. Puede cargarse en la memoria y posteriormente ejecutarlo desde la memoria. Esto es muy útil en sistemas sin disco duro ya que podemos para evitar tener que insertar su disquete cada vez que necesite iniciar cualquier programa frecuente y que no esté disponible en el disquete en esos momentos. Sin embargo, siendo muy útil para los programas de uso común, nos ata un poco en cuanto al uso óptimo de la memoria. El más simple de entender es el comando que simplemente carga un programa desde el sistema de almacenamiento (un disquete por ejemplo). Asumiré que mi programa se llama PROGRAM_EXE en este ejemplo:

ERT HOT_LOAD('p','flp1_program_exe')

Cuando mantienes presionada la tecla ALT y pulsas la tecla p, el sistema intenta cargar PROGRAM_EXE desde FLP1_. Sencillo. Pero, de nuevo, hay un par de puntos menores a tener en cuenta.

He puesto el texto entre comillas en el ejemplo anterior, pero en la mayoría de los casos, podría haberse escrito los parámetros del comando de esta forma:

ERT HOT_LOAD(p,flp1_program_exe)

En caso de duda, usa las comillas. Además, el nombre de archivo del programa está escrito en minúsculas, no importa ¡el QL maneja los nombres de archivo en mayúsculas y minúsculas! Ten en cuenta que si omites el nombre de la unidad, HOTKEY intentarán agregar el nombre de la unidad predeterminada por DATA_USE o PROG_USE (las unidades predeterminadas de Toolkit 2 para datos y programas).

Con HOTKEY hay dos extensiones para cargar programas en la memoria para que, posteriormente, puedan iniciarse rápidamente sin tener que tener tus discos en las unidades (esto es bastante similar en principio a usar RESPR o LRESPR para cargar extensiones SuperBasic).

Las dos extensiones son: HOT_RES y HOT_CHP. ¡Ahora las cosas se vuelven un poco más complejas! De hecho, hay otras variaciones llamadas HOT_RES1, HOT_CHP1 y HOT_LOAD1 para casos especiales en los que no te atreves a ejecutar dos copias del mismo programa al mismo tiempo. (A tener en cuenta que en QDOS podrían haber programas que se modifican a sí mismos cuando se cargan en memoria, lo cual podría tener efectos no deseados. Ignoraremos esto por ahora, pero ten en cuenta que existen razones para estas variantes del mismo comando).

HOT_RES se utiliza para cargar programas RESIDENTES. Eso significa que se cargan en la memoria para que posteriormente podamos iniciarlos rápidamente (una o más copias de ellos). Este comando tiene un problema: si hay otros programas ejecutándose o el Job del HOTKEY está activo, este comando podría no funcionar. En estos casos se debe utilizar HOT_CHP. En algunas versiones del sistema HOTKEY, la función HOT_RES parece convertirse automáticamente en HOT_CHP cuando sucede este problema.

¿Cuándo debes utilizar HOT_RES o HOT_CHP en lugar de HOT_LOAD?

Fácil. Reserva el uso de HOT_RES o HOT_CHP para los programas que utilizas con más frecuencia para evitar tener que insertar sus disquetes cada vez que inicies una copia. HOT_LOAD está bien para programas usados ocasionalmente en los que no quieres que acaparen memoria todo el tiempo mientras están cargados de forma residentes.

La secuencia real de eventos cuando se emite un comando HOT_RES o HOT_CHP es la siguiente:

1. Cuando el sistema interpreta el comando, agrega el programa pasado como parámtro al sistema de teclas de acceso directo. Esto significa que, en esencia, cuando se ejecuta la línea que define la tecla de acceso directo, se busca el programa y se carga en la memoria.

2. Cuando más tarde se pulsa la tecla de acceso directo definida como HOT_CHP o HOT_RES, busca el programa en la memoria e intenta iniciar su ejecución.

HOT_LOAD es esencialmente sólo el equivalente del paso (2) – sólo carga el programa nombrado cuando se pulsan las teclas indicadas, en lugar de almacenar una copia en la memoria. Es importante entender la diferencia entre estos comandos. HOT_LOAD iniciará un programa desde el disco sólo cuando se lo indicas. HOT_CHP y HOT_RES harán inmediatamente una copia del programa desde la unidad de almacenamiento a la memoria cuando se definan sus parámetros (tecla de acceso y nombre del programa). Posteriormente, al pulsar la tecla definida por HOT_RES o HOT_CHP, se ejecuta una copia del programa ya cargado en memoria. De hecho, es bastante inteligente, si usas HOT_CHP o HOT_RES, sólo una copia del programa se mantiene en memoria incluso si tiene dos de esos programas en ejecución. Es bastante complejo de explicar, pero básicamente los programas definidos como ‘puros’ pueden tener más de una instancia de sí mismos ejecutándose al mismo tiempo, aunque de hecho sólo hay una copia en la memoria – ¡el sistema está siendo bastante inteligente al ejecutar más de una instancia del mismo código a partir de una sola copia de él!

Estos programas ‘puros’ incluyen a Quill, Archive, Abacus, Easel y los programas QPAC1, por ejemplo. Pero hay otros programas (llamados ‘no puros’) que modifican su propio código de tal manera que no es prudente hacer que un programa en memoria se ejecute como si se tratara de dos instancias separadas. En caso de que una copia modificara su propio código al mismo tiempo que la otra instancia de sí misma intentara hacer algo podría producir el caos. Los programas compilados por Turbo entran en esta categoría – tiene que usar las versiones HOT_CHP1 y HOT_RES1 de estos comandos para asegurarse de que hay el mismo número de copias físicas del programa en la memoria como instancias de si mismo en ejecución. (Esto no es fácil de explicar pero espero que puedas seguirlo).

HOT_LOAD no hace esa distinción. Siempre carga una copia del disco y la ejecuta cuando la necesita. Si tienes problemas para entender HOT_CHP y HOT_RES y sus variaciones, ignóralos, usa HOT_LOAD solo por ahora hasta que entiendas estos conceptos.

Una vez que un programa se en memoria y se está ejecutando, se necesita una forma de saltar a y desde él. Supongamos que nuestro pequeño programa de ejemplo llamado PROGRAM_EXE tiene un nombre simplemente “PROGRAM” (es decir, el nombre que muestra cuando se está ejecutando y que emite el comando JOBS desde BASIC). Hay una función llamada HOT_PICK cuya función es encontrar el programa llamado, y traerlo para que sea el trabajo (o ‘Job’) actual. Esta acción se llama PICKING.

Por ejemplo:

ERT HOT_PICK('a','PROGRAM')

Una vez ejecutado el comando anterior, cuando presiones ALT a, el sistema busca un programa con ese nombre que se esté ejecutando en la memoria y lo “activa” para que puedas trabajar en él.

Todo esto está muy bien, pero como de costumbre con las teclas de acceso rápido (HOTKEYS), la historia no es tan simple.

Los nombres de los “Jobs” (de las tareas o trabajos en QDos) no son simples y pueden no ser obvios, por lo que el sistema HOTKEYS ofrece otra opción relacionada con esos nombres de “Jobs”.

Para elegir un “Job” o incluso eliminarlo, es posible que necesites saber su nombre. Muchas veces, el nombre del “Job” es igual al nombre del programa que cargaste, pero esto no siempre es así; ¡peor aún, algunos programas cambian sus propios nombres mientras se ejecutan por razones que se nos escapan a la mayoría de nosotros!

Para resolver esto, puedes usar la siguiente opción en algunos comandos HOTKEYS para establecer los nombres que desees darle al “Job” que representa tu programa. Estos comandos tienen la siguiente forma que incluye la especificación de un tercer parámetro:

ERT HOT_xxx('key','nombre del archivo','nombre del programa')

HOT_xxx puede ser, por supuesto, HOT_RES, HOT_CHP, etc.

El ‘nombre del archivo’ es el mismo que en los ejemplos anteriores. El ‘nombre del programa’ es cualquier nombre razonable que quieras dar al “Job” (o a la tarea). Por ejemplo, si el programa fuera una aplicación de base de datos llamado DATABASE_EXE y quisiéramos darle al “Job” (o a la tarea) el nombre de ‘mydbase’, entonces el comando debería ser este:

ERT HOT_LOAD('D','FLP1_DATABASE_EXE','mydbase')

Una vez que el programa se está ejecutando, verás el nombre de ‘mydbase’ si tecleas el comando JOBS o si has utilizado el menú de tareas del QPAC2. (Una tarea o un “Job” es simplemente un programa en código máquina, uno que se puede iniciar con EXEC, por ejemplo).

A partir de ese momento, podemos definir un HOTKEYS (una tecla de acceso directo) para que elijamos ese programa, por ejemplo así:

ERT HOT_PICK('d','mydbase')

De modo que al pulsar ALT d el sistema busca un programa que tenga el nombre de ‘mydbase’, y si lo encuentra lo traerá al primer plano como programa activo o programa seleccionado.

Aquí dejamos la primera parte de la descripción del sistema HOTKEYS, seguiremos profundizando en la segunda parte de este artículo.

—-
Fuente :
CAUTION: HOTKEYS – Don’t Burn Your Fingers
By David Denham, 1999
QL Today.

—-

La red del Sinclair QL es realmente impresionante a pesar de su antigüedad y muy fácil de usar una vez que te acostumbras a los principios que están detrás de ella.

Como todos los QL tienen dos conectores de red (también las placas Aurora o las QXL), puedes encadenar hasta 63 máquinas en una misma red. Las dos máquinas de los extremos de la red deben tener uno de los dos conectores desconectados. Seguramente éstos tendrán una resistencia o algo parecido para establecer el final de la red cuando no hay un cable conectado. (Es decir, los dos extremos no necesitan conectarse a modo de red circular, esto si es necesario en SERNET y en MIDINET tal como diremos más abajo).

El cableado de la red QL es extremadamente simple. Un cable de dos hilos con conectores de audio mono de 3,5 mm en ambos extremos es todo lo que necesitas para unir dos QL, un cable de altavoces es perfectamente adecuado. Cualquier longitud razonable de cable debería funcionar, aunque no sé cual es la distancia máxima recomendada entre máquinas.

Antes de pensar en usar la red del QL asegúrate de usar Toolkit 2, el uso se hace mucho más simple y divertido. La red básica es usable sin Taoolkit 2, pero es necesario tener Toolkit 2 para aprovechar al máximo la red.

Número de estación.

Para identificar los ordenadores dentro de la red es necesario asignar a cada uno de un número entre 1 y 63. Esto se hace con el comando NET y un número entre 1 y 63 (por defecto el número de estación es la 1 si al comando NET no se suministramos número alguno). Por ejemplo, con el comando “NET 2” asignamos al ordenador la estación número 2 dentro de la red.

En una simple red con 2 estaciones (sólo dos QL conectados entre ellos) ambos ordenadores pueden tener el mismo número de estación. En estos casos la configuración es mucho más simple ya que no haría falta el comando NET ni asignar a cada ellos un número distinto. Como el valor 1 es el defecto, en cada uno de los QL nos referiríamos al otro como estación n1.

En una red con más de dos QL, la numeración de las estaciones no es automática y se debe realizar estación a estación con el comando NET y asignando a cada máquina de la red un número distinto entre 1 y 63. Puede ser una buena estrategia ir numerando secuencialmente las estaciones de la red, pero hay que tener en cuenta que para que una estación actúe como “servidor de dispositivos”, el número de dicha estación tienen que estar comprendido entre 1 y 8 (ambos inclusive). Esto implica que en una res QL NET sólo pueden existir 8 servidores de dispositivos.

Tal como acabamos de comentar, una de las facilidades más importantes que nos aporta el Toolkit 2 es que podemos configurar en la red hasta 8 estaciones que actúen como servidores. Esto simplemente se hace con el comando “FSERVE”. De forma general las estaciones en las que hemos cargado el job FSERVE pueden compartir con el resto de la red, no sólo su sistema de almacenamiento, sino también impresoras, puerto serie, puerto paralelo (si tienes Super GoldCard), su propia consola, etc.

Algunos ejemplos.

Supongamos que tenemos una red de tres QL (los tres con Toolkit 2) y queremos configurar una red donde queremos que dos de los QL actúen como cliente y como servidor y el último de ellos sólo como estación que consume recursos de los anteriores. Lo que podríamos hacer es configurar la red con los siguientes comandos:

En el QL 1 tecleamos el siguiente comando:

  FSERVE

En el QL 2 tecleamos el siguiente los comandos:

  NET 2
  FSERVE

En el QL 3 tecleamos el siguiente los comandos:

  NET 3

Eso es todo, pero resaltemos algunos detalles:

– En el QL 1 no hace falta especificar un número de estación ya que por defecto el valor de la estación es 1 (el comando NET sólo sirve para especificar el número de estación cuando ésta es distinta de 1).

– Como tenemos dos máquinas actuando como “servidores” de dispositivos, a esas máquinas (QL 1 y QL 2) les tenemos que asignar números de estación comprendidos entre 1 y 8. Al QL 3 le hemos asignado la estación 3, pero podría haber sido cualquier otro número entre 3 y 63.

Una vez configurada la red, pongamos algunos ejemplos de uso. En el QL 3 podríamos teclear los siguientes comandos:

DIR n1_FLP2:
  (Nos mostrará el pantalla el directorio raíz de la segunda disquetera
   de la estación 1). 

DIR n2_WIN1_programas_
  (Nos mostrará el pantalla el directorio WIN1_programas_ 
   de la estación 2). 

COPY win1_boot to n2_PAR             
  (Copiará el fichero boot de la unidad win1_ en la impresora
   paralelo de la estación 2)

COPY win1_boot to n2_SCR
  (Copiará el fichero boot de la unidad win1_ en la consola
   de la estación 2)

WCOPY flp1_games_ to n1_win1_games1_ 
  (Copiará todos los ficheros de la disquetera 1 al subdirectorio
   win1_Games1_ de la estación 1)

OPEN #5, n2_ser1: list #5: close#5
  (Listará el programa que tengamos cargado en memoria en la
   impresora serie de la estación 2)

EXEC n1_win1_games_chess
  (Ejecutará el programa chess desde el subdirectorio win1_games_
   de la estación 1). 

Una caractarística curiosa es que podemos abrir una ventana en la consola de otro usuario, imprimir un mensaje y esperar de él una respuesta. Por ejemplo, Afx (que está en la estación 1) podría ejecutar el siguiente programa para hacer una pregunta a Badaman que está en la estación 2:

10 OPEN #4, n2_con_200x200a0x0
20 INPUT #4, "Hola, aquí afx ¿podemos almorzar juntos?", r$
30 PRINT r$
40 CLOSE #4

Otra versión del mismo programa.

10 ch = FOPEN(n2_con_200x200a0x0): CLS #ch
20 INPUT #ch, "Hola aquí afx, ¿podemos almorzar juntos?", r$
30 PRINT r$
40 CLS #ch: CLOSE #ch

Una configuración interesante dentro de QL NET es hacer uso del sistema de dispositivos por defecto incorporado en el sistema operativo, proporcionado por los comandos DATA_USE, PROG_USE, SPL_USE y DEST_USE.

DATA_USE [nombre]    
  (selecciona el directorio de omisión para ficheros de datos)

PROG_USE [nombre]
  (selecciona el directorio de omisión para programas ejecutables)

DEST_USE [nombre]
  (selecciona el directorio de omisión de destino (COPY, WCOPY)) 

SPL_USE  [nombre]
  (selecciona el spooler de impresión por omisión (SPL))

El uso de estos nombres de directorio por omisión hace nos hace el trabajo bastante más fácil. Por ejemplo, con la siguiente instrucción todos los programas serán cargados por defecto desde el directorio “progs” del disco win1_ de la estación 1 cuando no indiquemos expresamente una unidad de almacenamiento.

PROG_USE n1_win1_progs 

Una vez introducido el comando anterior, podríamos ejecutar cualquier programa ubicado en esta estación de trabajo y subdirectorio simplemente con EXEC y el nombre del programa.

Pongamos otro ejemplo, con la siguiente instrucción se selecciona el dispositivo PAR (puerto paralelo) de la estación 2 como destino del “spooler” de omisión.

SPL_USE  n2_par

Y partir de la línea anterior, podemos imprimir en segundo plano cualquier fichero como el ejemplo siguiente:

SPL flp1_myFile_txt    
  (imprime myFile_txt en el puerto paralelo de la estación 2)

NFS_USE

Además del uso de dispositivos por defecto, podemos también “mapear” rutas de una red a un dispositivo cualquiera, esto lo hacemos con el comando NFS_USE que nos aporta el Toolkit 2. Veámoslo.

Mediante el comando NFS_USE es posible ocultar la red local a las aplicaciones escogiendo un nombre especial para el servidor de ficheros en red local. La sintaxis es la siguiente:

NFS_USE "nombre", "ubicaciones de la red local", ...

Los “nombres de red local” deben ser nombres de directorio completos, pudiéndose dar hasta 8 en un comando. Cada uno de estos nombres estará asociado con uno de los 8 posibles dispositivos de directorio (“nombre_1” a “nombre_8”). Pongamos un ejemplo.

NFS_USE mdv,n2_win1_,n2_flp1_,n2_flp2_

La anterior sentencia asigna distintas ubicaciones de la estación 2 que actúa como servidor de ficheros a los dispositivos mdv1_, mdv2_ y mdv3_ de la estación cliente. En el ejemplo, “mdv1_” es asignada a la unidad win1_ en la estación 2, “mdv2_” será tomado como “flp1_” en estación 2 y “mdv3_” será tomado como “flp2_ “también en la estación 2.

Una cosa que también se suele hacer es “reasignar” un nuevo nombre a los dispositivos existentes si queremos “mapear” éstos a otras rutas de la red local. En nuestro ejemplo anterior haríamos lo siguiente:

MDV_USE MDD
NFS_USE mdv,n2_win1_,n2_flp1_,n2_flp2_

De esta manera mantendremos los accesos a las unidades de microdrive como MDD1_ y MDD2_ en lugar de MDV1_ y MDV2_.

El controlador de dispositivos DEV (DEV_USE).

En la primera versión de QDOS no existía la posibilidad de crear subdirectorios reales dentro de un dispositivo de almacenamiento. Debido a esto muchos programas de QL fueron escritos sin tener en cuenta la posibilidad de almacenar archivos en subdirectorios. En la siguientes versiones de QDOS, y por supuesto de SMSQ/E, apareció el soporte a lo que se llaman “nivel 2” del sistema de almacenamiento donde el soporte de subdirectorios es completo. Este “nivel 2” del sistema de almacenamiento se extendió con la (Super)GoldCard, dispositivos de disco duro y unidades de disquete de alta densidad. En este contexto, para facilitar la compatibilidad de los programas antiguos que no daban soporte a los subdirectorios, se creó una extensión que aporta un dispositivo virtual llamado DEV. En si, el dispositivo DEV es un dispositivo genérico por defecto (no sólo acotado al uso de la red local) y es una especie de “engaño” para permitir que el software antiguo (como Quill, Archive, Abacus y Easel) hagan uso de subdirectorios.

Además de lo expuesto anteriormente, y en el contexto que nos ocupa, los dispositivos DEV también tienen la capacidad de “mapear” dispositivos lógicos a rutas reales dentro de la red local.

Como de costumbre, hay hasta 8 dispositivos DEV; DEV1_ a DEV8_. Cada dispositivo DEV está conectado a un dispositivo real particular o a un directorio por defecto particular en un dispositivo real. Los archivos en un dispositivo DEV pueden ser abiertos, usados y borrados de la misma manera que en un dispositivo real.

Cada unidad “DEV” está conectada a un dispositivo mediante el comando DEV_USE. La sintaxis es la siguientes.

DEV_USE NúmeroDisp, DirectorioReal

Pongamos un ejemplo.

DEV_USE 4, n2_win1_sys_

A partir de la introducción de comando anterior podemos hacer referencia al contenido del directorio win1_sys_ de la estación 2 como dispositivo DEV4_ de nuestra estación.

A tener en cuenta que el sistema QDOS y SMSQ/E puede manejar también dispositivos distintos a los dispositivos de almacenamiento. Estos dispositivos son:

SER1 y SER2  (puertos serie RS232)
PAR          (puerto paralelo (sólo a partir de SuperGoldCard))
SCR,         (pantalla como dispositivo de salida)  
CON          (consola como dispositivo de entrada/salida)

Esto significa que podemos mapear una unidad DEV a uno de estos dispositivos. Por ejemplo:

DEV_USE 8, n1_par

La orden anterior asigna la unidad lógica “DEV8_” al puerto paralelo de la estación 1.

Otro ejemplo interesante:

NFS_USE "ser",n1_par, n2_par 
PAR_USE "ser"
COPY_N "flp1_myfile" TO "ser2"

Las líneas anteriores reasignan los identificadores de los puertos serie de mi estación, concretamente, SER1_ se reasigna al puerto paralelo el la estación 1 y SER2_ se reasigna al puerto paralelo de la estación 2.

SERNET y MIDINET

Tanto SERNET como MIDINET son controladores de red que aparecieron posteriormente y te permiten montar redes de bajo costo como la QL NET original del Toolkit 2. SERNET permite conectar dos o más máquinas que ejecutan SMSQ/E a través de los puertos serie, mientras que MIDINET permite conectar dos o más ordenares ATARI con SMSQ/E a través de los puertos MIDI. SERNET fue desarrollado a partir del software MIDINET de Phil Borman. Bernd Reinhardt modificó el software para usar los puertos seriales en lugar de los puertos MIDI.

Con estos controladores podemos ampliar las “fronteras” extendiendo la red QL, por ejemplo, permitiendo que las máquinas sin conectores net 1 / net 2 del QL se unan a la red.

Tanto el SERNET como el MIDINET están organizados como una red circular. En el caso de MIDI, el puerto MIDI OUT de cada máquina tiene que estar conectado al puerto MIDI IN de la siguiente máquina. Todos los cables tienen que formar un círculo completo. Cada máquina en el círculo tiene que estar funcionando y el controlador tiene que cargarse para tener una red en funcionamiento. Lo mismo se aplica a SERNET: con dos máquinas, puede usar un cable de módem nulo. Con tres o más máquinas, debes cablear tus propios cables para que todas las señales de salida de una máquina estén conectadas a las señales de entrada de la siguiente máquina y así sucesivamente, para formar un círculo completo también.

SERNET tiene que configurarse para que sepa qué puerto usar como puerto de comunicación. Como es habitual en muchos programas y controladores de dispositivo del QL esto se hace mediante el uso de MenuConfig para configurar los parámetros dentro del binario del propio controlador (SERNET_REXT).

Una vez configurado podemos cargar el controlador con una instrucción similar a la siguiente (suponemos que el controlador está en el directorio raíz de la unidad win1_.

LRESPR win1_SERNET_REXT

Sernet enlaza los ordenadores a través del puerto serie y utiliza el nombre de dispositivo “S” de forma similar a la “N” para la red QL.

Y por último, una vez cargado el controlador, sólo tenemos que definir el número de estación y activar los servicios de la estación como servidora dentro de la red. Las instrucciones serían como el siguiente ejemplo:

Estación 1:
  SNET_USE 1
  SERNET 

Estación 2:
  SNET_USE 2
  SERNET 

A partir de este momento estas dos estaciones pueden compartir sus recursos. Por ejemplo con la siguiente instrucción en la estación s1.

DIR s2_FLP2_            

Nos mostrará el pantalla el directorio raíz de la segunda disquetera de la estación 2.

Enlazando las dos redes, QLNET y SERNET.

Para finalizar, el último paso de nuestro experimento es configurar un entorno, en el cual puedan convivir dos redes: QL NET y SERNET. Por un lado QL NET nos permitiría conectar QL originales (BBQL) en nuestro entorno, y por otro lado podríamos añadir a esta “red QL” sistemas modernos que tengan disponible al menos un puerto RS232 (por ejemplo el emulador QPC2 en un PC con Windows 10 o la FPGA Q68).

El punto de unión de estas dos redes la hemos resuelto con una combinación hardware-software relativamente reciente. El hardware no es otro que la FPGA Q68 que incluye de serie un puerto RS232 y a la cual se la he aplicado un “modding” para incluir dos conectores QL NET. En cuanto al software, lo único que necesitamos ejecutar en la Q68 es el driver SERNET que hemos mencionado anteriormente y el nuevo driver QLNET de Martyn Hill que te permite conectar en red el Q68 con otras máquinas compatibles con QL a través de los puertos QLNET estándar. Los comandos a incluir en el boot de arranque de la Q68 sólo debe incluir los siguientes comandos:

LRESPR win1_sernet_rext     (Carga el controlador SERNET)
BAUD 115200                 (Establece la velocidad en baudios) 
SERNET 2                    (Establece s2 como número de estación SERNET)
SERNET                      (Activa los servicios SERNET) 

LRESPR win1_ndq68_dvr_v305  (Carga el driver de red QL NET para Q68)
NET 2                       (Establece n2 como estación QL NET) 
FSERVE                      (Activa las funciones de servidor QL NET). 

Descrito todo esto, la primera parte de este artículo seguramente tendrá más sentido.

—-
Fuentes:
– SUPERTOOLKIT II, MANUAL DEL USUARIO (Tony Tebby, Qjump, Reino Unido. 1985).
– The QL Network. QL Today, Volume 9 Issue 4. (David Denham).
– SERNET on QDOS? QL Today, Volume 6 Issue 6. (Dilwyn Jones).
– Announcing availability of a QLNET driver for the Q68 (ND-Q68) (https://qlforum.co.uk/viewtopic.php?f=3&t=2881&p=28393) (Martyn Hill).

Hace un tiempo (bueno, … bastante tiempo) escribíamos en QBlog un artículo introductorio sobre las facilidades de red local que incorporaba el Sinclair QL. En ese artículo comprobamos lo sencillo que es montar una pequeña red con dos QLs y la versatilidad el sistema operativo para manejar recursos compartidos entre distintas estaciones. (Si la red local del QL es algo nuevo para ti te recomendamos su lectura).

Ahora, en una serie de dos artículos, vamos a intentar profundizar algo más en las capacidades de red de los sistemas QDOS y SMSQ/e. Intentaremos describir con detalle qué posibilidades actuales tenemos para llevar al límite la red de área local de sistemas QDOS y SMSQ/E.

Esta primera entrega tendrá un carácter mas “exhibicionista” (por decirlo de alguna manera) de hasta donde podemos exprimir la red del Sinclair QL. Sólo expondremos conceptos muy generales y relataremos un ejemplo de cómo podemos llevar al límite la red del Sinclair QL en el contexto actual (año 2020). La segunda parte será algo más árida para quien no esté familiarizado con los sistemas operativos del mundo QL. En esa segunda parte entraremos en las entrañas de los distintos comandos y facilidades que nos aporta el sistema operativo a la hora de planificar y configurar nuestra red. También haremos una descripción más detallada de las distintas partes (hardware y software) que la componen.

Una pequeña introducción.

La incorporación de serie de hardware y software de red en los microordenadores de los años 80 no era una característica muy común. En el año 84, ésta fue una novedad interesante en el Sinclair QL que no fue lo suficientemente valorada ni conocida.

QL NET es el nombre por el que se conoce la red de área local del QL. Esta red permite la conexión de hasta 64 estaciones de trabajo que soporten este protocolo. La red permite compartir impresoras, unidades de almacenamiento y hasta la propia consola de cualquier estación conectada a ella.

Los datos circulan por la red a una velocidad de 100K Baudios y el protocolo asegura que las estaciones estén listas antes de que los datos sean pasados a través de la red. Los datos también pueden ser volcados a modo de “broadcast” a todos los ordenadores que estén a la escucha.

Con el paso de los años, y la entrada en el mundo QDOS/SMSQe de otro tipo de hardware, principalmente el Atari ST, se implementaron nuevos controladores de red dado que estos sistemas no incluían el hardware de red del QL (QL NET). El primero de los controladores en llegar fue MIDINET el cual permitía conectar en red varios AtariST. El puerto MIDI OUT de cada estación se conectaba al puerto MIDI IN de la siguiente estación y así se podía formar una red en anillo. Posteriormente, a partir de MIDINET se desarrolló SERNET que permitía también la conexión en red de varias estaciones SMSQ/E y QDOS a través la interfaz RS232. Este controlador se usaba frecuentemente en hardware distinto al QL original que incorporaba puertos RS232 de alta velocidad (Aurora, Q40/Q60 y emuladores como QPC).

Nuestra red experimental.

La idea básica es montar una red local entre 4 máquinas distintas y heterogéneas empleando QL NET y SERNET. Las características de cada estación que componen nuestra red son las siguientes:

Estación 1. QL clásico ampliado con una Super GoldCard y una QL-SD como unidad de almacenamiento.

Estación 2. Q68 con un “modding” reciente que incorpora QL NET. Además de QL .NET, Q68 incluye de serie un puerto RS232. (Q68 es una FPGA que implementa una máquina SMSQe)

Estación 3. PC con Windows 10 que ejecuta el emulador QPC2. Esta estación tiene un puerto COM1.

Estación 4. Un segundo PC con Windows 10 que comparte a través de la red TCP/IP una carpeta de su sistema de archivos con la estación 3.

El esquema de la red está en la siguiente figura.

(NOTA: No te preocupes por las siglas del la imagen anterior, hablaremos de ello en el la segunda parte de este artículo).

Podríamos decir que la “magia” de esta red heterogénea está en la FPGA Q68 (estación 2) que actúa como una especie de “gateway” entre dos redes distintas QL NET y SERNET. Mediante QL NET conectamos el QL original y la FPGA, mediante SERNET conectamos la FPGA y el PC con el emulador QPC2. Y por último nos aprovechamos de la posibilidad que tiene QPC2 de montar volúmenes de almacenamiento “mapeados” sobre capetas locales o remotas del PC anfitrión.

La infraestructura anterior y las facilidades que nos da el sistema operativo del QL (tanto QDOS como SMSQe) nos permite cosas como montar unidades de almacenamiento lógicas en el QL “mapeadas” a carpetas o directorios nativos del los PC de la red y de la FPGA.

Por poner un ejemplo, podemos redirigir el nombre que asigna QDOS al microdrive 1 (MDV1_) a una carpeta compartida que tiene el PC número 2 de mi red local. Desde este momento, si tecleamos “dir mdv1_” obtendremos el contenido de la carpeta compartida del PC 2 de nuestra red.

A modo ilustrativo, en la figura 1 podemos observar que en el QL (estación N1) se han definido los 4 dispositivos de almacenamiento lógicos (dispositivos DEV) siguientes:

– DEV1_ (apunta a la unidad de almacenamiento WIN1_ de la FPGA).
– DEV2_ (apunta a la unidad de almacenamiento WIN1_ del emulador QPC2 en el PC1)
– DEV3_ (apunta a un directorio del disco C: del primer PC, que ha sido montado a su vez como disposito DOS1_ en QPC2))
– DEV4_ (apunta a un directorio compartido del segundo PC, que ha sido monado como dispositivo DOS2_ en QPC2)

Forzando un poco más, podríamos “mapear” DEV4_ a una subcarpeta dentro de nuestro sistema de almacenamiento en la nube tal como dropbox. Esto significa que desde mi QL pudo escribir o leer directamente archivos que van a ser vistos de forma inmediata por toda las personas del planeta a las que le haya compartido dicha carpeta.

Esta red me permite prescindir de disquetes y tarjetas SD cuando quiero transferir ficheros a mi QL. Ahora todo lo hago todo via QL NET.

Algunas pantallas a modo de ejemplo.

Q68 con los puertos QL-NET (lateral) y su interfaz RS232 (parte trasera)

QL – accediendo a la unidad de almacenamiento de Q68

Q68 – accediendo a la unidad de almacenamiento del QL

QPC2 – con una unidad virtual del sistema anfitrión (DOS)

QL mostrando el contenido de una carpeta del PC con Win10 (ver número sectores)

Todo esto podría parecer confuso para las personas desconocedoras del mundo QL y sus sistemas operativos QDOS y SMSQe, pero en cuanto se dominen un par de conceptos toda esta configuración es muy sencilla.

En la segunda parte de este artículo explicaremos los principales comandos del sistema operativo que nos permite hacer lo indicado anteriormente. Veremos como crear esos dispositivos DEV y otros comando útiles para configurar y montar una red QDOS/SMSQe con máquinas heterogéneas.

Esta semana se ha liberado una nueva versión de SMSQ/E, la versión 3.36. Aporta algunas características interesantes:
– En Q68 las tarjetas no necesitan ser inicializadas para un acceso normal.
– En Q40/Q60 los archivos contenedores pueden ser leídos desde las cuatro primeras particiones.
– Las unidades WIN pueden ser removibles en SMsQmulator
– …

Pero una característica digna de mención para los usuarios de habla hispana es que por fin integra de forma nativa el soporte para teclados en español, tanto del teclado original del QL (Rom MGE) como para teclados de PC usados, por ejemplo, en la Q68. Los usuarios con teclados y QLs en español ya no tendremos que lidiar con controladores externos, basta con teclear el comando “KBD_TABLE 34” y ya tendremos habilitado el teclado en castellano.

También integra de forma nativa la posibilidad de activar los mensajes del sistema en castellano, esto se hace con el comando “LANG_USE 34”.

Como viene siendo habitual desde hace tiempo, los artífices de estas mejoras y nuevas características han sido Marcel Kilgus y Wolfgang Lenerz.

El sitio oficial para la descarga del SMSQ/E es este:
http://www.wlenerz.com/smsqe/,

Siempre es una buena noticia ver que, después de tantos años, sigan saliendo versiones nuevas de este “pequeño” y formidable sistema operativo.

El concepto de Variables de Entorno viene del mundo UNIX. Se utilizan también en MS-DOS pero de forma más limitada y no en la misma medida. Para el mundo QDOS, el archivo ENV_BIN proporciona una serie de extensiones que permiten el uso de Variables de Entorno en el Sinclair QL.

Si queremos disponer de estas facilidades debemos cargar previamente dicha extensión en nuestra sistema. Para ello basta con añadir en nuestro boot una línea similar a la siguiente (*):

100 LRESPR flp1_env_bin

(*) Notas:
– LRESPR requiere Toolkit 2
– La extensión ENV_BIN se puede obtener en la sección de Toolkits del sitio de Dilwyn Jones.

En esencia, una variable de entorno es una variable que puede ser “vista” por los programas ejecutables. En SuperBASIC podemos crear todo tipo de variables, pero si ejecutamos un programa desde SuperBASIC, estos programas no pueden “ver” dichas variables ni obtener datos de ellas.

El objetivo de las variables de entorno suele ser el cambiar la configuración de un programa. Estas variables funcionan como los “Bloques de Configuración” en QDOS, pero no requieren de la ejecución de un programa externo para hacer cualquier cambio en sus valores.

Echemos un vistazo a cómo podemos cambiar el comportamiento de los programas. Hay cinco maneras diferentes de hacer esto:

1] Intervención del usuario. Mediante esta estrategia, el usuario utiliza un menú o responde a las preguntas del programa.

2] Bloques de Configuración (Config Blocks). Esta característica es peculiar del QDOS y permite al usuario cambiar las opciones por defecto sin tener que saber cómo editar un archivo binario.

3] Fichero de Configuración. Este es un archivo separado que el programa lee para determinar cómo establecer los valores predeterminados para su ejecución.

4] Argumentos por la Línea de Comandos. En lugar de que el programa pregunte la de información al usuario, el usuario escribe dichos valores cuando ejecuta el programa desde la consola utilizando parámetros adicionales.

5] Variables de Entorno. El usuario establece una variable que luego es leída por el programa para cambiar su configuración predeterminada.

Cada una de las opciones tiene su propio lugar, sus ventajas y sus defectos. Algunas son más permanentes, como los Bloques de Configuración y los Archivos de Configuración, mientras que las otras opciones son más volátiles, como la “Intervención del Usuario” y de los “Argumentos por la Línea de Comandos”. Las “Variables de Entorno” se encuentran entre las opciones que se pueden establecer en el BOOT (arranque del sistema), o en un programa cargador, pero se pueden cambiar con solo teclear en un nuevo comando. El fichero ENV_BIN viene con 4 extensiones. Éstas son:

SETENV     - Define una variable de entorno.
ENV_LIST   - Lista todas las variables de entorno definidas.
ENV_DEL    - Elimina una variable de entorno.
GETENV$    - Obtiene el valor de una variable de entorno.

Los dos comandos más relevantes son SETENV y GETENV$. SETENV se usa de esta forma:

SETENV "VARIABLE=valor"

SETENV toma un argumento de cadena del tipo “XXXXX=YYYYY”, donde XXXXX y YYYYY son dos cadenas separadas por un signo igual. Cualquier espacio antes del signo igual es tratada como una parte de XXXXX y un espacio después del signo igual es tratada como una parte de YYYYY. El nombre de la variable es sensible a mayúsculas y minúsculas, así “VARIABLE” es diferente de “variable”. Por convenio, las mayúsculas se utiliza como nombre de las variables de entono. El comando SETENV se puede ejecutar en el programa de inicio del sistema -BOOT- (el cual podría ser alterado por un programa instalador), o bien directamente por el usuario. El comando para que un ejecutable obtenga el contenido de una variable de entorno es GETENV$. El comando se usa así:

a$ = GETENV$("VARIABLE")

En este caso, a$ se le asignará el valor de “valor” establecido en nuestro ejemplo por la instrucción SETENV anterior. Si la variable de entorno “VARIABLE” no está definida (no existe), entonces la función GETENV$ devolvería una cadena vacía (“”).

Hemos dicho que los ejecutables usan GETENV$ y no los programas SuperBASIC. Como las variables se utilizan ya de forma ordinaria en el entorno SuperBASIC, no ganaríamos mucho en el uso de variables de entorno (a no ser que pretendamos obtener algún valor preestablecido de forma personalizada en nuestro sistema). Por esto hemos destacado que el uso mayor de estos comandos es en los programas SuperBASIC compilados, que son ejecutables.

Vemos que el propósito de utilizar Variables de Entorno es la adición de flexibilidad para los programas que utilizan bloques de configuración. Ambos, Bloques de Configuración (Config Blocks) y Variables de Entorno se han diseñado realmente para cambiar la configuración predeterminada de los programas. La “Intervención del Usuario” y los “Argumentos por la Línea de Comandos” están diseñados para indicar al programa algunos datos adicionales. El uso de Variables de Entorno permite al usuario la posibilidad de hacer un cambio temporal en las opciones por defecto de un programa, sin tener que pasar por la molestia de usar “config”. Las variables de entorno se utilizan para cambiar una configuración para una sola sesión y ya está.

No es difícil el uso de los “Bloques de Configuración” y las “Variables de Entorno” en conjunción de tal forma que sean complementarias. El programa obtendría primeramente su configuración por defecto del Bloque de Configuración (Config Block). A continuación, se comprueba si hay variables de entorno establecidas. Si hay, entonces los valores de configuración de las Variables de Entorno reemplazan los valores de configuración definidos en los Bloque de Configuración.

 

Fuente:

Artículo original: http://dilwynjones.topcities.com/qhj/qhj/qhj28.txt

Timothy Swenson
Artículo aparecido en QL Hacker’s Journal

Traducción:
Afx
Septiembre de 2009

SuperBASIC es un intérprete BASIC implementado dentro de las ROMs del QL, además de las ROM Minerva, aunque estas últimas tiene algunas mejoras. El sistema operativo SMSQ/E viene con un intérprete BASIC mejorado, llamado SBASIC. A lo largo de los años se ha adoptado el término S*BASIC para hacer referencia a ambas versiones del BASIC del QL. El intérprete SuperBASIC fue desarrollado originalmente por Jan Jones en Sinclair, mientras que el QDOS en si mismo fue desarrollador por Tony Tebby.

El plan original era utilizar un sistema operativo encargado a una empresa denominada GST, pero por diversas razones este nunca se suministró con el QL y Sinclair usó el de Tebby en su lugar. El sistema operativo de GST, llamado 68k/OS, fue comercializado por GST como una tarjeta conectable en el QL durante un tiempo, aunque no se vendió mucho.

Las ROMs Minerva fueron desarrolladas originalmente por un pequeño grupo en QView -Jonathan Oakley, Stuart McKnight y Laurence Reeves- las letras iniciales de sus nombre de pila dan el nombre “JSL1” a la versión del SuperBASIC . Minerva estaba basada originalmente en las ROMs QDOS, aunque los numerosos cambios y mejoras realizados a lo largo del tiempo hacen que Minerva sea reconocida de forma independiente por derecho propio.

Las ROMs Argos para el ordenador Thor fueron desarrolladas por David Oliver de CST, la compañía que estaba detrás de los ordenadores Thor. Argos está basada en QDOS, pero incluye muchas mejoras del sistema diseñadas específicamente para los sistemas Thor.

SMSQ/E fue desarrollado por Tony Tebby con versiones más recientes mantenidas por Marcel Kilgus y Wolfgang Lenerz (que actúa como secretario) quien coordina las publicaciones de las diferentes versiones para las diversas plataformas. Hay que destacar como aspecto interesante, la existencia de una versión anterior llamada SMS2, que sólo estaba disponible en forma de cartucho para los sistemas Atari. Miracle System licenció un sistema operativo llamado SMSQ de Tony Tebby para sus tarjetas QXL. Este era el predecesor de SMSQ/E, la mayor diferencia entre SMSQ y SMSQ/E era que SMSQ no incluía ningún entorno gráfico (llamada Pointer Enviroment -o PE en adelante-). La /E en SMSQ/E hace referencia a la Extensión del Entorno construida dentro del sistema operativo.

En cuanto al nombre de SMSQ, se ha publicado diversas conjeturas sobre su significado. La explicación más probable es que corresponde a las siglas de “Single-user Multitasking System for QL” (Sistema Multitarea de usuario-Simple para el QL). SMSQ y SMSQ/E son cargados normalmente desde disco en lugar de ser instalado en ROM, aunque el Q40 puede almacenar su versión de SMSQ/E en una flash ROM, si fuera necesario.

Las versiones del BASIC se indican mediante cadenas de 2, 3 o 4 caracteres como AH, JM, JS, MG, JSL1 O HBA. Minerva usa “JSL1” para el SuperBASIC en todas sus versiones de la ROM, mientras que SMSQ/E siempre usa “HBA” como la versión de su SBASIC. Las versiones de la ROM del QL han sido conocidas generalmente por esos nombres de versión (por ejemplo QL versión JS) aunque estrictamente hablando ellas se refieren a las versiones del SuperBASIC. Lo números de versión del sistema operativo generalmente está formado por un número de versión de 4 caracteres como por ejemplo 1.10, donde el ‘.’ se sustituye por las variantes nacionales (por ejemplo, la versión del QDOS 1E13 se corresponde a la versión del SuperBASIC MGE es la versión española de la ROM del QL).

La versión del BASIC puede ser comprobada con el comando PRINT VER$ la cual mostrará la cadena de 2, 3, o 4 caracteres que identifican a la versión. La comprobación de la versión del QDOS no es tan simple como la función o comando del BASIC. Algunos toolkits incluyen una función como por ejemplo QDOS$ que muestran la versión del sistema operativo formada por los cuatro caracteres. Alternativamente, rastreando una imagen de la ROM en la pantalla y buscando una cadena que comience por “1.” o “2.” -si no es una versión inglesa debemos reemplazar el “.” por la letra que identifica al país-. Para aquellos que estén familiarizados con el código máquina pueden usar la llamada al trap MT.INF (trap #1, d0=0) que retorna un ID string QDOS como una palabra larga en el registro D2.

La primera versión de la ROM del QL era conocida como la versión FB, la cual estaba plagada de bugs y era incompleta, muchos la llaman versión “Full of Bugs!” (plagada de errores). Esta fue reemplazada rápidamente por la versión PB la cual fue muy mejorada, aunque realmente aún no era una versión acabada. La versión AH fue la primera versión que se podría considerar lo bastante estable para un uso permanente. Esta versión fue también reemplazada rápidamente por la versión JM, la primera versión suministrada en una ROM frente a las anteriores que fueron versionadas en EPROM.

A principios de 1985 fue liberada la versión JS que contenía mejoras significativas, como un manejador de errores, traducción de caracteres para la impresión e inspección de variables (WHEN var). La versión JS corrigió algunos errores de versiones anteriores, pero también introdujo unos cuantos errores oscuros propios de esta versión. La versión MG fue liberada un poco más tarde para el mercado internacional con variantes, como MGF para Francia, MGE para España, MGG para Alemania. Sinclair no publicó una versión MG para el mercado inglés, aunque se produjo una versión privada MGUK.

Se produjeron también algunas versiones privadas de la ROM del QL independientemente de Sinclair. Por ejemplo la rom MGUK de John Alexander y la edición JS 4MB de la ROM JS para el uso con emuladores las cuales podrían tener memorias más grandes que la que ofrecía la estándar del QL.

CST actualizó la ROM del QL original para el uso específico en los ordenadores Thor. A esta se las conoce como Argos e incluyen su propio sistema de ventanas y otras mejoras con respecto al QDOS.

Ultrasoft fabricó una versión de la ROM MG, llamada Ultra-MG, que contenía algunas correcciones de errores y añadía un mapa de teclado alemán.

La ROM Tyche de 64KB es un desarrollo de un QDOS para un sistema QL que nunca se llegó a editar. Es probable que ésta versión no pueda ser usada en un QL estándar.

Las ROM AH, JM, JS, MG y TB han sido liberadas para su uso libre en Europa (Sinclair permite la distribución para su uso sin ánimo de lucro), aunque en el caso de Norteamérica estos derechos están en manos de Paul Holmgren y Frank Davis y se debería pedir permiso a ellos para su uso en América del Norte. La ROM Minerva ROM está liberada para usarse con emuladores en todo el mundo.

BASIC   QDOS	Descripción 
FB	1.00	ROM FB de Sinclair (versión original "kludge")
PM	1.01	ROM PM de Sinclair
AH	1.02	ROM AH de Sinclair
JM	1.03	ROM JM ROM de Sinclair 
TB	1.03	ROM de Sinclair intermedia, entre JM y JS
JS	1.10	ROM JS Sinclair
JSU	1u10	ROM USA JS Sinclair
JS-4M	1.10	ROM JS, parcheada para 4MB RAM 
MG	1.13	ROM MG inglesa 
MF	1.14	ROM versión alemana
MGE	1E13	ROM MG versión española
MGG	1G13	Otra ROM versión alemana.
MGI	1I13	ROM MG version italiana
MGUK	1ê13	Actualización de John Alexander de 
                   la ROM MG con commandos añadidos
JSL1	1.61	Versión temprana de la ROM Minerva
JSL1	1.63	Versión siguiente de la ROM Minerva
JSL1	1.64	Versión siguiente de la ROM Minerva
JSL1	1.66	Versión siguiente de la ROM Minerva
JSL1	1.89	Versión siguiente de la ROM Minerva  
                    para uso con emuladores
JSL1	1.98	La version más reciente de Minerva, de 
                    distribución libre.
Thor	630 1.13  Thor v6.30 ROM 
Thor	634 1.13  Thor v6.34 ROM 
Thor	636 1.13  Thor v6.36 ROM 
thor	639 1.13  Thor v6.39 ROM 
Thor	641 ?	Thor v6.41 ROM 
Tyche	2.05	Última version del QDOS no liberado para 
                   hardware QDOS. Una ROM 64K que es 
                   interesante pero no es muy compatible con 
	         las ROM 48K del QL original. Contiene el 
                   mensaje de copywrite 
                   '(C) 1985 Sirius Cybernetics'   
Ultra-MG 1.14      La versión de Ultrasoft de la ROM MG alemana. 
                   Corrige algunos errores y
	         contiene un mapa de teclado alemán.
EFP 1E13 Sigma FP  Greek ROM, Versión EFP

Las versiones de la ROM anteriores a JS (por ejemplo AH, TB, JM) fueron las versiones primitivas de Sinclair. Ellas son perfectamente usables y mucha gente aún tiene EPROMs AH o JM en sistemas QL.

La versión JS introduce algunas nuevas características como la captura de errores con WHEN ERROR, variables WHEN para la monitorización de valores, y las características de traducción TRA. JSU era una versión para América del norte de la ROM del QL.

Con la ROM MG llegaron las versiones internacionales como MGF para Francia, MGI para Italia y cosas por el estilo. A lo largo de los años, se han sucedido algunos derivados como la versión 4MB de la ROM JS, y la ROM MGUK de John Alexander.

No se sabe con exactitud de dónde procede ni el significado de las dos letras en la numeración de las versiones. Una teoría es que provienen de las iniciales del personal (staff) de Sinclair (por ejemplo, JM pueden haber sido las iniciales del ingeniero John Mathieson). Hubo incluso rumores de que AH provenía de “Angela’s Holiday”, aunque después de todos estos años aún no se ha podido confirmar ninguno de estos rumores (ni tanto otros que han surgido).

Los BUGS de la ROM

A lo largo de los años se ha evidenciado la existencia de diversos errores en las distintas versiones de la ROM. Escritores como Simon Goodwin y Mark Knight los han documentado. La lista de Mark Knight está disponible en el sitio Web: http://www.dilwyn.me.uk/docs/basic/bugs.zip, y los artículos de Simon Goodwin pueden encontrarse en los números siguientes de la revistas QL World:

  • Agosto de 1987, página 18 “Bugging The ROM” (este articulo también detalla cómo convertir una página con versiones en EPROM a las posterires versiones de la ROM del QDOS).
  • Septiembre 1987, página 12, “Beating The Bugs”.
  • Junio de 1988, página 30, “Return Of The ROMs”.
  • Febrero de 1989, página 18, “Bugs At Large”.

Muchos de los errores documentados no son críticos y tienen soluciones simples, mientras que otros son potencialmente serios. Sin embargo la mayoría de ellos se pueden evitar compilando los programas con Turbo o con QLiberator, los cuales hacen un buen trabajo en corregir la mayoría de bugs. La ROM Minerva también corrige la mayoría de ellos con respecto a las versiones ROM de Sinclair.

A pesar de que la lista (más o menos larga) de errores pueda afectar a su confianza en el uso del QL, la mayoría de ellos tienen un efecto mínimo y probablemente la situación no es peor que el resto de los ordenadores, y además en el caso del QL están abiertamente documentados.


Funete.
– Artículo original: http://www.dilwyn.me.uk/docs/basic/versions.zip (Dilwyn Jones. Tal-y-bont, Gales, Reino Unido.)
(Traducción: afx)

USBwiz

Llevo siguiendo hace unas semanas en QL-Users los comentarios de Adrian Ives sobre la evolución del desarrollo de un driver para QDOS / SMSQ para manejar unidades de almacenamiento externos tipo tarjetas SD o pendrives. Su idea es conectar al puerto serie del QL (SER) la pequeña placa USBwiz y controlarla de forma nativa desde el QDOS. Con este driver podríamos montar pendrives o tarjetas SD y manejarlas como si se tratase de una unidad de almacenamiento masivo. Así, además de los dispositivos FLP_ o MDV_ (para controlar los disquetes o los microdrives respectivamente), tendríamos adicionalmente un dispositivo USB_ para acceder a estas unidades de almacenamiento.

El desarrollo lo lleva bastante adelantado y parece que para mediados de marzo liberará una versión de pruebas.

Si este proyecto llegara a buen puerto, sería una gran noticia para todos los entusiastas del Sinclair QL.

Algunos comentarios de posts recientes aquí:
http://www.mail-archive.com/ql-users@lists.q-v-d.com/msg09661.html

Qascade es una utilidad freeware, creada por Jonathan Hudson, que permite al usuario crear un menú del sistema personalizado al estilo del botón “Inicio” de Windows. Qascade debe su nombre al hecho de que podemos definir menús en cascada anidados unos dentro de otros. El único requerimiento de Qascade es PE (Pointer Environment) y env_bin para el soporte de variables de entorno.

Qascade permite que el usuario defina totalmente la estructura del menú. Una entrada de menú consiste en un ítem seleccionable o una entrada a un submenú. Cada submenú también consiste en ítems seleccionables o submenús. Esto puede continuar hasta agotar la memora o la pantalla. Los ítems seleccionables pueden asociarse a programas ejecutables, Things o programas SBasic y MBasic (pero no SuperBASIC).

Cuando es ejecutado, Qascade aparece en pantalla en forma de botón. Cuando seleccionamos este botón, el menú principal se despliega. Desde este menú podemos seleccionar una entrada que ejecuta algún programa o una entrada que despliega otro submenú.

El propósito de Qascade se suministrar un sistema simple de menú de nuestro sistema, y tener así una interfaz de usuario primaria para nuestro QL.

La flexibilidad de Qascade viene de parte de su fichero de configuración (_rc). Este fichero define qué entradas de menú se mostrarán y qué programas se ejecutarán cuando seleccionemos estas entradas. Este fichero es leído por Qascade cada vez que se ejecuta o cada vez que pulsamos sobre la tecla ESC cuando el botón principal de Qascade está activado. De esta forma no necesitamos re-ejecutar Qascade cada vez que cambiemos el fichero de configuración, basta con seleccionar el botón principal y con ESC se actualizará la nueva configuración. El fichero de configuración puede tener cualquier nombre, lo que significa que podemos tener varios ficheros de configuración diferentes. Qascade sabe el nombre del fichero que deberá tomar mediante una variable de entorno que es establecida mediante un comando con la siguiente forma:

    setenv "QASCADE_RC=flp1_qascade_rc"

Es necesario identificar en mayúsculas la variable QASCADE_RC, de lo contrario no funcionará. Podemos teclear este comando cada vez que ejecutemos Qascade o podemos colocarlo en el fichero BOOT.

La estructura del fichero RC es definida como:

    Clave(TAB)Texto_menú(TAB)Acción(TAB)Parámetros

O también de la siguiente forma:

    Clave;Texto_menú;Acción;Parámetros

Clave debe ser alguno de los siguientes valores:

    EXEC  - Inicia un programa ejecutable
    ETHG  - Inicia un Thing ejecutable
    MBAS  - Inicia una sesión MultiBASIC
    SBAS  - Inicia una sesión SBASIC
    TITLE – Define un nuevo título de menú 
    MENU  - Inicia la sección de un sub-menú
    MEND  - Finaliza la sección de un sub-menú
    SEP   - Dibuja una línea separadora

“Text_menú” es la descripción de la entrada del menú. “Acción” es el programa que se va a ejecutar (por ejemplo QED, XChange, etc.). “Parámetros” se corresponde con las opciones de la línea de comandos que normalmente se especifican después del comando tras el carácter “;” (por ejemplo EXEC zip;”-x”). Cualquier línea que comienza con el signo # es considerada como una línea de comentario.

Un fichero de configuración muy simpe podría ser este:

      #Un fichero Menú  _rc muy simple
      EXEC;Xchange;flp1_xchange
      SEP
      TITLE;Juegos
      MENU;Juegos
      EXEC;Ajedrez;Chess_exe
      EXEC;Buscaminas;Minefield
      MEND

Ten en cuenta las siguientes consideraciones:
a) Si usas tabulador (TAB) como separador, ssegúrate que tu editor soporta la inclusión del carácter TAB, algunos editores transforman dicho carácter por una secuencia de caracteres en blanco.
b) Fíjate que es posible indicar la unidad y la ruta completa del archivo ejecutable (en ejemplo, Xchange indica el dispositivo) u omitirla, en este último caso se tomará las rutas definidas en PROG_USE y DATA_USE.

A continuación muestro una copia de pantalla de mi sistema en el que se muestra un ejemplo.

Qascade

En definitiva, Qascade es una opción a considerar si deseas en tu QL una interfaz de usario simple y fácil de configurar.

—-
Fuente:
Qascade – A Review. By Timothy Swenson, QL-Hackers Journal.
—-

Curioseando algunos posts en QL-User me he encontrado una referencia de un reciente vídeo subido a youtube sobre el último encuentro internacional del Sinclair QL en Prottes (Austria).

Podemos ver en él un recorrido interesantísimo por una gran variedad de sistemas compatibles con el Sinclair QL. Se muestran algunos sistemas QDOS muy difíciles de ver en acción, tales como:

– SMS 2 sobre Atari ST
– CST Thor
– Sandy QXT 640
– SPEM QL System 2 con ICE Desktop
– Una adaptación especial de un QL con una CPU 68020 en placa.
– Q-Talk, un sintetizador de voz para el QL.
– Q40, el último sucesor hardware del Sinclair QL en acción.
– Una primicia de Q-emuLator para MacOSX. Se trata de una versión beta que saldrá probablemente a finales de año.

En el vídeo vemos también a Urs Koening comentado algunas ideas con Tony Tebby sobre posibles ampliaciones hardware para el QL. Su idea se llama QFC, una tarjeta Compact Flash conectable al puerto ROM del QL de cara a facilitar la desdcarga de ficheros desde Internet.

.

A raíz de los comentarios en un post anterior, me comentaba Badaman una idea que alguna vez ha circulado por ahí, de aportar una especie de disco virtual a un QL empleando un puerto serie y un programa en el PC (corriendo Linux o Windows, …) que actuara de “servidor” de ficheros. (Por lo visto ya existen cosas así para el C64, Amiga, …).

En relación a este tema, hace unos días compré un cable null-modem para hacer una prueba de conectar mi QL al un PC con Q-emuLator. Mi idea era ejecutar en las dos máquinas SMSQ/E y mediante el driver SERNET compartir recursos entre los dos ordenadores. (SERNET es un driver nativo de SMSQ/E para montar una red local empleando un “anillo” de ordenadores conectados vía puertos serie).

Por ahora no he conseguido grandes avances. Sólo he logrado desde el QL volcar “a pelo” información en la pantalla del emulador, pero no he logrado hacer funcionar a SERNET. Leyendo más tarde el manual de Q-emuLator, Daniele Terdina dice que aún no están soportados estos drivers (¡qué pena!). De todas formas tengo pensado escribirle a ver qué me cuenta de todo esto.

También he leído un artículo de Dilwyn Jones sobre SERNET y no aporta gran cosa con respecto a lo que ya dice el manual de SMSQ/E. Lo que sí dice es que él nunca ha logrado el conectar un QL a un PC vía SERNET y que ha tenido dificultades con la construcción del cable adecuado (no sé si es porque no lo ha intentado seriamente). Parece que con SERNET bajo SMSQ/E y de PC a PC no hay problemas, pero de QL a PC parece que sí. Seguramente debido a las peculiaridades de los puertos SER del QL.

Con este panorama, la solución más directa que yo veo para dotar al un QL real de un servidor de ficheros con espacio de almacenamiento “infinito”, es empleando la tarjeta QXL en un PC y usando el puerto NET para comunicar los dos sistemas. Parece que el puerto NET de Sinclair va bien y son compatibles entre el QL y la QXL; y además no habría que escribir drivers en el QL, que es la parte más complicada. El Toolkit II y el SMSQ/E ya nos aportan los drivers necesarios.

Dado que no existen por ahora iniciativas de desarrollo de una expansión tipo CompactFlash o tarjetas SD para sistemas QL, estas opciones son las que serían más realistas hoy en día a la hora de transferir ficheros al QL de forma relativamente cómoda desde un almacén masivo de archivos.