Karoshi MSX Community

Hola!

Bueno, pues gracias principalmente al tutorial de Pepe Vila, ya he conseguido dar mis primeros pasos en ensamblador. ;)
Una vez cogido el flujo de trabajo, me he propuesto un minireto para ver qué era capaz de conseguir fuera de lo aprendido en el tutorial. Para saber qué instrucciones se puede usar y cuáles no he ido tirando de opcodes.asm (de los ejemplos del asMSX) y de otro par de tutoriales de speccy.org y no sé qué otra página.

Al final he conseguido programar un mini-pang supercutre (tan cutre que ni te matan ni se acaba el juego xDDD). Y aquí es donde entrais vosotros. Voy a pediros que, como teneis más rodaje que yo, le echeis un vistazo a la sarta de barbaridades que he hecho y me lleveis al buen camino del ensamblador ;D
De la parte de MUEVE_JUGADOR estoy razonablemente satisfecho. Pero la parte de MUEVE_BOLAS creo que no ha quedado tan bien:

• Utilizo IX e IY y he leído que debería intentar minimizarlos... lo que no he sabido es cómo organizar el código sin llenarlo de PUSHs y POPs. Tampoco sé cuál de las dos opciones es mejor
• ¿Es normal que COMPRUEBA_PINCHO, que simplemente mira una colisión, ocupe 25 líneas?
• Para dividr las bolas, reduzco la actual, copio la reducida y le cambio el dx a la copia... en 60+ farragosas líneas :S ¿Ideas para mejorar esto?
• Utilizo la copia de SPRATR que tengo en la RAM como variables del juego, ¿esto habitualmente se hace así? (para las bolas tengo además otra tabla separada para saber si están activas, desplazamiento, etc.)

No busco una optimización a tope... simplemente que me indiqueis si estoy haciendo cochinadas muy gordas y cómo podría mejorarlas.

¡Muchas gracias!

Pues está francamente bien para ser tu primera prueba en ensamblador!

No he abierto aún el código, pero el resultado en pantalla es bueno.

Gracias.

Aunque no soy un crack del ensamblador me parece que vas por muy buen camino, y si conseguiste hacer en basic el Perez, no quiero imaginarme de lo que seras capaz en ASM.

:) mucho animo!

por cierto, ya me contareis un día de donde narices sacáis el tiempo los que sois papis...

Bueno, pues aquí vuelvo; ahora con dudas más concretas:

Imaginaos que estoy volcando un cacho de mapa a una línea horizontal de la pantalla. Tengo hl apuntando al próximo caracter a leer, de a donde lo quiero escribir y b el número de caracteres que quiero copiar:
Todo muy fácil, sencillo y para toda la familia.

Ahora viene lo gordo: si lo que quiero copiar es una columna tengo que andar con push/ex/ex/pop para poder incrementar tanto hl como de. ¿Esto normalmente se hace así? ¿Es suficientemente rápido o cuando empiece a añadir elemento se ralentizará el asunto?
Estoy pensando en hacer una alternativa que sea tener un buffer_columna, apuntar ahí de (con lo que en el bucle sólo tendría que hacer inc de) y luego, cuando esté lleno, volcarlo al búfer de pantalla con otro bucle diferente (en el que para la parte de hl sólo haría inc hl).

Estoy un poco perdido porque tampoco sé cómo medir cuánto tardo en preparar un frame. Intenté cambiar el color del borde justo después del halt y cambiarlo otra vez justo al acabar de pintar, que me sonaba haber leído que se podía hacer así, pero no me ha funcionado...

¡Muchas gracias por los ánimos!

@cybernoid: yo no tengo niños, pero imagino que pasar la noche despierto + netbook = entradas para la MSXDev ;)

P.D.: Adjunto como quedó al final el experimento del minipang

Al código que has puesto seguramente se le pueden arañar algunos ciclos, pero para saber si te cabrá en el frame dependerá también de cuantos caracteres transfieras junto al resto de cosas que tengas que hacer....

La técnica de cambiar el color del borde es buena, bonita, barata y muy efectiva, yo uso esta rutinilla

