archivo

Sistema

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.

Ya hablamos en una entrega anterior del significado del término Toolkit en el mundo QL y QDOS. En dicho post mencionamos cómo cargarlos y cómo hacer uso de ellos. En esta segunda parte nos centraremos en mencionar brevemente algunos de los Toolkits disponibles para sistemas QDOS.

A continuación detallamos los más importantes y haremos una breve descripción de cada uno de ellos.

1.- TURBO TOOLKIT

Probablemente los dos Toolkits más conocidos son Turbo Toolkit y el DIY Toolkit. El Turbo Toolkit es por supuesto parte del compilador Turbo, pero puede ser usado sin Turbo si lo deseas. Desde que Digital Precision paró el desarrollo de Turbo, George Gwilt continuó trabajando en el compilador y gente como David Gilham ha puesto también un montón de mejoras para adaptarlo a las necesidades de los sistemas QL modernos.

Muchas de las extensiones de Turbo Toolkit son específicas del compilador Turbo, por ejemplo las extensiones que acceden a las estructuras de datos básicas de las directivas del compilador; mientras que otras son más generales, como funciones que te dicen el punto de comienzo de variables en memoria, comandos para buscar en memoria determinados datos y mover bloques de memoria a través de ella.

2.- DIY TOOLKIT

DIY Toolkit son un conjunto de pequeños Toolkits, muchos de ellos en forma un una extensión cada uno. Originalmente fue una serie de artículos en la revista QL World. Simon Goodwin reunión sus artículos y ficheros en una colección de Toolkits y los etiquetó a cada uno con una letra, hasta que utilizó ¡todas las letras del alfabeto!

Las extensiones disponibles son muy diversas e imposibles de resumir brevemente. Puedes por ejemplo, tener un comando Input mejorado, implementado como una función llamada EDLINE$. También extensiones para hacer una búsqueda rápida en memoria, o funciones para extender los puertos de red del QL. Otros ejemplos son los manejadores de “traps” para facilitar las llamadas al sistema operativo. En total hay alrededor de 24 volúmenes que abarcan tres discos flexibles con extensiones para casi cualquier cosa que se pueda hacer vía extensiones. Estos volúmenes vienen también con una amplia documentación y el código fuente de muchas de las extensiones, de tal manera que podemos estudiarlo y aprender cómo el autor abordó la programación.

El DIY es “Cardware”, puedes hacer uso libre de estas extensiones pero el autor pide que le envíes una postal si usas el DIY Toolkit.

Este conjunto de discos con las extensiones son extremadamente útiles, pero si no tienes los artículos originales de la revista puede ser bastante pesado ir por los distintos ficheros doc de los discos para familiarizarse con ellos. Para el programador, es genial, puedes elegir las extensiones que necesites e incluirlas en tu programa.

3.- DJ TOOLKIT

DJ toolkit es un pequeña extensión sorprendentemente útil escrita por Norman Dunbar. Las siglas “DJ” aparentemente vienen de “Dilwyn Jones”, quien elaboró las especificaciones y las usó para algunos de sus programas. Parece ser un tipo de extensión que un programador crea para su uso, pero que puede ser muy útil para escribir cualquier programa en SuperBasic para nuestro propio uso. Incluye comandos para mover bloques de memoria, hacer búsquedas en la memoria, llenar zonas de memoria con un valor específico, funciones para tratar ficheros, funciones para el manejo de cabeceras de fichero, manipulación de variables del sistema, extensiones para manipular fuentes, detección de QPTR, etc. Cuanto más uso este Toolkit más me gusta. No reemplaza al Toolkit 2 y no trata de hacerlo, pero es extremadamente útil. También viene con algunos listados de demostración para ilustrar cómo usar estas extensiones.

4.- EXISTS

Esta es una extensión muy simple escrita por Phil Borman. Tiene un único propósito, la comprobación si existe en tu ordenador una determinada extensión. Retorna un 1 si la tiene y un 0 si no la tiene. A simple vista, parece que no es una extensión muy significativa hasta que realmente la necesitas, por ejemplo para comprobar determinadas extensiones en sistemas moderno.

Por ejemplo, si deseas comprobar que un sistema dispone drivers de color, una forma de hacerlo es ver si está presente la extensión “DISP_COLOR” de la siguiente manera:

IF EXISTS('DISP_COLOUR') = 1 THEN
  REMark el driver de color GD2 está presente
