archivo

Sistema

A raíz de la propuesta en un hilo de discusión en zona de pruebas me he decidido a probar la red local entre mis dos QL’s. Hasta ahora ni siquiera lo había intentado, entre otras cosas, por la mala fama (muy extendida por cierto) sobre la funcionalidad de la red local de los QL’s y Spectrum de Sinclair. Por ejemplo, en el manual del Toolkit 2, el propio Tony Tebby dice textualmente “.. si su QL es de una versión anterior al número de serie D14, es altamente posible que el soporte físico de la red no funcione en absoluto …”. Seguro que este tipo de afirmaciones no son gratuitas del señor Tebby. También es cierto que el propio Tebby, textualmente, reconoce más adelante que “… aunque la experiencia reciente ha demostrado que hay más QLs pre-D14 de los supuestos con una puerta de red local que funcina…”.

A pesar que mis QL’s son anteriores a la serie D14, y con la esperanza que se traten de esos “supuestos” QL’s a los que le funciona la puerta de red, empecé a montar y probar una mini-red de 2 QL’s para comprobar en la práctica su funcionalidad y fiabilidad.

Tras buscar el cable correspondiente y conectar los dos QL’s llegó la sorpresa … ¡¡funcionaaaa!!

Es fantástico, he conectado los QL’s en red y va todo a la perfección, tal como dice el manual del Toolkit 2. Hay que decir, que aunque el QDOS original soporta el funcionamiento de una red de QL’s (hasta un máximo de 62), lo hace de una manera muy elemental. El Toolkit 2 añade una serie de facilidades que permiten configurar la red local cómodamente y usar recursos del resto de QL’s conectados de forma muy simple. Con las facilidades del Toolkit 2 puedo poner fácilmente uno o varios de los QL’s como “servidor” y así compartir todas sus unidades de almacenamiento con el resto de QL’s de la red.

Aquí están mis dos QL’s conectados vía red local. El QL 1 (el que se ve en la imagen a la izquierda) tiene dos disqueteras de 1.4 y el RomDisQ de 8 MB, tiene su propio monitor (1084). El QL 2 (el de la derecha) no tiene unidades de almacenamiento externo, está conectado a mi capturadora AverMedia del PC (la calidad de la imagen es pésima, pero viable para hacer pruebas).

Red local 2 QLs

Para activar la red sólo hay que teclear el comando NET x (x es cualquier número entre 1 y 63) en cada QL. En mi caso NET 1 para el primer QL y NET 2 para el segundo QL. A continuación, en el QL que actúa como servidor hay que teclear el comando FSERVE (el QL 1 en mi caso). Estos son los comandos que he empleado en el primero de los QL’s:

NET 1
FSERVE

Como dijimos anteriormente, cada estación deberá tener un número único en la red. Si la estación no tiene recursos que ofrecer al resto y sólo va a utilizar recursos de los demás entonces no hace falta FSERVE.

Ahora, desde el QL 2 puedo ejecutar cualquier programa almacenado en el primer QL, por ejemplo así:

EXEC_W n1_flp1_chess_exe

Como veis, sólo hay que anteponer N con el número de estación a la unidad_fichero que queramos ejecutar.

Aquí vemos, el segundo QL ejecutando el chess almacenado en la unidad RomDisQ del primer QL.

QL 2 ejecutando programa almacenado en QL 1

Según el manual del Toolkit II, el servidor de ficheros permite acceso por parte de otro QL a 10 recursos unidos él, estos recursos pueden ser no sólo dispositivos de fichero (por ejemplo discos), sino también dispositivos en serie puros (modems, impresoras) o ventanas de pantalla del QL. Los servidores de la red deberán ocupar los número de estación entre 1 y 8. Una vez configurado el servidor podemos hacer cosas como las siguientes:

LOAD n1_flp1_osusq_bas 
    - carga el fichero "osusq_bas" del disco 1 de la estación 1 -

OPEN_IN #3, n2_flp2_clientes 
    - abre el archivo "clientes" en el disco 2 de la estación 2 -

OPEN #3, n1_con_200x100a10x10 
    - abre una ventana de 200 x 100 pixeles en la posición 10,10 
       en la estación 1 -

Esto último es especialmente curioso, podemos tener un programa en SuperBASIC que vuelque su salida por la consola de otra estación de la red. En la siguiente imagen vemos la pantalla del QL 2 donde se muestra por una parte el directorio de la unidad RomDisQ del QL 1 y por otra parte una ventana con “Hola mundo” ejecutada por el otro QL (¡el QL de la estación 1!).

Mostrando directorio en red y compartiendo consola

Compartiendo consola (detalle)

El QDOS ejecuta perfectamente en multitarea la salida por consola de un programa y atiende la salida por la misma consola de un programa ejecutado por otra estación de la red. En el ejemplo anterior el volcado del directorio de la estación 1 y la salida de “Hola mundo” (un bucle de 100 iteraciones) fue ejecutado en multitarea.

En una red de QLs con Toolkit II también funcionan los directorios por omisión de programas y de datos. Con una instrucción como esta, tecleada en el QL 2

PROG_USE n1_flp2_MisProgramas

se establece el directorio “MisProgramas” de la unidad flp2_ del QL 1 como directorio por defecto para la ejecución de programas.

Por último, uno de las facilidades más interesante es la posibilidad de “mapear” unidades compartidas de red como si fueran dispositivos nativos del QL. Esto lo hacemos mediante el comando NFS_USE.

