Curso de Ensamblador para C64: Cap. 3 - Ensamblando manualmente con BASIC

Para introducir nuestros programas en código máquina dentro de la memoria de nuestro ordenador, podemos hacerlo de varias maneras, tres de las formas más comunes son: cargar los bytes de los opcodes y operandos desde un programa cargador en BASIC, ensamblarlos mediante la ayuda de un programa monitor de código máquina, o ensamblando nuestro archivo .prg con la ayuda de un compilador de lenguaje ensamblador.

Evidentemente la forma más práctica es ésta última, y aún más versátil resulta si encima ese compilador de lenguaje ensamblador es un cross assembler (para desarrollar desde un ordenador superior).

Sin embargo de cara a tener una buena comprensión y aprender como funciona por dentro nuestro ensamblador, es muy importante que conozcáis primero como se ensambla de las formas más básicas.

Saber manejaros con estas primitivas formas de desarrollo, también os aportará práctica para depurar vuestros programas directamente en el C64 real. A parte de la corrección de posibles bugs, los "timings" y algunas cosillas podrian necesitar ser ajustadas ya que ningún emulador, por muy bueno que sea es 100% la máquina original, aunque Win Vice, por ejemplo se le acerca muchísimo (especialmente la versión para Mac). Los ejercicios que se irán viendo a lo largo del curso, funcionarán perfectamente en el emulador incluido en el IDE (el Vice).

Asi pues, por hoy, olvidaros que existen ensambladores, ¡como si no los hubieran ni inventado!, y haced frente al C64 como valientes, intentando programarlo en su lenguaje máquina nativo, y con ninguna otra herramienta más que su propio BASIC ...

Como se dijo en el anterior capítulo, cada instrucción de código máquina tiene un código numérico asociado, a menudo acompañada por uno o más números (sus operandos), cada número ocupa un byte (justo el "tamaño" de una celda de memoria).

Siendo un programa no más que una sucesión de instrucciones alojadas en la memoria (esperando ser ejecutados cuando les llegue el turno), nuestro primer paso obvio para programar en código máquina con ayuda del BASIC, está claro que consistirá en hallar la forma de transferir los bytes de nuestro programa en código máquina, a la memoria. Para ello necesitamos saber además ¿Qué bytes forman nuestro programa en CM?

Para la primera cuestión (transferir los bytes) el comando POKE viene al rescate (no obstante PEEK y POKE fueron diseñados para esto). También nos resultarán útiles las instrucciones SYS (y USR), para llamar a nuestro programa en CM, y por supuesto la instrucción DATA, para no tener que teclear cada byte con un POKE (¡que derroche de tiempo y memoria!). Ahora que ya tenemos claro como lo vamos a transferir, hablemos de los bytes en si que vamos a transferir (el código objeto del programa).

Pongámonos pues manos a la obra...

El programa de prácticas que vamos a compilar, no hará gran cosa, la verdad sea dicha, pero servirá para comprender a ensamblar de forma manual, lo cual es muy instructivo (¡os lo aseguro!).

Lo que haremos será crear un programa que sume dos números, cada uno de ellos en varias posiciones de memoria, que tranquilamente podéis llamarlas variables (asi es como son las variables en cualquier lenguaje en realidad: una simple posición de memoria que guarda un número).

Tras sumar dos variables, se almacenará el resultado en una tercera (aunque no la utilicemos en realidad) y comprobaremos si el resultado de la suma de las dos variables, es igual a otro que especificaremos en el programa. Si el resultado da = ese número, el color de fondo de la pantalla se incrementará en un bucle sin fin, de lo contrario, lo pondrá del color que indique el resultado obtenido.

Una vez presentado el programa, lo compilaremos a mano, y seguidamente cargaremos en la memoria, el "código objeto" obtenido de nuestra compilación manual, mediante un simple cargador en BASIC.

Lo primero que hay que hacer, antes de "compilar a mano" un programa en CM, es tener éste muy clarito. Para ello, en un bloc de notas, iremos anotando una tras otra, las instrucciones que componen nuestro programa. Previamente, a veces, aunque no es estrictamente necesario, en caso de rutinas/programas muy complejos, tambien podriamos haber dibujado un diagrama de bloques o un "diagrama de flujo", también llamados organigramas para ver claramente la estructura lógica del programa que queremos hacer antes de comenzar a escribirlo (esto es, su algoritmo).

