archivo

Archivos Mensuales: marzo 2014

Conversor HDMI a VGA

Conversor HDMI a VGA

Dando una vuelta más de tuerca a este conversor de Scart a HDMI, ahora he podido  conectar mi QL a un monitor VGA.

El mecanismo es “un poco ortopédico” 🙂 , pero funciona a modo plug & play sin tener que manipular cables ni componentes electrónicos. Básicamente consisten en emplear un camino de “ida y vuelta”, pasar la señal analógica a digital (con el conversor Scart a HDMI) y luego a la inversa de digital a analógica (conversión HDMI a VGA).

Ya comentamos el tema del conversor Scart a HDMI en otra entrada del blog. Ahora he adquirido en eBay este otro conversor para poder conectar la salida HDMI a VGA (el precio e bastante asequible, 7.5 dólares incluido gastos de envío).

La calidad de la imagen es bastante buena, pongo más abajo algunas fotos de mi pantalla plana VGA conectada al QL (las fotos son de mala calidad, en la realidad la imagen es más nítida). Sólo decir que en uno de mis monitores (Acer) el color blanco se convertía en magenta, pero en mi segundo monitor (LG) la imagen es muy aceptable.

Esto debería ir bien también en otros equipos retro.

Ejemplo salida VGA (QL - monitor LG)

Ejemplo salida VGA (QL – monitor LG)

Ejemplo 2 salida VGA (QL - monitor LG)

Ejemplo 2 salida VGA (QL – monitor LG)

Conversores encadenados

Conversores encadenados

Anuncios

El concepto de Variables de Entorno viene del mundo UNIX. Se utilizan también en MS-DOS pero de forma más limitada y no en la misma medida. Para el mundo QDOS, el archivo ENV_BIN proporciona una serie de extensiones que permiten el uso de Variables de Entorno en el Sinclair QL.

Si queremos disponer de estas facilidades debemos cargar previamente dicha extensión en nuestra sistema. Para ello basta con añadir en nuestro boot una línea similar a la siguiente (*):

100 LRESPR flp1_env_bin

(*) Notas:
– LRESPR requiere Toolkit 2
– La extensión ENV_BIN se puede obtener en la sección de Toolkits del sitio de Dilwyn Jones.

En esencia, una variable de entorno es una variable que puede ser “vista” por los programas ejecutables. En SuperBASIC podemos crear todo tipo de variables, pero si ejecutamos un programa desde SuperBASIC, estos programas no pueden “ver” dichas variables ni obtener datos de ellas.

El objetivo de las variables de entorno suele ser el cambiar la configuración de un programa. Estas variables funcionan como los “Bloques de Configuración” en QDOS, pero no requieren de la ejecución de un programa externo para hacer cualquier cambio en sus valores.

Echemos un vistazo a cómo podemos cambiar el comportamiento de los programas. Hay cinco maneras diferentes de hacer esto:

1] Intervención del usuario. Mediante esta estrategia, el usuario utiliza un menú o responde a las preguntas del programa.

2] Bloques de Configuración (Config Blocks). Esta característica es peculiar del QDOS y permite al usuario cambiar las opciones por defecto sin tener que saber cómo editar un archivo binario.

3] Fichero de Configuración. Este es un archivo separado que el programa lee para determinar cómo establecer los valores predeterminados para su ejecución.

4] Argumentos por la Línea de Comandos. En lugar de que el programa pregunte la de información al usuario, el usuario escribe dichos valores cuando ejecuta el programa desde la consola utilizando parámetros adicionales.

5] Variables de Entorno. El usuario establece una variable que luego es leída por el programa para cambiar su configuración predeterminada.

Cada una de las opciones tiene su propio lugar, sus ventajas y sus defectos. Algunas son más permanentes, como los Bloques de Configuración y los Archivos de Configuración, mientras que las otras opciones son más volátiles, como la “Intervención del Usuario” y de los “Argumentos por la Línea de Comandos”. Las “Variables de Entorno” se encuentran entre las opciones que se pueden establecer en el BOOT (arranque del sistema), o en un programa cargador, pero se pueden cambiar con solo teclear en un nuevo comando. El fichero ENV_BIN viene con 4 extensiones. Éstas son:

