Nuevo Starmouse

El programa Demo del ratón de Puricorp modificado
para correr en QLs más rápidos sin ratón usando las teclas F1/F5.

Salvador Merino
Fuengirola, 14 de agosto de 2003

En Febrero del año 1987 en una conversación telefónica con Serafín Olcoz (presidente del Club QLAVE), me informaba que habían conseguido de Investronica una oferta de liquidación de sus ratones para Sinclair QL a muy buen precio (2500 pesetas + 500 pesetas de gastos de envío para los socios del Club). Yo en aquel momento no tenia ningún interés en un ratón, y no sabia qué utilidad tenia el mover un cursor/flecha/diana por la pantalla con una caja con una bola y un botón, cuando eso se podía hacer igual con los flechas y barra espacio del teclado.

En mayo de 1987, compré mi tarjeta TRUMP CARD (ampliación memoria RAM a 896 Kbytes, interface disco y utilidades en ROM) y una unidad de disco externa 3.5" DD (720 Kbytes). Como fui uno de los primeros usuarios TRUMP CARD pude beneficiarme de un regalo, el programa QRAM de Qjump (de Tony Tebby).

QRAM era un programa que usaba el entorno gráfico Qpointer de Qjump (escrito inicialmente para el SANDY QLT o FUTURA), cuya utilidad era acceder a muchos recursos del sistema QDOS sin teclear ningún comando. En realidad era una colección de programas que te permitían trabajar en un entorno multitarea gráfico con ratón, y además lanzar programas en multitarea mal hechos (por ejemplo: había un programa que modificaba el área de trabajo de programas ejecutables que se acaparaban toda la memoria libre RAM (por ejemplo: los 4 programas de Psion -Quill, Abacus, Archive y Easel-)).

Cuando recibí el Ratón, lo primero que hice fue probarlo con QRAM. Y funcionaba bien, eso si, había que reconfigurar la velocidad del ratón en el panel de control. Luego se me ocurrió, cargar el microdrive que venia en la caja sin etiquetar y sin instrucciones de papel de ningún tipo. La primera sorpresa fue que aquello no funcionaba en mi QL-TRUMP CARD. El segundo paso fue ejecutar el comando RES_128 (reducir RAM a 128 Kbytes), y volver a cargar el cartucho microdrive. Pase directamente al programa PRO, y el ratón no funcionaba (lo tenia en el puerto Palanca de juegos 1). El nuevo paso fue cambiar la conexión del ratón al puerto palanca juegos 2, y volver a cargar el cartucho, y seleccionar  el programa INS. Volví a cargar el programa PRO, y estuve un rato manejando el ratón, pero yo ya tenia varios programas de dibujo muy superiores al Starmouse, y no volví a cargar el programa nunca más.

En la revista QLAVE v1 nº 6 Junio 1986, se dedica la portada a Starmouse, y Enrique J. Sanchis publica un comentario de dos páginas.

En la revista en disco CUQ nº 1 Octubre 1988, José Carlos de Prada publica RATONES (I), que es un Toolkit escrito en SuperBASIC y compilado con QLIBERATOR para utilizar el ratón en nuestros programas (Ya sea para mover un cursor gráfico o uno de texto).

En la revista en disco CUQ nº 2 Noviembre 1988, Marcos Cruz publica su artículo "El ratón que era un escarabajo pelotero" (un comentario muy amplio del ratón y su programa Starmouse).

Javier Guerra tiene mucho interés en conseguir una copia del programa Starmouse (en busca y captura en QForum "El Foro de Sinclair QL en Castellano").

Con fecha 11 de julio del 2003, aparece un señor que dice que se llama Abel Ruiz, y que fue el programador del programa Starmouse cuando tenia la edad de 15 años (año 1985), y  nos cuenta  una historia del desarrollo del hardware/software del ratón bastante creíble. Tanto que me da suficiente motivación para buscar un cartucho de microdrive sin etiquetar entre mis cientos de cartuchos guardados en una caja, y tenemos la suerte de encontrarlo y poder recuperar su contenido en disco.

Se prueba el programa Starmouse con los emuladores QLAY (Win95) y uQLx (Linux), y funcionan (naturalmente, en modo 128 Kbytes). Pero existe un problema, no hay ser humano capaz de controlar el cursor con las teclas F1 a F5 en un QL compatible más rápido que el original.

Modificando el código máquina del programa Starmouse

Hace mucho tiempo, años 1987 a 1989, cuando los usuarios QL ya teníamos nuestras ampliaciones de memoria e interface de disco, una costumbre no muy interesante para los autores de programas comerciales era modificar el código máquina del programa para saltarse la protección con la ayuda de un programa llamado monitor/desensamblador de código máquina (el más usado fue el Monitor de Computer One). En otras palabras, como en los viejos tiempos, vamos a parchear el Starmouse.

