Categoría: Historia

C64 a Fondo – 6502 vs 6510 Parte 4 – Primer Programa desde EEPROM

Continuamos este estudio comparativo del 6502 vs el 6510 en este caso creando nuestro primer programa en código máquina y grabándolo en una EEPROM, de esta forma vamos a indicarle al procesador que lea y ejecute el programa desde memoria.

Les dejo el link al articulo anterior en la serie, y al final como siempre los links a los artículos de la misma.

Parte 3 – Codeando a Mano la Primera Instrucción de Código Máquina

Qué es una EEPROM

Para poder avanzar en nuestro estudio de los procesadores vamos crear un programa en código máquina que vamos a almacenar en una memoria de sólo lectura. Esto es una eeprom Electrically Erasable Programable Read Only Memory, la cuál vamos a grabar fuera de nuestro breadboard utilizando un grabador de eeprom que el procesador va a tratar como si fuera una memoria de sólo lectura, leyendo instrucciones y datos de la misma pero nunca escribiendolos.

En nuestro caso el chip a utilizar es el AT28C256 de ATMEL. Este chip posee 32768 registros de 8 bits cada uno, por lo que podemos tener hasta 32k bytes de información en este tipo de memorias. El 256K se refiere a 256 K bits que son 32k Bytes (256/8).

Pinout de AT28C256

Este chip viene en formato DIP (Dual Inline Pins) de 28 pines (que parecido a las ROMs del Commodore, ¿capáz que podemos usarlas para algo más adelante ….?)

A14 – A0: Estos pines nos permiten seleccionar qué registro de ocho bits queremos acceder dentro de nuestra memoria, al ser 15 pines podemos direccionar 2ˆ15 = 32768 registros de 8 bits. Estos pines se conectan al bus de direccionamiento.

I/O 0 a I/O 7: Los pines de I/O es donde vamos a ver el contenido de cada registro previamente seleccionado para leer la memoria, o donde vamos a enviar los datos que tenemos para escribir la memoria. Estos pines se conectan al bus de datos.

VCC: En este pin es donde el chip espera una alimentación de +5Volts

GND: Este es el pin de referencia a tierra del chip

/WE: El pin de write enable al recibir una señal de low o 0 Volts permite grabar en los registros de la memoria. Como la estamos utilizando como una ROM conectamos este pin directamente a +5 Volts para que sea de sólo lectura. La barra / significa que este pin es active low con lo cual espera 0 Volts para activarse

/OE: El pin de output enable conecta o desconecta los pines de I/O del bus de datos. Si el pin está en +5 Volts la memoria se desconecta del bus de datos poniendo sus pines de datos en un estado de alta impedancia. La barra / significa que este pin es active low con lo cual espera 0 Volts para activarse

/CE: El pin de chip enable conecta o desconecta los pines del chip para una lectura o escritura trabajando en conjunto con /OE y /WE. Es active low con lo cual espera 0 Volts para activarse

Cómo leer y cómo escribir

Para poder leer o escribir tenemos que realizar una combinación de 3 pines /WE /OE /CE

Lectura

Para realizar una lectura deberemos primero poner en el bus de direccionamiento el address de la memoria que queremos acceder y acto seguido poner los pines:

/WE en +5 Volts (High)

/OE en 0 Volts (Low)

/CE en 0 Volts (Low)

En el bus de Datos tendremos la información asociada a la dirección que pusimos en el address bus..

Escritura

Para realizar una escritura deberemos primero poner en el bus de direccionamiento el address de la memoria que queremos escribir, luego en el bus de datos la información a grabar y acto seguido poner los pines:

/WE en 0 Volts (Low)

/OE en +5 Volts (High)

/CE en 0 Volts (Low)

El /WE o el /CE deberá ser un pulso.

Cómo seleccionamos la memoria desde el procesador

El 6502 y el 6510 pueden direccionar hasta 65536 registros de 8 bits cada uno o 64K como nos gusta llamarlos. Esto nos dejaría utilizar hasta 2 chips EEPROM de 32k cada uno.

Las direcciones que maneja el procesador van desde la $0000 hasta la $FFFF, siempre en hexadecimal como indicamos al anteponer el signo pesos. Si quisiéramos repartir estas direcciones entre 2 chips podríamos asignar de $0000 a $7FFF para el primero y de $8000 a $FFFF para el segundo.

Vamos a ver como se ven estas direcciones en binario para observar si podemos sacar algún patrón útil.

Espacio de DireccionamientoHexaBinario
Inferior$00000000 0000 0000 0000
Inferior$00010000 0000 0000 0001
Inferior………………………………………
Inferior$7FFE0111 1111 1111 1110
Inferior$7FFF0111 1111 1111 1111

Podemos observar que el primer bit en Binario es cero. Para direccionar todos los registros de la eeprom necesitamos 15 pines del A0 al A14 con lo que nos sobra el pin A15. Para poner en modo de lectura solamente al chip podríamos entonces conectar en forma permanente los pines:

/WE en +5 Volts (High)

/OE en 0 Volts (Low)

Y el pin /CE podemos conectarlo directamente al pin A15 así cuando esté en 0 Volts (Low) el chip eeprom estará seleccionado y podremos leerlo. Vayamos ahora a ver el segundo espacio de direccionamiento.

Espacio de DireccionamientoHexaBinario
Superior$80001000 0000 0000 0000
Superior$80011000 0000 0000 0001
Superior………………………………………
Superior$FFFE1111 1111 1111 1110
Superior$FFFF1111 1111 1111 1111

En este caso el pin A15 queda con un valor de 1 o +5 Volts (High) no podríamos conectarlo directamente al pin de /CE ya que no se activaría por ser Active Low el pin. Lo que deberíamos hacer es invertir el valor de 1 a 0 y propongo hacerlo con una compuerta NAND.

Una compuerta NAND tiene la siguiente tabla de verdad que es la opuesta a una compuerta AND.

Input AInput BResultado
LOWLOWHIGH
LOWHIGHHIGH
HIGHLOWHIGH
HIGHHIGHLOW

Con lo que si conectamos en la misma compuerta NAND como input A la salida en +5 Volts (HIGH) del pin A15 y como input B también la salida en +5 Volts (HIGH) del pin A15 el resultado será un 0 Volts (LOW) que permitirá activar el pin /CE de chip enable.

Para esto podemos utilizar un clásico chip como ser el 74HC00 que posee cuatro compuertas NAND de dos inputs cada una.

Y así quedaría montado en un breadboard.

Primer Programa en Código Máquina

