¡Hola a todos!, hay problemas con la web que espero poder arreglar lo antes posible, ¡mil perdones!

QBlog

QBlog
Visitar página web/blogCastellanoEspaña346 entradas

QBlog es una página web/blog de España en castellano que ha publicado 346 entradas, siendo la última del día 07/02/2025.

Referencias a Retroinvaders aquí

El blog sobre Sinclair QL en castellano

Ver índice de webs/blogs

Sinclair QL desconocido – QSound-QPrint (parte 2) [QBlog] [Leer]


Viene del post anterior

En esta segunda parte del artículo sobre la QSound veremos a nivel muy básico las capacidades sonoras que adquiere un QL al conectar la interfaz.

Tenemos una serie de comandos de BASIC para la generación de sonidos, la posibilidad de gestionar el PSG accediendo a sus registros desde código máquina, y finalmente unos ejemplos de programas BASIC, juegos y demos que sacan partido del chip PSG a diferentes niveles.

Comandos BASIC

La interfaz QSound-QPrint proporciona al QL la posibilidad de generar sonido a través de chip PSG y además dota al QL de un interfaz paralelo para impresora. En esta prueba no utilizaremos la interfaz de impresora, y revisaremos únicamente los comandos de BASIC adicionales que permiten manejar el chip PSG.

Por un lado, proporciona 3 comandos que generan sonidos específicos:

  • BELL
  • EXPLODE
  • SHOOT

Por otra parte, estos comandos y funciones permiten manejar el chip PSG directamente:

  • HOLD <n>
  • POKE_AY r, v
  • v = PEEK_AY (r)
  • LIST_AY r0,….,r13
  • PLAY n, sound$
  • RELEASE <n>
  • SOUND <n,f,v>

Para evitar conflictos con el Sample Sound System desarrollado por Marcel Kilgus para el Q40/Q60 y su emulador QPC2, en la ROM (1.40), el comando SOUND ha sido sustituido por el comando SOUND_AY.

ABC Elektronic suministraba con la tarjeta un diskette con algunos programas BASIC de demostración. En el siguiente video podemos ver (y escuchar) uno de ellos:

AYPlay (programando el PSG en código máquina)

El manual de la QSound-QPrint proporcionado por ABC Elektronic incluia información sobre cómo programar la generación de sonido desde código máquina, aunque no proporconaba ningún ejemplo. Durante el proceso de desarrollo del clon de Alvaro Alea, Marcel Kilgus realizó algunas modificaciones (ROM 1.40) en el código de la ROM original para corregir algunos fallos y desarrolló un programa (AYPLAYER) que permite la reproducción de archivos de audio creados mediante diferentes trackers para el chip AY (vtx, ym y pt3).

Juegos

El mismo Jochen Merz desarrolló y publicó algunos juegos que utilizaban las capacidades sonoras de la QSound. Como casi todo lo relacionado con el QL, la difusión de los mismos fue escasa. Yo sólo he podido conseguir esta versión del Arcanoid, de 1988. El propio Jochen Merz me ha autorizado para su publicación, aunque casi no recordaba el juego y no dispone de más material relacionado con esta interfaz.

Demos

En los últimos años, un grupo de coders con experiencia en ensamblador del 68000 han desarrollado varias demos para QL. En 2024 añadieron el sonido AY de la QSound a sus producciones. La última demo, ganadora de la categoría “Other platforms” en la GERP Party 2025 es una buena muestra de cómo llevar al QL original (BBQL) con un 68008 y 128k de RAM muy cerca de sus límites.

Para quien no disponga de una QSound, el emulador QPC2 emula la generación de sonido de la QSound, los comandos BASIC y el AYPlayer funcionan muy bien en este emulador, no así los juegos y demos, por temas de velocidad y compatibilidad con el SMSQ/E de software desarrollado para QDOS. Está previsto que el emulador QemuLator incluya la emulación de la QSound en la versión 4 para Windows, que todavía se encuentra en desarrollo.

Un QL con una QSound-QPrint cambia completamente. Y aunque no existe una gran cantidad de software que aproveche las capacidades sonoras, el AYPlayer de Marcel Kilgus permite acceder a la inmensa biblioteca de archivos de música AY disponible en internet, en páginas como zxart.ee o untergrund.net. Las demos para QL está disponibles en pouet.net.

QL Forever!

Sinclair QL desconocido: QSound-QPrint (parte 1) [QBlog] [Leer]


ABC Elektronic fue una de las compañías que se dedicaron a desarrollar y comercializar hardware y software para el Sinclair QL desde su lanzamiento, y que contribuyeron a mantener viva la plataforma tras la cancelación de la línea QL por Amstrad en abril de 1986.

Establecida por Andreas Budde en Bielefeld (RFA, o Alemania Occidental), entre otras contribuciones significativas a la historia del QL, fue la compañía que publicó los primeros trabajos comerciales de Jochen Merz (prolífico desarrollador y trader de Software y Hardware para QL, muy conocido por ser el alma mater de QL Today).

Sus productos más destacados incluyeron:

  • Software:
    • Giga-Basic: Extensión del SuperBASIC con más de 70 comandos
    • E.A.S.E: Front-End gráfico con iconos, menús y control por Mouse
    • Gigachrome: Software de diseño gráfico
    • Juegos como QBall, Pengi o Fight in the Dark (siendo estos dos últimos de los primeros trabajos publicados por Jochen Merz)
  • Hardware:
    • Gigasoft Mouse: uno de los primeros ratones para QL. Funcionaba con E.A.S.E, Giga-basic y Gigachrome
    • Giga-RAM: Extensión de RAM de hasta 3Mb
    • Gigasoft IBM-keyboard Interface: permitía conectar teclados PC/XT a través del puerto ROM
    • Gigasoft MegaRAM: Fue la primera expansión de memoria que permitía exceder el límite teórico de los 640K. Permitía expandir la RAM hasta un máximo de 3 MB
    • ABC Hard Disk interface: Interface para disco duro que permitía manejar hasta 2 discos
    • QSound-Qprint: Interface de sonido basado en el chip AY y puerto paralelo Centronics

Como ya es sabido, Sinclair lanzó el QL a principios de 1984 orientado al mercado profesional, aunque una serie de controvertidas decisiones en la fase de diseño (microdrives, teclado de membrana, ROM sin finalizar en el momento del lanzamiento) lastraron su vida comercial desde el principio. Como no estaba pensado para juegos u otras aplicaciones más lúdicas, los modos gráficos eran bastante limitados (256×256 en 8 colores o 512×256 en 4 colores) y el sonido se limitaba a un buzzer de peor calidad incluso que el del ZX Spectrum 48k. Tampoco disponía de puerto paralelo, por lo que solo podían conectarse directamente impresoras con conexión serie, más lentas y de escasa disponibilidad en el mercado.

Para dotar a sus equipos de capacidades sonoras, los fabricantes de microordenadores recurrieron a diversas soluciones, desde la creación de chips de propósito específico (POKEY en los Atari 400 y 800, Paula en el Amiga, por ejemplo) hasta la integración en sus diseños de chips PSG  (Programmable Sound Generator) de otros fabricantes. Varios micros de 8 bits de esa época contaban con un chip PSG que fue muy popular, el AY-3-891x de General Instruments, que también fue producido bajo licencia por Yamaha como el YM2149. Este chip es capaz de generar 3 canales de audio independientes más un canal adicional de ruido blanco. Fue un chip de sonido muy común, utilizado, entre otros, en el standard MSX lanzado en 1983, el Amstrad CPC (1984), el ZX Spectrum 128K (1985) e incluso el Atari ST de 16-bits (1985).

En 1986, ya después de la compra de la IP de Sinclair por parte de Amstrad y de la decisión por parte de Alan Sugar de discontinuar la linea QL, ABC Elektronic decidió desarrollar, producir y comercializar una tarjeta de sonido para QL, añadiendo además un puerto paralelo para impresoras del que también adolecía el diseño original de Sinclair, con el objetivo de hacer esta solución más atractiva para los potenciales usuarios. El diseño estuvo a cargo del mismo Jochen Merz, con la participación de J. Reintsch, y estaba basado en el citado chip PSG AY-3-8910.