Si tecleamos en la estación 2 la siguiente instrucción:

NFS_USE mdv,n1_flp1_,n1_flp2_

hará que, para esta estación (la 2), el dispositivo mdv1_ y mdv2_ sea “mapeado” a las unidades flp1_ y flp2_ de la estación 1. Es decir, podemos simular que estamos accediendo a las unidades microdrive del QL 2 cuando en realidad se está accediendo a las unidades de disquete de la estación 1.

Podemos especificar hasta 8 valores para un dispositivo y además especificar nombre de subdirectorios. Por ejemplo:

NFS_USE mdv,n1_flp1_,n1_flp2_,n2_rom1_juegos_,n2_win1_utils_

Esto hará que la estación donde ejecutamos este comando crea que tiene 4 unidades de microdrive con el siguiente “mapeo”:

mdv1_ = unidad flp1_ en la estación 1
mdv2_ = unidad flp2_ en la estación 1
mdv3_ = directorio "juegos" de la unidad rom1_ en la estación 2
mdv4_ = directorio "utils" de la unidad win1_ en la estación 2

En todas las pruebas que he realizado, la única pega que he observado es la relativa lentitud a la hora de acceder a recursos compartidos, pero en cualquier caso siempre resulta mucho más rápido y fiable que el acceso a unidades de microdrive (yo diría que casi es la velocidad de un disquete).

En conclusión, me he llevado una grata sorpresa con las facilidades que tiene el QL con Toolkit II para la configuración y trabajo en una red de QL’s. Si lo pensamos detenidamente y nos situamos en el año 84/85 ¿qué ordenadores personales ofrecían estas facilidades de serie? … pues muy pocos o ninguno. El QL tuvo carencias importantes en algunos aspectos (el sistema de almacenamiento incorporado por ejemplo) pero se adelantó a su época en otros aspectos, uno de ellos, en su capacidad de trabajo en red incorporado de serie.

Anuncios

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

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

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

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

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

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

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

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

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

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

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

INSTALACIÓN DE TOOLKIT’s

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

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

_BIN, _CDE, _REXT, _RXT, _EXT

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

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

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

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

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

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

100 LRESPR FLP1_TOOLKIT_EXT

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

EL ORDEN EN UN PROGRAMA DE INICIO

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

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

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

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

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

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

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

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


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

En varias ocasiones hemos tratado el tema del manejo de la pantalla del QL en Qforum (el foro del QL de sinclairql.es). En ellos hay variedad de información, pero al menos a mí, siempre me han quedado algunas lagunas debido al desconocimiento de cómo trata el QL la pantalla. En muchas ocasiones no he entendido exactamente las aportaciones de los otros usuarios cuando hablan en profundidad de este tema, siempre ha habido conceptos que se me han escapado y que no he llegado a comprender del todo bien. Por ejemplo, el porqué de las distintas resoluciones del QL, como se gestionan los colores, las peculiaridades del “flashing”, etc.

Para cubrir estas lagunas presento este artículo en el cual sólo me he dedicado a rescatar material “enterrado” en varias fuentes que hablan sobre esto. He dividido el artículo en dos partes. Una primera parte con “la teoría” extraída de un buen artículo de la vieja revista Qlave escrito por Javier Boira (¡fantástico el artículo!), y una segunda parte donde se ejemplifica el tratamiento directo de la memoria de pantalla del QL mediante un pequeño programa escrito en SuperBASIC. Este programa no es más que una adaptación de otro pequeño programa de Timothy Swenson publicado en el ezine “QL Hacer’s Journal”. Como veis, el contenido no es de elaboración propia, yo sólo me he limitado a rescatar, traducir, mezclar, decorar y organizar la información que he encontrado.

Bueno, empecemos.

La teoría

La pantalla constituye el medio directo de comunicación del ordenador con el usuario, es lógico pues que dediquemos algún tiempo a conocer más de cerca este elemento tan cercano al programador.

Nuestro QL nos ofrece, ya nada encenderlo, dos posibilidades gráficas; una de ellas con mayor colorido pero menor resolución (256×256), mientras la otra nos ofrece la ventaja de una mayor resolución con 512 puntos horizontales (512×256) a la par que se pierden cuatro colores y la posibilidad de parpadeo.

De todas formas ambos ocupan una misma región de memoria del QL, la cantidad 32K (relativamente grandes para los ordenadores de esta generación). Son estos 32K y sólo ellos los que van a llevar toda la información que se nos ofrece en nuestros monitores. La conversión en imagen visual se realiza a través del conversor de vídeo, este elemento busca la información de cada punto en la memoria (en el momento que se necesite) para darle la tonalidad y contraste necesaria enviándola al monitor y que nosotros reconozcamos la figura claramente. A pesar de que a nosotros nos parezca al utilizar el ordenador que éste nos dedica todo su tiempo esto no es cierto. El microprocesador ha de hallarse constantemente interrumpiendo su labor hacia nosotros (BASIC) para representar la pantalla, manejar Microdrives, atender al teclado y otras muchas cosas que hace mientras nosotros inocentemente creemos estar con nuestro aparato tranquilamente ocupada en el BASIC. Nosotros no nos enteramos del tiempo ocupado en dichos menesteres porque el tiempo utilizado es mínimo para nuestra capacidad de percepción.

Pero volvamos a la memoria de pantalla, que es allí donde se van a definir todas las posibilidades gráficas del QL. Nosotros podemos acceder a toda la información contenida en la memoria de pantalla, así como podemos modificarla con solo “pokear” la zona correspondiente (o “peekear” para leer).