En nuestro caso, éste es el programa que se ha escrito en la libreta:

000 org $033c 001 lda $fa 002 clc 003 adc $fb 004 sta $fc 005 cmp #$07 006 beq BUC 007 sta $d020 008 rts 009 BUC: inc $d020 010 jmp BUC

Fijaos bien que en el ejemplo, hemos escrito los "mnemónicos" de las instrucciones, no los códigos de operación (a los que en realidad, representan). Éstos los veremos acto seguido, en la siguiente fase de nuestra compilación manual...

mnemónicos viene del nombre mnemotécnico que se le dió a cada código de operación, para que los técnicos los recordaran más fácilmente. Suelen ser nombres cortos, abreviaturas/siglas, de no más de tres letras que indican la función exacta de lo que hace cada instrucción. En los primeros dias de la programación, para compilar un programa se consultaba una tabla escrita en papel (al final acababan memorizándose de tanto usarlos, doy fe de ello) para ver qué número correspondia con qué comando y lo introducian manipulando los bits de cada celda de memoria directamente: ¡Un tedioso trabajo electrónico!. Poco a poco se fueron incorporando tarjetas perforadas, consolas de visualización, y otros muchos sistemas de apoyo al pobre programador humano, y todo iba siendo cada vez más práctico. Justo esto es lo que vamos a hacer nosotros, excepto abrir nuestros c64 y manipular los bits directamente... Por otra parte seria muy dificil, por no decir imposible, ¡debido a la miniaturización de los chips! ¡Ni lo intentéis!, ¡eh!...