Pues ya lo he metido en el código.
Para desarrollar estoy tirando de emulador; creía que el meisei me iba a representar bien lo del borde, pero no se ve nada. En el BlueMSX sin embargo sí que lo veo, aunque siempre me llega hasta la mitad de la pantalla más o menos. Tengo que meterle alguna ñapa al código a ver si efectivamente sube o baja, no vaya a ser que me fíe y en realidad no pueda usarlo en el emulador.

Transferir transfiero... todos, los 768 (¿o a qué te refieres?).
Básicamente tengo un búfer y un valor offset que varía según se mueve el scroll (derecha +1, arriba -32, etc.). Copio offset bytes de buffer+offset a NAMTBL y luego copio 768-offset bytes de buffer a NAMTBL+offset.
La movida viene a la hora de pintar la nueva parte expuesta, que varía dónde he de escribir según el offset y hay que andar verificando que no me salga del búfer...
De hecho, estoy pensando si no sería más eficiente (sobre todo en el algoritmo de pintado de parte expuesta) mover los datos del búfer con ldir/lddr para hacer el scroll, luego pintar (sin preocuparme del offset) y luego hacer el LDIRVM... a ver si puedo hacer la prueba sin destrozar mucho el código que ya tengo :S

Yo para mirar lo del color del borde mientras desarrollo uso el Blue, y luego los resultados son iguales que en un MSX real donde lo pruebo cada mucho menos.

Sobre los tiempos, durante el retrazado te da tiempo a enviar los 768 caracteres, eso sí, sin usar la BIOS, y luego tienes el resto del frame para preparar el siguiente buffer a enviar en el siguiente retrazo... Quizás fuera mejor manipular el mapa en memoria, y luego volcar la parte que te interese directamente a vram, que la doble transferencia que es lo que entiendo que intentas hacer.

Hola chicos,

para que sirve lo de cambiar el color del borde (aparte de para cambiar el color del borde)? ¿? me tiene intrigado :P  ¿para medir el tiempo del retrazo?

me podeis explicar por encima como funciona todo el tema del retrazo de pantalla?


gracias

La idea es medir de una forma gráfica "cuánto tarda" el bucle de un juego. ¿Qué importancia tiene esto? Pues para sincronizarlo respecto del retrazado de pantalla y que el movimiento sea más fluido. Además, durante el retrazado vertical la VDP dispone de mayor ancho de banda para lectura/escritura, por lo que es el momento óptimo para realizar actualizaciones de VRAM (copiar datos, principalmente).

y como sabes cuando comienza ese retrazo? hay alguna variable de sistema que lo indique?

No sé si se podrá saber cuando empieza, pero puedes esperarlo con halt (o eso creo).

Mira, mi bucle principal es así:

De esta forma, el borde de la pantalla se pinta de azul hasta la mitad (el LDIRVM de la NAMTBL), luego hay un fragmento rojo durante los cálculos del scroll (más gordo cuando hay más cosas que hacer, por ejemplo al moverme en diagonal) y luego ya veo verde hasta abajo del todo. ^_^

Y a todo esto, he descubierto una cosa muy curiosa: el LDIRVM de C-Bios es SALVAJEMENTE más rápido que el de la BIOS normal (al menos en BlueMSX).
¿Alguien me puede confirmar esto? Si es así... ¿Por qué? ¿Podría traerme el LDIRVM de C-Bios a mi programa para evitar andar pillado? ¿Cómo? ¿De dónde lo saco?

Pues ahora que lo dices... la BIOS original hace esto:


Es decir, un bucle 'manual' de un porrón de ciclos para cada byte enviado, en cambio la C-BIOS hace esto:

Que envía con OTIR, bastante más rápido. Pero ya que te vas a saltar el BIOS, si sabes que vas a escribir durante el retrazado es más rápido todavía encadenar unos cuantos OUTIs

Y por eso probablemente C-BIOS no funciona correctamente en ordenadores MSX reales. O no en todos, vamos.

Por cierto, que es totalmente cierto: un montón de OUTIs son siempre más rápidos que un OTIR.

