archivo

Archivo de la etiqueta: toolkits

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

Uno de los aspectos más sorprendentes del QDOS y del SuperBASIC es la capacidad de cargar archivos binarios para aportar un montón de nuevos comandos al SuperBASIC. La mayoría de los equipos de los años 80 venían con un Basic integrado, pero éstos eran estáticos y no había una forma simple de extenderlos. Otros lenguajes (como C, Fortran o Pascal) usan librerías de funciones y procedimientos que permiten ampliar las capacidades de sus bibliotecas.

La primera extensión importante que se desarrolló para el QL fue el ToolKit (I y II). A partir de entonces el término toolkit fue usado para hacer referencia a extensiones cargables. Algunos de los toolkits más populares son ToolKit II (TKII), DIY ToolKit, y DJToolKit

Los primeros toolkits fueron escritos en Ensamblador, pero es poco conocido que también pueden ser creados con Q_Libertator. El formato de los ejecutables y las extensiones en QDOS son muy similares, y cuando se compilan de hecho pueden ser intercambiables. Esto significa que un ejecutable puede ser cargado también como una extensión.

Para averiguar cómo crear un toolkit, tomaremos como ejemplo una función sencilla, Q_Liberator, y seguiremos una serie de pasos muy simples. La función que vamos a incluir en nuestro toolkit de ejemplo es la siguiente:

10 REMark $$external
100 DEFine FuNction MAYUSCULA$(cad$)
110   LOCal i, temp
120   FOR i = 1 TO LEN(cad$)
130     temp = CODE(cad$(i))
140     IF temp > 96 AND temp < 123 THEN
150       cad$(i) = CHR$(temp-32)
160     END IF
170   END FOR i
175   RETurn cad$
180 END DEFine

Esta función toma cualquier cadena y convierte todas sus letras en mayúscula. El $$external de la línea 10 es una directiva del compilador que le dice a Q_Liberator que la función o procedimiento siguiente debe estar disponible fuera del ejecutable. Para cada procedimiento o función que deseemos convertir en extensión, debemos poner la directiva $$external antes de su declaración.

A continuación, lo que debemos hacer es compilar nuestro pequeño programa. Ya hemos visto en un post anterior en nuestro Blog cómo compilar programas con Q_Liberator.

Cuando compilamos nuestra pequeña función con Q_Liberator, es una buena idea desactivar la opción WINDS, ya que la extensión no necesita canales abiertos. De lo contrario se abrirán 3 canales para ella, siendo esto innecesario para nuestra simple función. Para reducir el tamaño del archivo binario también es una buena idea desactivar las opciones NAMES y LINES. Esto es importante ya que nuestra extensión permanecerá siempre en memoria y cuanto menos espacio y recursos use mucho mejor. Por convención, todas las extensiones se suelen definir en mayúsculas (en nuestro ejemplo MAYUSCULA$). Puedes comprobar esto con el comando EXTRAS donde verás todas las extensiones instaladas en tu sistema.

Si vas a cargar la extensión en un sistema donde ya esté cargado el runtime Qlib, podemos compilar nuestra extensión sin el runtime de Q_Liberator, esto nos ahorrará memoria si hay varias extensiones generadas con Q_Liberator en nuestro sistema. Si no sabes si el runtime QLib de Q_Liberator va a estar disponible en el sistema donde se vaya a cargar tus extensiones, entonces es mejor incluir el runtime en la compilación. Es una buena idea compilar la extensión de las dos formas y luego que sea el usuario el que decida la versión que más se ajuste a su sistema. Nuestra extensión de ejemplo ocupa 448 bytes sin el runtime Qlib, con el runtime ocupa unos 11,200 bytes.

Si cargas una extensión que no incorpora el runtime Qlib, y el sistema donde se ejecuta tampoco tiene cargado este runtime, no recibirás un mensaje de error cuando cargues la extensión (con LRESPR por ejemplo). Sin embargo, cuando invoques alguna función o procedimiento de dicha extensión recibirás un error. El mensaje de error exacto es:

Error “Runtimes Missing !”

Una vez hayas compilado una extensión, todo lo que se necesita es cargar la extensión con LREPSR y probarla. Recuerda que no puedes cargar una extensión con LRESPR cuando cualquier otro trabajo, distinto del Job 0 (SuperBASIC), se está ejecutando.
A partir de ahora, ya tienes una nueva función en SuperBASIC (cada vez que cargues esta extensión) y usarla como cualquier otra función nativa del lenguaje, algo similar a esto:

100 PRINT MAYUSCULA$("hola mundo, mi primera extensión")

Con esta simple guía y el uso de Q_Liberator, ¡ya puedes desarrollar nuevos comandos para ampliar el SuperBASIC!


Fuente:
Artículo original de Timothy Swenson
en QL Hacker’s Journal

toolkit_imgSeguramente todos hemos escuchado alguna vez el término de “toolkit”, pero ¿qué significa este término realmente?

Supuestamente, se trata de un tipo de herramientas de programación que nos ayuda en determinadas tareas. En algunos ordenadores estos toolkits pueden ser herramientas software diseñadas para llevar a cabo tareas específicas, como una serie de rutinas listas para usar y que simplifican al programador la escritura de software complejo.

En el QL, la interpretación de este término estuvo influenciado desde el día en el que Sinclair y Tony Tebby liberaron las versiones del Toolkit 1 y Toolkit 2.

El Toolkit 1 fue un predecesor del Toolkit 2. Fue vendido en cartuchos Microdrive por la división software de Sinclair Research. Un poco más tarde, Tony Tebby liberó las primeras versiones del Toolkit 2 que nosotros conocemos y apreciamos hoy en día.

Las primeras ediciones del Toolkit 2 eran suministradas generalmente en EPROM’s de 16K que se conectaban el conector de la expansión ROM de la parte trasera del QL. Había también una versión en cartucho microdrive, en el cual tú podías seleccionar las partes del Toolkit que necesitabas, lo que era muy útil para QL’s sin expansión donde la memoria era muy limitada. Aparecieron también versiones recortadas que se suministraban con las interfaces de disco – los comandos eran los mismos que el Toolkit 2 completo, pero no todos los comandos estaban disponibles, sólo aquellos que correspondían a la interfaz de disco.

El Toolkit 2 nos da un conjunto de nuevos comandos en SuperBASIC y suministra muchas facilidades así como la mejora de otras características disponibles en el QL estándar. Entre ellas está el manejo de la red local, los directorios por defecto y el la utilización de comodines para la gestión de ficheros, así como otras muchas.

Todo esto era percibido por los usuarios con el término de “toolkit” – para la mayoría de nosotros era una EPROM o un paquete de software que nos daba comandos extra en SuperBASIC.