Nuestra eeprom tiene que tener grabada alguna información para que nos resulte útil, por lo que vamos a cargarle un programa en código máquina. En nuestro primer programa vamos a llenar toda la memoria con la instrucción EA, esta es la instrucción de no operación la cual le dice al procesador que no realice nada durante 2 ciclos de reloj.

Este número hexa EA se corresponde con el binario 11101010 la cual utiliza 8 bits, el procesador va a estar en el ciclo de búsqueda de instrucción leyéndolo de nuestra eeprom. Utilizando el siguiente programa python podemos generar un archivo binario que llena completamente las 32768 posiciones de memoria de 8 bits de nuestra memoria eeprom.

rom = bytearray([0xea] *32768) # crea un array de 32768 ea

with open(“rom004.bin”,”wb”) as out_file: # wb significa escribir archivo binario

    out_file.write(rom)

Este programa al ser ejecutado con el comando:

$ python3 ./nombre_del_programa.py

Creará un archivo rom004.bin lleno de bytes EA, que podremos ver con el programa hexdump:

% hexdump -C rom004.bin

00000000  ea ea ea ea ea ea ea ea  ea ea ea ea ea ea ea ea  |…………….|

*

00008000

Todas las 32768 posiciones de memoria (del 0000 al 8000) están llenas con la instrucción de no operación EA. No es un programa muy útil pero si imita muy bien la codificación con resistencias de la instrucción EA hardcodeada en nuestro artículo anterior.

Cómo Se Graba una EEPROM

Ya que tenemos nuestro primer programa como un archivo binario de 32768 bytes, solo nos resta grabar el mismo en una EEPROM y esto se realiza con un grabador de eeproms. En este ejemplo vamos a usar un TL866 II Plus.

Este programador de eeprom es muy sencillo de utilizar a través del programa minipro, al mismo se le indica qué tipo de chip eeprom vamos a grabar y que archivo queremos grabar.

Antes de comenzar a grabar se inserta el chip eeprom en el zócalo zif y se conecta todo por usb a nuestra computadora.

En la siguiente imagen podemos ver como es el ciclo completo desde que ejecutamos el programa python hasta grabar la eeprom.

¿Y qué pasa entonces?

El procesador va a encender y buscar en las posiciones $FFFC y $FFFD la dirección de la primera instrucción a ejecutar ordenados como Low Byte y High Byte. Al haber grabado toda la memoria con la instrucción $EA encontrará con $EA en la posición de memoria $FFFC, luego irá a la posición $FFFD y cargará $EA.

$FFFC contiene $EA = %1110 1010

$FFFD contiene $EA = %1110 1010

Si lo ordenamos por los pines del address bus veríamos:

A15A14A13A12A11A10A9A8A7A6A5A4A3A2A1A0
1110101011101010

El Pin A A15 es un 1 que a través de la compuerta NAND se transforma en 0 equivalente a 0 Volts o Low, y como está conectado al  pin /CE nuestra EEPROM se activará.

Con esto cargará el  Program Counter con la primera posición de nuestro programa ficticio que será $EAEA y buscará el código de la próxima instrucción a ejecutar que será EA ya que es lo único que tenemos en el bus de datos.

Esta ejecución durará dos ciclos de reloj y luego el program counter avanzará a EAEB y volverá a leer el bus de datos en búsqueda de la próxima instrucción que seguirá siendo EA y así continuará.

.

Segundo Programa en Código Máquina

Casi siempre queremos indicar en qué dirección de memoria comenzar el programa y vimos en un artículo anterior que al tener un reset el 6502 y el 6510 buscan la primera instrucción en las direcciones $FFFC para el low byte y $FFFD para el high byte.

Con una pequeña modificación podemos hacer que nuestro programa comience a ejecutar en por ejemplo la dirección $8000.

rom = bytearray([0xea] *32768) # crea un array de 32768 ea

#modificamos dos bytes de nuestro array de EAs

rom[0x7ffc] = 0x00 # low byte que va a ser leído como $FFFC con el contenido $00 para formar la dirección $8000

# 0x7ffd va a ser leído como FFFD por tel procesador ya que estamos usando A15 como chip enable pero la EEPROM solo tiene 15 pines hasta A14

rom[0x7ffd] = 0x80 # high byte que va a ser leido para formar la dirección $8000

with open(“rom005.bin”,”wb”) as out_file:

    out_file.write(rom)

Creará un archivo rom005.bin lleno de bytes EA, pero que contiene la dirección $8000 en las posiciones $FFFC y $FFFD en formato low byte primero (little endian) que podremos ver con el programa hexdump:

% hexdump -C rom005.bin

00000000  ea ea ea ea ea ea ea ea  ea ea ea ea ea ea ea ea  |…………….|

*

00007ff0  ea ea ea ea ea ea ea ea  ea ea ea ea 00 80 ea ea  |…………….|

00008000

¿Y qué pasa entonces?

El procesador va a encender e ir a las posiciones $FFFC y $FFFD, activará el pin /CE en low a través de la configuración realizada en la compuerta NAND

$FFFC contiene $00 = %0000 0000

$FFFD contiene $80 = %1100 0000

Si lo ordenamos por los pines del address bus veríamos:

A15A14A13A12A11A10A9A8A7A6A5A4A3A2A1A0
1100000000000000

Luego cargará $00 ya que  ya que es el dato presente en la posición de memoria $FFFC, luego irá a la posición $FFFD y cargará $80. Con estos dos datos modificará el program counter a $8000 y comenzará a leer instrucciones de $8000. Claro que sólo leer $EA ya que es lo que está grabado pero luego de leerlo irá a $8001 y seguirá incrementando el Program Counter de a una unidad.

Un gran y simple programa para poder enfocarnos en cómo leer desde EEPROM un programa en código máquina.

Cómo funciona en la Commodore 64

La Commodore 64 posee 4 ROMS, 3 dentro de la placa madre y otra externa y variable:

El Basic ROM de 8 KB implementado con un chip MOS 2364A y ubicada en las direcciones de memorias $A000 – $BFFF. Esta ROM posee las rutinas de las instrucciones del lenguaje BASIC 2.0 que usamos en la Commodore.

El Kernal ROM de 8 KB implementado con un chip MOS 2364A y ubicada en las direcciones de memorias $E000 – $FFFF. Esta ROM posee las rutinas de más bajo nivel de la Commodore como ser las rutinas de ejecución de las primera instrucción, escrituras a pantallas, sonido.