Lo que Starmouse necesita es una rutina de espera (retardo), y sabemos que tiene que leer el puerto palanca de juegos 2 usando la rutina KEYROW del sistema operativo QDOS. Por lo tanto escribimos el siguiente parche:

* Rutina lectura teclado

        rorg    0

* Rutina Fbyte usada para un tiempo de espera 2

  (49 es un segundo y -1 es hasta que se pulse una tecla)

        move.w  #2,d3                Tiempo de espera

        move.l  #0,a0

        moveq   #1,d0

        trap    #3

        clr.b   d1

* La rutina que lee el puerto palanca juegos 2

        moveq   #$11,d0

        lea     datos,a3

        trap    #1

        rts

datos

        dc.b    9,1

        dc.l    0

        dc.b    0,2

        end

La anterior pantalla corresponde a una captura del monitor de Computer One ejecutando el código máquina del Starmouse en modo trace. Podéis observar en el centro de la pantalla el cursor del Starmouse.

El siguiente paso fue localizar todas las rutinas de lectura del puerto palanca juegos 2. En situaciones normales, solamente debería existir una sola subrutina, y muchos saltos relativos (jsr), pero había nada menos que la friolera de 8 veces repetido "el código de lectura del puerto palanca de juegos 2". ¿Por qué? Muy simple, existen un mínimo de 6 rutinas de código máquina (código relocalizable) que se llaman desde SuperBASIC con un CALL. En otras palabras, se han escrito rutinas independientes que se han colocado a saco (lo lógico y verdaderamente útil hubiese sido que esas rutinas fuesen un Toolkit con nuevos procedimientos y funciones para el SuperBASIC).

El fichero COD original lo partí en dos, porque los primeros 32768 bytes corresponden a la segunda pantalla utilizada por el programa Starmouse. Existen también muchas lagunas sin código entre tantas rutinas. Una de esas zonas en blanco son los primeros $E8 bytes del código relocalizable (o los primeros $E8 bytes de nuevo fichero "starmouse_cod"). Por eso elijo ese lugar para colocar mi parche de 36 bytes de longitud, y además es la dirección 0 relativa (dirección absoluta 251804). Luego el resto es fácil,  comienzo a "pokear" la memoria con:

18 POKE_W 252300,24576:POKE_W 252302,-398:POKE_W 253496,24576:

   POKE_W 253498,-1594:POKE_W 254000,24576:POKE_W 254002,-2098:

   POKE_W 254492,24576:POKE_W 254494,-2590:POKE_W 254996,24576:

   POKE_W 254998,-3094:POKE_W 255500,24576:POKE_W 255502,-3598:

   POKE_W 258300,24576:POKE_W 258302,-6398:POKE_W 260312,24576:

   POKE_W 260314,-8410

El código 24576 corresponde a la instrucción en ensamblador BRA (bifurcación incondicional. Algo parecido al GOTO del BASIC) y el número negativo es el salto a mi parche en la dirección 0 relativa.

Las direcciones 253144 (dirección relativa $4D8) y 253244 (dirección relativa $53C) contienen la constante de la base de la segunda pantalla (starmouse_pantalla) en una palabra larga (32 bits).

Se suponía que con esta modificación el programa Starmouse se podría utilizar en modo 128K en cualquier QL compatible corriendo el sistema operativo QDOS o Minerva, pero pronto vi que era imposible utilizar las opciones dibuja una recta y un circulo. Después de mucho pensar, probar, etc, llegué a la conclusión de que el problema estaba en el código BASIC, pero ¿Dónde? y ¿Por qué?. Y decidí escribir una nueva versión en perfecto SuperBASIC del programa "pro" ("starmouse_pro_nuevo"), porque la versión original con tantos GOTOs y GOSUBs me ponía enfermo y al borde de un ataque de nervios. Al final descubrí el error, el cual seguía siendo el mismo que en el código máquina, exceso de velocidad. El parche es el siguiente:

60 a=PEEK(208403+dif)+1:b=PEEK(208405+dif)+1:IF a<248 AND a>34 AND

   b>19 AND b<205 THEN b=((255-b)*.543)-27.5:a=(a*.803)-28:a2=a1:

   a1=a:b2=b1:b1=b:POINT #2,a,b:PAUSE 20:CALL 209100+dif:GO TO 50

Sí. Aunque parezca mentira, el parche es un simple PAUSE 20, porque todo es tan rápido que cuando pulsamos F5, antes de levantar el dedo, al programa le ha dado tiempo a repetir la linea más de 3 veces, y como es lógico las variables a2, a1 y a tienen el mismo valor (lo mismo ocurre con b2,b1 y b).

En resumen, en teoría todo esto podría suponer una pérdida de tiempo, pero supongo que toda esta información podría ayudar a otros usuarios para solucionar problemas similares.


Sinclair QL Recursos en Castellano Alojado en / Hosted at:
Sinclair QL Recursos en Castellano
Sinclair QL Spanish Resources