Karoshi MSX Community

Buenas,

Aqui el preguntón de turno...esta vez va de ciclos.
Decir primero que he mirado por los foros, cone l buscador y tal y no he encontrado esta infomación, pero que si está encantado de leerla eh ? :)
Bueno, lo que queria saber.

Resulta que tengo hecho un player para el PSG que se lanza desde interrupcion, osea en cada VSYNC y tengo pensado hacerle una serie de modificacions bastante fuertes. Fuertes en el sentido de que lo dotará de mucha más versatilidad y fuerte porque creo que son muchos calculos y muchos CICLOS de reloj. Entonces antes de ponerme a ello, a picar codigo (la teoria ya es´ta en mi libretica) pregunto:
- ¿Cuantos ciclos tengo para no saltarme ningun frame dentro de una rutina de interrupcion? Ya se que es diferente a 60 y a 50 Hz. ¿Teneis este dato?
- ¿Como tengo que contar esos ciclos de mi rutina de interrupcion? ¿He de contar el camino más largo através de los CP? ¿Cuenta tambien el JP que hay en la mem $38?
- ¿Hay alguna utilidad o "algo" que me pueda ayudar a contar los ciclos que uso? ¿O directamente pillo el manual del Z80 y a contar instruccion por instruccion?
- Los calculos de tempo del player los estoy haciendo a 50Hz ¿voy a saco y cambio el Registro para que todo el programa vaya a 50Hz independientemente de que sea el MSX q sea? ¿Lo fuerzo o eso es "incompatible" con el standard? El Nemesis no controla y a 60Hz va too follao :p

Bueno pues a ver si con estos numeros y tal os puedo mostrar el susodicho player en la RU.

ありがとお
Arigatoo
じゃね！
Ja ne !

Si yo fuera tú... no sabría la respuesta claro.  ::) Bueno, era sólo una forma de hablar. Empezamos de nuevo: si yo fuera tú tendría en cuenta ciertos problemas a la hora de hacer un replayer en IM1, que parece ser tu caso.

1.- Yes, tienes que tener en cuenta que no tendrás control total sobre la cantidad final de ciclos a gastar si no habilitas el modo IM2.

2.- Cuidadín, porque según qué información esté trabajando el replayer, en unos rasters consumirá unos ciclos y en otros consumirá más. A no ser que te hagas uno que siempre consuma la misma cantidad de ciclos en cada raster, como Joyrex hizo ne su día.

3.- La putadilla de los 50 o 60 hercios... Si no estás seguro, haz las pruebas siempre a 60; así te aseguras que luego corra a 50 también.

Sobre lo de la documentación de los ciclos (o T-states), yo miraría la parte de RESOURCES de MAP (http://map.grauw.nl/). En concreto el primer documento en la parte del Z80, llamado "Z80 instruction set overview".

Jannone tiene en su página (http://msx.jannone.org/bit/) un ensamblador on-line con una herramienta muy cuca que te cuenta ella sola los t-states y los bytes del trozo de código que quieras.

Dionisio me has dejado frio !  :o No por la respuesta en si, sino que me estas haciendo replantearme todo desde el princio...ai q lloro ! ;)
- Si me estas diciendo que el player no debe ir a rutina de interrupcion, entonces no se como controlar los tempos, el cada cundo se dispara una nota. Ilustrame un poquico si puedes.
- En raster hago el volcado a VRAM, la captura de teclado y el player (tal como tenia pensado)...mmm me da q no da tiempo a q todo vaya a 25 frames ???
- No entiendo las diferencias en forzar al Z80 que cambie el tipo de interrupcion de IM1 a IM2, ¿ En que se diferencia ?

Gracias a los dos por la documentacion referenciada, me será muy util.

Claro que debe ir a rutina de interrupción. Lo único que te digo es que tengas en cuenta que tu replayer necesitará una serie de ciclos si toca sólo frecuencias pero que probablemente, si utiliza frecuencias más envolventes más ruido más lo que estés haciendo en pantalla (volcado de gráficos, etc...) te puede consumir mucho. Sólo digo que un replayer no consumirá casi nunca el mismo número de ciclos (a no ser que se te curres un replayer como el que te comenté).

Debes intentar que todo se ejecute en casa interrupción. Por eso te dije lo de hacerlo a 60 hercios, que es más rápido que a 50. Así estarás seguro de que todo funcionará a 50 también... No sé si me explico.

En el modo IM2 tú controlas las interrupciones, por lo que tendrás más ciclos para ti. En el modo "normal" (IM1) hay ganchos ajenos a tu programa) que te quitan ciclos.