La zona de memoria de pantalla comienza en la dirección $20000, en decimal la 131072, y ocupa exactamente 32768 octetos de memoria RAM, es por esto por lo que de los 128K que lleva instalado nuestro QL de forma estándar, sólo son utilizables menos de 96K. Si multiplicamos estos 32768 bytes por 8 bits que contiene un byte nos dan 262144 en decimal, $40000 bits en hexadecimal. Luego en total disponemos de 262144 unidades mínimas de información, cada bit puede contener un sí o no, uno todo o nada. Luego en estas condiciones podríamos asignar dos colores, uno al si en un bit 1 y el otro al no 0, con lo que con 32K de memoria se podrían definir (si así lo hubiesen definido los diseñadores) 262144 puntos de pantalla. Los diseñadores de SINCLAIR no optaron por esta forma de estructurar la memoria de pantalla, sino por otra, en la que se utilizan cuatro colores. Con un mínimo de conocimiento binario se puede recordar que con dos bits podemos formar cuatro posiciones distintas jugando con los unos y los ceros 00, 01, 10, 11, con lo que con estas dos unidades podemos definir un punto de la pantalla en cuatro posiciones distintas o intensidades (que puede ser como en el QL en alta resolución el negro, rojo, verde y blanco).

Pues bien, si a cada punto dibujable (representable más bien) en la pantalla le asignamos dos bits, en los 262144 bits que disponíamos nos cabe la definición de 131072 puntos dibujables (dividir por dos), exactamente 512 filas por 256 columnas (512×256=131072). Pero además el QL viene dotado de otra resolución más baja, 256×256 puntos en ocho colores y posibilidad de parpadeo. En esta resolución cada punto representable debe hallarse en dieciséis posibles situaciones (negro, azul, rojo, magenta, verde, cian, amarillo, blanco, negro con parpadeo, azul con parpadeo, rojo con parpadeo, magenta con parpadeo, verde con parpadeo, cian con parpadeo, amarillo con parpadeo y blanco con parpadeo), que con bits se puede representar con cuatro (2e4=16, combinaciones de dos elementos “1” y “0” tomados de cuatro en cuatro), por lo que podemos representar 262144/4=65536 ($10000) puntos, es decir 256×256.

Por lo tanto, dependiendo de las combinaciones de unos y ceros en dos bits (alta resolución) o cuatro bits (baja resolución), aparecen en la pantalla los puntos en tonalidad e intensidades deseados. Ahora veamos cómo se colocan estos cuatro o dos bits en la memoria de pantalla.

La zona de memoria de pantalla comienza en la dirección $20000, y acaba en la $27FFF. Cada punto de la pantalla tiene situada su información en dos bytes diferentes y vecinos. Así en el modo de alta resolución cada dos bytes definirán ocho puntos (2×8/2). El primer bit de definición se hallará en el primero de los bytes, y el segundo en el segundo de los bytes. Así el primer punto de la pantalla (el de la esquina superior izquierda) vendrá definido por el primer bit el byte $20000, que seleccionará el color verde (1=verde), y por el primer bit del byte #20001, que seleccionará el color rojo. Si ninguno de ambos bits está activado el punto se hallará en negro, mientras que si se hallan ambos activados (“1”) estará en blanco.

El siguiente punto de la pantalla hacia la derecha viene definido por el segundo bit de los bytes $20000 y $20001 y así sucesivamente, cuando se completan los ocho bits del primer y segundo byte se pasa al primero del tercer y cuarto byte. De este forma los bytes pares contienen la definición del verde de un determinado punto, mitras lo impares del rojo. Cuando se completan los 512 puntos de una línea se pasa a la siguiente. Por lo tanto para localizar el byte en el que se halla de definición de un determinado punto hace falta realizar el siguiente cálculo:

– Punto definido por coordenadas “X” (horizontal) e “Y” (vertical) desde la esquina superior izquierda de la pantalla (0,0) y en puntos reales.

   byte par (verde)   = 131072 + Y * 128 + INT ( X / 8 ) * 2
   byte impar (rojo)  = 131072 + Y * 128 + INT ( X / 8 ) * 2 + 1
   posición del bit dentro del byte = 7 - (X - INT ( X / 8 ) * 8 )

Con estos cálculos podemos hallar la posición de memoria a pokear o leer. Por ejemplo, si deseamos poner en blanco el punto situado a 77 en vertical del origen (arriba) y a 405 en horizontal tendremos:

   byte par (verde)  = 141028
   byte impar (rojo) = 141029
   posicón bit = 2

Luego tenemos que poner el segundo bit de los bytes 141028 y 141029 a 1, con lo que pokeamos con una máscara de la siguiente manera:

   poke 141028, peek(141028) || 4
   poke 141029, peek(141029) || 4

Es decir, hacemos una operación lógica OR del valor 4 (en binario %00000100, el uno en el bit 2) con el contenido anterior, con lo que los bits que no son el bit 2 se quedan como estaban (0 OR 0 = 0, 0 OR 1 = 1), mientras que el bit2 se pone a 1 (0 OR 1 = 1, 1 OR 1 = 1) en los dos bytes, visualizándose dicho punto en color blanco.

