archivo

Hardware

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

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

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

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

Os pongo algunas imágenes:

QL is 40, QL forever!

PD:
¡Gracias napsternds! 

Resumen por: Miguel Ángel Rojo

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

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

Read More

El desarrollo de QLUB sigue avanzando. Martyn Hill, su creador, ha liberado recientemente el driver nativo QDOS y SMSQ/E para permitir integrar un PC con un emulador QL en la red QLNET.

A modo de resumen, el adaptador QLUB es una solución híbrida de hardware y software para permitir que un emulador QL en un PC con un puerto USB se pueda conectar a la red QLNET de Sinclair, la cual está disponible de serie en cualquier QL.

Además del QL, se pueden conectar máquinas compatibles con él que dispongan del hardware de red QLNET (por ejemplo Aurora, QXL, Q68, …) así como el ZX Spectrum con Interface-1 instalado.

Al vincular el emulador QL y el hardware QL «real» mediante QLNET y Toolkit II, es un asunto trivial transferir archivos con comodidad desde un entorno emulado al hardware retro original. Obviamente, la transferencia es de de “ida y vuelta”, pudiendo actuar como cliente o como servidor tanto el emulador como la máquina retro original.

La transferencia de archivos es solo el caso de uso más obvio: los juegos en red y la «computación distribuida» también se convierten en una propuesta práctica e interesante. Adicionalmente, dada la flexibilidad del sistema operativo QDOS, QLNET permite compartir los distintos dispositivos de cada estación a través de la red, por ejemplo impresoras, puertos serie, puerto paralelo y hasta la propia consola.

El dispositivo hardware es el siguiente:

Como se ve en las imágenes, QLUB consta de una placa Teensy++2.0 que se conecta a una pequeña placa adaptadora la cual alberga los conectores jac para la conexión de cableado QLNET.

Todos los componentes son libres y en los hilos del proyecto en qforum se pueden obtener el software necesario y las instrucciones para la construcción del dispositivo.

He realizado bastantes pruebas en mi red QLNET y el resultado es muy satisfactorio. Mi red QLNET está formada por tres estaciones: un QL real con SuperGoldCard, la FPGA Q68 y el PC con el emulador QL (QemuLator o QPC2). Las tres estaciones están configuradas como cliente y como servidor lo cual me permite la transferencia de ficheros desde-hasta cualquier estación así como la la ejecución de programas ubicados en cualquier estación servidora. En la siguiente imagen se puede observar como el QL original muestra el contenido de una carpeta del PC gestionada por QPC2 y el contenido de una de las unidades de almacenamiento de la FPGA-Q68. (En mi red QLNET: «n3» es el identificador del emulador PC que es la «estación 3», «n2» es el identificador de la FPGA-Q68 que es la «estación 2»).

La solución es perfectamente funcional y sólo existen algunas incidencias menores en las que está trabajando Martin Hill y que se corregirán en la siguiente versión del producto.

Referencias:

https://qlforum.co.uk/viewtopic.php?t=3590

https://qlforum.co.uk/viewtopic.php?t=4278

La red del Sinclair QL es realmente impresionante a pesar de su antigüedad y muy fácil de usar una vez que te acostumbras a los principios que están detrás de ella.

Como todos los QL tienen dos conectores de red (también las placas Aurora o las QXL), puedes encadenar hasta 63 máquinas en una misma red. Las dos máquinas de los extremos de la red deben tener uno de los dos conectores desconectados. Seguramente éstos tendrán una resistencia o algo parecido para establecer el final de la red cuando no hay un cable conectado. (Es decir, los dos extremos no necesitan conectarse a modo de red circular, esto si es necesario en SERNET y en MIDINET tal como diremos más abajo).

El cableado de la red QL es extremadamente simple. Un cable de dos hilos con conectores de audio mono de 3,5 mm en ambos extremos es todo lo que necesitas para unir dos QL, un cable de altavoces es perfectamente adecuado. Cualquier longitud razonable de cable debería funcionar, aunque no sé cual es la distancia máxima recomendada entre máquinas.