El Character ROM de 4 KB implementado con un chip MOS 2332A  y ubicada en las direcciones de memorias $D000 $DFFF. Esta ROM posee el diseño de los caracteres que vemos en la pantalla, cada caracter ocupa 8 bytes siendo una grilla de 8×8 (8 líneas de 8 bits cada una). La Commodore 64 implementa 2 juegos de caracteres de 256 caracteres cada uno.

La cuarta ROM es la más desconocida de todas ya que es cualquier cartucho que conectemos a la Commodore 64, los mismos están ubicados en las direcciones ROM High ($A000 – $BFFF o $E000 – $FFFF) y ROM Low ($8000-$9FFF) y son mapeados dentro de la memoria por el kernall durante el proceso de inicialización de la Commodore 64.

Codificando desde EEPROM visualmente

Para poder estudiar visualmente como grabar una EEPROM y hacer que el procesador ejecute un programa en código máquina desde la misma les dejo esta video que complementa al artículo.

6502 vs 6510 Primer Programa desde EEPROM – Parte 4

Artículos en la serie C64 a Fondo

A continuación el link al próximo artículo en la serie

Parte 5 – I/O Pins del procesador 6510

y aquí los links a los artículos anteriores

Introducción

Parte 1 – El módulo de reloj

Parte 2 – Pinout 6510 y 6502

Parte 3 – Codeando a Mano la Primera Instrucción de Código Máquina

Referencias

A continuación les dejo algunos links donde profundizar el tema:

VIDEOS

Video de la serie 6502 vs 6510 Parte 4 – Primer Programa desde EEPROM

6502 vs 6510 Primer Programa desde EEPROM – Parte 4

Aquí tiene acceso a toda la serie:

6502 vs 6510 estudio detallado y comparación 

PAPERS

ATMEL AT28C256 datasheet 

74HC00 Datasheet (PDF) – NXP Semiconductors

TL866II USER GUIDE 

David Griffith / minipro · GitLab 

W65C02S 8–bit Microprocessor 

6502 Instruction Set 

MOS 2364 ROM

MOS 2332 ROM  

Y como siempre la serie de Ben Eater del 6502

Build a 6502 computer | Ben Eater 

Todos los ejemplos de código de los videos los pueden encontrar en:

https://github.com/carlinhocr/6502_vs_6510

C64 a Fondo – 6502 vs 6510 Parte 3 – Codeando a Mano la Primera Instrucción de Código Máquina

Continuamos este estudio comparativo del 6502 vs el 6510 tratando de descubrir cómo es que el procesador accede a las instrucciones en código máquina, las lee, interpreta y ejecuta. También vamos a ver como codear nuestra primera instrucción directamente usando resistencias y el bus de datos del procesador.

Les dejo el link al articulo anterior en la serie, y al final como siempre los links a los artículos de la misma.

Parte 2 – Pinout 6510 y 6502

Qué son las instrucciones en código máquina

Un procesador no utiliza internamente ninguno de los lenguajes de alto nivel que solemos utilizar como por ejemplo sería el Basic en la Commodore, ni siquiera usa Assembler. Internamente un procesador solo tiene esquemas de transistores que responden a distintas combinaciones de unos y ceros, lo que denominamos el código máquina.

Set de instrucciones del 6502 y el 6510

El código máquina de ambos procesadores posee las mismas instrucciones de assembler de 6500 con lo que los programas de uno funcionan perfectamente en el otro. La siguiente tabla muestra un resumen de todas las instrucciones del procesador.

Y en la siguiente tabla tenemos todas las instrucciones del 6502 y el 6510 codificadas por su representación en hexadecimal o binario.

Podemos encontrar en esta tabla, por ejemplo, una instrucción muy común como es la LDA # que carga el registro del acumulador con un número de 8 bits que indicamos a continuación del símbolo #. Esta instrucción se encuentra en la Fila A Columna 9 en nuestra tabla.

El procesador para reconocerla espera ver al momento de buscar una instrucción en el bus de datos los valores 10101001 (correspondientes al hexadecimal A9) en los pines de datos del D7 al D0 de nuestros procesadores. Correspondientes a los pines 26 al 33 para el 6502 y del 30 al 37 para el 6510.

De dónde lee las instrucciones el procesador

Cuando prendemos por primera vez un procesador 6502 o 6510, el procesador busca siempre en las mismas direcciones de memoria un lugar donde le digamos dónde se ubica la primera instrucción del programa que queremos ejecutar. En el caso de estos procesadores puede buscar en sólo 3 lugares dependiendo cómo se esté realizando la inicialización de los mismos.

$FFFA-$FFFB si se recibe una interrupción no enmascarable (pin /NMI)

$FFFC-$FFFD si se recibe un reset (pin /RESET)

$FFFE-$FFFF para una interrupción (pin /IRQ o instrucción de código máquina break $00)

La selección de cuál de estos vectores (que así se llaman las direcciones de memoria donde se espera haya otra dirección de memoria) se activa es básicamente que pin de estos tres recibe un LOW, teniendo precedencia, primero /RESET, luego /NMI y finalmente /IRQ o break en caso de recibirlo los 3 a la vez.

Recordemos que las direcciones son de 16 bits ya que el 6502 puede direccionar hasta 65532 direcciones (2 a la potencia 16) ya que la memoria contiene datos sólo de 8 bits vamos a necesitar dos posiciones de memoria para cargar la dirección de nuestro primer programa, por eso para reset utilizamos la posición $FFFC y $FFFD. El procesador sólo necesita la primera posición de memoria y sabe que tiene que ir a buscar la segunda dirección.

Estas posiciones se graban con la característica de ser little endian, lo que significa que guardamos el byte menos significativo primero. Por Ejemplo si queremos guardar la dirección $0E00 como la primera de nuestro programa deberemos guardarla en memoria como 00 0E

Por lo que si quisieramos guardar la posición de memoria $0E00 cuando nuestro procesador realice un reset debemos almacenar el low byte  $00 en la posición de memoria $FFFC y el high byte $0E en la posición $FFFD.

Posición de MemoriaContenido
FFFC00
FFFD0E

Nuestra primera Instrucción, la no instrucción NOP

Como primera instrucción vamos a utilizar NOP, esta es la instrucción de no operación, le dice al procesador que no realice nada durante 2 ciclos de reloj. Si la buscamos en nuestra tabla vamos a ver que está en la fila E y la columna A o sea $EA, agrego el símbolo pesos para indicar que se trata de un número en hexadecimal. 

Este número hexa se corresponde con el binario 11101010 y el procesador va a estar en el ciclo de búsqueda de instrucción esperándolo en los puertos de datos de nuestro procesador. Por lo que deberemos codificar para cada pin del procesador 6502 y para el 6510 respectivamente:

