Karoshi MSX Community

Ehum, ¿alguien compartiría conmigo -por el amor de dios- la sabiduría de las transferencias rápidas a VRAM (esto es, sin usar la BIOS). Para una demo que ando preparando necesitaría transferir 1536 bytes a VRAM en un solo frame, ya se que es un poco bestia, pero...

Además temo el asunto de las incompatibilidades con las diferentes máquinas... ¿alguien que pueda construir una rutina sólida y reutilizable -léase snippet- con comprobación de cuales son los puertos de lectura/escritura de VRAM utilizados por el FTP y demás?. He estado buscando pero solo he visto pequeñas reseñas de OUTs sin dejar las cosas muy claras.

Notese que quien suscribe es un completo neófito en hacer burradas con el VDP y que siempre ha sido muy formalito y ha usado siempre la BIOS en sus relaciones sexuales ;).

Y asi deberia seguir siendo!  >:(

:P Y a todo esto... cuanto es el limite teorico usando la BIOS? Me parece que se comento, pero es por no buscar...  :-[

Por el tema de las incompatibilidades yo no me apuraría. Pero si quieres hacerlo bien, tienes que leer las posiciones de memoria 6 y 7 del slot 0-0, es decir, de la BIOS. En cualquier MSX sin tunear, tendrás

?HEX$(PEEK(&h0006))
98
Ok

Ese es el puerto de datos. ¿Cómo usarlo?

Pues bien sencillo desde ensamblador:

LD A,[0006h]
LD C,A

Y a partir de aquí, en lugar de utilizar OUT [nn],A habría que usar OUT [C],A o las instrucciones parecidas de bloques, OUTI, OTIR, etc

Mi recomendación: pasar de todo. Asume que 98 y 99 están siempre ahí. De hecho, sólo cambiaría para MSX1 con ampliación externa a MSX2, pero seguirían teniendo en 98 y 99 los puertos del TMS9918, así que ningún problema ;)

Y con OUTIs llegas bien a 1,5 KB, incluso a 60 Hz, siempre que no quieras copiarlos "muy arriba" en la pantalla.

Por favor reivindico que es conteste a MsxKun, me resulta interesante la pregunta.

Thank you (<- Es lo unico que se de inglés)

Creo que ronda los 800 bytes o así, ¿no?  ??? ... no se si habrá alguien que nos pueda dar el dato exacto...

Mola la pregunta ;D

realmente para transferir 600h bytes yo no usaría OUTI porque, no sale mucho mas rentable:


1 OUTI =16 t-states
1 OTIR=16/21 t-states

es decir, un  OTIR cuesta lo mismo que un OUTI si no llega a B=0 que sale 5 t-states mas caro.

si hacemos:


sale 5*6=30 T-states mas caro que si metemos una ristra de 600h OUTIs seguidos (600h bytes ?) es decir, ganamos la escritura de 2 bytes tirando por lo alto. Eso es cogersela con papel de fumar.

Otra cuestion es si es posible volcarlo todo en un solo frame. Prueba a ver ;D

Voy a ser mas claro, se puede hacer una transferencia de 768 Bytes (osea un screen 1 completo) y algo más(32 bytes mínimo) desde la Bios. O para estas cantidades ya es mas apropiado usar los puertos.

Gracias.

Gracias por vuestras respuestas. Voy a hacer un intento y os cuento el resultado. Merece la pena hacer la prueba, ya que sin esta transferencia rápida el programa correría a 12,5 fps, y con ella podría conseguir llegar hasta los 16 fps, lo cual sería todo un avance. Un frame ya lo gasto procesando todo el render, otro frame para presentarlo en pantalla (o dos, si uso las rutinas de la BIOS para ello), y el otro para detectar el movimiento del personaje, colisiones, etc... :'(

Y, ¿alguien tiene el dato de solicita Jos'b?. Yo nunca he sabido exactamente cuantos bytes puedes pasar en un frame usando BIOS, pero creo que, si tu intención es pasar una pantalla entera del mapa de nombres y algo más para sprites vas a andar bien pero muy cerquita del límite ;), depende de qué mas cosas hagas dentro del frame aparte de la mera transferencia a VRAM, claro...

¡Veo que cada vez más gente se vuelca al lado oscuro! ;)

Respecto a la velocidad del volcado, yo no consideraría únicamente eso. También tienes que tener en cuenta el tiempo que te roba la interrupción de la BIOS cada uno de esos frames. Si quieres rascarle un buen pico, este hilo de Sapphire no tiene desperdicio:

http://www.msxgamesbox.com/karoshi/index.php?topic=212.0

Y respecto al volcado a VRAM yo haría varias consideraciones :

