QBlog

Dado que, últimamente han salido algunos juegos y conversiones con texto tanto en inglés como español, y puesto que no siempre es fácil desde el emulador, usar el teclado en español y escribir acentos, exclamaciones, interrogaciones y la letra ñ, he preparado este script bash para hacer la adecuada conversión de caracteres partiendo de un texto en el PC con Linux.

El código está comentado, y podrás ver cómo funciona paso a paso. Puedes descargarlo más abajo. El fichero incluye un texto test.txt para pruebas.

La dinámica de uso es muy sencilla. Una vez escrito el programa, y guardado con codificación UTF-8, ejecuta el conversor desde la línea de comandos, en la carpeta donde esté el script y el texto a convertir, pasándole como parámetro el nombre del fichero, y obtendrás un fichero convertido ya con la codificación correcta ISO-8859-15 y los caracteres convertidos. Usa:

Recuerda que el conversor debe tener permisos de ejecución. Usa antes, para ello:

La extensión del fichero a convertir puede ser txt u otra, por ejemplo .bas si lo deseas.

Obviamente, en el PC el texto se verá con caracteres raros que deben verse bien en el QL.

Una vez que el texto esté convertido, llévalo al QL y mira si el texto está correcto, por ejemplo usando VIEW si tienes Toolkit 2 instalado, o cargando el programa si se trata de un listado. Ej.

Si todo fue bien, verás unos bonitos caracteres españoles en tu texto QL. La conversión servirá para cualquier versión de la ROM que se use, ya que el juego de caracteres internacional es el mismo en todas ellas.

Descargar el programa utf2ql.zip

Se ha añadido también el mismo script en Python que puede ser ejecutado con:

Si el script se usa en Windows, y la codificación de los textos es ISO-8859-15, podemos cambiar la línea 23 por:

y renombrar el script a iso2ql.py.

Sigue la conversación en: https://retrowiki.es/viewtopic.php?f=98&t=200040490

¿Te imaginas que tu programa SuperBASIC pueda mostrar una barra de progreso mientras se va cargando con LOAD o LRUN, o que muestre al usuario en cuánto tiempo se ha cargado este programa usando sólo SuperBASIC, sin necesitar ninguna extensión? Estas son algunas de las cosas que podemos conseguir con el método que explico aquí.

Es posible que esto ya sea conocido por los expertos en SuperBASIC, o que se haya documentado antes, pero para mi ha sido todo un descubrimiento recientemente, y así lo comparto.

Cuando ejecutamos una instrucción LOAD o LRUN, el sistema abre el fichero _bas que le indiquemos, y va leyendo y cargando cada línea. Al hacerlo, completa los comandos reducidos que pudiera haber, como REM, por poner un ejemplo, que traduce en el listado como REMark, y revisa si hay algún error de sintaxis para avisar al usuario mediante la inserción de un «MISTake» en esa línea.

Nunca me había parado a pensar cómo funciona la carga de programas SuperBASIC hasta que, hace unos días, hablando con Zerover, recordamos el juego «Nuclear Invaders» que el usuario dancresp había publicado en el foro español RetroWiki, y su peculiar forma de incluir comentarios en el listado que había compartido. Ver el enlace: https://retrowiki.es/viewtopic.php?f=98&t=200040396

En su listado hay lineas vacías y comandos REM sin número de línea, algo que a Zerover le pareció una buena idea para hacer el programa más corto, ya que, al parecer, dichas líneas no aparecerán en el listado una vez cargado el programa, por lo que ocupará menos memoria, y además esto ayuda a que el código sea más legible cuando se muestra en, por ejemplo, un foro.

Preguntando a dancresp sobre esta peculiaridad, me comentó lo siguiente:

«…de tanto en tanto los imprimo (los listados) para ojearlos, y aprovecho antes para separar los bloques con un REM al inicio del bloque y una línea en blanco al final. Lo curioso es que después los cargaba en el QL y no daba error.»

Entonces, ¿qué ocurre con las líneas en blanco y los REM? Pues, sencillamente que, durante la carga, las líneas que no tienen número de líneas son ejecutadas tan pronto como se cargan, como si las introdujésemos directamente por la ventana de comandos.

Esto me sorprendió, y comencé a hacer pruebas. Los REM y las líneas en blanco, por supuesto, no tienen ningún efecto en el ordenador. También podemos incluir el símbolo «:» que se usa como separador de comandos en una línea, y todo funcionará bien. Así pues, podemos tener un programa similar a este que el sistema cargará sin errores:

Y al hacer LIST, sólo se mostrará la línea numerada

ejecutando el resto de líneas no numeradas en el momento de la carga.

Y si este método funciona con REM, ¿funcionará con otras instrucciones SuperBASIC? La respuesta es sí.

Podemos usar instrucciones SuperBASIC intercaladas en el programa si las incluimos sin número de línea.

Algo como esto es posible:

El caso es que podemos usar incluso variables, bucles, etc… Para estructuras que requieran de cierre, como en el caso del uso de FOR, IF… los END deben estar en la misma línea, separados por «:», como si empleásemos el comando DO de Toolkit 2.

Lo que al parecer no funciona es la definición de funciones y procedimientos. Si definimos un procedimiento, y lo llamamos más adelante, en otra línea del fichero sin número de línea, recibiremos el error «No encontrado», y se parará la carga.

Este método permite tener dos programas en uno; el programa compuesto de instrucciones intercaladas en el listado almacenado sin número de líneas que se ejecutan durante la carga, y el listado del programa con números de línea que se ejecuta con RUN cuando se termine de cargar.

Como las líneas se cargan consecutivamente, podemos intercalar instrucciones allá donde queramos que se ejecuten a medida que el listado se cargue. Esto nos permitiría, por ejemplo, mostrar el porcentaje de carga del programa de esta forma:

Durante la carga, se ejecutará, cuando corresponda:

y el listado resultante que se mostrará con LIST será:

Por supuesto podemos incluir tantas instrucciones PRINT como deseemos, y afinar el porcentaje de carga. Si tenemos 100 líneas de código, y queremos mostrar el porcentaje de carga cada vez que se cargue un 10% del código, entonces deberemos intercalar los PRINT sin número de línea, con el mensaje correspondiente, cada 10 líneas.

Aquí otro ejemplo usando una barra de progreso creada a partir de caracteres:

Podemos echar a volar la imaginación haciendo uso de instrucciones gráficas como WINDOW, LINE, BLOCK o incluso SCROLL o PAN para dibujar y mostrar visualmente el avance de las barras de procentaje de carga… o todo aquello que se te ocurra.

Obviamente, con el editor del QL, ya sea con EDIT o con ED, no vamos a poder crear los listados con las líneas intercaladas sin número de línea. Para ello vamos a necesitar un editor de texto como por ejemplo QED o similar.

Lo recomendado es crear el programa completo por los medios habituales y probarlo hasta que todo funcione. Sólo después de esto sería recomendable incorporar el segundo programa, el que se ejecutará durante la carga, con las instrucciones sin números de línea que deseemos.

Para concluir, veamos otro ejemplo en el que se resume todo lo expuesto aquí en un pequeño programa que muestra el tiempo que tardó en realizarse la carga del programa.

En la primera línea, en la variable «t» se guarda la fecha y hora actual como un valor en coma flotante.

Saltando la línea de espacio en blanco, la línea 100 es cargada y será la única que se mostrará en el listado al hacer LIST.

Tras la línea de los dos puntos que no tiene efecto en el programa, con el PAUSE se simula en este ejemplo el tiempo de carga del resto de líneas de un programa. El valor 100 supone una demora de 2 segundos.

Y tras una nueva línea en blanco, la instrucción PRINT mostrará el tiempo transcurrido desde que empezó la carga del programa en segundos.

Este método da para mucho si se le echa imaginación, y permite mostrar, de forma dinámica, información que el usuario de nuestros programas en SuperBASIC agradecerá, sobre todo si el tiempo de carga es elevado, como cuando cargamos programas desde microdrive.

Mostrar avances en la carga, información sobre requisitos, o incluso trucos de uso, ayudará a mantener al usuario interesado en el programa y hará más llevadera la carga, pero no sólo sirve para eso.

Este método puede ser útil también para ejecutar instrucciones durante la carga que luego no es necesario que vuelvan a ser usadas cada vez que se ejecuta el programa en SuperBASIC, por ejemplo, cargar extensiones, ejecutar TK2_EXT, ejecutar un POKE o reservar memoria.

Otra forma de usarlo es eliminando del listado que será cargado en memoria aquellas líneas que no son de utilidad para la ejecución y que ocupan memoria, como los REM.

Dicho todo esto, es importante mencionar que el método sólo funcionará con listados de programas en SuperBASIC, ya que los programas compilados no nos dan esta posibilidad. y recordar también que, como ya dije, esto no permite el uso de procedimientos y funciones durante la carga.

Una cosa más. Si cargas el programa con LRUN y este no se ejecuta, añade un RUN sin número de línea al final del listado de tu programa.

Dilwyn Jones, en el foro inglés, hace ver la siguiente información:

En el manual del Toolkit 2 hay una nota sobre lo que puede suceder con líneas no numeradas en un archivo BASIC en algunas ROM QDOS, que también se menciona en los artículos de errores de ROM de Simon Goodwin en QL. World.

Un archivo DO es un archivo de comandos directos que se ejecutarán mediante el comando DO del Toolkit 2. El manual dice:

«Si hay un comando RUN en un fichero DO, el fichero no será cerrado, una vez leído su contenido. Tampoco será cerrado, si es cargado con MERGE en lugar de con DO.»

Quizás sea por eso que esta técnica nunca se implementó realmente, que la gente estaba consciente de problemas potenciales como este al cargar archivos con comandos directos si alguien fusionara el programa. Los artículos de Simon afirman que este problema de MERGE se solucionó en Minerva y, hasta cierto punto, en Toolkit 2.

En cualquier caso, es fácil verificar si LRUN / LOAD funciona bien simplemente cargándolo desde un disco y verificando si el archivo permanece abierto después usando algo como el menú de canales de QPAC2, o incluso cambiando los discos; el sistema pronto se quejará. si intenta cambiar los discos con un archivo aún abierto.

Siguel a discusión de la comunidad aqui: https://retrowiki.es/viewtopic.php?f=98&t=200040477

Peter Graf lo ha vuelto a hacer, y esta vez a lo grande. Acaba de anunciar una nueva tarjeta de expansión para el QL pero esta vez … ¡Vía puerto ROM! Una autentica locura.

Las características son:

• Conexión con pantallas modernas vía salida VESA estándar. Soporta los modos de videos tradicionales del QL añadiendo modos adicionales con más resolución (hasta 1024×768) y más colores (hasta 65536).
• Una CPU compatible con el 68000 a 40 MHz.
• 32 MB de RAM
• Soporte para sistemas operativos Minerva y SMSQ/E
• Un reloj en tiempo real
• Un puerto serie a 115200 baudios
• Conexión con ratón PS2
• Conexión con teclado PS2
• Un puerto adicional de entrada / salida.

Y todo esto en una placa de 53 x 35 mm que se conecta al puerto ROM del QL.

Oficialmente lo van a presentar en el evento alemán del 40 aniversario del QL (17/18/19 de mayo), pero ya hay un adelanto en un hilo de QLFormum, https://qlforum.co.uk/viewtopic.php?t=4799 .

Lo mejor es verlo en imágenes.

Viene del artículo: «Programando mi propia demo en QL III»

Finaliza esta serie de artículos, y en esta ocasión veremos cómo controlar las colisiones y las puntuaciones para dejar nuestra demo terminada.

En la línea 500 de esta versión, he inicializado los marcadores a 200. Este valor se corresponde con el número de casillas del tablero del color de cada bola. En un tablero de 20×20, cuya área inicial de cada bola es de 10×20, el número de casillas es de 200, luego el número de puntos es 200.

Cada vez que una bola se adentre en la zona de la bola contraria, robará una casilla y rebotará para volver a su zona del tablero. En ese momento, el marcador de la bola en cuestión se incrementará en 1, y el de la otra bola se reducirá en 1.

¡Este es el delicado equilibrio entre las fuerzas del Yin y del Yang!

Hay pocos cambios en esta versión.

En estas pocas líneas de código reside la «magia» de la demo:

Dentro del procedimiento PRUEBA(), en la línea 1270, compruebo si la bola se encuentra en una posición del tablero que corresponde a la bola contraria (1-bola%).

Si es así toca hacer rebote para volver a la zona de la bola, como si nos hubiésemos topado con una pared, y rebotásemos, pero puede que, al volver, nos topemos con otra zona del contrario que nos haga rebotar de nuevo. Puede que esto ocurra cerca de los bordes del tablero, y nos salgamos del mismo. Para evitarlo, hago una segunda comprobación.

En la línea 1280 me aseguro de que, si hago un cambio de dirección en Y, este cambio no hará que me salga del tablero, y para ello me aseguro de que el resultado del cambio de dirección dejará la bola más allá de la columna 1 y más acá de la columna 18, de otra forma no haré rebote, y evitaré salirme si la bola choca y me devuleve al borde del tablero.

Por supuesto, ambas comprobaciones pueden hacerse en un solo IF, aunándolas.

Si todo fue bien, en la línea 1290, cambio la dirección de dy% y lo guardo en la matriz b%().

Luego asigno la casilla del tablero a la bola que se adentró en ella en la línea 1300.

En las líneas 1310 y 1320 aumento el marcador de la bola en cuestión y decremento el marcador de la otra bola, respectivamente.

Y en la línea 1330 actualizo ambos marcadores en la pantalla mediante un bucle y la llamada al procedimiento MARCADOR().

Ya sólo queda ejecutar la demo.

La demo que hemos construido se ha hecho pensando no tanto en la optimización del código como en su forma y la aplicación de buenas prácticas.

Primeramente definimos la estructura del programa, incluyendo los procedimientos básicos y el bucle principal. Luego, con la planificación de cómo iba a funcionar el programa, determinamos las variables que usaríamos y dimos forma al tablero en pantalla.

