Archivo

Extensiones

Z2-RGbw1mLa página de QUANTA recoge un interesante artículo de ejemplo de los contenidos que pueden verse en su publicación QUANTA Magazine.

El tema es la Robótica en el QL, y mediante la narración de sus experiencias, el autor nos introduce en los avances que ha ido realizando en este campo y nos muestra, mediante capturas de pantalla, el funcionamiento de su programa para manejar robots con el QL.

Z2QLhelp11Captura del programa de gestión de robots.

Sin duda, una lectura interesante para los amantes de los ordenadores retro y de la robótica retro en particular.

Leer el artículo  aquí (en inglés)

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 esta entrega comenzaré a echar un vistazo a otros dispositivos hardware disponibles, describiendo varios sistemas de disco duro producidos para el QL.

Discos duros de primera generación

El disco duro original para sistemas QL estaba basado en viejos discos de baja capacidad, sistemas tales como el Rebel Hard Disk system (raro de encontrar) y el disco duro de Miracle (actualmente no está en producción, pero hay muchos de ellos ahí fuera).

Debido a la limitada capacidad de expansión del QL, la mayoría de estos primeros sistemas de disco duro no podían ser añadidos a través del bus de expansión del QL, puesto que éste solía estar ocupado con otras expansiones, tales como las ampliaciones de memoria y controladoras de disquetes. Algunos sistemas de expansión de esa época, como ya comentamos en la entrega anterior, ocupaban todo el espacio direccionable de para sí mismas (por ejemplo, la TrumpCard), por lo que los proveedores de estos sistemas tenían que recurrir a soluciones ingeniosas, como enganchar las ampliaciones de disco duro a través del puerto EPROM del QL. Si bien se trataba de una solución ingeniosa en ese momento, no significó que estos sistemas de disco duro fuera una forma convencional de ampliar un QL. Si tú tienes un sistema Aurora por ejemplo, podrías tener dificultades en añadir la ampliación mediante el slot ROM de ampliación equivalente de la placa Aurora.

Ampliación de disco duro CST de primera generación

Ampliación de disco duro CST de primera generación. Anuncio publicado en QL World, año 1985.

Otro ejemplo de un disco duro que se podía encontrar en esa época era de dominio público. Dirk Steinkopf publicó un disco que contenía los detalles de cómo construir un sistema basado en la unidad MFM o RLL. Para aquellos que desean intentar un proyecto de este tipo (los diagramas han sido liberados) la información disponible en 22 discos fueron ofrecidos por Qubbesoft P/D, por ejemplo. Si bien Qubbesoft ya no es una empresa comercial, todavía es posible obtener copias de estos discos ya que como he dicho son de dominio público.

Qubide

Qubbesoft introdujo en el mercado una nueva interfaz de disco duro IDE (tipo PC) para la QL y Aurora. Esta expansión se llamaba Qubide, la cual se conectaba al bus del QL y permitía que otras tarjetas de expansión de memoria y disquetes se pudieran añadir, aunque en algunos casos esto hace que el QL sea más ancho que ¡tu mesa de escritorio! El Qubide tiene una característica útil y es que sus direcciones de trabajo pueden ser modificadas a través de pequeños jumper situados dentro de la propia tarjeta, así si hay incompatibilidades con otras unidades de expansión se pueden seleccionar direcciones alternativas. Por ejemplo, si la estas utilizando con una Trump Card o tarjetas similares, podrías configurarla empleando 16KB disponible en el puerto EPROM situados en la ranura de la parte trasera del QL.

Qubide + Gold Car + conectores extra

Qubide + Gold Car + conectores extra

El Qubide era, y sigue siendo, ampliamente utilizada, y probablemente la ampliación de unidad de disco duro más popular en el QL. La unidad se dejó de producir con la desaparición de Qubbesoft P/D, pero su popularidad podría significar que en algún momento otra empresa pudiera reiniciar su producción. Hay dos versiones principales de la Qubide. La versión 1 original era una unidad de expansión de un simple disco duro. La versión 2 se ha mejorado para proporcionar servicios de apoyo a los medios extraíbles Atapi como dispositivos IDE Iomega Zip, junto con mejoras en el sistema de recuperado de archivos borrados que permiten la recuperación pesterior de archivos que se hubieran borrado accidentalmente. El Qubide utiliza un formato de archivos único en la escena del QL y no el formato QXL.WIN utilizados en sistemas más recientes tales como los emuladores. Aunque el Qubide es capaz de manejar CD-ROM IDE, no ofrece mucho más debido a que había espacio en la ROM para integrar más software de soporte. Software de terceros, tales como el Discover de Dave Walker mejora algunas de estas limitaciones aportando una limitada capacidad para la transferencia de ficheros, así por ejemplo, es posible al menos copiar ficheros desde un CD de PC.

Interfaz Qubide

Interfaz Qubide de Qubbesoft

Algunos emuladores, como el QDOS Classic, pueden usar un disco duro con formato similar al formato del Qubide.

Discos duros QXL.WIN

Cuando Tony Tebby desarrollo el sistema operativo SMSQ para la tarjeta QXL de Miracle Systems, introdujo una especie de contenedor de sistema de archivos llamado QXL.WIN para simular el almacenamiento en disco duro. Se trata de un único archivo de gran tamaño situado en el disco duro del equipo anfitrión, creado para que un sistema compatible QL viera dicho archivo como la zona de almacenamiento de disco duro. Para el equipo anfitrión, este archivo no es más que un fichero de datos de gran tamaño disponible para alguna aplicación. De cara al sistema compatible QL, éste aparece como un disco duro completo. Éste sistema contenedor QXL.WIN es utilizado por todos los sistemas que utilizan SMSQ o SMSQ/E, más dos emuladores del QDOS (el emulador QL uQLx para Linux/Unix y QemuLator para las plataformas Windows), por lo que se ha convertido en un estándar de sistema de ficheros de disco duro para sistemas compatibles QL. Lamentablemente, el Qubide no es capaz de leer un dispositivo que esté formateado de esta manera. Los archivos QXL.WIN pueden crearse incluso en medios extraíbles como Iomega Zip, LS120, y cosas así, pero no en disquetes, que siguen utilizando el mismo formato de disco QL.

