Articulos – Página 4

pico RGB2HDMI – Una vista moderna a dispositivos del pasado

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 rojo verde 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

Mas informacion

Pagina del pico-RGB2HDMI
Pagina de pcbway shared project
Grupo de Commodore Argentina
Contacto mlorenzati@gmail.com

Bluetooth a PS/2: Necesidades modernas, sistemas de antaño

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!

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.

LAS AVENTURAS GRÁFICAS Y EL VIAJE A MUNDOS DESCONOCIDOS

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*

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 5_1/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”.

Intel 4004

Conoce la historia del intel 4004, el primer microprocesador de la historia.

Unos meses antes de que Federico Faggin comenzara a trabajar en Intel, la compañía de calculadoras japonesa Busicom le había encargado a la empresa el desarrollo de unos cuantos chips. El ingeniero Ted Hoff, uno de los primeros empleados de Intel, creyó que los circuitos integrados propuestos por Busicom eran demasiado complejos, ya que requerían miles de transistores, e ideó un chip de 4 bits que ejecutara las funciones de la calculadora. El por entonces CEO de Intel, Robert Noyce, le dio permiso para continuar trabajando en el proyecto. Junto a otro ingeniero, Stanley Mazor, crearon la arquitectura básica, el diagrama de bloques, el set de instrucciones del microprocesador.

Otros ingenieros también trataban de desentrañar por entonces cómo crear un microprocesador. El mismo Federico Faggin opina que “no fue un paso tan extraordinario, era simplemente tomar lo que el cliente quería hacer y hacerlo mejor en ese momento, sencillamente porque la tecnología de puerta de silicio de Intel permitía colocar el doble de transistores en el mismo chip y usando una RAM dinámica podías reducir aún más el número de transistores”. Pero hasta que él llegó a Intel, el proyecto para Busicom estuvo parado durante meses. Faggin estaba feliz porque pensaba que era el momento correcto para construir una CPU en un chip, pero al mismo tiempo estaba preocupado porque Intel había prometido un tiempo de entrega muy corto.

Intel lo había contratado demasiado tarde para cumplir lo pactado, y tampoco había valorado la dificultad del proyecto. De hecho, al día siguiente a su incorporación, él, Hoff y Mazor recibieron la visita de Masatoshi Shima, un ingeniero de Busicom, que se encontró con la noticia del escaso tiempo con el que disponían. Faggin se puso manos a la obra, y durante meses trabajó a conciencia, quedándose en Intel hasta altas horas de la noche para lograr su meta. No solo tenía que dar vida a ese chip, sino que el pack incluía el desarrollo del 4001 (una memoria ROM), el 4002 (una RAM) y el 4003 (un dispositivo de entrada/salida). Shima, el ingeniero de Busicom, durante seis meses estuvo en Intel ayudándole y comprobando sus avances.

Para 1971, Faggin había desarrollado toda la familia de chips e Intel los presentaba anunciando una nueva era de la electrónica integrada. Aunque es difícil determinar la contribución que hizo cada uno, lo cierto es que no solo Federico Faggin, sino también Ted Hoff y Stan Manzor, han pasado a la historia, conjuntamente, como los padres del microprocesador.

El Intel 4004 fue lanzado en un paquete de 16 pines CERDIP el 15 de noviembre de 1971. El 4004 fue el primer procesador de computadora diseñado y fabricado por Intel, que previamente se dedicaba a hacer semiconductores de chips de memoria. En su anterior empleo, en Fairchild, Faggin había desarrollado una tecnología pionera llamada Silicon Gate Technology (SGT) y también había diseñado el primer circuito integrado MOS usando la tecnología SGT (el Fairchild 3708), demostrando la viabilidad de la nueva tecnología. Tan pronto como empezó a trabajar para Intel, Faggin creó una nueva metodología de «Random Logic Design» con silicon gate, que no existía previamente, y la utilizó para encajar el microprocesador en un único chip. Su metodología fue usada en todos los primeros diseños de microprocesadores de Intel (8008, 4040, 8080).

Masatoshi Shima, que asistió a Faggin durante el desarrollo de la familia 4004, más tarde escribió el software para la calculadora Busicom y se unió a la compañía Zilog, fundada por Federico Faggin a finales de 1974 y la primera compañía dedicada exclusivamente a microprocesadores, para el desarrollo y diseño del microprocesador Z80, uno de los tres chips que provocaron la revolución de las home computers en los años 80’s.

Apple Macintosh

Te contamos un poco sobre esta fabulosa máquina, que causó tanto revuelo en 1984

La McIntosh roja es una variedad de manzana de piel roja y verde. Tal es el origen del nombre del primer modelo de computadora personal con entorno gráfico lanzada a principios de 1984 por Apple, destinada al consumidor promedio y con un costo de U$S 2495 en los Estados Unidos.

Si bien no fue la primera computadora personal que incluyó una interfaz gráfica de usuario (la primera fue la Xerox Star 8010 de 1981), sí fue la primera con la que dicha interfaz alcanzó el éxito comercial. El sistema operativo Lisa (rebautizado Macintosh System 1.0) y el sistema de oficina Lisa, ambos heredados de la computadora Apple Lisa (lanzada en enero de 1983) introdujeron aspectos que perdurarían en los futuros sistemas de la compañía: barra de menú por sobre la pantalla (aunque sin el menú Apple), comandos de menú con el símbolo de Apple (reemplazado luego por el símbolo del trébol), doble clic sobre un ícono para abrir la ventana de forma animada, arrastrar los ítems a la papelera para eliminarlos, etc.