Teniendo el tablero y las variables disponibles, el siguiente paso era hacer que las bolas de la demo se moviesen libremente por el tablero sin salirse. Y finalmente hemos conseguido gestionar las colisiones de las bolas con las áreas del contrario y actualizar los marcadores.

En esta serie de «fascículos» pues se han puesto las bases de la construcción de programas en SuperBASIC. Con esta experiencia, y la documentación de lenguaje, no será dificil aventurarse a construir otras demos o juegos o programas… Ya tienes por dónde empezar con este ejemplo.

Espero que, esta serie os anime a crear nuevas aplicaciones para el QL 40 años después.

Si ejecutas el programa, verás algo curioso. Dado que estamos usando posiciones absolutas de caracteres en el tablero, llega un momento en que se produce un equilibrio inalterable entre ambas bolas. El marcador se estabiliza, o sube y baja un punto todo el tiempo.

Además verás que se genera un damero en el tablero. Esto también tiene como origen la forma en que las bolas se mueven por él.

¿Te animas a cambiar la forma en que se mueven las bolas en la demo, usando saltos en pixeles en vez de en caracteres? Esto cambiará ciertas estructuras de la demo y te permitirá crear rebotes basándote en qué porcentaje de la bola toca una celda del contrario, pudiendo determinar como será el rebote. Revisa el código de la demo PongWars en la que se basa esta serie de fascículos.

Cuando tengas hecho el ejercicio anterior, ¡podrás convertir esta demo en un juego!

Vamos a crear dos paletas, como en el pong, pero estas no se encontrarán a los lados, sino en el medio, en la frontera central de su territorio, cara a cara con el enemigo. La paleta de la bola 1 estará en la posición vertical 9, y la paleta de la otra bola en la posición vertical 10.

Como en el pong, las paletas se moverán sólo verticalmente, y en ellas podrás hacer rebotar la bola del contrario, parando su avance sobre tu zona del tablero y devolviéndola a su zona. Igualmente puedes ayudar a tu bola a adentrarse más en la zona del contrario haciéndola rebotar sobre tu paleta. Y, como en el juego original, en función de en que parte de la paleta rebote la bola, esta saldrá disparada con un ángulo determinado y una velocidad determinada. Las bolas pueden rebotar por ambas caras de cada paleta.

Gana la partida el primero que consigua que su bola se adentre en la zona del contrario hasta tocar su pared vertical, es decir, que la bola 1 llegue a la posición horizontal 19 o que la bola 2 llegue a la posición horizontal 0. Puedes pintar estas paredes con otro color si lo deseas.

Pon cuidado en todo el desarrollo, y ¡comparte tu juego!

• Manual del QL en español
• Manual de Toolkit II en español
• Código en GitHub – repo Sinclair-QL-YinYang

Puedes seguir los comentarios de la comunidad en: https://retrowiki.es/viewtopic.php?f=98&t=200040293

Viene del artículo: «Programando mi propia demo en QL II»

Sigo con esta serie de artículos, y hoy toca hablar de movimiento y rebotes de las bolas de la demo.

En anteriores entregas, hemos definido la estructura del programa, y luego inicializado las variables y dibujado la interfaz. Vamos a ver cómo darle movimiento a las bolas dentro del tablero y hacer algunas comprobaciones básicas para evitar que las bolas se salgan del mismo.

Como sabemos, cada bola tiene una posición X e Y en el tablero, que corresponde con la posición horizontal y vertical en el mismo. Para movernos por el tablero, que tiene unas dimensiones concretas, debemos sumar a las posiciones X e Y de cada bola, alternativamente, el valor 1 para avanzar. Con esto calculamos el siguiente movimiento. Es decir, que si la bola 1 está en la posición X=2, Y=5, le sumaremos uno a ambas, y calculamos así el movimiento: X=X+1, X=3; Y=Y+1, Y=6. Lo mismo para las posiciones X e Y de la bola 2. Primero la bola 1, luego la bola 2, alternativamente, sin parar.

Al valor que le sumamos a las posiciones X e Y le llamamos desplazamiento. Nos referiremos a ellos como DX y DY. Así que tenemos X1, Y1, DX1, DY1 para la bola 1 y X2, Y2, DX2, DY2 para la bola 2.

Pero si el desplazamiento es 1, ¿porqué necesitamos una variable?. Pues porque el desplazamiento puede ser negativo. Imagina que avanzamos con la bola 1 hasta llegar al borde del tablero. El siguiente movimiento no puede ser sumarle 1 a la posición X o Y. Debemos aplicar un cambio de dirección de la bola, com osi esta hubiera rebotado.

Si, por ejemplo, X1=10 e Y1=19, siendo que 19 es el tope del tablero, el valor de DY no puede ser 1, debe cambiar a -1, de esta forma, el cálculo del siguiente movimiento seria: X1=10 +1= 11; Y1=10+(-1)=9. Hemos cambiado la dirección del movimiento vertical de la bola 1, y así seguirá, hasta que la bola rebote en otra pared, y debamos cambiar el valor de DX o DY.

Para hacer este cambio, siendo que el valor de DY es 1 inicialmente, sería suficiente con hacer:

Consulta la matriz de la entrada anterior, porque en el programa, no se usan las variables que he puesto en este ejemplo, sino que los datos se guardan en la matriz b%(). Es lo mismo. sigue habiendo una X e Y por cada bola, y un desplazamiento de X e Y por cada bola, solo que, por ejemplo, para referirnos a la Y de la bola 1, debemos usar b%(0, 1). Y para referirnos a su desplazamiento, deberemos usar b%(0, 3).

Para hacer el cambio de dirección, entonces, usaríamos:

Y para añadir el desplazamiento a la Y después:

Veamos cómo usarlo en el programa.

En esta nueva versión del programa se han llevado a cabo algunos cambios y se ha añadido varias funciones. Este es el código.

En la línea 530 inicializo una nueva variable n%. La usaré en el flujo principal del programa, en la línea 190. Esta variable va a servirnos para identificar, alternativamente, la bola con la que vamos a trabajar, y lo hará con la fórmula:

n% = 1 – n%

Como n% empeiza valiendo 1, el valor de n% al realziar esta operación es 0, porque 1 – 1 = 0. La siguiente vez el valor de n% será 1, porque 1 – 0 = 1, y vuelta a empezar, 0, 1, 0, 1…

Como se aprecia, en las líneas 200 y 210 se han añadido cuatro procedimientos que toman como parámetro de entrada este valor. Veremos a continuación que hace cada uno de ellos, pero lo que hagan va a estar supeditado al valor de n%, que indica en todo momento si estamos trabajando con la bola 1 (valor 0) o con la bola 2 (valor 1).

Seguimos. Las líneas de la 780 a la 830 han sido sustituidas por una única línea:

Como veremos, MUEVE() pinta una bola, la que le digamos, y MARCADOR() pinta el marcador de una bola, también la que le digamos.

El bucle FOR, que no requiere END FOR porque todo él está en una línea, es extraño. No tiene rangos, sino una lista de números. En SuperBASIC, los valores que tomará la variable del bucle en cada iteración pueden definirse como un rango (n TO m) o como iuna lista de valores (a, b, c, d…). Aquí uso esta lista de valores (0, 1) para dibujar la bola 1 y la bola 2, una en cada iteración del bucle, y sus marcadores.

El procedimiento MARCADOR() también ha cambiado. Ahora, como debe servir no sólo al inicio para pintar los marcadores, sino durante toda la demo para mostrar las actualizaciones de los marcadores alternos, recibe el parámetro bola%, que le permitirá saber en qué posición pintará el marcador, y qué valor debe poner en el marcador, apoyándose en la función CERO$().

En la siguiente línea decide la posición:

Como el marcador de la bola 1 debe pintarse en la posición 0,0 y el de la bola 2 en la posición 283,0, Para poner la posición correcta segun la bola, multiplico el valor 283 por bola%, de tal forma que si bola% es cero, 283*0 = 0, y si es 1, 283*1 = 283.

En esta línea puinto la bola que corresponda:

Como b%(bola%,4) contendrá la puntuación de la bola en cuestión, con PRINT imprimo en la posición ya calculada el marcador, usando la función CERO$() que devuelve una cadena de texto con ceros a la izquierda.

Bien, para mover una bola, necesitamos:

• Borrarla de su posición actual
• Calcular la nueva posición
• Pintarla en su nueva posición
• Comprobar si hay colisiones

Tal como dije, cuatro nuevas funciones se suman a esta versión. Cada una de ellas corresponde a uno de estos pasos. Veámoslas.

Código:

A efectos de aportar claridad a la explicación exclusivamente, en este yt sucesivos procedimientos usaré una serie de variables locales, es decir, cuyo ámbito estará sólo dentro del procedimiento. Así, x% e y% contendrán la posición de la bola en el tablero, y c1% el color de fondo de la bola con el que sobreimprimiremos f%, que contiene un espacio vacío. Con esto borramos la bola en cuestión, la bola 1 o la bola 2 dependiendo del valor de la variable bola%.

Código:

Mismo caso en este procedimiento. Aquí, con las varialbes locales x%, y%, dx%, dy% calculo la siguiente posición de la bola, y la guardo en la matriz. Ver las líneas 1080 y 1090. a x% le sumo dx% y lo guardo en b%() y lo mismo con la y%.

Código:

En esta ocasión uso X e Y, el color del fondo y el color de la tinta, porque se trata de dibujar la bola que corresponda con sus colores. Como los colores de la bola y del fondo son inversos en cada bola, es decir, la bola 1 tiene de fondo el color azul y la tinta el color amarillo, y la bola 2 al contrario, el fondo amarillo y el color de la tinta el azul, el color c2%, que corresponde a la tinta, se calcula accediendo al color de la bola contraria, empleando la formula 1-bola% que vimos antes en n%.

Código:

Esta es la parte interesante, donde se comprueba si hay rebotes y, en tal caso, se hacen los cambios de dirección. Aquí usaré la posición X e Y de la bola y sus correspondientes desplazamientos DX y DY.

En las líneas 1260 y 1270 puede verse que si el valor de X o de Y es 0 o es 19, que son los límites del tablero, el valor de DX o de DY cambia, es decir, se convierte en el opuesto (p.ej. DX=-DX). Y si cambia, se guarda su valor opuesto en la matriz.

Y vuelta a empezar: borrar la bola, calcular la nueva posición, pintar la bola, compribar colisiones. Pruebalo ejecutando el programa.

.La próxima entrega será la última, y en ella veremos como aumentar el marcador y comprobar colisiones con la zona del contrario.

Tomando como base el ejercicio anterior de comer donuts, esta vez vamos a hacer que, cuando el avatar se coma un donut, su cuerpo crezca, y le salga una cola tan larga como donuts ha comido. Por supuesto, a medida que movemos el avatar, su cola se arrastra con el, como en el conocido juego Snake. Esto es, por si no lo habáis notado, un clon de dicho juego.

Las partes del cuerpo podemos representarlasa con la letra «M». Para arrastrar el cuerpo de nuestro avatar con forma de serpiente, con cada movimineto, debemos limpiar la cola de la serpiente. Esto implica que, de alguna forma, debemos guardar en orden, en alguna estructura, las posiciones XY no sólo del avatar (la cabeza de la serpiente), sino de cada parte del cuerpo, y esta estructura será mayor cuanto más grande se haga la serpiente como consecuencia de comer donuts.

¿Y qué tal si le añades un marcador donde ir anotando puntos?

• Manual del QL en español
• Manual de Toolkit II en español
• Código en GitHub – repo Sinclair-QL-YinYang

Puedes seguir los comentarios de la comunidad en: https://retrowiki.es/viewtopic.php?f=98&t=200040286

Programando mi primera Demo en QL – fascículo IV, colisiones y puntuaciones

Viene del artículo: «Programando mi propia demo en QL I»

Sigo con esta serie de artículos, y empezamos hablando de los tipos de los variables.

Como en otros BASIC de la época, en SuperBASIC las variables numéricas se indican con una serie de letras y números, dando comienzo con una letra, y pudiendo usar guiones bajos, pero no otro signo.

Las variables de cadeta o de texto, emplean el símbolo $ al final. Así «var_numero» y «var_cadena$» serán respectivamente, una variable numérica y una variable de cadena.

Pero en SuperBASIC podemos indicar que una variable va a contener un valor numérico entero añadiendo % al final del nombre de la variable, así pues «var_entero%» será una variable que almacenará valores enteros. Si le asignamos un valor decimal, sólo almacenará la parte entera. Esto es útil para reducir el consumo de memoria. Las variables enteras ocupan menos espacio en memoria y la aplicación funcionará más rápido, y esto también es de utilidad si decidimos compilar nuestra aplicación, ya que el ejecutable ocupará menos.

Pero en SuperBASIC, este tipo de variables enteras no pueden usarse en los bucles, a no ser que hayamos cambiado nuestra ROM por la ROM Minerva, una ROM avanzada a la ROM original del QL, que sí lo permite.

Como siempre, puedes conocer más leyendo la guía del usuario.

En esta nueva versión del programa he añadido contenido a los procedimientos INICIO, PANTALLA y FIN, he añadido un nuevo procedimiento MARCADOR y una función llamada CEROS$, que recibe un parámetro, como luego veremos.

El nuevo código es este:

No te asustes. Esto no son Mátemáticas, o al menos no muchas Matemáticas. Ya sabemos que hay dos bolas que rebotan, esto se ve en la captura de la demo (articulo anterior). Y hay un espacio sobre el que se mueven. Llamemos a las bolas «b» y al espacio «tablero».

Para conocer en qué posición del tablero está cada bola en un momento dado necesitaremos guardar una posición «X» y otra «Y», por cada bola, osea X1, Y1 y X2, Y2. También necesitaremos saber el desplazamiento que debemos aplicar a la bola: DX1, DY1, DX2, DY2.