Mmmm.

Creo que aquí igual no estamos hablando todos de lo mismo. j4mk3 habla de cuántos ciclos tiene disponibles entre v-blanks consecutivos para que no le pete el replayer. Lo que plantea Dioniso es la forma óptima para hacer un replayer sincronizado a nivel de ciclos, que me parece algo mucho más potente y ambicioso.

Lo suyo, con un replayer cualquiera (como por ejemplo el pobre Karoshi Caruso) es, al principio de cada interrupción, volcar los registros del PSG de RAM a los puertos correspondientes. En esto se tarda siempre lo mismo - es muy rápido - y así no se distorsiona el sonido. A continuación, todas las rutinas de gráficos - ya que fuera del v-blank, se pierde mucha velocidad de acceso y aparecen problemas - y por último, el replayer en sí que procesa los datos y genera los registros del PSG en RAM que serán copiados en la siguiente interrupción. De esta forma, salvo que tengas demasiada carga, podrás solucionarlo todo en cada v-blank sin problemas.

Igual os estoy liando todavía más :(

Mmm menos mal que me dices eso dionisio. Y pitpan eso es ! de Registros RAM al PSG en cada vsync.
Si os cuento...aix...tengo toda la rutina del player en la Vsync, pero a saco claro...no se que a framerate iba pero debe ser demasiado lento. En la ultima revision-cambio que le estoy haciendo al player (que no entiendo pq le deciis a esto Replayer ;) ) ya he perfilado lo de tener una copia en RAM de los registros y volcarlos. Auqnue antes de leeros, tenia previstos hacerlo todo en la interrupcion...y claro...uso ciclos a cascoporro.
mmm bien bien...con vuestra ayuda ya tengo bastante claro como hacerlo mejor y q el framerate no sufra.

Respecto a la rutina de interrupcion. Actualmente trabajo en DOS, no hago Roms. Investigue en su momento como se hacia y lo unico que hago es cambiar la direccion de salto de la posición 38h de memoria a mi interrupcion. Dentro de esta hago PUSH de todos los registros, pongo los calls del update de VRAM, mirar teclado y volcar al PSG, y salgo con POP de todos los registros.
Como lo hago en DOS, antes de cambiar la posicion 38h guardo los valores que ya hay y los restauro al salir del .COM
Ahora que pienso...Al hacer un .ROM, tendré BIOS en la 38h, no ? Que más tengo tener en cuenta cuando haga .ROM ? algún enlace o pagina donde mirar este detalle ?

Y a los nuevos interrogantes, hay dos de mis preguntas que estan sin respuesta del primer post, os agradeceria que alguien pudiera contestarlas:
- ¿Cuantos ciclos tengo para no saltarme ningun frame dentro de una rutina de interrupcion? Ya se que es diferente a 60 y a 50 Hz. ¿Teneis este dato?
- ¿Puedo ir a saco y cambiar el Registro para que todo el programa vaya a 50Hz independientemente de que sea el MSX q sea? ¿Lo fuerzo o eso es "incompatible" con el standard?

Yo suelo hacer una cosa para ver si me paso o no de ciclos... Muevo un sprite por la pantalla a píxel por interrupción. Si el sprite se ralentiza (si el movimiento no es suave) pues... demasiado lento.

Puedes forzar todos los modelos de MSX2 o superiores a 50, claro, como hace el Manbow 2 (mínimo MSX2). El problema es que si tu juego es de MSX1... pues que no podrás modificar un MSX1 que vaya a 60, como los japonenses, for eksámpol.