- Los consumos en ciclos son :
Así pues, el OUT (N),A es la instrucción de volcado más rápida que hay, el OUTI la supera gracias a que incluye un par de operaciones sobre los registros del Z80. El OTIR es bestialmente más potente que los anteriores, hay que tener en cuenta que si ponemos 600 OUTIs seguidos tendremos un consumo extra de 2T por cada OUTI, 600x2=1200T contra los 2T extras que consumirá el OTIR (¡se te olvidaron los ciclos de espera M1 Wyz ;)!). Una pena que definitivamente no se pueda usar en los MSX de primera generación, ahora que ¿os imaginas lo potente que es en un TR?; pues de hecho es (mucho) más rápido que usar el VDP :P
Respecto a cual usar; pues dependerá de lo que se quiera volcar y de su geometría en pantalla. ¿Te acuerdas aquel comentario de Sapphire hablando de la "multitarea"?, si por ejemplo, se trata de un volcado en el que el ancho no es de 32 bytes (si hablamos de NAMTBL) y por tanto te ves obligado a sumar una cantidad al puntero a la VRAM, puedes hacerlo de manera que esta operación sea el propio retardo, vamos que procura no usar NOPs, que eso es desperdiciar el Z80 :D.

- Está claro que el VDP de los MSX1 no soporta un flujo continuo de datos, necesita forzosamente alguna pausa entre OUTs . Esa es la razón de porque no funciona el OTIR en los MSX1; bueno, para ser precisos si que funciona; pero cuantos más datos le hagamos volcar el riesgo de que se nos vaya a la porra se incrementa. Lo mejor es usarlo para transferencias mínimas.

- La pausa que tenemos que dejar es lo que levanta más discusiones. Históricamente se hablaba de 8T, recientemente dvik en un hilo de MRC comentaba que se necesitan 16T (en ningún caso estoy contanto los ciclos empleados por el propio OUT), la BIOS deja 40T y yo empíricamente he llegado a dejar lo mínimo, 5T y ha funcionado.

- Hay muchos modelos de MSX1, no se cual se puede considerar el más lento. Personalmente, el HB-75P lo tengo considerado como equipo lento, únicamente porque fue de los primeros en llegar a España, la pregunta es ¿cuales son los primeros modelos MSX1 que aparecieron en el mercado?. Ya se que probablemente esos modelos incorporaran memorias lentas en sus primeras series y que luego se actualizará su hardware; pero es por tener alguna referencia. Con esa información se podría tratar de averiguar, a base de testeos, cual es el mínimo retardo necesario para que funcione en el 99,99% de los aparatos.

En el "Caverns of Titan" yo tengo las siguientes estructuras:

Funciona en todos los equipos que he probado. Si le quitas el NOP se va al carajo. Lo podeis comprobar en el texto parpadeante de la pantalla inicial del juego.

E indefinidamente repites las anteriores instrucciones. Funciona bien para todo lo que lo he usado : caracteres animados sobre todo (cascadas, puerta, rayos, etc.).

Idem que el anterior. Lo uso en la rutina de impresión de carácteres.

El OTIR sólo lo uso en la rutina de BiFi de cambio de paleta, que como son pocos bytes no pasa nada. ::)

Bueno, ya está bien, que me duele muuuuucho la cabeza y empiezo a no tener claro lo que he escrito :)

P.D.: ¿Lo de los 3,5Kb era broma, no, Robsy? :o

Pues no, no era broma. De hecho, la VRAM traga como una condenada. A ver si puedo hacer una "demo" con lo que tengo y ver qué tal funciona en más equipos MSX. Por supuesto, en BlueMSX/openMSX funciona bien, y también en mi SANYO MPC-100, que es un equipo tirando a lento. Prepararé una ROM y os pediré que la probéis en MSX reales, a ver si aguanta.

Pues las pruebas son satisfactorias. Prepararé algo un poco más llamativo, para que no creais que os estoy tomando el pelo con algún truquillo de feria, y veréis un video a 50/60 Hz y media pantalla. La aplicabilidad para juegos es aún discutible, pero creo que tengo CPU suficiente aún como para además incluir un replayer ligero funcionando sincronizado con el refresco.

¡Genial!, ¡queremos ese BIN/ROM para ya!. ;D

La verdad es que tengo bastantes ganas de verlo funcionando; pero sospecho de que la razón de la VRAM trague tanto es que tu SANYO te ha salido bueno, bueno... ;)

He estado haciendo cuentas y ni por esas...veamos:

El retardo base en los accesos al VDP es de 2 microsegundos, por lo que habrá que calcular cuantos ciclos de espera supondrán para un Z80 a 3,579545Mhz

1T/3579545 = 0,000000279 segundos/ciclo

0,000002/0,000000279 = 7,16845 ciclos

