El otro día cruzábamos la calle con Keila, una amiga. Salíamos de ver una obrita de teatro y nos mandamos mal por Colón, quedando en el medio entre varios autos que iban y venían. Automáticamente pensé en Frogger y se lo mencioné. Ella no entendió la referencia y yo quedé como un tarado. Pero me sirvió la anécdota para escribir esta nota.
Vamos a empezar esta serie con una descripción del CPU 6502, estudiando para qué sirve cada patita de este chip (que básicamente es el pin out) y cómo funciona su arquitectura interna. Vamos a estudiar que registros tiene y para qué sirven. Luego vamos a seguir contando cómo recrear esta placa PCB desde cero y terminaremos con un experimento que nos permitirá ver nuestra primera instrucción del 6502 ejecutándose.
La 2oc es una computadora modular basada en la arquitectura del procesador 6502 diseñada para aprender a programar en Assembler y arquitectura de los computadores.
En este artículo tenemos un índice a todos los artículos de la serie, publicados en el blog de EspacioTec
En esta ocasión vamos a prender varios leds imitando las luces de KIT el auto fantástico usando el puerto de usuario de la Commodore 64 para esto vamos a utilizar como Chiche un User Port Breakout Board.
Estudiaremos que es esta placa, como funciona, cómo conectar un led y escribir un programa en Basic para prenderlo y apagarlo y finalmente cómo conectar una barra de leds y ver las luces estilo auto fantástico.
Continuar leyendo “Los Chiches de la Commodore 64 – Episodio 2- Luces Auto fantástico con un UserPort Breakout Board”Continuamos este estudio comparativo del 6502 vs el 6510 esta vez estudiando qué son las interrupciones.
Vamos a estudiar qué son las interrupciones, los distintos tipos que poseen los procesadores 6502 y 6510, en que pines se encuentran, cómo responde el procesador a cada una de ellas y cuál es la mejor forma de diseñar un programa para qué puedan ser utilizadas para hablar con los periféricos.
Continuar leyendo “6502 vs 6510 Parte 12 – Como funcionan las interrupciones”Continuamos este estudio comparativo del 6502 vs el 6510 esta vez estudiando que es el Stack o Pila.
Vamos a estudiar en dónde se encuentra, que instrucciones lo usan, qué tamaño tiene y cuál es la mejor forma de crear un programa para poder aprovecharlo,
El stack es una porción de la memoria que se utiliza para el almacenamiento de datos temporales. Tiene la característica de ser de organización LIFO (last in first out) lo que significa que el último dato que guardamos en el stack es el primero que va a salir de éste. En este ejemplo vemos que aunque el valor A es el primero que entra en el stack, el mismo es el último que sale luego del valor B.
El stack se encuentra ubicado en la página uno de la memoria con lo que sus direcciones comienzan siempre con $01 y tiene 256 bytes de tamaño, en consecuencia sus direcciones de memoria van desde $01FF a $0100.
Para saber en que aparte del stack nos encontramos tenemos una variable llamada Stack Pointer o SP y que siempre va a indicar la próxima posición vacía del stack. El stack pointer siempre es inicializado en $FF y el $01 de su high byte está harcodeado dentro del 6502 y el 6510.
Algo muy importante a tener en cuenta con el stack es que sólo tenemos 256 posiciones de memoria y que el mismo es circular cuando llenamos la dirección $0100 la próxima es $01FF y si teníamos información útil aquí la misma es sobreescrita perdiéndola, por lo tanto, es muy importante limitar la cantidad de saltos anidados a subrutinas e información que copiamos al stack. A continuación veremos cuantas posiciones de memoria del stack cada instrucción utiliza.
El stack es muy útil en aquellos programas que no trabajan con direcciones de memoria conocidas pero sí con un orden conocido para acceder a la memoria (quien accede primero y quien después). Este tipo de código llamado reentrante se utiliza mucho para poder atender a las interrupciones.
El uso del stack pointer siempre comienza con su inicialización en $01FF.
El Procesador posee algunos registros internos de los cuáles forma parte el stack pointer (recordemos que el stack en sí mismo no es un registro sino un 256 bytes en memoria) y que siempre conviene tenerlos en cuenta.
El acumulador o registro A es un registro de 8 bits que nos va a dejar almacenar valores y realizar operaciones matemáticas en los mismos ya que está conectado tanto a la ALU (unidad aritmético lógica) como a al bus de datos.
Los registros X e Y son registros de 8 bits que nos van a dejar almacenar valores y utilizarlos como índices en distintas operaciones de acceso a memoria.
El Program Counter o PC, es un registro de 16 bits que almacena la dirección de memoria en la cual vamos a ejecutar la próxima instrucción, se divide en sus 8 bits high o PCH y sus 8 bits low o PCL ya que la memoria es de 8 bits en su contenido y para poder “llenarlo” debemos acceder dos veces a ella.
El stack pointer con 8 bits en su dirección de memoria low y 8 bits grabados como $01 en su parte High el cúal como vimos indica la posición dentro del stack.
El Processor Status Register o P contiene 8 bits de los cuáles se usan 7
Las instrucciones que usamos en el Stack ocupan utilizan un número fijo de bytes siendo 3 para las interrupciones, 2 bytes para las subrutinas y 1 byte para los datos guardados por el usuario.
El stack comienza en $01FF y se decrementa. Esta nomenclatura que parece rara se creó porque existían implementaciones donde se usaba una sóla página de memoria (el stack era $00FF ubicado en la zero page) entonces los usuarios utilizan espacio para programas y variables comenzando desde la dirección $0000 e incrementando el program counter y el stack decrementa desde $00FF. ¡Con suerte nunca se juntaban en el medio!
Hay 4 instrucciones que utilizamos para enviar y retirar información al stack. PHA, PLA, PHP, PLP
El stack sólo puede comunicarse con el Accumulador para recibir datos que nosotros queramos guardar en él, la instrucción para guardar datos por excelencia es Push Accumulator to Stack o PHA. Esta instrucción realiza los siguientes pasos:
Esto graba en memoria (en la sección del stack) lo que teníamos en el acumulador
Para poder tomar los datos que teníamos en el stack y volver a traerlos a memoria tenemos la instrucción Pull from Accumulator PLA
Hay que destacar que el sacar datos del Stack no borra los datos que tenemos en el mismo, sino que sólo desplaza el stack pointer, podríamos si quisiéramos seguir accediendo a estos datos con una instrucción de load desde la dirección $01FF, LDA $01FF.
Existe otro byte muy útil de analizar qué es el que mantiene el status de todo el procesador, este byte se denomina Processor Status Register y contiene varios bits útiles como ya hemos visto que representan el estado del procesador.
Si vamos a realizar algunos cambios o realizar operaciones que puedan modificar estos bits y no queremos perder los bits originales tenemos la operación PHP y su contraparte para recuperar los datos PLP.
Para guardar los bits del PSR la instrucción por excelencia es Push PSR to Stack o PHP. Esta instrucción realiza los siguientes pasos:
Esto graba en memoria (en la sección del stack) lo que teníamos en el acumulador.
Para poder tomar los datos que teníamos en el stack y volver a traerlos a memoria tenemos la instrucción Pull from Processor Status Register PLP
Hay 4 instrucciones que usan el stack para almacenar datos sin que nosotros decidamos qué datos son, JSR, RTS y BRK, RTI.
Cada vez que hacemos un salto hacia una subrutina JSR deberemos saber de alguna forma a dónde volver luego de ver el comando de fin de la subrutina RTS. Para saberlo utilizamos el stack donde almacenaremos el byte high y low de la dirección de la próxima instrucción luego del salto. También en forma parecida van a funcionar BRK que indica salto a una interrupción y RTI que es el regreso desde la misma.
La instrucción JSR o Jump to Subroutine utiliza el stack para guardar información de retorno a la ejecución del programa actual una vez esta subrutina haya finalizada, veamos los pasos que realiza:
La instrucción RTS nos devuelve desde una subrutina hasta la próxima instrucción a ejecutar después de la llamada a la misma en donde estuvimos ejecutando código. Sus pasos de ejecución son los siguientes:
El comando BRK simula la ejecución de una subrutina, algo muy importante a tener en cuenta es que él mismo nos va a dar como dirección de regreso Program Counter + 2 con lo que tenemos que tener un cuenta poner un byte que se pueda descartar después del break como ser por ejemplo un NOP, o nuestro programa no va a funcionar ya que volverá a un dirección incorrecta. También podemos utilizar ese byte extra para poder almacenar un código de por qué sucedió el break.
Esta instrucción tarda 7 ciclos antes de comenzar a ejecutar el programa que va a atender la interrupción (handler), y sus pasos de ejecución son los siguientes:
La instrucción RTI nos regresa desde dentro del programa que usamos como handler de la interrupción y reversa alguno de los pasos de la llamada a interrupción original. Estos son sus pasos:
El siguiente programa en código máquina usa el stack a través de 8 instrucciones PHA, PLA, PHP, PLP, JRS, RTS, BRK y RTI. Fue ejecutado en un procesador 6510 original creado en la semana 13 del año 1986.
Si ponemos un analizador de protocolo a ver los resultados de estos comandos podemos observar los siguientes resultados, el formato de los mismos sera:
10 0 Descartar no lo vamos a utilizar en el análisis
1000000000000000 Address Bus en Binario
10100010 Data Bus en Binario
8000 Address Bus en Hexadecimal
r Operación de Lectura “r” o escritura “W”
a2 Data Bus en Hexadecimal
ldx Si es una instrucción, el correspondiente mnemónico de assembler si no es un dato o dirección de memoria y se lee literal.
Lo primero que pasa con este programa es que comenzamos en la dirección 8000, cargamos ff en el registro X y lo transmitimos al Stack, la última operación que aparece como a9 es un ciclo que gasta el procesador en guardar el valor FF en el registros interno del Stack Pointer.
En este segmento del programa vemos cómo almacenar dos valores desde el acumulador al stack y como traerlos.
Cargamos el valor 64 al acumulador.
10 0 1000000000000011 10101001 8003 r a9 lda
10 0 1000000000000100 01100100 8004 r 64
Lo transferimos al stack y el próximo ciclo de instrucción 8006 se pierde ya que es utilizado internamente
10 0 1000000000000101 01001000 8005 r 48 pha
10 0 1000000000000110 10101001 8006 r a9 lda
Escribimos el valor 64 en la dirección 01ff del stack en memoria, el stack pointer queda en 01fe
10 0 0000000111111111 01100100 01ff W 64
Cargamos el valor 99 al acumulador.
10 0 1000000000000110 10101001 8006 r a9 lda
10 0 1000000000000111 10011001 8007 r 99
Lo transferimos al stack y el próximo ciclo de instrucción 8009 se pierde ya que es utilizado internamente
10 0 1000000000001000 01001000 8008 r 48 pha
10 0 1000000000001001 01101000 8009 r 68 pla
Escribimos el valor 99 en la dirección 01fe del stack en memoria, el stack pointer queda en 01fd
10 0 0000000111111110 10011001 01fe W 99
Pedimos transferir un valor desde el stack (el 99) y la próxima instrucción 800a se descarta
10 0 1000000000001001 01101000 8009 r 68 pla
10 0 1000000000001010 01101000 800a r 68 pla
Se escribe la posición actual del stack pointer 01fd en el address bus y se descarta el dato y se incrementa el stack pointer.
10 0 0000000111111101 01110000 01fd r 70
Se lee la posición actual del stack pointer 01fe y se guarda el valor en el acumulador
10 0 0000000111111110 10011001 01fe r 99
Pedimos transferir un valor desde el stack (el 64) y la próxima instrucción 800b se descarta
10 0 1000000000001010 01101000 800a r 68 pla
10 0 1000000000001011 10101001 800b r a9 lda
Se lee de la posición actual del stack pointer 01fe y se descarta y se incrementa el stack pointer.
10 0 0000000111111110 10011001 01fe r 99
Se lee la posición actual del stack pointer 01ff y se guarda el valor en el acumulador
10 0 0000000111111111 01100100 01ff r 64
En este segmento del programa vemos cómo almacenar dos veces el Processor Status Register, la segunda vez lo cambiamos para que el flag de testeo Zero esté en 1 asignando previamente al acumulador un valor de 0. Para terminar el programa traemos desde el stack esos valores.
Cargamos el valor 64 al acumulador.
10 0 1000000000001011 10101001 800b r a9
10 0 1000000000001100 01100100 800c r 64
Pedimos transferir al stack el Processor Status Register y el próximo ciclo de instrucción 800e se pierde ya que es utilizado internamente
10 0 1000000000001101 00001000 800d r 08 php
10 0 1000000000001110 10101001 800e r a9
Escribimos el valor 3d en la dirección 01ff del stack en memoria, el stack pointer queda en 01fe
Este valor representa el número binario 0011 1101 usando los flags del procesador es
N=0,V=0,E=1,B=1,D=1,I=1,Z=0,C=1 Podemos ver que el flag Z está en cero ya que el resultado de la última operación es 64 distinto de cero.
10 0 0000000111111111 00111101 01ff W 3d
Cargamos el valor 0 al acumulador.
10 0 1000000000001110 10101001 800e r a9
10 0 1000000000001111 00000000 800f r 00
Pedimos transferir al stack el Processor Status Register y el próximo ciclo de instrucción 8011 se pierde ya que es utilizado internamente.
10 0 1000000000010000 00001000 8010 r 08 php
10 0 1000000000010001 00101000 8011 r 28
Escribimos el valor 3f en la dirección 01fe del stack en memoria, el stack pointer queda en 01fd
Este valor representa el número binario 0011 1111 usando los flags del procesador es
N=0,V=0,E=1,B=1,D=1,I=1,Z=1,C=1 Podemos ver que el flag Z está en uno ya que el resultado de la última operación es cero.
10 0 0000000111111110 00111111 01fe W 3f
Pedimos transferir un byte desde el stack (el 3f) al Processor Status register y la próxima instrucción 8012 se descarta.
10 0 1000000000010001 00101000 8011 r 28 php
10 0 1000000000010010 00101000 8012 r 28
Se lee de la posición actual del stack pointer 01fd y se descarta y se incrementa el stack pointer.
10 0 0000000111111101 01110000 01fd r 70
Se lee la posición actual del stack pointer 01fe y se guarda el valor en el Processor Status register
10 0 0000000111111110 00111111 01fe r 3f
Pedimos transferir un byte desde el stack (el 3f) al Processor Status Register y la próxima instrucción 8013 se descarta.
10 0 1000000000010010 00101000 8012 r 28 php
10 0 1000000000010011 00100000 8013 r 20
Se lee de la posición actual del stack pointer 01fe y se descarta y se incrementa el stack pointer.
10 0 0000000111111110 00111111 01fe r 3f
Se lee la posición actual del stack pointer 01ff y se guarda el valor en el Processor Status Register
10 0 0000000111111111 00111101 01ff r 3d
En este segmento del programa vemos cómo saltar hacia una subrutina., cómo se almacena la dirección de retorno y que pasos se dan en el programa para volver al mismo momento desde donde partió el llamado de la subrutina.
Comienza nuestro programa en la dirección $8013 con un JSR para saltar a la subrutina, pero en lugar de tener a continuación una dirección de memoria tenemos el byte 1c, este es el low address en el que comienza nuestra subrutina con un lda #$44 como podemos ver al hacer un dump en binario de nuestro código, seguido de este tenemos el byte 80, lo que apunta nuestra subrutina la dirección $801C ya que siempre las direcciones de memoria de JSR son absolutas.
Se lee el byte de la dirección del futuro Low address $1C, esto va a pasar a PCL en algunos ciclos más.
10 0 1000000000010011 00100000 8013 r 20 jsr
10 0 1000000000010100 00011100 8014 r 1c
Se lee de la posición actual del stack pointer 01ff y se descarta.
10 0 0000000111111111 00111101 01ff r 3d
Se escribe PCH, el High Byte del program counter en la posición actual del stack pointer 01ff y se decrementa el stack pointer que queda en 01fe.
10 0 0000000111111111 10000000 01ff W 80
Se escribe PCL, el Low Byte del program counter en la posición actual del stack pointer 01fe y se decrementa el stack pointer que queda en 01fd.
10 0 0000000111111110 00010101 01fe W 15
Se lee la instrucción en la posición de memoria del high byte de la subrutina y se copia al PCH para poder hacer el jump a 801C una vez actualizado el program counter.
10 0 1000000000010101 10000000 8015 r 80
Comienza la ejecución de nuestra subrutina cargando el valor 44 en el acumuladore
10 0 1000000000011100 10101001 801c r a9 lda
10 0 1000000000011101 01000100 801d r 44
Se carga la instrucción sta para grabar el acumulador en la posición de memoria 2003
10 0 1000000000011110 10001101 801e r 8d sta
10 0 1000000000011111 00000011 801f r 03
10 0 1000000000100000 00100000 8020 r 20
Se escribe la posición de memoria 2003
10 0 0010000000000011 01000100 2003 W 44
Se pide volver de la subrutina con la instrucción rts, se lee la próxima instrucción en la posición 8022 y se descarta.
10 0 1000000000100001 01100000 8021 r 60 rts
10 0 1000000000100010 10101001 8022 r a9
Se lee de la posición actual del stack pointer 01fd y se descarta y se incrementa el stack pointer.
10 0 0000000111111101 01110000 01fd r 70
Se lee de la posición actual del stack pointer 01fe el low byte del PCL a y se incrementa el stack pointer.
10 0 0000000111111110 00010101 01fe r 15
Se lee de la posición actual del stack pointer 01ff el high byte del PCH a y se incrementa el stack pointer.
10 0 0000000111111111 10000000 01ff r 80
El Program Counter queda en 8015 y se busca la próxima instrucción en esa dirección
10 0 1000000000010101 10000000 8015 r 80 brk
En este segmento del programa vemos cómo se ejecuta una interrupción brevemente, hablaremos más de interrupciones como suceden y para que se usan en un próximo capítulo.
Este programa causa una interrupción por software llamada break la cuál hace que el procesador vaya a las direcciones $FFFE y $FFFF para buscar los bytes que indican que programa comenzar a ejecutar, este en nuestro caso es el que comienza en la etiqueta irq:
El break nos va a dar como dirección de regreso Program Counter + 2 con lo que tenemos que tener un cuenta poner un byte que se pueda descartar después del break como ser por ejemplo un NOP o nuestro programa no va a funcionar ya que volverá a un dirección incorrecta. También podemos utilizar ese byte extra para poder almacenar un código de por qué sucedió el break.
Esta instrucción tarda 7 ciclos antes de comenzar a ejecutar el programa que va a atender la interrupción (handler). A continuación nuestro programa corregido (notar el NOP) y veremos todos nuestros address familiares corridos un byte.
Nuestro segmento de programa entonces comienza en $8018 con el comando BRK cuyo código es $00, lee a continuación el próximo byte y lo descar
10 0 1000000000011000 00000000 8018 r 00 brk
10 0 1000000000011001 11101010 8019 r ea NOP
Escribe en el stack en las posiciones 01ff a 01fe la posición a la cual regresar $801a, nótese que si no tuviéramos la instrucción NOP regresaremos un byte antes a nuestro programa y este NO FUNCIONARIA.
10 0 0000000111111111 10000000 01ff W 80
10 0 0000000111111110 00011010 01fe W 1a
Escribe en el stack el Processor Status Register
10 0 0000000111111101 00110110 01fd W 36
Lee el vector fffe y ffff (low y high byte) para saber dónde está el handler o programa que manejará la interrupción, en este caso en la posición 8023.
10 0 1111111111111110 00100011 fffe r 23
10 0 1111111111111111 10000000 ffff r 80
Con el program counter en 8023 correspondiente a la etiqueta irq: carga la primera instrucción para guardar el valor 55 en el acumulador.
10 0 1000000000100011 10101001 8023 r a9 lda
10 0 1000000000100100 01010101 8024 r 55
Lee una instrucción para guardar el valor del acumulador en la posición de memoria 2005
10 0 1000000000100101 10001101 8025 r 8d sta
10 0 1000000000100110 00000101 8026 r 05
10 0 1000000000100111 00100000 8027 r 20
Escribe en la posición de memoria 2005 el valor 55
10 0 0010000000000101 01010101 2005 W 55
Lee la instrucción rti para salir del handler de interrupciones.
10 0 1000000000101000 01000000 8028 r 40 rti
Ciclo Interno, Lee el próximo byte y lo descarta.
10 0 1000000000101001 00000000 8029 r 00
Se lee de la posición actual del stack pointer 01fc y se descarta y se incrementa el stack pointer.
10 0 0000000111111100 00101101 01fc r 2d
Se lee de la posición actual del stack pointer 01fd y se copia la información al Processor Status Register y se incrementa el stack pointer.
10 0 0000000111111101 00110110 01fd r 36
Se lee la posición actual del stack pointer 01fe y se copia la información al PCL y se incrementa el stack pointer.
10 0 0000000111111110 00011010 01fe r 1a
Se lee la posición actual del stack pointer 01fe y se copia la información al PCH y se incrementa el stack pointer.
10 0 0000000111111111 10000000 01ff r 80
Se resumen la ejecución del programa en un loop infinito que salta a la posición de memoria 8019 en forma recurrente,
10 0 1000000000011010 01001100 801a r 4c jmp
10 0 1000000000011011 00011010 801b r 1a
10 0 1000000000011100 10000000 801c r 80
10 0 1000000000011010 01001100 801a r 4c jmp
10 0 1000000000011011 00011010 801b r 1a
10 0 1000000000011100 10000000 801c r 80
10 0 1000000000011010 01001100 801a r 4c jmp
10 0 1000000000011011 00011010 801b r 1a
10 0 1000000000011100 10000000 801c r 80
Si queremos realmente profundizar y ver como el CPU decrementa el stack, podemos usar un proyecto como visual6502 que nos muestra como funcionan las señales internas del procesador.
Primero saber que para decrementar en realidad se realiza la suma al complemento por lo que si queremos restarle uno a FD es lo mismo que sumarle FF
FD -1 = FC
FD + FF = FC
Veamos algunas de las señales internas utilizadas.
Más abajo que esto no podemos llegar adentro de un 6502 (Más profundo y llego a China)., para más información busquen el Diagrama de Hanson del interior del 6502 y el proyecto visual6502 ambos sitios incluidos en las referencias de este artículo.
El stack es utilizado en la Commodore 64 para todas estas instrucciones que vimos originalmente con exactamente las mismas funciones y parámetros. Todo el código que vimos en este artículo fue ejecutado en un MOS 6510 de la semana 13 de 1986.
El stack también comienza en la dirección $01FF y el valor del stack pointer es inicializado en la rutina de inicialización de la commodore:
.,FCE2 A2 FF LDX #$FF START LDX #$FF
.,FCE4 78 SEI SEI
.,FCE5 9A TXS TXS
.,FCE6 D8 CLD CLD
.,FCE7 20 02 FD JSR $FD02 JSR A0INT ;TEST FOR $A0 ROM IN
.,FCEA D0 03 BNE $FCEF BNE START1
.,FCEC 6C 00 80 JMP ($8000) JMP ($8000) ; GO INIT AS $A000 ROM WANTS
.,FCEF 8E 16 D0 STX $D016 START1 STX VICREG+22 ;SET UP REFRESH (.X=<5)
.,FCF2 20 A3 FD JSR $FDA3 JSR IOINIT ;GO INITILIZE I/O DEVICES
.,FCF5 20 50 FD JSR $FD50 JSR RAMTAS ;GO RAM TEST AND SET
.,FCF8 20 15 FD JSR $FD15 JSR RESTOR ;GO SET UP OS VECTORS
;
.,FCFB 20 5B FF JSR $FF5B JSR CINT ;GO INITILIZE SCREEN
.,FCFE 58 CLI CLI ;INTERRUPTS OKAY NOW
.,FCFF 6C 00 A0 JMP ($A000) JMP ($A000) ;GO TO BASIC SYSTEM
Esta rutina es llamada cada vez que se ejecuta un reset a través del vector del mismo nombre que está en las direcciones $FFFC, $FFFD
.:FFFA 43 FE .WOR NMI ;PROGRAM DEFINEABLE
.:FFFC E2 FC .WOR START ;INITIALIZATION CODE
.:FFFE 48 FF .WOR PULS ;INTERRUPT HANDLER
Para poder estudiar visualmente cómo funciona el stack les dejo esta video que complementa al artículo.
El Stack – 6502 vs 6510 Episodio 11
A continuación les dejo algunos links donde profundizar el tema:
WEBSITE
Aqui el sitio de OsoLabs con todos los videos y artículos
VIDEOS
Video de la serie 6502 vs 6510 Episodio 11 – El Stack
El Stack – 6502 vs 6510 Episodio 11
Aquí tiene acceso a toda la serie:
6502 vs 6510 estudio detallado y comparación
PAPERS
MCS6500 Microcomputer Family Programming Manual
Load and Run from 6502 ASM (1/2) | C64 OS
27c3: Reverse Engineering the MOS 6502 CPU (en)
Y como siempre la serie de Ben Eater del 6502
Build a 6502 computer | Ben Eater
Todos los ejemplos de código de los videos los pueden encontrar en:
Algunos de los easter eggs mas famosos, revisitados en esta entrega en el dia de pascuas.
La película Ready Player One (2018) dirigida por Steven Spilberg y basada en el libro homónimo de Ernest Cline popularizó el ya ultra conocido (gracias a internet) “primer easter egg (huevo de pascua) de la historia”. De la historia de los videojuegos, aclaremos. Y también aclaremos que eso es lo que creemos, solo hasta que aparezca uno anterior.
Cuenta la historia que Atari era reacia a dar a conocer los nombres de los programadores, artistas y diseñadores de sus videojuegos que por aquel entonces se publicaban para sus sistemas, en este caso para el Atari VCS/2600. Lo cual tenía a estos personajes algo disconformes. Así fue que en un acto de rebeldía, en el juego Adventure (1979), si el jugador hacía una cierta serie de acciones aparecería en pantalla la leyenda”Created by Warren Robinet”, en clara declaración de autoría e inmortalizando un nombre que de otra forma, hubiese quedado como uno más del montón.
Hay que entender el contexto, claro. No es que Atari fuera un explotador tampoco. Simplemente, la industria aún estaba en pañales. Y “el Atari” era, de alguna manera, considerado un juguete. Se vendía en los mismos mostradores que los juegos electrónicos, y las máquinas de pong hogareñas. Entonces los cartuchos de juegos eran meros accesorios que uno podía comprar (o pedirle a Santa) para cambiar el juego de la consola. Un gran avance sobre la generación anterior (las maquinas de Pong), que solo tenían un juego (o variantes de esta) y la cosa ya se estaba poniendo aburrida. Fairchild ya lo había hecho un año antes, pero la idea estaba en el aire. Y bajo esa lógica, así como Mattel no publicaba los accesorios de Barbie con el nombre de sus diseñadores, ¿porque lo haría Atari o quien fuese con sus cartuchos? “Sí, lo hizo un ingeniero. Un empleado. Pero te lo vende Atari”. Desde el punto de vista de la empresa, daba igual quién fabricaba qué parte.
Pero sucede que a diferencia del caso de Barbie, los juegos terminaron siendo lo más importante de la consola. Y si le sumamos el hecho que la VCS/2600, debido a sus limitaciones, era extremadamente difícil de programar, estos tipos era Rockstars. Invaluables y… mal pagos. Bueno, según ellos. Artistas. Así que no es de extrañar esa necesidad de querer firmar la obra.
Vamos a repasar algunos easter eggs fomosos que tal vez ya nuestros lectores conozcan, o tal vez no. En cualquier caso, siempre es divertido encender alguna de estas máquinas de 40 años y ver que todavía siguen ahí. Y esto las hace un poquito mas humanas… ¿no les parece?
Microsoft!
Cuenta la historia que Jack Tramiel, fundador de Commodore, en una maniobra (y canchereada a lo “che pibe”) le dijo a Bill Gates “yo ya me casé una vez” cuando éste le propuso la idea de que el interprete BASIC que le había vendido para sus nuevas microcomputadoras PET lo usaran bajo el modelo de licencias. Pero Jack ya había pagado una vez y no quería atarse a nadie. Bill entonces, previendo un posible juicio donde tuviese que demostrar autoría, dejó escondido dentro del código de su interprete la palabra “Microsoft!”. El comando mágico es
WAIT 6502,x
…donde X es la cantidad de veces que se escribe.
Claro que luego los ingenieros de Commodore lo descubrieron (Bill no se contuvo y lo escribió en una CES…) y lo eliminaron; pero si aún tienen acceso a una de las primeras PET, Billy sigue saliéndose con la suya.
Corolario: cuando Commodore necesitó un nuevo BASIC para la flamante y pronto a estrenarse Amiga… bueno digamos que por eso es que en la pantalla de la contemporánea C128 tuvieron que poner “BASIC 7.0 (c)1977 Microsoft Corp.” Pero Jack ya no estaba.
Software y Herdware
Ya que mencionamos la Commodore 128, los ingenieros que participaron en su desarrollo también quisieron dejar su marca. Bueno. Es que se había puesto de moda. Dentro de los gabinetes de las “súper avanzadas” Apple Macintosh (1984) y Commodore Amiga (1985) podemos ver inmortalizadas en el plástico las firma de los artistas que las crearon. Cada plataforma que salia al mercado era un sistema completamente nuevo al cual había que inventarle todo, esto requería de trabajo en equipo. Y mucho esfuerzo. Así que había que dejar la huella.
El comando mágico es entonces:
SYS 32800,123,45,6
… y aquí podemos ver quienes fueron los encargados del Software y quienes del Hardware o “herdware”, juego de palabras porque Bill Herd fue el encargado de liderar el equipo.
Pero ya lo habían hecho antes también. Si en la Commodore 16, Commodore 116 o Commodore Plus/4 (son básicamente la misma maquina en diferentes configuraciones) escribimos:
SYS 52651
… aparecerán los nombres de los involucrados.
Rebeldes
Como vimos al principio, los Easter Eggs no son solo una manera de firmar la obra. Sino también pretenden dejar un mensaje. A veces menos y a veces más explicito.
Terminando este artículo (que podría volverse infinito), me pareció muy emblemático el caso de la Amiga 500 (1987).
Commodore era una empresa que tras la renuncia de Jack Tramiel se volvió algo caótica. Cuando los ingenieros terminaron el desarrollo del Amiga, tenían en sus manos la computadora de consumo masivo (léase “hogareña” o “personal”) más poderosa del momento. Pero fue un fracaso en ventas, principalmente porque la gente de Marketing (al menos la gente de marketing de USA, aclaremos), no supo venderla. Eran áreas que estaban muy desconectadas entre si, lo que trajo mucha rivalidad interna y frustración en los desarrolladores.
Así que para la salida de la Amiga 500 nuestros enojados amigos dejaron en ROM (Kickstart 1.2) lo siguiente: Al presionar ambas teclas ALT, ambas teclas SHIFT, y las teclas de función obtenemos los siguientes mensajes en la barra de menu:
… + F1 : “System Software: Carl, Neil & Kodiak”
… + F2: “Graphics Software: Dale, Bart, Jim & :RJ:
… + F3: “QA: Jon, Bruce, Stan, Kim & Jerry
… + F4: “LG Support: Caryn, Dave, Victor, Terry, Cheryl & Nancy”
… + F5: “CBM Software: Andy, Barry, Dave & Eric”
… + F6: “Pics: Sheryl & Jack”
… + F7: “Docs: Rick, Mitch, Peggy & Rob”
… + F8: “Chips: Jay, Akio, Glenn, Edwin, Mark & Dave”
… + F9: “HW: Dave, Bill, ChrisR & Josh”
… + F10: “Me Made Amiga, They fucked it up.”
Wow.
Cuando Commodore descubrió ese ultimo, imagínense que no les resultó nada gracioso, porque si bien la combinación de teclas es algo … digamos … complicada, no es tan difícil que se dé, así que pidieron que se remueva.
Pero lejos de hacerlo, solo lo escondieron más. En las siguientes revisiones del ROM, con F10 podíamos leer: “Moral Support: Joe Pillow & The Dancing Fools” (la explicación de estos personajes requiere un artículo aparte)
Pero si presionamos la combinación antes citada con F1 y quitamos el diskette del drive interno, aparecerá el mensaje “The Amiga, Born a Champion”.
Pero esto no es todo. Si luego, sin soltar nada, presionamos el botón izquierdo del mouse y volvemos a introducir el disquette, vuelve a aparecer “We made Amiga…”
Como crear un adaptador de teclado Bluetooth a PS/2 si nadie lo ha hecho antes
Si hablara, ella te diría que me conoce desde chico, y yo te digo que la conozco muy bien. A ella le debo parte de mi interés por la ciencia, por las cosas técnicas. Fue tal el revuelo en casa cuando apareció, que algo adentro de mi muy joven yo hizo clic. Con ella podía jugar, dibujar, explorar, hacer mi propio mundo ahí adentro, pero no era simple. Había que aprender, había que probar, pero había que tenerle respeto para no romperla, que ya era una herramienta esencial de trabajo. Fuera del horario laboral éramos yo y ella. No podía molestar cada vez que quería hacer algo, tuve que aprender yo mismo como usarla, como invocar las cosas que quería, como salir de ese menú raro que se había puesto y no había visto nunca.
Ella, es mi PC 486 de 1997. Cyrix DX2 a 66Mhz en sus orígenes, hoy un DX4 a 100Mhz después de que esa batería asesina le comiera su placa madre original. No importa, sigue siendo ella, con su hermoso gabinete y un disco duro que al día de hoy tiene los mismos dibujos y savegames que le hice cuando tenía 7 años, más o menos. Para mi siempre fue todo pc speaker; era una PC de trabajo. Ya de adolescente un amigo me regaló su vieja SoundBlaster CT2230, y descubrí todo lo que me había estado perdiendo. De vez en cuando juego algún que otro juego, como los legendarios Monkey Island que nunca jugué de chico, le vuelvo a dar una pasada a los niveles de Jill of the Jungle que tanto conozco, o instalo algún que otro software interesante que hoy en día gracias a los archivos online están al alcance de la mano.
En fin, ella me acompañó toda mi vida. Siempre en su propio mueble y hoy en día en escritorio compartido con mi setup moderno; comparte monitor y parlantes con mi Lenovo Yoga 720 de 2017 utilizando un conversor de VGA a HDMI. Solo tengo que estirarme, encenderla, tocar dos botones en el monitor y ¡pum!, nos fuimos a 1997. ¿Nos jugamos YA un Indianápolis 500? Dale. Acordate que la carpeta se llama INDI y está en C:\JUEGOS\. Si más vale, cómo olvidarlo, dejame que en Norton Commander uso las flechas del teclado y ya lo pong… ¡Ah!, el teclado. Beige, enorme, crujiente pero de muy buenas teclas y un enter que daba placer, engorroso y con un cable largo. Saco mi moderno y práctico teclado Bluetooth que uso con la 720 y me dispongo a cambiarlo por ese bicho, ¡si solo pudiera usar el mismo teclado para mis dos PCs!
De toda necesidad salen planes y de esos planes, soluciones. No encontré nada en internet que resuelva mi problema, parecía que nadie lo había intentado y ninguna empresa le vió potencial comercial como para ponerse a fabricar un adaptador que permita conectar un teclado Bluetooth a un sistema con puerto PS/2. Ahí nomás se me prendió la lamparita y acepté el desafío, de la misma manera que acepté el desafío de aprender computación cuando era joven. Tenía que poner a uso práctico mis modestos conocimientos de C++ y hacer un proyecto con alguna de esas placas de desarrollo que tan famosas son hoy en día. Arduino tiene una gran comunidad pero su hard está un poco anticuado ya. Así descubrí la ESP-32 de EspressIF, este pequeño gigante tiene WiFi, Bluetooth, un IO completísimo y un procesador de núcleos duales a 240Mhz, todo a un precio accesible, ¡casi está para reemplazar la PC entera!
Nunca lo hubiera logrado de no ser porque encontré dos librerías para ESP-32 que la comunidad ya había pre-cocinado, o al menos hubiera tardado muchísimo más que la semana y media que me llevó. La primera es PS2dev, que maneja toda la interfaz PS/2 y emula ser un teclado. PS2dev estaba muy verde, poco desarrollada, solo encontré un usuario que la había usado exitosamente en un sistema no-PC-compatible y un montón más que se quejaban de que no servía para nada. Entonces empecé a debugearla y me encontré con que el problema estaba en el tiempo.
PS/2 (o PC-AT si nos remontamos a sus orígenes), es un protocolo serial bidireccional, donde la PC (el host) y el teclado periférico se turnan para comunicarse por un único cable de datos, regidos por una señal de reloj. El teclado envía las teclas presionadas y las ya no presionadas como códigos de uno o dos bytes de largo llamados make codes y break codes, correspondientes a una tabla que los asignaba a cada símbolo y letra a la que IBM llamó Scan Codes. Normalmente el teclado envía estos códigos y no pasa más nada, la computadora recibe el mensaje y actúa como esperamos. Pero hay ciertas ocasiones donde la comunicación hace uso de su carácter bidireccional, es decir que el host se comunica con el teclado, por ejemplo para solicitarle información, apagar o prender sus LEDs, etc. Para esto la computadora envía mensajes, llamados Mensajes de Comandos PS/2, y espera para cada uno al menos una respuesta de confirmación proveniente del teclado, llamada ACK (por acknowledge o “confirmación” en inglés). Entonces si queremos emular un teclado real tenemos que responder en tiempo y forma a estos mensajes de comandos. PS2dev lo hacía, pero resulta que las BIOS (sistema básico que controla el arranque e IO de una PC compatible) suelen ser muy exquisitas con sus tiempos y encontré varios sistemas donde la actuación de PS2dev no podía superar el encendido de la máquina, haciendo que la BIOS ignorara totalmente a nuestro “teclado”. En una Toshiba 205CDS respondía muy rápido a la pregunta “¿sos un mouse o un teclado?” ocasionando que la BIOS no recibiera el mensaje y configurara el periférico por defecto a un mouse, porque su puerto PS/2 es combinado. En mi 486 respondía muy rápido al mensaje “¡prendé tu LED de Num Lock!”, la BIOS no lo recibía y terminaba ignorando el teclado, asumiendo que estaba funcionando mal. Solo solucioné todos estos errores agregando los delays específicos en el preciso momento que eran necesarios, antes y después de cada ACK. ¡Y estoy hablando de microsegundos!
Con PS2dev finalmente funcionando nos quedaba la otra mitad; la comunicación Bluetooth. Mi teclado es BLE o Bluetooth Low Energy, un nuevo protocolo mucho más eficiente que hoy en día coexiste con el ultra-archi-conocido Bluetooth Classic. Otra librería me dió el dominio para esta interfaz, bt_keyboard, hecha por un usuario de la comunidad que usó el ejemplo publicado por el mismísima fabricande del ESP32, EspressIF, usando su API para Bluetooth HID recién salida del horno.
Bt_keyboard funcionaba, reconocía mi teclado, se conectaba, ¡recibía los códigos! No podía ser mejor, pero pasaba algo. Al igual que PS2dev, estaba muy verde y EspressIF no se había molestado en incluir entre sus rutinas todas las que se encargaban de reconectar el teclado una vez que había sido emparejado, entonces había que reiniciar y emparejar el teclado con cada encendido. Fue así como investigué sobre BLE y como el ESP32 guarda en su memoria flash las claves permanentes que nos permiten reconectar a un dispositivo previamente emparejado, hice las rutinas que escanean y detectan la presencia del teclado y nos salvan de tener que emparejarlo de nuevo. Ahora sí, ¡practicidad al fin!
Solo un pasito más. Los teclados Bluetooth transmiten códigos para cada tecla, como los que creó IBM para su PC en los 80. Decime que son los mismos. No, ¡claro que no!, no puede ser tan fácil. Los códigos que transmiten los teclados modernos, sea por Bluetooth o algo más conocido como USB, son precisamente códigos HID creados por el consorcio USB. Y no son uno para presionadas (make) y otro para liberadas (break), sino sólo uno que está presente (o no) dependiendo si la tecla está apretada (o no), que se comunica en un paquete de datos cada vez que hay algún cambio en las teclas. Así que el reto estuvo en hacer rutinas que detecten la presencia o no de la tecla en base a los códigos HID, traduzcan esto al respectivo código make o break, y finalmente lo envíen mediante PS2dev al la computadora host.
El último detalle lo tuvo una característica que quizás es la más interesante en lo que refiere a la interfaz PS/2; el llamado comportamiento Typematic o “tipomático”. Si lo traducimos literalmente, una combinación de la palabra “tipo” y “automático”. Por si no te diste cuenta, te lo explico, “tipo”es el nombre que se le da a una letra o símbolo, así que estamos haciendo referencia a: aaaaaaaaaaaaaaaa. Si, a cuando se repiten las letras automáticamente si mantenés apretada una tecla, a eso. Acordate cada vez que lo uses, “miren, ¡estoy tipomatiqueandooooooo!”. USB HID no provee un mecanismo explícito para detectar si una tecla está mantenida apretada y actuar al respecto, hoy en día es la computadora quien lleva el registro de que la última tecla no se soltó y empieza a repetirla internamente para lo que sea que estemos haciendo. En los viejos teclados PS/2 era el mismo teclado el que entraba en modo Typematic después de cierto tiempo de mantener apretada la tecla, usualmente unos 500 milisegundos, para luego enviar una y otra vez el mismo código make de la última tecla presionada, usualmente unas 20 veces por segundo. Esa fue la última cosa que le faltaba a mi proyecto.
Una vez emulado PS/2, solucionados los problemas de conexión de Bluetooh, traducidos los mensajes USB HID a los Scan Codes de IBM, y emulado el comportamiento Typematic, mi proyecto estaba terminado al fin. Un simple cable a ficha DIN-5 o Mini DIN-6 permite conectarlo al sistema, y le pedí a un amigo que me haga una cajita en 3D para protegerlo.
¿Funciona? Si, y muy bien. Pueden encontrar el código fuente en mi sitio de GitHub. De hecho todo este post lo escribí con ella, mi 486, pero no le digas que con un teclado Bluetooth, ¡porque no se dio cuenta y piensa que es PS/2! Ahora si, disfrutar del Indi 500 a simplemente dos botones, y un switch de distancia.
Con todo lo aprendido en los post anteriores vamos a realizar una pequeña animación. Para ello definiremos 2 sprites, que serán los frames del famosisimo Space Invaders:
El programa que estoy utilizando aquí es C64 Studio, un IDE de programación que entre otras cosas trae un sencillo editor de sprites que me permite exportar los DATA a lineas de BASIC, y lo pueden descargar desde aquí: https://www.georg-rottensteiner.de/en/index.html
Luego cargaremos estos valores a partir de la memoria 12288, que corresponden a los punteros 192 y 193. Para hacer una animación solamente tenemos que implementar un loop FOR, y alternamos estos valores en cada iteración.
La parte interesante que la podemos ver a continuación:
100 for sx = 24 to 255
110 poke v,sx
120 poke 2040,192 + ((sx and 8) / 8)
130 next El loop se encuentra entre las lineas 100-130, en la linea 110 se va actualizando la posición y en la linea 120 se especifica que frame mostrar segun esa posición.
El truco aquí esta en “+ ((sx and 8) / 8)”: este código toma el valor 1 o 0 segun el estado del bit 3 en la variable sx.
De esta forma las primeras 8 posiciones tomaran el valor 0, lo que hará que el puntero quede seteado en la posición 192, en las siguientes 8 posiciones quedará en 1, por lo que el puntero sera 193, en las siguientes 8 volverá a 0 … y así indefinidamente.
Si quisiéramos que la animacion se reproduzca mas rápido podemos checkear el estado de los bits de menor peso y si queremos que se reproduzca mas lento chequeamos los bits de mayor peso.
Aqui podemos ver como se ve nuestro alien animado:
y el listado completo a continuación:
10 v=53248
20 poke v+21,1
30 poke 2040,192
40 for t=12288 to 12414
50 read n
60 poke t,n
70 next
80 poke v+39,1
90 poke v+1,75
100 for sx = 24 to 255
110 poke v,sx
120 poke 2040,192 + ((sx and 8) / 8)
130 next
150 for sx = 255 to 24 step -1
160 poke v,sx
170 poke 2040,192 + ((sx and 8) / 8)
180 next
200 goto 100
1000 data 14,7,0,14,7,0,3,12
1010 data 0,3,12,0,15,255,0,15
1020 data 255,0,60,243,192,60,243,192
1030 data 255,255,240,255,255,240,207,255
1040 data 48,207,255,48,204,3,48,204
1050 data 3,48,7,158,0,7,158,0
1060 data 0,0,0,0,0,0,0,0
1070 data 0,0,0,0,0,0,0,1
1080 data 14,7,0,14,7,0,195,12
1090 data 48,195,12,48,207,255,48,207
1100 data 255,48,252,243,240,252,243,240
1110 data 255,255,240,255,255,240,63,255
1120 data 192,63,255,192,28,3,128,28
1130 data 3,128,48,0,192,48,0,192
1140 data 0,0,0,0,0,0,0,0
1150 data 0,0,0,0,0,0,0,1Y esto es todo por hoy, nos vemos en la próxima entrega!
En el post anterior vimos como activar un sprite, como seleccionar el area de memoria que dara la forma a nuestro sprite, y lo posicionamos en la pantalla.
Hoy vamos a darle la forma definitiva, para ello tenemos 2 vias:
Hoy vamos a optar por la segunda opción, mas que nada para aprender como se hacía a la antigüa usanza, despues podremos utilizar multitud de programas que nos permiten dibujar comodamente y exportar los datos al formato que deseemos
Los sprites en la C64 poseen un tamaño de 24 x 21 pixels, lo que nos da 3 bytes (24px) por 21 = 63 bytes.
Para definir un sprite “a la antigüa” dibujaremos una cuadricula de 24×21, agrupando en columnas de 8 pixels. Luego pintaremos las casillas con los puntos que componen nuestro gráfico, para finalmente convertir cada grupo de 8 pixels en un byte.
Por ejemplo, aqui tenemos un circulo solido relleno:
Cada grupo de 8 bits los convertimos primero a binario, y luego a decimal (podemos utilizar la calculadora de windows, seteandola en modo programador), de forma que el primer byte es 00000000, que en decimal es “0”, el segundo 01111110 es “126” en decimal, y asi con el resto.
A continuación tenemos el programa completo, con los 63 bytes que definen nuestra “pelota”.
10 v=53248
20 pokev+21,1: rem activamos sprite numero 1
30 poke2040,192: rem direccion de inicio 12288
40 fort=12288to12350 : rem leemos los 63 valores
45 read n
50 poke t,n
60 next
70 pokev+39,1: rem elegimos color blanco
80 pokev,100: rem posicion horizontal 100
90 pokev+1,110: rem posicion vertical 110
100 data 0, 126, 0
110 data 3,255,192
120 data 7,255,224
130 data 31,255,248
140 data 31,255,248
150 data 63,255,252
160 data 127,255,254
170 data 127,255,254
180 data 255,255,255
190 data 255,255,255
210 data 255,255,255
220 data 255,255,255
230 data 255,255,255
240 data 127,255,254
250 data 127,255,254
260 data 63,255,252
270 data 31,255,248
280 data 31,255,248
290 data 7,255,224
300 data 3,255,192
310 data 0, 126, 0Ademas de poder posicionar nuestro sprite en cualquier parte de la pantalla, tambien podemos elegirle un color, expandirlo al doble a lo ancho, o alto, o ambos.
Para darle un color utilizaremo el registro 39 (v + 39 seria) y un número entre 0 y 15 para especificar que color queremos asignarle