Análogo razonamiento deberíamos realizar para la baja resolución, sólo que en esta modalidad cada dos bytes guardan la información de cuatro puntos (2*8/4). El razonamiento para hallar la colocación de un punto quedaría como sigue:

   byte par (verde)   = 131072 + Y * 128 + INT (X / 4) * 2
   byte impar (rojo)  = 131072 + Y * 128 + INT (X / 4) * 2 + 1
   posición del bit verde, rojo = 7 - (X - INT (X / 4) * 4)
   posición del bit azul, parpadeo = 7 - (X - INT (X / 4) * 4) + 1

Notar aquí que los bytes de verde y rojo se hallan en los puestos indicados en los bytes par (verde) e impar (rojo), seguidos inmediatamente de los bits de azul en el byte par y parpadeo en el impar.

Hay que tener cuidado con la utilización del byte de parpadeo pues es un caso muy peculiar. Se pone a uno este bit en alguno de los puntos, dicho punto, así como el resto de la línea derecha hasta el final derecho de la pantalla si no se halla otro bit de parpadeo encendido, se pondrá a parpadear. Así pues el parpadeo se activa desde el punto hasta el siguiente con dicho bit a uno.

Hay que tener mucho cuidado al trabajar con la memoria de pantalla ya que un error de cálculo nos podría llevar a la memoria situada encima de esta zona, que contiene ciertas variables del sistema que al ser alteradas pueden hacer fallar el sistema del ordenador con un consiguiente descontrol del mismo. Esto podría pasar cuando cargamos una pantalla con lbytes y por error lo que cargamos excede de los 32K.

El control de la memoria de pantalla es muy útil sobre todo para la programación en lenguaje máquina, ya que las rutinas que trae el sistema operativo son de carácter muy general, teniendo que contemplar muchos casos particulares con el retardo que esto conlleva. También, los métodos expuestos anteriormente son la base de los comandos del SuperBASIC para el manejo de gráficos en la pantalla.

Un ejemplo práctico
Existen diversidad de rutinas para el tratamiento de la pantalla del QL, prácticamente la totalidad de ellas están escritas en ensamblador por razones de eficiencia.

Con el fin de ilustrar el uso de la pantalla del QL veremos a continuación un programa extraído de la ezine “QL Hackers Journal” de Timothy Swenson.

La finalidad de este pequeño ejemplo es guardar en memoria una zona de una ventana de pantalla para luego recuperarla y pintarla en cualquier otro lugar. Aunque en un programa real estas funciones escritas en SuperBASIC son excesivamente lentas, nos sirven sin embargo para asentar lo que hemos estudiado en este artículo. Además podrían utilizarse como idea base si quisiéramos portar este programa al lenguaje C o al lenguaje ensamblador para un uso real. Esta versión en SuperBASIC es más instructiva a la hora de comprender y testear el algorítmo como paso previo a su versionado en leguajes más eficientes para este tipo de tareas como es el caso del lenguaje ensamblador.

El programa es muy simple de seguir, a continuación mostramos su código fuente y unas capturas de pantalla de los resultados.

100 CLEAR
110 REMark --- Vector para almacenar pantalla
120 DIM store(5000)
130 :
140 REMark --- Cargar pantalla
150 LBYTES flp1_sys_cheetah_scr, 131072
160 :
170 REMark --- Guardar ventana
180 save_bg 120, 100, 360, 20
190 :
200 REMark --- Crear nueva ventana
210 OPEN #3, con_120x100a360x20_32
220 PAPER #3,0: INK #3,7
230 CLS #3
240 PRINT #3,"This is a test"
250 PRINT #3,"of real windows"
260 PAUSE 50
270 CLS #3
280 PRINT #3,"Hit Return"
290 PRINT #3,"to make this"
300 PRINT #3,"go away"
310 INPUT #3,in$
320 CLOSE #3
330 :
340 REMark --- Restaurar ventana
350 load_bg 120, 100, 360, 20
360 :
370 REMark --- Pintar fondo ventana en
380 REMark     varios lugares para demo
390 PAUSE 250
400 CLS:CLS#0:CLS#2
410 load_bg 120, 100, 0, 0
420 load_bg 120, 100, 80, 40
430 load_bg 120, 100, 200, 80
440 PAUSE 250
450 :
460 STOP
470 :
480 :
490 REMark ------------------------------------------
500 REMark   Procedimientos para guardar
510 REMark   y recuperar fondo de ventanas
520 REMark ------------------------------------------
530 :
540 DEFine PROCedure save_bg (length, height, x, y)
550   LOCal   mem, i, j
560   mem = 1
570   FOR i = 131072+(y*128) TO 131072+((y+height)*128) STEP 128
580     FOR j = i + (x/4) TO i + ((x+length)/4) STEP 2
590          store(mem) = PEEK_W(j)
600        mem = mem + 1
610      END FOR j
620   END FOR i
630 END DEFine save_bg
640 :
650 :
660 DEFine PROCedure load_bg (length, height, x, y)
670   LOCal   mem, i, j
680   mem = 1
690   FOR i = 131072+(y*128) TO 131072+((y+height)*128) STEP 128
700     FOR j = i+(x/4) TO i+((x+length)/4) STEP 2
710       POKE_W j,store(mem)
720       mem = mem + 1
730     END FOR j
740   END FOR i
750 END DEFine load_bg
Imágen, fondo de pantalla

Imágen, fondo de pantalla

Fondo, con ventana almacenando fondo de ventana

Fondo, con ventana almacenando fondo de ventana

Réplica de fondo de ventana

Réplica de fondo de ventana