ABC Elektronic lanzó esta tarjeta con el nombre de QSound-QPrint, apareciendo por primera vez en un anuncio en la revista QL World de Mayo de 1986 como “Próximamente disponible”

Anuncio en QL World Mayo 1986

No fue hasta agosto de 1986 cuando este producto estuvo a disposición de los usuarios, de nuevo aparece en un anuncio de ABC Elektronic en QL World.

Anuncio en QL World Agosto 1986

Aun así, no fue hasta el número de enero de 1987 de QL World cuando se publicó una reseña sobre este interfaz, en un artículo compartido con otras dos soluciones para dotar al QL de capacidades sonoras: el QV2000 Speech Synthesizer (Maurice Computers) , y el The Talker (Sector Software).

Artículo sobre sistemas de sonido para el QL en QL World Enero 1987

El artículo completo puede leerse en las páginas 8 a 10 de la revista disponible en este enlace: https://dilwyn.qlforum.co.uk/mags/qluserworld/QL%20World%20January%201987.pdf

En dicha reseña se destacaba lo siguiente: “QSound probablemente representará el inicio de una nueva línea de dispositivos de generación de sonido para el QL y sus compatibles. Uno de los mejores productos comercializados por ABC”.

Como cualquier otro producto relacionado con el QL, esta tarjeta tuvo una difusión limitada, y es prácticamente imposible encontrar a fecha de hoy (Febrero 2025) una tarjeta original. De hecho, yo nunca he visto ninguna a la venta. De todas maneras, en la comunidad de usuarios del QL aún quedan entusiastas que se dedican a preservar no sólo el software sino también el hardware de la época, recuperando diseños, haciendo ingeniería inversa y compartiendo el fruto de sus investigaciones para que cualquiera pueda  replicarlos y construirse un clon. Uno de ellos es un miembro muy activo de la comunidad QL en España, Alvaro Alea, quien, en septiembre de 2022 realizó un primer clon de la interface QSound-QPrint y publicó todos los detalles en su github: https://github.com/alvaroalea/QL_QsoundQprint_clone

En el proceso de diseño, construcción y pruebas del interface, se detectaron y corrigieron algunos errores en la ROM del dispositivo, que fueron resueltos con la colaboración de uno de los gurús de la escena del QL, Marcel Kilgus, que fue corrigiendo el software de la ROM en función de los problemas reportados por Alvaro e incluso desarrolló un software reproductor de archivos de sonido AY para QDOS.

Este proceso quedó reflejado en este post en qlforum (a partir de la página 9) https://www.qlforum.co.uk/viewtopic.php?t=1587&start=80

Clon de la QSound-QPrint por Alvaro Alea en 2022, con la ROM 1.94 de M. Kilgus

Recientemente he tenido acceso a uno de estos clones  y he dedicado un par de tardes a probar cómo suena un QL. He podido probar los diferentes comandos BASIC que añade la ROM para generar sonidos, algunos listados BASIC que los utilizan, el reproductor AYPlayer de Marcel Kilgus (que reproduce archivos pt3, vtx e ym) y finalmente alguno uno de los pocos juegos que se programaron utilizando las capacidades de esta tarjeta para generar sonido y también un par de demos desarrolladas en 2024 y 2025.

En la segunda parte de este post veremos que se puede hacer con la QSound.

Sinclair QL desconocido: Aurora [QBlog] [Leer]


A parte de las limitaciones autoimpuestas por Sinclair en la especificación final del QL (microdrives en lugar de diskettes, 128k de RAM, CPU 68008 con bus de direcciones de 8 bits en lugar del 68000), otro de los grandes handicaps del QL eran sus modos de video y la muy particular organización de la memoria de video. 

Los fabricantes de ampliaciones de hardware para el QL se centraron en resolver las necesidades más básicas (almacenamiento masivo y cantidad de memoria) por lo que aparecieron varias soluciones de controladora de diskettes y ampliaciones de RAM, e incluso varias que combinaban ambas (microperipherals, Sandy, CST, Medic, Cumana, Kempston, MCS, PCML, Silicon Express, Spem, Quest) aunque la ampliación definitiva del QL en la primera época fue la Trump Card de Miracle Systems. Aparecida en 1987, incorporaba ampliación de RAM hasta 896kb, controladora de diskettes DD (720kb) y el Toolkit 2 en ROM. 

Tarjeta Trump Card de Miracle Systems. Al arrancar el QL indica la RAM disponible (896k) y el Toolkit 2

La compra de Sinclair por parte de Amstrad en 1986 y la decisión de cancelar la línea QL por parte de Alan Sugar propiciaron que algunas de las compañías que aún creían que había un mercado potencial para esta tecnología (no olvidemos que el Sinclair QL contaba con el sistema operativo QDOS, quizá el más avanzado en su momento para microordenadores basados en la línea de procesadores Motorola 68k) intentaron adquirir o licenciar la tecnología para producir evoluciones de la misma. 

CST lo intentó con la línea de ordenadores Thor, y Sandy contrató a Tony Tebby, diseñador del QL original en Sinclair Research para diseñar y producir el QLT (posteriormente Sandy Futura), pero desafortunadamente ninguna de estas iniciativas empresariales llegó a buen puerto. En la revista Microhobby se informó puntualmente de la situación (números 80-mayo’86; 87-julio’86; 114-febrero’87)

Stuart Honeyball (Miracle Systems) continuó apostando por la evolución de la plataforma QL, diseñando, fabricando y comercializando la siguiente generación de ampliaciones, que iban más allá de los límites conocidos de la plataforma. La tarjeta aceleradora Gold Card de 1991 incorporaba una CPU 68000 a 16MHz, 2Mb de RAM, una controladora de diskettes DD (720k), HD (1440k) o ED (3200k), el Toolkit 2 en ROM y reloj en tiempo real con batería, mientras que la Super Gold Card de 1994 mejoraba el procesador con un 68020 a 24MHz, ampliaba la RAM a 4Mb e incorporaba un puerto paralelo para impresoras. 

Gold Card Super Gold Card

En paralelo, tanto Miracle Sytems como otros fabricantes de hardware habían diseñado y comercializado soluciones de disco duro (CST SCSI, Medic, Quest, Rebel), todas estas soluciones eran propietarias y su coste muy elevado para el usuario medio. Zeljko Nastasic (diseñador de hardware) de Qubbesoft dio en el clavo con el QubIDE, aparecido en 1994. Esta interfaz de disco duro según el standard IDE permitía añadir discos duros y unidades de CD-ROM, y además disponía de un conector pass-through para conectar controladoras de diskette, ampliaciones de RAM o aceleradoras. 

Resueltas las limitaciones del QL en cuanto a procesador, RAM y almacenamiento masivo, tan sólo quedaba ocuparse de mejorar los modos gráficos para dotar al QL (o mejor dicho al QDOS) de mayor resolución gráfica y número de colores en pantalla. 

Los principales actores de la escena del QL se pusieron a ello. Miracle Systems llegó a anunciar la muy esperada tarjeta gráfica para QL con el nombre de Masterpiece, diseñada como una placa que reemplazara al chip ZX8301 con 128k de video RAM en chips ZIP, pero nunca se concretó como producto, probablemente debido a que en esa época (1996) Stuart Honeyball había perdido el interés y estaba gradualmente abandonando la escena del QL. El mismo Stuart y Tony Firschman contactaron con Nasta (Zeljko Nastasic), quien ya estaba trabajando en los primeros diseños de su tarjeta gráfica, para pasarle todo el material de desarrollo de la Masterpiece, lo que supuso un muy buen empujón para el desarrollo de lo que se convirtió en la placa Aurora, aparecida a finales de 1996, comercializada por Qubbesoft. 

Portada de QL Today en la que se anunciaba el lanzamiento de la Aurora

Esta historia está explicada en detalle por el mismo Nasta en este post de ql forum 