Si una bola está en la posición X,Y, la siguiente posición en la que estará será X+DX e Y+DY.

Además, por cada bola, necesitaremos saber su color y la puntuación que tiene en cada momento.

Son muchas variables relacionadas con una misma cosa. ¿Qué tal si las juntamos en una estructura de datos de dos dimensiones, como una tabla, en la que haya dos columnas, una para cada bola, y 6 filas, una por cada concepto? Veamos la siguiente tabla.

Si, por djemplo, quiero saber la posición Y de la bola 2, tengo que consultar el elemento (1, 1) de la matriz. Fijate que la matriz empeiza en (0, 0), y que cada elemento de la matriz comienza por 0, o 1 según sea el valor de la bola: 0 para la primera bola (bola 1) y 1 para la segunda bola (bola 2).

Para definir una matriz como esta, empleamos la instrucción DIM seguida del valor máximo de las dimensiones de la matriz, en este caso (1, 5):

Como los valores que vamos a guardar son numéricos y enteros, podemos definir a la matriz como «b%». Luego veremos como poner valores en la matrizs y consultarlos.

El tablero tiene 20 x 20 casillas. Necesitamos el tablero porque hay zonas de este que pertenecen a una bola y otras zonas que pertenencen a las otras bolas. ¿Cómo saber que zonas del tablero son de la bola 1 y cuáles de la bola 2? con una matriz que tenga las dimensiones del tablero, y que guarde, en cada elemenrto de la matriz un 0 si pertenece a la bola 1 y un 1 si pertence a la bola 2. Así:

Osea, 20-1 en ambos casos. Recuerda que las matrices comienzan por 0, y de 0 a 19 van 20.

Con esto tenemos definido cómo queremos guardar los datos. Vamos a ver cómo.

Este procedimiento, como dijimos en el artículo anterior, inicializa las variables de la demo.

En la línea 320 se define el ancho y alto del tablero en las variables an% y al%. En la 330 se inicializan las dos matrices tablero% y b%.

Nota: Podría haber puesto DIM tablero%(19, 19) en vez de tablero%(an%, al%), pero así aprovechamos para ver que a una matriz podemos pasarle valores de una variable. En estos fascículos vas a ver cosas así con frecuencia. A los ya entendidos les parecerá que no tiene sentido, pero está pensado para probar y aprender cosas.

En la línea 340 definimos las variables de cadena f$ y b$. no confundir b$ con b%. La variable b$ va a contener el caracter con el que representaremos la bola. una O mayúscula. La variable f$ contiene un carácter vacío. Es lo que usaremos cuando queramos borrar la bola. He puesto un comentario con una definición alternativa de b$. Con b$=CHR$(226) asignamos a b$ el carácter que representa una bola en el juego de caracteres de la ROM Minerva, ya que esta ROM tiene un juego de caracteres diferente, con más símbolos. Puedes ver el juego de caracteres de tu ROM con este sencillo programa:

Seguimos. Entre las líneas 350 y 380 tenemos un bucle FOR i=0 TO 19 que termina con un END FOR i, y que nos va a servir para hacer 20 vueltas. A cada vuelta, vamos a meter valores en la matriz tablero%.

Las lineas 360 y 370 son a la vez dos bucles más. Ambos bucles están dentro (anidados) del bucle de las 20 vueltas, pero pasa algo curioso, no hay END FOR… Si el bucle y las instrucciones se ponen en una misma línea, no es necesario poner END FOR.

Con estas dos líneas vamos a llenar de 0 y de 1 cada parte del tablero que corresponde, inicialmente, a cada bola, tablero%(i, j), siendo que «i» corresponde a la fila y «j» a la columna. Estas son las varialbes de cada bucle. La asignación se hace mediante el signo =, como con cualquier varialbe, pero la variable debe indicar el elemento (i, j) en este caso.

Entre las líneas 390 y 500 defino los valores de la matriz b%(1, 5). Ver comentarios.

de las líneas 400 a la 430 uso la instrucción RND. Esta me permite obtener un valor al azxar para inicializar la variable, entre un par de valores dados. Al principio del programa usamos RANDOMISE, este es el motivo, generar números verdaderamente aleatorios con cada ejecución del programa.

Las líneas 450 y 460 asignan el valor del desplazamiento inicial de cada bola, de tal forma que la bola 1 avanzará 1 posición horizontal a la derecha y una vertical abajo, y la bola 2 lo hará al contrario, avanzará una posición horizonal a la izquierda, y una posición vertical arriba.

No hemos terminado, nos queda mucha tela que cortar. FIN es el procedimiento que uso para terminar el programa correctamente.

Fijate que en la línea 140 he añadido ch% y ch2%. Estas variables van a contener el núnero de canal (channel) de las zonas de pantalla donde vamos a dibujar. Si no lo sabías, el QL tiene la posibilidad de dfefinir rectángulos de pantalla denominados ventanas, donde podemos escribir como si de otras pantallas se tratase, con su sistema propio de coordenadas independiente, colores de fondo y de tinta… luego veremos cómo se definen.

El caso es que vamos a usar dos canales que identifican estas ventanas, y en el procedimiento FIN lo que hacemso es cerrar estos canales que corresponden a ventanas mediante la orden CLOSE. Las ventansa las abriremos en el procedimiento PANTALLA, aunque también podríamos haberlas abierto (OPEN) en el procedimiento INICIO.

En este procedimiento, además, cambiamos al MODE 4 antes de salir. Esto ayudará a ver mejor los listados, con más caracteres por línea cuado hagamos LIST.

Primero establezco, con MODE 8, el modo de pantalla a modo 8 (8 colores) que tiene una resolución de 256×256 pixeles.

En la línea 620 leo los colores de la matriz de las dos bolas y los guardo en c1% y c2% con c1%=b%(0,5): c2%=b%(1,5). Como vemos, podemos usar la matriz como una variable. Lo uso aquí, además de como medio de parendizaje, para no tener que escribir la posición de la matriz cada vez que quiero usar el color de la bola 1 o de la bola 2.

En las líneas 630 y 640 abro el canal ch% y el canal ch2%. vemos que el canal ch% tiene la siguiente definición:

Fijate que, aunque en el modo 8 las dimensiones de la pantalla son de 256×256 pixels, igualmente al abrir un canal destinado a una ventana debemos indicar las dimensiones de la ventana con un tamaño máximo de 512×256.

La segunda ventana tiene otras dimensiones, 324×225 y está ubicada en la posición 97×18, siendo 97 la posición horizontal y 18 la vertical:

En las líneas 670 y 680 uso la instrucción WINDOW para cambiar las dimensiones de las ventanas. Los datos son los mismos que al definir una ventana, ancho, alto, posición hortizontal y posición vertical, pero con WINDOWS podemos cambiar su tamaño y posición en cualquier momento. Con los cambios de posición de ventamas hemos hecho que ambas tengan el mismo ancho, estén las dos una encima de la otra, en el centro, y ahora podemos seguir trabajando con ellas, pero todo lo que hagamos a partir de ahora con esos canales sólo agfectará a la zona interior de sus nuevas dimensiones, y el fondo que tenían antes quedan pintados en pantalla, pues las ventanas son realmente invisibles a nuestros ojos, salvo que le demos un color de fondo o pintemos o escribamos en ellas.

En las lineas 690 y 700 pongo el color de fondo de cada ventana, el color de la bola 1 en ch% y el color magenta (rosa) en ch2%. El canal ch% es que usaremos para dibular el espacio donde rebotan las pelotas, el tablero, y le he dado las medidas de 20×20 caracteres. ch2% contendrá el marcador.

En la línea 710 defino un borde tanto para ch% como para ch2%. En el primer caso es un borde del grosor de un pixel y de color magenta, y en el caso de ch% tambien tiene un grosor de un pixel, y este tendrá el color del fondo, ya que no le he definido un color concreto. Los bordes reducen el ancho y alto del espacio donde podemos escribir en las ventanas, de tal forma que, si la ventana asociada al canal ch% está definida con un ancho de 324 y un alto de 202 pixeles, sólo podremos usar 322 y 200 respectivamante, pues el borde que hemos creado resta 1 pixel arriba, otro abajo, otro a la derecha y otro a la izquierda.

En la línea 720 uso BLOCK. Esta instrucción permirte crear rectángulos dentro de ventanas. Los datos son los mismos que los de las ventanas, ancho, alto, x e y, y además podemos indicaer el color de relleno, pero estos bloques tiene como referencia de posiciones el punto 0,0 de la ventana en la que se dibujan, y además están sujetos a un valor de escala. Dejaremos esto para otro momento. Ahora es suficiente con saber para que pintamos este rectángulo.

Al cambiar el tamaño de la ventana asociada al canal ch% pintamos la ventana delo color de la bola 1, pero en la demo, cada bola es dueña de la mitad del tablero. Con este BLOCK pinto la mitad correspondiente al color de la bola 2 en la mitad derecha del tablero. Es decir, primero puse el papel (fondo) de la ventana entera con el color c1% y luego he puesto el papel de la mitad derecha del color c2%.

En la línbea 730 cambio el tamaño de los caracteres con CSIZE. Esta instrucción permite tener caracteres el doble de ancho y alto que su tamaño original y con distinto espaciado. Ver CSIZE. Es muy útil para títulos.

En la línea 740 pongo el color de la tinta INK con la que van a ser dibujados los caracteres en ch2% de color verde, y luego uso CURSOR para indicar la posición exacta dentro de la ventana donde se va a escribir el texto. Fíjate lo potente que es esto. Podemos empezar a escribir en cualquier posición de la ventana con una presición de píxeles. Por supuesto también podemso escribvir caracteres de la forma tradicional indicado filas y columnas con la instrucción AT.

En la línea 750 se manda a imprimir com PRINT el título de la demo: «YIN & YANG» que aaprecerá centrada en la ventana por arte de la instrucción CURSOR.

En la siguiente línea cambio el color de la tinta de este canal del color verde, que era el que estaba, al color blanco.

Entre las líneas 780 y 830 dibujo las dos bolas en pantalla, en su posición inicial. Primero la bola 1 y luego la bola 2 de la misma forma. Pongo el color del fondo, y el color de la tinta, con AT indico la posición en la cuadrícula de caracteres donde estará la bola, datos que obtengo de b%, de tal forma que a AT le paso el canal, lla posición X y la posición Y, y luego con PRINT imprimo la pelota b$ donde le hemos dicho.

Ya tenemos dibujado el tablero y las dos pelotas. Ahora, con invocando al procedimiento MARCADOR voy a incializar los marcadores.

Este procedimiento es el encargado de poner los puntos de la bola 1 y de la bola 2 en el canal ch2%. En la bola 1 uso AT para posicionar los puntos y en la bola 2 uso CURSOR para posicionar de forma más precisa sus puntos. En ambos casos, a la hora de imprimir los puntos, uso la función CERO$, es decir, imprimo lo que devuelve de la función CERO$ cuando le paso el valor de los puntos que tienen que imprimirse. Ahora veremos por qué uso esta función.

Esta es una función, no un procedimiento. La particularidad de las funciones es que devuelven algo despues de procesarlo, y para ello usan RETurn.

Lo que hace CERO$ es recibir un valor, en este caso la puntuación de una bola, y devolver una cadena de texto de tres caracteres de ancho formateada con ceros a la izquierda de tal forma que si, por ejemplo, le pasamos el valor 8 devolverá «008», si le pasamos el valor 15, devolverá «015», y si le pasamos el valor 321 devolverá «321». Esto serśa de ayuda para que el marcador se vea siempre bien.

Al empezar, como la puntuación de cada bola está indiacada a 0, ambos marcadores se verán como «000». Cuando la función lo devuelva, esto es lo que se imprimirá en el procedimiento MARCADOR para cada uno de los marcadores de cada bola.

En la línea 980 se devuelve el resultado de la operación de rellenar con los ceros «0» que sena necesarios, mediante la instrucción FILL$, el valor guardado en txt$. Es decir, con FILL$ creamos una cadena de longitud 3-ln%, osea lo que falta para completar el número, y con & le añadimos el número que ya es una cadena txt$.

Un ejemplo: si la variable valor conrtiene 15, txt$ será «15» (una cadena), su longitud será 2, lo que obtenemos con LEN, y entonces deberemos rellenar con FILL$ a la izquierda con un (1) cero, es decir 3 – ln%, osea 3 – 2 = 1, y añadirle «15».

en la próxima ocasión veremos como aplicar movimiento y rebotes a cada una de las bolas para que se muevan por el tablero libremente.

El juego consiste en mover libremente por la ventana un avatar identificado con la letra «C» que se irá comiendo los donuts representados con la letra «o» que apareceran en posiciones al azar. Al comerse un donut aparecerá otro en otra posición, y así hasta pulsar ESC.

Dibuja una ventana en el centro de la pantalla, con las dimensiones que tú quieras. Estas dimensiones deben ajustarse al ancho y alto de los caracteres, incluso si usas borde. de tal forma que los caracteres que se impirman en ella deben caber completamente.

Usa las teclas del cursor y KEYROW para moverte, y controla que no te sales de la ventana.

Crea las variables siguientes:

• Una variable que contenga la letra C mayúscula, que será nuestro avatar en el juego.
• Una variable que contenga la letra o minúscula, que será lo que nos vamos a comer en el juego.
• Una variable que contenga un espacio vacío » » que usaremos para borrar el avatar y el objeto a comer antes de pintarlo de nuevo en la siguiente posición.
• Una variable X y otra Y que guarden las posiciones horizontal y vertical de nuestro avatar (la «C») en la ventana. Puedes inciarlizarlas en la posición que desees dentro de la ventana o hacerlo de forma aleatoria.
• Una variable X2 y otra Y2 que guarden las posiciones horizontal y vertical del objeto a comer y que aparecerá en las posicones aleatorias que le indiques.