SETENV     - Define una variable de entorno.
ENV_LIST   - Lista todas las variables de entorno definidas.
ENV_DEL    - Elimina una variable de entorno.
GETENV$    - Obtiene el valor de una variable de entorno.

Los dos comandos más relevantes son SETENV y GETENV$. SETENV se usa de esta forma:

SETENV "VARIABLE=valor"

SETENV toma un argumento de cadena del tipo “XXXXX=YYYYY”, donde XXXXX y YYYYY son dos cadenas separadas por un signo igual. Cualquier espacio antes del signo igual es tratada como una parte de XXXXX y un espacio después del signo igual es tratada como una parte de YYYYY. El nombre de la variable es sensible a mayúsculas y minúsculas, así “VARIABLE” es diferente de “variable”. Por convenio, las mayúsculas se utiliza como nombre de las variables de entono. El comando SETENV se puede ejecutar en el programa de inicio del sistema -BOOT- (el cual podría ser alterado por un programa instalador), o bien directamente por el usuario. El comando para que un ejecutable obtenga el contenido de una variable de entorno es GETENV$. El comando se usa así:

a$ = GETENV$("VARIABLE")

En este caso, a$ se le asignará el valor de “valor” establecido en nuestro ejemplo por la instrucción SETENV anterior. Si la variable de entorno “VARIABLE” no está definida (no existe), entonces la función GETENV$ devolvería una cadena vacía (“”).

Hemos dicho que los ejecutables usan GETENV$ y no los programas SuperBASIC. Como las variables se utilizan ya de forma ordinaria en el entorno SuperBASIC, no ganaríamos mucho en el uso de variables de entorno (a no ser que pretendamos obtener algún valor preestablecido de forma personalizada en nuestro sistema). Por esto hemos destacado que el uso mayor de estos comandos es en los programas SuperBASIC compilados, que son ejecutables.

Vemos que el propósito de utilizar Variables de Entorno es la adición de flexibilidad para los programas que utilizan bloques de configuración. Ambos, Bloques de Configuración (Config Blocks) y Variables de Entorno se han diseñado realmente para cambiar la configuración predeterminada de los programas. La “Intervención del Usuario” y los “Argumentos por la Línea de Comandos” están diseñados para indicar al programa algunos datos adicionales. El uso de Variables de Entorno permite al usuario la posibilidad de hacer un cambio temporal en las opciones por defecto de un programa, sin tener que pasar por la molestia de usar “config”. Las variables de entorno se utilizan para cambiar una configuración para una sola sesión y ya está.

No es difícil el uso de los “Bloques de Configuración” y las “Variables de Entorno” en conjunción de tal forma que sean complementarias. El programa obtendría primeramente su configuración por defecto del Bloque de Configuración (Config Block). A continuación, se comprueba si hay variables de entorno establecidas. Si hay, entonces los valores de configuración de las Variables de Entorno reemplazan los valores de configuración definidos en los Bloque de Configuración.

 

Fuente:

Artículo original: http://dilwynjones.topcities.com/qhj/qhj/qhj28.txt

Timothy Swenson
Artículo aparecido en QL Hacker’s Journal

Traducción:
Afx
Septiembre de 2009

Este artículo presenta una pequeña función muy útil para el uso con el escalado de gráficos en el BASIC del QL. Ésta pequeña función debería trabajar tanto en SuperBASIC como en SBASIC.

Recientemente estaba escribiendo un programa que necesitaba del uso de POINT, LINE y otros cuantos comandos gráficos que usan el sistema de coordenadas gráficos del BASIC. Yo necesitaba estar en condiciones de poder escalar gráficos para encajarlos en la pantalla completa, independientemente de la resolución de la pantalla.