https://qlforum.co.uk/viewtopic.php?p=27618#p27618

La tarjeta Aurora es un reemplazo de la placa base del QL, sin CPU ni memoria RAM, que básicamente se ocupa de toda la gestión de periféricos de entrada y salida. Para la CPU y la RAM es necesario contar con una Gold Card o Super Gold Card. Es un planteamiento lógico para la época, ya que en 1996 prácticamente no quedaban usuarios activos de QL que no dispusieran de aceleradora. 

La Aurora podía instalarse en el QL original como reemplazo de la placa base, aunque la cantidad de cables necesarios para el poco espacio disponible hacían que esta no fuera la opción más recomendable. Idealmente, la Aurora estaba pensada para ser instalada en una caja de PC. 

Para funcionar, además de una Gold o Super Gold Card que proporcione la CPU y la RAM, la Aurora necesita dos chips de la placa base del QL (el ZX8302 y el 8049, aunque este último puede ser sustituido por un HERMES o un SuperHERMES). También debe añadirse una ROM con el sistema operativo en el zócalo correspondiente, que puede ser la ROM JS original del QL (instalando los dos chips en piggy-back), la ROM Minerva (versiones MK1 o MK2) o bien una EPROM de 512K 27050 o 27C040. 

La placa dispones de los siguientes conectores: 

  • Conector de expansión: standard del QL, habitualmente para la Super Gold Card o el backplane para conectar más de una expansión (SGC + QubIDE) 
  • Conector de Monitor: mediante un cable adaptador permite conectar varios tipos de monitor (RGB, VGA, S-VGA o Multisynch) 
  • Conector de “utilities”: para conectar el pulsador de reset, leds de alimentación y red, altavoz y conectores para la red QLNet 
  • Conector de ratón: según la interfaz QIMI, que permite conectar ratones de Atari ST o Amiga 
  • Conectores de puerto serie: dos puertos serie según el standard de PC que pueden conectarse usando adaptadores a DB-9 o DB-25 
  • Conector de teclado: para conectar un teclado de QL 
  • Puerto para cartuchos ROM: permite conectar mediante un adaptador cartuchos ROM standard de QL 
  • Conector de alimentación: necesario en caso de alimentar la Aurora mediante la fuente de alimentación del QL 

La configuración de los dispositivos en cada uno de estos conectores debe hacerse mediante una serie de jumpers disponibles en la placa. 

La configuración más habitual era la instalación en una caja de PC AT con su fuente de alimentación, conectando la alimentación y las extensiones de hardware (Gold o Super Gold Card y QubIDE) utilizado un backplane que incorporaba el conector para la alimentación de la fuente AT (el QPlane, también comercializado por Qubbesoft) 

La principal característica de la Aurora es la posibilidad de utilizar los modos de video de 16 y 256 colores en alta resolución. Para ello es necesario utilizar los drivers de video incluidos en el sistema operativo SMSQ/E, que debe cargarse desde disco una vez arrancado el sistema. Como el sistema permite utilizar un archivo boot, que es un programa en SuperBASIC, que contiene las extensiones que deben cargarse, así como cualquier otra acción que queramos realizar automáticamente en el arranque del sistema, esto no constituye ningún impedimento y podemos arrancar el sistema en el modo gráfico que prefiramos. 

