Karoshi MSX Community

Bueeenas,

Vamos a ver me ha surgido una duda sobre la lectura del registro del VDP de MSX1.

Escape from the dwarves goldmine está siendo programado en .COM, osea...todo RAM para mi :) lo chulipitiflautico seria que sea un .ROM de 32 ks maximo. Esto hace que me plantee varios cambios, sobre todo por el tema interrupcion VDP y tal.

Ahora toco las posiciones 38-39-3A y pongo ahi el salto a mi rutina que vuelve con un RETI. Como bien sabemos todos, en .ROM ahí hay BIOS y esto no vale. Ya se que hay que hacer un enganche en FD9A y volver con un RET. Hasta ahi todo comtrolado.

EL PROBLEMA me viene al hacer la lectura del registro del VDP para coger la colision de SPRITE.
Ahora lo hago así :
(cachito del principio de mi rutina de Interrupción)

Según tengo entendido al leer el 99h se borra su contenido y cambia.
Claro...investigando veo que la rutina de interrupcion de la BIOS ya lee ese 99...tonces...
...si lo que tengo entendido es cierto
¿Cuando y como debo leer ese puñetero bit al hacer una ROM ?

Agradezco ayuda y sugerencias. ;)

P.D: Si no resuelvo esto , en la RU os presento el juego en .COM (y a cagar a la playa) XD

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.

A ver... todo depende de dónde enganches la rutina de interrupción.

Hay dos ganchos a los que llama la BIOS, uno al que salta en todas las interrupciones y otro al que salta sólo en las interrupciones del VBLANK. La diferencia es que si enganchas en este último, la BIOS ya ha leído el registro de estado del VDP (lógico porque ha tenido que discriminar si la interrupción ha sido provocada por el VBLANK) y al leerlo se ha borrado. Eso sí, como te ha dicho Kun, la BIOS no es tonta y lo guarda en la RAM.

Si enganchases al otro gancho, la BIOS aún no ha leído el registro de estado y es ahí cuando tendrías que leerlo.

De todas formas (y como comentarios a tu rutina de interrupción):

-La BIOS ya guarda todos los registros antes de llamar a los ganchos, no te hacen falta los PUSH (y POP que tendrás detrás).
-Si vas a usar la variable TIM_SPC como booleano, te puedes ahorrar los srl a, ya que con el AND que haces ya tendrías un valor de cero si el bit está apagado y un valor distinto de cero si el bit está encendido. ¿Para qué moverlo al bit 0?

Échale un vistazo a la última versión de la rutina FD9APATCH que puedes encontrar en el subforo de snippets: http://karoshi.auic.es/index.php?topic=212.msg13860#msg13860 quizá te de ideas :D

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. ;)

Ramones, dices eso acerca de las BIOS porque aún no ha pasado por tus manos mi reimplementación en Java de la misma que tengo hecha para el emulador :o, en la que como no tenía ni idea de esto de que en A vaya el estado del VDP pues no lo hacía, pero como ya lo he arreglado tu frase vuelve a ser cierta, y por tanto tus juegos podrán funcionar sin problemas :D

Este es el fragmento de la BIOS oficial de la zona de la que hablamos:


No les hubiera costado nada guardar la variable antes de llamar a H.TIMI, o hacer oficial y documentar que el valor ya va en el registro A...

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!

Totalmente de acuerdo. Para MSX1 es que lo veo casi imposible (sacarle partido). Y para MSX2 complejo (aunque el MSX2 si disponga de su bit por linea de patron de sprite especificando si se controla o no la colisión. Aunque se de uno que hace poco me comentaba que si le puede sacar partido... ¿verdad Fernando? :P

Es que mi frase siempre ha sido cierta. Yo hablaba de máquinas MSX *reales*. :P 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. ;)

Sip, en la RU te lo cuento en detalle. Verás que es bastante simple lo que necesito y con el uso de ese bit me sobra.


Aps, interesante es saberlo.

Yo lo que hago es engancharme en FD9A y leo directamente el registro de estado del VDP en mi rutina. Así, al volver a la BIOS, ella lo vuelve a leer y como ya ha sido leído se ha desactivado el bit de la interrupción y piensa que no es una interrupción del VDP con lo que no llama a FD9F y vuelve directamente.

¿Ves algo mal hecho en ese procedimiento?

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