65026510
Pin 33 D0 = 0Pin 37 D0 = 0
Pin 32 D1 = 1Pin 36 D1 = 1
Pin 31 D2 = 0Pin 35 D2 = 0
Pin 30 D3 = 1Pin 34 D3 = 1
Pin 29 D4 = 0Pin 33 D4 = 0
Pin 28 D5 = 1Pin 32 D5 = 1
Pin 27 D6 = 1Pin 31 D6 = 1
Pin 26 D7 = 1Pin 30 D7 = 1

Normalmente el procesador elegirá un address de memoria y el chip de memoria le entregará los datos con las instrucciones correspondientes y estos valores binarios. Por ejemplo el procesador puede ir al address $0E00 y un chip de memoria entregarle el valor de 8 bits $EA  contenido en esa dirección, luego de lo cual el procesador interpretará esta instrucción y la ejecutará.

Cargando la instrucción para que la lea el procesador, con un truquito.

En nuestra primera aproximación a codificar el 6502 y el 6510 “a mano” lo que vamos a hacer es fijar el bus de datos con los valores de la instrucción EA, conectando los pines del bus de datos D7 a D0 de la siguiente forma.

Utilizando una resistencia de 1k conectaremos cada pin que en el diagrama tenga un cero a tierra o low y cada uno que tenga un uno a 5V o al canal high. El número parece al revés que EA = 11101010 debido a que el pin de más a la derecha es D7 (el más significativo) y el de más a la izquierda D0 (el menos significativo).

De esta forma siempre que el procesador quiera cargar una instrucción y pasa a modo de ejecución va a cargar nuestra instrucción EA y sólo esa instrucción ya que es lo único que va a estar en el bus de datos.

Y qué pasa entonces 

El procesador va a bootear e ir a las posiciones $FFFC y cargará $EA ya que es lo único que tiene en el bus de datos y luego a la posición $FFFD y cargará $EA que es lo único que tiene en el bus de datos claro ya que esta hardcodeado con las resistencias.

Con esto cargará el  Program Counter con la primera posición de nuestro programa ficticio que será $EAEA y buscará el código de la próxima instrucción a ejecutar que será $EA ya que es lo único que tenemos en el bus de datos. Esta ejecución durará dos ciclos de reloj y luego el program counter avanzará a $EAEB y volverá a leer el bus de datos en búsqueda de la próxima instrucción que seguirá siendo $EA y así continuará.

Un gran programa para poder enfocarnos en cómo funciona de la forma más básica la carga en binario de una instrucción en código máquina.

Cómo funciona en el Commodore 64

Al encender la Commodore 64 un circuito de reset entra en acción. El mismo está compuesto por un integrado de tipo timer 556 que es ni más ni menos que dos timer 555 en el mismo chip, con todos los conectores de un 555 en los pines de la izquierda y de otro  555 en los pines de la derecha.

A continuación tenemos una foto de parte del circuito en una Commodore 64 real y un esquema del circuito eléctrico que vamos a analizar.

Análisis del Circuito de Reset

El 556 (componente U20) está cableado en forma monoestable lo que significa que por cada vez que es activado a través de su pin de trigger envía un pulso a través de su pin de output. Este circuito es activado solo al encender la computadora y después no vuelve a funcionar en la Commodore. Al ser dos timers 555 vamos a mirar la parte derecha del mismo, los pines con el número 2 que son los que forman parte del circuito de reset.

Primero tenemos que estudiar la parte del circuito que activa al 556 a través de su pin de trigger, este pin se activa solo cuando el pin de trigger recibe un voltaje menor de ⅓ del voltaje total. 

Al encender la Commodore la carga del capacitor c105 es cero con lo que el voltaje en el pin TRIG es menor a ⅓ del voltaje total y un pulso es emitido. El capacitor C105 se carga a través de una resistencia de 1 Mega Ohms hasta que llega a los 5 volts lentamente y el pin TRIG deja de tener un voltaje menor a ⅓ del voltaje total con lo que el estímulo para activarse deja de existir para no volver nunca a un valor low mientras dure la Commodore encendida.

.

Cuando el capacitor  c24 se carga a ⅔ del voltaje total se activa el pin de Discharge y el 556 corta el pulso que estaba emitiendo.

Si queremos calcular aproximadamente cuanto dura el estímulo del pulso, podemos aplicar la formula para saber cuánto tarde un capacitor de 0.1 microfaradios en cargar a través de una resistencia de 1 Millón de Ohms

Constante de Tiempo = Resistencia en Ohms x Capacitancia en Faradios

=47000 ohms x 0.00001 faradios = 0,47 segundos

El tiempo para la carga total es de Constante de tiempo x 5 = 0,47 seg x 5 = 2,35 segundos

Pero no necesitamos que se llene completamente el capacitor en 5 Volts solo hasta que llegue a 2.33 volts o dos tercios del valor que es aproximadamente dos quintos del tiempo de carga total con lo que el pulso de output se mantiene por ⅖ * 2.35 seg = 0,94 segundos.

Pero esta salida de pin de Output es HIGH y cuando el impulso es disparado por el 556 el mismo pasa por un inversor para salir LOW y conectado a la  línea de RESET, que está conectada al 6510 en su pin /RESET ocasionando un reset del procesador.

Esta salida del inversor está conectado a una resistencia a 5Volts también llamada resistencia pull-up que mantiene el valor de la salida en HIGH evitando el reset siempre y cuando el inversor no reciba un nuevo output que sabemos no pasará por que el capacitor c105 mantiene los valores arriba de ⅓ del voltaje total.

Que ocasiona un pulso de reset en el 6510 y sus periféricos

Cualquier chip (sid, cia, etc), bus (IEC, etc) o dispositivo conectado a un bus (disketteras) que estén conectados a esta línea de reset comenzarán sus propias inicializaciones.

Al haber ejecutado un reset el procesador 6510 buscará la dirección de memoria para su primera instrucción en las direcciones $FFFC y $FFFD low y high byte respectivamente. 

Estudiando el mapa de memoria del Commodore 64 veremos que eso nos lleva a la dirección $FCE2 la primera línea de la rutina de Power On del Commodore 64, como se referencia en libro Mapping The Commodore 64 

La siguiente rutina de Kernel es la que se ejecuta.