Suponen 7,16 ciclos del Z80 de los MSX, ya tenemos pues que hay que esperar entre 7-8 ciclos de media. Luego en función del modo de pantalla habrá que esperar (o no) un poco más antes de poder acceder al dato en la VRAM (tanto da leer como escribir). Para screen 2 tenemos un retardo extra que va de 0 a 6 microsegundos, por lo que, en el peor de los casos tendremos que esperar hasta 28T-29T. La excepción la tenemos únicamente durante una ventana que dura 4300 microsegundos tras el retrazado vertical, en ese intervalo el retardo extra es cero. Durante ese intervalo basta con esperar esos 7-8 ciclos iniciales.
¿Cuantos bytes podriamos transferir teóricamente durante ese intervalo (que es el óptimo para transferir datos a toda velocidad)?. Para calcularlo primero averiguamos cuantos ciclos tenemos disponibles durante ese lapso de tiempo :

(4,3ms * 3579545) / 1000ms = 15392 ciclos

15392 / 18 (ciclos OUTI) = 855 instrucciones OUTI

Así pues, podriamos encadenar 855 OUTIs uno detrás de otro sin esperas, lo que da poco más de 1/6 de pantalla o 3 lineas y pico de caracteres. A todas luces insuficiente. :(

Y si definitivamente si no accedemos al VDP en ese intervalo, hay que esperar un poco entre acceso y acceso.

He hecho también alguna preguntilla por el MRC para ver si me aclaran algunas dudas que tengo... ???

Como es probable que con tanto número me haya liado, espero que algún matématico que ronde por aquí le eche un vistazo a las cuentas y razonamientos en general. A ver si resulta que está más o menos correcto :P

Vamos que me muero de ganas de ver esos experimentos ;D

No tengo ganas... se me han quitado al leer que igual tengo que retocar las rutinas que hicimos para meter más retardos entre OUTI y OUTI...

 :'(

Quita, quita, ni se te ocurra, piensa que la media de retardo viene a ser de 18T y (si me lo confirman en MRC) resulta que el OUT también podría contarse; así que las espaldas estarían cubiertas. ;D
Y todo ello suponiendo que no envies mucho más de 900 bytes, si te apañas con eso, casi seguro que lo puedes hacer a toda caña sin preocuparte por nada. Yo también me he puesto a hacerme algunos programillas para ver si hay un fundamento "práctico" en todo esto o como siempre del dicho al hecho hay mucho trecho.

Ummm... entonces bien.

¿Más de 900 bytes? ¡Ni loco! El scroll pixel a pixel que viste sólo necesita 240, 256 o 480 bytes (según el modo de juego) y el que no has visto (pero tienes que ver, creo que merece la pena el efecto visual) sólo transfiere 440 bytes por frame.

Graaaasiaaa!
--
F.

P.D. A ver si hacemos otra quedada entre los de Madrid y nos vamos a algún otro restaurante chulo o repetimos en el "Bar La Peña". Adoc, ¿te apuntas?

Bien, parece que se van aclarando las cosas  ::) el caso es que, Jon aun no nos ha dado a conocer sus resultados.

..Saludos desde Palma de Mallorca, tierra de MSXeros ;D

¡Que lujazo!; pues entonces puedes plantearte incluso el hacer una versión deluxe-ultra-rápida en la que no haya esperas entre OUTs o incluso usar OTIR ;D; siempre y cuando la hagas nada más empezar el Vblank, claro.


[ENVIDIA]¡Anda!, ¿y que haces tú por allí pillastre? :D[/ENVIDIA]

WYZ: El Jon anda a media asta con mugollón de curro -y no me refiero al curro MSXero...-. Ya lo sabes tu bien, que me queda poquito poquito para mandar a betatestear a los computeremuzoneros la bestia de na-th-an adaptada a nuestra querida norma japonesa... puff, y el MSXdev por medio, dios, quiero dias de 48 horaas!. Por cierto, un lujazo leerte por aquí WYZ, ya sabes que esta es tu casa - o tu bar, lo que prefieras ;) -

jltursan: El scroll pixel a pixel horizontal y a todo color de Malaika será casi casi fullscreen y transferirá 576 bytes ;) (ahora bien, necesitará todo un frame para generar el frame siguiente, con que el scroll correrá a 25 fps -> lo cual es muy asumible y el resultado es bastante acongojante) ;)

Un scroll con esas características a 25fps está más que genial. De todas formas, ¿has probado a intercalar la transferencia de un byte a VRAM con el cálculo del byte del siguiente frame? Piénsatelo.

Y recuerda que en algún momento tendremos que hacer entre ambos un how-to sobre scrolls pixel a pixel en MSX1 :D

Nah, demasiado cañero para mi cerebro dañado por el alcohol. Además ya tengo la estructura de trabajo por cada frame muy bien definida y no voy a cambiar el diseño del programa. De todas formas es una idea ingeniosa (a la par que malévola) ;D

Sure! ;)

Y los tenemos de todos los gustos y colores: horizontales, verticales, parallax, con transparencias... ;D ;D ;D