Antes de pensar en usar la red del QL asegúrate de usar Toolkit 2, el uso se hace mucho más simple y divertido. La red básica es usable sin Taoolkit 2, pero es necesario tener Toolkit 2 para aprovechar al máximo la red.

Número de estación.

Para identificar los ordenadores dentro de la red es necesario asignar a cada uno de un número entre 1 y 63. Esto se hace con el comando NET y un número entre 1 y 63 (por defecto el número de estación es la 1 si al comando NET no se suministramos número alguno). Por ejemplo, con el comando «NET 2» asignamos al ordenador la estación número 2 dentro de la red.

En una simple red con 2 estaciones (sólo dos QL conectados entre ellos) ambos ordenadores pueden tener el mismo número de estación. En estos casos la configuración es mucho más simple ya que no haría falta el comando NET ni asignar a cada ellos un número distinto. Como el valor 1 es el defecto, en cada uno de los QL nos referiríamos al otro como estación n1.

En una red con más de dos QL, la numeración de las estaciones no es automática y se debe realizar estación a estación con el comando NET y asignando a cada máquina de la red un número distinto entre 1 y 63. Puede ser una buena estrategia ir numerando secuencialmente las estaciones de la red, pero hay que tener en cuenta que para que una estación actúe como «servidor de dispositivos», el número de dicha estación tienen que estar comprendido entre 1 y 8 (ambos inclusive). Esto implica que en una res QL NET sólo pueden existir 8 servidores de dispositivos.

Tal como acabamos de comentar, una de las facilidades más importantes que nos aporta el Toolkit 2 es que podemos configurar en la red hasta 8 estaciones que actúen como servidores. Esto simplemente se hace con el comando «FSERVE». De forma general las estaciones en las que hemos cargado el job FSERVE pueden compartir con el resto de la red, no sólo su sistema de almacenamiento, sino también impresoras, puerto serie, puerto paralelo (si tienes Super GoldCard), su propia consola, etc.

Algunos ejemplos.

Supongamos que tenemos una red de tres QL (los tres con Toolkit 2) y queremos configurar una red donde queremos que dos de los QL actúen como cliente y como servidor y el último de ellos sólo como estación que consume recursos de los anteriores. Lo que podríamos hacer es configurar la red con los siguientes comandos:

En el QL 1 tecleamos el siguiente comando:

  FSERVE

En el QL 2 tecleamos el siguiente los comandos:

  NET 2
  FSERVE

En el QL 3 tecleamos el siguiente los comandos:

  NET 3

Eso es todo, pero resaltemos algunos detalles:

– En el QL 1 no hace falta especificar un número de estación ya que por defecto el valor de la estación es 1 (el comando NET sólo sirve para especificar el número de estación cuando ésta es distinta de 1).

– Como tenemos dos máquinas actuando como «servidores» de dispositivos, a esas máquinas (QL 1 y QL 2) les tenemos que asignar números de estación comprendidos entre 1 y 8. Al QL 3 le hemos asignado la estación 3, pero podría haber sido cualquier otro número entre 3 y 63.

Una vez configurada la red, pongamos algunos ejemplos de uso. En el QL 3 podríamos teclear los siguientes comandos:

DIR n1_FLP2:
  (Nos mostrará el pantalla el directorio raíz de la segunda disquetera
   de la estación 1). 

DIR n2_WIN1_programas_
  (Nos mostrará el pantalla el directorio WIN1_programas_ 
   de la estación 2). 

COPY win1_boot to n2_PAR             
  (Copiará el fichero boot de la unidad win1_ en la impresora
   paralelo de la estación 2)

COPY win1_boot to n2_SCR
  (Copiará el fichero boot de la unidad win1_ en la consola
   de la estación 2)

WCOPY flp1_games_ to n1_win1_games1_ 
  (Copiará todos los ficheros de la disquetera 1 al subdirectorio
   win1_Games1_ de la estación 1)

OPEN #5, n2_ser1: list #5: close#5
  (Listará el programa que tengamos cargado en memoria en la
   impresora serie de la estación 2)