Y aquí es cuando el tema se pone interesante, la placa Aurora se fabricó y distribuyó en cantidades muy limitadas, unos pocos miles de unidades, y es francamente complicado encontrar una a la venta. De hecho, desde que estoy en el hobby del retro, sólo he visto 3 a la venta: 

  • La segunda estaba camuflada entre varias tarjetas en un lote de desguace de QL en ebay Francia. El comprador la identificó y la consiguió a buen precio, pero a fecha de hoy no ha conseguido hacerla funcionar. Puede verse aquí (https://qxl.win/aurora.htm
  • La tercera apareció en un anuncio de compra-venta en el boletín de QUANTA correspondiente al Volume 41, Issue 2 de julio de 2024. Rápidamente me puse en contacto con el vendedor en UK y, tras no pocas peripecias para traerla desde UK sin tener que pagar los abusivos gastos de envío y tasas de aduana, conseguí tenerla en casa en noviembre del año pasado. 

Tuve mucha suerte, ya que venía en un lote con una Super Gold Card, un QubIDE y un QPlane, e incluía todos los chips necesarios (ROMs JS en pigy-back, ZX80302 y 8049). Este último venía instalado en un adaptador de teclado DI-REN para QL, que permite conectar un teclado standard AT de 101 ó 102 teclas al Sinclair QL, o en este caso a la Aurora. También venía con todos los cables necesarios (monitor VGA, ratón, puerto serie y cables de “utilities” (leds, pulsador de reset, red QL, etc.). Finalmente, el lote incluía el cable de disquetera, una unidad de diskettes de 3,5” DD y el cable para el puerto paralelo de la Super Gold Card. 

La tarjeta Aurora y el QPlane tal y como llegaron de UK. Se aprecia la ROM en piggy-back a la izquierda y el adaptador de teclado AT DI-REN con el IPC 8049 de Philips a la derecha El lote completo con la QubIDE, la Super Gold Card, disquetera, cables y adaptadores

La Super Gold Card está preparada para tomar la alimentación de una fuente AT a través del QPlane, por lo que no puede usarse directamente en un QL standard. Para poder probar el conjunto, necesitaba una fuente AT, o en su defecto una fuente ATX y un adaptador, y un adaptador de teclado AT a PS/2, ya que no tengo ningún teclado de PC antiguo. Una vez conseguidos los adaptadores llegó el momento de las pruebas… 

El montaje completo con las tres placas conectadas al QPlane y el adaptador de fuente AX a AT en primer plano

Para el montaje definitivo, he añadido una GOTEK y un adaptador IDE-CF para utilizarlo como disco duro. Esto me permite mover muy fácilmente software y archivos entre el PC y la Aurora. 

Una vez configurado el hardware, creo un pequeño programa boot que se encarga de cargar el SMSQ/E, cargar algunas extensiones, cambiar el modo gráfico a 256 colores y ahí está, un QL visualizando gráficos a pantalla completa en 256 colores con 512×384 pixeles de resolución y en un monitor VGA moderno sin adaptadores, conversores ni similares. Visto desde 2025 no es nada espectacular, pero en el mundo QL en 1997 fue una revolución….. 

Aurora, fuente ATX, teclado y VGA, imagen a 256 colores QDOS con video a 256 colores

QIMSI Gold. Primeras impresiones [QBlog] [Leer]


El 26 de abril de este año, Peter Graf anunció en QL Forum su última creació: la tarjeta QIMSI Gold, una ampliación para Sinclair QL que, conectada al puerto ROM, dota al ordenador de Sinclair de interface de ratón y teclado externo, almacenamiento microSD, CPU a 40MHz, ampliación de RAM, salida de video digital standard VESA, 8 modos gráficos con resolución hasta 1024×768 con color de 16-bits y la posibilidad de añadir un puerto serie de alta velocidad, un puerto QLnet y un sistema de Sonido Sampleado, medante unas sencillas modificaciones de hardware.

El 27 de abril, afx publicó una entrada con la información disponible en el momento del anuncio: https://sinclairqles.wordpress.com/2024/04/27/qimsi-gold-una-nueva-goldcard/

El mismo día del anuncio, me puse en contacto con Stephan, el compañero de Peter que fabrica las tiradas de sus interfaces, y le pedí que me incluyera en la lista de compradores tan pronto como la abrieran. Me contestó muy amablemente que estaban finalizando los detalles con el objetivo de presentar la tarjeta en la reunión internacional de usuarios de QL programada en Alemania del 17 al 19 de Mayo, y que ya tendría noticias suyas a primeros de Junio.

Efectivamente, el viernes 31 de Mayo recibi un email de Stephan con los detalles de las opciones y costes de la QIMSI Gold:

Prices, all in Euro

QIMSI Gold without RTC (real time clock): 75€
QIMSI Gold with RTC: 90€

Shipment expenses: EU, UK, Switzerland: 11€; Germany 6€
Insured and tracked.

Ese mismo fin de semana le confirmé el pedido e hice el pago de una tarjeta con RTC, y el martes18 de Junio fui a Correos a recoger el paquete que no habían podido entregarme el día antes al no haber nadie en casa. Ya tenía mi QIMSI Gold!!!!

Estos días he hecho varias pruebas con el interface y estoy muy satisfecho con él. Pero dejaremos las conclusiones para el final. Ahora vamos con el análisis del dispositivo y sus capacidades.

El dispositivo

El núcleo del QIMSI Gold es una FPGA Lattice que implementa varias interfaces QL, una CPU compatible con 68000 funcionando a 40 MHz, 32MB de RAM y un adaptador de video con salida video digital en un único circuito integrado.

Especificaciones

Interfaz microSD: ranura para tarjeta microSD. Funciona como un duro para el QL y se puede acceder a él a través de «WIN1_», por ejemplo. En cuanto a funciones, esta interfaz es compatible con la interfaz interna QL-SD diseñada originalmente por Peter Graf.
Interfaz de ratón: una interfaz de mouse PS/2 para QL, compatible con Pointer Environment. Se admite la rueda de desplazamiento del mouse.
Interfaz de teclado: una interfaz de teclado PS/2 para el QL. Actualmente el soporte de software está disponible para Minerva y SMSQ/E.
Interfaz de sonido: una interfaz de sonido muestreado para el altavoz interno del QL. Para conectar el altavoz es necesario una pequeña modificación de la placa base del QL. La conversión digital-analógica utiliza una frecuencia de muestreo de 20 kHz y almacenamiento en búfer FIFO de hardware para hasta 1024 muestras.
ROM: QIMSI proporciona un área de ROM de 16 KB para el QL en el rango de direcciones $C000… $FEC8. Por defecto, contiene el controlador QL para la interfaz de la tarjeta microSD. También puede cargar una ROM emulada desde una tarjeta microSD.
CPU interna (MiniQ68): un microprocesador interno, cuyo código es compatible con el 68000 y funciona a 40 MHz de reloj. Este MiniQ68 puede ejecutar los sistemas operativos Minerva y SMSQ/E.
RAM: 32 MB de RAM dinámica síncrona (SDRAM). Parte de esta RAM se usa como memoria de pantalla dedicada y no está disponible para otros fines.
Controlador de gráficos: controlador de gráficos integrado con color de 16 bits y RAM FIFO de alta velocidad. Proporciona los modos estándar QL 256×256 píxeles (8 colores) y 512×256 / 1024×768 píxeles (4 colores), un modo Aurora de 1024×768 píxeles (256 colores), así como modos de color de 16-bits de 512×256 / 512×384 píxeles (65536 colores). Utiliza dual/triple scan para resoluciones bajas. En todos los modos, la salida en el conector de vídeo digital se proporciona como una señal estándar VESA de 1024×768 para máxima compatibilidad con PC.
Puerto Serie: El MiniQ68 tiene acceso a un puerto serie básico que funciona a hasta 115200 baudios.
Puerto de E/S: El MiniQ68 tiene acceso a un puerto de E/S de un solo cable que se puede utilizar para conectar otros equipos a través de QLNet.
Reloj en tiempo real (opcional): QIMSI Gold puede equiparse con un reloj de tiempo real y un supercondensador de larga duración como respaldo durante el encendido/apagado. Esta opción requiere componentes adicionales en la parte inferior de la PCB.

Sistemas Operativos

Al arrancar el QL con la tarjeta QIMSI Gold conectada, el sistema de arranque comprueba si existe un archivo ROM en la microSD y lo carga y a continuación comprueba si existe un archivo con el sistema operativo. El dispositivo toma el control del QL y utiliza el teclado para manejar el MiniQ68, que a partir de ese momento, lanza la carga del sistema operativo (Minerva4Q68 o SMSQ/E).

Minerva4Q68: Port de Minerva compatible con Q68 desarrollado por Jan Breden Beek https://github.com/janbredenbeek/Minerva4Q68

SMSQ/E: Ultima evolución del sistema QDOS original desarrollado por Tony Tebby https://www.wlenerz.com/smsqe/

Minerva proporciona mayor compatibilidad con software antiguo, mientras que SMSQ/E incluye el Pointer Environment, los Colour Drivers y las últimas actualizaciones del sistema. La última actualización de SMSQ/E es de este mismo año 2024.

Actualmente no hay drivers disponibles para poder trabajar con la QIMSI Gold y unidades de Microdrive o diskette, pero utilizando los drivers MDI y FDI de Martin Head pueden utilizarse archivos de imagen de microdrive y de diskette https://dilwyn.qlforum.co.uk/utils/index.html

Modos de Video

QIMSI Gold permite trabajar con los siguiente modos de video. Para cambiar de modo de video debe utilizarse el comando DISP_MODE num, donde num es un número de la siguiente lista.

0 = modo de color QL 8 – modo estándar de 512 x 256 píxeles en 8 colores
1 = modo QL 4 colores – modo estándar de 512 x 256 píxeles en 4 colores
2 = 512 x 256 píxeles en modo 33 (16 bits por píxel).
4 = 1024 x 768 píxeles en modo QL 4 colores
5 = 1024 x 768 píxeles en modo Aurora 256 colores
6 = 512 x 384 píxeles en modo 33 (16 bits por píxel)

Rendimiento

He medido el redimiento de diferentes configuraciones utilizando la utilidad Bogomips de Thierry Godefroy, descargable desde https://dilwyn.qlforum.co.uk/benchmrk/index.html, obteniendo los siguientes resultados:

QL estandard (68006; RAM 128k): 0.27 Bogomips

SuperGold Card (68020; RAM 4MB): 5.78 Bogomips

QIMSI Gold: 5.99 Bogomips

Según Bogomips, la QIMSI Gold es más rápida que un QL con SuperGold Card.

Ejecución de BogoMips en QL stock, QL+SuperGold Card, QL+QIMSI Gold

He probado algunas de las distribuciones más habituales para QL avanzado (QLE, Black Phoenix, Q68) y funcionan muy bien en todos los modos de video soportados.

Distribución Black Phoenix 1.5 en modo 6 – 512 x 384 píxeles en modo 33 (16 bits por píxel) Entorno QDock en modo 6 – 512 x 384 píxeles en modo 33 (16 bits por píxel)

Para las pruebas he utilizado un QL issue 6 con ROM JS, una SuperGold Card (clon de tetroid) para el benchmark con Bogomips y una QIMSI Gold con varias tarjetas microSD con diferentes archivos contenedores de disco duro QLWA.win.

Archivos QXL.WIN de las distribuciones QLE y Black Phoenix están disponibles en los siguientes enlaces:

QLE: https://www.sinclairql.net/downloads/THE_DISTRIBUTION_qle.ZIP

Black Phoenix: http://www.hunggartorino.it/ql/warehouse/BP15.zip

Modificaciones adicionales

No he tenido tiempo ni medios para hacer las pruebas que requieren pequeñas modificaciones del QL (Sample Sound System) o de la propia tarjeta QIMSI Gold (puerto serie, puerto QLNet).

Para utilizar el puero serie deben añadirse 3 cables (GND, Rx, Tx) en los pines identificados como «Serial Port»:
1 Ground (marked by rectangular pad)
2 Transmit Date (TxD) Output
3 Receive Data (RxD) Input

Para utilizar el puerto I/O como conexión QLNet deben añadirse un conector jack de 3.5mm en los pines identificados como «I/O» y añadir un terminador de 330 ohm :

1 Ground (marked by rectangular pad)
3 I/O Signal with 47 Ω series resistor and clamp diode to 3.3V

Para utilizar el Sample Sound System con el altavoz del QL deben hacerse algunas modificaciones que varían ligeramente dependiendo de la versión de la placa del QL. Esencialmente, debe cortarse una patilla del conector del puerto ROM y añadir un cable para llevar la señal de audio al altavoz. estas modificaciones deben hacerse con sumo cuidado para evitar dañar tanto el QIMSI Gold como el propio QL.

Mi objetivo a medio plazo es modificar uno de mis QL para dejarlo ampliado al máximo. Una ampliación equivalente a un QL + QIMSI Gold era posible en la época, pero habría requerido las siguientes expansiones, que no eran nada fáciles de encontrar:

Aurora – video con 256 colores

SuperGold Card – CPU y ampliación de RAM

SuperHermes – Puerto Serie

QubIDE o ROMDisq – disco duro

QSound – Tarjeta de Sonido

QIMI o SERMouse – ratón

Este tipo de configuración es equivalente a lo que podría ser un Q40 o Q60. La máxima expresión de un sistema compatible QDOS.

Conclusiones

La tarjeta QIMSI Gold permite tener un QL ampliado a la máxima expresión con hardware moderno y muy fácil de instalar, configurar y mantener. El precio es muy contenido y las posibilidades de cacharreo que ofrece son prácticamente ilimitadas.

Mi experiencia hasta el momento es muy buena, y eso que acabo de empezar. Tal vez no sea un dispositivo para aquellos que prefieran la simplicidad y las limitaciones del sistema original, pero eso es como si los aficionados al Amiga no quisieran ir más allá del A500 com 1MB de RAM, renunciando a aceleradoras, tarjetas de video RTG, discos duros, etc. Esa postura es muy respetable, pero no la única aproximación posible a un sistema que vivió mucho más allá de su desaparición comercial en abril de 1986, soportada por sus creadores y otros usuarios (Tebby, Graf, Kilgus, Jones, Wicks, Goodwin, Stewart, Nasta, Lenerz, Merz, Dunbar y tantos otros) que la han mantenido viva hasta bien entrado el siglo XXI. Bien merece el QL que lo sigamos usando y bien merecen los creadores de nuevos desarrollos de hardware y software que les apoyemos en sus proyectos.

QL Forever!!!!

Convertir caracteres de texto de PC a QL [QBlog] [Leer]


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:

./utf2ql.sh nombre_fichero.txt

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

chmod 755 utf2ql.sh

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.

VIEW nombre_fichero.txt

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

¿Y Windows?

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

python utf2ql.py nombre_fichero.txt

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:

   with open(input_file, 'r', encoding='ISO-8859-15') as infile:

y renombrar el script a iso2ql.py.

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

Carga dinámica de programas en SuperBASIC [QBlog] [Leer]


¿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.

Fuente imagen: https://www.flickr.com/photos/193030246@N04/51238171803 Cargando programas en SuperBASIC

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

REM y lineas en blanco

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:

REM start : 100 PRINT "Hi!" : REM end

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

100 PRINT "Hi!"

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

Comandos sin número de línea intercalados

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:

PRINT #0,"Loading..." 100 REM The code here 110 REM ...

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.

Porcentaje de carga

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:

CLS #0 AT #0,0,0:PRINT #0, "Loading 0%" 100 REM code AT #0,0,0:PRINT #0, "Loading 25%" 250 REM more code AT #0,0,0:PRINT #0, "Loading 50%" 500 REM more and more code AT #0,0,0:PRINT #0, "Loading 75%" 750 REM more code again AT #0,0,0:PRINT #0, "100% loaded" 999 REM program loaded

Durante la carga, se ejecutará, cuando corresponda:

CLS #0 AT #0,0,0:PRINT #0, "Loading 0%" AT #0,0,0:PRINT #0, "Loading 25%" AT #0,0,0:PRINT #0, "Loading 50%" AT #0,0,0:PRINT #0, "Loading 75%" AT #0,0,0:PRINT #0, "100% loaded"

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

100 REM code 250 REM more code 500 REM more and more code 750 REM more code again 999 REM program loaded

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:

CLS #0 AT #0,0,0:PRINT #0, "Loading 0%" 100 REM Program here PAUSE 50 : REM Simulates the loading time AT #0,0,0:PRINT #0, "Loading 25% "; FILL$(CHR$(226), 3) 110 REM Program here PAUSE 50 AT #0,0,0:PRINT #0, "Loading 50% "; FILL$(CHR$(226), 6) 120 REM Program here PAUSE 50 AT #0,0,0:PRINT #0, "Loading 75% "; FILL$(CHR$(226), 9) 130 REM Program here PAUSE 50 AT #0,0,0:PRINT #0, "100% loaded "; FILL$(CHR$(226), 12)

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.

Creando los listados

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.

Calculando el tiempo de carga

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.

t=DATE 100 PRINT "PROGRAM CODE" : REM Only this numbered line will be shown in the listing : PAUSE 100 : REM Simulates the loading time of the rest of the lines of code PRINT "Loaded in ";DATE-t;" seconds."

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.

Consideraciones

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.

Advertencia

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

QIMSI Gold ¡Una nueva GoldCard! [QBlog] [Leer]


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.

Programando mi primera Demo en QL – fascículo IV, colisiones y puntuaciones [QBlog] [Leer]


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.

El Ying y el Yang

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!

La versión IV

Hay pocos cambios en esta versión.

100 REMark Yin & Yang v.4 110 REMark GPL, 2024, Badaman 120 REMark Colisiones y puntuaciones 130 : 140 CLEAR: RANDOMISE: ch%=3: ch2%=4 150 dev$="mdv1_": prg$="yinyang": v$="v4" 160 : 170 INICIO: PANTALLA 180 REPeat prg 190 n%=1-n% 200 BORRA(n%): CALCULA(n%) 210 MUEVE(n%): PRUEBA(n%) 220 IF KEYROW(1)=8: EXIT prg: REMark ESC 230 END REPeat prg 240 FIN: STOP 250 : 260 DEFine PROCedure sa 270 REMark Salva los cambios 280 file$ = dev$&prg$&"_"&v$&"_bas" 290 DELETE file$ : SAVE file$ 300 END DEFine sa 310 : 320 DEFine PROCedure INICIO 330 REMark Inicializacion del programa 340 an%=20-1: al%=20-1 350 DIM tablero%(an%, al%): DIM b%(1,5) 360 f$=" ": b$="O": REMark b$=CHR$(226) 370 FOR i=0 TO 19 380 FOR j= 0 TO 9: tablero%(i,j)=0 390 FOR j=10 TO 19: tablero%(i,j)=1 400 END FOR i 410 REMark Bolas, posiciones 'x' e 'y' 420 b%(0,0)=RND( 0 TO 18) : REMark x1 430 b%(0,1)=RND( 0 TO 9) : REMark y1 440 b%(1,0)=RND( 1 TO 19) : REMark x2 450 b%(1,1)=RND(10 TO 19) : REMark y2 460 REMark Desplazamientos 'dx' y 'dy' 470 b%(0,2)= 1: b%(0,3)= 1: REMark d1 480 b%(1,2)=-1: b%(1,3)=-1: REMark d2 490 REMark Ambas puntuaciones 500 b%(0,4)=200 : b%(1,4)=200 510 REMark Colores 520 b%(0,5)=1 : b%(1,5)=6 530 n%=1 : REMark Bola alterna 540 END DEFine INICIO 550 : 560 DEFine PROCedure FIN 570 REMark Finalizacion del programa 580 CLOSE #ch%: CLOSE #ch2%: MODE 4 590 END DEFine FIN 600 : 610 DEFine PROCedure PANTALLA 620 REMark Presentacion de pantalla 630 MODE 8 640 REMark Dibuja tablero 650 OPEN #ch%,scr_512x256a0x0 660 OPEN #ch2%,scr_324x225a97x18 670 PAPER #ch%,5,7: CLS #ch% 680 PAPER #ch2%,0: CLS #ch2% 690 WINDOW #ch%,324,202,94,16 700 WINDOW #ch2%,324,22,94,218 710 PAPER #ch%,b%(0,5): CLS #ch% 720 PAPER #ch2%,3: CLS #ch2% 730 BORDER #ch%,1,3: BORDER #ch2%,1 740 BLOCK #ch%,160,200,160,0,b%(1,5) 750 CSIZE #ch%,3,0: CSIZE #ch2%,0,1 760 INK #ch2%,4: CURSOR #ch2%,99,0 770 PRINT #ch2%,"YIN & YANG" 780 INK #ch2%,7 790 REMark Posicion inicial de pelotas 800 FOR i=0,1: MUEVE(i): MARCADOR(i) 810 END DEFine PANTALLA 820 : 830 DEFine PROCedure MARCADOR(bola%) 840 REMark Actualiza el marcador 850 CURSOR #ch2%,283*bola%,0 860 PRINT #ch2%,CERO$(b%(bola%,4)) 870 END DEFine MARCADOR 880 : 890 DEFine FuNction CERO$(valor) 900 REMark Rellena con ceros, max. 999 910 txt$=valor: ln%=LEN(txt$) 920 RETurn FILL$("0",3-ln%)&txt$ 930 END DEFine CERO$ 940 : 950 DEFine PROCedure BORRA(bola%) 960 REMark Borra la bola 970 LOCal x%, y%, c1% 980 x%=b%(bola%,0) : y%=b%(bola%,1) 990 c1%=b%(bola%,5): PAPER #ch%,c1% 1000 AT #ch%,x%,y%: PRINT #ch%,f$ 1010 END DEFine BORRA 1020 : 1030 DEFine PROCedure CALCULA(bola%) 1040 REMark Calcula un movimiento 1050 LOCal x%, y%, dx%, dy% 1060 x%=b%(bola%,0): dx%=b%(bola%,2) 1070 y%=b%(bola%,1): dy%=b%(bola%,3) 1080 x%=x%+dx%: b%(bola%,0)=x% 1090 y%=y%+dy%: b%(bola%,1)=y% 1100 END DEFine CALCULA 1110 : 1120 DEFine PROCedure MUEVE(bola%) 1130 REMark Mueve la bola 1140 LOCal x%, y%, c1%, c2% 1150 x%=b%(bola%,0): y%=b%(bola%,1) 1160 c1%=b%(bola%,5): c2%=b%(1-bola%,5) 1170 PAPER #ch%,c1%: INK #ch%,c2% 1180 AT #ch%,x%,y% : PRINT #ch%,b$ 1190 END DEFine MUEVE 1200 : 1210 DEFine PROCedure PRUEBA(bola%) 1220 REMark Comprueba colisiones 1230 LOCal x%, y%, dx%, dy% 1240 x%=b%(bola%,0): dx%=b%(bola%,2) 1250 y%=b%(bola%,1): dy%=b%(bola%,3) 1260 : 1270 IF tablero%(x%, y%)=1-bola% THEN 1280 IF y%-dy%>1 AND y%-dy%<18 THEN 1290 dy%=-dy%: b%(bola%,3)=dy% 1300 tablero%(x%, y%)=bola% 1310 b%(bola%,4)=b%(bola%,4)+1 1320 b%(1-bola%,4)=b%(1-bola%,4)-1 1330 FOR i=0,1: MARCADOR(i) 1340 END IF 1350 END IF 1360 : 1370 IF x%=0 OR x%=19: b%(bola%,2)=-dx% 1380 IF y%=0 OR y%=19: b%(bola%,3)=-dy% 1390 END DEFine PRUEBA Rebotes

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

1270 IF tablero%(x%, y%)=1-bola% THEN 1280 IF y%-dy%>1 AND y%-dy%<18 THEN 1290 dy%=-dy%: b%(bola%,3)=dy% 1300 tablero%(x%, y%)=bola% 1310 b%(bola%,4)=b%(bola%,4)+1 1320 b%(1-bola%,4)=b%(1-bola%,4)-1 1330 FOR i=0,1: MARCADOR(i) 1340 END IF 1350 END IF

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.

Repasando

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.

Ejercicio

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.

Hagamos un juego

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!

Enlaces recomendados

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

Programando mi primera Demo en QL – fascículo III, movimiento y rebotes [QBlog] [Leer]


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.

La dinámica

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:

DY = -DY

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:

b%(0, 3) = -b%(0, 3)

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

b%(0, 1) = b%(0, 1) + b%(0, 3)

Veamos cómo usarlo en el programa.

La versión III

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.

100 REMark Yin & Yang v.3
110 REMark GPL, 2024, Badaman
120 REMark Movimiento y rebotes
130 :
140 CLEAR: RANDOMISE: ch%=3: ch2%=4
150 dev$="mdv1_": prg$="yinyang": v$="v3"
160 :
170 INICIO: PANTALLA
180 REPeat prg
190 n%=1-n%
200 BORRA(n%): CALCULA(n%)
210 MUEVE(n%): PRUEBA(n%)
220 IF KEYROW(1)=8: EXIT prg: REMark ESC
230 END REPeat prg
240 FIN: STOP
250 :
260 DEFine PROCedure sa
270 REMark Salva los cambios
280 file$ = dev$&prg$&"_"&v$&"_bas"
290 DELETE file$ : SAVE file$
300 END DEFine sa
310 :
320 DEFine PROCedure INICIO
330 REMark Inicializacion del programa
340 an%=20-1: al%=20-1
350 DIM tablero%(an%, al%): DIM b%(1,5)
360 f$=" ": b$="O": REMark b$=CHR$(226)
370 FOR i=0 TO 19
380 FOR j= 0 TO 9: tablero%(i,j)=0
390 FOR j=10 TO 19: tablero%(i,j)=1
400 END FOR i
410 REMark Bolas, posiciones 'x' e 'y'
420 b%(0,0)=RND( 0 TO 18) : REMark x1
430 b%(0,1)=RND( 0 TO 9) : REMark y1
440 b%(1,0)=RND( 1 TO 19) : REMark x2
450 b%(1,1)=RND(10 TO 19) : REMark y2
460 REMark Desplazamientos 'dx' y 'dy'
470 b%(0,2)= 1: b%(0,3)= 1: REMark d1
480 b%(1,2)=-1: b%(1,3)=-1: REMark d2
490 REMark Ambas puntuaciones
500 b%(0,4)=0 : b%(1,4)=0
510 REMark Colores
520 b%(0,5)=1 : b%(1,5)=6
530 n%=1 : REMark Bola alterna
540 END DEFine INICIO
550 :
560 DEFine PROCedure FIN
570 REMark Finalizacion del programa
580 CLOSE #ch%: CLOSE #ch2%: MODE 4
590 END DEFine FIN
600 :
610 DEFine PROCedure PANTALLA
620 REMark Presentacion de pantalla
630 MODE 8
640 REMark Dibuja tablero
650 OPEN #ch%,scr_512x256a0x0
660 OPEN #ch2%,scr_324x225a97x18
670 PAPER #ch%,5,7: CLS #ch%
680 PAPER #ch2%,0: CLS #ch2%
690 WINDOW #ch%,324,202,94,16
700 WINDOW #ch2%,324,22,94,218
710 PAPER #ch%,b%(0,5): CLS #ch%
720 PAPER #ch2%,3: CLS #ch2%
730 BORDER #ch%,1,3: BORDER #ch2%,1
740 BLOCK #ch%,160,200,160,0,b%(1,5)
750 CSIZE #ch%,3,0: CSIZE #ch2%,0,1
760 INK #ch2%,4: CURSOR #ch2%,99,0
770 PRINT #ch2%,"YIN & YANG"
780 INK #ch2%,7
790 REMark Posicion inicial de pelotas
800 FOR i=0,1: MUEVE(i): MARCADOR(i)
810 END DEFine PANTALLA
820 :
830 DEFine PROCedure MARCADOR(bola%)
840 REMark Actualiza el marcador
850 CURSOR #ch2%,283*bola%,0
860 PRINT #ch2%,CERO$(b%(bola%,4))
870 END DEFine MARCADOR
880 :
890 DEFine FuNction CERO$(valor)
900 REMark Rellena con ceros, max. 999
910 txt$=valor: ln%=LEN(txt$)
920 RETurn FILL$("0",3-ln%)&txt$
930 END DEFine CERO$
940 :
950 DEFine PROCedure BORRA(bola%)
960 REMark Borra la bola
970 LOCal x%, y%, c1%
980 x%=b%(bola%,0) : y%=b%(bola%,1)
990 c1%=b%(bola%,5): PAPER #ch%,c1%
1000 AT #ch%,x%,y%: PRINT #ch%,f$
1010 END DEFine BORRA
1020 :
1030 DEFine PROCedure CALCULA(bola%)
1040 REMark Calcula un movimiento
1050 LOCal x%, y%, dx%, dy%
1060 x%=b%(bola%,0): dx%=b%(bola%,2)
1070 y%=b%(bola%,1): dy%=b%(bola%,3)
1080 x%=x%+dx%: b%(bola%,0)=x%
1090 y%=y%+dy%: b%(bola%,1)=y%
1100 END DEFine CALCULA
1110 :
1120 DEFine PROCedure MUEVE(bola%)
1130 REMark Mueve la bola
1140 LOCal x%, y%, c1%, c2%
1150 x%=b%(bola%,0): y%=b%(bola%,1)
1160 c1%=b%(bola%,5): c2%=b%(1-bola%,5)
1170 PAPER #ch%,c1%: INK #ch%,c2%
1180 AT #ch%,x%,y% : PRINT #ch%,b$
1190 END DEFine MUEVE
1200 :
1210 DEFine PROCedure PRUEBA(bola%)
1220 REMark Comprueba si rebota
1230 LOCal x%, y%, dx%, dy%
1240 x%=b%(bola%,0): dx%=b%(bola%,2)
1250 y%=b%(bola%,1): dy%=b%(bola%,3)
1260 IF x%=0 OR x%=19: b%(bola%,2)=-dx%
1270 IF y%=0 OR y%=19: b%(bola%,3)=-dy%
1280 END DEFine PRUEBA

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:

FOR i=0,1: MUEVE(i): MARCADOR(i)

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:

850 CURSOR #ch2%,283*bola%,0

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:

860 PRINT #ch2%,CERO$(b%(bola%,4))

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.

BORRA()

Código:

950 DEFine PROCedure BORRA(bola%) 960 REMark Borra la bola 970 LOCal x%, y%, c1% 980 x%=b%(bola%,0) : y%=b%(bola%,1) 990 c1%=b%(bola%,5): PAPER #ch%,c1% 1000 AT #ch%,x%,y%: PRINT #ch%,f$ 1010 END DEFine BORRA

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%.

CALCULA()

Código:

1030 DEFine PROCedure CALCULA(bola%) 1040 REMark Calcula un movimiento 1050 LOCal x%, y%, dx%, dy% 1060 x%=b%(bola%,0): dx%=b%(bola%,2) 1070 y%=b%(bola%,1): dy%=b%(bola%,3) 1080 x%=x%+dx%: b%(bola%,0)=x% 1090 y%=y%+dy%: b%(bola%,1)=y% 1100 END DEFine CALCULA

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%.

MUEVE()

Código:

1120 DEFine PROCedure MUEVE(bola%) 1130 REMark Mueve la bola 1140 LOCal x%, y%, c1%, c2% 1150 x%=b%(bola%,0): y%=b%(bola%,1) 1160 c1%=b%(bola%,5): c2%=b%(1-bola%,5) 1170 PAPER #ch%,c1%: INK #ch%,c2% 1180 AT #ch%,x%,y% : PRINT #ch%,b$ 1190 END DEFine MUEVE

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%.

PRUEBA()

Código:

1210 DEFine PROCedure PRUEBA(bola%) 1220 REMark Comprueba si rebota 1230 LOCal x%, y%, dx%, dy% 1240 x%=b%(bola%,0): dx%=b%(bola%,2) 1250 y%=b%(bola%,1): dy%=b%(bola%,3) 1260 IF x%=0 OR x%=19: b%(bola%,2)=-dx% 1270 IF y%=0 OR y%=19: b%(bola%,3)=-dy% 1280 END DEFine PRUEBA

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.

Y en la próxima entrega…

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

Ejercicio

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?

Enlaces recomendados

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

Siguiente entrega

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

Programando mi primera Demo en QL – fascículo II, variables y tablero [QBlog] [Leer]


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.

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.

La versión II

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:

100 REMark Yin & Yang v.2
110 REMark GPL, 2024, Badaman
120 REMark Variables y tablero
130 :
140 CLEAR: RANDOMISE: ch%=3: ch2%=4
150 dev$="mdv1_": prg$="yinyang": v$="v2"
160 :
170 INICIO: PANTALLA
180 REPeat prg
190 REMark codigo del programa
200 IF KEYROW(1)=8: EXIT prg: REMark ESC
210 END REPeat prg
220 FIN: STOP
230 :
240 DEFine PROCedure sa
250 REMark Salva los cambios
260 file$ = dev$&prg$&"_"&v$&"_bas"
270 DELETE file$ : SAVE file$
280 END DEFine sa
290 :
300 DEFine PROCedure INICIO
310 REMark Inicializacion del programa
320 an%=20-1: al%=20-1
330 DIM tablero%(an%, al%): DIM b%(1,5)
340 f$=" ": b$="O": REMark b$=CHR$(226)
350 FOR i=0 TO 19
360 FOR j= 0 TO 9: tablero%(i,j)=0
370 FOR j=10 TO 19: tablero%(i,j)=1
380 END FOR i
390 REMark Bolas, posiciones 'x' e 'y'
400 b%(0,0)=RND( 0 TO 18) : REMark x1
410 b%(0,1)=RND( 0 TO 9) : REMark y1
420 b%(1,0)=RND( 1 TO 19) : REMark x2
430 b%(1,1)=RND(10 TO 19) : REMark y2
440 REMark Desplazamientos 'dx' y 'dy'
450 b%(0,2)= 1: b%(0,3)= 1: REMark d1
460 b%(1,2)=-1: b%(1,3)=-1: REMark d2
470 REMark Ambas puntuaciones
480 b%(0,4)=0 : b%(1,4)=0
490 REMark Colores
500 b%(0,5)=1 : b%(1,5)=6
510 END DEFine INICIO
520 :
530 DEFine PROCedure FIN
540 REMark Finalizacion del programa
550 CLOSE #ch%: CLOSE #ch2%: MODE 4
560 END DEFine FIN
570 :
580 DEFine PROCedure PANTALLA
590 REMark Presentacion de pantalla
600 MODE 8
610 REMark Dibuja tablero
620 c1%=b%(0,5): c2%=b%(1,5)
630 OPEN #ch%,scr_512x256a0x0
640 OPEN #ch2%,scr_324x225a97x18
650 PAPER #ch%,5,7: CLS #ch%
660 PAPER #ch2%,0: CLS #ch2%
670 WINDOW #ch%,324,202,94,16
680 WINDOW #ch2%,324,22,94,218
690 PAPER #ch%,c1%: CLS #ch%
700 PAPER #ch2%,3: CLS #ch2%
710 BORDER #ch%,1,3: BORDER #ch2%,1
720 BLOCK #ch%,160,200,160,0,c2%
730 CSIZE #ch%,3,0: CSIZE #ch2%,0,1
740 INK #ch2%,4: CURSOR #ch2%,99,0
750 PRINT #ch2%,"YIN & YANG"
760 INK #ch2%,7
770 REMark Posicion inicial de pelotas
780 PAPER #ch%,c1%: INK #ch%,c2%
790 AT #ch%,b%(0,0),b%(0,1)
800 PRINT #ch%,b$
810 PAPER #ch%,c2%: INK #ch%,c1%
820 AT #ch%,b%(1,0),b%(1,1)
830 PRINT #ch%,b$
840 MARCADOR
850 END DEFine PANTALLA
860 :
870 DEFine PROCedure MARCADOR
880 REMark Actualiza el marcador
890 AT #ch2%,0,0
900 PRINT #ch2%,CERO$(b%(0,4))
910 CURSOR #ch2%,283,0
920 PRINT #ch2%,CERO$(b%(1,4))
930 END DEFine MARCADOR
940 :
950 DEFine FuNction CERO$(valor)
960 REMark Rellena con ceros, max. 999
970 txt$=valor: ln%=LEN(txt$)
980 RETurn FILL$("0",3-ln%)&txt$
990 END DEFine CERO$ Matrices

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.

Matriz: b%(1, 5)Bola 1Bola 2
Posición X(0, 0)(1, 0)
Posición Y(0, 1)(1, 1)
Desplazamiento X(0, 2)(1, 2)
Desplazamiento Y(0, 3)(1, 3)
Color(0, 4)(1, 4)
Puntos(0, 5)(1, 5)

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):

DIM b%(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í:

DIM tablero%(19, 19)

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.

INICIO 300 DEFine PROCedure INICIO
310 REMark Inicializacion del programa
320 an%=20-1: al%=20-1
330 DIM tablero%(an%, al%): DIM b%(1,5)
340 f$=" ": b$="O": REMark b$=CHR$(226)
350 FOR i=0 TO 19
360 FOR j= 0 TO 9: tablero%(i,j)=0
370 FOR j=10 TO 19: tablero%(i,j)=1
380 END FOR i
390 REMark Bolas, posiciones 'x' e 'y'
400 b%(0,0)=RND( 0 TO 18) : REMark x1
410 b%(0,1)=RND( 0 TO 9) : REMark y1
420 b%(1,0)=RND( 1 TO 19) : REMark x2
430 b%(1,1)=RND(10 TO 19) : REMark y2
440 REMark Desplazamientos 'dx' y 'dy'
450 b%(0,2)= 1: b%(0,3)= 1: REMark d1
460 b%(1,2)=-1: b%(1,3)=-1: REMark d2
470 REMark Ambas puntuaciones
480 b%(0,4)=0 : b%(1,4)=0
490 REMark Colores
500 b%(0,5)=1 : b%(1,5)=6
510 END DEFine INICIO

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:

10 FOR i=0 TO 255: PRINT CHR$(i)!

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.

FIN 530 DEFine PROCedure FIN
540 REMark Finalizacion del programa
550 CLOSE #ch%: CLOSE #ch2%: MODE 4
560 END DEFine FIN

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.

PANTALLA 580 DEFine PROCedure PANTALLA
590 REMark Presentacion de pantalla
600 MODE 8
610 REMark Dibuja tablero
620 c1%=b%(0,5): c2%=b%(1,5)
630 OPEN #ch%,scr_512x256a0x0
640 OPEN #ch2%,scr_324x225a97x18
650 PAPER #ch%,5,7: CLS #ch%
660 PAPER #ch2%,0: CLS #ch2%
670 WINDOW #ch%,324,202,94,16
680 WINDOW #ch2%,324,22,94,218
690 PAPER #ch%,c1%: CLS #ch%
700 PAPER #ch2%,3: CLS #ch2%
710 BORDER #ch%,1,3: BORDER #ch2%,1
720 BLOCK #ch%,160,200,160,0,c2%
730 CSIZE #ch%,3,0: CSIZE #ch2%,0,1
740 INK #ch2%,4: CURSOR #ch2%,99,0
750 PRINT #ch2%,"YIN & YANG"
760 INK #ch2%,7
770 REMark Posicion inicial de pelotas
780 PAPER #ch%,c1%: INK #ch%,c2%
790 AT #ch%,b%(0,0),b%(0,1)
800 PRINT #ch%,b$
810 PAPER #ch%,c2%: INK #ch%,c1%
820 AT #ch%,b%(1,0),b%(1,1)
830 PRINT #ch%,b$
840 MARCADOR
850 END DEFine PANTALLA

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:

OPEN #ch%,scr_512x256a0x0

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:

OPEN #ch2%,scr_324x225a97x18

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.

MARCADOR 870 DEFine PROCedure MARCADOR
880 REMark Actualiza el marcador
890 AT #ch2%,0,0
900 PRINT #ch2%,CERO$(b%(0,4))
910 CURSOR #ch2%,283,0
920 PRINT #ch2%,CERO$(b%(1,4))
930 END DEFine MARCADOR

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.

CERO$(valor) 950 DEFine FuNction CERO$(valor)
960 REMark Rellena con ceros, max. 999
970 txt$=valor: ln%=LEN(txt$)
980 RETurn FILL$("0",3-ln%)&txt$
990 END DEFine CERO$

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.

970 txt$=valor: ln%=LEN(txt$)
980 RETurn FILL$("0",3-ln%)&txt$

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».

Y en la próxima entrega…

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.

Ejercicio

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

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

Siguiente entrega

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

Programando mi primera Demo en QL – fascículo I, los preparativos [QBlog] [Leer]


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.

SuperBASIC

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:

100 DEFine PROCedure incremento
110 contador = contador + 1
120 END DEFine incremento
130 contador = 1
140 incremento
150 PRINT contador

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.

La estructura

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

100 REMark nombre del programa, version
110 REMark licencia, anyo, autores
120 REMark Estructura basica
130 :
140 CLEAR: REMark 'mdv1_yinyang_v1_bas'
150 dev$="mdv1_": prg$="yinyang": v$="v1"
160 :
170 INICIO: PANTALLA
180 REPeat prg
190 PRINT "Pulsa ESC": REMark Resto del codigo del programa aquí
200 IF KEYROW(1)=8: EXIT prg: REMark ESC
210 END REPeat prg
220 FIN: STOP
230 :
240 DEFine PROCedure sa
250 REMark Salva los cambios
260 REMark Nota: crear un fichero con el
270 REMark nombre correcto antes de usar
280 REMark y con cada nueva version
290 file$=dev$&prg$&"_"&v$&"_bas"
300 DELETE file$: SAVE file$
310 END DEFine sa
320 :
330 DEFine PROCedure INICIO
340 REMark Inicializacion del programa
350 END DEFine INICIO
360 :
370 DEFine PROCedure FIN
380 REMark Finalizacion del programa
390 END DEFine FIN
400 :
410 DEFine PROCedure PANTALLA
420 REMark Presentacion de pantalla
430 END DEFine PANTALLA
440 :
450 REMark Resto de FNs y PROCs aqui

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

Vamos por partes

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.

Nuestro programa

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

170 INICIO: PANTALLA
180 REPeat prg
190 PRINT "Pulsa ESC": REMark Resto del codigo del programa aquí
200 IF KEYROW(1)=8: EXIT prg: REMark ESC
210 END REPeat prg
220 FIN: STOP

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.

Usando el programa

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.

EDIT 150

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.

Y la próxima semana…

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.

Enlaces recomendados

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

Siguiente entrega

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

Expandiendo un QL, hacia el futuro y hacia el pasando [QBlog] [Leer]


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! 

Presencia en El Mundo del Spectrum, podcast 12×04 [QBlog] [Leer]


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.

Emisión del Super Directo

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.

Teclado español en sQLux [QBlog] [Leer]


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:

KBD = ES

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

Cambios

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.

Obtener el emulador

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):

sudo apt install build-essential cmake git libsdl2-dev
# ve a la carpeta donde descargarás el código
git clone --recursive https://github.com/SinclairQL/sQLux/
cd sQLux
cmake -B build/
make
# ahora prueba el binario
./build/sqlux --help

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).

«The Comfy Chair» – Sketch de los Monty Python.

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

Usando «MENU BOOT» [QBlog] [Leer]


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.

Probando la aplicación

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.

Cómo funciona

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:

100 REMark carga juego
110 EXEC_W JUEGO_EXE

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.

En resumen

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.

¿Por dónde empiezo?

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_.

Limitaciones

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.
Más información

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

Descargar

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.

Ejemplo de uso

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

Puede descargar el archivo aventuras.zip

Paquete de supervivencia del QL en español [QBlog] [Leer]


«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.

QL SCR Viewer en línea [QBlog] [Leer]


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

Info sobre su funcionamiento

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.

Enlaces

Presencia en AmigaWave #338 [QBlog] [Leer]


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.

Emisión del programa

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.