Para moverte por la ventana suma o resta uno a las posiciones X e Y del avatar con cada pulsación, pero antes, asegurate que X e Y no han llegado a los bordes de la ventana, si es así, no sumes ni restes nada a las posiciones X e Y, simplemente por ahí no se puede avanzar.

Enlaces recomendados

• Manual del QL en español
• Manual de Toolkit II en español
• Código en GitHub – repo Sinclair-QL-YinYang

Puedes seguir los comentarios de la comunidad en: https://retrowiki.es/viewtopic.php?f=98&t=200040267

Programando mi primera Demo en QL – fascículo III, movimiento y rebotes

Parece que, más allá de los sospechosos habituales de la comunidad de QL, hay gente interesada en conocer un poco más sobre el QL, y en programar en él. Varios juegos en SuperBASIC han visto la luz recientemente en los foros de RetroWiki,. Esta colección de pocos artículos que inicio hoy pretende dar a conocer las particularidades del SuperBASIC mediante un ejemplo práctico, la realización de una pequeña demo.

Para aprovechar estas entregas es necesario que tengas conocimientos básicos de programación y sobre el Sinclair QL.

Me quedé hipnotizado con este ejemplo de programación, y me propuse portarlo al QL. A medida que lo iba desarrollando, más potencial le veía como medio para aprender programación.

El código en JavaScript y el video puede verse aquí: https://github.com/vnglst/pong-wars

Este es el aspecto que tendrá la demo en el QL.

Del potencial del lenguaje del QL ya se ha hablado mucho y bien. La característica que más destaca de él es que permite realizar programación estructurada mediante el uso de Procedimientos y Funciones. Estos se definen mediante una sentencia DEFine PROCedure o DEFine FuNtion. Por ejemplo, si necesitamos llamar al código que aumenta un contador ne un programa, podemos hacer un GO TO o GO SUB o usar un procedimiento o función, que sería la forma correcta de hacerlo en SuperBASIC:

Como vemos en la línea 140, es suficiente con poner el nombre del procedimienrto para que se ejecute el código entre DEFine y END DEFine. No importa en la línea que esté el procedimiento. SuperBASIC lo encontrará y usará. El resultado obtenido será 2.

A un procedimiento o función podemos pasdarle parámetros, como veremos más adelante, igual que en cualquier lenguaje actual.

Esto que es tan obvio conlleva una forma de hacer programas distinta, modular, en la que el código puede trocearse para hacerlo más operativo y limpio, aunque esto implica, generalmente, un mayor número de líneas.

Pues bien, partiendo de esta premisa, veamos cómo sería el «esqueleto» de nuestro programa demo:

Podría decirse que esta es una estructura genérica que podría usarse con cualquier programa en SuperBASIC que hagamos. Vamos a estudiarla.

Como se aprecia, las lineas estan numeradas, y cada línea puede tener una o varias sentencias separadas por dos puntos. Incluso podemos tener líneas con dos puntos y nada más. Esto se usa para separar visualmente el código.

Los comentarios en el programa se incluyen con la sentencia REMark. Podemos tener comentarios que ocupen una línea o al final de una línea, tras una o varias sentencias en esa línea.

En la línea 140 vemos un CLEAR. Esto se usa para limpiar el valor de las variables del BASIC. A continuación va un comentario con la ruta de nuestro programa, un ejemplo de lo que comentaba antes sobre los REM.

En la siguiente línea, mediante variables, podemos determinar el dispositivo, el nombre del programa y la versión del mismo. Esto será útil para el procedimiento llamada sa.

El procedimiento sa

De la línea 240 a la 310 se define el procedimiento «sa» que sirve para salvar los cambios de nuestro programa a medida que programamos.

Este tipo de procedimientos es muy común en el mundo QL, y ayudan a no tener que escribir los comandos para borrar y volver a guardar el programa que vamos haciendo. SuperBASIC permite usar los procedimientos en el sistema como si de nuevos comandos se tratase, así pues, una vez hayamos ejecutado el programa, aunque paremos su ejecución, los procedimientos pueden ser invocados desde la línea de comandos.

Con sólo escribir sa en la línea de comandos, se guardará una versión actualizada de nuestro programa. Eso sí, las variables dev$, prg$ y v$ (varaibles que contienen texto y por eso terminan en $) deben tener los valores correctos, pues en la línea 290 se compone la ruta y el nombre dle fichero que usaremos.

dev$ tiene como valor mdv1_, que corresponde a un dispositivo de microdrive. Podemos usar otros como flp1_ para disqueteras, win1_ para discos, ram1_ para discos RAM… y de cada tipo de dispositivo puede haber 8, por ejemplo, de microdrives puede haber mdv1_, mdv2_ … mdv8_

En la línea 290 se usa el caracter & para concatenar o unir estas cadenas que se guardarán en la variable file$

Cuando estés programando, verás lo útil que resulta el nuevo procedimiento/comando sa.

El programa como tal está entre las líneas 170 y 220:

Procedimiento INICIO

Este es un procedimiento que contendrá la inicialización de variables del programa. En la siguiente versión del programa veremos qué variables necesitaremos y cómo se definen. Por ahora dejamos el procedimiento creado entre las líneas 330 y 350.

Procedimiento PANTALLA

Este procedimiento será el encargado de dibujar la pantalla, de mostrar la interfaz de la demo. Está entre las líneas 410 a 430. Ahora no hace realmente nada, igual que INICIO, pero en la siguiente versión le daremos contenido.

Procedimiento FIN

Este procedimiento definido entre las líneas 370 a 390 nos permitirá cerrar el programa de forma adecuada. Mismo caso que en los procedimientos anteriores. Lo veremos en acción en la siguiente versión del programa.

STOP

Esta instrucción sirve para parar la ejecución del programa, como puede suponerse. Realmente no es necesario usarla en este programa, pero ayuda a delimitar visualmente donde termina el código.

Si bien debajo de la línea 220 hay definiciones de Procedimientos, estos no se ejecutarán a no ser que se llamen o invoquen en el programa.

REPeat prg

Repeat es un bucle que tiene asociado un identificador, en este caso «prg», que nos da la oprtunidad de ejecutar el contenido de las líneas entre REPeat y END REPeat hasta que se cumpla una condición de salida. Cuando esto ocurre, se sale del bucle mediante EXIT, como puede vertse en la línea 200.

El bucle se repite hasta que pulsemos la tecla ESC, y entonces salede él y continua la ejecución con FIN y luego STOP.

KEYROW es una instrucción que lee el teclado y devuelve un valor numérico correspondiente a la tecla pulsada. En este caso KEYROW lee la fila 1 de la cuadrícula del teclado y comprueba si esta devuelve el valor 8, que corresponde a la tecla ESC. Consulta la guía dle usuario para más información y uso de KEYROW.

Una particularidad del SuperBASIC es que, si ponemos las instrucciones que deben ejecutarse tras un IF en una sola línea, no necesitamos hacer uso de THEN ni tampoco de END IF, com ohago en la línea 200.

En la línea 190 incluiríamos el resto de programa y los procedimientos a los que deseemos invocar en las siguientes versiones de esta demo.

El programa realmente no hace nada. Una vez ejecutado, espera todo el tiempo a que pulsemos la tecla ESC para salir.

Podemos copiar el código y guardarlo en nuestor disco como un fichero de texto plano, en la ruta «mdv1_yinyang_v1_bas»

Si vamos a cambiar la ubicación del fichero, debemos cambiar también el valor de la variable dev$ editando el código, para poder utilizar correctamente el comando sa. Un ejemplo de edición de código desde QL. Introducir este comando, y una vez editado, pulsar ENTER.

Aparecerá la línea en la línea de comandos para poder editarla. Luego se guardarán los cambios con ENTER.

Si tienes el Toolkit II o TK2 para los amigos, puedes hacer uso del comando ED, que te permite editar el programa en la ventana donde se lista. Lee el manual de TK2.

Si ejecutaste el programa, cuando hayas hecho los cambios, podrás usar el comando sa con tranquilidad para guardarlo.

Haciendo uso del comando RENUM las líneas se renumerarán automáticamente de 10 en 10, empezando por la línea 100, dejando espacio para nuevas lineas.

Recuerda que, para borrar, debes usar la combinación de teclas CTRL + tecla izquierda o CTRL + tecla derecha.

No te pierdas la próxima entrega en la que definiremos las variables de la demo, la pantalla y el marcador de puntuación.

Mientras tanto, ¿qué te parece probar todo lo visto aquí con una pequeña aplicación hecha por ti?

Ejercicio

Te propongo que, usando esta estructura, crees un menú en pantalla que muestre tres opciones, de tal forma que al pulsar 1, haciendo uso de PRINT, la aplicación escriba, la frase «Buenos días». Si pulsamos 2, se debe imprimir «Buenas tardes» y si pulsamos 3, debe decir «Buenas noches». Usa ESC para salir.

Cada una de las tres opciones puede ser invocada mediante un procedimiento llamado OPCION1, OPCION2 y OPCION3 respectivamente. Dentro de estos procedimientos estarían los PRINT que muestran los mensajes.

Las pulsaciones de las teclas se comprobarán mediante KEYROW (ver manual) haciendo uso de los correspondientes IF, de la misma forma que en la línea 200, pero en vez de usar EXIT invocaremos al procedimiento que corresponda.

• Manual del QL en español
• Manual de Toolkit II en español
• Código en GitHub – repo Sinclair-QL-YinYang

Puedes seguir los comentarios de la comunidad en: https://retrowiki.es/viewtopic.php?f=98&t=200040237

Programando mi primera Demo en QL – fascículo II, variables y tablero

Se que el título de este post es un poco extraño, pero me permite compartir lo que recibí en un paquete entregado por Correos esta semana. Se trata de dos «expansiones» para uno de mis QLs.

Una de las expansiones es una puerta abierta al futuro, se trata del dispositivo de moda en el mundillo QL, QIMSI. Seguramente ya lo conoceréis porque hemos hablado mucho de él en otros post de Retrowiki y en Qlog. En el encuentro de Majadas del 40 aniversario lo pudimos ver en vivo (muchos de nosotros por primera vez). Brevemente, para quien no lo conozca, se trata de una diminuta placa que se conecta al puerto ROM del QL y que aporta almacenamiento masivo en una micro-SD, conexión de ratón PS2, conexión a un teclado externo PS2 y posibilidad de incoporar comunicaciones serie de alta velocidad. Ahora tengo la QIMSI en uno de mis QL con una GoldCard, esto me permite ejecutar tanto QDOS como SMSQ/E, que por cierto, se acaba de liberar una nueva versión hace un par de semanas.

La segunda «expansión» es una mirada al pasado, concretamente una disquetera de 5 1/4 DD de Miracle System. Sinceramente no me esperaba que funcionara, pero fue conectarla al QL, encender el sistema, formatear un disquete, copiar ficheros y …. sorpresa ¡¡FUNCIONAAAA!!. Otra prueba interesante que realice es acceder a la disquetera como «unidad compartida del QL» desde la FPGA (Q68) y desde el emulador en el PC (QPC2) empleando la QLNET (la red local del QL). Mola mucho hacer un «n1_dir_flp1_» desde la FPGA o el emulador en el PC y ver como se enciente la luz de la disquetera del QL mostrando el contenido del directorio.

Esto me parece fantástico, una plataforma que ha sobrevivido 40 años y que en la actualidad aún se mantiene su sistema operativo el cual puede lidiar con tanto con dispositivos modernos (tarjetas microSD de almacenamiento masivo) como con dispositivos de almacenamiento de principios de los 80.

Os pongo algunas imágenes:

QL is 40, QL forever!

PD:
¡Gracias napsternds! 

Resumen por: Miguel Ángel Rojo

Varios integrantes del grupo de QL estuvimos en el programa Super Directo de El Mundo del Spectrum emitido el 1 de febrero de 2024 con motivo del 40 aniversario del QL. Este programa fue la base, junto con la entrevista que se llevó a cabo en el evento de Majadas del Tietar, para su podcast 12×04.

Acceso al Podcast 12×04

Esta vez los amigos del QL se fueron a una entrevista monográfica y en directo sobre el Sinclair QL al programa «El mundo del Spectrum» el 1 de febrero del 2024, que contó con 7 invitados expertos de este mítico y desconocido ordenador.

Alejandro, Jesús y Juan estaban acompañados por Napsternds, Badaman, Zerover, Titoxunix, AFX, Álvaro Alea y Miguel Ángel Rojo.

Alejandro ofreció una breve explicación sobre la salida del Sinclair QL en habitual obertura del programa. Le sigue Jesús sobre lo que se va a hablar durante las más de dos horas siguientes.

Juanfra nos ofrece su opinión sobre los seguidores del Spectrum y como lo veían, como la alargada sombra de hijo mayor, a través de las revistas de la época, y posiblemente siendo sin duda el siguiente paso del Spectrum. Esto, no obstante, no lo fue para todos ellos, por los cambios que vinieron en el mundo de la Informática y la aparición de nuevos sistemas.

Los protagonistas fueron hablando, uno a uno, dando sus agradecimientos y un breve comentario sobre su visión de este particular ordenador.

Jesus, entrando al turrón, pregunta por el acontecimiento sobre el evento del 40 aniversario o QLis40.

Badaman nos cuenta que el 16 de abril de 2013 en una reunión por videoconferencia, hizo la propuesta, un evento de QL en España aprovechando las instalaciones del Museo de Historia de la Computación ubicado en Majadas de Tiétar, Cáceres, con fecha al año siguiente, en torno al 12 de enero, coincidiendo con la presentación a los medios del QL en el 84.

En el evento se puedo contabilizar unas 40 personas y se mostraron unos 15 QLs, y maquinas vistas rara vez, como toda la colección de Fede, la de Titoxunix con su placa nueva de QL de Tetroid, o la fabricación de hardware que hace Alvaro.

Badman, Zerover. Afx, todos aportaron al evento su granito de arena. Hubo, actividades, charlas, exposiciones de equipos con ampliaciones clásicas y nuevas, faltando tiempo para trastear con ellas.