EXEC n1_win1_games_chess
  (Ejecutará el programa chess desde el subdirectorio win1_games_
   de la estación 1). 

Una caractarística curiosa es que podemos abrir una ventana en la consola de otro usuario, imprimir un mensaje y esperar de él una respuesta. Por ejemplo, Afx (que está en la estación 1) podría ejecutar el siguiente programa para hacer una pregunta a Badaman que está en la estación 2:

10 OPEN #4, n2_con_200x200a0x0
20 INPUT #4, "Hola, aquí afx ¿podemos almorzar juntos?", r$
30 PRINT r$
40 CLOSE #4

Otra versión del mismo programa.

10 ch = FOPEN(n2_con_200x200a0x0): CLS #ch
20 INPUT #ch, "Hola aquí afx, ¿podemos almorzar juntos?", r$
30 PRINT r$
40 CLS #ch: CLOSE #ch

Una configuración interesante dentro de QL NET es hacer uso del sistema de dispositivos por defecto incorporado en el sistema operativo, proporcionado por los comandos DATA_USE, PROG_USE, SPL_USE y DEST_USE.

DATA_USE [nombre]    
  (selecciona el directorio de omisión para ficheros de datos)

PROG_USE [nombre]
  (selecciona el directorio de omisión para programas ejecutables)

DEST_USE [nombre]
  (selecciona el directorio de omisión de destino (COPY, WCOPY)) 

SPL_USE  [nombre]
  (selecciona el spooler de impresión por omisión (SPL))

El uso de estos nombres de directorio por omisión hace nos hace el trabajo bastante más fácil. Por ejemplo, con la siguiente instrucción todos los programas serán cargados por defecto desde el directorio «progs» del disco win1_ de la estación 1 cuando no indiquemos expresamente una unidad de almacenamiento.

PROG_USE n1_win1_progs 

Una vez introducido el comando anterior, podríamos ejecutar cualquier programa ubicado en esta estación de trabajo y subdirectorio simplemente con EXEC y el nombre del programa.

Pongamos otro ejemplo, con la siguiente instrucción se selecciona el dispositivo PAR (puerto paralelo) de la estación 2 como destino del «spooler» de omisión.

SPL_USE  n2_par

Y partir de la línea anterior, podemos imprimir en segundo plano cualquier fichero como el ejemplo siguiente:

SPL flp1_myFile_txt    
  (imprime myFile_txt en el puerto paralelo de la estación 2)

NFS_USE

Además del uso de dispositivos por defecto, podemos también «mapear» rutas de una red a un dispositivo cualquiera, esto lo hacemos con el comando NFS_USE que nos aporta el Toolkit 2. Veámoslo.

Mediante el comando NFS_USE es posible ocultar la red local a las aplicaciones escogiendo un nombre especial para el servidor de ficheros en red local. La sintaxis es la siguiente:

NFS_USE "nombre", "ubicaciones de la red local", ...

Los «nombres de red local» deben ser nombres de directorio completos, pudiéndose dar hasta 8 en un comando. Cada uno de estos nombres estará asociado con uno de los 8 posibles dispositivos de directorio («nombre_1» a «nombre_8»). Pongamos un ejemplo.

NFS_USE mdv,n2_win1_,n2_flp1_,n2_flp2_

La anterior sentencia asigna distintas ubicaciones de la estación 2 que actúa como servidor de ficheros a los dispositivos mdv1_, mdv2_ y mdv3_ de la estación cliente. En el ejemplo, «mdv1_» es asignada a la unidad win1_ en la estación 2, «mdv2_» será tomado como «flp1_» en estación 2 y «mdv3_» será tomado como «flp2_ «también en la estación 2.

Una cosa que también se suele hacer es «reasignar» un nuevo nombre a los dispositivos existentes si queremos «mapear» éstos a otras rutas de la red local. En nuestro ejemplo anterior haríamos lo siguiente:

MDV_USE MDD
NFS_USE mdv,n2_win1_,n2_flp1_,n2_flp2_

De esta manera mantendremos los accesos a las unidades de microdrive como MDD1_ y MDD2_ en lugar de MDV1_ y MDV2_.