Esta rutina activa el flag de deshabilitar interrupciones, programa el stack pointer para estar vacio con la dirección $01FF, deshabilita el modo decimal del procesador, busca si existe un cartucho en el puerto de expansión y si se encuentra le da al programa del cartucho el control de la Commodore, si no continúa con las rutinas de inicialización del kernel, inicializa los chips SID y CIA, inicializa la RAM, inicializa el VIC, limpia el flag de deshabilitar interrupciones y comienza el intérprete BASIC. 

Con esta clásica pantalla azul concluye nuestro pequeño resumen de como arranca nuestro Commodore 64.

Codificando la primera instrucción visualmente

Para poder estudiar visualmente como codificar la instrucción EA con resistencias y ver cómo busca las instrucciones el 6502 y el 6510 les dejo esta video que complementa al artículo.

6502 vs 6510 instrucción NOP (EA) codificada – Parte 3

Artículos en la serie C64 a Fondo

A continuación el link al próximo artículo en la serie

Parte 4 – Primer Programa desde EEPROM

y aquí los links a los artículos anteriores

Introducción

Parte 1 – El módulo de reloj

Parte 2 – Pinout 6510 y 6502

Referencias

A continuación les dejo algunos links donde profundizar el tema:

VIDEOS

Video de la serie 6502 vs 6510 Parte 3 – instrucción NOP (EA) codificada

6502 vs 6510 instrucción NOP (EA) codificada – Parte 3

Aquí tiene acceso a toda la serie:

6502 vs 6510 estudio detallado y comparación 

PAPERS

W65C02S 8–bit Microprocessor 

6510 MICROPROCESSOR WITH I/O 

6502 Instruction Set 

Load and Run from 6502 ASM (1/2) | C64 OS 

Mapping The Commodore 64

C64 Kernal Disassemble 

Y como siempre la serie de Ben Eater del 6502

Build a 6502 computer | Ben Eater 

Todos los ejemplos de código de los videos los pueden encontrar en:

https://github.com/carlinhocr/6502_vs_6510

C64 a Fondo – 6502 vs 6510 Parte 2 – Pinout

Vamos a empezar este estudio comparativo del 6502 vs el 6510 con una descripción del para qué sirve cada patita de estos chips (que básicamente es el pin out). Nos va a servir de guía para poder hablar de las diferencias que tienen estos chips entre sí

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.

Parte 1 – El módulo de reloj

Cosas en Común entre el 6502 y el 6510

Ambos chips fueron creados por MOS Technologies y muy utilizados en el final de los 70 y principios de los 80. El 6510 ya no se fabrica más en la actualidad (escribiendo estas notas en Junio del 2023) sobreviviendo sólo en los corazones de millones de Commodore 64 y en los corazones de miles de Commodorianos.

El 6502 todavía sigue siendo muy utilizado teniendo versiones actuales de USM y de WDC siendo la versión actual la 65C02 que agrega algunas instrucciones extras de assembler y baja mucho el consumo eléctrico.

Arquitectura

Ambos procesadores son procesadores de 8 bits y comparten muchísimas cosas en común. La arquitectura interna de estos procesadores es idéntica y está dividida en dos partes una sección con los registros y otra con las operaciones de control, las señales que provocan transferencias de datos están en la sección de control.

Set de instrucciones

El código máquina de ambos procesadores posee las mismas instrucciones de assembler de 6500 con lo que los programas de uno funcionan perfectamente en el otro.

Agrego algunas instrucciones extras del modelo 65C02 (las marcadas con punto en la siguiente tabla) que NO recomiendo usar para poder mantener compatibilidad con el 6510 y el 6502 originales pero que ahorran algunos pasos al no tener, por ejemplo, que pasar por el acumulador para guardar el registro X en el stack con la instrucción PHX. El 65C02 es una versión más moderna del MOS 6502 siendo una ventaja el ser fully static por lo que se puede parar el clock y los registros no pierden sus valores.

Velocidad de Reloj

Los procesadores 6502 y 6510 originales soportan una velocidad de reloj de hasta 1Mhz, teniendo luego el 8502 que soporta hasta 2Mhz (usado en el modo 64 de la Commodore 128)

Registros

La cantidad de registros y la forma de accederlos se mantienen para toda la familia estos son los familiares A, X e Y, el Status Register y el Stack Pointer los 5 de 8 bits y el Program Counter de 16 bits.

Modos de direccionamiento

Ambos chips funcionan de idéntica forma al relacionar la memoria y sus registros presentando modos de direccionamiento diferentes ya sea si uno quiere cargar directamente de memoria, o un número literal al acumulador, en forma indexada los datos y aplicar funciones que trabajan con el acumulador sin tocar memoria.

Bus de Direccionamiento y Bus de Datos

Ambos procesadores poseen 16 líneas de direccionamiento de datos (pines) pudiendo manejar entre memoria y registros de I/O hasta 64Kb (2ˆ16 = 65536 bytes).

Pin-Out y diferencias

Aquí salta a la vista la diferencia más grande ya que el 6510 posee 6 pines adicionales que puede ser utilizados como interfaz de Input/Output para comunicarse con periféricos ya que estos son bidireccionales. 

Para manejar estos pines el 6510 utiliza las direcciones 0 y 1 donde especifica en la cero si son inputs (pone un cero) o output (pone un 1)  y en el dirección 1 los valores de los mismos, ya sea recibidos de un periférico y escritos por el procesador para consumo externo.

Pin-Out 6502

Este chip posee un formato DIP 40 con las siguientes funciones en sus pines

VPB Pin de La B significa Bar o Barra para que este pin se active el voltaje tiene que ser Low o 0v

RDY El pin ready se utiliza para decirle al microprocesador que tiene que frenar y mantener al mismo en el estado actual, para activarlo y que frene el pin espera un estado low. Por ejemplo al recibir un estado Low (o volts) en el pin todas las líneas de output van a mantener los valores de corriente que tenían mostrando qué dirección estaban buscando. 

PHI1 o 01 (OUT) Pin de Salida de Reloj, el mismo es una salida de reloj para conectar a otros dispositivos. El PHI1 es típicamente la señal del PHI2 pero invertida

IRQB Pin de interrupción. Al conectar este pin a 0V, si las interrupciones están habilitadas, el procesador guardará el contenido de los registros actuales y buscará en las posiciones de memoria FFFE y FFFF donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar para atender a esta interrupción

MLB El pin de Memory lock se usa para mantener la integridad de las instrucciones Read-Modify-Write en un sistema multiprocesador. Cuando presenta un valor Low o 0 volts indicate que algún otro circuito debe arbitrar el ciclo del bus.