Con el paso del tiempo, prácticamente la mayoría de los sistemas se suministraban con el Toolkit 2 preinstalado. Entre los ejemplos más destacados tenemos las interfaces de Miracle System (Trump Card y Gold Card por ejemplo) las cuales tenían una implementación completa del Toolkit 2 en placa. Aquellos que usan SMSQ/E en sus sistemas de forma estándar, todas las facilidades del Toolkit 2 están incluidas en el SBASIC.

Tony Tebby permite actualmente una distribución limitada del Toolkit 2 para quienes lo necesiten, por ejemplo, en el uso de emuladores QL.

Lo que pretendo hacer con esta serie de artículos es examinar algunos toolkits disponibles que suministran extensiones al SuperBASIC o al SMSQ/E. Hay muchos de ellos por ahí que son gratuitos y se pueden obtener de las librerías de dominio público y de varios sitios Web.

Aunque yo nunca he visto el libro, me han dicho que la mayoría de las extensiones en forma de toolkits para el QL se enumeran en el manual de referencia SuperBASIC de Rich Mellor – véase el detalle en los anuncios de publicidad de RWAP, aunque te advirtió que cuesta 20,00 libras.

INSTALACIÓN DE TOOLKIT’s

La mayoría de los toolkits son suministrados en discos. Generalmente se suelen instalar en el área de procedimientos residentes con las sentencias RESPR, LBYTES, y CALL.

El comando RESPR reserva una cantidad de espacio en memoria (a especificar) en el área de procedimientos residentes. Este espacio es generalmente del mismo tamaño que el tamaño del fichero que contiene el toolkit en el disco. La mayoría de los toolkits vienen en un sólo fichero que contiene todas las extensiones. El nombre del fichero generalmente tiene una extensión o sufijo de 3 o 4 caracteres como uno de estos ejemplos (aunque algunos no tienen extensión o tienen otra extensión menos común):

_BIN, _CDE, _REXT, _RXT, _EXT

BIN es una abreviatura de binario, CDE es de código (code), REXT es de “Runtime Extensions” y EXT de extensión. Mientras que el requisito de memoria es al menos el mismo que la longitud del fichero, puedes averiguar el espacio a reservar con la función FLEN que te devuelve el tamaño del archivo. Supón que tienes un toolkit llamado FLP1_TOOLKIT_EXT, el comando PRINT FLEN(“FLP1_TOOLKIT_EXT”) te dirá cuanta memoria necesitas reservar.

El fichero que contiene el toolkit debe ser cargado en esa área de memora con el comando LBYTES, a continuación debemos usar el comando CALL para hacer que el ordenador ejecute una pequeña pieza de código en el toolkit que lo vincula al sistema y le dice al QL el nombre de los nuevos comandos y funciones contenidos en él. Aquí hay un ejemplo. Nosotros asumimos que el tamaño del fichero TOOLKIT_EXT es de 1234 bytes:

100 base = RESPR(1234)
110 LBYTES FLP1_TOOLKIT_EXT,base
120 CALL base

La mayoría de los toolkits son inicializados mediante una llamada a la dirección base del bloque de código que se utilizó cuando éste fue cargado en la memoria. Algunos de ellos tienen ciertas necesidades específicas y requerimientos bastante diferentes, los cuales suelen estar documentados en sus instrucciones. También hay toolkits que tienen requerimientos diferentes cuando se intentan enlazar dentro de un programa compilado en Basic, pero esto es un tema aparte.

Las tres líneas del ejemplo anterior son incluidas generalmente en un fichero de arranque de algún tipo. La mayoría de los toolkits vienen son sus propios programas de arranque, y mirando su código generalmente podemos averiguar cómo añadir ese código de inicialización a nuestros propios programas de arranque con sólo rastrear las líneas con los comandos RESPR/LBYTES/CALL. Muchos programas de gran tamaño suelen cargar también pantallas de presentación durante el proceso de arranque. Debes también tener cuidado porque muchos programas suelen incluir secuencias de inicio propias y algo enrevesadas, por eso a veces es difícil extraer el mínimo de información que tú necesitas.

Si tu sistema dispone del comando LRESPR, puedes reemplazar las tres líneas anteriores con una sola llamada, por ejemplo:

100 LRESPR FLP1_TOOLKIT_EXT

El comando LRESPR automáticamente reserva la memoria que coincide con la longitud de archivo, carga el fichero y hacen un CALL a para enlazar el toolkit en el Basic.

EL ORDEN EN UN PROGRAMA DE INICIO

No hay una regla fija para establecer un orden correcto en la secuencia de arranque en los programas de inicio, pero a medida que tienes más experiencia esto suele ser cada vez más fácil. En general, el código del QL no es muy quisquilloso en cuanto al orden en el que debe ser cargado las distintas extensiones y toolkits, pero hay algunas reglas simples que te pueden ayudar:

Si tu sistema tiene una copia del Toolkit 2, que exige un comando para ser inicializado, éste debería ser cargado al inicio del programa de arranque. Por ejemplo, 100 TK2_EXT es un ejemplo de un comando necesario, en algunas expansiones de disco que vienen con el Toolkit 2 integrado, para hacer visible el toolkit desde el SuperBASIC.

Si tu sistema tiene algunos aceleradores de pantalla como el Speedscreen o el Lightning, generalmente es mejor cargar estas extensiones primero en el arranque de tu sistema, antes que otras extensiones y toolkits.

Si tu sistema usa el entorno de ventanas (pointer environment o PE), que es proporcionado con los archivos llamados PTR_GEN, WMAN y HOT_REXT, éstos deben ser instalados generalmente antes que otros toolkits.

PE (Pointer Environment) integra una facilidad llamada HOTKEY, que está generalmente configurada por un comando como HOT_GO. Los toolkit se cargan generalmente antes de este comando. Asimismo, los toolkits deberían ser cargados antes que cualquier otro programa ejecutable. Esto es debido a que no se puede asignar memoria del área de procedimientos residentes (RESPR) mientras se esté ejecutando cualquier otra tarea, en estos casos recibirás un mensaje parecido a “Not Complete”.

Así que tu programa de inicio probablemente tendrá una secuencia de carga en el siguiente orden:

– TK2_EXT en caso de ser necesario para hacer disponible el Toolkit 2 .
– Instalar cualquier software de aceleración de pantalla.
– Instalar PE (pointer environment) si lo usas.
– Instalar calquier Toolkit .
– Definir las teclas rápidas, etc
– Enviar un comando HOT_GO para despertar las teclas de acceso rápido en caso de que las utilices.

Estas son sólo unas directrices sencillas si bien pueden variar de programa a programa.


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

Revisando las entradas sobre QL en Friendfeed, otra red social en auge, me encuentro con este artículo que a su vez viene de una noticia en el foro de Hacker News y que habla sobre una pequeña extensión al SuperBASIC creada por Linus allá por 1986 que fue publicada en la revista BITTI de Finlandia (el artículo parece esta en suomi).