El controlador de dispositivos DEV (DEV_USE).

En la primera versión de QDOS no existía la posibilidad de crear subdirectorios reales dentro de un dispositivo de almacenamiento. Debido a esto muchos programas de QL fueron escritos sin tener en cuenta la posibilidad de almacenar archivos en subdirectorios. En la siguientes versiones de QDOS, y por supuesto de SMSQ/E, apareció el soporte a lo que se llaman «nivel 2» del sistema de almacenamiento donde el soporte de subdirectorios es completo. Este «nivel 2» del sistema de almacenamiento se extendió con la (Super)GoldCard, dispositivos de disco duro y unidades de disquete de alta densidad. En este contexto, para facilitar la compatibilidad de los programas antiguos que no daban soporte a los subdirectorios, se creó una extensión que aporta un dispositivo virtual llamado DEV. En si, el dispositivo DEV es un dispositivo genérico por defecto (no sólo acotado al uso de la red local) y es una especie de «engaño» para permitir que el software antiguo (como Quill, Archive, Abacus y Easel) hagan uso de subdirectorios.

Además de lo expuesto anteriormente, y en el contexto que nos ocupa, los dispositivos DEV también tienen la capacidad de «mapear» dispositivos lógicos a rutas reales dentro de la red local.

Como de costumbre, hay hasta 8 dispositivos DEV; DEV1_ a DEV8_. Cada dispositivo DEV está conectado a un dispositivo real particular o a un directorio por defecto particular en un dispositivo real. Los archivos en un dispositivo DEV pueden ser abiertos, usados y borrados de la misma manera que en un dispositivo real.

Cada unidad «DEV» está conectada a un dispositivo mediante el comando DEV_USE. La sintaxis es la siguientes.

DEV_USE NúmeroDisp, DirectorioReal

Pongamos un ejemplo.

DEV_USE 4, n2_win1_sys_

A partir de la introducción de comando anterior podemos hacer referencia al contenido del directorio win1_sys_ de la estación 2 como dispositivo DEV4_ de nuestra estación.

A tener en cuenta que el sistema QDOS y SMSQ/E puede manejar también dispositivos distintos a los dispositivos de almacenamiento. Estos dispositivos son:

SER1 y SER2  (puertos serie RS232)
PAR          (puerto paralelo (sólo a partir de SuperGoldCard))
SCR,         (pantalla como dispositivo de salida)  
CON          (consola como dispositivo de entrada/salida)

Esto significa que podemos mapear una unidad DEV a uno de estos dispositivos. Por ejemplo:

DEV_USE 8, n1_par

La orden anterior asigna la unidad lógica «DEV8_» al puerto paralelo de la estación 1.

Otro ejemplo interesante:

NFS_USE "ser",n1_par, n2_par 
PAR_USE "ser"
COPY_N "flp1_myfile" TO "ser2"

Las líneas anteriores reasignan los identificadores de los puertos serie de mi estación, concretamente, SER1_ se reasigna al puerto paralelo el la estación 1 y SER2_ se reasigna al puerto paralelo de la estación 2.

SERNET y MIDINET

Tanto SERNET como MIDINET son controladores de red que aparecieron posteriormente y te permiten montar redes de bajo costo como la QL NET original del Toolkit 2. SERNET permite conectar dos o más máquinas que ejecutan SMSQ/E a través de los puertos serie, mientras que MIDINET permite conectar dos o más ordenares ATARI con SMSQ/E a través de los puertos MIDI. SERNET fue desarrollado a partir del software MIDINET de Phil Borman. Bernd Reinhardt modificó el software para usar los puertos seriales en lugar de los puertos MIDI.

Con estos controladores podemos ampliar las «fronteras» extendiendo la red QL, por ejemplo, permitiendo que las máquinas sin conectores net 1 / net 2 del QL se unan a la red.