NMIB Pin de interrupción no enmascarable. Al conectar este pin a 0V el procesador guardará el contenido de los registros actuales y buscará en las posiciones de memoria FFFA y FFFB donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar para atender a esta interrupción. Este tipo de interrupción es incondicional y siempre será honrada.

SYNC Pin de sincronía El ciclo del procesador donde trae el código de operación (OpCode) se indican con el pin SYNC en high. Cuando el procesador busca un código del operación el pin queda en high y queda high por todo el resto del ciclo

VDD o VCC Pin de Energia. El procesador típicamente trabaja con +5v 

AB0 a AB11 Pines del Bus de Direccionamiento. Son pines bidireccionales que permiten recibir las direcciones de los dispositivos a los cuales comunicarse (memorias, otros chip en la placa, registros de I/O, etc). Al ser un bus de 12 bits direcciona hasta 4096 bytes o desde $0000 hasta $1000 

VSS Pin de Ground, este pin se conecta al common ground del diseño.

DB0 a DB7 Pines del Bus de datos, Este es un bus bidireccional que permite recibir y escribir datos junto con el bit de R/W a memorias y registros de I/O

R/WB Pin de Lectura/Escritura. Este pin indica si el procesador está realizando una lectura o una escritura. Cuando se encuentra en 1 o en estado High el procesador está realizando una lectura cuando está en 0 o estado Low una escritura.

NC  No Connect, este es un pin que no se debe conectar ya que no está conectado a nada dentro del procesador

BE Pin de Bus Enable, cuando este pin esta High los pines de address, data y RW están activos, cuando está low quedan con impedancia alta sacando al procesador del bus.

PHI2 o 02 (OUT) Pin de Salida de Reloj, el mismos es una salida de reloj para conectar a otros dispositivos

SOB Pin de Set Overflow. Este pin cuando recibe un cambio de high a low prende el bit de Overflow en el Status Register del procesador (bit 6). No se uso mucho en el pasado y no se recomienda su uso.

PHI0 o 00 (IN) Pin de entrada de Reloj, Este pin permite conectar un reloj interno al procesador para sincronizarse con otros dispositivos.

RESB Pin de reset, este pin sirve para realizar un reset del procesador cuando se conecte a 0v. El reset tomará 7 ciclos de reloj y buscará en las posiciones de memoria FFFC y FFFD donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar. El reset debe ser mantenido en 0v por lo menos durante dos ciclos de reloj para que sea reconocido.

Pin-Out 6510

Pines diferentes al 6502

PHI1 o 01 (IN) Pin de entrada de Reloj, Este pin permite conectar un reloj interno al procesador para sincronizarse con otros dispositivos. En el 6502 era el PHI0 y el 6510 sólo tiene 2 pines con respecto al reloj en lugar de los 3 que posee el 6502.

AEC Pin de Address Enable Control, se comporta de forma similar al pin de Bus Enable del 6502. Cuando este pin esta High los pines de address, data y RW están activos, cuando está low quedan con impedancia alta sacando al procesador del bus. Esto permite desarrollar sistemas con acceso directo a memoria por parte de otros chips o periféricos (DMA).

P0 a P5 Pines de I/o Port. Este procesador en su más marcada diferencia presenta en estos pines 6 conexiones bidireccionales con periféricos como si fuera un pequeño VIA o CIA. Vamos a explorar como funciona en detalle en un futuro artículo y video.

Pines idénticos al 6502

RDY El pin ready se utiliza para decirle al microprocesador que tiene que frenar y mantener al mismo en el estado actual, para activarlo y que frene el pin espera un estado low. Por ejemplo al recibir un estado Low (o volts) en el pin todas las líneas de output van a mantener los valores de corriente que tenían mostrando qué dirección estaban buscando. 

IRQ/ Pin de interrupción. Al conectar este pin a 0V, si las interrupciones están habilitadas, el procesador guardará el contenido de los registros actuales y buscará en las posiciones de memoria FFFE y FFFF donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar para atender a esta interrupción

NMI/ Pin de interrupción no enmascarable. Al conectar este pin a 0V el procesador guardará el contenido de los registros actuales y buscará en las posiciones de memoria FFFA y FFFB donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar para atender a esta interrupción. Este tipo de interrupción es incondicional y siempre será honrada.

VDD o VCC Pin de Energía. El procesador típicamente trabaja con +5v 

AB0 a AB11 Pines del Bus de Direccionamiento. Son pines bidireccionales que permiten recibir las direcciones de los dispositivos a los cuales comunicarse (memorias, otros chip en la placa, registros de I/O, etc). Al ser un bus de 12 bits direcciona hasta 4096 bytes o desde $0000 hasta $1000 

VSS Pin de Ground, este pin se conecta al common ground del diseño.

DB0 a DB7 Pines del Bus de datos, Este es un bus bidireccional que permite recibir y escribir datos junto con el bit de R/W a memorias y registros de I/O

R/W Pin de Lectura/Escritura. Este pin indica si el procesador está realizando una lectura o una escritura. Cuando se encuentra en 1 o en estado High el procesador está realizando una lectura cuando está en 0 o estado Low una escritura.

PHI2 o 02 (OUT) Pin de Salida de Reloj, el mismos es una salida de reloj para conectar a otros dispositivos

/RES Pin de reset, este pin sirve para realizar un reset del procesador cuando se conecte a 0v. El reset tomará 7 ciclos de reloj y buscará en las posiciones de memoria FFFC y FFFD donde está el vector (otra posición de memoria) que posee la primera instrucción a ejecutar. El reset debe ser mantenido en 0v por lo menos durante dos ciclos de reloj para que sea reconocido

Conectando al 6502 y al 6510

Para poder ver visualmente como es el esquema de conexión de pines de ambos procesadores les dejo un video donde vamos a repasar para que sirve cada pin y como conectarlo a un breadboard para en futuros videos poder programar ambos procesadores.

6502 vs 6510 Chip pin out – Parte 2

Artículos en la serie C64 a Fondo

A continuación el link al próximos artículo en la serie

Parte 3 – Codeando a Mano la Primera Instrucción de Código Máquina

y aquí los links a los artículos anteriores

Introducción

Parte 1 – El módulo de reloj

Referencias

A continuación les dejo algunos links donde profundizar el tema:

Video de la serie 6502 vs 6510 Parte 2 – Pin Out

6502 vs 6510 Chip pin out – Parte 2

W65C02S 8–bit Microprocessor 

6510 MICROPROCESSOR WITH I/O 

Todos los ejemplos de código de los videos los pueden encontrar en:

https://github.com/carlinhocr/6502_vs_6510