Pues me gustaría que probarais la siguiente ROM: entrelazado 512x88 (http://www.robsy.net/int51288.rom).

Se trata de una prueba un poco chunga en la que intercalo dos imágenes de 256x88 originadas desde una imagen original de 512x88. Al utilizar el refresco, pues se consigue que todo parpadee muchísimo, pero la imagen gana en calidad, ciertamente, frente a cualquiera de las versiones de 256x88.

Lo llamativo del programa no es la idea de entrelazado, que es bastante antigua. De hecho, las imágenes de 107 colores de Daniel Vik o el modo de texto en dobles columnas de jltursan, son ejemplos de lo mismo. Lo curioso aquí es la transferencia a RAM: estoy pasándole al bueno del MSX 2816 bytes a VRAM por frame. Es el equivalente a 256x88 píxels de patrones monocromos. No hay trampa ni cartón. Por supuesto, no está al límite: se podrían llegar -calculo- a unos 2900-2950 bytes por frame. No lo he ajustado para 60 Hz, así que sólo debería funcionar en ordenadores MSX a 50 Hz. Eso sí, probadlo y si tenéis pegas, comentádmelo: modelo, casuística.

A 60 Hz, calculo que nos quedaríamos en unos 2304 bytes seguro, es decir, equivalente a 256x72 pixels de patrones monocromos. Incluso en este peor horizonte, estamos hablando de más de 2 KB por frame. Y se puede hacer.

Truquitos a tener en cuenta: sin BIOS, OUTIs a lo burro, pausas adicionales al finalizar v-blank.

Siento que mi primera estimación de 3,5 KB/frame fuera un poco exagerada. Aun así, me he quedado a las puertas de las 3 KB/frame a 50 Hz, lo cual creo que es un buen logro. Estamos hablando de actualizar media pantalla en monocromo por frame. Y si necesitamos otro frame para los cálculos, nos quedarían juegos muy dinámicos funcionando a 25 Hz.

Por cierto, la foto, aunque mala, es de dos amigas de la facultad. Saludillos para Lastor y Zut. ;)

Ah! Y no hay trampa ni cartón: no desactivo la pantalla en ningún momento y, como imaginaréis, no se trata de optimización de patrones y cambios en la tabla de nombres. Podéis mirar el estado de la VRAM desde el debugger del BlueMSX. Os podéis fiar de Robsy, palabrita.  ;D

Si la cosa no funciona, es que falta incluir retardos. Pero creo que he incluido los suficientes. Mi SANYO MPC-100 se lo come sin problemas.

Y ahora me vuelvo a seguir con mi juego, que ya va tomando forma. Por supuesto, mi juego utiliza la BIOS a rajatabla, sin movidillas friki-VRAMeras.  ;D

La leche, no me lo puedo creer... ¿tanto traga la VRAM?. A ver, le metes 2960 bytes a piñon con OUTIs correlativos y después empiezas a rebajar la presión y le metes el recopón de OUTIs, pero esta vez poniendole dos NOPs de descanso entre medias... ¿por que ese cambio?. ¿Es que se llega a una 'zona peligorsa'? ???, la verdad, no entiendo por que le puedes meter los OUTIs sin más -y los acepta-, y luego despues bajas el pistón..., la imagen está en la zona baja de la pantalla, ¿si estuviera más arriba te cogería el refresco?... Respuestas, respuestas ;). Por cierto, fantástico socio!. ¿Que tal un pequeño texto a modo de tutorial?. En cuanto pueda lo probaré con mi Sony HB10P.

Pues sí, socio, ésa es la idea.

He establecido la duración del v-blank en ciclos, y le he metido una ristra de OUTIs equivalente a esa duración. A partir de ahí, sigo haciendo OUTIs pero con dos NOPs de retardo entre ellos. Así consigo llegar al total. Lo he puesto en la parte baja de la pantalla porque la idea es poder escribir en VRAM fuera del v-blank, y así, mientras se está dibujando ya la parte alta de la pantalla se puede volcar info aún a VRAM no renderizada (parte baja, en mi caso). Hasta donde sé, 2 NOPs más la duración del propio OUTI son retardo suficiente para que no se pierda nada de lo que se manda a VRAM.

La solución es ideal para juegos, por ejemplo, de carreras: en la mitad superior de la pantalla, marcadores, horizonte con scroll falso, etc, que se actualiza en frame PAR junto con los cálculos de pantalla gráfica; en el frame IMPAR se vuelca la mitad inferior de la pantalla, con precision de pixel. Sirve también para arcades laterales, etc. Mil opciones!

Por no hablar de video a pantalla completa en screen 3 a 50/60 FPS!  ;D

Pues parece que al final me voy a quedar sin probarlo en mi Sony MSX1; por lo que se ve, se me ha fastidiado por completo la disquetera externa.... :'(.
Lo he probado en un MSX2 y se ve tal que en el BlueMSX, el efecto es muy llamativo y cuanto más miras la imagen más definición gana :).
El chorro inicial de OUTIs parecen más de los que debería poder soportar el VBlank en todos los MSX1; pero bueno, hay que probarlo primero. A ver si algún alma caritativa nos envía algún comentario. Un problema que va a haber al testearlo es que va a ser dificil verificar que haya basura en pantalla debido a la naturaleza de las fotos, habrá que fijarse un poco.
Viendo todo esto se me ha ocurrido una nueva maldad sobre el VDP, voy a probar a ver si se me sale (porque poderse hacer seguro que se puede). >:D