¿Además de usar las cosas para lo que no son? XDDDD Entiendo que al leer el bit de interrupción chequeas si es o no una interrupción para procesarla o no. Si haces eso.. pues no se... no creo que te pase nada.  Lo que pasa es que H.KEY recibe TODAS las interrupciones por eso hay que filtrar cuál quieres. Por ejemplo el MIDI del Turbo R también activa interrupciones cuando está funcionando que saltan ahí. Y las interrupciones de linea en MSX2 si no recuerdo mal también saltan ahí.

Pero ya te digo si lo tienes controlado, no creo que te pase nada. Ahora mismo no se me ocurre nada. Pero claro son las 8 de la mañana.... xDD

Totalmente. :) Gracias.


Pues adelante. ;)

Bueno, aprovecho y genero el siguiente número pseudoaleatorio de la secuencia. Así meto un poco más de aleatoriedad en el juego ;D ;D


Sip, lo que hago ahora es una espera activa que apaga un flag propio y sólo sale cuando se enciende... Y sólo lo enciendo si detecto que es una interrupción de VBLANK. Pero como ya te he dicho, en toda interrupción calculo un número aleatorio... así aprovecho las interrupciones un poquito más :P

Además, le robo unos cuantos ciclos a la BIOS, lo cual no está nada mal para según que casos ;D ;D ;D

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 !!!  ;D ;D ;D ;D

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 :)

¡Felicidades! ;D Me quito la boina verde 8)

Ahora ya podré chulear de que conozco a alguien que usa el bit de colisión por hardware satisfactoriamente en un juego y no ha sucumbido en el intento ;)

Eso te eleva a la categoría de gente como "EL ÚLTIMO SUPERVIVIENTE" :D *** BEHIND THE MUSGO ***

A ver si llega pronto ese vídeo  :D, por cierto, ¿Lo has probado en un MSX1 con el VDP Toshiba como el Toshiba HX-20?

Pues no lo he probado porque no tengo ese modelo. Supongo que lo dices para ver si el VDP este deja tambien el bit de colision en AF.
Sugerencias para emularlo ? OpenMSX ? BlueMSX ? alguien sabe su configuracion o si se puede emular bien ?

De todas formas ya os digo...q de momento no es oro todo lo q parece. Tengo algunos problemas con el .ROM en algunos emuladores. (Que seguro me podeis echar una mano :) )
- El BlueMSX no arranca el juego si lo pongo en el slot2
- El Meisei se queda "picueto" tras mostrarme el logo. Creo que se queda así justo en el momento de hacer el primer EI

Sí, porque como es un poco especialito (Al menos con el de 5º Sprite). Que yo sepa todavía no lo emula nadie, básicamente porque no creo que esté documentado exactamente cómo funciona de distinto.

Con el 5º sprite y con el denominado "modo mixto" (screen 2 con un solo banco), que tampoco parece funcionar en esos VDP Toshiba. Ah, y no solo van montados en Toshibas, que en uno de mis Sony HB10P está el maldito :-\

Ah Ok Ok.
Mi juego no busca el 5o Sprite, ya sabia que algunos VDP no lo implementaban. Y tampoco uso el modo mixto de screen2. Así que supongo que no habria problema en esos modelos de Toshiba o HB10.