Para ver de una forma muy gráfica lo que tarda una rutina en relación con la interrupción, lo que suelo hacer - Sap también es muy fan de esta técnica - es cambiar el color del borde al inicio de la V-Blank (reescribir el valor del registro 7 de la VDP) y hacer otra vez lo mismo al final de la rutina en cuestión. Así puedes ver de forma gráfica lo que tarda. Cuanto más ancha sea la franja de color, más lenta es la rutina, y te permite verlo en relación a la frecuencia que empleas, entendiendo que la pantalla en vertical entera supone aproximadamente un 100%. Es una aproximación, porque evidentemente se consume tiempo en la vuelta de los cañones a la posición inicial (benditos CRTs), pero sirve, es muy intuitivo hacerlo así y muy fácil de implementar.

¡Por supuesto! Es fundamental :D


De hecho, en las primeras versiones del bucle de juego siempre cambio el color para cada acción a realizar, lo que me da una idea de si es posible, o no, hacer las cosas de una forma o de otra.

La ventaja que tiene esta técnica es que la puedes meter directamente en los MSX y así mides en la máquina real la carga de la CPU. El objetivo siempre es que la franja que representa el volcado a VRAM esté dentro del VBLANK (es decir, que no llegue al borde superior de la pantalla visible).

En el QBIQS lo que hago es:

1) Trato la interrupción (que hace lo mínimo, mínimo).
2) Vuelco todo a VRAM (y a 60hz cabe todo dentro del VBLANK, con lo que va más deprisa).
3) Vuelco los registros de sonido al PSG. Realmente no es necesario hacerlo justo al terminar la interrupción, ya que por unas milésimas de segundo no se nota nada.
4) Realizo el cálculo del siguiente frame visual, incluyendo todo lo necesario (lectura de joysticks, scroll, parallax, movimiento de sprites, naves, choques, borrado...)
5) Llamo al PT3 para que calcule los registros del PSG para el siguiente frame.
6) Llamo al ayFX para que sobreescriba dichos registros con los efectos de sonido.

Básicamente eso funcionaría para casi el 95% de los juegos.

Lo único que he encontrado es una línea en el changelog del NO$MSX:
z80/vdp: changed cycles per 50Hz from 71592 to 71328 - closer to reality

Así que al menos a 50Hz el valor es 71328, y si multiplicamos por 5/6, el valor para 60Hz sale cosa así de 59440. No se hasta que punto estos valores serán exactos, ni si se mantienen para todos los modelos.

Muchas pero que muchas gracias por las respuestas :)
Me ha ayudado mucho a recolocar parte del codigo y hacerlo mucho más optimo para que funcione bien en el VSYNC.
Espero poder enseñaros parte del trabajo (o completo) para la RU.
Gracias una vez más.
Arigatoo.

Hola j4mk3,

En el emulador AmiMSX que programe para Commodore-Amiga usaba 202 T-States de CPU por cada scan-horizontal de video, esto da un total de:

PAL (50Hz) 313 scan-lines * 202 T-States = 63226 T-States de CPU.
NTSC (60Hz) 262 scan-lines * 202 T-States = 52924 T-States de CPU.

Sin embargo olvidate de ir contando los T-States... Lo mejor es que uses lo que te comenta pitpan de cambiar el color del borde, es lo mas practico. Yo siempre lo he echo asi y me ha ido muy bien.

Saludos

Juan

Bueno, Juan, depende de lo que quieras hacer. Para código síncrono, obviamente, tienes que contar de forma exacta los t-states: Seleniak, demos de Dvik & Joyrex, replayers de 1-bit, repayer de samples, Sp8 Invaders, ...

Buenas de nuevo,

Ya he estado haciendo pruebas varias con mi player PSG en la interrupcion y he aplicado lo del cambio de color del borde para ver los tiempos.
Parece que voy bien ya que creo q me sobran muchos ciclos, pero no estoy seguro si lo q veo me dice eso, a ver si me lo podeis asegurar.