JL: espero ansioso para saber de qué se trata...

Respecto a la imagen, aunque sea muy pixelada, no dará problemas para verificar si se pierden datos: si se pierde un único byte, quedarían todas las líneas siguientes afectadas. Los datos no se corrompen en el caso de time-out de VRAM, simplemente no se escriben y tampoco se actualiza el puntero a VRAM.

De todos modos, la idea de entrelazado horizontal o vertical monocromo me parece un poco cafre. Lo hice horizontal, y quizás hubiera sido mejor hacerlo vertical. Haré una prueba, para ver si la imagen gana alguna calidad, aunque no lo creo. Y, por supuesto, no probéis la ROM si sois o creeis que podéis ser epilépticos. Consulte con su médico o farmacéutico antes de utilizar esta ROM :D

Esta tarde lo probaré en mi sony hb10p, que tiene un vdp un tanto especialito. Si ese lo traga, es que no hay problema ;)

Oye viejo, ¿podrías de paso probar la última rom que te pasé (SFT) a ver qué tal se traga tu hb10p ese scroll ?

Si es que no lo hiciste ya, claro...

Gracias :D

Vale Sapph, la probaré también. El caso es que robsy y yo hemos detectado que en particular ciertos SONY tienen el VDP más caprichoso de lo normal y que no tragan con ciertas cosas, como modos mixtos de pantalla, etc... es el caso del HB-10P, así que, como banco de pruebas gráfico me viene de perlas.

Ya os contaré como me ha ido ;).

A ver, feos anti-BIOS, primero:

- Mi HB20P es mas bonito que el 10P de Jon. (o lo era cuando no tenia tanta humedad a cuestas)

Segundo, la rom no me tira en el 8020 :( Al menos, en el execrom, desde la CF, no va, carga y se queda pasmada, o me vuelve al DOS, segun le da.

Voy a probar otros cargadores y ahora digo. Uiiiiiiii como no tire...

La ROM ocupa la página 0, es posible que tenga algún problema por eso...
Yo sólo la he podido probar en un 8245 e iba como un tiro; pero claro, en un MSX2 no tiene gracia. :(

La pagina 0? Que malvado!  >:(
Bueno, el caso es que con el rima.com si que ha cargado. Y va fino. Asi que es Philips 8020 compliant.

El parpadeo, tal y como tengo yo el ojo ultimamente, pos no se aprecia tanto tanto.

Y ahora, a lo que vamos, las amigas de la foto, estado civil, medidas.... ?

El HB-10 y otros SONYs son lo más puñetero que hay, palabra. Por ellos abandonamos el modo mixto, que era un chollo! Pero claro, hay mucha gente por ahí con HB-10, HB-20, HB-100, HB-200, HB-75, HB-55, HB-501, etc. Y mucho me temo que todos ellos no soportan el modo mixto. Así que 3 bancos a redefinir en cada SONY.

Gracias por los comments. Por supuesto que sí, página 0, BIOS-free ROM!

Yo tambien lo probé en mi 8020/00, a través del waver, y rula. Como cosa curiosa, en algunos lugares los pixeles "grises" se veían azules y en otros verdes. Supongo que eso será más bien cosa de la tele, claro.

Bueno; pues aquí está...

Para que luego se diga que con screen 0 no se puede hacer nada ;)

woooa, beware the VDP Pirates!!! y en Screen 0!!!!

Pero esto es cambiando la tabla de patrones???. Cómo es la nueva estructura de ese modo mixto?. Explanation needed!

/me está flipando...

Eso es lo que yo quería ver ;)

Tremendo JL! :o

Se me olvidaba preguntar...poprque solo lo h probado en emuladores ¿ solo se ven  6 bit de cada caracter en este modo bitmap scr0? ¿la documentacion (*) esta equivocada al decir que se puede alcanzar una resoucion de 320x192 verdad?

Esto, Jon...

A mi me sigue saliendo lo de

¡Un error ha ocurrido!  :-\
Parece que no estás autorizado para descargar o ver attachments en este foro. 

Y necesito -quiero- ver los attachments YAAAAAA!  :'(

Edu, mira a ver si ahora puedes. Ahora, en principio, tienes TODOS los permisos abiertos, jejeje, así que ya podrías, por ejemplo, quitarle al Kun el smiley de Cyndi de la firma, si es tu gusto  ;) :D :D

Si sigues sin poder ver los attachments ahora, revisa tu configuración personal de usuario, tal vez estés desde ahí denegando algo. Y si no, pues no se me ocurre...  ???