-------------------------------------- DEC HEX CÓDIGO OPERACIÓN 6510 -------------------------------------- 0 00 BRK 1 01 ORA ($FF,X) 2 02 JAM 3 03 SLO ($FF,X) 4 04 NOP $FF 5 05 ORA $FF 6 06 ASL $FF 7 07 SLO $FF 8 08 PHP 9 09 ORA #$FF 10 0A ASL A 11 0B ANC #$FF 12 0C NOP $FFFF 13 0D ORA $FFFF 14 0E ASL $FFFF 15 0F SLO $FFFF 16 10 BPL $FFFF 17 11 ORA ($FF),Y 18 12 JAM 19 13 SLO ($FF),Y 20 14 NOP $FF,X 21 15 ORA $FF,X 22 16 ASL $FF,X 23 17 SLO $FF,X 24 18 CLC 25 19 ORA $FFFF,Y 26 1A NOP 27 1B SLO $FFFF,Y 28 1C NOP $FFFF,X 29 1D ORA $FFFF,X 30 1E ASL $FFFF,X 31 1F SLO $FFFF,X 32 20 JSR $FFFF 33 21 AND ($FF,X) 34 22 JAM 35 23 RLA ($FF,X) 36 24 BIT $FF 37 25 AND $FF 38 26 ROL $FF 39 27 RLA $FF 40 28 PLP 41 29 AND #$FF 42 2A ROL A 43 2B ANC #$FF 44 2C BIT $FFFF 45 2D AND $FFFF 46 2E ROL $FFFF 47 2F RLA $FFFF 48 30 BMI $FFFF 49 31 AND ($FF),Y 50 32 JAM 51 33 RLA ($FF),Y 52 34 NOP $FF,X 53 35 AND $FF,X 54 36 ROL $FF,X 55 37 RLA $FF,X 56 38 SEC 57 39 AND $FFFF,Y 58 3A NOP 59 3B RLA $FFFF,Y 60 3C NOP $FFFF,X 61 3D AND $FFFF,X 62 3E ROL $FFFF,X 63 3F RLA $FFFF,X 64 40 RTI 65 41 EOR ($FF,X) 66 42 JAM 67 43 SRE ($FF,X) 68 44 NOP $FF 69 45 EOR $FF 70 46 LSR $FF 71 47 SRE $FF 72 48 PHA 73 49 EOR #$FF 74 4A LSR A 75 4B ASR #$FF 76 4C JMP $FFFF 77 4D EOR $FFFF 78 4E LSR $FFFF 79 4F SRE $FFFF 80 50 BVC $FFFF 81 51 EOR ($FF),Y 82 52 JAM 83 53 SRE ($FF),Y 84 54 NOP $FF,X 85 55 EOR $FF,X 86 56 LSR $FF,X 87 57 SRE $FF,X 88 58 CLI 89 59 EOR $FFFF,Y 90 5A NOP 91 5B SRE $FFFF,Y 92 5C NOP $FFFF,X 93 5D EOR $FFFF,X 94 5E LSR $FFFF,X 95 5F SRE $FFFF,X 96 60 RTS 97 61 ADC ($FF,X) 98 62 JAM 99 63 RRA ($FF,X) 100 64 NOP $FF 101 65 ADC $FF 102 66 ROR $FF 103 67 RRA $FF 104 68 PLA 105 69 ADC #$FF 106 6A ROR A 107 6B ARR #$FF 108 6C JMP ($FFFF) 109 6D ADC $FFFF 110 6E ROR $FFFF 111 6F RRA $FFFF 112 70 BVS $FFFF 113 71 ADC ($FF),Y 114 72 JAM 115 73 RRA ($FF),Y 116 74 NOP $FF,X 117 75 ADC $FF,X 118 76 ROR $FF,X 119 77 RRA $FF,X 120 78 SEI 121 79 ADC $FFFF,Y 122 7A NOP 123 7B RRA $FFFF,Y 124 7C NOP $FFFF,X 125 7D ADC $FFFF,X 126 7E ROR $FFFF,X 127 7F RRA $FFFF,X 128 80 NOP #$FF 129 81 STA ($FF,X) 130 82 NOP #$ 131 83 SAX ($FF,X) 132 84 STY $FF 133 85 STA $FF 134 86 STX $FF 135 87 SAX $FF 136 88 DEY 137 89 NOP #$FF 138 8A TXA 139 8B ANE #$FF 140 8C STY $FFFF 141 8D STA $FFFF 142 8E STX $FFFF 143 8F SAX $FFFF 144 90 BCC $FFFF 145 91 STA ($FF),Y 146 92 JAM 147 93 SHA $FFFF,X 148 94 STY $FF,X 149 95 STA $FF,X 150 96 STX $FF,Y 151 97 SAX $FF,Y 152 98 TYA 153 99 STA $FFFF,Y 154 9A TXS 155 9B SHS $FFFF,Y 156 9C SHY $FFFF,X 157 9D STA $FFFF,X 158 9E SHX $FFFF,Y 159 9F SHA $FFFF,Y 160 A0 LDY #$FF 161 A1 LDA ($FF,X) 162 A2 LDX #$FF 163 A3 LAX ($FF,X) 164 A4 LDY $FF 165 A5 LDA $FF 166 A6 LDX $FF 167 A7 LAX $FF 168 A8 TAY 169 A9 LDA #$FF 170 AA TAX 171 AB LXA #$FF 172 AC LDY $FFFF 173 AD LDA $FFFF 174 AE LDX $FFFF 175 AF LAX $FFFF 176 B0 BCS $FFFF 177 B1 LDA ($FF),Y 178 B2 JAM 179 B3 LAX ($FF),Y 180 B4 LDY $FF,X 181 B5 LDA $FF,X 182 B6 LDX $FF,Y 183 B7 LAX $FF,Y 184 B8 CLV 185 B9 LDA $FFFF,Y 186 BA TSX 187 BB LAE $FFFF,Y 188 BC LDY $FFFF,X 189 BD LDA $FFFF,X 190 BE LDX $FFFF,Y 191 BF LAX $FFFF,Y 192 C0 CPY #$FF 193 C1 CMP ($FF,X) 194 C2 NOP #$FF 195 C3 DCP ($FF,X) 196 C4 CPY $FF 197 C5 CMP $FF 198 C6 DEC $FF 199 C7 DCP $FF 200 C8 INY 201 C9 CMP #$FF 202 CA DEX 203 CB SBX #$FF 204 CC CPY $FFFF 205 CD CMP $FFFF 206 CE DEC $FFFF 207 CF DCP $FFFF 208 D0 BNE $FFFF 209 D1 CMP ($FF),Y 210 D2 JAM 211 D3 DCP ($FF),Y 212 D4 NOP $FF,X 213 D5 CMP $FF,X 214 D6 DEC $FF,X 215 D7 DCP $FF,X 216 D8 CLD 217 D9 CMP $FFFF,Y 218 DA NOP 219 DB DCP $FFFF,Y 220 DC NOP $FFFF,X 221 DD CMP $FFFF,X 222 DE DEC $FFFF,X 223 DF DCP $FFFF,X 224 E0 CPX #$FF 225 E1 SBC ($FF,X) 226 E2 NOP #$FF 227 E3 ISB ($FF,X) 228 E4 CPX $FF 229 E5 SBC $FF 230 E6 INC $FF 231 E7 ISB $FF 232 E8 INX 233 E9 SBC #$FF 234 EA NOP 235 EB SBC #$FF 236 EC CPX $FFFF 237 ED SBC $FFFF 238 EE INC $FFFF 239 EF ISB $FFFF 240 F0 BEQ 241 F1 SBC ($FF),Y 242 F2 JAM 243 F3 ISB ($FF),Y 244 F4 NOP $FF,X 245 F5 SBC $FF,X 246 F6 INC $FF,X 247 F7 ISB $FF,X 248 F8 SED 249 F9 SBC $FFFF,Y 250 FA NOP 251 FB ISB $FFFF,Y 252 FC NOP $FFFF,X 253 FD SBC $FFFF,X 254 FE INC $FFFF,X 255 FF ISB $FFFF,X