Y como siempre la serie de Ben Eater del 6502

Build a 6502 computer | Ben Eater 

C64 a Fondo – 6502 vs 6510 Parte 1 – El módulo de reloj

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.

Introducción

¿Qué es un módulo de reloj?

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.

NTSC: 59.826Hz (refresh rate) * 520 Pixels * 263 lineas = 8.18MHz

PAL: 50.125Hz (refresh rate) * 504 Pixels * 312 lineas = 7.88MHz

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

6502 vs 6510 Módulo de Reloj Manual – Parte 1

Artículos en la serie C64 a Fondo

A continuación el link al próximo artículo en la serie

Parte 1 – El módulo de reloj

y aquí los links a los artículos anteriores

Introducción

Referencias

A continuación les dejo tres excelentes artículos que hablan en profundidad del reloj de la Commodore 64.

Hardware Basics Part 1 – Tick Tock, know your Clock — Dustlayer

Hardware Basics Part 2 – A Complicated Relationship — Dustlayer

Clock Frequency

Y Cómo construir el módulo de Reloj por Ben Eater.

Clock module 

C64 a fondo – 6502 vs 6510

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.

Uso como guía los videos de Ben Eater (Build a 6502 computer | Ben Eater ) agregando estudios del 6510 y la Commodore 64.

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,

Parte 1 – El módulo de reloj

Artículos en la serie C64 a Fondo

A continuación los links a todos los artículos de la serie

Introducción

Parte 1 – El módulo de reloj

Parte 2 – Pinout 6510 y 6502

Parte 3 – Codeando a Mano la Primera Instrucción de Código Máquina

Parte 4 – Primer Programa desde EEPROM

Parte 5 – I/O Pins del procesador 6510

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.

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.

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*

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”.

El Joystick Colossus, un ejemplo de ingenio criollo e inclusión.

Marcos Calvo nos cuenta la historia del Colossus, el entrañable joystick nacional desarrollado y fabricado por su padre, Martín, en la década de 1980.

Joystick Colossus en su versión de 4 botones para la consola Famicom.

Compré mi primera Commodore 64 allá por 1997, con el único fin de experimentar la magia de cargar un juego desde un casete de audio común: quienes nos iniciamos en el mundo de las consolas con el Atari 2600, pasando luego al Nintendo (el “Family” para los amigos del barrio) y el Sega, conseguir un juego nuevo era sinónimo de adquirir (o intercambiar) un cartucho, un estuche de plástico que contenía una plaqueta electrónica con misteriosos circuitos integrados… por eso, la posibilidad de copiar juegos en un radiograbador parecía cosa de otro mundo, algo demasiado bueno para ser verdad…

Pero esa no es la historia que vengo a contarles hoy, ni soy yo su protagonista; resulta ser que acompañando a esa vieja Commodore publicada en la revista Segundamano venía un joystick especial, un artefacto muy bonito que alguna vez mi abuela llegó a confundir con una azucarera o un mate. Ese joystick era muy distinto a los que había conocido hasta ese momento: hecho de madera maciza, su forma contrastaba con los clásicos mandos de plástico con ventosas en la base, esos que pretendían ser la palanca de mando de un avión de combate. Este joystick era pesado, elegante, y era el único que funcionaba de forma delicada y consistente, motivo por el cual el privilegio de utilizarlo se convirtió pronto en motivo disputas fraternales aguerridas en el ámbito lúdico hogareño.

Pasaron 25 años, poca cosa para un amante de los videojuegos. Un día comienza a circular por Espacio TEC la noticia de que Marcos Calvo, hijo de un fabricante de joysticks nacionales llamado Martín, estaba dispuesto a brindarnos una entrevista. Grande fue mi sorpresa al descubrir que ese joystick, fabricado por don Martín en la maravillosa década del ‘80, era nada menos que el Colossus, ese control de “alta gama” que llegué a disfrutar cuando comenzaba a despertarse mi interés por la retrocomputación.

El joystick Colossus, para quienes no hayan tenido el privilegio de haberlo utilizado, es un cilindro de madera ahuecado, dentro del cual se ubican cuatro flejes metálicos rodeando una arandela central. La arandela, solidaria a la palanca de mando, hace contacto con los con los flejes de acuerdo al movimiento de la palanca (arriba, abajo, izquierda y derecha), poniéndolos “a tierra”. Si dos flejes adyacentes entran en contacto con la arandela central, la máquina a la cual se conecta el joystick podrá interpretar que se desea realizar un movimiento diagonal… la palanca es acompañada, en la versión clásica de la Commodore 64, por un único botón de color rojo, el cual sirve para disparar y/o saltar, generalmente. En un testimonio fílmico disponible en la web (ver ref. 1), el propio Martín nos cuenta que el diseño, aún en su simplicidad electrónica, debió resolver un par de cuestiones mecánicas… por ejemplo, ¿cómo hacer para que la palanca quedara ubicada siempre en el centro del artefacto? El elemento clave para lograrlo es tan insólito como eficaz, y todavía se encuentra disponible en las casas de repuestos que trabajen con la marca Renault. Quien tenga curiosidad (o necesidad de realizar una restauración) no tiene más que escuchar esta simpática anécdota en las palabras del propio creador del Colossus.

Esta entrevista, a pocos instantes -o renglones- de comenzar, toma el punto de vista de Marcos, hijo de don Martín y testigo privilegiado del amanecer y ocaso del Colossus. Marcos responde amablemente a mi saludo inicial, y pronto coordinamos una entrevista virtual. Él y su papá están de viaje por Buenos Aires, a punto de comenzar un nuevo emprendimiento en la provincia de La Rioja… el momento parece ser ideal: muchos recuerdos, muchas historias deben quedar atrás para dar lugar a lo nuevo, y casualmente estamos en el lugar y en el instante justo para oír y rescatar uno de esos entrañables pasajes de la historia de los videojuegos en la Argentina. ¡Aquí vamos entonces!

J: Tengo curiosidad, ¿en qué año nació Martín? ¿A qué se dedicaba antes de crear el Colossus?

M: Mi papá nació en 1945. Durante muchos años trabajó como fotógrafo profesional, participando en campañas gráficas de grande empresas. También llegó a trabajar como corrector literario.

J: ¿Y cómo llega al mundo de las computadoras hogareñas?