Los sistemas QL modernos ofrecen una variedad de formas y proporciones de pantalla, por ejemplo, el QL estándar tiene una resolución de 512×256 y los sistemas Q40/Q60 1024×512. Ambos tienen una proporción de 2:1 píxeles de pantalla. Pero un sistema QXL se ejecuta en modo SVGA con resoluciones de 800 por 600 pixels, esto es una ratio de 4:3 en lugar de 2:1. Un sistema Aurora ofrece un sistema de resolución tipo EGA 650×350, también el QPC ofrece resoluciones similares, lo cual viene a ser una proporción aproximadamente de 2:1 (sólo aproximadamente).

A modo de referencia, aquí se muestran algunas de las resoluciones gráficas más comúnmente usadas de varios tipos de sistemas que yo he usado. Notarás que en esta lista no se incluyen los emuladores como QLay, QemuLator y QDOS Classic dado que yo no tengo suficiente conocimiento de esos tipos de sistemas para poderlos incluir en esta lista.

Ancho    Alto    Ratio    Tipo de sistema
-----------------------------------------
 256     256      1:1     QL en modo 8
 512     256      2:1     QL en modo 4
 512     384      4:3     QPC, Aurora
 640     350  aprox. 2:1  modo EGA en QXL, Aurora, QPC
 640     480      4:3     modo VGA en QXL, Aurora, QPC
 768     280      2.74:1  Extendido 4 en ST-QL
 800     600      4:3     SVGA sobre QXL, QPC etc
1024     512      2:1     Q40/Q60, QPC
1024     768      4:3     XGA sobre QPC

Figura 1.

Cuando se define una ventana, el sistema le asigna un SCALE con valor 100 en la dirección del eje vertical, estableciendo el punto de origen en la coordenada 0,0 situado en la esquina inferior izquierda. Es menos fácil de predecir el número de puntos en el sistema de coordenadas que existirán en la dirección horizontal – una ventana que es cuadrada es en términos de número de píxeles no es cuadrada en términos de de coordenadas gráficas.

Esto nos provoca un problema, si utilizamos LINE, CIRCLE, ELLIPSE, etc. para dibujar formas o figuras y dichas formas no caben en la ventana en cuestión, parte de la figura se dibuja fuera de la ventana, aunque no se producen errores gracias a la forma en que los comandos gráficos del BASIC trabajan.

De hecho, existe una relación que no está muy bien documentada que, si se conoce la altura y anchura de la ventana y la escala vertical, nos permite predecir cuantos puntos en el sistema de coordenadas horizontal serán visibles dentro de la ventana en cuestión.

1000 DEFine FuNction X_Scale(y_scale,wide,high)
1010   RETurn 0.75 * y_scale * wide / high
1020 END DEFine X_Scale

Figura 2: Listado de la función.

La función toma tres parámetros. El primero (y_scale) es el número de puntos del sistema de coordenadas deseado en el plano vertical. A menos que lo cambies con el comando SCALE, tendrá normalmente el valor de 100. Si usas por ejemplo SCALE #1, 150,0,0 será de 150. El segundo parámetro es el ancho de la ventana en pixels (si estás usando la resolución del QL en modo TV la ventana #1 o #2 tendrán un ancho de 448, o 252 si usas el modo monitor del QL). El tercer parámetro es el alto de la ventana, normalmente 200 para ambas ventanas en ambos modos (TV o Monitor).

La linea 1010 usa esta información para calcular el número de puntos que le corresponden a eje horizontal. Ten en cuenta que hay una relación de 0,75 o 3:4 entre el eje horizontal y vertical. En otras palabras, sea cual sea la proporción de anchura de la ventana con respecto a la altura, el número de puntos visibles en el sistema de coordenadas horizonal es de 0,75 veces la parte visible del sistema de coordenadas verticales en esta proporción de píxeles.