Napsternds nos cuenta lo mágico que puede ser un QL viéndolo desde el punto vista de tres generaciones, el que comenzó en la época como su primer ordenador y no lo dejó, el que volvió después del fiasco de los microdrives, o el que, como él y Miguel Angel, empezaron hace pocos años.

Posibilidades de configuración, trastear, conseguir funcionalidades, y mucha exploración, el descubrimiento es lo que nos tiene enganchados y resulta ser una maravilla.

Álvaro da un visión en perspectiva sobre el recuerdo de la presentación del QL, su diseño, las prisas, el “contrarreloj” por superar a sus rivales y las decisiones que, a la larga, salieron muy caras a pesar de que la máquina se distribuyó con retraso.

A la pregunta de la utilización de los microdrive, TitoxUnix nos cuenta que Sinclair los introdujo por abaratar y por el intento de imponer su propio estándar, y que el mayor problema del QL fue el tiempo, con un desarrollo muy largo, ya que fue un ordenador que tendría que haber salido a finales del 83 como mucho, y con mas inversión.

Afx añade que, en Sinclair, no supieron fijar un objetivo. No tenían claro lo que querían: ordenador portátil, super Spectrum, ordenador de oficina…

Sinclair fue un visionario, pero tal vez se adelantó demasiado a su tiempo, y sus productos no llegaron en el momento adecuado: mini televisores, calculadoras, coches eléctricos… con el QL tenia la perspectiva de hacer un producto barato para competir de igual a igual con los PCs, pero era un reto, sobre todo ante la llegada de los clónicos PC.

Sinclair tubo un acierto rotundo con el ZX80, ZX81 y su ZX Spectrum. Al alcanzar un éxito brutal, convirtiéndose en la empresa número uno del mercado, y con la presión de los accionistas de conseguir otro éxito, el descontrol por el crecimiento de la empresa, con un QL poco definido… con todo eso se alargó su salida al mercado, entregándose a los clientes tarde y con muchos problemas, lo que hizo que una maquina adelantada a su tiempo, con un SuperBASIC y un sistema operativo espectacular, no tubo la repercusión deseada en el mercado.

Juanfran, que es poseedor de una gran colección de Sinclair, nos mostró la publicidad de la época, el catálogo del Sinclair QL con las ordenes de pedido del ordenador. Todo un tesoro que habla de sus características y sus posibilidades profesionales a un increíble precio de 110.000 pts (el equivalente a unos 2.000 € o más de hoy)..

Un dato importante del suplemento número 3 de QL User nos dice que Sinclair recibía entre 500 y 600 hojas de pedido de QLs al día, teniendo un retraso increíble en los pedidos.

El Sinclair QL tenía previsto que saliese personalizados para 12 países diferentes, mas un importador, pero, finalmente, salieron 9.

Entrando ya en tema de hardware, TitoxUnix nos da una explicación sobre el QL. Un micro de 32 bits con un 68008 de bajo costo, una ULA 8302 que controla todos los periféricos y con más ampliaciones que un ZX Spectrum.

El resumen del hardware fue que en febrero del 86 el QL ya era un ordenador retro y no había mercado para él. Todo desapareció, pero gracias a entusiastas de la comunidad, aún sigue viva, después de 40 años.

Del sistema operativo de Tony Tebby y el SuperBASIC de Jan Jones se podría hablar largo y tendido, pero dejaremos cuatro detalles. El QL estaba diseñado con algo que salió al Mundo mucho después, el Plug&Play que permitía que las ampliaciones se conectaran y autoidentificaran en el sistema sin necesidad de cargar controladores. Otra novedad era la multitarea real. Se añadió una suite ofimática en 4 cartuchos de Microdrive (procesador de textos, hoja de cálculos, base de datos, y gráficos empresariales) de serie, que fue escrita por la empresa PSION. Todo ello mucho antes del lanzamiento de Microsoft Windows.

Muchos coinciden en lo sorprendente que puede ser un QL con su entorno de ventanas y la conectividad de red. Mediante un cable de audio mono entre dos QLs se puede montar una red local con la que ejecutar programas y poder comunicarse con dos simples comandos. Era algo de ciencia ficción en el 85. Cuando muy poco después llegaron las ventanas, fue algo impresionante. Se trata del Pointer Environment (PE), 10 años antes de Windows, y a la par que los Mac, el QL tenia algo parecido, con ratón ya entonces.

Álvaro comenta que lo que más le llama la atención del hardware del QL es el segundo procesador. El microcontrolador 8049, que libera muchas tareas al 68008. Una idea revolucionaria para ahorrar costes.

Se habló también un poco más sobre los microdrives. Hoy es muy complicado encontrar microdrives que funcionen, porque se deterioran con el tiempo, al igual que las membranas del teclado. El resto del equipo aguanta bastante bien.

En el ámbito de los clones, que también los hubo, el Merlin Tonto (de ICL), fue un ordenador de oficina con teléfono para secretarías que Sinclair hizo en colaboración con British Telecom partiendo del hardware del QL. En Australia fue vendida por Computerphone como OPD. No tuvo mucha repercusión. Venía con la suite de PSION y el SuperBASIC venia en un microdrive.

En cuanto a emulación de QL, está muy avanzada, con una gran variedad de programas emuladores, ya que, cuando el QL se descontinuó y los equipos se fueron estropeando, no se tuvo más remedio que recurrir a ellos. Los hay para Mac, Windows y Linux. Miguel cuenta que, uno de ellos es QemuLator, muy fácil de usar, e invitando mucho a trastear con él, pudiendo acceder tanto a los contenedores .win como a los microdrives, entre otros.

Cabe destacar también los siguientes emuladores: SMSQemulator, ZesarUX, MAME-MESS y QPC2, que emula a la perfección un sistema tan avanzado como es SMSQ/E. En FPGA también podemos implementar, con total realismo, un QL. Mister, Mist, Sidi, Neptuno y recientemente, Poseidon.

Respecto al Software, Zerover comenta que lo que más le gusta es el SuperBASIC, y era de los que se hacia su propio software, modificando el juego de caracteres, creando su propio ensamblador para programar en código maquina, creando un editor de sprites, y haciendo pequeños juegos.

Sobre juegos, quizá los más relevantes son, el PSION Chess, el Mach Point, el juego de ajedrez por antonomasia en el QL, el Chess, y un gran juego de tenis muy logrado y entretenido, el Match Point. Por desgracia la scene es muy reducida, y salvo dos juegos conversacionales de elaboración reciente, no suele salir nada de nueva generación para el QL. Hay buenos juegos para QL, pero no son muchos, por ser un ordenador enfocado a las empresas.

Las revistas y libros eran muy necesarios para los usuarios entonces. La QL Word fue la revista por excelencia, heredera del QL User que se publicó hasta el 94, muchos años después de la desaparición del QL, y que era complicada de conseguir, salvo en sitios especializados, y dos revistas: la IQLR y QLTODAY, cuyo último numero data del 2013. Es admirable que la comunidad se mantuviese activa hasta esa fecha.

Actualmente existen varios sitios de información y preservación de QL destacados. Uno es el de Dylwin Jones, en inglés, y sinclairql.es recursos en castellano, realizado por Badaman, y que cuenta con el material del club de usuarios de QL en España, el club Qlave, cuyo material preservado por Salvado Merino, se puedo subir a Internet en el año 2002, fecha de la aparición de esta web.

Los libros de QL más destacados son «QL programación avanzada» y el de SuperBASIC de Jan Jones.

AFX nos cuenta algo muy interesante, lo que se puede hacer con la red, un PC, un QL y la IA ChatGPT. Para el 40 aniversario del QL, Afx creó un programa en SuperBASIC que conecta, vía RS232, el QL con ChatGPT a través de un PC con un emulador que hace de intermediario, para dialogar. Es una excelente forma de mantener la maquina viva con algo actual.

Álvaro nos cuenta que clonar el hardware para usar en QL es relativamente accesible, y hay una cantidad de ellos bastante importante, empezando por la Qubide de José Leandro y la placas clonadas de Álvaro Alea, y TitoxUnix y Zerover con pequeñas aportaciones muy interesantes. Internacionalmente, tenemos al ruso Tetroid, que hace una variedad importante de clones (Gold Card, Qubides, interfaces de disco…) algo en lo que los rusos siempre han sido unos expertos y han tenido relevancia en el mundo de los Spectrum.

Como hardware curioso y raro, tenemos un digitalizador de video que Salvador Merino mostró en el evento del 40 aniversario. Por desgracia, nos quedamos con las ganas de verlo en funcionamiento.

Para ir terminando y dar paso a las despedidas, la mayoría coincidimos que para entrar en el QL no hace falta tenerlo. Con un emulador puedes ver si te gusta, podrás disfrutar de sus bondades, incluso si tienes FPGA lo apreciarás con mayor calidad. Si uno se anima a comprar un QL, hay que tener en cuenta un posible cambio de membrana que puede estar deteriorada, y que necesitarás ampliarlo con más memoria sí o sí. Para esto, una Qubide quizá sea la mejor opción.

Gracias al esfuerzo y apoyo del usuario Exile, el emulador sQLux ahora soporta la configuración de teclado de PC en español. Algo que nos viene muy bien para poder programar o editar textos cuando usamos la ROM MGE o la ROM Minerva y cargamos el driver de teclado español.

Para que funcione, en el fichero sqlux.ini debemos indicar:

Después de una gran cantidad de soporte y pruebas, los cambios de código necesarios para el teclado en español ahora se han fusionado nuevamente en la rama maestra de sQLux, por lo que ya es posible descargar y compilar el emulador de forma sencilla.

Esta versión lleva el nombre interno de «The Comfy Chair», una parodia de los Monty Python que ha sido motivo de risas entre el programador y yo durante el proceso de desarrollo. Y es que «nadie espera a la inquisición española…» XD

Los cambios se han probado en X11 (Mint Linux, Ubuntu Linux y Pi Os) y MS Windows. Hay soporte para teclas muertas y una selección de combinaciones de teclas Alt Gr.

De forma predeterminada, Raspberry Pi OS usa SDL en X11, por lo que estos cambios actualmente funcionarán «listos para usar» para Raspberry Pi. Los cambios no funcionan en Raspberry Pi OS cuando SDL está configurado para usar Wayland, ya que la versión de Wayland que se usa actualmente en Pi OS no informa de pulsaciones de teclas muertas.

Para obtener la versión final de Windows o Linux, compílela a partir de las fuentes principales de sQLux en: https://github.com/SinclairQL/sQLux

Sigue los pasos básicos en Debian Linux (necesitas Git):

En el repositorio hay información para compilar el emulador en otros sistemas.

• Copia el ejecutable que encontrarás en la caprta build llamado sqlux donde desees ubicar tu emulador.
• Copia allí la carpeta roms.
• Copia también la carpeta examples.
• Luego copia el fichero sqlux.ini que encontrarás en la carpeta sQLux.
• Modifica el fichero sqlux.ini a tu gusto.
• Ejecuta ‘sqlux’.

Eso es todo. Ahora, prepárate a disfrutar del sillón confortable (Comfy chair).

Actualización: Hoy 27 de febrero ha sido publicada la nueva versión del emulador, la 1.0.7, llamada «The Comfy Chair» XD https://github.com/SinclairQL/sQLux/releases/tag/v1.0.7

En 2008, -hace ya unos años-, creé un programa que permite, de forma flexible, configurar menús de arranque para el QL clásico, sin entorno de ventanas.

El programa ofrece una variada gama de posibilidades de configuración para mostrar un menú desde el que seleccionar opciones que permiten lanzar aplicaciones.

El menú puede mostrar o no información relacionada con las opciones según lo configuremos, puede recorrer una lista de opciones amplia, y lanzar una o varias de las opciones si se desea.

En definitiva, el ‘MENÚ BOOT’ no es más que un BOOT de BOOTs interactivo.

Al descargar la aplicación, ya cuentas con una configuración de ejemplo que te ayuda a entender su funcionamiento.

Puedes usar las teclas del cursor, y la tecla espacio para seleccionar las distintas opciones:

• 1. Característica del programa
• 2. Ficheros del programa
• 3. Uso del menú
• 4. Configuración del menú
• 5. Cómo obtener ayuda

La estructura de esta configuración puede servir de ayuda para entender cómo ser estructura la aplicación.

El programa, que tiene el nombre BOOT, se carga mediante la facilidad del sistema de cargar ficheros BOOT al introducir el soporte y pulsar F1 o F2. Desde el BOOT se llama a MENU_BAS.

Podemos renombrar MENU_BAS para que se inicie como BOOT si lo deseamos.

Este programa establece el modo de pantalla y la ubicación de los archivos, carga la configuración desde MENU_CFG, y dibuja la pantalla. Seguidamente, lee el archivo MENU_LST del disco para conocer la información de las aplicaciones que debe mostrar en el listado, y a continuación, las muestra. La estructura del archivo MENU_LST es auto-explicativa.

A continuación, la aplicación nos da la opción de que seleccionemos las distintas entradas del menú, mientras nos va mostrando la información correspondiente a cada una de ellas, que se encuentran en cada archivo _INFO creado para cada aplicación.

P.ej. Si tenemos un juego que se llama JUEGO_EXE que queremos ejecutar, deberemos crear un archivo JUEGO_INFO para el MENU_LST que leerá MENU_BAS. El contenido de este _INFO debe adaptarse al tamaño de la ventana de información del programa. Su primera línea será mostrada resaltada.

A parte del _INFO podemos adjuntar un _TXT con información concreta si necesitamos facilitar al usuario más explicaciones para hacer funcionar la aplicación, pero este _TXT no se mostrará desde el programa.

Por último, una vez seleccionada la aplicación, sólo nos resta pulsar ‘Espacio’ para ejecutarla. El ‘MENU_BAS’ llamará al _BOOT del programa que queramos ejecutar con un LRUN. De igual forma que con el _INFO en el ejemplo anterior, deberemos crear un fichero JUEGO_BOOT que contenga las instrucciones de carga de la aplicación, por ejemplo:

Una vez lanzada la opción, el programa termina, a no ser que tengamos activado el valor ‘multi’ en el archivo MENU_CFG. En tal caso el programa permitirá lanzar tantos programas e instancias de programas como deseemos hasta pulsar ESC para salir.

Este JUEGO y el resto de programas de la lista deberá ser referenciado en el archivo MENU_LST.

Con el programa se adjunta una imagen que puede ser usada como diseño de cabecera del menú, y que ocupa 1/4 de la pantalla. Por defecto, el fichero se llama MENU_SCR y se carga en la posición de memoria 131072, la primera posición de la memoria de pantalla.

Podemos cambiar a voluntad las extensiones por defecto mediante el fichero MENU_CFG.

Un fichero BOOT lanza el fichero MENU_BAS que carga información de configuración MENU_CFG que indica cómo se mostrará el menú en pantalla, y carga la lista de programas del menú que está en MENU_LST.

Para ver información sobre cada aplicación y lanzarla, además de los ficheros de la propia aplicación (programa en SuperBASIC o ejecutable…), se necesita tener un fichero con extensión _INFO que describe el programa y lo que se mostrará en el menú, y un fichero con extensión _BOOT con las instrucciones de carga para que, una vez sea seleccionada esta opción, se ejecute el programa elegido adecuadamente.

Como sugerencia, a la hora de crear la recopilación de programas que se van a mostrar en el menú, recomiendo que primero se recopilen los programas que formarán parte del menú, y se creen o renombren los ficheros _BOOT de cada uno de ellos.

A continuación crea un fichero _INFO por cada programa con el mismo nombre que el usado en el fichero _BOOT. P. ej. JUEGO_BOOT y JUEGO_INFO. Cuando tenga configurado el menú, y sepas el tamaño que ocupará el texto informativo de cada aplicación en pantalla, podrás adaptar el contenido de los ficheros _INFO para su correcta visualización en el programa.

Ahora crea un fichero llamado MENU_LST e incluye en él los nombres, sin la extensión, de cada uno de los programas. Este nombre debe coincidir con el usado en los ficheros _INFO y _BOOT. Sigue la estructura del fichero de ejemplo del programa para que la aplicación funcione correctamente.

Ahora llega le momento de determinar cómo se verá el menú. Esto se consigue configurando el archivo MENU_CFG, cuyos parámetros están explicados en el propio archivo de ejemplo.

Por último, añade el fichero BOOT principal facilitado y el fichero MENU_BAS. Tu menú está listo.

Es importante que, en ambos ficheros configure adecuadamente la ruta que se guarda en la variable disp$. Por defecto, su valor es flp1_.

El programa cuenta con algunas limitaciones que es importante conocer a la hora de usarlo:

• Requiere que todos los ficheros se encuentren en el mismo medio y la misma ruta.
• El nombre de fichero _INFO y el nombre del fichero _BOOT han de ser el mismo, y usarlo, sin la extensión, en MENU_LST.
• La imagen de fondo tiene que tener, forzosamente, el ancho de la pantalla.

Lee el manual disponible en la aplicación con más detalles sobre su configuración.

Tienes disponible esta aplicación a través del enlace:

https://github.com/JavGuerra/Sinclair-QL-menu/

Allí puede descargar un fichero .zip al hacer click sobre el botón ‘CODE’ en verde.

MENU_BOOT se usó en la selección de aventuras conversacionales realizado con el CAAD en 2008.

Puede descargar el archivo aventuras.zip

«QL ES pack» es un paquete de iniciación al QL en castellano pensado, sobre todo, en aquellos que se acercan por primera vez al QL, bien porque han comprado un ordenador, o bien porque tienen interés en la máquina y desean usar un emulador.

El pack contiene una recopilación de recursos y utilidades básicas como:

• Material imprescindible. Con manuales y artículos de interés.
• Recursos. Como videos, y más artículos de información.
• Software. Con programas como el paquete PSION en español, y otros.
• Enlaces. Por supuesto tienes una serie de enlaces recomendados también para seguir profundizando.

Aquí la dirección de la página: https://javguerra.github.io/QL_ES_pack/

Este recurso on-line seguirá creciendo con nuevas aportaciones.

Espero que sea útil.

El amigo Miguel Ángel Rojo preguntaba en un grupo sobre aplicaciones para ver pantallas de QL en el PC, y aunque ya encontró una que le sirve me picó el gusanillo, y vi la posibilidad de crear algo así yo mismo, y aquí está el resultado.

Como sabemos, el QL original tiene dos modos de pantalla, el modo 8 de 256×256 a 8 colores, y el modo 4 de 512×256 a 4 colores.

La aplicación Sinclair QL SCR Viewer es un HTML que permite cargar en el navegador un archivo de imagen en formato QL ubicado en local o en remoto, mediante un botón INPUT, y mostrar su contenido sin que ocurran errores de CORS, y sin usar un servidor.

La imagen resultante puede descargarse en formato PNG con un tamaño de 1024×768 pixels.

La aplicación se encuentra en línea en la dirección: https://javguerra.github.io/qlscrview/

Su código fuente está disponible en la dirección: https://github.com/JavGuerra/qlscrview

La aplicación interpreta los colores y el formato en MODO 8 y en MODO 4 del QL, con los colores de cada pixel usando la paleta: negro, azul, rojo, magenta, verde, cian, amarillo y blanco para el modo 8, y negro, rojo, verde y blanco para el modo 4.

Para representar los colores de los pixeles en modo 8, el primer byte del archivo que se lee tendrá codificado en sus bits el componente verde de cada pixel, con el siguiente patrón por byte: GFGFGFGF, el segundo byte tendrá codificados en bits los componentes de color rojo y azul de cada pixel, con el siguiente patrón por byte: RBRBRBRB, siendo G verde, R rojo y B azul, y así sucesivamente hasta final del archivo. El valor F (flash) no se usa. Si un bit tiene valor 0, el valor de su componente de color es cero. Si tiene valor 1, el valor de su componente de color es 255.

Para representar los colores de los pixeles en modo 4, el patrón de cada uno de los dos bytes es GGGGGGGG y RRRRRRRR respectivamente. El valor del componente de color B (azul) se pone a 255 si los valores G y R están a 1.

Para conservar la proporción 4:3 de la imagen, la resolución de la imagen mostrada es de 1024×768, de tal forma que, por cada pixel en la imagen original en el modo 8 se pintan cuatro pixeles en horizontal y tres pixeles en vertical, y por cada pixel en modo 4 se pintan dos píxeles en horizontal y tres en vertical.

La aplicación detecta automáticamente el modo de imagen sabiendo que, si toda la imagen tiene sus bit de flash (F) a 0, con mucha seguridad se trata de una imagen en modo 8, y que si hay algún bit que se corresponde con los bits de color verde de la imagen en modo 4, entonces se trata de una imagen en este modo, y hace el cambio al modo de visualización adecuado.

Una vez cargada la imagen en la aplicación, es posible cambiar el modo de visualización a través del botón de modo.

Como dije, el archivo ‘index.html’ es autocontenido, y se puede descargar y utilizar en una computadora fuera de línea.

Para probarlo, puedes usar el archivo ‘qlcolors_scr’ que es una imagen de pantalla en modo 8 que también se facilita.

Mi agradecimiento a Dilwyn Jones por aportar ideas y propuestas para la detección automática del modo y otros formatos de pantalla.

• Ir a la aplicación
• Descripción técnica de la aplicación
• Repositorio

Resumen por: Miguel Ángel Rojo

Varios integrantes del grupo de QL estuvimos en el programa #338 de AmigaWave emitido en directo el 21 ene 2024 con motivo del 40 aniversario del QL.

Desde el año 2015 y como cada domingo por la noche, AmigaWave nos deleita a los usuarios, tanto de Amiga como de otros ordenadores, con un programa del mundo retro, con contenido de noticias, juegos, anécdotas, curiosidades, salseo, y muchas cosas más, durante casi dos horas y media de duración, por lo que se hace muy entretenido a la vez que aprendes.

El domingo 21 de enero de 2024 el programa invitó a un grupo de usuarios del Sinclair QL para charlar sobre el evento del 40 aniversario de QL que hemos llevado a cabo.

Estuvieron Web8bits, Fireboy, HTDreams, Lince y kikems, y como invitados se encontraban, Badaman, Zerover, AFX, Alvaro Alea, Napsternds, y Miguel Angel Rojo.

Web8bits hizo una pequeña introducción sobre la charla, para entrar en contexto, sobre este aniversario, comentando la alegría que sentía al ver que habría tanta gente representando al QL en España. Comentó también que esto es así pese a que mucha gente no tiene muy claro que es el QL aunque lleva el nombre Sinclair.

A la presentación de todos y cada uno de los presentes como suele ser habitual, se siguió con los inicios informáticos de los invitados del QL.

Badaman explico que soñaba con tener un Amiga, pero se cruzó el QL en su vida por ser más barato, por su elegancia, su enfoque a lo profesional, e ideal para aprender Informática, fue el primer ordenador que tubo en 1986, gracias a él, enredando y aprendiendo a programar, se que pudo desarrollar en el ámbito profesional.

Lo interesante fue que no había nadie más con QL en su entorno, estaba solo, y al tener que buscarse la vida, le hizo aprender, no había mas remedio que leerse los manuales.

Napsternds llego al QL en diciembre del 2019, en al 85 tuvo un Spectrum 48k, y en el 89 un Amiga 500. Del QL de la época recuerda las revistas de microhobby cuando investronica lanza sus ordenadores en el 85-86. Varios años después se paso al pc.

Se hizo con un QL en los anuncios de Wallapop, y como suele pasar, con un QL básico estas vendido, la primera experiencia con microdrives y conseguir hacer algo era complicado. El QL requiere mucha investigación y acaba siendo muy divertido. Napsternds cuenta que, en los últimos dos años no pasan 5 días seguidos sin que coja el QL.

Miguel Angel Rojo también fue de los que llego tarde, en 2019, gracias a las Retrocryptas de Ron. Pensaba que era un Spectrum más. Y entonces un QL nacional que se puso a tiro. Sus primeros pasos con ordenadores fueron de la mano de los Amstrad de Alan Sugar, el CPC 6128, aunque teniendo conocimientos de otros ordenadores a través de amigos y familia que poseían Spectrums, Ya más tarde vinieron los PCs. Por los insufribles microdrives, Miguel Angel ya tenia pedida una tarjeta del vendedor Tetroid con memoria, acceso a C.F y disquetera (la TDI).

Zerover comenzó su andadura con el QL en el año 1986, pensando que era un Super Spectrum. Fue un ordenador que le gustó mucho al descubrir lo que en realidad era. Siempre lo ha tenido en la mesa. Pasó después a los PCs y fue actualizándolos, hasta que finalmente termino en el mundo Mac, que es su ordenador habitual.

Álvaro explico que su primer ordenador fue un Spectrum de Amstrad, estirándolo hasta llegar a los 386 y 486, y con el tiempo fue haciéndose con todos los modelos de Sinclair. Uno de los que siempre leia en las revistas era el QL, que aparecía como una maquina mucho más avanzada.Hace poco años ¿2019? encontró uno completo y en caja por Wallapop, pero destrozado. Consiguió ponerlo al día para usarlo: membrana, no tenia microdrives… se divirtió mucho con el cacharreo.

El primer ordenador de AFX fue un QL de la primera generación de usuarios, sobre el año 1985. Se hizo con uno teniendo claro que, como estudiante, seria para tal cuestión, ya que no lo quería para juegos. Buscaba un ordenador con 80 columnas, con algún medio de almacenamiento que no fuesen las cintas de casete, y por descarte aterrizó en el QL, pero aún no sabía que era una gran máquina con SuperBASIC, más memoria… atrayéndole también el paquete de ofimática PSION. Pero, a los dos años, un poco cansado de los microdrives y del teclado, lo dejó aparcado. Redescubrió el QL hacia el 2004 gracias a Internet, pero ya como hobby. Como anécdota, contó que su hermano se quedó el QL original y se lo robaron. De aquél nunca más se supo.

Después de conocer un poco la vida informática de cada uno de los participantes, se dio paso a una mesa redonda sobre este ordenador.

Fireboy comenzó con un apunte sobre una característica que llama la atención cuando compramos un QL, y es la de que no tenga la tecla de borrar. Badaman explica que sí se puede borrar pulsando CTRL mas la flecha izquierda.Esta particularidad del QL es algo que es un misterio, y sólo Clive y sus ingenieros sabrán el por que se hizo así. De todas formas, en los Spectrum de la era Sinclair, para borrar también se usa una combinación de teclas, Caps shift + 0 que al menos ya lleva escrita la palabra Delete.

Algo interesante fue que la gente erróneamente cree que el teclado del QL proviene del diseño del Spectrum +48k, pero, en realidad fue al revés, el +48k heredó el teclado del QL.

En el mundo del QL es importante leerse el manual, pues es muy versátil. Puedes descubrir que puede borrar como ninguna otra máquina usando combinaciones de letras, pero los usuarios miramos la tecla de encima del Enter con recelo por no encontrase una tecla de borrar allí.

A la pregunta de Web8bits sobre como nació el QL, Napsternds resume que Sinclair, tras el éxito a todos los niveles del Spectrum en 1982, pensó en el sucesor y quiso hacerse un hueco en el mercado profesional, con el QL que presentó en enero de 1984. A pesar de las discusiones internas, no utilizó el Z80 como se esperaba, sino que optó por un 68008.

Hay que anotar que el proyecto inicial del QL era la creación de una máquina portátil, y por ello fue dando bandazos, con un diseño caótico, hasta llegar a lo que es hoy en día. Como producto ni fue un ordenador domestico ni lo suficiente robusto y solido para profesionales.

