Recientemente nos donaron en el museo una maravillosa CBM PET 8032.
Ya contábamos con otra PET, el modelo 4032, que son muy similares, pero la principal diferencia es el display: como sugiere el nombre, la 8032 tiene un display de 80 columnas, mientras que la 4032 solo tiene 40.
Si bien para la 4032 hay una variedad interesante de software (incluso modernos, como Attack of Petscii Robots), siendo la 8032 un modelo más “profesional” no encontré demasiado software, por lo que decidí comenzar a desarrollar algo para mostrar a los visitantes en esta máquina.
El principal problema que tengo es mi total incapacidad artística (y menos con caracteres PETSCII), por lo que se me ocurrió que podria armar un slideshow/animacion con PETSCII art, para lo cual tendria que utilizar algunos de los tantos utilitarios que convierten imagenes en petscii.
El problema que encontré fue que todos estos utilitarios generan PETSCII para la C64 y en 40 columnas (por lo que no me servían para generar pantallas para la 8032) tras lo cual decidí implementar yo mismo un conversor de imagen B&W a PETSCII.
El conversor toma una imagen en PNG, en 1 bit de profundidad de color, a una resolución de 640×200, y genera un archivo con los códigos que se pueden importar en cualquier compilador de assembler (aca voy a poner un ejemplo en kickassembler, el que utilizo yo).
Para utilizar el conversor lo mejor es utilizar algun software de edición de imágenes (ejempo: GIMP), ajustarla en tamaño a 640×400, luego la pasamos a B&W con 1 bit de profundidad de color (para eso mejor aplicar un filtro threshold, para evitar tramas). Finalmente reescalamos todo a 640×200 (la mitad de altura) sin aplicar ningun tipo de suavizado (nada de bilinear ni esas cosas, smoothing none), y lo guardamos como PNG. Esta imagen “preprocesada” es la que vamos a usar como entrada en nuestro programa.
El programa está escrito en Python 3, por lo que es requisito que esté instalado en nuestro sistema. Para utilizarlo simplemente escribimos “python convert.py <imagen_de_entrada.png> <output.raw>”, lo que nos generará un archivo de 2000 bytes, que es lo que ocupa una pantalla en la PET 8032.
Ejemplo de uso:
Supongamos que tenemos una imagen como esta:
entonces la llevamos a 640x400px.
La razón de utilizar primero una resolucion de 640×400 y luego escalar verticalmente a la mitad es porque la “resolución” de pantalla de la pet es en realidad 640×200, pero los pixeles son el doble de altos que ancho, y para trabajar la imagen en el GIMP de manera que se visualice correctamente es mejor hacer todo en 640×400, y al final escalar a 640×200.
Una vez que acomodamos en tamaño, el siguiente paso es convertir esta imagen en B&W con 1 bit de profundidad de color. Para ello lo mejor es utilizar primero el filtro Threshold (disponible en todos los programas de edición de imágenes), ajustamos el slider hasta lograr el mejor resultado, y luego convertimos esta imagen a monocromo 1 bit. Esto es necesario porque simplemente en la PET no tenemos ningun color, ni escala de grises.
Queda un último paso, que es reescalar a la mitad, para que el software pueda realizar la conversión correctamente.
Para ello vamos a las opciones de Image Resizing de nuestro software, y reescalamos a 640×200 (quitamos el bloqueo de aspect ratio), y desactivamos todo tipo de suavización (nada de bilinear, trilinear ni esas cosas).
Exportamos esta imagen como PNG, y este lo utilizaremos como archivo de entrada con el conversor.
¿Por qué no hago todos estos ajustes automaticamente? Al fin y al cabo, la libreria PIL (tratamiento de imágenes en Python) permite hacer todo esto.
La razón es muy simple: Si automatizo estos pasos no tengo control sobre tamaños, ni ajustes de threshold, ni sobre qué efectos aplicar (a veces conviene por ejemplo aplicar un posterizado a 3 colores, y sobre eso realizar la conversion con un tramado por position), por lo que decidí que el programa SOLO realice la conversion del bitmap a characters, y el procesado que lo realice el usuario de la forma y con las herramientas que le parezcan.
Y como lo importamos en nuestro .asm?
Como mencionamos anteriormente, con “python convert.py image.png petscii.raw” convertimos la imagen a petscii. Luego podemos importarla y utilizarla como nos parezca. A continuación un ejemplo ultra sencillo:
* = $0400 "Basic Upstart"
// Esto basicamente escribe en BASIC lo siguiente: SYS 1050
.byte $00, $0c, $04, $0a, $00, $9e, $20, $31, $30, $35, $30, $00, $00, $00
* = 1050
main:
// SETEAMOS EL SET DE CARACTERES MAYÚSCULAS
ldx #12
stx 59468
rts
* = 32768 "SCREEN"
.import binary "petscii.raw"
lo compilamos con kickassembler, cargamos el PRG en el vice (con el ejecutable xpet.exe), y obtenemos nuestra pantalla en PETSCII
Vamos a empezar esta serie analizando que es un módulo de reloj o system clock, por qué se usa, como funciona el de la Commodore 64 a grandes rasgos y por qué vamos a usar otro módulo de reloj durante nuestro estudio.
Les dejo el link al articulo anterior en la serie, y al final como siempre los links a todos los artículos de la misma.
Un módulo de reloj es un circuito electrónico que oscila generando una secuencia de pulsos repetitivos que llamaremos señal de reloj, estos pulsos son distribuidos a todos los elementos lógicos que tenemos en nuestra computadora para que se sincronicen.
¿Por qué se usa?
Porque generalmente nuestras computadoras trabajan con lógica sincrónica. Los gates o compuertas lógicas que usamos para operar sobre los datos tienen un tiempo finito de respuesta a los cambios en los inputs que reciben, esto se llama delay de propagación.
El intervalo entre los pulsos del reloj tiene que ser suficientemente largo como para que los gates y sus salidas se establezcan en valores estables antes de que suceda el próximo pulso de reloj.
Cómo funciona el de la Commodore 64
Bienvenidos al infierno, digo a cómo funciona aproximadamente el reloj de la Commodore 64. Y digo aproximadamente por que en este post no vamos a describir el circuito en detalle pero sí algunos vericuetos interesantes.
Empecemos con un cristal llamado Y1, este nos da una resonancia mecánica desde la cuál vamos a llegar a través de varios circuitos a los 1 Mhz a los que típicamente corre el 6510.
Ahora dependiendo de si la computadora es NTSC o PAL la frecuencia de la señal va a ser de aproximadamente 14,318 Mhz o 17,73 Mhz redondeando.
A esta señal se conoce como el Color Clock por que al dividir estos números por 4 obtenemos 3.58 Mhz para NTSC y 4.43 Mhz para PAL las cuáles son las señales de carrier responsables de que cómo vemos los colores en nuestros televisores.
Un Circuito integrado conocido como el U31 Dual Voltage Controlled Oscillator nos genera otras frecuencias en 8.18 Mhz para NTSC y 7.88 Mhz para PAL, esta señal se conoce como el Dot Clock y nos dice cuántos píxeles se puede escribir por pantalla en cada refresh de la misma.
Finalmente llegamos al System Clock que define que es un ciclo de CPU como la Commodore 64 es un máquina de 8 bits esto nos limita a mostrar hasta 8 píxeles por ciclo de CPU por lo que corresponde un ciclo de duración de un octavo de Dot Clock.
NTSC: 8.18MHz / 8 = 1.023MHz
PAL: 7.88MHz / 8 = 0.985Mhz
Llegando al máximo de velocidad de 1Mhz del 6510.
¿Por qué usamos otro reloj en nuestro estudio?
Si utilizáramos un reloj de 1 Mhz sería muy difícil ver que ocurre en la cpu por cada instrucción de nuestro programa. Los instrumentos que usamos para medir no podrían detectar fácilmente la variación de bits o impulsos eléctricos en los pines de address bus y no llegaríamos a comprender que sucede en cada paso.
Por eso tenemos un reloj que nos permite parar la pelota e ir más lento, tan lento como queramos, inclusive pulsando un botón vamos a ir ciclo por ciclo de reloj e instrucción por instrucción.
Cómo funciona nuestro clock
Vamos a utilizar el reloj del kit de Ben Eater. Este funciona con tres timer 555 y algunas compuertas and y or, en las referencias les dejo el detalle de como lo arma él en sus videos.
Este reloj nos permite a través de un switch decidir si queremos ir paso a paso cada ciclo de reloj pulsando un botón o usar un potenciómetro para dar la velocidad de las instrucciones.
Cómo Seguimos
Para ver visualmente como funciona el módulo de reloj y cómo corremos el osciloscopio para analizar sus variaciones les dejo el primer video de la serie
Hoy los quiero invitar a un viaje al interior de la Commodore 64 y sus chips donde vamos a ver en profundidad detalles de assembler, conexiones y funcionamiento, que me desvelaron desde chico, y creo que agregan mucho a nuestro conocimiento técnico.
¿Por qué la Commodore? Bueno un poco por amor (un poco bastante ja) y otro por que pienso que es una de las últimas computadoras en las cuáles podemos llegar a entender en profundidad qué es lo que está pasando realmente por dentro cuando ejecutamos un programa, jugamos un juego o tocamos música con el SID.
Todavía podemos ver los chips, medir las señales en sus patas, mirar donde hay una resistencia o un capacitor y entender por donde pasa la magia desde el programa a la acción.
Cómo conocí la Commodore 64.
Un día caminando por la calle con mi viejo a los 9 años, me recuerdo pidiéndole por enésima vez un Colecovision, el mismo que veía todas las noches en las propagandas de la trasnoche Kenya Sharp con el juego de pitufos. El se paró en el medio de la calle, me miró y me dijo:
¿Y si tuvieras una computadora mejor, que podés programar tus propios juegos?
Así llegó el 10 de Julio de 1987 mi Drean Commodore 64C, y también llegarían muchas horas de juegos de la mano de Commando, Ghost and Goblins, y terminando en un Zack Mackraken allá por los 16 años.
También llegaron muchas horas de programación en Basic y los libros de Data Becker (esos blancos y naranjas) con los que siempre me pasaba lo mismo.
Comenzaba a leer ávido y en detalle esas letras apenas entendibles y pasaba la página 1, 2 (siempre introducciones), 5, 6 (ya empezaban a explicar binario y hexadecimal) e invariablemente en la página 16, ya no entendía nada.
Que se necesitaba un monitor de código máquina, que tal cartucho, que el diskette (que no se comparaba con mi humilde datasette) y que me daban algún programa de ayuda que consistía en 20 páginas ilegibles con muchas instrucciones DATA que luego de tipearlo terminaban invariablemente en el nefasto:
"ERROR EN LOS DATA".
Luego de esta frustración me iba a Atarilin a conseguir algún juego nuevo de la mano de Carlos y Alejandro, de los que siempre venía alguna palabra de aliento,y volvía a mis 10 minutos de carga del datasette y a jugar un par de horas, la resiliencia de los 11 años.
Esa misma resiliencia me hacía al mes volver a comprar un nuevo libro de Data Becker y volver a empezar el ciclo, así pasaron “Peeks y Pokes para el Commodore 64”, “Gráficos para el Commodore 64”, “64 consejos y trucos” pero nunca llega al soñado “64 interno” considerado sólo para expertos a esa tierna edad.
El retorno del Commodoriano
El año pasado (2022) repasando el libro Make Electronics me tope con los videos de youtube de Ben Eater, un verdadero demente que hizo una computadora sólo con breadboards y utilizando el 6502 como procesador, sus videos muy bien explicados, y la posibilidad de comprar kits con todo lo necesario para armarlos y seguirlos paso a paso me llevo a tirarme de lleno a contestar las preguntas que me torturaban desde chico:
¿Cómo funcionaba la Commodore? ¿Cómo cargaba una instrucción desde el código máquina al procesador? ¿Cómo se ejecutaba?
Compré los kits y mientras los esperaba compre una Commodore 64 por mercado libre, la prendo con su fuente original (no lo hagan en sus casas niños si no quieren quemarla) y me daba un hermoso error con todos ceros en la pantalla y un OUT OF MEMORY ERROR.
Lo pensé, decidí quedármela y aprovecharlo como la oportunidad para arreglarla y aprender a fondo cómo funciona por dentro esta computadora.
6502 vs 6510
Y así nace esta serie, donde comparo cómo funciona el procesador 6502 (usado en Apple , Atari, etc) y el 6510 de nuestra querida Commodore 64 que en apariencia son iguales pero tienen sutiles y fundamentales diferencias.
Con esta serie de blogspot y videos que armé para acompañarlos y vamos a explorar desde el pin out hasta los registros internos del 6510, pasando por sus puertos de I/O, como cargarle una instrucción en código máquina a mano y llegando hasta conectarle una eeprom con varias instrucciones para que ejecute un programa de nuestra autoría.
Espero me acompañen en este viaje para contestar estas preguntas que me hacía desde pequeño y conocer a fondo estos procesadores.
Siganme en este apasionante viaje empezando por el próximo artículo,
Si de chico tenias una micro computadora, seguramente utilizaste pantallas basadas en tubos de rayos catódicos para ver su imagen. Estas maravillas analógicas tuvieron su inicio con la televisión blanco y negro en la década el 30, su apogeo a todo color entre los 70 y 90 y ocaso en el siglo 21 de la mano de la llegada de los LCDs y OLEDs.
Para quienes añoran usar sus retrocomputadoras hoy día se veran limitados en opciones para contectarla a monitores ya sea porque los de epoca van fallando por paso del tiempo o porque no hay opciones modernas que usen interfaces obsoletas. Aca mostrare una propuesta de codigo abierto simple y economica que pretende ir cubriendo diferentes retrocomputadoras con mas colores y resolución a medida que el proyecto recibe colaboracion y hay dispositivos mas potentes para mejores prestaciones asi como el porque de querer hacerlo.
Uniendo la retrocomputacion con la electronica digital
Cada persona tuvo su camino particular con las microcomputadoras, en mi caso la Commodore 64 abrio un mundo de posibilidades no solo en la programacion sino en la electronica digital, dado que fue de las primeras computadoras en ofrecer una arquitectura abierta y extensible a traves de sus diversos puertos y su amplia documentacion. Esto me llevo a recorrer el camino de la electronica digital como tecnico, ingeniero y finalmente especialista en electronica y sistemas embebidos. En este camino dejo entreveer que mas alla de que los sistemas actuales tienen bases en los sistemas de computo antiguos, muchas cosas siguen manteniendose relevantes en sistemas embebidos (o dedicados de un solo proposito). Todavia se usan microcontroladores de 8 y 16 bits, todavia se usan perifericos clasicos como en los 80 y todavia es valioso programar sabiendo que hardware tenes bajo el capot.
La retro computacion como filosofia mas que hobbie
Por definicion la retrocomputacion es una serie de actividades que involucran computadoras antiguas.
Preservar: Arreglando hardware de los equipos con componentes defectuosos
Extender: Ampliando las capacidades originales del sistema a traves de sus perifericos o puertos
Desarrollar: Generando nuevas aplicaciones y juegos
Difundir: Dando a conocer a traves de convenciones, redes sociales y foros sus hitos e historias
Enseñar: Como estos sistemas fueron base de sistemas actuales, todavia presentes en la arquitectura de computadores.
Para los seguidores de la retrocomputacion ademas de todo esto, al ser sido parte de esa historia, hay nostalgia y buenos recuerdos asociados. Que mejor manera que rendir tributo a estos recuerdos que colaborando de alguna manera y dado que en estos años mi colaboracion fue mas desde la recuperacion de equipos y desarrollo de algunas interfaces que la comunidad open source comparte y queria ir un poco mas alla con algun desafio.
El primero que aparecio fue claro: “no estan quedando monitores que soporten RGB o las opciones que hay son muy costosas”, mirando el mercado actual las opciones no son prometedoras:
Open Source Scan Converter: Este dispositivo provee las mejores prestaciones para captura y representacion de la imagen, con el inconveniente de su alto costo por estar desarrollado con FPGA ( Matriz de puertas programables)
Conversores SCART genericos: Estos dispositivos son relativamente economicos pero no hay mucha disponibilidad y el problema fundamental es que introducen altisima latencia y destruyen la imagen original al procesar los cuadros para presentarlos en pantalla
pi Zero RGB2HDMI HAT: Este dispositivo tiene una gran calidad de imagen con una moderada densidad de color, debido a que cuenta con una computadora raspberry pi zero y una serie de placas que se colocan en su puerto de entrada salida. Termina siendo caro asi como complejo
AMIGA digital Video: Este dispositivo es especifico de Amiga, se instala dentro de la maquina y lee las señales digitales de la salida antes del converso de digital a analogico. Su calidad es excelente pero es sumamente invasivo y especifico a un equipo, asi como costoso porque utiliza una computadora y su salida HDMI solo para lograr la representacion de la imagen.
Basandome en mis conocimientos de procesamiento digital y de embebidos sabia que habia tiempos de captura de señales a muy alta velocidad asi como requerimientos de tiempo critico para que la señal no sufriera los conocidos “desgarros”, lo cual lo hacia un desafio digno. Sumado a esto, pense en utilizar no tanta potencia y costo en una FPGA sino un microcontrolador de propositos generales, obviamente al compartir mis intenciones recibi muchas negativas de que no iba a ser posible, pero no hay nadie mas obstinado que un ingeniero que le digan que no se puede…
Intro al RGB
Para resolver el desafio primero hay que entender como funcionaban los monitores analogicos, en especial los RGB, el cual fue el estadio intermedio entre los monitores de TV clasicos (PAL / NTSC / SECAM) y el VGA. Estos utilizaban 3 lineas analogicas para el rojoverde y azul (de ahi su acronimo) y contaban con una linea de sincronismo compuesto o dos lineas para vertical y horizontal en formato digital. La informacion era enviada como variaciones de intencidad de luz a traves del tiempo, con un barrido de izquierda a derecha y de arriba a abajo, la cual se podria recuperar y encuadrar al usar las señales de sincronismo.
Las imagenes muestran la relacion entre el barrido y las areas de informacion de video y señales de enganche y las señales de video y sincronimo. Cada inicio de linea era marcado por un flanco de bajada y subida abrupto de la linea de horizontal y cada cuadro completo por el el flanco de bajada y subida abrupto de la linea de vertical. La cantidad de disparos verticales en un segundo da los cuadros por segundos representados. Los espacios entre el flanco de disparo y el inicio de video marca el porche trasero y el espacio sin señal de video hasta el nuevo dispare el porche frontal, en similar medida para con el vertical, ambas marcan espacios sin informacion de video, para permitir “retornos” de linea de video, dado que en los tubos de rayos catodicos habia un tiempo inherente de retorno de linea.
Por ende, para resumir, si quisieramos capturar el video necesitamos engancharnos a la señal de sincronismo horizontal y comenzar a adquirir pixel a pixel, pero deberiamos conocer que ancho tiene cada pixel.
Aproximaciones teoricas
De este punto en adelante se plantearan teoricamente partes necesarias de la solucion.
Flujo de temporizado de captura
Hay ciertos calculos que son faciles de sacar, como cual es la resolucion vertical, que es la cantidad lineas horizontales o disparos de horizontal que se dan antes de que se produzca un disparo vertical (en modo progresivo). Otros que son parametros de entrada, como los pixeles por linea, que solo dependen de la capacidad del receptor para capturar cada pixel. En un monitor analogico lo da el ancho de banda de video y la definicion del pixel en el TRC. En el caso del capturador, por la cantidad de memoria que dispongamos por linea y la capacidad de captura del conversor analogico a digital. Esto se conoce como frecuencia del pixel que es resolucion total horizontal x vertical x cuadros/seg. En 640×480 y 60 cuadros son aprox 800x525x60=25.175Mhz Otro punto no menor es que el CAD debe ser capaz de adquirir los 3 colores al mismo tiempo, sino estariamos capturando el rojo de un pixel y potencialmente el azul del siguiente. Este modulo tambien tiene la responsabilidad critica de responder rapido y sin variaciones al disparo de horizontal, si esto no se cumple sera visible en la pantalla las variaciones.
Transporte y conversion
Esta etapa tiene varias responsabilidades, una es la de tomar lo que sale del adquisidor y transportarlo al microcontrolador por el puerto que este tenga, otra es la de convertirlo en tiempo real al formato de colores que se haya dispuesto de memoria para presentar en pantalla pero la mas importante es la de unir estos puntos con un mecanismo automatico de desligue al procesador de la tarea, en este caso el uso de DMA (Acceso Directo a Memoria). En nuestro caso se usara un ADC de 16 bits por color y un bus de 8 bits asi que los 24 bits finales de color, como las pantallas HDMI manejan 24 bits, es logico descartar el byte mas bajo de cada color.
En el grafico de la izquierda se ven algunas compresion de color mas usadas con la cantidad de bits por color. Para comprimir en tiempo real hay que tomar la entrada, color por color y descartar la cantidad correcta de bits de cada uno hasta completar los 3 colores. Esto se puede ver en el siguiente grafico, donde se usa un registro de desplazamiento para ir procesando cada color, tirando los bits menos significativos y pasando lo al buffer.
Almacenamiento
Esta etapa repite la vision de los puntos anteriores pero hace un paso atras para tener una vision mas amplia, que es que parte de la informacion que capturo va a la memoria que se dispone. El video tiene ni bien se dispara un back porch sin informacion util, pero seguido de informacion util, el desafio es esperar siempre la misma cantidad de tiempo. Para eso se utiliza el mismo mecanismo de captura, pero en vez de poner de destino un area de memoria de video, se envia a una unica posicion dummy. Esto se logra usando encadenamiento de DMA, para que sea de manera automatica. Una vez hecho esto la memoria se llenara de una linea a la vez, usando como infomacion de linea un conteo de cuantos disparon HSYNC se tienen, hasta el proximo disparo VSYNC que resetea la cuenta.
Renderizado HDMI
Una vez que se haya logrado guardar un cuadro completo de la imagen capturada, se puede utilizar para la entrada de una placa de video, pero que tal si lo hacemos SIN una placa de video? Esto es posible gracias a un proyecto opensource llamado picoDVI, que permite utilizar un microcontrolador de propositos generales Raspberry pico RP2040 (no confundir con la raspberry pi), el cual utiliza 8 pines del microcontrolador para generar al vuelo las señales de DVI, precursor del HDMI. En la pagina de Wren6991 esta bien explicado, pero en resumen, se encodean los pixeles para generar tramas TMDS, usando 8 bits por color y 2 bits de correcccion. Esta informacion se manda para el rojo, verde, azul y reloj de manera diferencial para suprimir el ruido, de ahi las 8 lineas usadas. DVI limita la cantidad de monitores, aunque la gran mayoria lo soporan, igualmente en mi fork de picoDVI realize el soporte de HDMI, con la inclusion de audio, el unico detalle es que DVI se puede usar sin pagar y HDMI requiere pagar licenciamiento y verificacion de complimiento de estandar. Si lo usas a nivel personal, nadie te va perseguir por usarlo en tu casa, si vendes miles de unidades seguro te tocan el timbre.
Cuando no hay perifericos, martillazos
Los microcontroladores de propositos generales (SoC) pueden tener conversores analogicos a digitales, puertos series como el USART, I2C o SPI, pines que responden a interrupciones o algunos mas especificos, pero la pregunta es como mostrar video sin un periferico de video? Para esto primero cuento como se hace normalmente cuando se quiere “programar” un periferico, bueno se usa bit banging, que es esto? Bit Banging es tanto leer como escribir los pines de I/O del micro para generar a fuerza de codigo un comportamiento, cual es el truco? Bueno que se requiere muchos mas ciclos de reloj de lo que necesitaria el periferico, esto es porque el programa debe leer estados para poder decidir y esto requiere al menos 2 muestras para no errarle. Este numero suele se mucho mayor, alrededor de 10 veces, porque las instrucciones de un micro no son de un ciclo de reloj.
Esto hace que el micro se vea ocupado haciendo tareas que son realmente triviales para un periferico dedicado, lo cual es un mal uso del micro.
Procesando los numeros
Si vemos los casos de arriba, tanto para la captura como para la renderizacion requeririamos un micro de 1200Mhz para captura y de 2500 Mhz para renderizacion HDMI, los numeros no cierran. Y todavia resta espacio de micro para que se puedan hacer otras cosas, asi que hay que buscar otra manera.
Salvando el dia con el PIO (del rpi Pico)
El RPI Pico 2040 es el primero de una familia de microcontroladores de la Raspberry Pi Foundation, entre sus caracteristicas:
Procesador Cortex M0 de doble nucleo
2 Mbytes de Flash de programa
264Kbytes de RAM
USB 1.1
26 pines de IO
Timers, SPI, USARTs, CAD y…. 2 PIO (programable IO) de 4 maquinas de estado cada uno, pero que es esto?
La PIO no es mas que un periperico programable de entrada salida que permite desarrollar perifericos no existentes en el micro. Esta directamente conectado a los puertos de entrada salida, puede conectarse al DMA y lo mas interesante es que tiene su propio set reducido de instrucciones que corren separado del procesador principal.
El pocas palabras es como tener 8 pequeños microcontroladores que pueden correr codigo a ciclo perfecto (cada instruccion es un ciclo de reloj). Con esto se pueden dedicar un pequeño procesador (llamado maquina de estado) a capturar la entrada, comprimirla y mandarla a memoria y otros a transportar las tramas TMDS a la pantalla HDMI, sin uso de la CPU.
Armado
Con lo expuesto antes, se arman todos los modulos y etapas aprovechando los PIOs del RP2040, los DMAs para transferencias sin uso de CPU e interrupciones por flanco de HSYNC y VSYNC y se dispone memoria (que no es mucha) para modos de 320×240 y 16 bits o 640×240 y 8 bits, asi como el uso de pines para teclado y el USB para gestion remota.
La frecuencia de trabajo del micro esta en 250Mhz, para lograr la velocidad necesaria en el HDMI, esto significa que el limite de los 133Mhz se ha superado, pero porque anda? El limite de los 133Mhz lo dicta la memoria flash QSPI, que encima tiene mas penalidades en tiempo porque el codigo que se cachea no necesariamente es el que se va a ejecutar (logica de prediccion de salto). Pero, si corremos desde RAM, no tenemos esa limitacion, y para eso toda rutina critica, se marca para correr a maxima velocidad. El micro principal no se ve afectado.
Pila de Software
El software esta desarrollado de manera modular, desde las rutinas de bajo nivel para captura y renderizacion como las de menues en pantalla y sobre imposicion en pantalla. Salvo el SDK de Rpi Foundation (que fue modificado) y la libreria de DVI (que tambien fue modificada) todas las otras librerias fueron realizadas de cero.
Videos del conversor
Aca comparto una serie de videos de youtube, no tienen una gran edicion, son caseros pero muestran la idea.
Primer video del pico RGB2HDMI
Aplicacion USB para captura de imagenes
Sistema de menues
Charla en Commodore eu
Menues integrados
Firmware unificado para ambas resoluciones y guardado de configuraciones
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.
Yo y ella, allá por los 90
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!
Mi setup moderno, Yoga 720 a la izquierda, ella abajo a la derecha, teclado Bluetooth al centro
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!
Mi 486 luciendo el prototipo del adaptador
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.
Primera unidad para betatesters, en este caso con conector Mini-DIN
¿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.
En esta oportunidad les acercamos una entrevista particular: su protagonista es Roberto Trillo, gran coleccionista de calculadoras mecánicas y colaborador de Espacio TEC. ¿Cómo inició su camino en el coleccionismo? ¿cuántas calculadoras posee en su colección? Estas y otras preguntas tendrán su respuesta en esta cordial charla -asado mediante- en su casa de Escobar.
-Entrevista a Roberto Trillo-
Roberto junto a algunas de sus mejores calculadoras mecánicas.
Un día llega a nuestras manos un objeto que logra cautivarnos: puede ser un mueble antiguo de madera, una moneda rara, una tela cubierta con variados pigmentos, una estampilla de un país muy lejano, o cualquier cosa que usted pueda o se permita imaginar… Muchas veces no existe una explicación para la fascinación que despierta en nosotros esa “cosa”, ese simple “ente material”. ¿Por qué no podemos evitar reposar la mirada sobre un simple reloj cucú cuando resta un minuto para el cambio de hora? ¿Qué tiene de interesante esa vieja moneda con la cual ya no podemos comprar nada? ¿Y esta pintura colorida que ilustra un puente icónico del sur porteño? ¿Acaso comprendemos realmente qué ocurrió la tarde en que decidimos guardar una estampilla, reprimiendo para siempre su destino de darle alas a una carta?
Algún tiempo atrás recibí un mensaje que me cambió la agenda: Roberto Trillo me escribió para invitarnos a mi pareja y a mí a comer un asadito en su casa… ¡cómo negarnos! Aclaro, para quienes aún no conocen a Roberto, que nuestro entusiasmo no provino de la posibilidad de disfrutar una deliciosa carne a la parrilla: su casa es, sin exagerar, un catálogo inagotable de maravillas mecánicas, un monumento a la memoria viva del cálculo hecho “a manija”. Roberto es, para ponerlo en palabras modestas, el mayor coleccionista de calculadoras mecánicas de Argentina, poseedor de una de las colecciones más importantes (si no la más importante) de toda Sudamérica. Pero sobre todas las cosas, Roberto es una persona apasionada por la docencia y la historia, alguien que con mucha generosidad comparte su pasión por esos objetos que, más allá de permitir las cuatro operaciones fundamentales de la aritmética, maravillan por la creatividad de sus diseños, la maestría de su fabricación y lo intrincado de sus mecanismos. Basta una simple búsqueda en internet para descubrir que este mago de las “cuentas con engranajes” recorrió escuelas, museos y canales de televisión llevando con él valiosas piezas de su colección y elementos didácticos para el disfrute de grandes y chicos.
Después de un muy agradable almuerzo, en el cual las ricas berenjenas al escabeche de su compañera Liliana y un buen malbec hicieron su aporte, le pedí a Roberto la posibilidad de realizarle una pequeña entrevista en su taller; para mi fortuna la propuesta fue aceptada, y es así como ustedes tendrán la posibilidad de adentrarse, a través de las palabras del propio Roberto, en el apasionante mundo del coleccionismo de calculadoras mecánicas.
Julián:
Saludos Roberto, nos encontramos en un día feriado… lunes 15 de agosto de 2022… dejo la grabadora sobre tu mesa, junto a unos engranajes de madera… ¿qué estás fabricando?
Roberto:
Estoy construyendo una maquinita “Pascalina” para llevar al museo de Especio TEC, así pueden usarla los chicos y ver cómo funcionaba la primera calculadora del mundo, diseñada por Blaise Pascal en 1643.
J: Es increíble cómo ha avanzado la tecnología, al punto en que hoy es posible realizar cálculos muy complejos con cualquier teléfono celular… pero seguro existieron varios pasos en el camino que inició con la Pascalina… ¿ese camino es tu objeto de estudio Roberto?
R: Es cierto, es largo ese camino. En mi colección pongo el foco exclusivamente en las calculadoras mecánicas; no tengo nada que se enchufe, eléctrico ni electrónico… bueno, en realidad hay una excepción: guardo en aquella vitrina una pequeña calculadora electrónica a pilas, que en los ‘90 se conocieron como “calculadoras tarjeta”… cuando la veo pienso en el creador de la antigua calculadora Monroe, que debe pesar unos 30kg…. estamos hablando de máquinas hechas hace solo 120 o 130 años, es decir, no tenemos que remontarnos al nacimiento de Cristo… ¿qué diría él al ver esta miniatura electrónica? ¿qué pensaría si le cuento que su nieto ya podrá utilizar una de estas maravillas, que no tiene nada mecánico en su interior y que es del tamaño de la “etiqueta” de su calculadora tan voluminosa y pesada? Seguramente, ese hombre me hubiera tomado por alguna clase de Julio Verne, es decir, pensaría que mi calculadora tarjeta no es ciencia, sino “ciencia ficción”… algunas veces pienso, ¿qué ocurriría si viniera alguien a contarnos cuáles serán las maravillas que verá mi nieto cuando tenga mi edad?
J: Arthur C. Clarke dijo una vez que cualquier tecnología lo suficientemente avanzada es indistinguible de la magia…
R: ¡Exacto! ¿Cómo le podés decir a un hombre que estaba diseñando una calculadora llena de engranajes que dentro de 80 años iba a existir una máquina tan chiquita, y sin partes móviles..? ¡Magia! Sin embargo existe.
J: Roberto, ¿tenés una estimación, una noción de cuántas calculadoras tenés en tu colección?
R: Normalmente digo que puedo llegar a tener unas 200 máquinas… pero quizá eso no sea del todo verdad… algunas de las máquinas fueron utilizadas como donantes de piezas para otras del mismo modelo… una suerte de donantes de órganos mecánicos. Podría decirse, con todo rigor, que el corazón de mi colección está formado por unas 70 máquinas, de las cuales unas 40 me acompañan acá en mi casa… estas están en perfecto estado, todas funcionando. Esa funcionalidad me incentiva a mostrar mi colección, a recorrer escuelas secundarias y otros lugares, enseñando que existieron otras herramientas para hacer cuentas antes del celular.
J: Sin dudas es una excelente puerta de entrada a la historia de la ingeniería… imagino que con tantas máquinas disponibles debe haber existido mucha competencia, guerras de patentes y esas cosas… ¿es así?
R: Sí, en aquellos días la competencia era feroz, y eso llevó a la creación de mecanismos muy innovadores… a mí me cuesta decir que estas máquinas son obsoletas: la Comptometer, por ejemplo, que fue creada en Estados Unidos alrededor de 1880 y fabricada hasta 1960 con el mismo principio básico de funcionamiento, permite hacer cuentas con mucha mayor velocidad en comparación a un teléfono celular si uno aprende a utilizarla correctamente, al menos para las operaciones de suma y resta… esto se debe a que los dígitos de los sumandos pueden ingresarse “en paralelo”, mientras que en nuestros teléfonos tenemos que introducirlos de manera secuencial.
J: ¿Se podría decir que las Comptometer son tus calculadoras favoritas?
R: Me gustan mucho las Comptometer, porque brindan la posibilidad de hacer cuentas con mucha velocidad… pero debo decir que también hay otras máquinas que me maravillan: las Adix, por ejemplo, son maquinitas muy livianas que pueden llevarse en el bolsillo, y que tienen el encanto de tener “a la vista” todos sus engranajes, de forma que uno puede ver y tratar de entender su principio de funcionamiento… eso me fascina. Tampoco puedo dejar de lado máquinas especiales como la calculadora “Curta”, también llamada la “maravilla mecánica”… es muy placentero realizar sumas con este instrumento que tiene más de 400 piezas y cabe en la palma de la mano, sintiendo el movimiento de sus engranajes puestos a nuestro servicio… le tengo estima a pesar de no ser una máquina especialmente antigua en mi colección, ya que se empezaron a fabricar en 1948. Para ser sincero, me gustan todas las calculadoras mecánicas.
J: ¿Qué me podés contar sobre la Pascalina que estás fabricando? ¿Tenés alguna en tu colección?
R: Pascal la desarrolló en 1642, y fabricó unas cincuenta unidades, de las cuales todavía sobreviven nueve: ocho como parte de colecciones en museos y una en manos privadas. Lo curioso es que luego de la Pascalina, y por un lapso de 200 años, no se fabricaron nuevas calculadoras. La primera que llegó a comercializarse ya en el siglo XIX fue el aritmómetro de Charles-Xavier Thomas, alrededor de 1850… a partir de allí comenzó la “época de oro” de las calculadoras mecánicas.
J: Así como Suiza se caracteriza por la construcción de buenos relojes, ¿sería correcto decir que también fue el país que más se destacó a la hora de fabricar calculadoras mecánicas?
R: Suiza, al igual que Alemania, se caracterizó siempre por la calidad de sus mecanismos (calidad sobre cantidad)… podemos decir que fabricaron las máquinas de mayor calidad entre 1850 y 1930. Luego, cuando EE. UU. ingresó en el mercado fabricando la Monroe, el juego cambió: ahí se empezaron a fabricar máquinas en gran cantidad.
J: Pensando en quienes no están muy familiarizados con estas máquinas, es posible que el término “calculadora mecánica” pueda ser asociado con esas viejas y populares sumadoras “Olivetti”, que imprimían en una tira de papel sus resultados…
R: Sí, esas máquinas imprimían en papel, pero debemos decir que las máquinas pioneras en ese campo fueron las Burroughs. Entre 1880 y 1920 existió una competencia fuerte entre Burroughs y Comptometer… las Burroughs llegaron a ser tan grandes y pesadas que traían su propia mesa.
J: Roberto, si me lo permitís, me gustaría dejar de lado por un momento el aspecto histórico y técnico para realizarte un par de preguntas más cercanas al coleccionismo: ¿cómo llegás vos a las calculadoras mecánicas? Es decir, ¿cuál fue el punto de inicio de esta tremenda colección?
R: Bueno, antes que nada dejame decirte que esta “tremenda” colección se formó sola… cuando alguien pone pasión y garra, las cosas terminan llegando… sea lo que sea que uno coleccione. Quizá esto te cause gracia, pero yo creo que uno no elige su colección, sino que son los objetos los que, de alguna forma, lo eligen a uno: a lo largo de la vida pasan por nuestras manos muchos artefactos raros… si hay uno que te llama hay que prestar atención… ¿qué tiene esto? ¿por qué me cautiva? A mí me gusta mucho la mecánica… un día me llamó la atención una máquina que estaba en venta en Mercadolibre, muy barata… salió algo así como lo que cuesta un café con dos medialunas. Como estaba toda vieja y trabaja dije “la voy a desarmar para ver qué tiene adentro, total… ¿qué puedo perder?”
J: ¿Recordás cuándo fue esta primera compra?
R: Debe haber sido hace aproximadamente 15 años… yo tengo 68 años, así que puede decirse que empecé hace relativamente poco…. fue una locura que me agarró… y no paré. Volviendo a aquella primera calculadora, recuerdo que el día que la desarmé no dormí… a eso de las tres de la mañana descubrí de qué forma la máquina realizaba la multiplicación… te imaginarás lo que me dijo Liliana cuando se lo comenté con tanto entusiasmo a esa hora… bueno, el asunto es que me encantó el mecanismo, y así fue como se me ocurrió escribirle al jefe del servicio técnico de Monroe (que todavía existe, solo que ahora fabrican máquinas electrónicas), y él me contestó muy amablemente contándome que mi máquina era el “Modelo B” de 1911… con su mejor intento de castellano me dijo “manual de usuario no disponible en línea”. A esto yo le respondo, a modo de broma… “¡Qué poca seriedad de la firma! ¡Hace solo 100 años que dejaron de fabricarla y ya no tienen el manual! Ni soñar con pedirles el repuesto entonces… una fábrica así no va a subsistir por mucho tiempo”. Bueno, parece que los yanquis no entienden mucho este tipo de humorada… un tiempo después compré otra Monroe, el “Modelo K” (el “caballito de batalla” de la fábrica), y le escribí nuevamente a este señor: le expliqué que lo anterior había sido una broma, y le expresé la emoción que me producía el ver a mi nieto junto a estas máquinas… parece que le toqué alguna fibra sensible, porque me contestó enviándome muchísimas fotos de la fábrica en 1911, entre las que aparecía el fundador de la empresa, ya anciano, junto a un escritorio… frente a él estaba la primera máquina que yo había comprado. También me explicó que la máquina Modelo K fue muy popular (se habían hecho más de 200.000 unidades), pero me expresó haber quedado perplejo ante la primera (Modelo B): “¿Cómo es posible que esa máquina haya terminado en Sudamérica, siendo una de las primeras 1000 que se fabricaron? Es una máquina hecha a mano… qué lástima que Ud. no sea coleccionista, de lo contrario tendría en sus manos una verdadera pieza de museo”… y eso fue todo: a partir de ahí no pude parar más; ese fue el comienzo de mi camino en el mundo del coleccionismo.
J: ¡Qué interesante inicio! ¿y cómo seguiste?
R: A partir de ahí me interesaron mucho los mecanismos, comencé a investigar y aprendí sobre las distintas marcas que existieron… por otra parte, el hecho de tener una casa de antigüedades me ayudó a la hora de encontrar máquinas raras… muchos colegas, cuando encuentran alguna máquina en un galpón me llaman y me preguntan: “¿te sirve para tu colección?¿la tenés?”… últimamente respondo con mayor frecuencia con un “gracias, ya la tengo”, pero siempre aparece algo nuevo.
J: Estando acá en tu taller, Roberto, veo que también tenés unos cuantos relojes “cucú” y relojes “aniversario” en reparación… ¿también sos aficionado a la relojería?
R: Exacto, todo lo que sea mecánico es bienvenido, porque lo entiendo y puedo repararlo. Muchas veces veo a Liliana tocando el piano y me maravillo, el arte es un don, al igual que la mecánica… ese es mi don: entiendo a las máquinas, me gustan; por eso es que las colecciono, y por eso es que me gusta transmitir mis conocimientos a los chicos… un niño o una niña de 10 o 12 años no se imagina cómo se hacía para marcar un número en un teléfono “a disco”: algo que hasta hace no tanto nos parecía de lo más mundano y normal hoy ya no se conoce… menos aún imaginan que una calculadora puede funcionar con engranajes.
J: ¿Imaginás a estas calculadoras todavía en funcionamiento en los próximos 50, 100 o 200 años?
R: A veces vas a una casa de remates y ves relojes muy extraños en una pared… te da la sensación de que “murió el abuelo”, y cargaron todo así nomás para ponerlo en venta… en realidad no sé qué pasará con estas máquinas, yo las estoy disfrutando en este momento. Pero en relación a lo técnico, creo que la calidad y robustez de estos componentes pueden permitir su subsistencia por muchas décadas más… es como la vieja heladera Siam de la abuela, imposible de comparar con las heladeras de ahora. Hoy las cosas están hechas para durar un poquito más de lo que cubre la garantía… las calculadoras mecánicas, por otra parte, estaban hechas con la idea de que debían durar “para siempre”… el concepto era otro, y el mundo también.
J: ¿Imaginás a alguno de tus nietos continuando esta colección algún día?
R: No sé qué va a pasar… quizá alguno de ellos… sé que mis hijas probablemente no… me gustaría que eso pase. Sin embargo, y por sobre todas las cosas, lo que más disfruto es poder compartir mis máquinas en las escuelas, al menos unas 10 de ellas que son las que caben en un baúl del auto… así las ideas y el conocimiento pasan a la próxima generación. Estos bienes intangibles son mucho más importantes que las máquinas en sí mismas.
Sentarse en una dura silla de madera frente a un escritorio blanco con biseles negros y pulsar el botón de un CRT monocromático hasta oír el “clic”; Después, un pequeño ruido a estática, y ya estaba corriendo nuestra 386 (bueno, más que nuestra, de la familia), lista para retomar la aventura de un pirata con un carisma sin igual (¡perdón Jack Sparrow!) ¡Eso era felicidad!
por Demere*
Sentarse en una dura silla de madera frente a un escritorio blanco con biseles negros y pulsar el botón de un CRT monocromático hasta oír el “clic”; Después, un pequeño ruido a estática, y ya estaba corriendo nuestra 386 (bueno, más que nuestra, de la familia), lista para retomar la aventura de un pirata con un carisma sin igual (¡perdón Jack Sparrow!) ¡Eso era felicidad!
Siempre amé jugar todo software que pasara por mis manos, ya sea en la NES, en la MSX o en la “PC”. Sin embargo, algunas veces me preguntaba: ¿por qué me atrae tanto jugar en un monitor de PC, pudiendo disfrutar de los coloridos juegos que, en contrapartida, ofrecían la NES o la MSX? Con los años llegué a la respuesta.
Quería vivir historias
Tal como ocurre con una película o un libro, la PC me ofrecía cosas que no eran tan comunes en mis juegos de consola: historias, personajes, lugares… todo presentado con la magia que solo las aventuras gráficas podían brindar. En este tipo de juegos los personajes se desarrollaban al punto de hacerlos entrañables, presentándonos sin preámbulos sus miedos, gustos, reacciones e ideales… se presentaban al jugador como seres pensantes, y eso me atraía.
Dentro de lo encasillado que nos puede parecer hoy un juego de point & click, lo cierto es que sentíamos la agradable sensación de ser actores activos en los retorcidos mundos y situaciones producidos por la imaginación de uno o varios tipos que, sentados en un escritorio a miles de kilómetros, habían logrado plasmar en un diskette de 51/4, en tiempos en los cuales internet era solo un rumor.
El inicio de todo
Para hablar del origen de este género tenemos que remontarnos a las aventuras conversacionales, un entretenimiento de interacción a través de texto en el cual se esperaba que eligiésemos nuestro destino “tipeando” las distintas decisiones, algo análogo a lo que ocurre en los libros de “Elige tu propia aventura”. El primer juego de este tipo fue “Colossal cave”, escrito por Will Crowther, cuya primera edición fue llamada “Adventure”. Lentamente el programa empezó a correr en varias computadoras de la época, hasta que un tal Don Woods encontró una copia en un servidor y se le prendió la lamparita: con el permiso de Will expandió el universo del juego llenándolo de personajes y guiños a los libros de Tolkien (aunque Woods negó dicha inspiración y atribuyó los parecidos a la casualidad).
Con el paso del tiempo sucedió lo inevitable: llegó “Mistery house”, el primer juego conversacional con gráficos, el cual se encuentra en la frontera que divide a las aventuras conversacionales de las aventuras gráficas. Aun hoy se debate a qué genero pertenece este juego, y cuál es el punto exacto en el cual se produjo esta evolución… si bien no soy yo quien puede definir de qué lado de la línea está “Mystery house”, sí puedo afirmar que fue Ken Williams, fundador de On-line Systems (posteriormente Sierra On-line) y creador de juegos como Mission Asteroid (1980), quien puso los pilares fundamentales de lo que hoy se conoce como aventura gráfica.
La aventura recién comienza: ¿Lucas Films o Sierra Online?
Así fue como ingresé en el maravilloso mundo de las aventuras gráficas, género cuya dinámica supongo familiar para cualquiera que lea este artículo; para quien no le resulte así, reproduzco aproximadamente la definición actual de Wikipedia: “La dinámica de este tipo de experiencia consiste en la resolución de diversos rompecabezas, planteados como situaciones que se suceden en el marco de una historia, interactuando con personajes y objetos a través de un menú de acciones o interfaz similar, usualmente utilizando un cursor para mover al personaje y obligarlo a realizar distintas acciones.”
Pues bien, permítanme decir que le falta algo a la definición, y esto es el “espíritu”: Cada desarrolladora dotó a sus juegos de un espíritu y de un carisma único. Así abrimos un abanico de desarrolladores, que podemos dividirlo de forma simplificada en 3 vertientes: Lucas Films Games, Sierra online, y “el resto”; en esta última podemos encontrar propuestas de lo más disímiles, desde “Simon the sorcerer” hasta “Beneath a steel sky” o “Myst”, los cuales pertenecen a distintos equipos de desarrolladores y cuentan cada uno con su particular percepción y enfoque.
Volviendo a las primeras dos empresas mencionadas, tenemos los estandartes más importantes del género, por lejos. Sierra, por un lado, apuntaba a un público mas bien adulto, con aventuras más “maduras” como “Gabriel knigth” o “Police quest”, pasando por un picante “Leisure Suit Larry”. La particularidad de Sierra es que podíamos saltar algunos puzzles, aunque como consecuencia podía ocurrir que faltara luego algún ítem necesario para avanzar en el juego, además de la posibilidad de fallar o morir en el objetivo final… en general, el nivel de dificultad solía ser elevado. En contraposición, Lucas Film apostó por un enfoque más “familiar”, con puzzles más fáciles y guiados en los cuales era imposible bloquear nuestro avance; eso sí, la historia era contada con un poco más de comicidad, e incluso se buscaba la complicidad con el jugador, dando un aspecto más empático a sus personajes… el humor y la aventura no podían faltar en Lucas Film: basta nombrar juegos clásicos como “Monkey Island”, “Maniac Mansion”, “Full Throttle”, “Sam & Max” y “Grim Fandango”, entre muchos otros.
Auge y caída
Si tuviéramos que delimitar la etapa gloriosa de las aventuras gráficas, podríamos marcar el inicio en 1987 con el lanzamiento de “Maniac Mansion”, juego que fue portado a varias plataformas. La industria nos trajo luego joyas indiscutidas como la saga “The Secret of Monkey Island” (en especial la primera y segunda entrega), una de las más apreciadas por los jugadores; allí nos acompañó nada más y nada menos que Guybrush Threepwood, un entrañable antihéroe que se convirtió en un icono del genero, puesto con el tiempo en un pedestal junto a los mismísimos Mario y Sonic. Guybrush era un tipo común en un mundo de aventuras: no tenia poderes y era víctima de la mala fortuna, pero compensaba todo con mucho humor y simpatía, sumados a su buena voluntad y capacidad de decisión.
Con el tiempo, y a partir de la llegada del los polígonos al mundo de los videojuegos, estos queridos personajes fueron perdiendo espacio. A pesar de la aparición de algunos buenos títulos en 3D como “Grim Fandango”, el mundo perdió interés por el género, quizá a partir de un cambio generacional con jugadores que se fueron sumando en búsqueda de nuevas experiencias, o tal vez a causa de la falta de innovación o al estancamiento de Lucas Film; la realidad es que por unos cuantos años no hubo lugar para las aventuras gráficas en la industria, situación que inevitablemente redujo el género a una cuestión de nicho.
Presente y futuro.
Aun así, el género supo permanecer en el lugar más importante al que se puede aspirar: el corazón de los miles de jugadores que formamos parte de estas historias siendo magos, detectives, piratas, motoqueros, galanes, viajeros en el tiempo y hechiceros… Si bien esta larga lista se fue acotando con el transcurrir del tiempo, hoy podemos evidenciar un resurgir del interés en las queridas aventuras gráficas, lo cual espero permita a las nuevas generaciones vivir momentos épicos en donde la narración, la imaginación, el buen humor, y la profundidad de los personajes tenga su adecuada valoración por encima de las físicas y los gráficos.
Felizmente para nosotros, en los últimos años han visto la luz una buena cantidad de proyectos, tanto “indies” como de desarrolladoras más conocidas, prometiéndonos nuevas historias que espero llenen nuestros corazones. Juegos como “Machinarium”,” La Fuga de Deponia”, o “Thimbleweed park” nos dejan entrever que aun hay lugar para estas producciones, lejos del mainstream que supieron conseguir hace más de 30 años pero con el espíritu que siempre las caracterizó. Este hermoso género aún tiene mucho para dar, y si todavía no han tenido la posibilidad de descubrirlo, los invito a que le den una oportunidad, ¡no los decepcionará!
Spoiler Alert: Hay que tomárselo con calma al comienzo, sobre todo si venimos de otros géneros. Pero cuidado: ¡Es sumamente inmersivo y adictivo!
*El autor trabaja con gráficos y es apasionado por los videojuegos. Posee un canal de YouTube llamado “BetaMax by Demere”.
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,1
Y 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:
Usar un editor de sprites, que nos genere los numeros necesarios
Hacerlo a mano
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, 0
Ademas 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
Para expandir a lo ancho tenemos el registro 29, y para expandir a lo alto el registro 23. Cada uno de estos registros son de 8 bits, y cada bit se corresponde con el sprite que queremos expandir, así que por ejemplo, si queremos expandir el sprite 1 a lo ancho deberiamos tipear POKE V+29,1 y si queremos expandir el sprite 8 a lo alto lo hacemos con POKE V+23,128 Aqui podemos ver como jugamos un poco con estos registros:Y con esto tenemos suficiente por hoy. Nos vemos en el proximo capitulo!
Los sprites en la C64 son objetos que podemos definir como nosotros deseemos, y que se pueden posicionar en cualquier parte de la pantalla. Al ser manejados por hardware no tenemos que preocuparnos por preservar el fondo de pantalla, ni mover bytes, pintarlos ni nada que en otras computadoras es tarea corriente. La C64 puede manejar hasta 8 sprites, y cada uno de ellos se les puede asignar un color independiente, expandirlos en el eje X o Y, posicionarlos en cualquier parte de la pantalla, y un monton de cosas mas. Cada sprite tiene un tamaño de 24×21 pixels, y ocupa 63 bytes en memoria
En este pequeño ejemplo vamos a definir un sprite cuadrado (todo con el valor 255, que en binario es 11111111), y vamos a ver como lo podemos mover, expandir y cambiar el color. Primero vamos a ingresar este programa en la c64, con el que vamos a poder ejemplificar varios conceptos 😀
10 v=53248
20 poke v+21,1
30 poke 2040,16
40 for t=1024 to 1087
50 poke t,255
60 next
70 poke v,100
80 poke v+1,110
En la primera linea seteamos la variable v con el valor 53248. Este valor corresponde al primer registro de los 46 que posee el chip de video de la C64 (el VIC2). De esta manera solamente tenemos que recordar una posición de memoria, y ciertos registros claves. El primer registro aparece en la linea 20, el número 21, y corresponde al numero de sprite activo, en este caso el número 1. Luego aparece una dirección de memoria (2040) con el que podemos especificar que segmento de la memoria del VIC2 queremos utilizar para definir la forma de nuestro sprite.
NOTA acerca del direccionamiento de memoria del VIC2: Si bien el 6510 (el microprocesador de la C64) puede direccionar hasta 64kb de memoria, el VIC2 solo puede direccionar 16kb. Por razones que escapan a esta introducción, el VIC2 se puede configurar para que utilize cualquiera de los 4 bancos de 16Kb, y por defecto cuando encendemos la C64 esta configurado para trabajar en el banco 0 (el bloque de memoria que va de 0 a 16384)
En la dirección de memoria 2040, entonces, podemos especificar el lugar donde se almacenarán los valores que daran forma a nuestro Sprite, en segmentos de 64 bytes. Para nuestro ejemplo utilizamos el valor 16, que multiplicado por 64 nos da … 1024… mhmmm.. Eso lo vimos en un post anterior, en el que imprimíamos en pantalla utilizando POKEs directamente en la dirección de video del VIC2. La idea de utilizar la memoria de video es mostrar como se va llenando la memoria con los valores que necesita el sprite (lineas 40 – 60), y como podemos modificarlos y ver como se reflejan esas modificaciones en la figura del sprite. Por supuesto que en un juego real no vamos a utilizar esa direccion, porque donde borramos la pantalla o actualizamos cualquier valor se nos rompe el sprite. Finalmente en las lineas 70 y 80 posicionamos el sprite en pantalla. Si ejecutamos el programa obtendremos el siguiente resultado (observen como se modifica el sprite cuando altero las 2 primeras lineas de texto en pantalla)
Observese tambien que se ve un puntito que representa el cursor. En la siguiente entrega ya vamos a darle una forma mejor, y vamos a mostrar el uso de los diferentes registros.