Básicamente, habida cuenta de la forma de la pantalla QL, la introducción de un escalado como éste es necesaria a fin de que los círculos aparezcan realmente de forma circular dado que si dibujamos “círculos” con una proporción de 1:1 píxeles, éstos no aparecen como circulos en la pantalla del QL ya que los píxeles no son exactamente cuadrados.

Aquí hay un ejemplo simple del uso de esta fórmula. ¿Cuál sería el ancho máximo de una línea que cubra toda la pantalla? Estamos trabajando en una resolución de pantalla del QL de 512×256 y necesitamos dibujar un círculo en el centro de la pantalla. En el listado de la Figura 3 se muestra cómo podemos conseguirlo:

100 WINDOW 512,256,0,0 : CLS
110 x = X_Scale(100,512,256)
120 CIRCLE x/2,50,25
130 :
1000 DEFine FuNction X_Scale (y_scale,wide,high)
1010   RETurn .75 * y_scale*wide/high
1020 END DEFine X_Scale

Figura 3: Uso de la función para centrar un círculo en la pantalla

Bueno, esto podría parecer un gran alboroto para nada. En la realidad, llegar a esta fórmula, ha hecho más fácil para mí escribir programas con gráficos a escala que se ajusten al tamaño y forma de la ventana en cuestión. ¡Oh!, ¿qué programa era ese? Pues eran algunos de los módulos del protector de pantalla de mi programa LPsaver.

Esta rutina es actualmente una aproximación. Podrías encontrar errores, en parte debido a la simplificación de los cálculos realizados, al redondeo en las operaciones de punto flotante, etc, la escala real puede variar de con respecto a lo que indican la rutina, pero los resultados son lo suficientemente aproximados para la mayoría de los propósitos.

———-

Artículo original:  http://www.dilwyn.me.uk/docs/articles/scales.zip 

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

Traducción: Afx
febrero de 2009

 

Gary Kildall

Gary Kildall

Gary Kildall, uno de los miembros del equipo de Intel que desarrolló el microprocesador 8080, creo su primera versión del sistema CP/M en 1974 para apoyar a un compilaro para PL/M, el primer lenguaje de alto nivel que produjo Intel. En 1975 agregó un editor (ED), un ensamblador (ASM) y un debugger (DDT), o programa de depuración de programas de usuario. Le ofreció el nuevo sistema operativo a Intel, que lo rechazó, hecho que probablemente haya sido lo mejor que le puediera haber ocurrido a Kildall. Asociado con Dorothy McEwan, empezó a publicar revistas para aficionados y a vender el CP/M de forma particular. El CP/M de Kildall superó rápidamente en ventas a las revistas para aficionados.

Ya sea por el diseño o debido a un rotundo golpe de suerte, Kildall había dado con un sistema que solucionaba en gran medida el principal problema del microordenador en sus primeros años: el de la compatibilidad. Los tres ordenadores de mayor consumo más importante de finales de los años setenta (el PET, el Apple y el Tandy) tenían sistemas operativos de disco incompatibles, y los productores independientes de software tenían que optar por un formato u otro. El código debía escribirse por completo para lograr que un producto de software funcionar con una máquina diferente de aquella para la cual había sido diseñado. Pero el CP/M vino a cambiar completamente esta situación: su considerable popularidad significó que una gran mayoría de fabricantes comenzara a adoptarlo, creando por consiguiente un “estándar” de facto. Muchas firmas que habían elegido para sus máquinas los procesadores Intel 8080 o Zilog Z80 especificaron el CP/M porque ofrecía una fomra sencilla de manejar el acceso a pantalla, impresora, discos, etc. Su popularidad iba en aumento y cada vez se disponía de más software CP/M, lo que representaba un incentivo aún mayor para adoptarlo.