Fuentes.
————
– Revista QLave, “La Pantalla del QL”, Javier Boira.
– QL Hacer’s Journal, Timothy Swenson


Autor: Dilwyn Jones
Traducción y adaptación: afx

A raíz de nuestro anterior artículo (“Dispositivos DEV y el uso del comando DEV_USE” en la Gold Card) para adaptar el software antiguo a que se ejecute desde subdirectorios en discos duros o en discos de alta densidad, yo presentaré la segunda parte de este tratado de los dispositivos DEV. Esta vez mostraré cómo poner en práctica un mecanismo para simular las facilidades del PATH en un PC.

Esto significa que puedes teclear LOAD ‘miprograma’ sin tener que recordar o establecer el nombre del subdirectorio donde se encuentra ‘miprograma’. ¡Esto es fantásico! Pero entonces ¿por qué alguien no nos ha hablado de esto antes?

Básicamente, se necesita la combinación de dos facilidades disponibles en las tarjetas Gold Card. Normalmente solo funcionará con software que usan las facilidades de directorios por defecto DATA_USE o PROG_USE del Toolkit 2. El BASIC es un buen ejemplo de esto, puedes hacer un excelente uso de esta facilidad solo con el uso de los comandos LOAD o EXEC. Ten mucho cuidado con el uso de SAVE ya que podrías no saber dónde se ha guardado exactamente un fichero.

El manual de la Gold Card explica que mediante el uso de un tercer parámetro en el comando DEV_USE, puedes crear una cadena enlazada de nombres de dispositivos DEV. Así que, si intentas cargar un programa o archivo desde DEV1_ y falla, también se intentará cargar desde el nombre de dispositivo DEV2_ y así sucesivamente. Ahora, si hacemos que los valores de directorios por defecto del Toolkit2 apunte un dispositivo DEV, nosotros podemos hacer que el sistema mire a través de 8 directorios para encontrar el archivo que queremos.

El ejemplo siguiente es sólo un ejemplo sencillo que podrás adaptar a tus requerimientos. El ejemplo presupone el uso de un disco duro (dispositivos WIN) pero puedes adaptarlo al uso de otros dispositivos como una disquetera (sustityendo WIN por FLP). En este ejemplo muestro el encadenamiento de 7 subdirectorios para los programas de uso común.

100 REMark uso de DEV con subdirectorios
110 REMark esto emula la facilidad del PATH en el PC
120:
130 REMark se puede establecer una cadena de hasta 8
135 REMark directorios
137 :
140 REMark adáptalo a tus necesidades
150 DEV_USE 1,WIN1_,2
160 DEV_USE 2,WIN1_QUILL_,3
170 DEV_USE 3,WIN1_ARCHIVE_,4
180 DEV_USE 4,WIN1_ABACUS_,5
190 DEV_USE 5,WIN1_EASEL_,6
200 DEV_USE 6,WIN1_PERFECTION_,7
210 DEV_USE 7,WIN1_TEXT87_,8
220 DEV_USE 8,WIN1_BASIC_
230 :
240 REMark hacer uso de los defaults del Toolkit 2 
245 REMark a través de la cadena DEV's
250 DATA_USE dev1_
260 PROG_USE dev1_
270:
280 REMark cargar ahora con LOAD myprog or EXEC archivo
290 REMark ... se carga aunque esté escondido en algún dir.
300 REMark solo funciona con software que chequea los 
305 REMark defaults de Toolkit 2

Supongamos que intentas cargar el programa WIN1_BASIC_myprog_bas, pero no recuerdas donde lo habías grabado. Puedes usar LOAD ‘myprog_bas’ para después ejecutarlo. El QL intenta cargarlo pero fallará, normalmente dándonos el error ‘not found’. Pero antes de esto el QL añade el “default” del ToolKit 2 e intenta cargarlo otra vez como LOAD DEV1_myprog_bas. Esto debería ser lo mismo que LOAD WIN_myprog_bas. Sin embargo, si el fichero no se encuentra allí, LOAD debería renunciar, pero el QL identifica que hay un enlace desde DEV_1 a DEV2_

Ahora intenta cargarlo como WIN_quill_myprog_bas. ¡Y falla otra vez! Pero hay otro enlace al directorio “Archive”, así que el QL lo intenta en WIN1_archive_myprog_bas. Esto vuelve a fallar, así que trata de recorrer todos los eslabones hasta WIN1_basic_myprog_bas donde finalmente lo logra.

Podrías pensar que la búsqueda por varios directorios puede ser lento. Esto no es tan malo en discos duros o en discos ED, pero puede ser excesivamente lento si se accede a unidades de disco que no contienen el disquete introducido (en mi sistema además hace un terrible ruido intentando acceder al disco ¡No sugiero que lo intentes!).

La respuesta sencilla al problema de la velocidad de búsqueda es poner los subdirectorios usados más frecuentemente al inicio de la lista. Si los dos mayores usos que haces de tu QL es utilizarlo como procesador de textos y para la programación en SuperBasic, haz los ajustes en las especificaciones de DEV1_ y DEV2_.

Puede que te guste experimentar con DEV_USE ‘FLP’ como yo indiqué en mi artículo previo (“Dispositivos DEV y el uso del comando DEV_USE”) con programas que no soporten el “Default” del ToolKit 2, pero ten cuidado y procura salvar tus trabajos ¡Es muy fácil perder ficheros accidentalmente guardándolos en directorios equivocados!

