|
Darth_Fistro
|
 |
« : 04 de Marzo de 2006, 11:06:36 am » |
|
Güenas  Taba trasteando con GRPPRT para escribir en sc2 pero no sé cómo situar el cursor gráfico en un punto. Están LEFTC,RIGHTC, etc.. que lo mueven 1 píxel a cada lado, pero no encuentro la rutina para situarlo. Aprovecho ya para preguntar si GRPPRT escribe un caracter y lo colorea, como PRINT#1 en BASIC. Bueno, ya os molestaré en otro momento  Un día publico una tabla con dudas, lo que pasa es que me muerdo la lengua para que no me expulsen  ¡Gracias! |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
Darth_Fistro
|
|
« Respuesta #1 : 06 de Marzo de 2006, 04:42:31 pm » |
|
ok, ya he dado con el clavo. Por favor, ¡que cierren el topic! |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
MsxKun
|
|
« Respuesta #2 : 06 de Marzo de 2006, 07:57:44 pm » |
|
|
|
|
|
|
En línea
|
--  She Bops! |
|
|
|
Darth_Fistro
|
|
« Respuesta #3 : 07 de Marzo de 2006, 08:08:26 pm » |
|
Pues no, no era tan fácil como creía. Se supone que en fcb3h y fcb5h se almacenan los cursores gráficos x e y respectivamente. Escribo valores ahí y luego hago call GRPPRT pero aparece siempre el texto en la posición (0,0). Además, esas variables del sistema son de 2 bytes cada una, y no sé por qué, porque la pantalla va de 0 a 255. Y ya de paso, ¿qué es más rápido, JR o JP? ¡Asias! |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
SapphiRe
Visitante
|
|
« Respuesta #4 : 07 de Marzo de 2006, 08:15:44 pm » |
|
Y ya de paso, ¿qué es más rápido, JR o JP? Obviamente es más rápido JP, porque el Z80 sólo tiene que coger la dirección del salto y escribirla en el registro PC (10 ciclos según las tablas), mientras que con un JR (aunque te ahorras un byte) tienes que coger el PC y sumarle el valor adecuado (12 ciclos según las tablas). Saludos -- SapphiRe |
|
|
|
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #5 : 07 de Marzo de 2006, 08:52:13 pm » |
|
Pues no, no era tan fácil como creía. Se supone que en fcb3h y fcb5h se almacenan los cursores gráficos x e y respectivamente. No me había fijado que andabas trasteando con GRPPRT... En esas posiciones que dices, los valores que se almacenan son temporales y para uso interno  . Utiliza GRPACX ($F3B7) y GRPACY ($F3B9) para situar el cursor, debería funcionar perfectamente. Obviamente es más rápido JP, porque el Z80 sólo tiene que coger la dirección del salto y escribirla en el registro PC (10 ciclos según las tablas), mientras que con un JR (aunque te ahorras un byte) tienes que coger el PC y sumarle el valor adecuado (12 ciclos según las tablas). Y eso me recuerda....¡Por Dios, que alguien eche luz sobre el tema de los ciclos en el MSX!. Aunque en la página de MAP ya se comenta lo del ciclo/s extra que tiene que sufrir el Z80 en los MSX, todavía no lo tengo claro. ¿TODAS las instrucciones se penalizan con un ciclo excepto las que lo hacen con dos?, ¿incluso un puñetero NOP?. A ver si alguien me aclara esta duda existencial...  |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
pitpan
|
|
« Respuesta #6 : 07 de Marzo de 2006, 09:50:18 pm » |
|
Por cada instrucción que se "fetchea" cae un ciclo extra. Por tanto, un NOP tardaría 4+1=5 ciclos. Las instrucciones con prefijos ED, DD y cía consumen 1 ciclo extra para el primer byte y otro ciclo más para la otra.
Pero tampoco lo tengo nada claro... No estarás haciendo pruebas de sincronización a lo bestia? Me lo malicio...
Tuve que hacer algo así, pero no para malignos manejos gráficos, sino para el reproductor de sonido sampleado de 1-bit, que requería sincronización absoluta para respetar los 22 KHz/11 KHz/8 KHz.
|
|
|
|
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #7 : 07 de Marzo de 2006, 10:19:14 pm » |
|
¡Puaf!, es que es una pena todo ese lastre....y más teniendo en cuenta que si en los MSX2 ya no era necesaria la espera antes de acceder a la VRAM, se podría haber eliminado en el Z80 ese ciclo extra de latencia de la memoria. Hace poco se comentó lo de poder cargarse esa espera (¡sobrefrecuenciar el Z80! ); pero no se en que quedo el asunto, si era posible o no.  Claro, que entonces todo el software hecho para la anterior generación y que utilizara sincronización precisa dejaría de funcionar |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
Darth_Fistro
|
|
« Respuesta #8 : 08 de Marzo de 2006, 03:40:15 pm » |
|
Utiliza GRPACX ($F3B7) y GRPACY ($F3B9) para
¡Mil gracias! Para tí de regalito:  Las direcciones son fcb7 y fcb9, las tenía apuntadas como "acumulador gráfico" pero no sabía qué eran. Ahora todo va como la seda (trasteando para un conversacional, a ver qué tal va). Ah, ¡y a usar JPs a saco!  |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
pitpan
|
|
« Respuesta #9 : 08 de Marzo de 2006, 03:52:47 pm » |
|
Créeme que no notarás diferencia alguna entre usar JP y JR si te estás dedicando a "pintar" gráficos. El cuello de botella es siempre el acceso a VRAM, así que mejor ahórrate los bytes para mejor destino. Pero claro, ésta es mi opinión. |
|
|
|
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #10 : 08 de Marzo de 2006, 04:57:52 pm » |
|
Para tí de regalito: Kiss Kiss Kiss Me estás mal acostumbrando... Las direcciones son fcb7 y fcb9, Me alegro de que te dieras cuenta de que los valores que puse estaban mal El cuello de botella es siempre el acceso a VRAM, así que mejor ahórrate los bytes para mejor destino. Pero claro, ésta es mi opinión. Pozí. Salvo que tengas un bucle que vayas a repetir un puñado de veces, ni te molestes con los JP. |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
Darth_Fistro
|
|
« Respuesta #11 : 08 de Marzo de 2006, 07:10:21 pm » |
|
Gracias, tomo nota Es para bucles internos, no para gráficos. Usando la BIOS no sé dónde andará el límite, pero no creo que vaya más allá de 800 bytes por barrido vertical, ¿me equivoco? ¿Cómo hacían aquellas conversiones spec para hacer scroll en dos tercios de pantalla? Ya sé que no iban tan rápidas como en Spectrum y que sólo son monocromos, pero mover 4kbs de patrones no debe ser moco de pavo. Supongo que usando un chorro de OUTs que hacían después que aquellos juegos no funcionasen en la mitad de los MSX2. Lo digo para experimentar a mover un bloque en sc2, que mira por donde ni siquiera lo he probado aún |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
jltursan
|
|
« Respuesta #12 : 08 de Marzo de 2006, 08:33:35 pm » |
|
¡Caaaaaaspa!, no eran a 50fps, de hecho recuerdo que en muchos casos veías "la ola" del scroll, cosa que en el spectrum no pasaba Por si te pones y experimentas te confirmo que el bucle más rápido que he conseguido en un MSX1 es con 5 ciclos de espera (un NOP) entre OUT's. Si utilizas un bucle, los 11 ciclos que tarda un JP ya son suficientes para hacer los OUTs sin pausa. En los MSX2 puedes enchufarlos sin pausa e incluso usar el OTIR Este "artículo" está muy bien, seguro que encontrarás cosas realmente curiosas (y bastante duras también  ) http://bifi.msxnet.org/msxnet/tech/tmsposting.txtAhora entiendo lo que me contaba en una ocasión Robsy acerca de enviar el máximo número posible de datos a la VRAM dentro del VBlank |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
Darth_Fistro
|
|
« Respuesta #13 : 08 de Marzo de 2006, 08:38:18 pm » |
|
Por si te pones y experimentas te confirmo que el bucle más rápido que he conseguido en un MSX1 es con 5 ciclos de espera (un NOP) entre OUT's. Si utilizas un bucle, los 11 ciclos que tarda un JP ya son suficientes para hacer los OUTs sin pausa. En los MSX2 puedes enchufarlos sin pausa e incluso usar el OTIR A mí todo eso de los OTIR y demases me suena a brujería de la mala Voy a echarle un vistazo a eso, gracias |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