Mientras el CP/M se difundía, Digital Research se concentro en los sistemas para múltiples usuarios y produjo el MP/M. Éste estaba diseñado para ser compatible con el CP/M en todos los aspectos, si bien sus primeras versiones no compartieron nada el éxito del CP/M. El fraccionamiento de las áreas de usuario y otras configuraciones que el programador de sisteas pudiera necesitar hacer no eran en absoluto sencillas y en el tratamiento de archivos difería a veces del CP/M. No obstante, debido a que los costos de los microprocesadores iban disminuyendo a medida que iba aumentando la producción, la necesidad de que varios usarios compartieran un procesador ya no tenían una fuerte necesidad desde el punto de vista económico. Tal vez por esto el MP/M no logró hacerse popular.

Sede inicial de Digital Research, Massachusetts

Sede inicial de Digital Research, Massachusetts

Digital Research reunió fondos de varias empresas de inversión en 1981, para convertirse en una auténtica multinacional, con una presencia notablemente fuerte en Europa (donde llegó a tener oficinas en Gran Bretaña, Alemania y Francia). Aproximadamente al mismo tiempo, Digital Research fue una de las primeras compañías en asegurarse el contrato para desarrollar un sistema operativo para el recientemente diseñado Personal Computer de IBM. A pesar de que el contrato para el IBM-PC al final lo obtuvo Microsoft, Digital Research no salió para nada derrotada. Desde entonces actualizó el CP/M para los procesadores de Intel 8088/8086 para hacerlos similares al MS-DOS y también dio un nuevo paso adelante con el Concurrent CP/M.

El Concurrent CP/M es el opuesto del MP/M, permitiendo la ejecución simultánea de diversos programas en el mismo procesador. Con este sistema, un usuario podría trabajar en tres tareas diferentes al mismo tiempo (p. ej., hoja electrónica, generación de informes y correo electrónico) pasando de una a otra a voluntad. Las versiones existentes del Concurrent CP/M pueden visualizar simultáneamente cada pantalla (o parte de ella) utilizando una configuración de “ventana”. Nuevas versiones del Concurrent CP/M prometían ejecutar directamente la mayoría de los programas escritos para el IBM PC-DOS.

Entre las decisiones estratégicas que tomó Digital Research y muchas otras firmas de sistemas y lenguajes, fue la de concentrar todo su trabajo de desarrollo en el lenguaje C, que es especialmente notable por su portabilidad. El código escrito en C sólo debe ser recompilado para que pueda ser usado en otro procesador, aunque esta característica despertó críticas en cuanto a que se trataba de una codificación incómoda. Es mejor, razonaban sus detractores, hacer un trabajo adecuado en ensamblador para cada procesador individual. Sin embargo, el uso de C fue adquiriendo una creciente popularidad y puesto que el sistema operativo UNIX, tan ampliamente utilizado, estaba escrito en C, la tendencia hacia este lenguaje fue irreversible.

Digital Research fue ciertamente coherente con su idea de que la verdadera portabilidad solo era posible a través de lenguajes de alto nivel. Por ello, pasó a proporcionar varios lenguajes para una amplia gama de micros. En el extremo más bajo del mercado, sin embargo, Digital Research organizó un Departamento de Productos para el Consumidor que vendería su BASIC Personal, CP/M Personal y su propia versión de LOGO. El Personal CP/M, al igual que el CP/M-86, estaba diseñado para ser almacenados en ROM y pronto estuvo disponible también para el chip Z-80 en virtud de un acuerdo con Zilog.

Posteriormente Digital Research se embarcó en el desarrollo de VIP y GSX. VIP es un envoltorio que permite que quienes desarrollan programas puedan presentar una interface uniforme para el usuario, independientemente del paquete de aplicaciones que esté ejecutando. Varias aplicaciones podía compartir los mismos datos, y éstos podían ser transferidos de una a otra. En este sentido el VIP fue muy similar a la tecnología Lisa y Macintosh de Apple pero requería menos memoria. El VIP podía funcionar en cualquier ordenador con más de 50 Kbytes de RAM y equipado con 150 Kbytes o más de espacio de disco.

El GSX era destinado a ser para los gráficos lo que el CP/M fue para los discos. Utilizaba un juego estándar de funciones para gráficos que se podían emplear en una variedad de distintos elementos de hardware. GSX es una versión para microordenador del estándar gráfico GKS (relacionado con NAPLPS).