Tanto el SERNET como el MIDINET están organizados como una red circular. En el caso de MIDI, el puerto MIDI OUT de cada máquina tiene que estar conectado al puerto MIDI IN de la siguiente máquina. Todos los cables tienen que formar un círculo completo. Cada máquina en el círculo tiene que estar funcionando y el controlador tiene que cargarse para tener una red en funcionamiento. Lo mismo se aplica a SERNET: con dos máquinas, puede usar un cable de módem nulo. Con tres o más máquinas, debes cablear tus propios cables para que todas las señales de salida de una máquina estén conectadas a las señales de entrada de la siguiente máquina y así sucesivamente, para formar un círculo completo también.

SERNET tiene que configurarse para que sepa qué puerto usar como puerto de comunicación. Como es habitual en muchos programas y controladores de dispositivo del QL esto se hace mediante el uso de MenuConfig para configurar los parámetros dentro del binario del propio controlador (SERNET_REXT).

Una vez configurado podemos cargar el controlador con una instrucción similar a la siguiente (suponemos que el controlador está en el directorio raíz de la unidad win1_.

LRESPR win1_SERNET_REXT

Sernet enlaza los ordenadores a través del puerto serie y utiliza el nombre de dispositivo «S» de forma similar a la «N» para la red QL.

Y por último, una vez cargado el controlador, sólo tenemos que definir el número de estación y activar los servicios de la estación como servidora dentro de la red. Las instrucciones serían como el siguiente ejemplo:

Estación 1:
  SNET_USE 1
  SERNET 

Estación 2:
  SNET_USE 2
  SERNET 

A partir de este momento estas dos estaciones pueden compartir sus recursos. Por ejemplo con la siguiente instrucción en la estación s1.

DIR s2_FLP2_            

Nos mostrará el pantalla el directorio raíz de la segunda disquetera de la estación 2.

Enlazando las dos redes, QLNET y SERNET.

Para finalizar, el último paso de nuestro experimento es configurar un entorno, en el cual puedan convivir dos redes: QL NET y SERNET. Por un lado QL NET nos permitiría conectar QL originales (BBQL) en nuestro entorno, y por otro lado podríamos añadir a esta «red QL» sistemas modernos que tengan disponible al menos un puerto RS232 (por ejemplo el emulador QPC2 en un PC con Windows 10 o la FPGA Q68).

El punto de unión de estas dos redes la hemos resuelto con una combinación hardware-software relativamente reciente. El hardware no es otro que la FPGA Q68 que incluye de serie un puerto RS232 y a la cual se la he aplicado un «modding» para incluir dos conectores QL NET. En cuanto al software, lo único que necesitamos ejecutar en la Q68 es el driver SERNET que hemos mencionado anteriormente y el nuevo driver QLNET de Martyn Hill que te permite conectar en red el Q68 con otras máquinas compatibles con QL a través de los puertos QLNET estándar. Los comandos a incluir en el boot de arranque de la Q68 sólo debe incluir los siguientes comandos:

LRESPR win1_sernet_rext     (Carga el controlador SERNET)
BAUD 115200                 (Establece la velocidad en baudios) 
SERNET 2                    (Establece s2 como número de estación SERNET)
SERNET                      (Activa los servicios SERNET) 

LRESPR win1_ndq68_dvr_v305  (Carga el driver de red QL NET para Q68)
NET 2                       (Establece n2 como estación QL NET) 
FSERVE                      (Activa las funciones de servidor QL NET). 

Descrito todo esto, la primera parte de este artículo seguramente tendrá más sentido.

—-
Fuentes:
– SUPERTOOLKIT II, MANUAL DEL USUARIO (Tony Tebby, Qjump, Reino Unido. 1985).
– The QL Network. QL Today, Volume 9 Issue 4. (David Denham).
– SERNET on QDOS? QL Today, Volume 6 Issue 6. (Dilwyn Jones).
– Announcing availability of a QLNET driver for the Q68 (ND-Q68) (https://qlforum.co.uk/viewtopic.php?f=3&t=2881&p=28393) (Martyn Hill).

Aprovechando la salida de la nueva versión de SMSQ/E, en el siguiente video de se programa semanal de AmigaWave, David hace un excelente repaso de la trayectoria del mundo del QL, especialmente de las expansiones como la GoldCard las QXL y las Q40 y Q60, y muestra el entorno de ventanas Pointer Envoronment (PE) a color real, y con resoluciones superiores a 512×512.

Lo relativo al QL comienza en el minuto 50 y dura unos 40 mins.

¡No os lo perdáis!

Desde Rusia nos llega una “nueva” tarjeta de expansión para el Sinclair QL con ampliación RAM y controladora de disquetera compatible con la popular Trump Card de Miracle System. En realidad se trata de una tarjeta clónica de esta última.

La Trump Card incorpora 768K de RAM, que al conectarla al QL con sus 128K, expande la memoria disponible hasta los 896K. La interfaz de disco está basado en el controlador WD1772 con el cual se da soporte a unidades de disco de 3.5 pulgadas y 720K (o a discos 5.25 pulgadas de baja densidad). La tarjeta incluye también el Toolkit II.

Varias unidades aparecen regularmente a la venta en eBay y en SellMyRetro.

Tarjeta clónica Trump Card (1)

Tarjeta clónica Trump Card (1)

Tarjeta clónica Trump Card (1)

Tarjeta clónica Trump Card (1)

Tynemouth Software sigue ampliando su catálogo de placas adaptadoras para transformar teclados de máquinas retro en teclados USB. Esta vez le ha tocado el turno al Sinclair QL.

Aquí el enlace al proyecto:
http://blog.tynemouthsoftware.co.uk/2015/12/day-3-sinclair-ql-usb-keyboard.html

Con esta pequeña placa podemos transformar nuestro teclado QL en un teclado USB, ideal para montar una Raspberry Pi o una MiST dentro de la caja de un QL.

Sinclair QL USB keyboard

Sinclair QL USB keyboard

Sinclair QL, teclado USB

Sinclair QL, teclado USB

Recientemente ha salido a la luz la implementación hardware del Sinclair QL en la FPGA MiST. El core actual es capaz de emular a un QL con ampliación RAM de 512 KB, que con los 128KB del sistema original tendríamos un QL emulado con 640 KB de RAM.

Como dispositivos de almacenamiento se soportan imágenes de Microdrive y volúmenes QL-SD a modo de sistema de almacenamiento masivo de lectura/escritura.

Se pueden ver los resultados en estos videos:

(Video elaborados por Urs König en EJAGFEST 2015)

(Pruebas preliminares del propio Till Harbaum)

Enlaces relacionados:
http://www.lotharek.pl/product.php?pid=96
http://qlforum.co.uk/viewtopic.php?f=2&t=1360

Clon QubIDE de Jose_leandro

Clon QubIDE de Jose_leandro

Ya es una realidad, el clon QubIDE de jose_leadro está en manos de los entusiastas del Sinclair QL.

Esta tarjeta es la expansión ideal para cualquier propietario de un Sinclair QL que quiera dar uso a este retro-ordenador. Se acabaron las incomodidades y el infierno de los Microdrive, además, ya podemos prescindir de buscar esas tarjetas de ampliación RAM y controladoras de disquetes tan caras y difíciles de conseguir en la actualidad.

El «kit» completo de jose_leadro está compuesto por tres componentes:

1) La tarjeta clon QubIDE propiamente dicha, la cual incorpora una ampliación RAM de 512 KB. Para quien no lo sepa, la QubIDE es una pequeña tarjeta controladora de discos IDE que incorpora el driver necesario para el sistema operativo, fue diseñada por la empresa Qubbesoft a mediados de los 90.

2) Una Eprom con el sistema operativo Minerva más el Toolkit II. Aunque este componente es opcional ya que la QubIDE puede funcionar perfectamente en un QL estándar, sí que es muy recomendable. Minerva es una versión depurada y mejorada del QDOS (el sistema operativo original del QL). El Toolkit II son unas extensiones que aportan nuevos comandos y facilidades al sistema operativo que nos simplificará enormemente el trabajo con el QL (un editor SuperBasic de pantalla completa, comandos para manejo de directorios, etc…).