Sinclair quería presentarlo antes que los Macintosh (que se presentó dos semanas después) pero en el momento de la presentación era un ordenador incompleto y vació, con la promesa de entregarlo en 90 días, pero se retrasó hasta abril y se distribuyó con muchos fallos, por lo que la prensa se les hechó encima y precipitó que el QL, finalmente, no llegase a ningún sitio.

Badaman relata el porque el interés por una máquina profesional. Clive se había quedado tocado por el concurso de un ordenador para Alfabetización Informática de la BBC que ganó la computadora BBC micro de Acorm Computers frente a otros competidores como Sinclair, Oric, Dragon…

Sinclair decidió que podía hacer un ordenador mejor que el BBC para escuelas, universidades y el mercado de pequeñas y medianas empresas. Era un proyecto muy ambicioso. Era una maquina que podría haber sido gloriosa y estar a la altura de los IBM PC, e incluso de los Macintosh, pues, un año después, ya poseía interface gráfica. Aunque con su salida, se llegaron a vender un número razonable de QLs, que podrían haber sido más si no llega a ser por los problemas económicos de Sinclair que le obligaron a vender la empresa, y que el mercado de los 16 bits estaba a las puertas, lo que no jugó a su favor.

En el año 85 se presentó el QL localizado en español en Informat85. Después vendría la versión en alemán, francés, italiano… pero Alan Sugar decidió discontinuar el QL al comprar Sinclair a Clive. El debate sobre esta decisión se hizo amplia, pero cabe destacar que Tony Tebby quiso hacerse con los derechos del QL sin llegar a conseguirlo. Se especula con que el QL le hacia la competencia a los modelos PCW de Amstrad.

Por aquel entonces, el QL ya no era una maquina viable y Sinclair preparaba ya el QL2, si no se hubiera vendido Sinclair a Amstrad tal vez habríamos visto en el mercado esa evolución.

Recapitulando, podemos decir que el QL nació en el 84, con prisas, con bugs en la ROM, con los microdrives que eran un desastre, el teclado que no era todo lo profesional que se esperaba… En definitiva, se hicieron varias chapuzas que no convencieron al publico. Lo que nace mal acaba mal.

Pero el QL también tuvo cosas positivas. Contaba con un potente interprete BASIC, y se adelantó a su tiempo, pues se entregaban con un buen paquete de software. También fue el primer ordenador personal multitarea, algo que fue explotado tarde, sólo cuando, salieron ampliaciones hardware para aprovecharla. Con más memoria y una controladora de discos, la cosa podria haber cambia radicalmete.

Sinclair fue número uno de ventas de Informática doméstica con sus ZX81 en el año 81, con una facturacion de 22 millones de libras, y con la gama Spectrum (ZX82) en el 82 subió a 53 millones de Libras. Una empresa con semejante crecimiento en tan poco tiempo, cuando se estaba diseñando el QL, tubo que ser un caos absoluto y de enorme calibre. Era un empresa sin rumbo acompañada de malas ideas en la parte técnica, con un sistema operativo listo pero sin hardware sobre el que correr, mientras Clive se entretenía con su coche eléctrico y su obsesión por ahorrar.

El QL, en aquella época, ya salio con la opción de ser muy ampliable, y su sistema operativo QDOS tenia la ventaja que permitía pichar una tarjeta en el bus de ampliación y a funcionar, sin necesidad de cargar controladores. Nació con esa idea. Siguiendo las directrices establecidas, se podían añadir sin problemas, varias tarjetas seguidas, aunque los fabricantes de terceros hicieron lo que quisieron y había problemas para combinarlas. En el evento se vieron varios ejemplos del llamado “trenecito” que se forma al concatenar varias tarjetas seguidas.

Badaman comenta cómo surgió la idea de hacer una reunión presencial de usuarios. Esta salió de la video conferencia anual que se hace en abril, concretamente el 16 por ser la fecha de salida del QL Español. Al tener Badaman contacto con el Museo de Historia de la Computación, se pudo celebrar allí el evento en una fecha celebre, la del 40 aniversario.

El evento fue todo un éxito, y una experiencia inolvidable para un sistema que, al final, no deja de ser minoritario, y en el que llegaron a juntarse en torno a 40 personas en un evento solo de QL.

Cuando se hizo eco del evento en otras comunidades de QL, se ha despertado el interés tanto en las comunidades de Alemania e Inglaterra de tener su evento QL despues del nuestro. Y eso son buenas noticias para la escena de este ordenador.

Este evento dio la oportunidad de ver el sistema en otras plataformas, ATARI, AMIGA… incluso en FPGA como la Poseidón que mostró Ron.

Hubo una amplia cantidad de aparatos de muestra: Cambridge Z88, Trump Card, Gold Card, Super Gold Card, Qsound, Tetroid disk interface, Qubide, Qimsi, Aurora, QXL, Qlub, varios ratones, disqueteras, un monitor Vision QL, conversores QL-VGA, Q68, incluso programadores EPROM, junto con los 15 QL’s que seguramente batieron récord de mayor numero de unidades por metro cuadrado que nunca se habían visto en España.

Pudimos ver de la mano de Zerover la impresionante Aurora. Para el que no sepa que es, se trata de una placa alternativa a la placa base del QL, sin microdrives, sin CPU y sin RAM, ya que esta pensada para usarse con ampliaciones. Se pudo ver una Qubide con discos duros, la Gold Card con un adaptador para cuatro disqueteras. Varios QL con puerto series conectados, Qls conectados a monitores de PC con el conversor a VGA, y e internamente algunos con el chip HERMES.

Un QL puede llevar el Super HERMES para conectar un teclado de PC, aunque podía funcionar también con un teclado de QL. Los usuarios de entonces ya usaban cajas de PC, particularmente porque el disipador recalentaba el ordenador y porque no existían en esa época recambios de membranas cuando se rompían.

A día de hoy, no cuesta mucho encontrar recambio para nuestros QL, salvo las ULAS que ahora ya se pueden implementar en FPGA.

Álvaro nos enseño su habilidad a la hora de hacer clones. Mostró tres interfaces de discos diferentes, varias ampliaciones de memoria, dos de ellas en tarjeta, un cartucho y una para poner dentro del QL, encima del procesador, y también la Qsound, una especie de tarjeta de sonido para el QL.

Napsterds cuenta sobre la red local del QL y su facilidad de compartir archivos e impresoras con un solo comando. También vimos fotos de la placa base del QL completamente nueva de Tetroid en la que Titoxunix ha ido ensamblando todos sus integrados. También vimos la tarjeta isa QXL compatible QL para ranuras ISA de PC.

Ron trajo una sorpresa, con la presentación de la implementación del QL en la FPGA Poseidon. Es un gran amante del QL que se encontraba como pez en el agua hablando de ello.

Badaman hizo un ultimo repaso a lo acontecido con todo el cacharreo que se vio allí, presentado a los asistentes lo que se trajo. También se vieron imágenes de la comida de hermandad que se realizó en un bar cercano. También habló de otras actividades que se llevaron a cabo en el programa del evento, como la entrevista a Salvador Merino, la mesa sobre Hardware de QL, Ron con la Poseidon y AFX presentando su programa QL para conectar con la IA ChatGPT.

Para terminar, Kikems y los demás conductores del programa dan paso a las despedidas de los invitados para seguir con las noticas de Web8bits que siguió hablando de QL con la presentyación de una demo reciente para Sinclair QL, comentando sus carecteristicas.

¡Hola!!!!
siguiendo con el tema Sinclair QL con el que os estamos machacando desde hace unos meses, hoy traigo ‘la novedad’ de 2019 respecto a software: QLCommander.

QLCommander es un administrador de archivos de dos paneles basado en la idea del famoso Comandante Norton de los 80 y que facilita mucho la búsqueda manual de archivos, copiarlos o eliminarlos.