Más tarde, partiendo de GSX, Digital Research creó su propio GUI (Interfaz Gráfica de Usuario) llamada GEM (Graphical Environment Manager). GEM era un sistema de ventanas para ser usado con el sistema operativo CP/M sobre procesadores Intel 8088 y para el microprocesador Motorola 68000. Versiones posteriores funcionaban también sobre DOS para toda la familia x86.

GEM es conocido sobre todo por ser el entorno gráfico de usuario de la serie de ordenadores Atari ST, y fue también distribuido con una serie de ordenadores compatibles IBM PC creados por Amstrad (PC1512, PC1640 y Sinclair PC200). Fue el núcleo también para una pequeña cantidad de programas DOS, de los cuales el más destacado fue Ventura Publisher. También se portó a otros ordenadores que previamente no tenían interfaz gráfica, pero no llegó a ganar popularidad en esos sistemas.

Digial Research fue muy prolija también en el desarrollo de una amplia gama de compiladores e intérpretes de varios lenguajes de programación incluyendo C, Pascal, COBOL, Forth, PL/I, PL/M, BASIC, y Logo.

En 1991, Digital Research finalmente fue comprada por Novell, la cual pretendía extenderse en el mercado de los Sistemas Operativos con la experiencia de Digital Research en este campo.

——
Fuentes:
– Enciclopedia “Mi Computer”, fascículo 36. Editorial Delta, 1984
– Wikipedia, http://es.wikipedia.org/wiki/Digital_Research
– Wikipedia, http://es.wikipedia.org/wiki/Graphical_Environment_Manager

UltraQ es otro nuevo proyecto de desarrollo hardware para el Sinclair QL que está tomando forma “sobre el papel”. Es también una propuesta de Dave Park, con la colaboración de Nasta.

Se trata de una tarjeta “multifunción” para el Sinclair QL que incorpora una controladora de disquetes, interfaz paralelo, interfaz de ratón (QIMI), IDE, y su propia CPU con 4 MB de memoria adicional (al estilo de la Gold Card / Super Gold Card). En el apartado de firmware y software, la tarjeta vendrá con una versión personalizada de Minerva y posiblemente con una versión de SMSQ/E en una tarjeta CF.

UltimIDE (Ultimate IDE) es un nuevo proyecto hardware para el Sinclair QL en el que está trabajando Dave Park (de Sandy Electronic) con la colaboración de Nasta (un desarrollador hardware que estuvo detrás del diseño de Aurora y QubIDE).

UltimIDE es una interfaz IDE basada en la QubIDE, pero con componentes actuales y una nueva versión del driver para el sistema operativo.

Parece que ya tienen desarrollado un esquema preliminar y pronto tendrán los primeros prototipos.

Estas son algunas especificaciones provisionales:
– Interfaz IDE con soporte para dos dispositivos IDE.
– Una conexión en la placa para discos SSD.
– Una o dos ranuras CF. Se incluirá una tarjeta CF con los controladores, utilidades y SMSQ/E.

Disponibilidad prevista: mayo / junio de 2014

Enlaces a la noticia:
http://sinclairql.com/wp/?p=18
http://sinclairql.com/wp/?p=12

Urs Koenig pone a disposición de la comunidad su fantástica galería de imágenes relacionadas con el mundo QL. Hay 1979 imágenes en 84 carpetas de temática variada todas referentes al Sinclair QL y su historia. Esta distribución (todos los archivos) es de uso libre, pero con los términos de uso que expresa el autor el readme de su galería (ver este enlace para las condiciones de uso). Todas las imágenes son fotos o imágenes escaneadas realizadas por el propio Urs Koenig y sus amigos.

>> Enlace de la galería de imágenes QL.

(Imagen cortesía de Urs König), Sinclair QL Preservation Project (SQPP)

(Imagen cortesía de Urs König), Sinclair QL Preservation Project (SQPP)