3) Por último, un programa Windows para poder realizar el traspaso de ficheros entre el PC y la tarjeta CF o SD. Esta utilidad ha sido desarrollada por Habi, y tiene la cualidad de entenderse perfectamente con el sistema de ficheros de las unidades QubIDE y las particularidades del sistema de ficheros del QDOS (por ejemplo, las cabeceras de los ejecutables).

Por supuesto, que además de lo anterior tendremos que tener una unidad de almacenamiento IDE (disco duro o equivalente). En este apartado, lo recomendable y lo más práctico, es adquirir una de esas típicas tarjetas IDE-Compact Flash o IDE-SD. En mi caso tengo una IDE-SD y funciona a la perfección. Otra alternativa muy compacta es el DiskOnModule, un módulo de memora flash encapsulado en el propio conector IDE.

Esta propuesta de almacenamiento masivo que nos trae jose_leadro es completa, en el sentido que no necesitamos ningún componente adicional en el QL para transferir la enorme biblioteca de software que existe en internet a una unidad IDE y ser usada en nuestros QL como si de un “gran” disco duro se tratar.

Sin duda, este clon QubIDE dará nueva vida a nuestros QLs.

Este es el enlace principal del proyecto donde se encuentra una descripción completa y distintos tutoriales:

http://hardware.speccy.org/temp/qubide.html