Cuando yo lo experimenté, lo que hice para prevenir el riesgo de destruir los datos del disco duro fue el utilizar un disco ED formateado o un ramdisk con el controlador FLP o RAM renombrado como WIN mediante el uso de los comandos FLP_USE WIN o RAM_USE WIN.

Creé los directorios necesarios para las pruebas con el comando MAKE_DIR, copie unos cuantos ficheros dentro de ellos, y renombré el dispositivo con FLP_USE WIN o RAM_USE WIN. Por un momento, tuve por todas partes dispositivos renombrados, dispositivos que eran ignorados y “defaults” que apuntaban a una cadena de lugares. En ese memento me quedé totalmente confundido, aunque logré aprender lo suficiente para hacerlo funcionar ¡Lo que no me gustó es volverlo a desentrañar todo de nuevo!

Por favor, ten en cuenta la advertencia del manual de la Gold Card – “es fácil llegar a confundirse acerca de la configuración”. Se necesita tener la menta clara para hacer un seguimiento de lo que está pasando, así que si lo dudas, no uses esta facilidad a pesar que es potencialmente útil cuando se utiliza con cuidado.

Aunque esto es solamente utilizable en la Gold y Super Gold Card, los usuarios con otras interfaces como la Trump Card que no soportan los dispositivos DEV pueden usar las utilidades llamadas PATH u SUB escritas por el ex-presidente de Quanta Phil Borman. Éstas están disponibles en la librería de software de Quanta.

atari_st_aEn la primera década de existencia del QL (1984 a 1994) el Atari fue la máquina más afín al Sinclair QL y donde se lograron las mejores emulaciones QL de la época. En algunos foros también se ha etiquetado al Atari ST como una máquina muy “camaleónica” debido a sus facilidades a la hora de emular otras plataformas. Además de la emulación del Sinclair QL (donde el éxito fue bastante menor), adquirió bastante relevancia la emulación del Mac original. Sus promotores consideraban que se conseguía, por un precio más barato, una máquina tan potente como la máquina original. Además de las posibilidades de emulación, el hardware del Atari jugó un importante papel en la evolución del QDOS como el SMS y SMSQ/E.

Todo esto viene a cuento porque hace unas semanas compré una ampliación para mi Atari STe. Se trata de la tarjeta SuperSatanDisk con la que podemos dotar de un “disco duro” a nuestro Atari ST empleando tarjetas SD (ver hilo en http://www.zonadepruebas.com/modules/newbb/viewtopic.php?topic_id=6490&forum=2&post_id=49212#forumpost49212). La mencionada tarjeta es una pequeña joya par la ampliación de un ST, pero eso es otra historia (prepararé otro post más adelante relatando mi experiencia con ella).

Uno de mis objetivos con esta ampliación era poder transformar mi Atari en un sistema QDOS, además de poder disfrutar, por supuesto, de la gran biblioteca de software escrita para la gama ST de Atari.

El primer paso para conseguir el objetivo de convertir mi Atari en una máquina QDOS fue, obviamente, buscar información en Internet. De lo que he podido encontrar, destaco 4 alternativas descritas a continuación. De esas alternativas, la única que parece más viable es la última que describo (SMSQ/E para Atari), ya que el resto o bien no se producen en la actualidad o no tienen las prestaciones suficientes para un uso real de un sistema compatible con el Sinclair QL.

1) Strong QL/Atari emulator.

Este emulador consistía en un placa conectable al Atari que también era conocida como placa emuladora “Futura Data Centre QL emulator” para Atari ST. Fue desarrollado inicialmente por la empresa Noruega Futura Data Centre, cuyo nombre no tiene nada que ver con otro proyecto llamado Futura que era un derivado del QL.

El emulador completo consistía en un kit formado por un adaptador hardware, un disco con formato Atari que contenía ficheros relevantes para convertir el Atari ST en modo QL y un disco con formato QL que contenía una rutina para extraer la ROM del QL y transferir el QDOS desde el QL al disquete con formato Atari.

El emulador hardware consistía en una pequeña tajeta con circuitos impresos que se montaba y desplazaba al chig Shifter, una ULA QL 8301 y varios chis TTL. La instalación de la tarjeta requería la retirada del blindaje metálico interior del Atari. La conexión al ST se hacía con solamente siete cables pero dos conexiones al chip GLUE del Atari debían ser modificados para permitir al software conmutar entre el “modo Atari” y el “modo QL”.

2) Tarjeta Merz QVME

La tarjeta QVME es una tarjeta basada en el bus VME (para el Atari STE y la serie TT) que contenía una emulación completa del QL. Esta tarjeta emula a un QL estándar donde la resolución de la pantalla era programable (en tiempo de ejecución), por ejemplo, 1024×830 o 1280×700. La tarjeta simplemente se conectaba en el bus VME de los STe o TT. Para el uso en un ST estándar se necesitaba un adaptador extra. La tarjeta tenía un conector de monitor para conectar el Atari directamente a un monitor multisync. La tarjeta QVME no podía usar monitores monocromo. Tenía también un “modo de compatibilidad” para el uso de programas que escribían directamente en la pantalla del QL (es decir, el área RAM que representa la salida a pantalla del QL). Se podían usar 4MB de la RAM del Atari para el QDOS. Además todos los dispositivos del Atari eran usables por el QDOS, por ejemplo, las unidades de disco, puertos serie, puertos paralelo, el puerto del ratón y discos duros. Debido a diferencias en el hardware, la red del QL no está soportada en la emulación. Los controladores de dispositivos ofrecían opciones adicionales, por ejemplo, subdirectorios reales en el disco duro, canalizaciones, etc. El software de emulación estaba en un disco y debía cargarse en el Atari (esto significaba que también se podía usar el Atari como tal).