Pues teniendo en cuenta que oficialmente la espera mínima en el peor de los casos es de 28 ciclos y OTIR sólo espera 22...  :(

Y además de no cumplir el estándar, tampoco le veo mucho sentido que C-BIOS hagan la transferencia mucho más rápido porque puede hacer que juegos funcionen más rápidos, o incluso que no funcionen  ???

Buh, pues me da a mí que de momento voy a seguir utilizando LDIRVM.
Así me aseguro compatibilidad... y "me obligo" a hacer código eficiente para el resto de cosas. Si cuando esté todo montado veo que necesito un poco más de velocidad, pues entonces ya me contareis lo de la espera mínima, los OTIR y cómo hacer una transferencia más rápida...
:D

Al final no he podido resistirme y he abandonado el LDIRVM... pero es que la diferencia de tiempos es salvaje, en especial a 60Hz que se come prácticamente todo el frame él solito :(

He aislado la parte del scroll infinito para compartirla con vosotros (aunque, sinceramente, no sé si estoy reinventando la rueda :-P).

Podeis hacer scroll hacia los lados, hacia arriba y en diagonal (hacia abajo no porque el juego que estoy haciendo no lo neceista y simplemente lo quité). Con espacio pulsado hace el volcado con OTIR (implementación basada en C-BIOS) y sin él utiliza LDIRVM. El borde azul es transferencia RAM->VRAM, el borde rojo el pintado de la parte nueva de la pantalla (en el ejemplo, caracteres aleatorios) y el borde verde es libre.
Como vereis, LDIRVM a 60Hz prácticamente se come todo el frame :( En el código del juego, que se mira qué caracteres tiene que poner en función de un mapa de tiles, el scroll diagonal se pasaba de tiempo y por eso acabé con el OTIR.
Por contra, ¡OTIR a 50Hz no se sale del VBlank! ¡Es genial! Lo malo es que a 60Hz sí. Tengo que desenrollar ese bucle, pero como el número de bytes a transferir no es fijo aún no he aprendido a hacerlo (creo que tengo que hacer un código automodificable con un JR). También estoy usando números de puertos VDP "fijos" y eso tampoco me gusta.

Otra opción que probé en su momento fue mover el buffer con LDIR/LDDR y volcar con OUTIs. Era algo más rápido que la solución LDIRVM y facilitaba mucho el saber dónde pintar del buffer, que con el offset es un poco coñazo :)

En fin... probadlo si os interesa. Y cualquier sugerencia es bienvenida :-D

Hola,

Creo que es incompatible con MSX2, lo he estado probando con blueMSX y con openMSX con configuración de MSX2 y no funciona.

Pues es cierto que se cuelga en MSX2... (En MSX1 sí funciona, en emulador y en máquina real).  Algo le pasa que llega a HALT con la CPU con las interrupciones deshabilitadas, y echando un vistazo al código sólo veo un EI pero dentro de una rutina...

@cybernoid:
Pues tienes toda la razón; en MSX-2 no tira. He tenido que meter la pata al quitar el resto de código del juego, porque éste sí que funciona. :S

@Mortimer:
No me ha dado tiempo a mirar nada (de hecho, estaba contestando cuando has escrto tú) pero precisamente la parte que tiene el DI/EI sustituye a un call SETWRT... que estaba pensando en recuperar para despreocuparme de los números de puerto.

Muchas gracias por el aviso; ya os contaré si consigo arreglarlo!

Métele un EI antes del MAIN_LOOP. En la primera generación cuando llamas a INIT32 activa las interrupciones y por eso funciona, pero de la segunda pa'rriba me temo que no. Creo que ahí está el fallo.

Un saludo.

Hola.

Estaba arreglandolo y cuando me he conectado para subir la nueva versión he visto tu respuesta, e_sedes. He visto que era antes de empezar el MAIN_LOOP, he puesto un call DISSCR y call ENASCR (un poco a ciegas, sin saber muy bien qué tenía que ver), y ha empezado a funcionar. Supongo que uno de los dos hace un EI dentro...
Ahora al menos ya sé el motivo de que no tirara; ¡muchas gracias!

Adjunto la nueva versión; está basada en FLDIRVM de SapphiRe del hilo de la rutina de transferencia "refinitiva" (http://karoshi.auic.es/index.php?topic=796.0), aunque no he sabido aplicar todo lo que tiene aquella (aprovechar el DEC B que hace internamente OUTI). Creo que si lo consiguiera y quitara los NOP entraría todo en el VBlank a 60Hz...
Pero bueno; de momento está arreglado lo de MSX2 y superior y aún con NOPs va bastante rápido :)

Por cierto, Mortimer, el MSX1 real en el que has probado es a 50Hz, ¿verdad?

Sí, lo probé con un Toshiba HX-20 a 50Hz...

Como comentas, sin los nops debería de entrar: un retrazo a 60Hz son 16060 ciclos, y cada OUTI son 17 ciclos, así que para volcar la tabla de nombres completa: 16060-(17*768)=3004 ciclos sobrantes. Si descuentas lo que consume el bios verás que muy justo, pero entra, pero apenas puedes hacer otra cosa que volcar a saco.

Ahora que comentais sobre 50Hz y 60Hz...

¿Si fuerzo a 50hz cambiando la vdp puedo tener algún problema? ¿Que no se vea en algún monitor o algo?

Sí, dependiendo del monitor y del cable con el que esté conectado puede que la imagen empiece a saltar (En algunos monitores se dejan ajustar manualmente con un mando por detrás) o se vaya el color. Además, sólo puedes cambiar la frecuencia en MSX2 o superiores

Hola de nuevo!

¿Me podeis echar un cable con la instrucción DAA? O no sé usarla o no hace lo que yo creo que hace. He mirado los fuentes de Jumping y del Minesweeper (RKOS), pero no me aclaro.

El caso es que yo tengo una variable que, por ejemplo, vale 17 ($11) y quiero mostrar en pantalla eso, el 1 y el 7. Si DAA hace lo que yo creo...

• $11 -> DAA -> $17 -> AND $0F -> ya tendría el 7
• $11 -> DAA -> $17 -> AND $F0 -> RR RR RR RR -> ya tendría el 1

...pero si estais leyendo este post es, clarostá, porque no funciona así :(

¡Muchas gracias de antemano!

Pues no, no hace lo que crees... ;D

Con DAA consigues lo siguiente:

Tienes un número en formato BCD: 48h -> 48 en BCD
Y tienes otro número en formato BCD: 12h -> 12 en BCD
Los sumas con un ADD, y consigues, como es lógico, 5Ah, que no es un número BCD.

Ejecutas entonces DAA, y te da el resultado correcto, 60h, que en BCD es 60. Tachán!

Pero si quieres convertir base 2 a BCD, tendrás que programarlo tú.

Truco para hacerte la vida más fácil: DAA funciona correctamente con ADD, ADC y SBC, pero, contra toda lógica, no funciona bien con INC/DEC.

Ya le podía dar yo vueltas al código...
Muchas gracias, pitpan; ya lo tengo funcionando ^_^

Hice en su día un documento bastante completo sobre BCD, pero no he sido capaz de encontrarlo... Tenía todas las rutinas básicas para funcionar cómodamente con BCD, incluso para números de bastantes bytes. Si alguien lo tiene por ahí, que se anime a subirlo, por favor.

Me alegra saber que con la explicación rápida te has podido buscar la vida... En su día, cometí el mismo error al pensar que DAA podía con todo. Me estrellé contra la rutina mientras programaba mi emulador de menos de 2 KB del Space Invaders para 80286  :P

Google + Wayback Machine FTW

¡Buenas una vez más!

A ver si sabeis aclararme una cosa. Para uno de los estados del jugador (llamémoslo "pitufando" xDDD) tengo mucho código compartido entre las dos direcciones de la siguiente forma:

Ahora bien, para simplificar ese if...then...else he intentado lo siguiente:

Pero lo que está en el call nz no se llama nunca :(
¿Alguna idea de por qué no funciona? ¿Qué es lo que se me escapa?

Para simplificar aun mas, ¿para que haces un segundo CALL? si Z es falso entonces NZ es cierto. Mejor un JR Z y vuelta al código comun,  :D

Mi idea era justo la contraria; ahorrarme los JR y las etiquetas mediante el segundo CALL :D Menos instrucciones y menos saltos con el mismo número de condiciones.
Pero tu respuesta me ha puesto sobre la pista de lo que pasaba. No es que no se estuviera llamando el segundo CALL, era justo lo contrario; al llamarse el primero se modificaban los flags y se llamaba también al segundo. Como ambas funciones hacen justo lo contrario, "se anulaban" entre ellas y parecía que no se estaba llamando a ninguna.
No sé qué paja mental me había montado para no darme cuenta... :)

Se pierden las banderas en el primer CALL, pero puedes hacer que funcione asi:
Saludos y esperemos que tu player pueda seguir "pitufando" ;D

Sí, ya lo ví.
Nah si era porque pensé en lo de los dos CALLs condicionales y quedaba tan bonito el código... Al final se queda con los JR.
Hay que mantener un poco el misterio ^_^

Yo habría puesto primero la llamada con nz, ya que es una condición más común que z, y luego me habría asegurado en la rutina de no volver con el flag z activado.

De hecho, yo hice algo así al optimizar el código del Genesis (de utopian) para Spectrum, si os bajais el código fuente lo podreis ver en el archivo drawsprite.asm

O se puede poner simplemente un "XOR A" al final del CODIGO_ESPECIFICO_DERECHA para volver con el flag z activado de nuevo, sin necesidad de hacer push y pop de las banderas.

No había visto tu respuesta, Metalbrain.
En condiciones generales, nz sí que es más común que z (en proporción 255 a 1), pero en mi caso partícular son equiprobables.
Pero vamos, que al final se queda como está, con el if-then-else por jrs. Modificar uno de los métodos (añadir el xor a) pues es mejorar este caso para penalizar el resto de sitios en los que se usa. Y al fin y al cabo era más por optimizar estéticamente el código que porque necesitara más velocidad o memoria.
El código del Genesis es inmanejable para mí; no sé ni por dónde empezar a mirar. De momento me tengo que conformar con los ejemplos del asMSX y el Jumping :D

Muchas gracias a todos por las respuestas.

Y aquí voy con otras dos consultas: ;D

Ahora mismo, mi código (asMSX) empieza con:
El caso es que la directiva .rom ya hace automáticamente dicho padding (e incluso el .start), pero siempre lo veo puesto explícitamente. Es decir, si simplifico lo anterior a lo siguiente, genera exactamente el mismo fichero .rom:
Entonces viene la duda, porque en todos los ejemplos he visto el start y, en la mayoría, el padding. ¿Se deja simplemente por claridad o hay algún motivo que se me escapa? (en algunos casos he visto el padding de la tercera línea con .dws)

Y una última cosa: he visto que algunos listados empiezan por ld sp, $f380 ¿Es necesario? ¿El stack pointer no está inicialmente apuntando ya ahí?

Lo dicho, muchas gracias a todos de antemano.

Pues precisamente para hacer la vida fácil a los programadores principiantes, la directiva ROM hace exactamente todo lo que dices. Tienes las dos opciones: usar ROM o crear tú la cabecera a mano. Como otros ensambladores no disponen de la directiva ROM, el código fuente que encontrarás por ahí lo hace todo "a mano".

Pero vamos, es tan sencillo como

.org 4000h
db "AB"
dw INIT,0,0,0,0,0,0
INIT:
; tu código a partir de aquí


En cuanto al LD SP,... tienes razón cuando indicas que el puntero de la pila ya debería estar ahí. Y esto es así siempre que estés arrancando el ordenador con tu ROM y no haya ejecutado nada más antes. Sin embargo, si arrancas desde BASIC, o si antes de ejecutarse tu ROM se ha ejecutado alguna otra ROM o programa, es posible que SP no esté donde tú te crees, lo que puede generar muchos errores absurdos y muy difíciles de depurar. Para curarse en salud, nada como un LD SP,... y los correspondientes IM, etc.

Qué respuesta más rápida :D
La verdad es que ahora que ya voy con algo más de rodaje sí que veo las cosas más claras (como lo de montar la cabecera manual del ROM que comentabas). Pero vamos, que el asMSX lo pone bien fácil; fue uno de los empujoncitos para que yo empezara con esto del ASM.
Hum... está bien saberlo. Hablando de una ROM ¿podría dar problemas cargarla con execrom, por ejemplo?