GMOVE, que es como se llama el invento, es un nuevo comando que realiza funciones de blitter en una ventana de QL, es decir, mueve bloques de pixels en pantalla. Ya lo dice el encabezado de la noticia original (“Onko joskus tullut eteen tilanne,…“):
linus_list

“¿Alguna vez te has encontrado una situación en la que quisieras mover parte de una ventana a otro lugar? Esta tarea no podrá hacerse sin ampliar del juego de instrucciones BASIC. Esto añade al conjunto de instrucciones del QL el comando GMOVE, con el que puedes mover un gráfico, por ejemplo, dentro de un programa de dibujo.”

Su sintaxis es la siguiente:

GMOVE (#ch),x1,y1,l,k TO x2,y2

Aparentemente mueve un bloque de medidas l,k (ancho x alto imagino) que empieza en las coordenadas x1,y1 a la posición x2,y2 dentro de una ventana o canal ch (por omisión, como es costumbre, el canal 1).

Una vez tecleamos el listado SuperBASIC que aparece en la revista, se genera un fichero de código máquina en mdv1_ llamado GMOVE que podremos cargar cuando queramos mediante:

A=RESPR(704)
LBYTES mdv1_GMOVE,A
CALL A

Una vez hecho esto, ya tendremos conectada al SuperBASIC la nueva instrucción GMOVE.

¿Alguien se anima a “picar” el programita?

Turbo fue el segundo de los compiladores SuperBASIC publicado por Digital Precision Limited (el primero fue Supercharge). Originalmente, el compilador Turbo fue obra de Simon N. Goodwin, acompañado de un equipo de personas como Freddy Vachha (MD de Digital Precision), Chas Dillon, Dave Newell y Gerry Jackson. Recientemente Turbo ha pasado a ser freeware (lo que significa que se puede copiar y obtener copias de forma gratuita) respaldado por George Gwilt, un experimentado programador QL cuyo trabajo incluye el desarrollo del ensamblador GWASS y GWASS Lite (Gwasl).

¿Por qué usar un compilador BASIC?

Un compilador SuperBASIC toma un programa BASIC y lo convierte en un programa que puedes ejecutar con EXEC. Normalmente el resultado es que el programa se ejecuta muchísimo más rápido, un programa varias veces más pequeño, un programa en el que el usuario no tiene porqué ver el código fuente SuperBASIC y un programa mucho más seguro ya que el programador puede beneficiarse de mejores mecanismos para el tratamiento de errores disponible en programas compilados. Los programas compilados, a menudo corrigen bugs derivados de versiones antiguas del BASIC como pueden ser las versiones de la ROM JM y JS, y asegura que el programa se ejecute de una forma consistente en todas las versiones de ROMS donde ciertos comandos podrían no trabajar completamente igual a las versiones más tempranas de la ROM del QL.

Un programa compilado no tiene que ser interpretado cuando se ejecuta, por lo que generalmente se ejecutará más rápido que el programa original. Turbo pretende convertir el programa original en un programa equivalente en código máquina. Hay dos tipos de compiladores, los que compilan a un código intermedio (por ejemplo el compilador Q-Liberator) y aquellos que compilan a código máquina (o lo más cerca posible). Esto creó una gran discusión en los primeros días sobre cuál era el mejor compilador para el usuario QL, pero la conclusión era que ambos tenían características destacables y que la elección dependía de lo que se pretendiese hacer. Turbo siempre tuvo la ventaja de la velocidad, pero tiende a ser estricto con aspectos de la sintaxis y tiene reglas ligeramente diferentes con respecto al paso de parámetros por referencia a y desde procedimientos y funciones. Por otro lado Q-Liberator siempre fue preferido por aquellos que trataban de compilar programas que hacían uso de “Pointer Environment” (PE, el entorno de ventanas para QDOS).

En estos días, los argumentos tienden a diferenciarse menos. En los rápidos sistemas QL-compatibles de hoy en día, el argumento de la velocidad es menos importante. Turbo es un proyecto libre y todavía mantenido con nueva versiones que aparecen de vez en cuando. Q-Liberator sigue siendo un programa comercial, y aunque no se producen nuevas versiones, sigue siendo hasta la fecha, sorprendentemente compatible con los sistemas modernos.

Siempre he sido un fan de ambos compiladores y pensé que sería el momento de echar una nueva mirada a Turbo ya que ahora es gratuito y ofrece un montón de nuevas facilidades que se han actualizado.

Turbo siempre se ofreció con un pequeño toolkit que contenía extensiones muy útiles al BASIC, algunas de ellas eran específicas para Turbo (otras son de uso general). Estas incluyen por ejemplo un “capturador” de errores para funciones INPUT. Más recientemente, Turbo Toolkit ha sido actualizado por David Gilham y George Gwilt

Este artículo está basado en las siguientes versiones del compilador Turbo y Turbo Toolkit:

Compilador Turbo (parser) versión 4.20
Turbo Toolkit versión 3.34

¿Dónde puedo conseguir el compilador Turbo?

El compilador Turbo y su Toolkit se puede obtener desde la mayoría de las librerías de dominio público del QL y de varios sitios Web. La fuente principal es el sitio Web del grupo escocés de usuarios QL de John Sadler:
http://www.jms1.supanet.com

También del sitio Web de Dilwyn Jones, en:
http://www.dilwyn.me.uk/turbo/index.html

Los manuales de Turbo son de acceso libre y puedes obtener también los fuentes si estás interesado en el diseño del compilador, aunque estos no son necesarios para el uso general de compilador.

Merece la pena obtener los nuevos manuales, incluso si tienes los originales de Digital Precision, ya que gente como Timothy Swenson han puesto gran esfuerzo en la actualización del contenido.

Puede que valga la pena conseguir los “Programas de Asociados”, un conjunto programas adicionales que aunque no sean indispensables para el uso de Turbo son muy útiles.

¿Cómo instalar Turbo?

Si has descargado los paquetes de Turbo desde los sitios Web que hemos comentado, habrás obtenido archivos en formato zip. Estos archivos deben ser descomprimidos con la versión QL del programa Unzip. No intentes descomprimirlo la versión Unzip de PC o de otro sistema, lo más probable es que pierdas las cabeceras de los ficheros ejecutables y no funcionen.

Una vez que hayas descomprimido los ficheros obtendrás los siguientes ficheros.

Turbo:
PARSER_TASK   - esta es el 'parser', que lee y comprueba
                el programa original SuperBASIC.
CODEGEN_TASK  - este es el generador de código, que
                produce el programa compilado final.
T_CONFIG_DATA - junto con T_CONFIG_LOAD establece el bloque
                Confing estándar en los programas.
UTILITY_TASK  - permite configurar Turbo Toolkit, etc.
CHANGES_TXT   - un fichero de texto que detalla los cambios
                recientes aplicados a Turbo.

Turbo Toolkit:
TURBO_TK_CODE - el Turbo Toolkit completo,
                para uso general
TURBO_SMS_CODE- una versión de Turbo Toolkit ligeramente
                más pequeña para usuarios de SMSQ/E.
TURBO_REM_CODE- un suboconjunto de Turbo para la inclusión
                en programas compilados.
TURBOBASE_ASM - código fuente en ensamblador del toolkit.

Turbo Manuals:
TURBOTOC_TXT  - Tabla de contenidos del manual.
TURBOS1_TXT  a
TURBOS4_TXT   - manual de Turbo en cuatro secciones.
UTILITY_TXT   - manual de las utilidades
T_CONFIG_TXT  - manual de T_CONFIG_DATA y T_CONFIG_LOAD
TASCOM_TXT    - manual para Task Commander, una utilidad
                que ayuda a convertir un porgrama compilado
                en una extensión del BASIC (es decir, un
                fichero que puede ser cargado con
                LRESPR en lugar de EXEC)
TURBODEM_TXT  - describe el contenido de los ficheros de
                demostración de Turbo Toolkit suministrado
                en el paquete de "Programas Asociados"

Adicionalmente, estos documentos de referencia también están
disponibles, pero realmente no los necesitas al principio

TURBOREF_TXT  - fichero de referencias. Listado de mensajes de
                error y comandos del Turbo Toolkit en orden
                alfabético
LINKLOAD_TXT  - ejemplos de cómo usar LINK_LOAD
INTFILE_TXT   - explicaciones de Simon Goodwin sobre la generación
                de código intermedio producido por el "parser"
                para el generador de código.
TURBOREP_TXT  - un artículo de Simon Goodwin acerca del diseño
                de Turbo.

Programas asociados:
TASCOM        - Task Commander transforma un ejecutable en un
                comando SuperBASIC.
DATASPACE_TASK- un programa que cambia el área de datos
                de una tarea.
LIBRARY_MANAGER-un programa que extra rutinas
TURBO_TK_DEMOS- un conjunto de programas de demotración con
                procedimientos y funciones útiles.
MAKE_MODULES  - una utilidad para partir un programa
                SuperBASIC en módulos más pequeños.

Descomprime todos los ficheros que piensas que vas a necesitar y ponlos todos juntos en un disquete o en un directorio de tu disco duro. Si intentas usar Turbo Toolkit deberás cargarlo primero mediante RESPR o LRESPR.

LRESPR FLP1_TURBO_TK_CODE

Existen tres versiones diferentes de Turbo Toolkit. Turbo_TK_Code es la apuesta más segura en el sentido de que funcionará bien en todos los sistemas. Turbo_SMS_Code sólo funcionará en sistemas SMSQ/E, y tiene la ventaja que es ligeramente más pequeño (si estás usando SMSQ/E Turbo_SMS_Code es la versión que debes usar, ya que se añade soporte a algunas características avanzadas de SMSQ/E). La tercera versión, Turbo_REM_code, es más reciente y adaptada a las nuevas versiones de Turbo, donde puedes incrustar el toolkit dentro de un programa compilado, en lugar de tener que cargarlo previamente con LRESPR. Para ver cómo “incluir” o “adjuntar” esta facilidad tendrás que mirar en el fichero CHANGES_TXT el uso de la directiva REMark %%:

REMark %%<filename>,a,b

El nombre de fichero a incluir está indicado por y puede llevar dos parámetros, a y b:

a es el desplazamiento al código de inicialización en el fichero, o 0 si no hay rutina de inicialización.

b es el desplazamiento a la tabla de inicialización.

La línea con REMark %% pude estar en cualquier lugar dentro del programa SuperBASIC. Ésta es una característica avanzada y por ahora no necesitas saber nada más sobre esto.

Turbo_Rem_Code es una versión especial de Turbo Toolkit diseñada para la inclusión en el programa compilado, y utiliza la directiva

REMark %%flp1_turbo_rem_code,6,10

Una vez que has cargado Turbo Toolkit, puedes cargar tu programa SuperBASIC y listar o editar algunas líneas para garantizar que es un programa listo para ser compilado.

Ahora debemos asegurarnos que el valor predeterminado de PROG_USE está apuntando a la unidad de disco o subdirectorio que contiene los programas PARSER_TASK y CODEGEN_TASK. Si se está apuntando a otro lugar, el comando CHARGE que se utiliza para iniciar el compilador no encontrará los programas necesarios. Así, suponiendo que el compilador está en FLP1_ el comando PROG_USE FLP1_ hara que Turbo esté lista para empezar a compilar. Introduce ahora el comando CHARGE y deberás ver la aparición del panel principal de configuración del compilador (ver figura 1).

Turbo, Panel principal

Turbo, Panel principal

Si por alguna razón el comando CHARGE no funciona, puedes también iniciar el proceso de compilación con los comandos EXEC_W o EW:

EW PARSER_TASK:EW CODEGEN_TASK

que esencialmente es lo que hace el comando CHARGE.

Este panel frontal te permite establecer una serie de opciones para configurar el proceso de compilación. En la línea superior se muestra una serie de información general y si se han detectado errores o no.

En la tercera línea hacia abajo, en el primer cuadro te permite elegir entre las opciones FREEFORM o STRUCTURED. Esto establece el nivel de comprobación para programas que estén correctamente estructurados o no. Para activar esas opciones usa las teclas del cursor y activa o desactiva la opción con la tecla ESPACIO. El siguiente cuadro de elección selecciona si deseamos utilizar código de 16-bit o no. Si el programa compilado es corto (menos de 64 kilobytes) Turbo intentará usar código de 16 bits para generar un programa más pequeño y más rápido.

La siguiente opción permite establecer si deseamos incluir número de línea en el programa compilado. Esto tiene incidencias en el tamaño del programa compilado, pero por supuesto hace que sea más fácil depurar programas porque los mensajes de error nos indicarán el número de línea donde se produjo dicho error. La siguiente opción te permite elegir las opciones BREVE, FAST y REMs, y por último en esta misma línea en la caja de selección del extremos derecho podremos configurar cuantas ventanas con copiadas desde el BASIC al programa compilado (con cuantas ventanas abiertas comenzará el programa).

En la cuarta línea especificaremos el nombre del fichero del programa compilado. Hay un valor por defecto o RAM1_TEST_TASK cuando lo ejecutas por primera vez. Puedes cambiar esto si lo deseas usando el Config estándar o el programa MenuConfig para configurar los valores por defecto incluidos en PARSER_TASK. No hay bloques de configuración en CODEGEN_TASK o Turbo Toolkit.

En la quinta línea puedes especificar los objetos de datos (el espacio para datos del programa compilado, que por defecto son 2 kilobytes) en el cuadro de la izquierda (este valor se puede cambiar más adelante por medio de un programa llamado DATASPACE_TASK). En la caja de parte derecha de esta línea, puedes especificar cuanta memoria se reserva para el buffer del compilador, que tiene influencia en la velocidad de compilación. Los sistemas QL modernos tienen un montón de memoria, así que no hay necesidad de escatimar en este apartado.

En el cuadro de informe (Report) se puede especificar el nombre de un fichero al cual se enviará los detalles de la compilación. Esto ayudará en el análisis de los errores generados. También en el nombre del TASK podemos especificar el nombre de la tarea para el programa compilado, este es el nombre que verás cuando se usa el comando JOBS para ver la lista de programas en ejecución.

En la línea inferior se pueden establecer una cadena de opciones para la compilación de programas (ver el manual para más detalle). Por último, en la línea inferior se encuentra las opciones para salir (Quit) del panel.

Una vez establecidas las opciones deseadas debemos desplazarnos al cuadro del centro y pulsar ENTER para comenzar la compilación (cuadro COMPILE). El proceso de compilación comenzará, tomándose algún tiempo dependiendo el tamaño del programa a compilar. Si se producen errores serios, aparecerá un mensaje y el analizador (Parser) parará su ejecución, ya que en otro caso se producirán resultados inesperadas en la fase de generación de código.

Si todo ha ido bien y no se han producido errores, tendrás un bonito programa compilado listo para ejecutar con EXEC. Por supuesto, recuerda que si has generado el programa en un RamDisk, necesitas grabar el programa a disco antes de apagar o reiniciar tu QL, en caso contrario lo perderás. La compilación a un disco RAM puede ser mucho más rápida que compilar a un disco flexible, especialmente útil en las compilaciones de prueba.

Hay algunas otras opciones disponibles con el comando CHARGE, que ayudarán a automatizar el proceso de compilación en cierta manera:

CHARGE ‘nombrefichero’ especifica el nombre de fichero para el programa compilado.

El comando CHARGE \ con la barra invertida a continuación, compilará automáticamente el programa usando la configuración por defecto y saltando el panel principal. Esto es de muy útil si quieres compilar rápidamente un programa para uso propio o para pruebas sin molestarte demasiado sobre los ajustes del compilador.

Para complicarte un poco la vida (más fácil una vez que te acostumbras, especialmente en la elaboración de programas más complejos) existen una serie de directivas para especificar al compilador muchas de las opciones establecidas en el panel principal. Por ejemplo, el comando TURBO_model 1 fuerza al compilar a crear programas como si se hubiera especificado el “<64” en el panel frontal. TURBO_objdat ’50 ‘ asignará 50 KB al espacio de datos en el programa compilado. Si estas desarrollando varios programas complejos, puedes incluir esas directivas en tu programa para estandarizar de forma consistente el proceso de compilación cada vez que cambias algo.

¿Cuánto de compatible es el compilador Turbo?

La respuesta no es inmediata. Necesitas leer extensos ficheros de documentación suministrados con el compilador para encontrar exactamente qué se compilará y qué cosas no se compilarán correctamente. Para un uso general, sólo necesitas algunas directrices simples para conseguir que pequeños programas se compilen sin ningún problema.

Para programas más complejos, necesitarías leer los manuales con más detalle, pero te acostumbrarías rápidamente a los cambios. Las principales novedades que fueron para mi más destacables son las facilidades de manejo de errores (Turbo tiene su propio sistema de captura de errores WHEN_ERROR 1 Y WHEN_ERROR 2 a diferencia el del comando WHEN ERRor de SuperBASIC/SBASIC), el uso del paso de parámetros por referencia (para usar parámetros por referencia se debe emplear el comando REFERENCE en la definición de la lista de parámetros), y la necesidad del uso cuidadoso de la dimensión de los string en comparación a la declaración de string del BASIC ordinario.

Se han hecho varios cambios en el compilador desde la popularización de SMSQ/E. El comportamiento de las ventanas se ha mejorado mucho cuando Pointer Environment (PE) está presente, por ejemplo.

George Gwilt ha desarrollado algunas utilidades para el uso del Compilador Turbo. La más destacable es TurboPTR, una utilidad bien pensada para escribir y compilar programas bajo PE. En cierto modo se puede comparar al toolkit QPTR de Tony Tebby, pero TurboPTR está específicamente orientado al uso de Turbo.

Las utilidades Turbo-config o T-Config te permiten incluir bloques de configuración para el uso de programas compilados.

Los ‘Associated Programs’ son versiones actualizadas incluidas con la versión original de Turbo, actualizadas para trabajar mejor en los sistemas recientes y para aprovechar mejor las facilidades disponibles en los sistemas QL recientes.

Resumen

El compilador y el Toolkit han tenido una importante remodelación en los últimos tiempos y merece la pena obtener una copia actualizada. Si tu única experiencia con Turbo ha sido con versiones anteriores correspondientes a la primera década del QL, o simplemente has leído algo de la versión original de Digital Precision deberías descargarte la nueva versión y probarlo. Es un paquete bastante complejo, y por supuesto, la gran cantidad de documentación puede hacer desistir a muchas personas a intentar aprenderlo.

Una serie de nuevos comandos y variaciones en otros se han añadido a Turbo Toolkit y al Compilador Turbo en los últimos años, especialmente destinados a facilitar la tarea a los usuarios de SMSQ/E y GD2, en estos casos bien merece la pena la actualización a las últimas versiones.

Hay muchas más cosas que decir sobre Turbo pero no caben en un artículo corto como éste. Espero que este breve recorrido te ayude a comenzar con él y te anime a utilizar el Turbo Toolkit y el Compilador Turbo después de todo el trabajo realizado por gente como George Gwilt y David Gilham para poner día este fantástico compilador.


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

En Internet hay variedad de información sobre el QL en cuanto a emuladores, hardware diverso (como el Q40/Q60), manuales, así como una gran colección de software. Pero para un recién llegado a este “mundillo” o para cualquier entusiasta de la retroinformática que intente resucitar un viejo QL, tanta información al principio tal vez sea un poco confusa, al menos lo era para mí hace algunos años cuando intenté retomar esta afición después de un largo periodo de ausencia.

Si disponemos de un QL básico y queremos ampliarlo es conveniente saber qué tipo de ampliación nos conviene y las distintas opciones que existen a la hora de adquirir esas ampliaciones (eso si, … en caso de que tengamos la suerte de encontrarlas de segunda mano o en algún proveedor que aún tanga stock).

Para allanar un poco el camino a quien lo necesite, he traducido (o más bien “castellanizado”) un buen artículo de Dilwyn Jones sobre este tema. Este artículo ofrece una doble vertiente, por una parte ofrece una especie de historia del QL y por otra parte sirve como enseñanza a aquellos usuarios que regresan al QL después de un período de ausencia y que desean actualizar sus conocimientos.

El artículo completo está dividido en dos partes, una primera centrada en el hardware y la segunda en el software. Bueno, aquí va la primera parte.

———————————–

Expandiendo tu QL parte 1


Dilwyn Jones
Tal-y-bont, Gales, Reino Unido.

Traducción: Afx
abril de 2009


Este artículo está inspirado en la correspondencia que tuve con un ex-usuario que ha redescubierto su QL diez años después de que lo almacenara en su ático sustituyéndolo por un equipo como el que utilizaba en su trabajo.


Tras su jubilación, con más tiempo en sus manos, él se había tropezado con el QL a través de un sitio web y comprobó que todavía había un gran interés por este sistema. Después de haber enviado unos cuantos mensajes de correo electrónico y de haber realizado algunas llamadas telefónicas, desempolvó su QL sin ninguna ampliación que aún conserva, y se encuentró con que todavía funciona después de diez años almacenado. Redescubrió entonces un interés por la máquina y por la programación en SuperBASIC.


En Internet, había encontrado información sobre el nuevo hardware como el Q40 y varios emuladores QL, pero estaba interesado en gastar lo menos posible en un Kit mínimo para el QL, suficiente para la programación en SuperBASIC y para el uso de procesamiento de textos mínimamente aceptable. Durante su correspondencia conmigo, se hizo evidente que hay una gran cantidad de información disponible del mundo QL sobre los últimos acontecimientos, pero no sobre los productos de los años precedentes. Así que decidí escribir un artículo sobre la ampliación de un sistema basado en el QL. Este artículo ofrece una doble vertiente, por una parte muestra una especie de historia del QL y por otra parte sive como enseñanza a aquellos usuarios que regresan al QL después de un período de ausencia y desean actualizar sus conocimientos.


Las expansiones del QL se dividen principalmente en las siguientes categorías:



PUERTOS DE EXPANSIÓN


El QL tiene varios puertos que permiten que otros dispositivos puedan conectarse a la máquina, también permiten que otros QLs puedan ser conectados para formar una red.


1. RANURA DE EXPANSIÓN DEL SISTEMA


En el lado izquierdo de la QL hay una cubierta desmontable que oculta un conector de expansión de 64 pins. Esta es la principal vía de expansión, se pueden conectar tarjetas de memoria, disqueteras, etc., empleando esta ranura.

Vista Posterior

Vista posterior, puertos de expansión:
Conectores de red, (alimentación), video (RGB y UHF), puertos serie y puertos joystick.

2. RANURA EPROM


En la parte posterior del QL hay una ranura de expansión de 30 vías en la que se puede conectar una EPROM. Esta placa sólo puede llevar una EPROM de 16 kilobytes y suele ser utilizada para conectar al sistema una ROM extra, tales como extensiones para el intérprete SuperBASIC (denominados Toolkits ROM, ver más abajo), aunque en los últimos años, ingeniosos diseñadores de hardware han desarrollado formas de utilizarlo para agregar nuevos periféricos, ya que el QL sólo posee una ranura de expansión ROM.


3. RANURA PARA EXPANSIÓN DE MIDRODRIVES


Esta es una pequeña ranura en el lado derecho de la QL que sólo sirve para añadir unidades de Microdrives extra al QL. Como Sinclair nunca desarrolló esas unidades Microdrive extra, esta ranura parece ser redundante, si bien puede tener dos usos. En primer lugar, puede servir para llevar una pequeña cantidad de energía a otros periféricos o complementos, en teoría, es posible sacar alimentación eléctrica de este conector, y en segundo lugar, se podrían utilizar para conectar unidades de Microdrives del Spectrum. Si alguna de las unidades Microdrive de tu QL no es demasiado fiable, podrías, por ejemplo, copiar un cartucho de Microdrive poniendo el original en el Microdrive del Spectrum (que sería MDV3_) y copiarlo a la unidad Microdrive utilizable del QL. Una advertencia, las unidades Microdrive del Spectrum no siempre formatean de forma correcta los cartuchos de Microdrives con el formato del QL, aunque generalmente si lo leen de forma correcta. Aunque los cartuchos Microdrive del QL y del Spectrum son físicamente idénticos, en la práctica los dos equipos formatean las cintas de forma diferente, la del QL normalmente da una capacidad un poco mayor.

Puerto microdrives

Puerto de expansión de microdrives

Puerto ROM

Puerto de expansión ROM

4. CONECTORES DE RED


Estos te permiten conectar dos o más QLs con un cable simple de dos hilos de una forma eficaz, aunque bastante lenta, para formar una red entre los equipos. Por lo tanto, más de un QL (hasta 64 en teoría) pueden compartir impresoras, unidades de disco, etc. Por desgracia, sólo se puede conectar otros QLs a este puerto -no podrías utilizarlo para conectar el QL a un PC o a un Apple Mac, por ejemplo-.


5. PUERTOS SERIE


Estos son puertos RS232C bastante estándar, que pueden ser usados para conectar el QL a impresoras, módems y otros equipos con el cableado adecuado. De hecho, existe un sistema llamado Sernet (desarrollado por Bernd Reinhardt, el antiguo Midinet), que permite la creación de una red entre QLs y otros equipos que ejecuten sistemas operativos compatibles QL o emuladores QL utilizando un cable serie.


El QL tiene dos puertos serie, pero hay limitaciones en su uso. La velocidad máxima es 19200 baudios o 9600 baudios, dependiendo de para que se esté utilizando, además es difícil usarlos de forma independiente para diferentes aplicaciones.

6. PUERTOS DE JOYSTICK


Estos puertos localizados en la parte posterior del QL han recibido poca atención, pero permiten que se puedan añadir dos joysticks tipo Atari al QL. Para simplicidad, los joysticks pretenden emular pulsaciones de teclas. Los movimientos arriba / abajo / izquierda / derecha del joystick emulan pulsaciones de las teclas del cursor y el botón de disparo emula una pulsación de la tecla espacio. De esta manera es fácil de leer las acciones del joystick con la función INKEY$ del SuperBASIC por ejemplo.


7. VIDEO


El QL tiene un modulador de televisión, permitiendo que el equipo se pueda utilizar con un televisor doméstico. También tiene una salida de vídeo compuesto para conectar a monitor monocromo o a algunos grabadores de video. El mismo conector permite la conexión con la mayoría de los monitores de vídeo RGB, pero tristemente no a los modernos monitores SVGA. Algunos artículos en la revista QL Today muestran cómo conectar el QL a modernos aparatos de TV empleando el conector SCART / Peritel.

A lo largo de los años, se han desarrollado diferentes tipos de periféricos. A continuación, vamos a echar un amplio vistazo a los distintos tipos de dispositivos que se han producido. Prácticamente la mayoría de ellos no están disponibles en la actualidad, aunque se pueden encontrar en venta de segunda mano o a través algunos comerciantes que aún venden diferentes equipos QL. Con un vistazo rápido a algunas de las revistas recientes como QL Today, Quanta y algunos sitios web se pueden localizar los datos de contacto de algunos suministradores que aún venden productos para el QL.

AMPLICACIONES DE MEMORIA


El QL básico sin expandir viene con sólo 128 kilobytes (KB) de memoria RAM. Si bien esto podría ser suficiente para escribir programas simples en BASIC y como procesador de textos básico, esta cantidad de memoria es muy restrictiva para la mayoría de los usuarios del QL. En teoría, se puede añadir más memoria en el interior del QL. En la década de 1980 algunas empresas ofrecían esta ampliación como una actualización, pero lo más común era comprar una tarjeta de expansión de memoria que se conectaba a la ranura de expansión del sistema en el lado izquierdo del QL. Las memorias de expansión originales solían tener sólo 128 o 256 kilobytes de memoria, pero con el abaratamiento de los chips de memoria y el aumento de la densidad de integración los fabricantes pronto llevaron la ampliación al límite impuesto por el diseño estándar del QL, 640 Kilobytes (128KB del QL estándar más una ampliación de 512 KB). Durante muchos años, esta era la expansión “estándar” para un QL y, de hecho, estas unidades siguen siendo muy adecuadas si todo lo que deseas es añadir algo de memoria a la QL y aún te conformas con un sistema basado en los Microdrives. El problema con estas expansiones de memoria es que muchas de ellas no tienen un conector puente o “paso a través” (“through connector”) para permitir la conexión de otros periféricos tales como interfaces de disco (un “through connector” es un duplicado del conector de 64 pins que está en el interior del QL de tal manera que se pueda seguir conectando otros periféricos o tarjetas de expansión al QL). Si piensas que es probable que en algún momento quieras comprar otros dispositivos, como un interface de disquetes o disco duro, lo mejor sería pagar un poco más y obtener una tarjeta de expansión de memoria con un “through connector”. Ejemplos de tarjetas de expansión adecuadas son Miracle Expandaram, Sandy 512K, Silicon Express Insider y la CST 512KB Ram Card.


Ten en cuenta que sólo puedes añadir una tarjeta de expansión de memoria. Si compras una vieja unidad de 256KB, y luego decides agregar otros 256KB, no funcionará.

Expanderam

Miracle Expaderam

El aumentar la memoria a tu sistema QL no aumentará la velocidad de funcionamiento de manera significativa, aunque un QL con 128KB de memoria sin discos flexibles puede mejorar el rendimiento de los Microdrives mediante el uso de memoria extra para manejar el buffer de las unidades de Microdrive mediante la copia de cierta cantidad de datos en memoria (llamados “bloques esclavos”).


En la práctica, este tipo de tarjeta de “sólo-memoria” fue sustituida por tarjetas de expansión que también integraban interfaces de disco flexible y en estos días ambos tipos de unidades se pueden conseguir por muy poco coste.


SYSTEMAS DE DISQUETES


Una unidad de disco mejorará en gran medida tu QL en muchos aspectos. Los discos flexibles pueden manejar mucha más información que los cartuchos de Microdrive, suelen ser más baratos, mucho más fiables y más rápidos. Los cartuchos de Microdrive ya no se fabrican, y aunque se pueden encontrar de segunda mano, pocos usuarios de QL trabajan hoy en día sin sistemas de disco flexible.

Los sistemas de disco flexible más populares en estos días son los adheridos al formato denominados QJump, en lugar del formato “oficial” original de los sistemas de Sinclair, aunque esto no debería ser un problema ya que los sistemas originales “Sinclair / Micro Peripherals” son muy difíciles de conseguir.

La mayoría de los usuarios QL utilizan el estándar de 3,5 pulgadas, el mismo que se utilizan en el resto de ordenadores actuales. La mayoría de las interfaces también puede manejar los antiguos discos de 5,25 pulgadas, así como los menos comunes y más caros disquetes de 3 pulgadas utilizados por compañías como Amstrad en sus primeros sistemas informáticos. Pocos proveedores de software para QL ofertan sus programas en otro medio que no sean los discos de 3.5 pulgadas, y adquirir otro sistema que no sea este sería un inversión errónea.

Los antiguos interfaces de disquete para el QL sólo podían manejar discos de Doble Densidad (720KB de capacidad). Estos van a ser cada vez más escasos de conseguir en el futuro, a medida que los fabricantes se concentren en los discos de alta densidad (discos HD con una capacidad de alrededor de 1,4 MB). Si bien es cierto, la comunidad QL aún utiliza discos DD frecuentemente. Las más recientes interfaces de disco y unidades de expansión como la Gold Card o la Super Gold Card (más información sobre estas unidades más adelante) pueden manejar disco HD e incluso los raros discos de Extra Densidad (ED) de 3,2 megabytes. Tenga en cuenta que estos discos de 3.2MB no son estándar, de hecho el QL es el único equipo que conozco que utiliza este formato – los otros equipos que usan estas unidades ED emplean en su lugar un formato con densidades de 2.8 MB-.

Trump Card

Trump Card, ampliación de memoria e interfaz de disco (DD)

Una característica útil en los sistemas de disco del QL es que los sistemas de disco HD y ED pueden leer y escribir en discos de menor densidad para la que fueron diseñados. Por lo tanto, las unidades de disco HD puede leer y escribir en discos y DD, mientras que las unidades de disco ED también puede usar los discos HD y DD. La fiabilidad en la utilización de discos de menor densidad en unidades de disco diseñadas para manjar discos de más alta densidad no es muy buena. Por ejemplo, no es raro encontrar que un disco DD que ha sido copiado en tu unidad ED le falla a la hora de leerlo un amigo el cual sólo dispone de una unidad de disco DD.


Las ampliaciones que sólo contienen la interfaz de disco son generalmente muy adecuadas para añadir a un sistema que ya contenga una expansión de memoria, siempre que exista un medio para conectar las dos al mismo tiempo en el QL. Como muchas tarjetas de memoria incluyen un “conector a tráves”, éste no es necesariamente un problema. Hay también tarjetas base como la QPlane de Qubbesoft o la llamada MPlane de TF Services que agregan más ranuras de expansión para el QL y que permiten la posibilidad de conectar tarjetas de expansión adicionales.


Las interfaces de disco para el QL fueron producidas por varias empresas, tales como CST, Miracle Systems, Silicon Express, Sandy y PCML entre otros. Yo he usado una CST QDISK con una tarjeta de Miracle Expandaram de forma satisfactoria durante unos cantos años.


Algunas de estas interfaces de disco contiene un subconjunto de los “toolkit’s” que he mencionado (véase el apartado sobre los Toolkits más adelante). Algunos contienen el Toolkit 2 completo. Cuando busques una interfaz de disco pregunta si incluye Toolkit 2, ya que te ahorraras el tener que comprarlo por separado más adelante.


Las interfaces de disco puede ser utilizadas por sí solas sin ningún tipo de expansión de memoria, pero como la interfaz de disco necesita un poco de memoria para sí misma, se reduce aún más los escasos 128KB de memoria en un QL estándar, por este motivo el uso de una expansión de disco sin ninguna expansión de memoria tiene un dudoso beneficio, a menos que lo único que pretendas es escribir tus propios pequeños programas en SuperBASIC o usar Quill para redactar documentos cortos por ejemplo.


Al cabo de cierto tiempo, los fabricantes dejaron de producir tarjetas de ampliación de memoria y tarjetas con interfaces de disco de forma separada y empezaron a optar por diseños todo-en-uno.


TOOLKITS


Los ToolKits (caja de herramientas) ¡no son martillos ni llaves! …, son añadidos software que suministran facilidades al sistema operativo y al SuperBASIC. El más común se llama Toolkit 2, de Tony Tebby, uno de los diseñadores originales del sistema operativo del QL. Se trataba de una versión mejorada del Toolkit original publicado por la división de software de Sinclair en los primeros días del QL. Toolkit 2 (también llamado Super Toolkit 2 en algunos casos) añade muchas nuevas facilidades, incluyendo conjunto de nuevas funciones y comandos para el SuperBASIC casi imprescindibles. Estos Toolkits se han convertido en características estándar de muchos usuarios de sistemas QL a lo largo de de los años y, para mí, las facilidades ofrecidas por el Toolkit 2 son indispensables.


Toolkit 2 ha aparecido en tres formas distintas en los últimos años. El primero fue en un cartucho EPROM, una pequeña caja de plástico con chips de 16KB EPROM conectado a la ranura de expansión EPROM en la parte trasera de la QL. Este fue un sistema muy útil, ya que significaba que el juego de herramientas se encontraba disponible al instante cada vez que se encendía el QL sin tener que cargar el kit software desde el disco, por ejemplo. Una segunda versión del Toolkit 2 se suministraba en un disquete o en un cartucho de Microdrive, lo que le permitía seleccionar qué secciones del software se deseaba cargar con el fin de ahorrar espacio y reducir el tamaño del Toolkit descargando funciones no deseadas. A esto se llama Toolkit reconfigurable. Si bien esto era útil en algunos aspectos, esta versión del Toolkit fue menos popular que la versión EPROM.


La tercera versión del Toolkit 2 era suministrada dentro de los sistemas de interface de disco, especialmente los producidos por Miracle Systems. Si obtienes una interface de disco con Toolkit 2 en la tarjeta no necesitarás adquirirlo por separado(1).


UNIDADES COMBINADAS


Varias empresas pasaron a integrar unidades de expansión de memoria, interfaces de disco y Toolkit 2. Ejemplos de esas unidades fueron el Super-Q-Board de Sandy, una unidad similar de PCML (ambas llevaron la RAM del QL hasta un total de 640KB) y un dispositivo más ambicioso llamado Trump Card de Miracle Systems. Esta unidad rompió la normas llevando el total de la memoria RAM del QL hasta los 896KB haciendo uso del espacio asignado por los diseñadores del QL a las ampliaciones de otros periféricos, para proporcionar una expansión de memoria RAM por encima del límite teórico de los 640KB del diseño original. El inconveniente es que no es posible la conexión de otros periféricos ya que el espacio de memoria reservada para éstos ya no está disponible al ser usadas completamente por la tarjeta de expansión.

Una segunda versión de la Trump Card fue versionada más tarde por Qubbesoft – ambas versiones, la de Miracle y la de Qubbesoft, son unidades de expansión de bajo coste ideales para resucitar un viejo QL, o para equipar un QL de repuesto de nuestro sistema principal.

Lamentablemente, estas unidades a penas se consiguen hoy en día ya que han dejado de fabricarse hace muchos años, a menos que tengas la suerte de encontrarte una de segunda mano o que algún vendedor la venda y tengas la suerte de hacerte con una de ellas.

La mayoría de estos sistemas más antiguos sólo pueden manejar una o dos unidades de disquete, y sólo unidades de doble cara y doble densidad (DD).

Gold Card

Gold Card

Miracle Systems más tarde produjo un sistema combinado llamado “Gold Card”, que incluía un sistema de disco capaz de manejar unidades DD, HD, ED y 2 o 4 unidades de disco. La Gold Card le suministraba al sistema una ampliación de 2 MB de memoria RAM, Toolkit 2 e incluso un nuevo microprocesador para sustituir el 68008 original del QL. El microprocesador 68000 de la Gold Card permite ejecutar el software muchas veces más rápido que el QL original, esto le aseguró su éxito. A pesar de que las Gold Card ya no se fabrican, se pueden conseguir de segunda mano y hacen que sean las unidades de expansión ideales para ampliar un QL básico.

Miracle Systems fue un paso más allá y produjo una versión mejorada de la Gold Card, imaginativamente la llamó “Super Gold Card”. Esta tarjeta le dio aún más memoria al QL, 4 MB de memoria RAM, junto con un microprocesador más rápido, el 68020. Además incluía una interfaz paralelo Centronics para el uso de impresoras compatible cuya conexión se incluyó en la propia placa junto con la posibilidad de utilizar hasta 4 unidades de disco sin necesidad de adaptadores externos. Después de que Miracle Systems pararse su producción, la Super Gold Card fue producida por Quanta y luego por QBranch. Debido a la escasez de componente su producción al final fue muy lenta, pero se suelen encontrar unidades y a menudo se disponen algunas de segunda mano -QBranch suelen tener algunas Gold Card y Super Gold Card disponibles para la venta, por ejemplo(2)-.


Un sistema ampliado: Sinclair QL, Gold Card, Mouse, Disquetera HD

QL vista frontal

QL vista frontal, sistema ampliado

Notas:


1.- Hoy día el Toolkit 2 es de libre distribución.


2.- En la época en la que se escribió la versión original de este artículo, las ampliaciones comentadas se podían conseguir de forma relativamente fácil, sin embargo hoy en día -abril de 2009- es prácticamente imposible conseguir dichas ampliaciones. QBranch, por ejemplo hoy día ya no produce ni vende, pues ha cerrado su negocio.

—-
(Artículo en formato pdf)