3) QLem

QLem es un emulador software para ciertas máquinas de la serie Atari ST. El emulador es obra de Johan Klockars y es un programa freeware que puede ser descargado de la dirección http://www.devili.iki.fi/pub/emulators/Sinclair/QL/. QLem viene acompañado de un volcado de la ROM JS del QDOS y del programa QL2ST que consiste en una utilidad con dos funciones fundamentales, inicializar discos en formato QL y convertir ficheros en discos con formato QL a discos con sistema de ficheros TOS de Atari. QLem se puede ejecutar tanto en monitor y resolución monocromo como en los monitores y resoluciones en color del Atari. Se soportan disquetes TOS/DOS pero sólo a nivel de directorio raíz. Parcialmente se implementa la emulación de un puerto paralelo (PAR), una segunda unidad de disco y emulación del Joystick.

4) SMSQ/E para ATARI ST, STE, TT

La última de las posibilidades de “emulación” es SMSQ/E. He puesto emulación entre comillas porque realmente no se trata de un emulador sino de la versión del sistema QDOS más avanzada que corre de forma nativa en el hardware de Atari.

SMSQ/E puede convertir cualquier ordenador Atari basado en el motorola 68000 (excepto el Falcon030 y el Atari ST Book) en un sistema en el que se puede ejecutar la mayoría del software escrito para el QL. Además el sistema da soporte a gran cantidad de hardware adicional integrado en el Atari, tal como:
– Soporte de discos duros ACSI & SCSI
– Soporte de discos removibles SyQuest
– Lectura y escritura de particiones de discos duros TOS
– Dispositivos de pueto paraleleo (PAR)
– Hasta 4 puerots serie (SER)
– Se soporta muchas tarjetas aceleradoras (HyperCache, HyperCache 030, PAK etc.)
– Soporte de FAST RAM (TT)
– Driver de dispositivos MIDInet y MIDI

SMSQ/E emula la pantalla de 640×400 en monocromo porque esta es la única resolución mayor o igual que los 512×256 del QL. Se puede usar la resolución completa incluso desde el BASIC. Si se requiere mayor resolución o mayor compatibilidad se puede utilizar hardware adicional que da soporte nativo a la organización de pantalla del QL original, las posibilidades son las siguientes:
– “QL Emulator original”: sólo para el ST y Mega ST. Requiere el chip de video ZX8301 del QL. Emula resoluciones de 512×256 en 4 colores y 256×256 en 8 colores.
– “QL Emulator extended”: sólo para ST y Mega ST. No requiere del ZX8301 y da resoluciones de 512×256 en 4 colores y 768×280 en 4 colores. Pude ser conectada a monitores QL originales.
– QVME: placa conectable el bus VME del Mega STE y TT. Es enteramente programable y soporta modos desde los 512×256 hasta 1280×900 en múltiplos de 8 pixels. Las frecuencias horizontales y verticales son también programables.

Q-Trans es un programa que viene incluido en el paquete LaunchPad de Dilwyn Jones, pero que puede ser usado de forma autónoma.

Básicamente es el programa típico para la gestión de ficheros donde podemos copiar, mover, renombrar, borrar ficheros, etc de forma cómoda e intuitiva. Posee además interesantes opciones para la búsqueda de ficheros; estadísticas de archivos y dispositivos de almacenamiento; y la posibilidad de ejecución de programas desde el propio entorno.

Tiene una interesante gestión de una especie de “papelera de reciclaje” desde donde podemos recuperar ficheros que hayamos borrado por error.

El programa funciona bajo PE (el entorno de ventas del QL) y la navegación por unidades y subdirectorio es muy cómoda. Hay disponibles dos versiones, la versión 1 para sistemas antiguos, y la versión 2 para sistemas que soporte Window Manager 2 – SMSQ/E version 3.0 o superior. El programa consta de un solo ejecutable y viene acompañado de un completo manual en formato _doc de Quill.

Personalmente lo encuentro mucho más cómodo y útil que el gestor de ficheros de QPAC II.

A continuación os pongo algunas pantallas:

QTrans-a

QTrans-b

QTrans-c


Autor: Dilwyn Jones
Traducción y adaptación: afx

Muchos usuarios actuales del QL tienen ahora acceso a los directorios de nivel 2 en sus sistemas, ya sea bien a través de discos duros o mediante el uso de un sistema con disqueteras HD o discos ED. Es bastante fácil instalar el software en estos discos organizados en directorios para asegurarnos que los discos individuales o unidades de disco duro no se llenen de masas de pequeños programas en el directorio raíz. Pero muchos programas QL fueron escritos para usuarios que no tenían disco duro o sistemas de directorios de nivel 2, y muchos de ellos no ofrecen la posibilidad de trabajar con sub-directorios. El manual de la Gold Card nos sugiere una forma de hacer que estos antiguos programas sigan funcionando mediante el empleo de dispositivos DEV y el comando DEV_USE, pero esto no es muy obvio debido a que las indicaciones están ocultas en medio de los detalles de las distintas opciones disponibles. Es conveniente leer primero las notas sobre los dispositivos DEV en el manual de la Gold Card, luego leer este artículo y probar los ejemplos que se ofrecen más abajo.