¡A mandar!. Es un screen 0 normal, al que mediante tres screensplits se la han añadido tres bancos diferentes de patrones, entrelazado y algún que otro cambio de color. De alguna manera el resultado se parece a screen 2.
Lamentablemente esta demo se me olvidó advertir que no funciona a 60Hz, de hecho se autoconfigura a 50Hz (lo que empeora el entrelazado :(), por lo que en los equipos brasileños no se verá correctamente. Lo siento mucho; pero si ya sincronizar a una frecuencia cuesta, no te digo a dos :P


Pues para mí que sí que está rara esa documentación (por cierto, ¿cual es?), los carácteres siguen teniendo 6 bits de ancho; así que el ancho en pantalla es de 240. Además como 40 no es múltiplo de 256, es más cómodo reducir la dimensión vertical a 144. En total se queda pues en 240x144. Podría pensar que con algún truquillo se podría hacer algo más; pero teniendo en cuenta que este VDP ya ha sido destripado en muchos otros aparatos y nunca he visto resoluciones extrañas, tiendo a pensar que los 256x192 reales es lo máximo a lo que podemos aspirar. :(

Pues sigo igual: en blanco. "Parece que no estás autorizado etc., etc."  :(

Pues no es nada del foro, Robsy, ahora eres prácticamente un administrador en cuanto a privilegios. Mandame to id y password por email, y así puedo hacer pruebas conectándome como si fueras tu, a ver si detecto por qué es... ¿firewall en el server del curro, tal vez?... no se, ponme la info por mail, ok?  ???

JL, pensé que estbas usando un modo hibrido bitmap/texto, pero veo que el resultado con sc0 a pelo es espectacular. Mi pregunta iba sobre esto:


Que puedes encontrar en titech pages, esa que te pedi en otro post. A mi me da la impresión de que está equivocado... aunque nunca se sabe.

La verdad es que no me las he mirado mucho; pero curiosearé un poco. A mí, por lo menos esa descripción me parece bastante rara.  ::)
En el texto, de todas formas no hacen referencia a que la pantalla tenga 320 pixels de ancho, sino a que los tercios de la tabla de nombres son de 320 bytes cada uno (40*8=320), cosa harto extraña ya que por mucho que estires los patrones sólo puedes tener 256 disponibles y si multiplicas por 3, tienes 768 posiciones como mucho. Para gestionar 960 habría que definir 1/4s de pantalla, cosa que podría haber hecho; pero que para el caso no valía mucho la pena :P.

De todas formas igual es mejor experimentar, a ver si resulta que de esta combinación de registros sale algo interesante. ;)

>:D >:D >:D >:D >:D >:D >:D >:D >:D Ni se os ocurra  >:D >:D >:D >:D >:D >:D >:D >:D >:D

Ya verás que cosas más raras pasan por el foro el 28 de diciembre... ::)

Bueno, aqui va la respuesta en Screen 1 para JL: es un doble bitmap en el que se usan 40 bytes para color.No hay sito para hacer esto asi que aparece un pequeño fallo en la parte superior izquierda de la pantalla que se debe precisamente a esa tabla de color. Seria sencillo eliminarla y tambien  sincronizarlo bien, porque esta hecho a base de HALts. Pero como el resultado es lo que esperaba y mola, pues lo pongo aqui a bote pronto. No se como llamar a este modo con doble bitmap (que suponia en este mismo hilo que teoricamente funcionaría)

Nos vemos en los bares
WYZ

Oye wyz,

es una pasada ;D ;D ;D

El codigo fuente no lo vas a hacer público ¿verdad? ;D ;D

Sip, solo lo he probado en Blue y Open y fuenciona bien. Sobre todo en Blue con la opcion sincronizacion con la freceuncia de refresco del monitor. El codigo? cuando JL desvele el suyo. ::)

¡Muy bueno Wyz! ;). A ver si mañana le echo un vistazo al código y me hago un cuadro al detalle de lo que has hecho...
Últimamente no hacemos más que retorcerle el brazo al pobre VDP ;D


¡Hecho!, en cuanto lo pula un poco (que está mu feeeeeeo) lo posteo como snippet.

Le pogo un poco de musica que me parece muy soso sin efectos.  ;D

 :god: :god: :god: :god: :god: :god:

Las tres variantes que he probado, son geniales, tanto la de Robsy, com la de JL como esta ultima con música. :D

Con unos cuantos fotogramas como estos se podria crear una animación simple pero bastante atractiva. (si se puede hacer claro está).