Lo que me trae de cabeza es el porque al ponerlo en el slot 2 no tira :( ¿Alguna pista?

Añade el 20P tambien :D


Da mas info, es una ROM de 32k?

Será porque es un ROM de 32KB y busca la segunda página del ROM donde no debe (cuando pasas de un ROM de 16KB necesitas una rutina de búsqueda de slots para detectar en que slot está metido el ROM y activar así la segunda página de 16KB del mismo). Me parece que desde asMSX puedes hacerlo automáticamente con la directiva .search, de todas formas, echa un ojo a este topic del foro (http://karoshi.auic.es/index.php?topic=628.0), donde tienes una rutina de detección muy limpita ;)

Kun, Vieju... (no leeis la pagina 1 del post, XD )
Sí, es de 32ks y sí uso el .SEARCH, lo tengo puesto al principio de la ROM (os paso luego la inicialización)... Me he encontrado con otras anomalias que tengo que investigar, como el cambio de una habitación que no va a la contigua sino a una que está 8 posiciones más allá... :(
Pasan cosas raras, tengo que investigar. Peró si teneis algún consejo o os pasó en su momento, comentadmelo que toda pista es bienvenida. :D

Vieju, los tutoriales que dices me los tengo pateaos y repateaos, me los he leido a conciencia. Aún así no veo que ocurre y hasta el finde no me pondré a mirar de nuevo MSX code, cosas de estudiar y trabajar que impiden a uno el desarrollo :p

Tambien tengo una rutina explicada de Sapphire, que no he probado aún, que lo hace de una manera algo extraña para mi ...intenta modificar el codigo y si no puede pone el slot de la pagina en la que está en la page 2, ...ta chulo, pero lo dicho hasta el finde, no podré investigar.

Consejetes welcome ! :)

He implementado la rutina que pasó Sapphire , que por lo q pone en los comentarios es de konamiman una parte, en vez de usa el .SEARCH pero estamos en las mismas...No arranca desde el SLOT2 de los emus y se me clava en el meisei :(
alguna pista ? o si tengo q aportar algun dato para que podais dar una pista, me lo deciis.

No tiene sentido a menos que estés haciendo accesos a la segunda página del juego cuando aún no está situada... es algo muy raro, pero sin ver el código del juego no hay forma de saber qué pasa :-\

Pues no se me ocurre, j4mk3... se que igual es *otra* pregunta tonta, pero supongo que el .search está colocado después del inicio del programa y no antes, ¿no?... es que, si no, es algo realmente raro. ¿Podrías hacer un c&p del inicio de tu programa y de las directivas del asMSX que utilizas? :-*

La iniciacion que tengo es esta...creo q un poco liante :p


Alguna sugerencia  ???

Pues en principio, si te compila bien (es decir, si te detecta PILA como constante y la etiqueta SETPAGES32K, pues debería estar bien). Entiendo que en un momento dado activaras las interrupciones. En fin, no veo nada extraño.

¿Podría ser que tu listado del GEN que te detecta la segunda página del ROM no esté al 100% asMSXizado, es decir, sustituyendo los paréntesis de "contenido en" por corchetes "[" y "]" y que te esté compilando mal esa rutina en concreto?

Decías que ya has probado con el .SEARCH, pero igualmente te lo paso sin usar ese listado del GEN por si aca está ahí el error:

Puede haber un pequenyo problema: aseg'urate de dejar a 0 los 12 bytes posteriores a la cabecera ROM.

Es decir, prueba a hacer lo siguiente:


No tengo claro que 'ese sea el problema, pero podr'ia darse el caso. En todo caso, la rutina que implementa SEARCH funciona perfectamente tanto en RAM como en ROM, tanto en el slot 1 como el 2 o incluso en slots expandidos. Palabrita del ninyo Jes'us. El tema de que la directiva ROM no deje a cero los espacios de la cabecera ya est'a corregido en la WIP del asMSX, pero he de decir en mi defensa que muchas ROMs comerciales de MSX pasaban mucho de ello...

Bueeeno,
Parece que la cosa ya está mejor. Ya consigo que arranque del Slot2 del blueMSX. Hoy tocará pruebas en MSX reales a ver que tal.
Realmente la solución final no sabria deciros cual a sido, pero tengo mis sospechas.
La cosa es que tanto con el .SEARCH como con la rutina de Saphire funciona bien y arranca con el Slot2. Vosotros deciis que la causa no parece que venga de los 12 bytes en blanco de cabecera que no ponia,...entonces...me da a mi que era el Bluemsx. Parece como si leyera de algún tipo de cache el fichero .ROM ya que la cosa funcionó cuando forcé el sacar y volver a meter el .ROM en el slot2.
 
Nose, es raro.

A lo que añado otra cosa más, esta vez del Meisei: el susodicho emulador en el curro me lee la ROM, ejecuta bien y en el portatil de casa (misma versión recien bajada) se cuelga al mostrar el primer gráfico.
Tube ayer la ayuda de Aorante que lo probó en su Meisei en su casa y a él le arranca perfectamente de los dos slots. Ahora si que ya no me lo explico. Todo apunta a algún problema en mi portatil.
"Que paranormal es todo eh!?"

Pero mira...me la suda. Lo probaré en MSX reales, miraré de pasar el Ramones seal of quality y au ! :)
Jodidos emuladores. ;)

OT:
Si el ramones test se retrasa hasta principios de mayo... el video con salsa picante se lo zampará otro...

A tocar las pelotas a otro maki !! XD o mejor...a ver si tienes las pelotas de hacer tu un juego XD