Karoshi MSX Community

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

¡Gracias!

ok, ya he dado con el clavo. Por favor, ¡que cierren el topic!  ;D

Y de paso que encierren a Darth tb!  ;D ;D ;D

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

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

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 :P. Utiliza GRPACX ($F3B7) y GRPACY ($F3B9) para situar el cursor, debería funcionar perfectamente. :)


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... :-\

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.

¡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! ;D); 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 :P :P

¡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!  :D

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

Me estás mal acostumbrando... ;D


Me alegro de que te dieras cuenta de que los valores que puse estaban mal :P :P


Pozí. Salvo que tengas un bucle que vayas a repetir un puñado de veces, ni te molestes con los JP.

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

¡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 :P
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 ;D

Este "artículo" está muy bien, seguro que encontrarás cosas realmente curiosas (y bastante duras también :o)

http://bifi.msxnet.org/msxnet/tech/tmsposting.txt

Ahora 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 :D

A mí todo eso de los OTIR y demases me suena a brujería de la mala  ;D

Voy a echarle un vistazo a eso, gracias  :D