Pongo de color verde el borde al principio de la rutina q salta al ahcer el VSYNC y lo vuelvo negro de nuevo al salir.
Se me empieza a pintar de Verde justo cuando termina la parte inferior de la pantalla, es decir, me hace todo el margen inferior de la pantalla de verde.
De vez en cuando se pinta un trozo de la parte superior, solo 3-4 lineas creo.
El resto del borde es negro.

Esto significa q estoy consumiendo muy poco del VSYNC, no ?
Es normal q se empieze a pintar ahí justo al terminar , osea en la Y=192 ?

En otra prueba, lo he aplicado a una pequeña intro con graficos, animacion y musica, de vez en cuando no se pinta ningun trozo verde. Se queda en negro. Veo como la franja verde inferior parpadea. Lo he puesto en el BLUEMSX frenandolo mucho y efectivamente, hay veces q no se pinta nada verde.
Eso significa que me estoy saltando Frames verdad ? que estoy dentro de la rutina de VSYNC más de la cuenta ? o es que me quedo fuera demasiado rato con un trozo de codigo en DI muy largo ?

Hola j4mk3,

- El VDP lanza la interrupcion de vBlank al Z80A justo cuando termina de pintar la ultima linea de la pantalla, por lo cual es correcto que se te empieze a pintar de verde la pantalla a partir de la linea 192. (o 212) luego el color verde continuaria viendose por la parte de arriba de la pantalla a no ser que tu rutina de interrupcion ya haya terminado de ejecutarse con lo cual habria restaurado el color del borde en negro.

- Cuando el color verde parpadea es porque tu rutina se sale de frame, el efecto de parpadeo ocurre porque al ocurrir este desbordamiento de interrupcion, la interrupcion de vBlank ya no se lanza al final de la pantalla, sino... justo cuando termino el codido de la interrupcion anterior, vamos... en cualquier momento con lo que todo se "desincroniza"

- El codigo que tienes en la interrupcion siempre ha de estar con DI para evitar problemas.

Espero haberte ayudado...

Saludos

Juan

Gracias Juan por tu respuesta.
No me queda muy claro si el parpadeo se em salta frames o no. Parte del codigo de esa intro está realizado por NapalM, que creo q conoces ;) y creo q lo que ocurre es que hace un DI por ahí en el codigo fuera de la rutina de interrup que se está mucho rato  hasta volver a EI, con lo cual se salta algún frame. Me parece que hace DI por ahí cuando escribe en el VDP o algo así. Ya lo revisaremos a ver. Yo es que estoy más con el PSG haciendolo "cantar" :)

Superutil 007. Gracias.

Hola j4mk3,

Si, conozco a NapalM de hace varios años... La semana que viene lo vere en la ru de MSX...

Una forma de averiguar si ese codigo de NapalM te esta ocasionando problemas con la interrupcion de vBlank seria hacer la siguiente prueba:

- Deja la interrupcion de vBlank completamente vacia excepto lo de poner el color del borde en color verde y luego en color negro (deja algunos NOPs entre medio para que el color verde no sea demasiado pequeño de ver)

Prueba tu codigo ahora y fijate en la linea verde:

- Si la linea verde aparece SIEMPRE en el mismo sitio, al final de la pantalla, es que ese DI que decias no afecta.
- Si la linea verde aparece en diferentes lugares de la pantalla de forma aleatoria, es que ese DI te esta "fastidiando"

Espero que te sea de ayuda...

Si vas a la ru de MSX ya hablaremos... yo estare en el stand de "la plataforma invitada"

Saludos

Juan

