SMSQmulator como plataforma de SMSQ/E
Publicado: Mié Feb 03, 2016 5:02 pm
El último mes he estado colaborando con Wolfgang Lenerz, con sugerencias, informes de error y una traducción nueva para SMSQmulator. Gracias a este emulador he podido volver a usar mi entorno QL, que tenía aparcado desde que migré a Raspberry Pi hace unos tres años, pues nunca he logrado ejecutar o compilar uQLx salvo en Intel, ni siquiera la versión específica para Raspberry Pi, que a otros sí les funciona.
SMSQmulator tiene varias ventajas respecto a QPC2 y Q-emuLator: no necesita instalación, es multiplataforma, usa un fichero de texto como configuración (que por defecto puede estar en el directorio del ejecutable)... Y su único requisito, facil de cumplir, es tener instalada una máquina virtual de Java.
Me estoy dando cuenta de que estas características hacen de SMSQmulator la plataforma ideal para desarrollar para SMSQ/E. pues es posible distribuirlo junto con el programa. El usuario solo tiene que descomprimir el archivo ZIP o TAR.GZ o lo que sea, y arrancar con un doble clic o un comando. El emulador leerá su fichero de configuración y arrancará desde un WIN, por ejemplo.
Para mejorar la experiencia, y que el emulador en sí sea invisible al usuario, es útil que el programa pueda tener algún control del emulador y conocimiento del entorno anfitrión. Por ejemplo, echaba en falta que desde SBASIC se pudiera leer el estado de la barra de menú del emulador, y Wolfang lo implementó tras sugerírselo. Entre las próximas sugerencias pendientes de enviar tengo que se pueda leer la resolución de pantalla del sistema anfitrión, con `host_xlim` y `host_ylim`, por ejemplo; y que si el tamaño de pantalla en el fichero de configuración es 0x0, se use el máximo disponible; con ello, el programa podrá saber el máximo tamaño real que pueden tener sus propias ventanas. Otra sugerencia pendiente es que el dispositivo de arranque sea configurable (un disquete IMG, o un directorio montado como NFA o SFA). El caso es que nuestro programa (aplicación, juego o lo que sea) tenga control completo y el usuario no necesite tener ningún contacto con el emulador ni con su configuración.
Cuando escribí la adaptación de la aventura de texto Asalto y castigo para QL, y a pesar de haber incluido instrucciones de uso que me parecían claras y detalladas, tuve que solucionar varias dudas en el foro de CAAD sobre cómo usar el juego. Y finalmente preferí escribir una guía que sirviera para otros casos: Comó arrancar un programa de QL. Para quien no sabe nada de QL, usar QPC2 o Q-emuLator no es fácil porque hay muchos conceptos nuevos con los que familiarizarse, aparte de la barrera que supone la instalación y configuración del emulador. Pero con SMSQmulator se podrían eliminar esas barreras y usarlo como una máquina virtual de SMSQ/E para distribuir programas que funcionen en cualquier plataforma moderna, lo cual es un gran aliciente para desarrollar.
Por supuesto, todo esto supone programar para SMSQ/E dejando atrás QDOS... algo para lo que, por otra parte, ya va siendo hora, si es que queremos que SMSQ/E siga siendo atractivo. Intentar desarrollar de forma compatible con todos los muchos emuladores de sistemas QL y todos los sistemas operativos (QDOS, Minerva y SMSQ/E principalmente, aunque olvidando Argos, SMS2, SMSQ...) y todas las ROM y todas las resoluciones de pantalla y de color es una locura y un lastre. En algún punto hay que poner la frontera. El mismo caso de Asalto y castigo ya comentado me sirve también de ejemplo: lo hice para que funcionara tanto en Q-emuLator como en QPC2, y que estuviera disponible en varios formatos para ambos emuladores... El trabajo adicional que supone eso no merece la pena, salvo por la satisfacción de aprender. Por ejemplo, por una parte parece una lástima escribir un programa en SBASIC y no hacerle unos retoques para que funcione también en el antiguo SuperBASIC... Pero al final los retoques no se pueden limitar solo a elegir el modo, tamaño y colores de pantalla, sino que obligan a renunciar a muchas ventajas de SBASIC o, peor, a duplicar código para hacer dos versiones.
Me gustaría saber qué opináis sobre todo esto, si lo veis interesante y, si es así, qué ideas se os ocurren para posibles proyectos o colaboraciones. Yo tengo varios proyectos en marcha para S*BASIC, que progresan lentamente y terminarán siendo solo para SBASIC; la librería Sfera para SuperForth; un derivado modernizado del eForth que portó Salvador Merino en 1992 desde x86; y algunos otros proyectos más. Pero en todo caso el objetivo es el mismo: desarrollar para SMSQ/E, usando SMSQmulator como plataforma.
SMSQmulator tiene varias ventajas respecto a QPC2 y Q-emuLator: no necesita instalación, es multiplataforma, usa un fichero de texto como configuración (que por defecto puede estar en el directorio del ejecutable)... Y su único requisito, facil de cumplir, es tener instalada una máquina virtual de Java.
Me estoy dando cuenta de que estas características hacen de SMSQmulator la plataforma ideal para desarrollar para SMSQ/E. pues es posible distribuirlo junto con el programa. El usuario solo tiene que descomprimir el archivo ZIP o TAR.GZ o lo que sea, y arrancar con un doble clic o un comando. El emulador leerá su fichero de configuración y arrancará desde un WIN, por ejemplo.
Para mejorar la experiencia, y que el emulador en sí sea invisible al usuario, es útil que el programa pueda tener algún control del emulador y conocimiento del entorno anfitrión. Por ejemplo, echaba en falta que desde SBASIC se pudiera leer el estado de la barra de menú del emulador, y Wolfang lo implementó tras sugerírselo. Entre las próximas sugerencias pendientes de enviar tengo que se pueda leer la resolución de pantalla del sistema anfitrión, con `host_xlim` y `host_ylim`, por ejemplo; y que si el tamaño de pantalla en el fichero de configuración es 0x0, se use el máximo disponible; con ello, el programa podrá saber el máximo tamaño real que pueden tener sus propias ventanas. Otra sugerencia pendiente es que el dispositivo de arranque sea configurable (un disquete IMG, o un directorio montado como NFA o SFA). El caso es que nuestro programa (aplicación, juego o lo que sea) tenga control completo y el usuario no necesite tener ningún contacto con el emulador ni con su configuración.
Cuando escribí la adaptación de la aventura de texto Asalto y castigo para QL, y a pesar de haber incluido instrucciones de uso que me parecían claras y detalladas, tuve que solucionar varias dudas en el foro de CAAD sobre cómo usar el juego. Y finalmente preferí escribir una guía que sirviera para otros casos: Comó arrancar un programa de QL. Para quien no sabe nada de QL, usar QPC2 o Q-emuLator no es fácil porque hay muchos conceptos nuevos con los que familiarizarse, aparte de la barrera que supone la instalación y configuración del emulador. Pero con SMSQmulator se podrían eliminar esas barreras y usarlo como una máquina virtual de SMSQ/E para distribuir programas que funcionen en cualquier plataforma moderna, lo cual es un gran aliciente para desarrollar.
Por supuesto, todo esto supone programar para SMSQ/E dejando atrás QDOS... algo para lo que, por otra parte, ya va siendo hora, si es que queremos que SMSQ/E siga siendo atractivo. Intentar desarrollar de forma compatible con todos los muchos emuladores de sistemas QL y todos los sistemas operativos (QDOS, Minerva y SMSQ/E principalmente, aunque olvidando Argos, SMS2, SMSQ...) y todas las ROM y todas las resoluciones de pantalla y de color es una locura y un lastre. En algún punto hay que poner la frontera. El mismo caso de Asalto y castigo ya comentado me sirve también de ejemplo: lo hice para que funcionara tanto en Q-emuLator como en QPC2, y que estuviera disponible en varios formatos para ambos emuladores... El trabajo adicional que supone eso no merece la pena, salvo por la satisfacción de aprender. Por ejemplo, por una parte parece una lástima escribir un programa en SBASIC y no hacerle unos retoques para que funcione también en el antiguo SuperBASIC... Pero al final los retoques no se pueden limitar solo a elegir el modo, tamaño y colores de pantalla, sino que obligan a renunciar a muchas ventajas de SBASIC o, peor, a duplicar código para hacer dos versiones.
Me gustaría saber qué opináis sobre todo esto, si lo veis interesante y, si es así, qué ideas se os ocurren para posibles proyectos o colaboraciones. Yo tengo varios proyectos en marcha para S*BASIC, que progresan lentamente y terminarán siendo solo para SBASIC; la librería Sfera para SuperForth; un derivado modernizado del eForth que portó Salvador Merino en 1992 desde x86; y algunos otros proyectos más. Pero en todo caso el objetivo es el mismo: desarrollar para SMSQ/E, usando SMSQmulator como plataforma.