El estándar establece que WIN1_ se corresponde con el disco duro principal del ordenador (un .WIN en la unidad C: de un sistema DOS o Windows), mientras que WIN2_ sería la siguiente unidad (la unidad D:.WIN), el CD-ROM puede ser una tercera unidad (WIN3_) y medios extraíbles como unidades ZIP podría WIN4_ (unidades E:.WIN, F:.WIN) y así sucesivamente, hasta 8 unidades. Todos los archivos QXL.WIN tienen que estar en el directorio raíz de esas unidades.

El emulador QPC basado en Windows tomó el sistema QXL.WIN y lo llevó un paso más allá al permitir al usuario definir hasta 8 “discos duros” virtuales (WIN1_ a WIN8_). Cada disco virtual puede estar en un directorio separado del mismo disco duro de la máquina anfitrión, o estar separado físicamente en otros discos duros. Por lo tanto, el disco duro principal (WIN1_) puede ser C:.WIN en un sistema basado en DOS, mientras que WIN2_ puede ser un segundo fichero QXL.WIN en el disco duro principal, WIN3_ podría ser otro fichero QXL.WIN en un segundo disco duro (D:), un CD-ROM que contenga un CD con otro archivo QXL.WIN podría ser WIN4_ (E:.WIN en un PC) y así sucesivamente hasta 8 unidades.

Todos estos sistemas que usan el sistema de archivos QXL.WIN pueden direccionar capacidades mucho más altas que los antiguos sistemas QL de disco duro. Estos sistemas más antiguos eran típicamente discos duros con capacidades entre 20 y 40MB, mientras que en estos días la capacidad suele ser muchas veces más grande que esos antiguos sistemas. Los archivos para el QL suelen ser bastante pequeños y tienen mucho menos requisitos de almacenamiento que muchos nuevos sistemas “devoradores” de espacio de almacenamiento. Pero si fuera necesario, tenemos la posibilidad de manjar discos duros de gran capacidad empleando SMSQ/E. Un ejemplo que puedo citar es un CD-ROM que he elaborado con gran cantidad de clipart para el QL, que maneja cientos de megabytes (nunca pensé que necesitaría tratar con algo semejante en un sistema compatible QL).


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

Traducción: Afx
abril de 2009

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)

¿Alguna vez soñaste con tener varios programas SuperBASIC ejecutándose a la vez como si fuesen programas compilados en multitarea? Pues con la ROM Minerva, que sustituye a tu ROM original de QL, es posible. Con ella se entrega un manual y un disco de utilidades que incluye los ficheros multib_asm y multib_obj, que permiten hacer esto.

Cuando ejecutamos (EXEC) multib_obj, se abre una nueva ventana en la que se unen los canales 0 y 1. ¡Cada instancia tiene sus propios canales 0, 1… por separado!

minerva_multibasic

Seis intérpretes SuperBASIC funcionando a la vez

Actualización 11-04-2009: Según se indica en el documento updates_doc que se incluye en el disco de utilidades Minerva, las últimas versiones de la ROM no necesitan cargar el fichero externo, pues MultiBASIC viene integrado. Es suficiente con ejecutar

EXEC PIPEP

para disponer de nuevas instancias SuperBASIC.

Los programas se cargan y corren de la misma forma, y funcionan todos los comandos del SuperBASIC, pues MultiBASIC lo que hace es lanzar nuevas instancias del intérprete SuperBASIC. Para cambiar entre los distintos intérpretes que lanzemos sólo tenemos que usar CTRL-C como siempre que trabajamos en multitarea.

Si ejecutamos el comando JOBS (TK2) vemos que nos lista una nueva tarea llamada SB.n con prioridad 8. Dentro de cada nueva instancia del intérprete SuperBASIC podemos lanzar nuevas instancias como se ve en la imagen. El límite está en la memoria disponible.

Si queremos disponer de canal 2 para listados deberemos abrirlo desde su instancia correspondiente. Podemos dejar el tamaño de los canales de este nuevo intérprete a las medidas a las que estamos acostumbrados mediante el siguiente programa (requiere TK2):

100 OPEN #0;con: OPEN #1;con: OPEN #2;con
110 WMON

Muchas veces, por la proliferación de ventanas que se crean en la pantalla, no sabremos en que instancia del SuperBASIC nos encontramos. Siempre podemos recurrir al comando JOBS o a la siguiente instrucción para saber cual es el ID del job que estamos utilizando:

PRINT VER$(-1)

Una instacia en MultiBASIC puede borrarse a si misma si encuentra un error. En el manual indican que esta es la forma adecuada de borrar una instacia. Proponen por ejemplo usar CLOSE #0 para salir.

Estas características de MultiBASIC posteriormente fueron implenentadas y mejoradas en el interprete de comandos del sistema operativo SMSQ llamado SBASIC, pero aunque lo que hace MultiBASIC es una cualidad del QDOS, si ejecutamos el programa multib_obj en un sistema con otra versión de ROM, este no funcionará. Asi que si vas a usar un emulador para probarlo no te olvides de cargar la ROM Minerva.

Enlaces para descarga:

downloadiconROM Minerva
Manual de la ROM Minerva
Disco de utilidades de la ROM Minerva

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.