Asi pues, abrid el archivo: ASCII-opcodes reference.txt en la carpeta "Manuales\Referencias" (C:\C64-Kickass-IDE\manuales\referencias) que se creó al instalar KICKASS IDE. Si no lo habéis hecho ya, es más que recomendable que lo instaléis, ya que os resultará más fácil seguir el curso. No obstante para eso se creó el paquete de desarollo. En ese archivo encontraremos un listado más que útil, con varios códigos que se usan en la programación del C64, de entre los que se encuentran justamente los que necesitamos, en la columna CÓDIGO DE OPERACIÓN.

Como véis en la lista, cada mnemónico tiene un código de operación distinto para cada modo de direccionamiento. De momento no os preocupéis con esto de los "modos de direccionamiento", no tardando mucho, lo veremos con detenimiento. Ahora vamos a convertir el programa con la ayuda de esta lista. Nuestro programa empezaba en la linea 0, con org $033c. Ésto no es un mnemónico propiamente dicho, si no que es una directiva de ensamblador. Sirve para decirle al compilador (¡en este caso nosotros mismos!) cual va a ser la primera dirección de memoria donde se ensamblará el programa.

Asi pues, la directiva org, nos indica que el programa deberá ser ensamblado a partir de la dirección $033c, que corresponde precisamente al área del buffer de casette. Un lugar muy práctico para almacenar pequeños programas CM de prueba como éste, siempre con la precaución de no exceder el tamaño de este área, que comprende el rango $033c-$03fb (ó en decimal 828-1019), y de que no se va a usar el casette mientras se ejecute nuestra rutina, pues éste usa este buffer de forma temporal mientras carga los datos en la memoria.

Nuestra primera instrucción deberá ser ensamblada en esa dirección de memoria y comenzaremos a escribir el código objeto (todavia en la libreta) asi:

828 lda 250

Lo que se hace aquí, es simplemente cargar el registro acumulador (a), con el contenido de la posición de memoria $fa, en decimal 250 (por cierto, una dirección de la famosa pág. cero, no usada por el sistema). Notad que no se va a cargar el acumulador con el valor 250, si no con lo que la dirección de memoria 250 contenga. Concretamente, se dice que se ha usado el Modo de Direccionamiento de Página Cero.

Cargar el acumulador con un número en lugar de una dirección de memoria, se indicaria con el prefijo # delante del número, y estariamos entonces usando el Modo de Direccionamiento Inmediato. Este modo de direccionamiento recibe el nombre del hecho que el operando a usar es el número que le sigue inmediatamente al propio código de operacion. Usando este modo, se escribiria asi: lda #$fa.

Como basic no entiende el formato hexadecimal, vamos a ir convirtiendo todos los números en decimal, pero sabed que es más preferible usar el hexadecimal, ya que todo queda mucho más compacto, entre otros motivos.

Es importantísimo que comprendáis como funciona el sistema hexadecimal asi como el binario, para poder seguir el curso correctamente sin problemas. Doy por hecho que los comprendéis perfectamente, de no ser asi os recomiendo que leáis la siguiente entrada en Wikipedia: http://es.wikipedia.org/wiki/Hexadecimal En el mundo del C64 (y en otros también) se usa el prefijo $ para indicar que un número está en formato hexadecimal, el prefijo %, para indicar que está en binario y si a un número no le antecede ningún prefijo, se entiende que es un número decimal.