El uso es simple, copia los ficheros de los programas dentro de un subdirectorio, a continuación usa el comando DEV_USE para asignar los directorios predeterminados y, finalmente, cambia el nombre del dispositivo DEV para que responda a los dispositivos habituales como FLP1_ y FLP2_ que son reconocidos por la mayoría de los programas. En otras palabras, “mágicamente” esto hace que el software funcione desde un disco duro o desde un subdirectorio sin tener que actualizar o cambiar los programas que no están preparados para el uso de subdirectorios.

Tomemos como ejemplo el procesador de textos Quill. Dado que los usuarios de Quill tienden a generar una gran cantidad de archivos de texto, sería deseable poder colocar los archivos del propio Quill dentro de su propio ‘slot’ o ‘carpeta’ en la unidad, de modo que la relación extensa de archivos de texto esté en otra localización y no se mezclen con los archivos del programa. Para ello podemos crear 2 directorios de la siguiente manera:

    MAKE_DIR WIN1_QUILL_

Los ficheros de Quill los colocaremos en este directorio, WIN1_QUILL_ (los dispositivos WIN corresponden al disco duro de un sistema QL). Luego podemos crear un sub-directorio para almacenar los ficheros de texto.

 
    MAKE_DIR WIN1_QUILL_DATA_

Por lo tanto nuestros archivos de texto pueden ser guardados al estilo de WIN1_QUILL_DATA_carta1_doc, por ejemplo. Pero ¡NO!, ¡Quill no te permitirá ficheros con nombres largos de esa manera! Aquí es donde el dispositivo DEV viene al rescate.

Básicamente, lo que hacemos ahora es dejar que el software siga funcionando por sí solo como siempre lo ha hecho y que crea que se sigue cargando y guardando datos desde FLP1_ y FLP2_. Sin embargo, el QL cambiará automáticamente estos nombres para que redirigirlos a WIN1_QUILL_ y WIN1_QUILL_DATA respectivamente, ofreciendo una forma automática y sencilla de utilizar directorios con el mínimo esfuerzo por parte del usuario sin la necesidad de hacer cambios difíciles de software que no está preparado para trabajar con directorios.

Mediante los dispositivos DEV y el comando DEV_USE podemos hacer creer a nuestros programas que están colocados en los FLP1_, FLP2_, MDV1_, MDV2_ (o cualquier otro dispositivo) aunque ellos estén alojados físicamente en un subdirectorio particular.

Siguiendo nuestro ejemplo, podemos establecer dos dispositivos DEV, uno para acceder al programa, a los archivos de ayuda, al controlador de la impresora y cosas así; y el otro para los ficheros de datos. Asumiendo que tenemos configurado Quill para cargar los archivos de ayuda desde FLP1_, para acceder a sus archivos DAT de los controladores de impresora desde FLP1_, y para cargar y guardar archivos a y desde FLP2_, tendríamos que asignar los directorios de la siguiente manera.

100 DEV_USE 1, WIN1_QUILL
110 DEV_USE 2, WIN1_QUILL_DATA
120 DEV_USE 'FLP'

Por lo tanto, cada vez que le dices a Quill que guardare un archivo como ‘FLP2_micarta_doc’ realmente lo está convirtiendo en WIN1_QUILL_DATA_micarta_DOC. Cada vez que le pides a Quill que liste los archivos de FLP2_, realmente la lista de archivos se está extrayendo de WIN1_QUILL_DATA_.

Tendrás que hacer un pequeño programa en Basic como este para cada programa al que le quieras reasignar sus unidades, pero esto supone bastante menos trabajo que modificar u obtener versiones actualizadas (si las hubiera) de todos tus programas que no funcionen de forma adecuada con sub-directorios. Úsalo en un programa boot de tu aplicación (renombra el boot normal del programa como ‘boot2’ por ejemplo, y salva este como el BOOT de tu programa en un direcotorio relevante).

NOS QUEDA UN PROBLEMA. ¡Ahora no podremos usar los discos flexibles! Cualquier referencia a FLP1_ y FLP2_ automáticamente el sistema nos estará redirigiendo al disco duro. La solución es renombrar los dispositivos floppy también. Esto no debería ser un problema grave en el sistema que hemos descrito ya que los disquetes se usan muy poco en un equipo con disco duro. Para hacer esta reasignación usaremos el comando FLP_USE ‘fdv’ para renombrar los discos FLP a FDV (FDV al estilo de los MDV de los microdrives). Así accederemos a las unidades de disquete usando FDV1_ y FDV2_ en lugar de FLP1_ o FLP2_.

Esto es algo que lleva algún tiempo comprender y dominar, pero no se puede explicar de una forma más simple. Es obvio que habrá excepciones, los programas que no funcionan, por ejemplo, programas de Microdrive protegidos y algunos programas que necesiten más de dos DEVS instalados, pero al menos esto es un ejemplo de trabajo que muestra lo simple que puede ser. ¡Oh sí!, no te olvides de restablecer los dispositivos después de usar el programa con el comando DEV_USE ‘dev’ y, posiblemente, FLP_USE ‘FLP’ si los habías cambiado también.

(NOTA: Asegúrate de restablecer la configuración a la normalidad cuando dejes de usar el programa en cuestión.”DEV_USE” por sí mismo, cancelará cualquier asignación DEV que hayas hecho. El no cancelar esta configuración afectará al próximo programa que ejecutes.)