(http://dl.getdropbox.com/u/609776/forums/FURASTER.PNG)

Muy gráfico, lol :saimazoom:

Lo suyo sería hacer un GIF animado con parpadeo y todo, para que se viera que incluso tarda más de 1 frame. Pero hacerlo es tiempo que se puede invertir en la MSXdev, LOL!

Al hierro!

Que conste que, aunque no diga nada, estoy imprimiendo cada comentario que haces acerca de tu posible participación en el MSXdev y mandándolos a un notario ;D ;D ;D ;D ;D ;D

Y mientras estás en el notario, yo estaré haciendo gráficos :joe: ¡Sólo quedan 3 meses! ¡Y aun no sé de qué leches voy a hacer el juego!

¿Futbol femenino? ¿Simulador de cabra? ¿Aventura conversacional en arameo? LOL! :o

"Eres una cabra"

1. Balar
2. Pastar
...

LOL! Me has convencido. Acabo de enviar el registro a la MSXdev'09 :joe:

Por cierto, ¿de que iba este thread antes de que nos fuéramos por las ramas de mala manera? ;D

¡Pues si que ha enviado el registro, si! :o :o :o. ¿¿Genre: "VR Lamb simulator"?? (<-esto es coña, eh?)

¡A ver si tengo un rato y actualizo la web del concurso esta noche! ¡A ver si cunde el ejemplo con más registros! (Kun?, Dionisio?, pitpan?, kabish?, resto del mundo?)

Poor cierto, chicos... volved al topic, please!!!  2gf:)

Jajaja! :joe:

También está la posibilidad de una aventura conversacional de fútbol ;) LOL!

Os prometo que en el próximo post vuelvo al topic, que esto de los ciclos es lo que mola :P Pero mientras tanto:

Pues haberlas, haylas (más o menos) ;)

(http://download-a-saco-2k2.galeon.com/captain2nes.jpg) (http://www.gry.tportal.pl/gryonline/nes/c/image/captt2.png)

(http://www.consoleclassix.com/info_img/Tecmo_Cup_Soccer_Game_NES_ScreenShot2.jpg)


 ::offtopic::
Venga, todos back on topic!!!  ;) ;) ;) ;)

Ese mítico CAPTAIN TSUBASA (aka OLIVER Y BENJI en castizo castellano). La versión de SNES es todavía más espectacular en el apartado gráfico que la original de NES. Indispensable para aficionados al fútbol nihongofílicos.

Volviendo al topic, si tu código es asíncrono, lo más práctico es el tradicional cambio de color de borde. Asigna un color a cada rutina y así tendrás una idea gráfica de cómo se reparte el tiempo de frame en cada una de las tareas.

Interesa también que no haya demasiada diferencia de tiempo entre las varias bifurcaciones que puede tomar tu programa, intenta que tus algoritmos estén bien balanceados, sinó puede darse un caso en que varias rutinas tarden más de lo normal y pierdas algún frame. Eso lo puedes ver por la estabilidad de las franjas de color. Si te es posible, es interesante probar el llamado worst case scenario: la situación en la que todas las rutinas pasan por las bifurcaciones más lentas.

En cuanto a código síncrono, entonces sí que es necesario llevar una contabilidad detallada de los t-states (incluyendo las esperas extra en los ciclos M1). En el caso de Firelite, la rutina de música del Seleniak, el bucle generador de audio siempre tarda los mismos t-states, y se ejecuta en en bucle sin fin. La interrupción se encarga de, rápidamente, automodificar el bucle para que vayan sonando las diferentes notas, samples y modulaciones, así como la lectura de los dispositivos de control y animaciones.

WTF?!? OMG!!!! LOL!!! :malaika:

Justo lo que les digo a mis alumnos: análisis del coste en el caso peor. Lo único es que alguno tiene una imaginación desbordante. Tenemos por aquí colgada una gráfica de una práctica de hace años en la que se ve que el coste del algoritmo decrece a medida que el tamaño del problema crece :o :o

Aportaré también mi granito de arena: procura hacer las pruebas a 60Hz, ya que a esta velocidad de refresco tienes menos ciclos por frame. Si las pruebas las haces a 50Hz puedes encontrarte una desagradable sorpresa cuando ejecutes el programa en un ordenador a 60Hz. Al revés esto no sucede (hablando de código no síncrono, por supuesto).