¡Mecachis!, ahí ya no llego... :(. Al utilizar screensplits sucesivos, unos dependen de otros cada vez más y si no mantengo el número de ciclos lo más estable posible por cuadro, se me descojonarían. He comprobado que hay una tolerancia de hasta unos 60T arriba o abajo; pero sospecho que al meter un replayer y supongo que en función de la música, podría variar mucho el tiempo de ejecución cada cuadro.
Tú que has hecho un replayer bastante ligero, Wyz, ¿como ves el tema?, ¿Trabaja un mismo número de ciclos la rutina cada vuelta?, ¿depende mucho de la canción?.
Otro gallo cantaría usando samples; en ese caso supongo que siempre se esta trabajando lo mismo cada unidad de tiempo.

Por cierto, ciertamente en el BlueMSX si se utiliza el Sync Mode "Sync to PC Vertical Blank" la calidad mejora una salvajada. Eso sí, se parece muy poco a lo que se ve en un MSX real... ::)

Sin ver el codigo de tu rutina no sabría decirte exactamente, si te puedo decir que en cada ciclo el replayer varia el numero de procesos.

Si lo que quieres es añadir sonidos ... pues puedes hacerte un reproductor sencillito a base de meterle al PSG los registros del 0 al 13 (o los que sean necesarios) en cada llamada por otro lado hacerte una captura de esos registros simplemente reproduciendo un PT3 o( un fragmento) aprovechando que tienes el codigo y en vez de hacer outs al chip guardar los registros en RAM . Al reprducirlos con la rutina de volcado de registros del Vortex sonaria exactamente igual (?). Es el replayer mas sencillo, mas rapido  y mas estable en cuestion de T-states que se me ocurre para fragmentos cortos claro.(seguro que esto se le ha ocurrido a mas de uno ;))

Por cierto, has probado en un MSX real las tres ROMs colgadas aqui? se ve algo? cuenta cuenta!!

Pues a mí no se me había ocurrido... :P. La verdad es que para una demo es una buena solución para poder usar un tracker y screensplits (o sincronización simultaneamente). Eso me lleva a pensar, ¿que estará haciendo MkII en estos momentos? :)


Más o menos. La de Robsy hubiera querido probarla en el MSX1 que de eso se trataba; pero como parece que se me ha fastidiado ya definitivamente la disquetera externa, no pude probarlo (estoy a la caza en eBay). En el MSX2 la transferencia era perfecta y viendola es cuando se me ocurrió lo de aprovechar la mezcla del blanco y del negro a lo bestia en screen 0.

La mía funciona sólo a 50Hz; pero está sincronizada tanto en los emuladores como en los equipos reales. Eso me sorprendió agradablemente ya que es prueba de lo buenos que han llegado a ser los emuladores. Se ve clavado al MSX real si en el BlueMSX se selecciona el Sync Mode que se adapta al refresco del MSX. El parpadeo es importante... :P

La tuya va perfecta a 50Hz y 60Hz, el sonido va algo acelerado en un TR (lógico), por lo demás se ve igual que las otras, el parpadeo es menos notable ya que hay menos zonas grises.

Como detalle curioso, en un TFT se ve MUCHO mejor ya que el pixel persiste más (tengo un TFT que es tirando a malo). En una tele de tubo se ve como en el emulador.

En mi MSX1 creo que no funciona (ni me molesto) porque no admite modos hibridos, como le pasa a lso sony segun explicacion de Robsy, asi que esa informacion vale su peso en cartuchos de konami. Gracias ;D

Os subo una demo con lo del otro dia, un poco mas decente. Ademas le he incluido un test de VDP que se puede bypasear pulsando espacio al iniciar.

Nos vemos...

¿Un test de VDP?, en cuanto llegue a casa lo probaré a ver de que se trata... :)

¿Decente?. ¡Ahora está redonda!, si te has currado un scroll de texto y todo... :D

Y yo sigo sin autorizar! No puedo bajarme nada! Quiero ver esos desarrollos friki-tech!

Bueno, ya he podido ver las demos, y la verdad es que tengo que quitarme la boina y recortarle el capillo: hay que ver lo que se puede hacer estrujando un poquito el VDP. Lo he conseguido gracias a mi alter ego esquizoide, Robsy_BackUp, que será quien se encargue del trabajo sucio de downloads/uploads directos al foro.  ;)

WYZ y JL: gracias por compartir esas pequeñas maravillas.

¡Anda, es verdad!. Dándote de alta como otro usuario seguro que ya habrías podido bajarte los archivos desde el principio.... :P. Además se me ocurre que así se engorda la cifra de usuarios ;D, que por cierto ya supera la centena (¿serán todos programadores y artistas? ::)).
La última de las versiones de Wyz me ha llegado al alma ya que uno de los modos gráficos del Dragon tenía unos colores similares e idéntica resolución :).

Bueno, y ese chorro de bytes y ese bitmap en screen 0 no se quedan atras. Lo suyo seria currarse una karoshi forum demo con todas estas cosillas en la que la peña se involucrara. Por cierto, Dioniso sabe de unas cosas con sprites que te dejan asi  :o

Bueno ... vamos a dejar eso para el juego. TOP SECRET!!!  ;)

(que después nos quedamos sin sorpresas)