ELSE
  INK #0,7 : PAPER #0,0 : CLS #0 : REMark mode 4 colours
END IF

5.- PDTK

Un pequeño Toolkit de Mark Swift. Suministra un conjunto de extensiones en la línea de las que encontramos en el Toolkit 2. Originalmente fueron escritas para ser incluidas con el emulador de Amiga, pero pueden ser usadas en la mayoría de los sistemas. Ocupa solamente unos 4 kilobytes y el autor ofrece el código fuente en ensamblador para aquellos que quieran estudiarlo. Las instrucciones son breves pero muy completas aunque con pocos ejemplos. Este Toolkit es especialmente útil con los emuladores que no incluyen el Toolkit 2.

6.- HYPERBOLIC FUNCTIONS

Este es un pequeño Toolkit con un conjunto de funciones matemáticas. Se suministran las siguientes funciones SINH, COSH, TANH, COTH, ARSINH, ARCOSH, ARTANH and ARCOTH. No se ofrecen instrucciones sino los ficheros de código fuente en alamán. Podría ser útil para aquellos que quieran utilizar estas funciones matemáticas.

7.- PEX

El objetivo básico de este pequeño Toolkit es permitir que los programas puedan escribir en ventanas de segundo plano. Parece que necesita una ROM Minerva en el QL, o versiones antiguas de SMSQ/E.

8.- TINY TOOLKIT

Es un Toolkit de pequeño tamaño pero muy extenso. Contiene alrededor de 70 extensiones en a penas 9K. Tiene instrucciones en inglés y alemán. Fue escrito por Matthias Leidig hace muchos años y actualizado por Rich Mellor recientemente. Contiene un conjunto muy diverso de extensiones, algunas extremadamente útiles, otras no tanto o de uso menos frecuente.

9.- QVIEW TOOLKIT

Este es un Toolkit escrito por desarrolladores de QView, quienes originalmente desarrollaron la ROM Minerva. El Toolkit, aparentemente fue desarrollado para su uso en un sistema BBS (bulletin board system) de cara a evitar la dependencia de otros kits de herramientas comerciales de la época. Tiene solamente 1K de tamaño pero sus extensiones son muy útiles. Una característica muy positiva es que todas sus extensiones comienzan con TT, con lo cual es poco frecuente que entre en conflicto con otras extensiones. Incluyen funciones de manejo de memoria, funciones para abrir y borrar ficheros, buscar string en memoria, extensiones para facilitar las llamadas al QDOS y cosas así. Un pequeño Toolkit muy bueno, aunque la mayoría de las extensiones están disponibles en otros Toolkit más modernos.

10.- DISPLAY CODE

Este Toolkit apareció en QL Today hace algunos años. Está dirigido a aquellos desarrolladores que quieran hacer uso de sistemas QL modernos, pero de manera que sus desarrollos sigan funcionando en sistemas antiguos siempre que fuera posible. Incluye extensiones para comprobar el tamaño de la pantalla, modo de resolución, si está presente PE, número de versión de QDOS, si los drivers GD2 de color están presentes o no, si gestor de ventanas Window Manager 2 está presente o no, y cosas así. La mayor parte de esto se puede hacer desde SMSQ/E, pero utilizarlo así provocará que nuestro programa sólo funciones en sistemas SMSQ/E. Con un poco de cuidado, puedes usar este pequeño Toolkit en QDOS o SMSQ/E y asegurar que tus programas funcionen bien en los dos sistemas operativos.

CONCLUSION
A medida que usas estas herramientas, encontrarás que hay un cierto grado de solapamiento en la mayoría de ellas, con lo cual deberás elegir el mejor que se adapte a tus necesidades. Por otro lado, el Toolkit 2 original es el más ampliamente aceptado y el que todo el mundo debería tener. La mayoría de los sistemas QL modernos lo incorporan de una manera u otra, en caso contario puedes obtener una copia del los sitios Web que hemos comentado (por ejemplo, en el sitio web Dilwyn Jones).

Prácticamente todos estos Toolkits se pueden obtener de las bibliotecas de software de dominio público, o las Webs más conocidas sobre QDOS como son las de Thierry Godefroy y Dilwyn Jones. Este último sitio Web tiene una página dedicada a los Tookits, si deseas descargar algunos de los que he mencionado, así como muchos que no he mencionado, puedes localizarlos en:

http://www.dilwyn.me.uk/tk/index.html


Autor: David Denham
Traducción y adaptación: afx