M: La primera máquina que compró fue una Texas Instruments, de esas en las que había que “escribir” los programas… ahí yo tendría unos tres años. Después adquirió una Sinclair, y se hizo experto en el “Manic Miner”, que era bastante difícil… mi papá lo terminó dando vuelta. Eso para mí era como… “guau”… yo soy un desastre en los juegos de plataforma. Luego vinieron la Commodore y la Atari, para llegar finalmente a la Amiga: esa máquina era increíble, tenía muy buen sonido… ya para esa época intercambiábamos juegos con amigos, había también ingenieros conocidos que programaban… la gente se gastaba mucha plata en eso.

J: ¿Podrías contarme detalles sobre la empresa que fabricó el Colossus? ¿Llegó a tener muchos empleados?

M: Colossus era un emprendimiento totalmente familiar. Mi viejo comenzó solo, recorriendo carpinterías y tallando pieza por pieza a mano… le llevaba un montón de tiempo. Al principio trabajó con maderas muy duras, y finalmente terminó utilizando caldén, que era mucho más “maleable”. Respecto al tema de los empleados, inicialmente se había asociado con otra persona, pero debido a algunos desacuerdos respecto a la calidad final que debía tener el producto (mi papá es muy detallista) la sociedad se terminó disolviendo. En aquél momento yo tendría cuatro o cinco años, y recuerdo haber visto a un par de personas trabajando… vivíamos en un departamento por Luis María Campos, en Capital, ese fue el primer lugar de fabricación. Pero la cosa realmente comenzó a funcionar cuando a mi papá se le ocurrió convocar a jubilados del barrio: el trabajo debía ser muy meticuloso, muy artesanal… hacía falta mucha paciencia; y justamente esas habilidades fue las que encontró mi papá en esas personas mayores, gente que tenía muchas ganas de trabajar, que estaba aburrida en su retiro. Fabricando los joystick Colossus muchos jubilados volvieron a sentirse útiles, podría decirse que “revivían”. Al mudarnos un tiempo después al Pasaje La Cárcova Colossus ya tenía tres jubilados “en planta”, más dos o tres que trabajaban desde su casa.

J: Este es un verdadero ejemplo de “trabajo inclusivo”, ¡excelente! ¿ellos también hacían el control de calidad?

M: Sí, los joystick se probaban exhaustivamente, se “torqueaban” uno por uno hasta lograr un funcionamiento óptimo.

J: ¿Cómo culminó la “experiencia Colossus”?

M: El final llegó en los años ‘90, con la apertura de las importaciones… te doy un ejemplo: los cables que comenzaron a llegar desde afuera tenían tres veces más calidad y costaban una fracción de lo que salían los nacionales… muchos amigos que mi papá tenía en el rubro de la electrónica también comentaban sobre lo que se venía: artículos muy baratos y fabricados en masa, con los cuales era muy difícil competir; al ver esto mi viejo entendió que las cosas se iban a complicar, que pronto el mercado nos iba a asfixiar… y así fue como decidió comprar una casa quinta por Burzaco para poner canchas de paddle, cambiando de rubro completamente.

J: Es una lástima que esa experiencia de trabajo artesanal e inclusivo haya terminado… sin embargo, la calidad de lo que hicieron en aquél momento hoy es reconocida por los retro-gamers, hay muchos joystick Colossus que siguen dando alegría a grandes y chicos…. ¿qué te genera saber eso?

M: Saber que todavía hay joysticks que siguen andando es un orgullo, algo increíble. Todavía conservo algunos Colossus en casa… hace poco enchufé uno, que estuvo guardado por 32 años, en un probador que tenemos: más allá de una pequeña desviación de la palanca funcionó perfecto. El tiempo demostró que el eslogan de mi papá, “un joystick para siempre”, estaba en lo correcto. Eran controles rústicos, hechos para durar… una tradición heredada de mi abuelo, que en su momento construyó varios muebles del hogar “a prueba de chicos”.

J: Teniendo una tradición tan interesante, y con la experiencia acumulada en los años transcurridos, ¿pensaron en volver a fabricar el Colossus? Muchos fanáticos, entre los que me incluyo, estaríamos felices teniendo la posibilidad de comprar nuevos joysticks “de autor”… ¿se podría soñar con un Colossus USB para poder disfrutarlo con los emuladores que existen en la actualidad?

M: Mirá, pensar en fabricar… no lo creo… lo que podría hacer eventualmente es dedicar algún tiempo para terminar de armar algunos Colossus que estuvimos guardando todos estos años… sería un artículo bastante exclusivo. El problema es el tiempo, ya que hoy estoy en proyectos bastante alejados a Colossus… sería algo para hacer “de onda”, aprovechando los ratos libres. Quizá si existiera un mercado internacional, y si lograra asociarme con la persona correcta… se podría pensar en armar una “fabriquita” de nuevo… pero hacerlo solo sería muy difícil. Hoy estoy enfocado y poniendo mis energías en los yuyos naturales y en los cristales de La Rioja, en donde tenemos una reserva ecológica autosustentable. Volviendo al tema del USB, ¡claro que es posible! En algún momento lo pensamos, al igual que en la posibilidad de una conexión Bluetooth. Te digo más, justo antes de cerrar la fábrica sacamos dos modelos avanzados para PC… hubo mucha investigación, se usaron potenciómetros de calidad superior a lo que había en aquél entonces en el mercado, pero aún así el producto final no satisfacía a mi papá… había muchas piezas, era complejo el ensamblaje… y por otra parte el joystick para PC no prendió mucho en esa época. También se desarrolló un modelo especial para juegos de carreras con volante, palanca de cambios y pedales… de esos se vendieron muy pocos, quizá unas 30 unidades… lo gracioso es que ese proyecto tenía como finalidad que mi mamá aprendiera a manejar. Nos quedaron piezas como para fabricar cerca de 100 simuladores, pero terminarlos hoy en día sería complejo, son 10 veces más complicados que los joysticks, con lo cual el precio final sería “delirante”. Como nota final te cuento que existió un modelo para el “Family” que tenía cuatro botones… quizá ponga en venta algunos de esos.

J: Con tantos modelos fabricados y desarrollados, ¿todavía conservan el prototipo del primer Colossus?

M: Lamentablemente no, creo que se extravió en alguna mudanza… recuerdo que el primer joystick que hizo mi papá estaba hecho con madera de cajón de manzanas… después hizo uno de chapa, para finalmente llegar al modelo que resultó definitivo. La idea de haber hecho el modelo final con madera tiene que ver con entregar una sensación de calidez y calidad: la chapa es muy fría, y el plástico nunca le gustó.

Ref.: 1. https://www.youtube.com/watch?v=27gX1-Tlw-Y

Intel 4004

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

Intel 4004

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.