En cuanto al hardware, tenía un procesador Motorola 68000 de 16 bits corriendo a 8 Mhz. (Lisa, con el mismo procesador, trabajaba a 5 Mhz.) y 128 KB de memoria RAM soldadas a la placa lógica (equivalente al motherboard). Los precios de las memorias eran un factor limitante por entonces; de haber salido de fábrica con 256 KB habría costado entre 200 y 400 dólares más. Por otro lado, no poseía un procesador gráfico o de sonido dedicados, sino que utilizaba el mismo procesador Motorola, que posteriormente sería utilizado en las consolas Sega Génesis, Sega Mega CD y Neo Geo como procesador principal, y en la Sega Saturn como procesador de sonido.

También incluía una unidad de disquetes de 3,5″ con capacidad para 400 KB (contra 320 KB de los disquetes de 5,25″ de la competencia), un monitor CRT blanco y negro de 9″, un mouse (algo prácticamente inédito en aquellos tiempos) con un solo botón, y un teclado, aunque sin las teclas de dirección (flechas) ni pad numérico.

Las posibilidades de expansión eran bastante limitadas: la memoria RAM podía llevarse a 512 KB pero reemplazando los 16 chips de 64 KB soldados por otros de 256 KB; las unidades externas de disquetes, necesarias para poder operar eficazmente el equipo, valían U$S 495; y los discos rígidos fabricados por terceros, que se conectaban al puerto serial, estaban al alcance de unos pocos.

Es por esto que, en septiembre de 1984, aparece la Apple Macintosh 512K (a un precio de U$S 2795), con 512 KB de memoria RAM, una capacidad de disquetes de 800 KB y la posibilidad de conectar un disco rígido propietario, entre otras mejoras.

Volvé a ver ésta y otras computadoras históricas en Espacio TEC. No te pierdas la reapertura el próximo domingo 19 de septiembre de 9 a 12 hs y de 14 a 18 hs con entrada libre y gratuita.

Recuerdos de Clementina

“Clementina” fué como se bautizó a la primera computadora cientifica del país. Te contamos más de ella y porqué fue tan importante

Clementina, en realidad una Ferranti Mercury II, se fabricó en 1955 en Inglaterra y fue la primer computadora científica argentina. Llegó al puerto de la ciudad de Buenos Aires en noviembre de 1960 e ingresó junto a otras computadoras: dos UNIVAC USS 90, una IBM 305 y una IBM 650. Todas ellas compartían algo en común, además del año de importación: las memorias de tambor magnético, las de núcleo magnético, las tarjetas y cintas perforadas. Ninguna de ellas incorporaba transistores, que habían sido creados en 1947, lo cual pone en evidencia que la velocidad de adopción de los nuevos descubrimientos era sensiblemente menor que en la actualidad.

Clementina tenía 18 metros de largo, 5000 válvulas de vacío y una memoria total de 5 KB. de núcleo magnético. Se puso en marcha el 15 de mayo de 1961. Dos meses antes se había brindado una capacitación inicial de programación sobre el lenguaje Autocode al grupo que trabajaría con la Mercury II. Aquí vale destacar que trabajar con Clementina era muy distinto a trabajar con una computadora de la actualidad. La máquina funcionaba durante las 24 horas del día y se asignaban turnos para las tareas de compilación y ejecución de programas, que eran ingresados mediante una cinta de papel perforado, y sus resultados iban a parar a una impresora o a otro conjunto de tarjetas perforadas. Lo curioso es que cuando la computadora calculaba, emitía unos sonidos que se asemejaban a “Clementina”, una canción popular inglesa, y cariñosamente se la bautizó así (aunque luego también le hicieron modular algunos tangos).

La computadora fue operada principalmente por científicos y estudiantes del Instituto de Cálculo de Buenos Aires y, a pesar de su corta vida que culminó con el golpe de estado de 1966, Clementina sembró las semillas para el desarrollo informático de la Argentina y además se convirtió en catalizador para el inicio de todas las carreras de computación que se crearían en el país. Así de importante fue.

Luego del golpe de estado, Clementina siguió operando solamente para asistir a los alumnos de Computación con sus trabajos prácticos. Pero el paso del tiempo, la falta de mantenimiento y la imposibilidad de obtener repuestos debido a su antigüedad, hicieron que la computadora fuera desactivada para siempre en 1970. Algunas de sus partes aún se conservan.

Años más tarde, a principios de la década de 1980, Ferranti fabricó las ULAs (Uncommitted Logic Arrays) de algunas de las home computers más famosas de la historia de la informática hogareña, como la Sinclair ZX81, Sinclair ZX Spectrum, Acorn Electron y la BBC Micro.

Autor: Diego Chiacchio (homecomputer)

https://homecomputer.com.ar

Diego es coleccionista de computadoras antiguas desde 1999, cofundador de Retrocomputación.com, la mayor comunidad de habla hispana de coleccionistas y usuarios de microcomputadoras, creador del sitio Home Computer dedicado a las computadoras hogareñas y consolas clásicas de video juegos y colaborador de Espacio TEC.