Algunas fotos de mi clon QubIDE:

Clon QubIDE + Eprom Minerva con Toolkit II

Clon QubIDE + Eprom Minerva con Toolkit II

Tarjeta SD-IDE y DiskOnModule

Tarjeta SD-IDE y DiskOnModule

Programa editor de imágenes de Habi

Programa editor de imágenes de Habi

QubIDE en acción (WIN1_)

QubIDE en acción (WIN1_)

Me ha llegado recientemente esto:

Mi QL-SD 1

Mi QL-SD 1

Se trata de la «QL-SD», una interfaz para tarjetas SDHC que nos permite cargar y guardar programas y datos de una forma rápida y segura sin la necesidad de interfaces de disco ni unidades Microdrive.

La interfaz se ajusta internamente dentro del QL, lo que supone que tenemos que abrir el QL, quitar los dos chips ROM originales y montar sobre uno de los zócalos ROM una pequeña tarjeta que contiene el controlador de la tarjeta SD y una ROM con una versión mejorada del sistema operativo llamada Minera. Además se deberá montar una segunda plaquita en donde se inserta la propia tarjeta SDHC. El lugar ideal para montar esta segunda tarjeta es en el espacio que deja la segunda unidad Microdrive ( mdv2_ ) la cual debemos extraer, así podríamos insertar y extraer la tarjeta SD como si de un cartucho Microdrive se tratara. Esto último no es obligado, esta segunda tarjeta pude alojarse en cualquier otro lugar interno o externo del QL. El comportamiento final de la tarjeta es como si tuviéramos un disco duro conectado a nuestro QL.

En el paquete se suministra también una tarjeta SDHC precargada con software e «imágenes» de disco duro de distinto tamaño pre-configuradas y listas para usar. La imagen de disco duro que reconocerá el QL debe estar en el directorio raíz de la tarjeta. Con el software suministrado podemos crear esas «imágenes» en el PC y transferir ficheros a ellas con Q-emuLator.

Es altamente recomendable una expansión de memoria, yo diría que imprescindible. Entre las limitaciones más importantes están: a) su incompatibilidad, en el momento actual (*), con las tarjetas de expansión (Super) Gold Card (*); y b) la imposibilidad de conectar otros dispositivos al puerto ROM externo del QL.

Esta expansión se puede conseguir en http://www.sellmyretro.com donde periódicamente están saliendo a la venta tiradas limitadas.

Aspecto del kit montado y en acción:

Mi QL-SD 2

Mi QL-SD 2

Mi QL-SD 3

Mi QL-SD 3

Me ha parecido un desarrollo fantástico, la expansión que esperábamos muchos entusiastas del Sinclair QL.

Editado:
(*) No se descarta resolver esta incompatibilidad en el futuro.