Antes de seguir con la siguiente linea, debemos saber cual será su dirección exacta... para ello deberemos mirar en la lista que mencioné lineas atrás, y observar si el operando del comando contiene uno ($FF), dos bytes ($FFFF), o ninguno. Si no contiene ninguno, la instrucción completa ocupa 1 byte en la memoria, y la siguiente dirección seria la anterior + 1 (el propio comando), si tiene un byte de operando ($FF) seria +2 (+1 del propio comando, +1 del operando) , y +3 si tiene dos bytes de operando. Tened en cuenta que en el 6510 (y en toda la familia 65xx) todos los comandos de operación ocupan sólo 1 byte. ¿No es tán complicado, verdad?

la linea anterior nos indica que la siguiente instrucción comenzará pues en 828+2, o sea 830, ya que en la lista vemos que lda $FF (que es el modo de direccionamiento que usamos en nuestro programa para esa linea) sólo tiene un operando ($FF en la lista). Por tanto la siguiente linea para nuestro borrador del código objeto, en la libreta, la escribiremos asi:

828 lda 250 830 clc <<

clc, borra la bandera de acarreo, y es necesario para sumar correctamente un número, ya que la instrucción de suma lo hace teniendo en cuenta el estado de esta bandera del procesador (bandera C, de Carry)

Es una instrucción que no requiere ningún operando, (se dice que está implícito, o mejor dicho que usa el Modo de Direccionamiento Implícito) y por tanto sólo ocupará el byte que ocupa el propio comando. Por ello la siguiente dirección del programa es la anterior +1, o sea 831:

828 lda 250 830 clc 831 adc 251 <<

adc sirve para realizar una suma entre el acumulador y una posición de memoria, añadiendo el acarreo (bandera C), es por esto último que previamante limpiamos esa bandera, con clc, para que la suma sea correcta.

Ésta y las siguientes dos lineas, si nos fijamos en la lista como antes, vemos que tambien ocupan 2 bytes (el "opcode" y su operando). El programa iria quedando asi:

828 lda 250 830 clc 831 adc 251 << 833 sta 252 << 835 cmp #7 << 837 <<

sta 252 almacenará el contenido que tenga en ese momento el registro acumulador en la posición de memoria 252, y cmp #7, comparará el contenido del acumulador con el número 7, poniendo la bandera de cero (Z) = 1 si el numero comparado es igual al contenido en el acumulador, o Z = 0 en caso contrario. Ya veremos con más detalle todo esto, cuando hablemos más a fondo sobre cada instrucción y acerca de las banderas de estado.

La siguiente instrucción, beq es un poco más peliaguda de ensamblar (a mano). Pertenece al tipo de instrucciones de salto condicional y usa el modo de direccionamiento relativo, beq significa "saltar si igual" (Branch on EQual), y la igualdad a la que se refiere exactamente es si el contenido de la bandera de cero está activada (1) o no (0). En caso afirmativo, el siguiente byte del comando, indica el número de bytes a saltar (desde el PC, ó puntero de programa, del fin de la instrucción). Este byte que indica el número de bytes a saltar, es entendido como un número con signo, o lo que es lo mismo, un número binario en complemento a dos. Asi pues, si queremos compilar a mano instrucciones que usen el direccinamiento relativo, tendremos que conocer como se convierte un número en su complemento a dos. La verdad es que es muy sencillo. Para convertir un número positivo en negativo (esto se llama obtener su complemento a dos) tan sólo debemos coger el número en su versión positiva, invertir el valor de sus bits (con lo que tendriamos su complemento a uno) y le sumamos 1. Debido a que un byte con signo sólo puede alcanzar valores entre -127 y +128, esa será la distancia máxima a la que podremos "saltar".

El problema en nuestro caso actual, es que tras el beq no hemos indicado una dirección concreta, sino una etiqueta (por comodidad, a la hora de programar en papel) y todavia nos es imposible de saber el valor que tendrá la dirección a la que queremos saltar... asi que la dejamos asi, con el nombre de la etiqueta, y ya calcularemos el byte de salto relativo más adelante, cuando sepamos su valor concreto. En todo caso, si miramos la tabla, beq es una instrucción que sólo requiere un operando, asi que la siguiente instrucción empezará en PC+2.