Por cierto, enhorabuena por las demos Sync y VDPir. Creo que esta MSXDev va a ser la más impresionante en cuanto a calidad técnica. Creo que se está dando un salto muy grande estos dos últimos años.

My contribution

PAL (50Hz)
313   Lines per frame
121   Vblank
192   Active area
   
38,66%    % of time in vblank
61,34%   % in active area
   
Z80 speed Hz   
3.579.545   
   
Cycles per frame   
71.286   
   
27.558   Cycles in vblank
43.728   Cycles  in active area
   
15.716,99   Line rate Hz
50,21   Frame rate Hz
   
18   cycles for OUTI
28   cycles for OUTI; NOP;NOP
   
1.531   Bytes in vsync
1.562   Bytes in active area
   
   
3.093   Tot bytes per frame
   100% cpu usage (and about 2K of unrolled code ;-)

NTSC (60Hz):
262   Lines per frame
70   Vblank
192   Active area
   
26,72%    % of time in vblank
73,28%   % in active area
   
Z80 speed Hz   
3.579.545   
   
Cycles per frame   
59.671   
   
15.943   Cycles in vblank
43.728   Cycles  in active area
   
15.716,99   Line rate Hz
59,99   Frame rate Hz
   
18   cycles for OUTI
28   cycles for OUTI; NOP;NOP
   
886   Bytes in vsync
1.562   Bytes in active area
   
   
2.447   Tot bytes per frame
   100% cpu usage (and about 1K of unrolled code ;-)

Thanks ARTRAG! :), take a look at this thread (http://www.msxgamesbox.com/karoshi/index.php?topic=628.0) (in spanish only :( ) where I'm writing a tutorial of how to cope with the limitations that the standard imposes. You'll find similar maths slighty different due the vertical frequencies used as base for calculations, exactly 50 and 60 hertz in my example, I know that there're no exact values; but I haven't been able to find a good reference about that. Where do you have found those values, 50,21Hz and 59,99Hz?

go here:

http://www.work.de/nocash/portar.htm#displaytimings

BTW the math is very easy:

15716.99 Hz / 262 = 59.9885 Hz

and

15716.99 Hz / 313 = 50.214 Hz

PAL and NTSC have (or should have... I'm not sure) the same line frequency (in order to fit in the same bandwidth)

PS

Actually you can do a simple test

write a small ASM code that :
1) Set 0 as background color,
2) disable the interrupts
3) changes cyclically the color background (R#7) with loop exactly equal to 4*227,75=911 cycles
4) run it on a real HW

If the colors cycle every 4 lines and are stable this is the proof that 15716.99 is the line frequency.
Try it in PAL and in NTSC and let me know.
I do not have a real HW so I cannot help you here.

PPS

3.579.545 Hz  /  15.716,99 Hz = 227,75 cycles

Some new calculation: I have found that due to interlacing pal and ntsc have 262.5 and 312.5 lines rescpectively
this leads to


cpu clock    3.579.545    Hz      
            
Hsync   15716,99   Hz      

   # of lines per frame            Vblank            Active area
PAL    312,50                        120,50            192,00
NTSC    262,50                        70,50            192,00
            
            Frame rate          
PAL    50,29    Hz      
NTSC    59,87    Hz      
            
            cpu cyles per frame            Vblank            Active area
PAL                71.171,89             27.443,88            43.728,01
NTSC                59.784,38            16.056,38            43.728,01
            
                           OUTI               NOP;NOP;OUTI      
cpu cyles                     18               28      
                  
                                                          Bytes           Bytes              Total
PAL                                                              1.524,66            1.561,71        3.086,37
NTSC                                                             892,02            1.561,71        2.453,74

Yes, it's true, this shows some light over why a PAL TV has 625 lines!, there're two frames of 312,5 lines each  :)
Anyway, I'm still in doubt about the vertical frequencies; everywhere I look, I'm finding 50Hz and 59.94Hz as the correct values for PAL and NTSC ???.

What about my proposal to write a code of 911 cycles?


this should be 911 cycles (I verified with http://msx.jannone.org/bit/ )

If the color bars drift the hsync frequency isn't 15716,99Hz

Ok; so it's time to make some speed tests...

let me know!

PS
wikipedia says that PAL has 15734 Hz as Hsync

this means 227,5 cycles per line and that
that the test can be done on 2 line with a loop of 455 cycles
i.e. like this

This is an interesting table....
http://www.paradiso-design.net/TVsystems_worldwide.html

according to this site

NTSC M has

525   lines
59.94 Hz/59.94 fields/s (Vsync)
15734 Hz Hsync

and PAL (many of them) has

625 lines
50 Hz/50 fields/s (Vsync)
15625 Hz Hsync

I think it is time to experimnet...(for who has a real HW)

El fichero adjunto tiene extension .zip y .txt, pero parece estar dañado. Esta en algun otro sitio el fichero?. Acabo de leer el hilo y me gustaria probar esa demo en mi msx1.
Un saludo!!!