Karoshi MSX Community

Esta noche (como de costumbre) he estado despierto un buen rato y una de las paranoias que se me han ocurrido ha sido la siguiente:

Supongamos por un momento que tenemos un ordenador con RAM en la página 0 de algún slot. Supongamos, también, que copiamos la BIOS a esa página y ejecutamos el siguiente código:


Es más, tendríamos también un buffer de, al menos, 2kb's en la zona donde la BIOS guarda la tabla de caracteres... suponiendo, claro, que no la vayamos a utilizar.

Teniendo un poco de cuidado y asegurándonos de no escribir nada más en esta "BIOS modificada" la preguntas son:

-¿Tenemos todas las funcionalidades de las llamadas a la BIOS?
-¿Habría algún problema con las interrupciones? ¿Ganaríamos mucho tiempo?
-¿Alguien se anima a probarlo?

Jeje, pues no es tal paranoia. O mucho me equivoco o la estructura del The Cure y del U:U se deben de parecer bastante, la diferencia radicará en que ellos no habrán copiado la BIOS sobre la RAM de la página 0, sino que se habrán limitado a implementar su propio servicio de interrupciones en $38.
Si quieres aprovechar la BIOS; pues haces lo que dices, y deberías poder trabajar perfectamente con ella. Como es lógico, perderás todo lo que hacía el servicio de interrupciones original; pero seguro que el resultado vale la pena.
Respecto al tiempo que ganarías; pues no es mucho, porque el gancho que se suele usar, el $FD9F, creo que no tiene antes tareas muy pesadas; pero seguro que te ahorras un par de lineas de barrido.
Y ante la duda, ya sabes, IM2  ;D

Vale, reformulo la pregunta: y si NO usas nunca el gancho en $FD9F y sincronizas siempre con HALT's, ¿ganarías mucho? ¿Son muy pesadas las tareas que se hacen en la interrupción?

No creo que sean muy pesadas, pero desde luego hacen muchas cosas que no nos sirven a los desarrolladores de juegos... No quiero ni lectura del buffer de teclado! Viva el joystick, larga vida al teclado de mi MSX!

Puesssss, nada. Aunque no uses el gancho, la interrupción se va a seguir ejecutando. Las únicas soluciones son la que tú has comentado antes, parchear FD9A, pasar a modo IM2 o usar DI (en este último caso HALT no funcionaría muy bien :P)
Y como dice Robsy; pues no son demasiado pesadas, no; pero claro, la mayoría en un juego no se aprovechan para nada y no está la interrupción como para desperdiciar ciclos. No hablemos de cosas como que al toquetearte el registro de estado del VDP, te lo ponen a cero y te ves obligado a hacer chapucillas si tienes que andar detectando colisiones de sprites, 5 sprites en linea y cosas así. >:(

Hola de nuevo:

  He estado haciendo unas cuantas pruebecillas con las interrupciones (sí, he logrado que el ordenador se cuelgue de muy diversas formas) y al final he plasmado los resultados en forma de snippet. ¡Se ganan unas 16 líneas del raster!

Echadle un vistazo y ya me comentáis
--
SapphiRe

Aaaah, ahora sí, te ha quedado de lujo Sapph ;).

Por si alguien necesita utilizar interrupciones mediante el gancho en FD9F (que ya no funcionará) se puede implementar un servicio personal añadiendo el código que necesitemos al principio de la misma rutina FD9APATCHCODE. Hay que llevar cuidado ya que esta rutina se invocará cada vez que haya una interrupción, no sólo la del VDP; por lo que si queremos conseguir una periodicidad en nuestra rutina de 1/50 o 1/60 deberemos comprobar antes que se trata de la interrupción del VDP y si es así ejecutar nuestro código.

Otra cosa, ¿en tus investigaciones has encontrado algo acerca de la obligatoriedad de la lectura del puerto de direcciones del VDP (in a,($99))?, es por si se puede eliminar de la interrupción... ???

¡Buen trabajo!

Gracias! :D


Sí, eso lo hace la propia rutina de la BIOS, tiene un JP P tras el in a,[$99] que si no se ejecuta ya pasa al servicio de interrupción del VDP. De todas formas mi idea era eliminar la rutina de todo. He añadido un comentario en el snippet para activar nuevamente el gancho en FD9F... o donde se quiera, claro está :D

¿Puedes poner un ejemplo de interrupción no generada por el VDP?


Si prescindía de esta instrucción se saltaba siempre a 0038 al volver a activar las interrupciones. Al añadirlo no ha habido ningún problema.

Un saludo
--
SapphiRe

A poco que tengas un MSX vitaminado son la mayoría ;D. Por ejemplo, las de las tarjetas de sonido como la MoonSound o el propio interface MIDI, periféricos como el RS232, en fin, supongo que casi cualquier periférico va a generar sus propias interrupciones con la periodicidad que el componente imponga.

No he mirado el código en $38; pero supongo que la rutina de la BIOS pasará a ejecutar el gancho en FD9F cuando haya comprobado previamente que esa interrupción si que es una del VDP, comprobando el valor del bit 7 del registro de estado del VDP. Si no se trata de una interrupción del VDP se pondrá con otras cosas o acabará, no se lo que hace en realidad.


Que curioso...

Pues actualiza unas cuantas cosillas en la RAM. Lo suficiente como para que se desperdicien unas 16 líneas de raster en cada vblank.


No es tan curioso, es la forma de resetear ese bit de interrupción: al leer el registro de estado del vdp se resetea el bit de interrupción. Si no se lee no se resetea y, al salir de la rutina, la interrupción vuelve a dispararse y se repite otra vez todo el proceso. El resultado es un bonito cuelgue :D

 ;D

Ahora mismo se me había ocurrido la explicación y entraba para autocontestarme.... :P

Claro, si no lo pones a cero, la BIOS supone que el VDP está en un estado de perpetua excitación y se mete en un bucle sin fin :-\. Una pena, habrá que seguir utilizando el DI/EI al hacer según que cosas con el VDP.