|
Título: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 25 de Enero de 2013, 11:18:45 am Buenas,
me encuentro en screen 2 con el siguiente pseudocódigo: Espero un HALT Paso a pantalla una zona cuadrada de 4x4 tiles de color negro. Paso a pantalla una zona cuadrada de 4x4 tiles de mapeado justo encima del negro (ie. borra el negro). Pues cuando estoy en la mitad inferior de la pantalla el comportamiento es el que espero: me enseña el mapeado. Pero si lo hago en la mitad superior veo el mapeado pero con un parpadeo. ¿Es normal este comportamiento? En cierto modo lo vería lógico y entonces debería cambiar la manera de hacer lo que quiero. Pero me choca que en la mitad inferior haya ido bien y de ahí que haya continuado adelante, pero en la superior parpadee. Saludos! Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 25 de Enero de 2013, 11:27:06 am Por si acaso, he encontrado un algoritmo más "elegante" 8) para hacer lo que quiero, pero me queda la curiosidad.
Título: Re: Comportamiento gráfico en Screen 2 Publicado por: MsxKun en 25 de Enero de 2013, 12:15:54 pm Si ves un parpadeo, es que no le da tiempo a dibujar. Es normal que pase arriba, porque es donde empieza a dibujar la pantalla. Como copias los tiles a VRAM? Y... para que los cuadros negros si luego los machacas? :D
Título: Re: Comportamiento gráfico en Screen 2 Publicado por: zilogZ80a en 25 de Enero de 2013, 03:11:01 pm Efectivamente pueden ser varias cosas,
Hay que ver las cosas exactamente para responderte. Estas usando la BIOS para escribir en VRAM? En el caso de no usar la BIOS tienes encuenta la demora en la escritura del VDP respecto al Z80? Que es lo que intentas volcar a VRAM? es un buffer? o son escrituras directas en ciertas zonas de la VRAM? Como dice en KUN el refresco de la pantalla empieza arriba y va avanzando hacia abajo de la pantalla. Ya te contaras con mas detalle las cosas. Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 25 de Enero de 2013, 03:16:10 pm Valeee, me imaginaba que podía sería algo así MsxKun.
Jeje, suena raro, ya. Es una especie de animación pero donde no restauro el fondo. Me era cómodo borrar donde ha estado y volver a dibujar en la nueva situación. Pero ya está cambiado el algoritmo. Supongo que por eso se inventaron las "máscaras". Con lo cómodos que son los sprites... zilogZ80a, son escrituras usando la BIOS y no es un buffer de golpe. Pero sí que va a ser eso del dibujo de la pantalla. Realmente con dos cambios puedo simplificarlo al caso de una animación usando tiles (en vez de sprites). Y supongo que se suele solucionar con una máscara alrededor del objeto a animar. Gracias! Título: Re: Comportamiento gráfico en Screen 2 Publicado por: Dioniso en 25 de Enero de 2013, 05:23:41 pm Y recuerda:
-haz los cálculos. -guarda todo lo que vayas a volcar en RAM. -HALT. -Tortazo en la cara! (o lo que es lo mismo, volcado del buffer). Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 25 de Enero de 2013, 06:22:30 pm Sí sí, gracias. Ya hago los cálculos antes pero ahora he visto que puedo hacer más cálculos todavía y así escribir de manera más compacta a VRAM.
Título: Re: Comportamiento gráfico en Screen 2 Publicado por: Jon_Cortazar en 28 de Enero de 2013, 07:38:34 am Y recuerda: -haz los cálculos. -guarda todo lo que vayas a volcar en RAM. -HALT. -Tortazo en la cara! (o lo que es lo mismo, volcado del buffer). Exacto, that's the way to go! Y ánimo, pentacour, sea lo que sea lo que estés tramando! ;-)) Título: Re: Comportamiento gráfico en Screen 2 Publicado por: aorante en 28 de Enero de 2013, 02:59:46 pm Es correcto esto? ???
justo después del HALT, se puede hacer un volcado rápido (sin esperas) a la VRAM de hasta 1000 bytes (aprox)?? Lo digo porque si mueve de un buffer de la RAM, solo la parte de los nombres de patrones (mapa de tiles), lo puede hacer utilizando OTIR Título: Re: Comportamiento gráfico en Screen 2 Publicado por: MsxKun en 28 de Enero de 2013, 03:52:32 pm Es correcto esto? ??? justo después del HALT, se puede hacer un volcado rápido (sin esperas) a la VRAM de hasta 1000 bytes (aprox)?? Lo digo porque si mueve de un buffer de la RAM, solo la parte de los nombres de patrones (mapa de tiles), lo puede hacer utilizando OTIR Hay que poner esperas :D A saco, con un OTIR por ej. puedes volcar cierto numero de sprites. Sin abusar, hay un pequeño margen, a menos que haya por ahi una interrupcion que haga chorrocientas cosas. Por eso lo tienes mas controlado si la interrupcion la manejas tu. En to caso, para volcar la pantalla entera, esperas. Yo uso una ristra de OUTIs con sus NOPs entre medio que voy repitiendo. Título: Re: Comportamiento gráfico en Screen 2 Publicado por: aorante en 28 de Enero de 2013, 04:43:27 pm justamente al principio de este apartado, en el asunto TUTORIAL: Desarrollo compatible para todas las familias de MSX (II) (http://karoshi.auic.es/index.php?topic=668.msg9125#msg9125), se habla de este tema:
Citar La excepción la tenemos únicamente durante una ventana que dura aproximadamente 4300 microsegundos (a 60Hz) tras el retrazado vertical, en ese intervalo el retardo extra es cero. Durante ese intervalo basta con esperar esos 7-8 ciclos iniciales. Antes he comentado que existe una ventana de 4300 microsegundos tras el retrazado vertical cuando el refresco es de 60Hz, en ese intervalo los datos pueden ser enviados sin retardos extras y a la máxima velocidad posible. ¿Cuantos bytes podriamos transferir teóricamente durante ese intervalo?. Para calcularlo primero averiguamos cuantos ciclos tenemos disponibles durante ese lapso de tiempo : (4,3ms * 3579545) / 1000ms = 15392 ciclos Sabemos que un OUTI consume 18 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 partir de ahí ya no tenemos ninguna garantía de que no se produzca corrupción del flujo de datos, tendremos que empezar a intercalar retardos. Este resultado es aproximado, en el siguiente apartado se tratará de calcular con más precisión este valor. Por cierto, en este intervalo podríamos usar un OTIR (marginado él); pero claro ya nos podriamos ir olvidando de esos 855 bytes; eso sí, a costa de la pérdida de velocidad ganaríamos bastante memoria. lo que no sé, es cuantos bytes permitiría con un OTIR, o si en vez de encadenar un ristra de 855 OUTIs, podemos usar unos bucles DJNZ, con igual resultado... ??? (el tema ciclos no lo controlo·lo :D ) Título: Re: Comportamiento gráfico en Screen 2 Publicado por: MsxKun en 28 de Enero de 2013, 05:27:06 pm Haz la tipica prueba de cambiar el color del borde :D
Yo tengo la suerte de tener mi 20P con el maravilloso VDP Toshiba ese lentorro, asi que si me paso enviando datos, me saldra bonita roña en pantalla. Una gran ayuda :D Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 30 de Enero de 2013, 11:55:30 am Una curiosidad: Konami por ejemplo, ¿usaba llamadas a la BIOS para el volcado a pantalla o los OTIR? Seguro que algún máquina de aquí ha destripado el código de algún juego y lo sabe.
Título: Re: Comportamiento gráfico en Screen 2 Publicado por: zilogZ80a en 30 de Enero de 2013, 04:55:31 pm Una curiosidad: Konami por ejemplo, ¿usaba llamadas a la BIOS para el volcado a pantalla o los OTIR? Seguro que algún máquina de aquí ha destripado el código de algún juego y lo sabe. Vamos a reponderte y ademas te pongo el codigo de la rutinas de KONAMI comentaditas. Lo primero que debes de saber es que Konami no usaba las direcciones base de la VRAM y las modificaba de la siguiente manera. Aunque esto no tiene la mayor importancia pero para que lo sepas. ;---------------------------------------------------- ; ; Modo de video: ; ; Screen 2 ; Sprites 16x16 unzoomed ; Pattern name table = #3800-#3AFF ; Pattern color table = #0000-#17FF ; Pattern generator table = #2000-#37FF ; Sprite atribute table = #3b00-#3B7F ; Sprite generator table = #1800-#1FFF ; Background color = #E1 (Gris/Negro) ;---------------------------------------------------- Konami se ceñia completamente al standar como puedes ver en las siguientes rutinas que te pongo a continuacion. Konami lee los valores de los puertos de acceso a usar en el VDP de las direcciones 0006h y 0007h ya que no todos los MSX emplean los mismos, aunque si casi todos. Ademas tambien hacia esto con la RAM usando 8Kb cuando creo que solo hay 2 modelos muy antiguos con esa RAM tan minima. Código: ;--------------------- ; In: ; A = Dato ; DE = VRAM address ;--------------------- WriteVRAM: ; ... call SetVDPWrite exx out (c), a exx ei ret ; --------------------------------------------------------------------------- ;--------------------- ; In: ; DE = VRAM address ; Out: ; A = Dato ;--------------------- ReadVRAM: ; ... call SetVDPRead exx in a, (c) exx ei ret ; --------------------------------------------------------------------------- ;---------------------------------------------------- ; Prepara el VDP para escritura ; In: ; DE = VRAM address ;---------------------------------------------------- SetVDPWrite: ; ... ex af, af' ex de, hl call SETWRT ; BIOS SETWRT=0053H - Set up VDP for write di ex de, hl exx ld a, [0006h] ; 0006h - One byte, VDP Data Port number ld c, a exx ex af, af' ret ; --------------------------------------------------------------------------- ;---------------------------------------------------- ; Prepara el VDP para lectura ; In: ; DE = VRAM address ;---------------------------------------------------- SetVDPRead: ; ... ex de, hl call SETRD ; BIOS SETRD=0050H - Set up VDP for read di ex de, hl exx ld a, [0007h] ; 0007h - One byte, VDP Data Port number ld c, a exx ret ; --------------------------------------------------------------------------- Como puedes ver Konami usa llamadas a la BIOS del MSX como SETRD y SETWRT. Te adjunto rutina de una de sus cortinillas. y con esto espero haberto contestado. Código: ;---------------------------------------------------- ; Cortinilla vertical ; Borra la pantalla partiendo del centro en ambas direcciones ;---------------------------------------------------- DrawCortinilla: ; ... ld hl, Timer dec (hl) inc hl ld b, 18h ; Numero de patrones a escribir verticales dec (hl) ret m ld a, (hl) srl a jr c, DrawCortinilla2 xor 1Fh DrawCortinilla2: ; ... ld e, a ld d, 38h ; #3800 es el area de la tabla de nombres DrawCortinilla3: ; ... xor a call WriteVRAM ld a, 20h ; Siguiente columna call ADD_A_DE djnz DrawCortinilla3 ld de, 3B00h ld a, 0D0h call WriteVRAM xor a ret ; --------------------------------------------------------------------------- Aqui me tienes y en mi correo para lo que quieras. Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 31 de Enero de 2013, 11:36:37 am Gracias por la explicación!
Pero me refería a si Konami usaba la llamada a la BIOS FILVRM para pasar datos masivamente a VRAM o los out con el consiguiente problema que parece haber de los NOP para no saturar el VDP. Quizás es que no lo tengo muy claro porque hasta ahora "voy con mi FILVRM a todas partes" Título: Re: Comportamiento gráfico en Screen 2 Publicado por: zilogZ80a en 31 de Enero de 2013, 03:49:27 pm Gracias por la explicación! Pero me refería a si Konami usaba la llamada a la BIOS FILVRM para pasar datos masivamente a VRAM o los out con el consiguiente problema que parece haber de los NOP para no saturar el VDP. Quizás es que no lo tengo muy claro porque hasta ahora "voy con mi FILVRM a todas partes" Ya que pides algo mas concreto te pongo las rutinas que usaba Konami para hacer un FILVRM, junto a LDIRVM y LDIRMV. mas la rutina de copiar datos de VRAM a VRAM y con todo este codigo creo que tu pregunta quedará resuelta. Código: ;---------------------------------------------------- ; Rellena la VRAM ; DE = Direccion VRAM ; A = Dato ; BC = Numero de bytes ;---------------------------------------------------- setFillVRAM: ; ... call SetVDPWrite fillVRAM: ; ... ex af, af' VRAM_write2: ; ... ex af, af' exx out [c], a exx ex af, af' dec bc ld a, b or c jr nz, VRAM_write2 ei ret ; --------------------------------------------------------------------------- fillVRAM_HL: ; ... ld a, [hl] inc hl jr fillVRAM ; --------------------------------------------------------------------------- ;---------------------------------------------------- ; ; Transfiere datos desde la RAM a la VRAM ; HL = Origen ; DE = Direccion de destino en la VRAM ; BC = Numero de datos ; ;---------------------------------------------------- HLtoVRAMset: ; ... di call SetVDPWrite ;---------------------------------------------------- ; ; Transfiere datos desde la RAM a la VRAM ; HL = Origen ; BC = Numero de datos ; ;---------------------------------------------------- HLtoVRAM: ; ... ld a, [hl] exx out [c], a exx inc hl dec bc ld a, b or c jr nz, HLtoVRAM ei ret ; --------------------------------------------------------------------------- ;--------------------------------- ; Copia VRAM a VRAM ; In: ; HL = Origen ; DE = Destino ; BC = Numero de bytes a copiar ;--------------------------------- CopyVRAM: ; ... call ReadVRAM ex de, hl call WriteVRAM ex de, hl inc hl inc de dec bc ld a, c or b jr nz, CopyVRAM ret ; --------------------------------------------------------------------------- Título: Re: Comportamiento gráfico en Screen 2 Publicado por: pentacour en 04 de Febrero de 2013, 03:49:42 pm Gracias! Aunque de momento no necesito más velocidad que la que me da la BIOS, me estudiaré este código para un futuro.
|