Karoshi MSX Community
05 de Julio de 2021, 03:36:20 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: 1 2 [3]
  Imprimir  
Autor Tema: Rincón del novato en ASM  (Leído 17017 veces)
0 Usuarios y 1 Visitante están viendo este tema.
Iggy Rock
Visitante
« Respuesta #30 : 06 de Octubre de 2012, 01:31:49 pm »

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,  Cheesy
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #31 : 06 de Octubre de 2012, 01:47:52 pm »

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,  Cheesy
Mi idea era justo la contraria; ahorrarme los JR y las etiquetas mediante el segundo CALL Cheesy 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... Smiley
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
nanochess
Karoshi Lover
***
Mensajes: 141


Programando algo buenísimo :)


WWW
« Respuesta #32 : 06 de Octubre de 2012, 09:24:25 pm »

Ahora bien, para simplificar ese if...then...else he intentado lo siguiente:
Código:
; ...montón de código común...
ld a, [player_status]
cp PITUFANDO_DCHA
call z, CODIGO_ESPECIFICO_DERECHA
call nz, CODIGO_ESPECIFICO_IZQUIERDA
; ...otro montón de código común...

Pero lo que está en el call nz no se llama nunca Sad
¿Alguna idea de por qué no funciona? ¿Qué es lo que se me escapa?
Se pierden las banderas en el primer CALL, pero puedes hacer que funcione asi:
Código:
; ...montón de código común...
ld a, [player_status]
cp PITUFANDO_DCHA
        push  af
call z, CODIGO_ESPECIFICO_DERECHA
        pop   af
call nz, CODIGO_ESPECIFICO_IZQUIERDA
; ...otro montón de código común...
Saludos y esperemos que tu player pueda seguir "pitufando" Grin
En línea

Mira mis juegos MSX/Colecovision/Atari/Intellivision http://nanochess.org/retro_es.html, y sígueme en Twitter http://twitter.com/nanochess
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #33 : 07 de Octubre de 2012, 07:45:04 pm »

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.
Saludos y esperemos que tu player pueda seguir "pitufando" Grin
Hay que mantener un poco el misterio ^_^
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
Metalbrain
Karoshi Fan
**
Mensajes: 92


Z80jutsushi


« Respuesta #34 : 09 de Octubre de 2012, 11:10:24 am »

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.
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #35 : 21 de Octubre de 2012, 11:28:40 am »

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 Cheesy

Muchas gracias a todos por las respuestas.

Y aquí voy con otras dos consultas: Grin

Ahora mismo, mi código (asMSX) empieza con:
Código:
.page 1
.size 32
rom_start:
.rom ; ID ("AB")
.start MAIN ; INIT
.org rom_start + $10 ; STATEMENT, DEVICE, TEXT, Reserved
MAIN:
; ...
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:
Código:
.page 1
.size 32
.rom ; ID ("AB"), INIT, STATEMENT, DEVICE, TEXT, Reserved
; ...
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.
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
pitpan
Karoshi Forum's Guru
*******
Mensajes: 1812


« Respuesta #36 : 21 de Octubre de 2012, 11:55:44 am »

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.
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #37 : 21 de Octubre de 2012, 01:58:54 pm »

Qué respuesta más rápida Cheesy
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.
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.
Hum... está bien saberlo. Hablando de una ROM ¿podría dar problemas cargarla con execrom, por ejemplo?
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
Páginas: 1 2 [3]
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!