Seguimos con la siguiente linea: sta $d020. Ya hemos visto que hace sta, almacena el contenido del acumulador en memoria. En este caso la dirección de memoria indicada en su operando ($d020), fijaos que es un número mayor de 255 (no cabe en un sólo byte), por lo cual no usa direccionamiento de pág. cero como si sucedia en el caso anterior.

En este caso se está usando el Direccionamiento Absoluto, por que usa una dirección absoluta (no relativa), concretamente la dirección $d020, ó 53280 en decimal, ¿a muchos os suena verdad?. Es la dirección de memoria que usa el chip gráfico (VICII) para mantener el color del fondo de la pantalla.

Si miramos en la tabla vemos que hay un STA $FFFF, y si recordáis, cuando el operando era $FFFF la siguiente dirección era la actual +3. Asi va quedando, entonces:

828 lda 250 830 clc 831 adc 251 833 sta 252 835 cmp #7 837 beq BUC << 839 sta 53280 << 842 <<

La siguiente instrucción, rts, en la linea 8, no tiene operandos por lo que la siguiente dirección es la última + 1. Esta instrucción significa "ReTurn from Soubroutine" (volver de subrutina), y basicamente funciona como RETURN en Basic, volviendo al punto del programa donde fue invocada la rutina. En las siguientes lineas, vienen otras instrucciones que tambien usan direccionamiento absoluto por lo que ya conocéis como proceder y daré el resultado directamente. El programa ya ha pasado la fase de "obtener direcciones de ensamblado":

828 lda 250 830 clc 831 adc 251 833 sta 252 835 cmp #7 837 beq BUC 839 sta 53280 842 rts << 843 inc 53280 << 846 jmp 843 <<

Fijaos que ya conocemos el valor de la etiqueta BUC, es justo la dirección que ocupaba donde decia BUC: inc $d020, que es 843. La última instrucción del listado es un salto incondicional, que usa siempre direccionamiento absoluto, y los dos siguientes bytes que le siguen son efectivamente la dirección exacta a la que tendrá que saltar, algo muy distinto a expresar un número de bytes a saltar, como veiamos antes, con el direccionamiento relativo.

Esta dirección de memoria se almacenará usando el método de almacenamiento invertido, asi que en el paso final siguiente de la compilación, deberemos almacenar el número de 16 bits que compone esa dirección en el orden que dicta ese método: primero el byte bajo y luego su byte alto. Para ello resulta útil tener el número de 16 bits en hexadecimal y traducir cada byte al decimal, a la hora de compilarlo (para ponerlo en lineas DATA del BASIC). Por ejemplo $d020, se debe almacenar en memoria como $20 (32 en decimal) y luego $d0 (208 en decimal).

Pero regresemos de momento en el punto donde estabamos. Conocemos la etiqueta BUC (podemos apuntar en una esquina de la libreta, o en una página aparte BUC = 843), y ahora como decia, ya podemos calcular aquel byte del salto relativo que habiamos dejado pendiente. Si fuera direccionamiento absoluto hariamos 837 beq 843, pero las instrucciones de salto condicional no tienen un código de operación que use el dir. absoluto, asi que deberemos obtener que byte poner a continuación del beq. Para ello miramos, ¿cuantos bytes hay que saltar hasta la etiqueta BUC? La respuesta es 4 (843-839), que como es un número positivo (el salto es hacia adelante) no será necesario que calculemos su complemento a dos. Si hubiera sido un salto para atrás de 4 bytes, si que tendriamos que haber expresado -4, que en formato de byte con signo seria 252.

Ahora todo lo que queda es sustituir los mnemónicos por su código de operación (consultando la lista de códigos) y tendremos por fin, el código objeto del programa que habiamos escrito en papel, al que se denomina código fuente. La fuente de la que sale el código objeto...

Dir. | cod. objeto | cod. fuente | 828 165, 250 lda 250 830 24 clc 831 101, 251 adc 251 833 133, 252 sta 252 835 201, 7 cmp #7 837 240, 4 beq 843 839 141, 32, 208 sta 53280 842 96 rts 843 238, 32, 208 inc 53280 846 76, 75, 3 jmp 843

