Nunca he usado ese bit, pq parece que es problematico...

De todas formas, podria ser esto?

Handbuc:

STATFL (F3E7H, 1)
initial value:  0
contents:   stores VDP status (contents of status register 0, in MSX2)

ahi tienes en RAM el contenido del registro de estado del vdp, prueba a ver.

Venga, que hoy estoy "escritor". xD Te explico.

Si te enganchas a H.TIMI (0FD9Fh), te sobra código en tu rutina de interrupción.

Para empezar SOLO tienes que guardar AF. ¿Por qué? Pues porque la BIOS ya ha hecho ese trabajo de guardar por tí todos los registros (debuggear un poco cualquier BIOS en la dirección 038h).

Así que con:

interrupt:

push af
....
pop af
ret

Te sobra.

Y sobre el "maldito" registro de estado 0, pues casi que igual o más fácil. Mira:

push af
ld (registro0vdp),a
....
pop af

Si si... cuando la BIOS salta a H.TIMI te pasa en AF el valor que ha leído en 038h (vamos lo tú haces en MSXDOS con el in a,(099h)).

Si utilizases la variable que comenta Sapphire tendrías un problema: Que leerías lo del FRAME ANTERIOR. ¿Por qué? Pues porque ese valor se guarda en la variable de sistema, precisamente, después de retornar de H.TIMI.

Por eso el solo guardar AF y el usarlo tal cual viene como parámetro.

Lo se lo se... no hay ninguna referencia escrita a que esto es así como lo cuento. Y es cierto, no he encontrado ningún libro, documento o similar donde me diga que lo que llega en AF en H.TIMI es el registro de estado del VDP. Pero después de leer todas las BIOS que han pasado por mis manos, TODAS hacen lo que te dicho, de una manera o de otra.

Yo he usado la rutina de interrupción así en todas las ROMs que he hecho... y todavía no conozco ningún problema con ellas y esto.

Si al final usas satisfactoriamente ese bit, me quitaré sinceramente el sombrero. No conozco a nadie en ninguna plataforma equipada con detección de colisiones por hardware que haya tenido la bravura de utilizarla de un modo coherente, ya que la colisión por bit es demasiado estricta (tocas un sólo pixel y mueres, LOL!) y usarlo como filtro para una 2ª rutina de detección por áreas conlleva un ahorro de ciclos que al final no sirve para nada cuando se produce el peor caso de colisión posible.

De todas maneras, desconozco el desarrollo de tu juego, al igual te va bien ese tipo de colisión. Y decirte que tienes mi apoyo y admiración por usar las maravillas intrínsecas del hardware de la máquina


¡Al hierro!

Es que mi frase siempre ha sido cierta. Yo hablaba de máquinas MSX *reales*. Y tu me hablas de un emulador. Me alegra que lo hayas subsanado a raíz de esta conversación.
Lo que no entiendo (porque no tengo ni idea de como implementar un emulador) es por qué no lo tenías "implementado". Si tu emulador emula el MSX, emulará la BIOS y con ella... el código de 038h... ¿cómo es que no lo tenías implementado? De verdad, me gustaría conocer la respuesta porque soy muy torpe con eso de emuladores. Igual es que hablas de un simulador del MSX en java, no de un emulador... entonces lo entendería...

Y bueno, espero que no te siente mal, pero es que nunca me he preocupado porque mis programas funcionen en los emuladores, sino en las máquinas reales.

Pues te cuento, es que mi emulador es bastante particular en muchos aspectos, porque si recordáis fue un proyecto que nació de la idea un poco nebulosa de crear una plataforma mixta Java+MSX para desarrollo de bocetos, pero después se redefinió para crear un emulador MSX orientado a web y en un futuro espero no muy lejano a plataformas móviles. Y puesto que estos dispositivos son relativamente limitados en recursos, uno de los objetivos prioritario de diseño es la eficiencia: Cada bytecode Java ahorrado acerca el emulador a móviles más modestos además de bajar el consumo.

Así que, uno de los sitios dónde se podría ahorrar bastante era alrededor del BIOS: 32KB de memoria para almacenarla, quizás puertos de I/O, en algunos casos la necesidad de un mapper... Y además también podía ahorrar que se ejecutara tanto código Z80 emulado, relativamente lento, ya que podía utilizar los 'atajos' que ya tenía creados del enfoque original y atacarlos directamente con Java.

Es decir, que como comentas, en un emulador con un enfoque tradicional, se emula todo el hardware, y sobre él correrá la BIOS original (O equivalente), si esta BIOS dejaba en A un valor antes de saltar a algún sitio, ahí estará en la emulación. Pero en el caso de mi enjendro no, ante cada llamada al BIOS 'simulo' más que 'emulo' que el efecto documentado sobre el estado de la máquina es el mismo que si hubiera ejecutado la llamada original, pero salvo que los cree expresamente este tipo de efectos laterales no estarán (O habrá otros disintos).

Así que bueno, no sé si lo que estoy haciendo es un emulador, un simulador, o algo intemedio, la idea es que ni el usuario ni el software vean la direfencia... 

Espero que te haya disipado las dudas...


Claro que no me lo tomo a mal, obviamente son los emuladores los que tienen que adaptase a los juegos, aunque bueno, ya sacaré este tema más adelante porque me afecta de forma directa 

Saludos

Totalmente. Gracias.


Pues adelante.

Señores....señoras ninguna

Ya he hecho mi primera .ROM de 32ks, con el asMSX, el .SEARCH que incorpora para la page2, con la lectura del AF para pillar el bit de colision (y si funciona) y enganchando la Interrupcion al 0FD9Fh.

Gracias a todos, Saphire, Ramones,

SIIIIIIIII !!! 

Pronto os pongo un video de como va el juego.

Maki, ve poniendo ketchup o algún tipo de salsa al fichero de video de las jornadas en Calella si quieres que tenga buen sabor cuando te lo tragues !!!

Madonna, quitate el sombrero