|
cybernoid
|
 |
« : 06 de Marzo de 2007, 12:42:47 pm » |
|
pues estaba yo feliz y contento haciendo mis pijadas con el asMSX y el SDCC cuando me ha dado por hacer bucles en ASM.
y haciendo bucles he llegado hasta este código, se que se puede hacer de otras maneras, pero me interesa comprender por que no funciona.
el código es el siguiente:
CX equ 9000h
xor a
ld [CX],a
buc:
ld a,65
push hl
call WRTVRM
pop hl
ld a,[CX]
inc a
ld [CX],a
ld l,a
cp 10
jp nz,buc
ret
bueno, este bucle tendría que dar por resultado una bonita fila de 10 'A' , pero en vez de 10 muestra 2 ¿?¿? alguien sabe decirme por que?
|
|
|
|
|
En línea
|
|
|
|
|
nerlaska
|
|
« Respuesta #1 : 06 de Marzo de 2007, 01:12:54 pm » |
|
Bueno, lo primero .. ese código es poco óptimo  Y lo segundo .. mmm .. la dirección 9000 no es ROM? :-) Vamos . .que no se puede escribir ahí o lo tienes puesto como RAM? Pregunto .. por si las moscas. |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe
Visitante
|
|
« Respuesta #2 : 06 de Marzo de 2007, 01:15:03 pm » |
|
CX equ 9000h
xor a
ld [CX],a
buc:
ld a,65
push hl
call WRTVRM
pop hl
ld a,[CX]
inc a
ld [CX],a
ld l,a
cp 10
jp nz,buc
ret
Veamos, utilizas la posición de memoria CX (9000h en tu ejemplo) como una variable donde vas almacenando el contador. Supongamos que tienes inicializado hl a la primera posición de memoria de vídeo donde quieres imprimir la A. En un principio no veo ningún problema en el código (salvo su ineficiencia, pero ese es otro tema). Lo que sí es curioso es que sólo imprima 2 A's, ya que 10 en binario es 2... ¿puede venir de ahí el problema? Otra pregunta es, ¿en qué dirección se está ejecutando el código? A ver si estás machacando algo del código con el ld [CX],a... Saludos -- Sph. |
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #3 : 06 de Marzo de 2007, 01:24:22 pm » |
|
Bueno, lo primero .. ese código es poco óptimo Y lo segundo .. mmm .. la dirección 9000 no es ROM? :-) Vamos . .que no se puede escribir ahí o lo tienes puesto como RAM? Pregunto .. por si las moscas. bueno, el codigo no pretende ser optimo, solo estaba probando, respecto a la direccion de memoria yo he probado en basic a escribir en la posicion y funciona  supongo que en assembler deberia funcionar tambien. pero bueno, la idea seria escribir en la ram |
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #4 : 06 de Marzo de 2007, 01:27:59 pm » |
|
CX equ 9000h
xor a
ld [CX],a
buc:
ld a,65
push hl
call WRTVRM
pop hl
ld a,[CX]
inc a
ld [CX],a
ld l,a
cp 10
jp nz,buc
ret
Veamos, utilizas la posición de memoria CX (9000h en tu ejemplo) como una variable donde vas almacenando el contador. Supongamos que tienes inicializado hl a la primera posición de memoria de vídeo donde quieres imprimir la A. En un principio no veo ningún problema en el código (salvo su ineficiencia, pero ese es otro tema). Lo que sí es curioso es que sólo imprima 2 A's, ya que 10 en binario es 2... ¿puede venir de ahí el problema? Otra pregunta es, ¿en qué dirección se está ejecutando el código? A ver si estás machacando algo del código con el ld [CX],a... Saludos -- Sph. el codigo se esta ejecutando en formato ROM page 2 8000h. el codigo esta un poco marraneado de mucho probar, ya sabes que estoy aprendiendo y la cosa esta chunga, pero claro para aprendre uno tiene que probar y probar y acaba haciendo cosas como este codigo |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe
Visitante
|
|
« Respuesta #5 : 06 de Marzo de 2007, 02:32:34 pm » |
|
el codigo se esta ejecutando en formato ROM page 2 8000h. Entonces no hay más vuelta de hoja, el problema es el que ha apuntado nerlaska: no puedes modificar la posición 9000h porque está en ROM. Prueba a poner algo por encima de C000h |
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #6 : 06 de Marzo de 2007, 02:42:52 pm » |
|
el codigo se esta ejecutando en formato ROM page 2 8000h. Entonces no hay más vuelta de hoja, el problema es el que ha apuntado nerlaska: no puedes modificar la posición 9000h porque está en ROM. Prueba a poner algo por encima de C000h ok, funciona muchas gracias a los 2 tengo algunas preguntillas mas, yo de hexadecimal mas bien cojeo mucho, he hecho el tipico ?&HC000 en MSX BASIC y me retorna -16384 ¿por que el numero es negativo? ¿no debería ser positivo? |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe
Visitante
|
|
« Respuesta #7 : 06 de Marzo de 2007, 03:03:20 pm » |
|
tengo algunas preguntillas mas, yo de hexadecimal mas bien cojeo mucho, he hecho el tipico ?&HC000 en MSX BASIC y me retorna -16384 ¿por que el numero es negativo? ¿no debería ser positivo? Pues es tanto negativo como positivo. Ten en cuenta que en 16 bits puedes almacenar un total de 65536 números diferentes, o bien desde el 0 al 65535 o bien incluyendo también números negativos. ¿Cómo? Muy sencillo: el bit más significativo se considera bit de signo, por lo que cualquier número mayor o igual a 8000h será negativo. Así puedes representar números positivos desde 0 a 32767 y desde -32768 a -1. O sea, desde -32768 a +32767 ambos inclusive. Es decir C000h es tanto 49152 como -16384. ¿Por qué? Fácil, si sumamos 49152 más 16384 (que es igual a 4000h en hexadecimal) nos da exactamente 65536 que es 10000h en hexadecimal. Pero ese número es de 17 bits, por lo que al trabajar con sólo 16 bits el resultado es 0000h, o sea: 0. Por lo tanto: 49152 + 16384 = 0 por lo que 49152 = -16384 Por eso C000h vale tanto 49152 como -16384. Vale, posiblemente ahora estés pensando que desde un punto de vista matemático lo anterior no tiene sentido, y llevas razón. Pero es que estamos trabajando ÚNICAMENTE con 16 bits, por lo que las ecuaciones reales son: (49152 + 16384) mod (2^16) = 0 mod (2^16) y 49152 mod (2^16) = -16384 mod (2^16) Un saludo -- Sph. |
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #8 : 06 de Marzo de 2007, 03:11:43 pm » |
|
tengo algunas preguntillas mas, yo de hexadecimal mas bien cojeo mucho, he hecho el tipico ?&HC000 en MSX BASIC y me retorna -16384 ¿por que el numero es negativo? ¿no debería ser positivo? Pues es tanto negativo como positivo. Ten en cuenta que en 16 bits puedes almacenar un total de 65536 números diferentes, o bien desde el 0 al 65535 o bien incluyendo también números negativos. ¿Cómo? Muy sencillo: el bit más significativo se considera bit de signo, por lo que cualquier número mayor o igual a 8000h será negativo. Así puedes representar números positivos desde 0 a 32767 y desde -32768 a -1. O sea, desde -32768 a +32767 ambos inclusive. Es decir C000h es tanto 49152 como -16384. ¿Por qué? Fácil, si sumamos 49152 más 16384 (que es igual a 4000h en hexadecimal) nos da exactamente 65536 que es 10000h en hexadecimal. Pero ese número es de 17 bits, por lo que al trabajar con sólo 16 bits el resultado es 0000h, o sea: 0. Por lo tanto: 49152 + 16384 = 0 por lo que 49152 = -16384 Por eso C000h vale tanto 49152 como -16384. Vale, posiblemente ahora estés pensando que desde un punto de vista matemático lo anterior no tiene sentido, y llevas razón. Pero es que estamos trabajando ÚNICAMENTE con 16 bits, por lo que las ecuaciones reales son: (49152 + 16384) mod (2^16) = 0 mod (2^16) y 49152 mod (2^16) = -16384 mod (2^16) Un saludo -- Sph. acabas de meter un jaleo de numeros en mi cabeza que no te lo puedes imaginar, yo hace tiempo hacia cositas en asm para el Speccy, eran chorradas y las hacia en decimal, con lo que no me liaba mucho, pero ahora con el rollo del hexadecimal me estoy volviendo loco... bueno, supongo que con la practica iré pillando algo, por cierto sapp el 8245 ya ocupa su lugar desde hace un par de días |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe
Visitante
|
|
« Respuesta #9 : 06 de Marzo de 2007, 03:26:45 pm » |
|
acabas de meter un jaleo de numeros en mi cabeza que no te lo puedes imaginar Los matemáticos somos así  por cierto sapp el 8245 ya ocupa su lugar desde hace un par de días ¡¡OLE OLE OLEEEE!!!  |
|
|
|
|
En línea
|
|
|
|
|
nerlaska
|
|
« Respuesta #10 : 06 de Marzo de 2007, 05:20:38 pm » |
|
Nadie te obliga a escribir en Hexadecimal Puedes trabajar todo en decimal si quieres. Y siempre esta la calculadora de Windows para hacer conversiones. |
|
|
|
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #11 : 06 de Marzo de 2007, 05:27:13 pm » |
|
Pero conviene mucho utilizar el hexadecimal si vas a trabajar con máscaras de bits, ya que te permite hacer cosas muy rápidamente sin necesidad de tirar de la calculadora. Y, además, recuerda que en hexadecimal funciona el BCD... Pero mejor dejo que Sap os cuente estas cosillas |
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #12 : 06 de Marzo de 2007, 05:35:01 pm » |
|
Nadie te obliga a escribir en Hexadecimal Puedes trabajar todo en decimal si quieres. Y siempre esta la calculadora de Windows para hacer conversiones. eso seria lo mas facil, pero es que me da rabia lo del Hexadecimal, no lo acabo de pillar, con el binario y el decimal no tengo problemas, pero el hexadecimal se me resiste  |
|
|
|
|
En línea
|
|
|
|
|
kabish
|
|
« Respuesta #13 : 06 de Marzo de 2007, 05:35:02 pm » |
|
La verdad es q el invento de la calculadora para convertir numeros esta muy bien. !Yo tambien la uso!. Lo q pasa es q la mayoria de las veces uso el compass y viene ya con una calcu muy completa. !Hasta he llegado a convertir graficos y todo!.
Ademas puedes probar tu codigo "en caliente" con ctrl+g, y viene muy bien si, como yo, estas aprendiendo y son cosas muy simples.
|
|
|
|
|
En línea
|
|
|
|
|
cybernoid
|
|
« Respuesta #14 : 06 de Marzo de 2007, 05:36:12 pm » |
|
Pero conviene mucho utilizar el hexadecimal si vas a trabajar con máscaras de bits, ya que te permite hacer cosas muy rápidamente sin necesidad de tirar de la calculadora. Y, además, recuerda que en hexadecimal funciona el BCD... Pero mejor dejo que Sap os cuente estas cosillas que es el BCD? algun truquillo para que se me quede el hexadecimal? |
|
|
|
|
En línea
|
|
|
|
|