Quiero recordar que se ha ido compilando en decimal, para facilitar el cargador en BASIC, que es de lo que trata el capitulo. Sin embargo fijaos que compacto y clarito queda todo en hexadecimal:

Dir.|cod. objeto | cod. fuente | 033c a5 fa lda $fa 033e 18 clc 033f 65 fb adc $fb 0341 85 fc sta $fc 0343 c9 07 cmp #$07 0345 f0 04 beq $034b 0347 8d 20 d0 sta $d020 034a 60 rts 034b ee 20 d0 inc $d020 034e 4c 4b 03 jmp $034b

Ahora tan solo queda realizar la carga con un bucle FOR NEXT en BASIC, y en las lineas DATA pondriamos los numeros del código objeto que hemos ido obteniendo. Este seria el resultado:

para salir del bucle infinito, pulsaremos la tecla RUN/STOP + RESTORE (ESC + RE.PAG en Vice), tras lo cual podremos probar de nuevo con otros valores (el programa sigue en memoria), p.ej.) poke 250, 1: poke 251, 0: sys 828, que al no ser un resultado = 7, dejaria la pantalla del color del resultado de la suma, que es 1 (el codigo de color para el blanco), sin entar en el bucle infinito con el borde incrementando su color:

Para los que quieran ahorrarse teclear el programa cargador, aqui tienen el disco con el programa ya tecleado:

ensamblalo-cap3.d64

Podéis asimismo comprobar, que tras hacer un SYS 828, la posición de memoria 252 contiene el resultado de la suma. ¡Probadlo vosotros mismos!

Sólo necesitais ejecutar desde el mismo Basic PRINT PEEK(252) Tambien podéis cambiar el valor de 7 en la linea 5 haciendo un POKE 836, 16 por ejemplo, y veréis que ahora el bucle multicolor se ejecutará cuando la suma de las dos variables sea 16. ¡Probadlo!

A todo esto, si por casualidad habéis puesto números en las variables de los sumandos, cuyo resultado fuera mayor de 255 (el "ancho" de un byte), veréis que el resultado obtenido es erróneo. Probadlo ahora: introducid varios valores cuya suma sea mayor que 256...

Para solucionar este problemilla, obviamente deberemos trabajar con números de precisión de 16 bits (o más), lo cual se logra combinando pares de 8 bits. Lo veremos, llegado el momento...

En el próximo capítulo nos olvidaremos de este método y compilaremos un nuevo programa, esta vez con la ayuda de un monitor de código máquina, desde el cual podremos pensar ya tranquilamente en hexadecimal, además ya no tendremos que realizar tantos cálculos extra (con las etiquetas), el monitor se ocupará de ello por nosotros.

Os recomiendo que practiquéis pequeños ensamblados a mano. Para ello os propongo el siguiente ejercicio. Es muy importante que cojáis soltura y os vayáis acostumbrando a operar a este nivel. No dejéis almenos de realizar el ejercicio propuesto: ¡haciendo es como más se aprende!

Ejercicio 1. Compilar a mano el siguiente programa, realizar un cargador en basic y ejecutarlo:

000 org 49152 001 ldx #0 002 FILL: txa 003 sta 1024,x 004 sta 1280,x 005 sta 1536,x 006 sta 1768,x 007 inx 008 bne FILL 009 rts

Si lo hacéis bien, comprobaréis con vuestros propios ojos (nuevamente) la velocidad y potencia que puede llegar a desarrollar incluso un sencillo programa escrito en lenguaje máquina.

Además, podéis trastear con el programa todo lo que queráis (y es muy aconsejable que lo hagáis).

Por ejemplo, ¿que pasaria si cambiaramos el lugar de la etiqueta FILL poniendola en la linea 3? o ¿y si en vez de txa pongo lda #1? ¿o que pasa si cambio ldx #0, por ldx #65...? Obviamente contra más lenguaje sepáis, más cosas interesantes se os ocurrirán de cara a trastear, pero con lo que ya habéis ido aprendiendo, más la propia experimentación descubriréis que es un divertido método con el que seguir aprendiendo y consolidando conceptos.

Sin la curiosidad y la experimentación tan propias del ser humano, no habria existido nunca ciencia alguna, y sin ella hoy en dia, no existirian si quiera los ordenadores...