Andrei Tenu, Andrew en QLForum.co.uk, es un desarrollador rumano que volvió a la escena QL hace unos poquitos años, 29 años después de verder su propio QL, y además de QLCommander a programado la serie de Aventuras P.I. Cole. Para conocerlo un poco nada mejor que leer su presentación en QL Forum de mediados de 2018: (https://qlforum.co.uk/viewtopic.php?p=24305#p24305)

Hi All ! Glad to have found you !
I am Andrew – I had a Sinclair QL back in the 80’s and I loved it.
There were only 3 Sinclair QL’s in Romania at that time and we did not had much software for it – in fact I only had the Psion set, Psion Chess, a couple of games, the TK2 toolkit and the Computer One Pascal compiler.
So I started to develop my own programs for it, in SuperBasic and Pascal – and used the computer till 1990, mainly to write software for university projects. In 1990 I moved on to PCs – and regretted the QL since
Now I started to use Q-emulator and also bought a Sinclair Ql (i am waiting for it – hope it is in good working order)
I am just discovering the range of software that is available for the QL and I rely on you guys for tips and support !
Thank you.

Hola a todos ! Encantado de haberos encontrado !
Soy Andrew. Tuve un Sinclair QL allá por los años 80 y me encantó.
En ese momento solo había 3 Sinclair QL en Rumanía y no teníamos mucho software para el; de hecho, solo tenía el conjunto Psion, Psion Chess, un par de juegos, el kit de herramientas TK2 y el compilador Computer One Pascal.
Entonces comencé a desarrollar mis propios programas, en SuperBasic y Pascal, y usé la computadora hasta 1990, principalmente para escribir software para proyectos universitarios. En 1990 pasé al PC y desde entonces me arrepiento.
Ahora comencé a usar Q-emulator y también compré un Sinclair Ql (lo estoy esperando, espero que esté en buen estado de funcionamiento)
¡Hace poco que estoy descubriendo la gama de software disponible para QL y confío en ustedes para recibir consejos y soporte!
Gracias.

Pues bien, en el este enlace podéis descargar el código fuente del programa, el compilado y el manual en formato pdf.

https://qlforum.co.uk/viewtopic.php?p=27712#p27712

Y no está de más que os divirtáis leyendo todo el post (de varias páginas) donde se puede ver las pruebas y mejoras que el software va recibiendo hasta que llega a esta versión 2.0: https://qlforum.co.uk/viewtopic.php?t=2669

Tal y como indica el manual QLCommander necesita ciertas librerías, toolkits y sistema/gestor de ventanas para funcionar:

• qlc_code (contains More_code, Header_code and Function_code, all from DIY Toolkit). El programa ‘mísmamente’.
• Toolkit 2 (On Qemulator use v2.32 – on QL at least v2.88, but v2.32 is recommended). En Minerva suelo cargar la 2.36 que a aparecido hace poco pero en ROMS anteriores suelo utilizar la 2.23 cargada como si fuera un cartucho ROM al utilizar un multiROM de Tetroid o un adaptador de EPROMs de los habituales.
• PE environment (hot_rext, ptr_gen, wman – only on QDOS, not needed on SMSQ/E). En mi caso es para QDOS así que hay que descargar los siguientes archivos de la página del Pointer Environment de Dilwyn Jones:
  1.- Pointer Interface: https://dilwyn.qlforum.co.uk/pe/ptrgen206.zip
  2.- WMAN: https://dilwyn.qlforum.co.uk/pe/wman208.zip
  3.- HOT_REXT: https://dilwyn.qlforum.co.uk/pe/hotrext231_e.zip
• QPTR Toolkit.Versión 0.15 de las herramientas para programación en Pointer Environment de Tony Tebby de la página de soft de programación https://dilwyn.qlforum.co.uk/program/ de Dilwyn Jones: https://dilwyn.qlforum.co.uk/program/qptr.zip
• Turbo Toolkit: De la página del compilador de SuperBasic Turbo https://dilwyn.qlforum.co.uk/turbo/index.html: https://dilwyn.qlforum.co.uk/turbo/trbot14.zip

En estos momentos ya tenemos todo lo necesario para hacerlo funcionar. Si utilizáis dispositivos QL-SD o QIMSI los archivos zip se pueden pasar rápidamente a vuestro .WIN mediante un emulador pero en mi caso tengo una QubIDE con lo que se hace necesario utilizar el software de HABI para transferir los archivos.

Ahora toca pasar los archivos zip al QL para después descomprimirlos. Aquí ya supongo que el Toolkit II y el tema del unzip lo tenéis solucionado.

Primero hay que conectar el medio de almacenamiento al Pecé, si tenéis SD o Compact Flash es muy fácil (es lo que utilizo para pruebas para ir más rápido) pero si el medio definitivo es una DOM la cosa se complica: yo compré hace tiempo adaptadores con dos conectores macho y un cable de IDE a USB:

Se puede arrancar la aplicación de HABI sin preocuparse por el sistema operativo, me funciona perfectamente en Windows 11 64 bits. Para poder acceder al disco hay que arrancarlo en modo Administrador:

Tras ello ‘abrimos’ la unidad correspondiente al QubIDE accediendo al menú ‘Disco’ y pinchando -obviamente- ‘Abrir Disco’:

Nos debe aparecer la lista de discos accesibles del sistema y escojeremos el adecuado y pincharemos sobre ‘OK’.

En pocos momentos aparecerá la lista de particiones y de que tipo son. Como véis la tarjeta tiene tres particiones: la primera la de uso y arranque, la segunda partición para datos y la tercera es mi temporal para pasar archivos o descomprimir pruebas. Normalmente solo se monta la partición de arranque y para las otras dos tengo una programilla BASIC para montarlas si las necesito. Aquí sólo hay que pulsar ‘Aceptar’ para poder continuar.

La utilidad vuelve a la pantalla principal donde se muestran las particiones y sus archivos. Si lo deseamos podemos borrar cosas o crear carpetas.

Pero lo que buscamos es transferir los archivos zip a la tarjeta/DOM para la QubIDE. Como sabéis los diversos sistemas de archivos del QL guardan las cabeceras de cada archivo aunque en realidad sólo son importantes para los ejecutables ya que estas cabeceras indican cuanta memoria se reserva la aplicación para su funcionamiento. Como nuestros archivos zip no tienen cabecera ni la necesitan se desactiva la opción ‘Extraer’ que está en el menú ‘Opciones’. También suelo dejar la Opción ‘QL’ para no olvidarme:

Ahora vamos a tranferir los archivos. En mi caso siempre los paso a la partición número 3 así que la selecciono en el arbol de carpetas de la izquierda. Solo seleccionarla con el botón izquierdo del ratón:

Ahora en el menú ‘Archivo’ pinchamos en ‘Insertar Ficheros’. Aparecerá la ventana de diálogo donde se pueden escojer los archivos a transferir y ya solo nos queda pinchar el botón ‘Si’ para confirmar la transferencia:

En unos segundos el programa volverá a responder y podremos ver nuestros archivos en la lista:

Es hora de descomprimir. Para usar el Unzip 5.41 hay dos métodos si bien el paso de parámetros utilizando el Toolkit II me parece lo más fácil así que vamos a ello. Partiendo de que tenemos todas las particiones montadas y nuestros archivos zip están en la raíz de la tercera partición (WIN3_) y que Unzip está en la carpeta tools_ del la partición 1 (WIN1_) empezaremos por descomprimir el Pointer Environment. Es posibe que muchos de vosotros ya tengáis alguna distribución con el PE descomprimido y configurado pero en mi caso, para ahorrar memoria -máximo tengo 640KB-, lo ejecuto cuando el programa que arranco lo necesita.

Toca descomprimir los 3 archivos del Pointer Environment, los archivos quedarán guardados en la carpeta sys_ de la primera partición:

Con EXEC_W ejecuto el programa de manera que no vuelva al prompt hasta que finalice su ejecución cono lo que hay que pulsar una tecla para salir de Unzip. Se puede ver el método de pasar parámetros a Unzip mediante Toolkit II: entre comillas después de un punto y coma. La opción ‘-d’ sirve para indicar dónde queremos descomprimir el archivo (y se puede ver que no es necesario poner un espacio después de la opción, aunque se puede) y después se pasa la ruta completa al archivo. Entre los dos parámetros sí que hay un espacio.

Después el QPTR Toolkit. También lo dejamos en win1_sys_:

Ahora en lugar de EXEC_W utilizo la abreviatura EW, que es lo mismo.

Para el Turbo cambio de carpeta y lo dejo en win1_tools_Turbo:

Por útimo nos queda descomprimir el QLCommander, que ya es hora:

Lo de dejarlo en la carpeta win1_QLCommander es para facilitar el tema ya que aunque se puede cambiar es la carpeta de trabajo por defecto.

En realidad no es necesario si dejamos las opciones por defecto pero no está de más ver sus opciones. Para configurarlo hay que ejecutar un pequeño programilla BASIC (tarda un poco en arrancar así que calma):

Como véis permite modificar varias opciones y a veces da error, no se por qué, y otras no al modificar opciones. También, una vez dentro del programa de configuración, se puede pulsar F3 para cargar la configuración, F1 después para guardarla y Q para salir.

Si se deja la carpeta temporal por defecto debemos crearla manualmente desde el prompt del QDOS:

<<ACTUALIZACIÓN>>
Ya he encontrado el problema del error, necesita tener cargado el Turbo Toolkit para ejecutarse. Esto nos da dos posibilidades de utilizar el programa de configuración:
1. Ejecutarlo desde dentro del propio QLCommander. Si habéis mirado el manual o hecho alguna prueba sabréis que el QLCommander carga los ficheros BAS automáticamente al pulsar con Intro sobre ellos y esto permite hacer un RUN cuando tenemos el programa SuperBASIC a la vista.

2. Podemos crear un pequeño cargador en SuperBasic que cargue el Toolkit antes de ejecutar el programa de configuración:

Este archivo BOOT lo guardo con

de manera que lo puedo ejecutar con

<<FIN ACTUALIZACIÓN>>

Pues depende. Si vuestro sistema carga los requisitos previos por defecto solo hay que ejecutar la aplicación:

En mi caso, como tengo que cargar los requisitos creo un nuevo ‘programa’ en SuperBasic que me haga el trabajo, asi que se teclea NEW (más la tecla Intro) y ¡venga!

esto lo guardo con

de manera que el programa se inicia con:

En realidad el QL no es sensible a mayúsculas y minúsculas para encontar los archivos pero si los guarda con esa diferenciación y queda más bonito.

Creo que no me dejo nada. Tampoco soy un súperexperto en estos temas así que si hay alguien que desea añadir algo más, ya sabe… que comente

Badaman hace una introducción al ordenador Sinclair QL que es retransmitida en directo en la Retrocripta de Ron el sábado 27 de enero de 2024.

Se programó una jornada para cercar a los potenciales usuarios de QL al conocimiento de este ordenador que fue realizada por Badaman, quien fue explicando y compartió pantalla para mostrar las características bñasicas del QL durante aproximadamente dos horas.

A continuación se muestran los videos que fueron emitidos en directo con la ayuda de Ron a través de su canal de Twitch, la Retrocripta.

Resumen por: Miguel Ángel Rojo

Demostración en el evento QLis40 realizado en el Museo de Historia de la Computación de Majadas de Tiétar, Cáceres, el 13 de enero de 2024.

Afx muestra las características avanzadas de sistema operativo SMSQ/E y las posibilidades de conectividad en red de un QL, una Q68 y un PC usando el dispositivo QLUB.Video de la demo realizado por Zerover.

De la mano de AFX, os enseñamos el entorno más avanzado, la «maquina de fantasía», -como dice Ron-, un QL basado en SMSQ/E, que puede reproducir videoclips en una maquina emulada. Ni siquiera en una FPGA esto es posible, y tampoco en una máquina real con Super Gold Card se podría hacer esto.

Lo que nos mostró en el evento fue cómo conectar dos máquinas QL en red local con el dispositivo QLUB. Haciendo que el PC actúe como servidor, podemos conectar hasta 63 máquinas en una misma red, en la que se pueden compartir impresoras, e incluso Spectrum con que cuenten con Interface 1 y microdrives.

Se puede ver en el video cómo, introduciendo unos comandos (dir n3_dos1 y dir n3_win1) podemos mostrar tanto el directorio del disco local del PC compartido como el contenido del win1_ del QPC (emulador) que previamente fue configurado como la estación 3 (n3).

Mediante esta capacidad en red, que ya estaba presente en el sistema desde sus inicios, AFX hace uso de un programa para conectarse a Internet y consultar con ChatGPT desde un QL.

Con un sistrema básico de 128Kb de memoria, y tal vez ayudado por el Tooklkit II, pero sin necesidad de un dispositivo de almacenamiento propio, usando los recursos de la red, un QL puede ser operativo gracias al QLUB, un aparato que consta de una placa Teensy++2.0 que se conecta a una pequeña placa adaptadora la cual alberga los conectores jack para la conexión de cableado QLNET y un cable USB para conectarse a un PC, y poder ser usado así por un emulador.

Los asistentes comentaron lo interesante que sería desarrollar un programa que no usase el emulador para acceder la red y conectar otros ordenadores QL.

El cableado de la red QL es extremadamente simple. Un cable de dos hilos con conectores de audio mono de 3,5 mm en ambos extremos. Eso es todo. Un cable de altavoces nos vale. El protocolo de red de QL es un poco más complicado que eso.

Como nos contó Afx, aunque no es imprescindible, puedes utilizar el Toolkit II para aprovechar al máximo la red del QL y hacer su uso más simple.

Resumen por: Miguel Ángel Rojo

Mesa redonda en el evento QLis40 realizado en el Museo de Historia de la Computación de Majadas de Tiétar, Cáceres, el 13 de enero de 2024.

Badaman charla con TitoxUnix, José Leandro, Ron y Álvaro Alea sobre las particularidades del Hardware del QL.

En el evento no podía faltar, dentro de las actividades de esta jornada, la mesa redonda sobre hardware del QL, con la presencia de Jose Leandro, Ron Méndez, Álvaro Alea y TitoxUnix. Queríamos saber más sobre sus experiencias con el hardware del QL ya que casi todos ellos se dedican a la creación de expansiones ya sea por afición o por necesidad, tanto para ellos como para la comunidad.

Badaman moderó la mesa y dirigió la actividad para que la charla fuese agradable y amena mientras los contertulios exponían sus experiencias.

En una época en la que había ya muy pocos usuarios con las ampliaciones necesarias para disfrutar de un QL en condiciones, y con periféricos cada vez más escasos, en un mercado que estaba desapareciendo, Jose Leandro revolucionó la escena con un nuevo dispositivo que aunaba ampliación de memoria y medio de almacenamiento, «la Qubide de José Leandro». Sin él, muchos usuarios no podrían disfrutar de este fantástico microordenador.

Esta Qubide contaba con 512Kb de ampliación de RAM y puerto IDE y alcanzó gran éxito entre los usuarios nacionales e incluso internacionales, y fue inspiración para toda una nueva hornada de dispositivos para QL a partir de su trabajo.

La Qubide no venía sola. Contaba también del programa de Habi, una aplicación que trabaja con imágenes de disco en el PC para intercambiar software con el QL.

Su primera andadura con el QL llegó por sorpresa, En un mercadillo José Leandro le dijo a su novia que, si encontraba un QL en su embalaje original, estarían juntos para toda la vida, Y se obró la magia. Apareció un QL en caja, con los cuatro microdrives de PSION. Pero al encontrarse con una maquina de la que no se podía sacar partido por sus limitaciones, decidió buscar por medios habituales las diferentes ampliaciones que existían con escaso éxito. El hardware volaba, y de un proyecto inacabado de los chicos de omega recupero un esquema del Qubide, y se puso manos a la obra.

José Leandro heredó de Santiago (STGO) -que en paz descanse- mucho material de Investrónica, empresa para la que trabajó, y entonces se dedicó también a reparar QL con ese stock. Restauró varios ordenadores que vendió a un precio simbólico a la comunidad.

Por desgracia, el hecho de que todo fuese tan cerrado el el mundillo del QL, hizo que perdiera interés dejándolo algo de lado.

El siguiente en la rueda fue Álvaro Alea, que llego al QL en 2020 , conociéndolo antes por la emulación y poco más, ya que no pudo hacerse con uno en la epoca.

¿Que hacer cuando te llega un QL solamente con microdrives? La historia se repite. Imposible usarlos. Así que lo primero fue conseguir un emulador de microdrive, un hardware para cargar imágenes de microdrive con una sd, el v-drive, el problema es que en el mundo del QL eso no basta. Por fortuna, Albaro posee conocimientos de electrónica es capaz de clonar su propio hardware a partir de esquemas disponibles en Internet: interfaces de disco, ampliaciones de memoria, controladoras de disquetes…

Álvaro trabaja en replicar el dongle de QL y en una tarjeta de ampliación que sea todo en uno: Gold Card, controladora y memoria, a un precio asequible. ¡Seria todo un bombazo! Esto evitaría tener que poner una placa de ampliación detrás de otra (el famoso trenecito).

Nos cuenta Álvaro que el QL posee, en su concepción, algo que vino más tarde al mundo del PC, el plug and play, enchufar y usar, ya que su sistema operativo es capaz de detectar automáticamente las ampliaciones y de conectarlas al sistema.

TitoxUnix conoció los QL unos 15 años atrás, y seguía las publicaciones en Speccy.org, Adquirir hardware era complicado, y el SuperBASIC sin microdrives u otro medio de almacenamiento no es útil. Se dedicaba, como de niño con el Spectrum, a hacer programillas, listarlos, hacer RUN y poco más, así que finalmente se registró en Retrowiki en octubre de 2016, y ahí fue cuando se dedicó también a la clonación de hardware para QL.

Entre sus proyectos está la clonación de la Qubide, una ampliación de RAM, y últimamente se entretiene soldando integrados en una nueva placa de QL. ¡Todo un impresionante reto! Por suerte todavía se pueden encontrar la mayor parte de estos integrados, o incluso, si llegase, el caso implementarlos en FPGA. TitoXunix tiene algunas interesantes ideas en mente que esperemos que pueda llevar a cabo.

Ron, todo una eminencia en el mundo retroinformático, betatester tanto de máquinas reales como FPGAs, nos dio su opinión sobre el mundo del QL. Fue, desde siempre, poseedor de esta maquina, y asegura que, «si no existiese, habría que inventarla». Contó que, en sus inicios, el 68008 era lo lógico tras el Z80, pues era un salto cuantitativo.

Ron afirmó que el QL real es irremplazable, que las FPGAs son el siguiente nivel, y que han llegado para quedarse, Nuestro QL tiene un fantástico core para la Mister de la mano de Marcel Kilgus, que además es portable a otras FPGAs. Gracias al grupo RetroWiki FPGA-dev team, se están dedicado a ello.

Badaman comentó que el QL tiene la posibilidad de encadenar en red, sin ninguna complicación, mediante dos conectores, hasta 63 máquinas, con un cableado extremadamente simple. Un cable de audio mono de 3,5 mm en ambos extremos es todo lo que necesitas para unir dos QL. Lo que viene a ser un cable de altavoces de toda la vida. AFX posteriormente haría una demostración de ello.

AFX, un gran entusiasta del QL, lanzó la siguiente pregunta a los participantes de la mesa: «Ante una supuesta desaparición de todos los QL reales, ¿qué propuesta de hardware de reemplazo ofrecerían sin usar una FPGA?, Todos coincidieron que una placa nueva con sus integrados seria la mejor opción.

El QL vuelve a la vida gracias al trabajo de gente como los ponentes que nos deleitan con sus expertos conocimiento y muchos otros que apotan su grano de arena. Salvador, Badaman, AFX, Zerover, Mcleod, Radastan, Jose leandro, Ron, TitoxUnix, Napsternds, Álvaro, y muchos más.

Esperamos con ansia esa aplicación que prepara y de la que nos habló Zerover que nos permita transferir archivos entre todos los medios de almacenamiento del QL de forma sencilla. Tenemos muy verde esa parte, sobre todo en emuladores.