Y ya que estamos hablando de ciclos y utilizando acrónimos, os diré que mi poca experiencia con el código síncrono es un auténtico PITA. Y eso que sólo he hecho reproductores de sonido digitalizado de 1 bit y 4 bits. Salvo que seas un valiente, no te metas. Se puede hacer casi todo con código asíncrono. El código síncrono sólo te servirá para temas de audio al forzar el PSG a hacer cosas muy raras o gráficas, aunque en el caso del MSX(1) tampoco me fiaría demasiado...

Como cualquier otra cosa en programación, el código síncrono (así como el automodificable) debe utilizarse sólo en situaciones justificadas, ya que el asunto pasa de ser algo puramente algorítmico a cirugía pura y dura.

Tal como dice pitpan, se suele usar para exprimir el PSG y/o lograr efectos gráficos que de otra manera no serían posibles, aunque yo no las calificaría de "muy raras", ya que el propio PSG está preparado para ser usado como un DAC por la CPU al poner la frecuencia a 0, y la mayoría de registros del VDP no estan latcheados (al contrario del Atari ST, por ejemplo) para que puedas hacer efectos gráficos en tiempo real.

En cuanto a fiarse de los tiempos, estad tranquilos, porque en su día hice una inmensa batería de pruebas para el scroll 3D de un juego tipo Street Fighter a base de código síncrono, y los resultados en todos los modelos fueron exactos como un reloj suizo. Así que si la máquina es 100% compatible MSX el código síncrono ha de funcionar bien. Incluso hay métodos para compensar por posibles tolerancias entre modelos.

Otra cosa curiosa fruto de usar código síncrono es que, a pesar de funcionar en todas las máquinas reales, en varias ocasiones han reventado gran cantidad de emuladores, lo cual es bueno ya que gracias a ello se han podido mejorar dichos emuladores :)

Como curiosidad os diré que existe una demo acabada con música digitalizada, animación y split screen que hicimos cuando estaba en Matra que es 100% código síncrono. Del primer al último t-state.

Por razones internas, se decidió no publicarla ::)

¿Ni siquiera un vídeo? No se puede decir que hay tarta de chocolate y no dejarla ni oler... :P :P

Soy así de puta. Ya me conocéis. LOL!

Bueno, realmente prefiero ser discreto con todo el material de la época Matra. Si se decidió no publicarlo, creo que es mejor no hacerlo sin consentimiento de los demás miembros, ya que a parte de que fue una decisión corporativa, incluye material que no está creado por mí.

Lo que sí mostraría si lo encuentro sería un video del matamarcianos horizontal multiplano parallax que presentamos en la última RU a la que asistí. Ahí todo el material era de mi cosecha.

Pero eso será si lo encuentro, claro :-\

Ostras, esa demo sí que la recuerdo.  Era una demostración de varios juegos en los que matra estaba trabajando (o pruebas para futuros juegos), entre los cuales estaba ese matamarcianos horizontal.
En el stand de MATRA recuerdo que había incluso una recreativa con el moskow 2024

Qué grande fue esa RU. :)

Saludos

Makinavaja

Que habeis hecho con este post !?!  :'( :'( :'( :'(
Si es que salgo de vacaciones y me encuentro la casa revuleta !
Ay Madonna ! XD

Menos mal que luego volveis al topic.

Deciros que ya tengo claro todo lo de los ciclos y tempos, interrupciones,frames, hertz, etc. Me estan quedando cosas muy pocholas a mi y a mi compi de grupo Napalm. A ver si esta Ru os enseñamos cositas chulas. ;)

Tranquilo, que tengo programada una interrupción a 0,0000001 Hz que me hace volver al topic ;D

¡Eh! ¡Pocholo tu!

Inculto Napalm ! :) XD
http://buscon.rae.es/draeI/SrvltGUIBusUsual?sourceid=Mozilla-search&LEMA=pocholo&TIPO_BUS=3

pocholo, la.

1. adj. coloq. p. us. Bonito, atractivo o agradable.