Etiqueta: hardware

The 20c – Episodio 4 – ROM, Read Only Memory

Introducción 

En este episodio vamos a conocer al Chip ROM o Read Only Memory el cual tiene la funcionalidad de darnos una memoria de sólo lectura. Esta memoria nos va a servir para poder almacenar todas las instrucciones de nuestros programas.

Para usar este chip diseñamos una placa Dual que va a poder correr tanto un chip ROM como uno RAM que comparten el mismo pinout, en este episodio nos vamos a enfocar en la ROM.

Vamos a estudiar el pinout del chip, como funciona, como poder grabarlo usando un programador de EEPROM y vamos a realizar experimentos que nos dejen almacenar y ejecutar nuestro primer programa.

Como siempre vamos a explicar como crear la placa desde cero y como funciona la misma.

Descripción general de la placa ROM

Nuestra Placa RAM/ROM, cuando la configuramos en modo ROM, sirve para almacenar los programas que vamos a ejecutar en nuestra 20c. 

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 del nombre, se refiere a los 256 Kbits individuales que posee la placa los que equivalen a 32 Kbytes (256/8=32). 

Para grabar este chip con instrucciones utilizaremos un grabador de memorias EEPROM.

Este chip viene en formato DIP (Dual Inline Pins).

Descripción del Pin Out del chip AT28C256 

Este chip presenta 28 pines con el siguiente funcionamiento:


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 o ADDRESS BUS .

I/O 0 a I/O 7: Los pines de input/ouput o 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 o DATA BUS .

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.

Mapa de Memoria

El 6502 puede direccionar hasta 65536 registros de 8 bits cada uno o 64K como nos gusta decir. 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.

Nuestro chip posee 32kb de espacio pero vamos a tener que decidir con qué direcciones de memoria vamos a querer accederlo, esto se denomina mapa de memoria.

El mapa de memoria indica para cada chip y periférico de nuestra 20c qué direcciones del ADDRESS BUS van a activarlo para acceder a sus registros, en el caso de chips con registros para configurarlos o en el caso del chips de memorias ROM y RAM para leer o modificar su contenido.

Vamos a decidir colocar nuestro chip ROM en las direcciones de la $8000 a $FFFF principalmente por que ahi vamos a tener 3 posiciones de memoria o vectores muy importantes, los dos de interrupciones NMI e INT y el de RESET que como recordamos es donde el chip 20c busca la dirección donde va a estar el primer programa a ejecutar cuando prendemos el mismo.

Este mapa de memoria es el recomendado originariamente en el manual de Hardware y el en de Programación de MOS Technologies.

El siguiente es el mapa de memoria de la 20c

En este mapa podemos ver donde tenemos el chip ROM y algunos otros chips extra que vamos a estudiar en futuros episodios.

Cómo acceder al Chip

El chip no se encuentra todo el tiempo activo ya que si no tendría siempre el DATA BUS ocupado. El CPU ordena a los chips de la computadora y le indica al chip que quiere leer sus datos a través de los pines de ChipSelect /CS y OutputEnable /OE.

Aquí es donde entra en juego el mapa de memoria, vamos a activar los pines de /CS y /OE cuando en el ADDRESS BUS se escriba una dirección de las que definimos como parte del chip ROM. Este chip por definición va a ser de sólo lectura.

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. El /WE o el /CE deberá ser un pulso, cuando indicamos que una señal debe ser un pulso se debe a que el chip reacciona, no al valor específico en volts, sino al cambio de voltaje, en el caso de /CE de +5Volts a 0V también llamado Falling Edge.

Escritura

Para realizar una escritura deberemos primero poner en el bus de ADDRESS BUS la dirección de la memoria que queremos escribir, luego en el bus de datos o DATA BUS 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)

Recordemos que al tratarse de una ROM no vamos a realizar escrituras a la misma, esto lo vamos a lograr conectando el chip /OE de output enable siempre a +0v o Ground.

Cómo seleccionamos la memoria desde el procesador

Nuestro chip está en las direcciones desde $8000 a $FFFF. Vamos a ver como se ven estas direcciones en binario para observar si podemos sacar algún patrón útil.

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

Podemos observar que el primer bit en Binario es uno. 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)

También podemos conectar el pin /WE al pin de R/W del procesador 6502 ya que el mismo emitirá un pulso de +5V al realizar una lectura, pero por si se equivoca y envia una escritura no queremos que esto afecte a nuestra memoria así que no lo hacemos.

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.


Veremos cómo realizar la conexión a nuestra placa en la sección Guía de Conexión.

Programando en Assembler

Para poder programar nuestro chip 6502 con facilidad vamos a utilizar un programa Assembler llamado VASM. Este ensamblador nos va a permitir compilar a binario nuestro programa. El link para descargarlo se encuentra en las referencias.

Programa

Empecemos con un programa assembler sencillo que emula nuestros experimentos anteriores con resistencias para codificar la instrucción de no operación NOP cuyo opcode es 0xEA.

Vamos a explicar línea por línea que hace nuestro programa:

Líneas 1 y 2 comentarios

Línea 3 .org 8000 

Indica que queremos comenzar nuestro programa a partir de la dirección $8000 justo donde comienza nuestra ROM. Esto va a hacer que el compilador cuando traduzca nuestro programa a los OPCODEs de cada operación los situe a partir de la dirección $8000.

Línea 4 vacia

Línea 5 RESET 

Esto se denomina un LABEL nos sirve para poder indicar una parte del código donde vamos a querer llegar sin tener que saber exactamente que dirección hexadecimal posee en la memoria, el ensamblador se va a encargar de poner la dirección Correcta durante el ensamblaje (el ensamblador que ensamble un buen ensamblaje, buen ensamblador será).

Este importante esta LABEL en particular ya que el 6502 automáticamente busca en la dirección $FFFC y $FFFD la dirección donde está la primera instrucción a ejecutar y nosotros le vamos a pedir que sea la dirección donde esta el LABEL RESET.

Línea 6 comentario

Línea 7 a 16 NOP

Comienzan nuestras instrucciones con la instrucción NOP de no operación, el 6502 lo va a leer y va a pasar dos ciclos de reloj sin hacer nada. En nuestro programa compilado va a poner 10 bytes EA consecutivos.

Línea 17 vacia

Línea 18 comentario

Línea 19 .org FFFA

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 20 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFA $00 y en la $FFFB $80. Esta dirección carga el vector de interrupciones NMI.

Línea 21 .org FFFC

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 22 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFC $00 y en la $FFFD $80. Esta dirección carga el vector de interrupciones de la operación RESET, luego de un reset del procesador va a cargar como primera instrucción la que aquí se encuentre.

Línea 23 comentario

Línea 24 .org FFFE

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 25 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFE $00 y en la $FFFF $80. Esta dirección carga el vector de interrupciones IRQ.

Compilando

Ahora que ya tenemos nuestro código fuente, vamos a compilar nuestro código assembler  a código de máquina usando vasm.


Aquí le doy varias opciones al compilador, vamos a verlas

Vasm6502_oldstyle, esta opción le dice al ensamblador que utilice el módulo de sintaxis Oldstyle, esto va a definir distintas particularidades de como escribir los LABELs y otros detalles

-Fbin, vamos a señalar como módulo de Output el simply binary output module, este módulo va a escribir la salida de todas instrucciones que tenemos en nuestro código fuente como un archivo binario. Los espacios vacíos entre secciones .org que no llenamos con instrucciones van a tener el byte $00

-dotdir, que acepte en nuestro código direcciones especiales al ensamblador como ser por ejemplo .org

ep4_firstprogram.asm, el nombre de nuestro archivo con el código fuente

-o, a continuación indicaremos el archivo donde poner el código binario ya ensamblado

ep4_firstprogram.bin, el nombre de nuestro programa ensamblado en binario

Análisis del código máquina

Ahora utilizando el programa hexdump examinemos nuestro código máquina y tratemos de interpretar donde están las instrucciones anteriores.

A las direcciones que vemos sumemosle $8000 por como muestra el archivo hexdump, con lo que donde dice 00000000 miremos 000008000. ¿Por qué es así? Por que la ROM sólo tiene 32kb y nosotros lo ponemos en el mapa de memoria de nuestro 6502 a partir de la dirección $8000, pero no existe esta dirección dentro de la ROM ya que 32kb van desde $0000 a $7FFF. Hexdump solo muestra la realidad del interior del archivo sin saber donde vamos a mapear nosotros.

Línea 00000000 aquí vemos 10 veces el byte EA que corresponde al código de operación de NOP

Línea 00000010 todos ceros, recuerden como -Fbin rellenaba los espacios que no definimos

Línea 00007ff0 aqui finalmente vemos los últimos 6 bytes como 00 80 00 80 00 80 que corresponde a las direcciones LOW y HIGH para el LABEL de reset que está definido en la dirección $8000 para los 3 vectores de 6502 NMI, RESET e IRQ.

Ahora que tenemos nuestro código máquina vamos a grabarlo en el chip de EEPROM 

Cómo grabar el Chip con un grabador de EEPROM

Para escribir las instrucciones de nuestro chip vamos a usar un grabador externo que nos va a permitir completar cada casillero de memoria con las instrucciones que queramos

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 o el T48.

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 conectamos el grabador a nuestra computadora, e insertamos el chip eeprom en el zócalo zif 

Vamos a utilizar el programa minipro para poder hacer la escritura del chip, donde conseguir el mismo está incluido en las referencias de este mismo episodio.

Para grabar un archivo binario con el nombre por ejemplo ep4_firstprogram.bin ejecutaremos el siguiente comando.

$ minipro -p AT28C256 -w ep4_firstprogram.bin

La opción -p es para especificar el modelo de la memoria que vamos a grabar en este caso una AT28C256 de ATMEL.

La opción -w para especificar que queremos hacer una escritura y a continuación el nombre del archivo a grabar.

Y con esto tenemos nuestro primer programa grabado en ROM, en los experimentos vamos a ver que ejecuta nuestra computadora con este primer programa

Circuito de la Placa ROM de la 20c

El siguiente gráfico muestra el circuito que explica el funcionamiento de la Placa ROM de la 20c.

El circuito posee los siguientes elementos:

SOCKET RAMROM

El cual está representado físicamente como un socket DIP-28 de 28 pines, a cada uno de estos pines se le conectó un Netlist representando cada una de las funciones de estos pines por ejemplo el netlist A0 representa el pin A0 que estará conectado a todos los elementos que tenga que estar conectados con la línea o trace del address 0. 

Tiene conectado los netlists de A0 a A14, D0 a D7 y todos los netlist de /RW (señal de Write Enable), OE y CS. Para darle energía esta conectado a los planos de +5b y GROUND.

HEADER ADDRESS

Este es un header hembra de 16 pines el cuál se usa para conectar el address bus, el mismo tiene conectados 16 netlist (o conexiones entre varios pines que tienen la misma información). Estos netlist corresponden a los pines A0 hasta A15. 

Tenemos dos de estos conectores para poder tener la información en la parte superior e inferior de la placa y realizar interconexiones con otras placas.

HEADER DATA

Este es un header hembra de 8 pines el cuál se usa para conectar el data bus, el mismo tiene conectados 8 netlist (o conexiones entre varios pines que tienen la misma información). Estos netlist corresponden a los pines D0 hasta D7.

Tenemos dos de estos conectores para poder tener la información en la parte superior e inferior de la placa y realizar interconexiones con otras placas.

HEADER EXPANSION

Este es un header hembra de 16 pines el cuál se usa para conectar el expansion bus, el mismo tiene conectados 16 netlist (o conexiones entre varios pines que tienen la misma información). Estos netlist corresponden a algunos netlist conectados directamente a pines de RAMROM como ser:

RW, OE, CS

o señales genéricas que pueden transmitir información a otras placas como ser:

RST, CLOCK, RW, E5 hasta E15

Tenemos dos de estos conectores para poder tener la información en la parte superior e inferior de la placa y realizar interconexiones con otras placas.

HEADER POWER y GROUND

Este header posee dos pines y están conectados a las capas de 5V y de GROUND respectivamente. Tenemos cuatro de estos conectores, uno en cada esquina de la placa.

CAPACITOR

Tenemos un capacitor de 0.1 microFaradios para que cuando el CPU arranca pueda disponer del pico extra de energía que necesita.

AGUJEROS para TORNILLOS

Para poder fijar nuestra placa a distintos lugares la misma cuenta con 6 agujeros para tornillos de 3mm o M3.

SWITCH RAMROM SW1

Este switch no posee ninguna característica eléctrica y no está conectado a ning;un circuito, como nuestra placa puede funcionar tanto como ROM como RAM vamos a correr el switch y dejarlo en la posición en que vamos a usar la placa.

NETLIST

Los componentes están conectados entre sí a través de un objeto llamado netlist el cual nos permite tener diagramas más limpios.

Este funciona de forma tal que todo lo que tenga el mismo nombre pertenece al mismo netlist y deberá estar conectado junto cuando hagamos el PCB (con traces). 

En nuestro ejemplo todas las conexiones A0 estarán conectadas por traces en el PCB

PCB de la Placa ROM de la 20c

El siguiente PCB explica cómo se ubican los elementos y traces para conectar nuestro circuito. El PCB que diseñamos está hecho con 4 capas de cobre.

TOP

En la capa llamada TOP que es la que podríamos ver como arriba y de frente en nuestra PCB vamos a tener algunas las conexiones de nuestros netlist a través de traces, los cuáles son finas líneas de cobre que conectan los mismos como si fueran cables y los todos los componentes ya sea sockets, capacitores y headers.

LAYER 5V

En la capa +5v conectaremos las conexiones de power. Al usar estas conexiones en una capa separada nos ahorramos muchos centímetros de traces que deberían conectarse a pines con los voltajes de 5V podemos conectar directamente el pin de cada componente a esta capa a través de un agujero llamado VIA.


LAYER GROUND

En la capa GROUND conectamos las conexiones de ground o masa. Al de tener una capa entera para GROUND es poder aislar el ruido eléctrico de las conexiones entre componentes.

BOTTOM

Por último tenemos la capa de BOTTOM donde se sueldan nuestros componentes y tenemos conexiones adicionales.


Modelado 3D

Cuando terminamos de realizar nuestra Placa debemos proceder al modelado 3D de la misma para observar cómo queda y si nos gusta el lugar donde pusimos cada componente

.

Generación de archivos fuent

Para poder mandar a fabricar nuestro PCB deberemos contar con al menos 3 archivos:

  1. Archivo .gerber donde le indicamos al fabricante como armar nuestra placa
  2. Archivo BOM o Bill of materials donde se encuentran todos los componentes que forman nuestra placa con el código de producto del fabricante.
  3. Archivo Pick and Place donde le indicamos al fabricante cómo ubicar los componentes en nuestra placa PCB.

lista de archivos

Estos archivos los van a encontrar previamente generados en el github de Osolabs. También incluimos archivos para poder editar el circuito con el software EasyEDA, Kickcad o Altium Designer.

Con estos tres archivos vamos a poder fabricar nuestra placa

Gerber_v03_RAM_ROM_4Plane_2026-05-26.zip Este archivo contiene todos los planos para poder generar nuestra placa PCB.

BOM_v03_RAM_ROM_4Plane_v03_RAM_ROM_4Plane_2026-05-26.xlsx Contiene todos los componentes de nuestra placa y el código del fabricante que identifica a ese componente.

PickAndPlace_v03_RAM_ROM_4Plane_2026-05-26.xlsx

Indica en qué parte del PCB va cada componente y en qué capa debe ubicarse.

Los siguientes archivos se proveen para poder editar el circuito 

3DModel_ramrom_front.png

Es una imágen con la parte de atrás de nuestra placa modelada en 3D

3DModel_ramrom_back.png

Es una imágen con la parte de adelante de nuestra placa modelada en 3D

Altium_Circuit_1_v03_RAM_ROM_4Plane.schdoc

Contiene el diseño del circuito editable con el programa Altium Designer.

Altium_PCB_v03_RAM_ROM_4Plane.pcbdoc

Contiene el diseño del PCB editable con el programa Altium Designer.

PCB_v03_RAM_ROM_4Plane_2026-05-26.pdf

Es un PDF con un dibujo de cada capa del PCB

ProDoc_v03_RAM_ROM_4Plane_2026-05-26.epro

Archivo para EasyEDAPro con el circuito y el PCB el cual puede editarse.

SCH_v03_RAM_ROM_4Plane_2026-05-26.pdf

Es un PDF con los circuitos lógicos de la placa

Preparación de las Placa ROM

Al recibir nuestra placa de la fábrica y antes de comenzar a utilizar la misma y al momento que la sacamos de la caja, hay algunas tareas que deberemos hacer para poder hacer uso al máximo de la misma:

  1. Remover los bordes de manipulación de la placa
  1. Limpiar placa con alcohol isopropílico
  1. OPCIONAL – Poner un zócalo ZIF de 28 pines en el socket de la placa
  1. Poner el chip AT28C256 en el socket
  1. Ajustar a mano las patas del chip para que calcen el socket
  2. Alinear pin 1 con el pin 1 en el socket
  3. Primero insertar un lado del chip, poniendo el mismo en diagonal y luego el otro lado
  4. Verificar que ninguna patita quedó doblada
  5. Hacer presión y ver que todas están bien ajustadas en el socket
  1. Poner Tornillos de soporte de la placa para que esté levantada por encima de la superficie o instalarla, en nuestro caso usamos la base impresa en 3D de la 20c que vamos a aprender a crearla e imprimirla en un próximo Episodio
  1. Configurar switch SW1 en modo ROM para acordarnos que función cumple la placa.

Guía de Conexión de la placa ROM de la 20c

Vamos a explicar como conectar los distintos componentes de la placa para dejar esta lista para funcionar en una maqueta. Tené esta sección como referencia para cuando ensambles toda la 20c.

La memoría ROM queremos activarla para que funcione en las direcciones $8000 a $FFFF. Para esto vamos a necesitar tener el pin  A15 en uno como ya hemos visto.

A15A14A13A12address
ROM1XXX8000-FFFF

La memoria ROM tiene dos pines para activarse /OE y / CS ambos tienen que estar en cero para que la misma esté activada.

/OE memoria ROM

El Pin /OE vamos a conectarlo directamente a la señal de GROUND para que esté siempre activo .

R/W memoria ROM

El Pin R/W vamos a conectarlo directamente a +5v para que la memoria sea de sólo lectura siempre .

/CS memoria ROM

El pin de chip select vamos a seleccionarlo con el pin A15. Al pin A15 vamos a combinarlo consigo mismo en una compuerta NAND de forma tal que cuando valga un 1 lógico o +5v la  compuerta NAND dará un 0 lógico o +0v. Como ya estudiamos por el comportamiento de la compuerta NAND

Esa salida de la compuerta NAND vamos a conectarla a través del EXPANSION BUS con el pin /CS

Vamos a utilizar al el chip 74HC00, usando los pines 2A, 2B y la salida 2Y utilizando un breadboard

  1. Conectar el chip 74hc00 a un breadboard montando el lado izquierdo del chip en la parte por arriba de la canaleta del breadboard y la parte derecha en la parte inferior a la canaleta del mismo. Esto hará que respetemos la orientación del esquema que incluimos con el PIN 1 abajo a la izquierda.
  1. Conectar el pin de VCC al carril de +5v o rojo del breadboard
  1. Conectar el pin de GND o ground +0v al carril azul del breadboard.
  1. Conectar las canaletas superiores e inferiores del breadboard de +5v y 0v o ground entre sí
  1. Para poder hacer el efecto en la compuerta NAND conectaremos el pin A15 del bus de direccionamiento al pin 2B del 74HC00 y desde el mismo breadboard conectaremos el pin 2B al 2A.
  1. Conectamos la Salida 2Y al pin /CS del bus de expansión
  1. Finalmente para que el chip 74HC00 funcione no podemos dejar ninguno de sus inputs flotantes por lo que los conectamos todos a +5v. Estos son los pines 1A, 1B, 2A, 2B, 4A, 4B.

Conexión del resto de la placas

Para poder realizar nuestro experimentos tenemos que configurar el CLOCK y la CPU 6502 de la 20c asi cómo darle power en +5v.

  1. Conectamos un módulo de power a nuestro breadboard seleccionado el carril en +5v, tener en cuenta de poner el pin del módulo que dice + en el carril rojo de +5v.
  1. Conectamos el carril rojo del breadboard al pin de +5v de la placa de RAM/ROM.
  1. Colocamos al costado de la placa de RAM/ROM la placa de CLOCK y conectamos los pines de power +5v y GROUND entre las dos placas
  1. Conectamos la salida del reloj paso a paso de la placa de CLOCK al pin CLOCK de la placa de RAM/ROM pero en el pin header inferior, el que está más cerca del breadboard
  1. Colocamos la placa de CPU encima de placa de RAM/ROM y conectamos todos los headers de ADDRESS BUS y de DATA BUS. También vamos a conectar entre sí el pin de CLOCK y los pines de +5v y GROUND
  1. Instalamos la placas de DUINO PROTOCOL ANALYZER junto a su Arduino Mega en el header superior de la placa de CPU 6502
  1. Por último observamos que así nos queden todas las conexiones

Experimento 1 – Grabando solo NOPs

Vamos a reproducir el experimento que usábamos grabando la instrucción de no operación NOP, cuyo opcode es 0xEA como vinimos haciendo hasta acá y estudiaremos cómo se comporta la 20c usando la placa de DUINO PROTOCOL ANALYZER.

Vamos a usar el programa que creamos en la sección sobre código máquina. Este programa usa principalmente la instrucción NOP:

Para el detalle línea por línea de lo que hace el programa ir a la sección Programando en Assembler


Vamos a compilarlo con vasm.

Y ahora colocamos la eeprom en el programador


Corremos el comando minipro y lo grabamos


Y ahora vamos a estudiar la salida del procesador usando el DUINO PROTOCOL ANALYZER, utilizando el script 001_Arduino_DUINO_PA que ya vimos en el Episodio 3 sobre el DUINO PA y analizaremos el output de nuestro experimento.

Reset seguido de lectura de instrucciones NOP

  1. Conectamos el pin CLK del header CLOCK_555_OUT
  1. Seleccionemos el switch para el reloj paso a paso. 
  1. Presionemos el botón de reset de nuestro CPU y dejemoslo presionado.
  1. Presionar 3 veces el botón de STEP BUTTON de nuestra placa de CLOCK
  1. Soltar el botón de RESET de nuestro CPU
  1. Continuemos presionando el botón de STEP BUTTON de nuestra placa de CLOCK y veremos que cada vez que lo hacemos avanza un ciclo en  nuestro CPU, algunas instrucciones ocupan un ciclo de reloj y otras más
  1. Observamos en detalle los datos que nos da nuestro DUINO PROTOCOL ANALYZER a través del Arduino Mega.

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. 

$FFFC contiene $00 = %0000 0000 

$FFFD contiene $80 = %1000 0000

En la misma va a encontrar los bytes $00 y $80 al utilizar la notación little endian la dirección que va a cargar el cpu 6502 en su registro de program counter va a ser $8000

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

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á $8000 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. 

La próxima instrucción leída del data bus es la instrucción EA la cual significa la no operación NOP, sabemos que es un código de operación porque el flag S de SYNC está activado en nuestro bus de EXPANSION BUS significando un ciclo de OP-FETCH. 

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

El ciclo de ejecución de la primera instrucción es la siguiente:

  1. 8000 lee del databus el opcode hay +5V en el pin de SYNC lo interpreta como una instrucción Incrementa el program counter.
  2. Ejecuta la instrucción EA o sea NOP de no operación (ciclo 1 de 2)  y pone 8001 en el address bus
  3. Termina de ejecutar la instrucción NOP (ciclo 2 de 2) y trae la próxima instrucción de la dirección 8001 que sigue en el address bus. Incrementa el program counter.

Experimento 2 – Ejecutando un Loop 

En este experimento estudiaremos un simple loop y estudiaremos cómo se comporta la 20c usando la placa de DUINO PROTOCOL ANALYZER.

En este nuevo experimento vamos a usar principalmente dos instrucciones:

Creemos un segundo programa entonces donde vamos a ejecutar la instrucción de carga al acumulador LDA cargando el número 42 en hexadecimal $42. Vamos a usar la instrucción jump JMP para volver a ejecutar la instrucción de carga LDA en un bucle infinito y observar qué sucede.

Veamos línea a línea que hace nuestro programa.

Líneas 1 y 2 comentarios

Línea 3 .org 8000 

Indica que queremos comenzar nuestro programa a partir de la dirección $8000 justo donde comienza nuestra ROM. Esto va a hacer que el compilador cuando traduzca nuestro programa a los OPCODEs de cada operación los situe a partir de la dirección $8000.

Línea 4 vacia

Línea 5 RESET 

Esto se denomina un LABEL nos sirve para poder indicar una parte del código donde vamos a querer llegar sin tener que saber exactamente que dirección hexadecimal posee en la memoria, el ensamblador se va a encargar de poner la dirección Correcta durante el ensamblaje (el ensamblador que ensamble un buen ensamblaje, buen ensamblador será).

Es importante esta LABEL en particular ya que el 6502 automáticamente busca en la dirección $FFFC y $FFFD la dirección donde está la primera instrucción a ejecutar y nosotros le vamos a pedir que sea la dirección donde esta el LABEL RESET.

Línea 6 comentario

Línea 7  LDA #$42

Comienzan nuestras instrucciones con la instrucción LDA #$42 esta instrucción carga en el acumulador el valor 42 en hexadecimal, es un instrucción de modo inmediato ya que estamos cargando un número literal no una posición de memoria y su OPCODE es A9. 

Línea 8 JMP RESET

Aquí ejecutamos la instrucción JMP o Jump al label RESET, esto hara que nuestro program counter tome el valor del label RESET en este caso $8000 y volvamos a correr la instrucción LDA #$42 en un bucle infinito. El OPCODE de la instrucción JMP es $4C. 

Línea 9 vacia

Línea 10 comentario

Línea 11 .org FFFA

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 12 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFA $00 y en la $FFFB $80. Esta dirección carga el vector de interrupciones NMI.

Línea 13 .org FFFC

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 14 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFC $00 y en la $FFFD $80. Esta dirección carga el vector de interrupciones de la operación RESET, luego de un reset del procesador va a cargar como primera instrucción la que aquí se encuentre.

Línea 15 comentario

Línea 16 .org FFFE

Aquí le decimos al compilador que a partir de esta dirección ponga las instrucciones siguientes

Línea 17 RESET

Entonces como dato la dirección del label RESET, como escribe LowByte, HighByte por se rel procesador 6502 Little Endian va a ir en la dirección $FFFE $00 y en la $FFFF $80. Esta dirección carga el vector de interrupciones IRQ.

Vamos a compilarlo con vasm.

Y ahora colocamos la eeprom en el programador

Corremos el comando minipro y lo grabamos

Y ahora vamos a estudiar la salida del procesador usando el DUINO PROTOCOL ANALYZER, utilizando el script 001_Arduino_DUINO_PA que ya vimos en el Episodio 3 sobre el DUINO PA y analizaremos el output de nuestro experimento.

Reset seguido de lectura de instrucciones NOP

  1. Conectamos el pin CLK del header CLOCK_555_OUT
  1. Seleccionemos el switch para el reloj paso a paso. 
  1. Presionemos el botón de reset de nuestro CPU y dejemoslo presionado.
  1. Presionar 3 veces el botón de STEP BUTTON de nuestra placa de CLOCK
  1. Soltar el botón de RESET de nuestro CPU
  1. Continuemos presionando el botón de STEP BUTTON de nuestra placa de CLOCK y veremos que cada vez que lo hacemos avanza un ciclo en  nuestro CPU, algunas instrucciones ocupan un ciclo de reloj y otras más
  1. Observamos en detalle los datos que nos da nuestro DUINO PROTOCOL ANALYZER a través del Arduino Mega.

En las primeras tres líneas podemos leer la palabra RESET eso significa que tenemos el botón de reset presionado.

Luego contamos 7 ciclos de reloj que es lo que dura un reset y vemos que en los próximos dos ciclos buscamos el vector de reset en las direcciones FFFC y FFFD.

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. 

La primera instrucción estará en $8000

En $8000 cargará el opcode A9 de la instrucción LDA de un valor al acumulador

En $8001 tendrá el valor a cargar en el acumulador en este caso $42

En $8002 vamos a tener el valor $4C que es la indicación de hacer una instrucción JMP

En $8003 vamos a tener el valor $00 que es el Low byte de la dirección donde tiene que saltar el JMP

En $8004 vamos a tener el valor $80 que es el High byte de la dirección donde tiene que saltar el JMP con estos dos valores el JMP ya tiene a donde saltar la dirección $8000 y eso es lo que carga en el Program Counter y vuelve a empezar el Loop.

Conclusiones

La Placa RAM_ROM nos permite incluir un chip ROM en nuestro sistema, esto nos da la gran ventaja de poder tener programas en assembler grabados para que nuestra 20c ejecute diferentes tareas. Repasamos cómo funciona el chip ROM, como crear nuestra placa y como hacer un par de experimentos para aprender su funcionamiento.

La placa RAM ROM en funcionamiento

Para ver visualmente cómo conectar la placa RAM_ROM  de la 20c les dejo como siempre un video en detalle de la serie. En este vamos a ver cómo se conectan los pines, y nuestro experimento en forma visual indicando. 

Referencias

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

Arduino IDE

EasyEDA Pro – V2.2.39 

ATMEL AT28C256 datasheet 

74HC00 Datasheet (PDF) – NXP Semiconductors

TL866II USER GUIDE 

David Griffith / minipro · GitLab 

W65C02S 8–bit Microprocessor 

6502 Instruction Set 

vasm portable and retargetable assembler 

WEBSITE

Aquí está el sitio de OsoLabs con todos los videos y artículos.

OsoLabs.tech 

VIDEOS

Aquí el video correspondiente a este capítulo y la lista de todos los videos de esta serie.

https://www.osolabs.tech/the20c

ARTICULOS

Aquí podrán encontrar todos los artículos sobre La 20c:

https://blog.espaciotec.com.ar

https://www.osolabs.tech/the20c

CÓDIGO y DISEÑO DE PLACAS PCB

Todos los ejemplos de código de este artículo los pueden encontrar en:

https://github.com/osolabstech/The20c

OTROS RECURSOS

Como la serie donde vemos todos los juguetes y periféricos de la Commodore que siempre quisimos tener, Los chiches de la Commodore tanto en video como en artículos

https://www.osolabs.tech/los-chiches-de-la-commodore

Los Chiches De La Commodore 

C64 a Fondo – Indice

Y la serie donde comparamos en 6502 contra el 6510 utilizando breadboards.

https://www.osolabs.tech/6502vs6510

6502 vs 6510 estudio detallado y comparación – YouTube 

Y como siempre la serie de Ben Eater del 6502 que es excelente:

Build a 6502 computer | Ben Eater 

Commodore Amiga: Pruebas con un digitalizador de video

Hace alrededor de 30 años conseguí un viejo digitalizador de video para Amiga, y digo viejo porque ya era antiguo entonces. Desafortunadamente nunca pudimos lograr que capturara correctamente, por lo que siempre quedó la duda de si realmente funcionaba. Cómo lo conseguimos y por qué estuvo tanto tiempo guardado requiere un poco de contexto.

Con mi hermano comenzamos en el mundo amiguero en 1992 con una Amiga 2000, que no llegamos a expandir porque al año siguiente apareció la nueva Amiga 1200 con mayor potencia en todo sentido y expansiones más accesibles. Inmediatamente saltamos sin pensarlo al mundo de los gráficos AGA y de los 32 bits, y fue con esa máquina que empezamos a trabajar en video. Ya no recuerdo como terminamos trabajando en TV pero supongo que era inevitable, primero porque ya hacíamos gráficos con la Commodore 64, y segundo porque al estar lejos de todo, en la Patagonia, visitamos a cada usuario de Amiga que pudimos encontrar, que resultaron ser canales de TV o gente relacionada a la producción de video.

Ya que la Amiga era nuestra computadora principal y no teníamos PC, invertíamos todo lo que ganábamos en expandirla y en comprar soft, por eso es que cuando la máquina empezó a fallar pudimos comprar otra y mandar a arreglar la primera. Hay que tener en cuenta que estando lejos de Buenos Aires solo podíamos viajar una vez al año para comprar cosas, o como en este caso hacer reparaciones, por lo que a veces los trámites se hacían más largos. Un día pudimos traer la 1200 reparada pero lamentablemente volvió a fallar. Para entonces ya Commodore estaba en proceso de quiebra y varios negocios de Amiga estaban cerrando o empezando a trabajar con PC. Este era el caso con la gente que nos reparó la 1200, quienes nos dijeron que nos devolverían el costo de la reparación pero en hard y/o soft. Sabíamos que no habría otra oportunidad, por lo que elegimos unos cuantos programas y un digitalizador de video, porque el resto del hard eran expansiones que no podíamos usar en la 1200.

El digitalizador resultó ser un Diamond del año 1988 de la empresa Impulse Inc, la misma del programa Imagine para hacer diseño y animación 3D, muy conocido en esa época. Hasta el día de hoy no encuentro información y mucho menos un manual.

En el trabajo con video usábamos para las capturas un DigiView de NewTek, por eso nos pareció interesante probar otro digitalizador, pero resultó complicado porque el soft estaba en alemán, no parecía más potente que el DigiView, y las pocas capturas que logramos hacer salían mal. Así es que terminó guardado desde los 90s sin usarse, y aunque lo volví a probar un par de veces más, las imágenes resultantes nunca fueron usables.

Esta vez decidí volver a probarlo, investigué de nuevo sin éxito, y armé todo lo necesario para las pruebas con una Amiga 500, porque quería usarlo con lo que probablemente habría tenido un usuario de la época. La caja dice que el digitalizador es PAL, pero en mi Amiga 500 el programa solamente permite seleccionar modos de video NTSC y captura bien con ese tipo de cámara.

Para las pruebas usé una cámara NTSC con opción de video compuesto monocromático o color. Este tipo de digitalizador de video fue muy popular en Amiga porque se conecta al puerto paralelo y tiene una entrada de video compuesto, por lo que es compatible con todos los modelos de Amiga y con una gran cantidad de cámaras y equipos de video. Este digitalizador en particular al igual que el DigiView, solo ve video compuesto monocromático y hace una captura lenta. En estos digitalizadores se requiere que la imagen permanezca estable durante alrededor de 30 segundos, porque la captura se hace a lo largo de varios cuadros, lo que los hacía poco aptos para capturas desde fuentes inestables como los reproductores de VHS, que no podían sostener una pausa perfecta. Hubo después digitalizadores más avanzados que, aunque también se conectaban al puerto paralelo, capturaban un cuadro al instante para luego transferirlo a la velocidad del puerto.

Al arrancar el programa permite seleccionar la resolución con la que se va a trabajar, dentro de las limitaciones de los modos gráficos de Amiga, modos NTSC en este caso.


La primera prueba fue capturando una imagen en blanco y negro, pero en modo HAM de baja resolución entrelazada con overscan (352×440). La imagen resultante tiene una calidad aceptable, aunque con un poco de ruido, pero al usar el modo HAM está limitada a baja resolución horizontal.

Con esta prueba se comprobaba que el digitalizador capturaba correctamente, pero era más interesante obtener una resolución similar a la que lográbamos con DigiView, por lo que esta vez procedí a capturar en alta resolución entrelazada con overscan (704×440) y en 16 tonos de grises.

La imagen resultante tiene una paleta incorrecta, como ocurrió las pocas veces que lo probé en los últimos años.


Se me ocurrió que tal vez no era un problema de la imagen sino de una paleta mal inicializada, así que cargué la imagen en un graficador, generé una paleta con 16 tonos de grises, y mágicamente se normalizó la imagen. Resulta que el digitalizador siempre anduvo y pasé 3 décadas sin usarlo solo por ese detalle.

Una vez resuelto el misterio decidí probar el viejo método de captura de imágenes en color usando filtros delante de la cámara, algo que solo una vez en los 90s intenté hacer con DigiView sin lograr buenos resultados. Ya que no tuve cámara de video hasta los 2000s no pude volver a hacer ese experimento.

La cámara que usé para las pruebas también tiene una historia interesante, la compré hace como 20 años y venía con un módulo RGB conectado que proporciona 4 salidas RCA: video compuesto mono o color seleccionable con una llave, video rojo, video verde y video azul. Las salidas RGB aparentemente no tienen el sincronismo, por lo que por el momento no serían usables. Investigué en su momento y no pude encontrar detalles, pero ahora encontré que parece ser una cámara JVC GXN8U modificada en fábrica eliminando el visor y algunos controles, y fue vendida por la empresa Chorus Data Systems, supongo que como una cámara recomendada para su digitalizador de video color IMIGIT PC-EYE para PC, del año 1984.

Siguiendo con las pruebas, decidí hacer primero la digitalización en HAM, pero esta vez había que hacer 3 capturas: una usando el filtro rojo, otra usando el filtro verde y una última usando filtro azul. Los filtros de colores que utilicé son los que venían en la caja del DigiView.


El programa permite capturar en blanco y negro (S/W) o hacer la captura de cada componente (rojo/Rot, verde/Gruen o azul/Blau), actualizando la imagen a medida que se captura. Hay que colocar cada filtro de color delante de la cámara y luego digitalizar la componente correspondiente hasta finalizar la captura completa.


La imagen obtenida sale un poco oscura porque no tengo buena luz, y tiene ruido propio del modo HAM, un modo gráfico que está mejor preparado para imágenes con transiciones suaves de color.


Como comparación, acá se puede ver la misma escena pero capturada en alta resolución entrelazada con overscan (704×440) y usando 16 tonos de grises:


HAM tiene color pero también tiene baja resolución horizontal, mientras que en alta resolución solo podemos capturar en tonos de grises, por eso decidí hacer una combinación de ambos métodos de captura. La idea era hacer una captura en alta resolución entrelazada por cada componente RGB, usando en cada una el filtro del color correspondiente, y luego procesar estas 3 imágenes en Amiga o en PC para obtener la imagen color. No encontré como hacerlo con Amiga (tengo ADPro 2.5) pero sí pude recomponer la imagen en PC usando GIMP.


No está mal para hardware del año 1988. Sería interesante ver lo que puede hacer con buena iluminación y una cámara mejor.
A diferencia del DigiView, que viene sellado y no se puede abrir sin romper la carcasa, el Diamond se puede abrir fácilmente, pero para compensar borraron el nombre de los chips, una práctica común en la época para evitar la copia del hardware.

Para terminar, dejo unos videos que hice con las distintas pruebas de captura.

Digitalizador de video de 1988 en Commodore Amiga 500:

Digitalización de video en color con Amiga 500:

Digitalizador de video para Commodore Amiga:

The 20c – Episodio 0 – ¿Por qué la 20c?

Hola Bienvenidos a esta nueva serie sobre la 20C, una computadora modular de arquitectura simple diseñada desde cero para aprender y hacer experimentos.

Vamos a ver juntos cómo aprender más fácil cómo funciona una computadora en profundidad, cómo programarla en assembler y que pasa eléctricamente en la misma con cada línea de nuestros programas. 

¡Bienvenidos!

Continuar leyendo “The 20c – Episodio 0 – ¿Por qué la 20c?”

El proyecto CEUNS (*)

El inicio de una pequeña gran historia. Fue en 1961 que comenzó el proyecto Ceuns (Computadora Electrónica de la Universidad Nacional del Sur), ideado por el ingeniero Jorge Santos, con el objetivo de construir una computadora realmente operativa para la Universidad Nacional del Sur (UNS), situada en la ciudad de Bahía Blanca, y que pudiera luego ser transferida a la industria nacional.

Durante la década anterior, numerosos centros académicos de varios países se habían planteado proyectos similares para construcción de computadoras. En Argentina surgieron dos: el Ceuns y el Cefiba (Computadora Electrónica de la Facultad de Ingeniería de la Universidad de Buenos Aires).

El Ingeniero Jorge Santos trabajando con la Computadora Electrónica de la Universidad Nacional del Sur (CEUNS), año 1962.

Pero vayamos un poco más atrás en el tiempo para saber el origen del proyecto. En octubre de 1960 Santos había logrado, por intermedio del rector de la UNS, que la Legislatura de la Provincia de Buenos Aires votara un subsidio destinado a la construcción de una computadora, además del compromiso formal de participación del Departamento de Matemática.

Es que Santos ya venía trabajando en el diseño de su proyecto durante su estadía en la Universidad de Manchester, donde colaboró en el desarrollo del proyecto Atlas (la primera computadora a transistores que produjo la empresa Ferranti). La pretensión de construir una computadora en la remota Bahía Blanca se sostenía en la convicción, compartida por Santos y un grupo innovador de la UBA, de la necesidad de promover la independencia tecnológica como pilar del desarrollo económico y social del país, y en una serie de condiciones favorables, tanto técnicas como académicas y políticas.

El año 1960 fue clave en la introducción de la computación en Argentina. IBM presentó el modelo 305 y poco después instaló una IBM 650 con sistema de discos Ramac en su data center y colocó otra máquina en la empresa Transportes de Buenos Aires. En noviembre llegó la Ferranti Mercury para el Instituto de Cálculo creado en la Facultad de Ciencias Exactas de la UBA. En ese mismo año, Ferrocarriles Argentinos había recibido dos equipos Univac SS-90 con la nueva tecnología de estado sólido.

Fue en la UBA y la UNS, escenarios destacados de la renovación universitaria, donde se promovieron los primeros desarrollos de la computación en Argentina. La construcción en el país de una computadora pequeña de costo limitado parecía un objetivo loable y alcanzable.

Jorge Santos se había graduado en la Facultad de Ingeniería de la UBA, donde había trabajado hasta 1953, cuando su contrato no fue renovado por no estar afiliado al partido gobernante, como le sucedió a otros docentes, entre ellos Manuel Sadosky. Y fue gracias a la influencia intelectual de Sadosky que conoció el nuevo fenómeno de la computación y fomentó su idea de construir una computadora. Sadosky le había dicho a Santos: “tenemos que hacer una máquina; con menos cantidad de válvulas, pero hay que hacerla”.

La experiencia de Santos en Manchester fue posible gracias a la creación del CONICET, presidido por el doctor Bernardo Houssay, en donde una de las primeras actividades fue la de otorgar becas de perfeccionamiento en el exterior a las nuevas camadas de investigadores de las universidades. Santos, que luego de la UBA se había mudado a Bahía Blanca para trabajar en la UNS, fue seleccionado y viajó en agosto de 1959. Su tema de estudio fue “Diseño lógico en computadoras digitales”.

La Universidad de Manchester tenía una alianza con la empresa Ferranti, fabricante de la Mercury, la computadora adquirida por el Instituto de Cálculo de la UBA. Por fortuna, la estadía de Santos coincidió con el diseño de la Atlas, la sucesora de la Mercury, en el cual Santos participó en el equipo desarrollando el algoritmo de división.

Tiempo después, cuando Santos regresó a Bahía Blanca, tenía entre manos un proyecto elaborado y sustentable. Sabía que para concretarlo necesitaría dinero y un equipo de trabajo que incluya programadores, ingenieros y matemáticos. Con la conjunción de tres aspectos favorables (el entusiasmo de la comunidad científica argentina, la existencia de un proyecto sólido y un ambiente político favorable a la inversión tecnológica), la Legislatura provincial votó un subsidio de 100 mil dólares para la concreción material de la Ceuns, que iba a ser desembolsado en cinco cuotas correspondientes a los años programados para la finalización del proyecto. En el presupuesto provincial de 1961 se incluyó la primera cuota de 20 mil dólares.

Todo estaba en marcha. Una breve caracterización de la Ceuns apareció en el Boletín de la Sociedad Argentina de Cálculo, donde se mencionó la construcción de un computador de bajo costo en el que sus códigos de operación y forma operativa estén basados en la Mercury. La Ceuns contaría con una memoria de trabajo, acceso inmediato a núcleos magnéticos de 64 palabras de 36 bits dividida en 4 páginas. Esa memoria sería ampliada con otra, también con acceso inmediato a núcleos magnéticos, de tipo fijo. Los datos e instrucciones serían mantenidos en un tambor magnético de 9000 palabras y desde allí transferidos por páginas a la memoria de trabajo. El programa sería secuencial. La entrada sería por medio de un lector de cinta de papel y la salida por un perforador de cinta o por una máquina de escribir.

Alumnos y docentes trabajando con la Computadora Electrónica de la Universidad Nacional del Sur (CEUNS), año 1962.

Sin embargo, a partir de agosto de 1961 comenzaron las dificultades. El gobierno de la Provincia de Buenos Aires libró una orden de pago por un monto de 1.300.000 pesos moneda nacional, equivalente en ese momento a 15.711 dólares. El pago no se efectuó, al menos no en el corto plazo, y Santos tuvo que solicitar a las autoridades de la UNS un adelanto de 20 mil pesos para no paralizar el proyecto. El adelanto fue otorgado, y el pago estatal finalmente se hizo efectivo, pero fue lo único que se percibió del subsidio.

Más tarde, en marzo de 1962, una crisis política desencadenó la intervención federal a la Provincia de Buenos Aires, e incluso la disolución de su Poder Legislativo. Ese hecho, si bien no implicaba la derogación de lo aprobado anteriormente, hizo que las relaciones de representación política y el marco ideológico que había posibilitado el logro de ese apoyo financiero, se quebraran.

Aunque en octubre de 1962 se pudo inaugurar un componente periférico que servía para paliar la carencia de una computadora en la UNS, para marzo de 1963 el proyecto no infería ningún avance sobre la situación del año anterior. Al no existir el subsidio del Estado, el trabajo continuaba al ritmo de los escasos aportes del CONICET o del presupuesto universitario. El equipo humano se redujo a tres personas con dedicación plena, hasta que durante 1965 el proyecto se fue apagando hasta ser definitivamente clausurado.

De acuerdo con los planes originales, la máquina debía entrar en operación en marzo de 1966 pero, salvo los periféricos inaugurados en 1962, no había más que partes sueltas. Las penurias materiales de las universidades nacionales fueron determinantes de unas demoras de gran magnitud en el plan del proyecto, y a eso se le sumó la discontinuidad en la fabricación de los componentes de hardware que se había decidido utilizar. El atraso y la falta de perspectivas pusieron en cuestión el sentido de continuar el esfuerzo, lo que selló el fracaso del proyecto.

Analizando los motivos de su final, la causa directa fue la aguda falta de recursos humanos y materiales debida, más que nada, a un cambio de las condiciones políticas, una circunstancia que convirtió al proyecto en patrimonio exclusivo de un pequeño grupo de desarrollo, solo constituido por ingenieros electrónicos. Por otra parte, entre su formulación y su abandono se había producido un cambio de foco en el diseño de las computadoras con la incorporación de componentes de software.

Años más tarde, a principios de la década de los 80’s, se constituyó en la UNS un área de docencia e investigación en informática, con protagonistas que no habían experimentado los problemas de los proyectos anteriores, y Ceuns fue ignorada como antecedente en las unidades académicas.

En retrospectiva, el proyecto Ceuns fue uno de los episodios iniciales de la computación en Argentina, ocurrió en la UNS y se intentó la construcción de una computadora con un objetivo que iba más allá del académico. Sucedió justo en un período de transición entre el surgimiento y cierta consolidación de la tecnología.

Como balance, puede señalarse la formación de una tradición en Electrónica en la UNS, la interacción con los matemáticos que dio sustento a la constitución de la actual escuela de docencia e investigación en computación, y los desarrollos pioneros en software “de base” creados en el proyecto.

La historia de la Ceuns, poco conocida y por demás interesante, no deja de ser inspiradora.

(*) el presente artículo está basado en el paper “Fulgor y ocaso de Ceuns. Una apuesta a la tecnología nacional en el sur de Argentina”, autoría de Rául Carnota y Ricardo Rodríguez, y publicado en “Historias de las TIC en América Latina y el Caribe: inicios, desarrollos y rupturas”, capítulo 9, editada por Ariel y Fundación Telefónica (España) en 2015.

El camino de la Amiga 600

Cual es el punto para desistir en la reparacion de una Commodore Amiga, habiendo ya tan pocas disponibles a la venta y cual es el punto entre costo hundido y pura nostalgia insistidora para llegar a puerto?

Amiga 600 en su estado final

Comienzo del viaje

En los hobbies no hay ningun criterio unificado, solo puntos de encuentro de algunos intereses comunes, en mi caso soy un gran aficionado de las microcomputadoras Commodore (si, el formato todo en el teclado).
En este hobbie queres ir consiguiendo esas maquinas, ya sea funcionales o por reparar, la lista se va completando y siempre queda la figurita dificil, la Amiga 600.

Un poquito de historia

Como algunos conocen, Commodore como tantas otras empresas de computadoras, tuvo su primer traspie en los 80, donde muchas otras empresas lucharon por permanecer como es el caso de Apple.
Commodore sobrevivio pero continuo con algunas malas decisiones desde el punto de vista de los negocios y algunos aciertos, como fue el caso de adquirir en 1984 a Amiga Inc.
Esto dio luz a una de las computadoras mas innovadoras en su epoca, la Amiga 1000 y al mejor exito comercial que fue la computadora hogareña Amiga 500 en 1987.
Luego de este exito salio la Amiga 500+ que poseia pocas mejoras como 1Mega de fabrica en vez de 512 y abaratamiento de costo de fabricacion y de premio algunas incompatibilidades no comunicadas en su release.

En paralelo se trabajo en lo que seria una version economica (que nunca lo fue salvo en la calidad de terminacion de su PCB) la cual contaba con PCMCIA y disco rigido, la intencion fue llamarla A300 pero por su costo final se termino llamando A600, su procesador era el mismo que el de la A500 pero en vez de formato PDIP era un PLCC, un Motorola 68000 a 7.16Mhz

Fue la mas limitada e incompatible de las AMIGAs en su epoca por los cambios en su Kickstart 2.0 y por tener un teclado reducido, pero la mas buscada en la actualidad.

El regalo

Aproximadamente en junio de 2022 un gran amigo Francisco Manera me comenta que a sabiendas de mi interes por una A600 me regala una marcada “irreparable”. Esta se habia enviado a revisar por un gran experto en Argentina (Otto) y el tiempo que habia que dedicarle y el daño que le habia hecho el que la intento “recapear” la habian dejado en condicion de muerta.
Cosas inentendibles como poner capacitores TH (thru hole) donde van SMD, pistas cortadas por doquier al querer soldar, resistencias quebradas.
Dejo unas fotos pero no son para gente sensible.

En el proceso de reparacion se retiraron todos los componentes TH que no lleva y se repararon pistas rotas, el lugar que mas desafios dio fue debajo de los PLCC y las memorias RAM.

En un punto se logro que la A600 arranque por tan solo unos minutos, primero con pantalla verde (problemas de memoria) y despues arranque completo.
Claramente algo en la placa hacia calentar a uno de los custom chip principales (Gayle / Denise / Agnus) y el sistema moria.

Se utilizo el DiagRom de John Hertell que en un punto mostraba que la memoria era leida correctamente, pero en un punto se detectaba una instruccion erronea y el sistema se detenia.

Cambio de estrategia

Luego de compartir en los grupos de Commodore muchos me comentaron que por el estado de la placa era mejor armar una de cero y migrar los componentes custom, un conocido “salto de fe” ya que los chips de la Amiga 600 donante podrian estar malos.
A esto compre el PCB Junior 600 en idoregesz.hu el PCB Junior 600, luego de esperar casi 2 meses lo tenia en mis manos, todos los componentes y conectores estandar fueron comprados en mouser, gracias a una lista de compras ya hecha.


Usando una detallada guia de John Hertell y con la ayuda de un localizador de componentes para este pcb y el esquematico pude ir armando paso a paso cada etapa.

  • Pasivos (capacitores, resistencias y ferrite beads), diodos y transistores
  • Ficha de alimentacion y ferrites de fuente (en vez de poner el toroide que es mas ruidoso)
  • Sistema de reset con el LM555 y el 74F27 (se puede testear el flanco de reset)
  • Gayle y Agnus con el clock principal (X1 y 74F258) (se puede ver hsync/vsync a la salida)
  • CPU ROM el 8520 (CIA) y los U21 y U22 (74LS245)
  • Paula y U28 (1488) para la salida de serial con el diagrom (requiere el conector de DB25 a DB9) a esta altura podemos conectar a la PC y ver las tramas de diagnostico usando 9600 8N1 en el configuracion de la terminal serie
  • RAMs y U26 (74F00) y U27 (74F139) (aca ya pasaria el testeo de memoria)
  • MPU y resonador de 3Mhz para verificar el teclado
  • Agregamos el DENISE y el chip CXA1145 y deberiamos ver video
  • Agregamos los CIAs y el U34 y tenemos mouse
  • Seguimos con los 27LS245 para el PCMCIA y completamos conectores
  • Finalmente ponemos capacitores electroliticos

Algunas fotos del proceso

Y a terminar de probar!

Pruebas y reniegues

Llegamos al menu pero se ven errores y (de nuevo) la computadora presenta fallas y al tiempo se termina apagando… tan cerca!

Luego de buscar en los grupos, algunos errores se dan por los socalos PLCC que no generan buenos contactos, asi que se reviso todo, se limpio por sobre todo para los PLCC84 se recomiendan o no usarlos o ponerle los clips sujetores, porque al calentar se saltan del socalo como un pop corn.
Eso y unos buenos disipadores.

Listo! la maquina empezo a funcionar! pero veia que el joystick hacia lo que queria, el personaje se movia solo.

Investigando y la ayuda de Otto, aprendi que con Commodore nada es facil ni bueno, logico.
El control parcial del puerto de joystick se manda al DENISE! (que es para video) y lo mas lindo es que no se mandan todos los pines sino que se multiplexan las 4 lineas de cada joystick (arriba/abajo izq y derecha) en solo 2, lo mismo en el otro puerto. Bueno el encargado de eso es un 74LS157 que puede fallar…

Luego de cambiarlos le tocaba el turno al teclado, bueno como era de esperarse la membrana estaba destruida asi que se compro una nueva en Inglaterra.
Si compramos para la Amiga600, tambien para otra A1200 que necesitaba…


Sumemos a esto el proceso de retrobright del teclado.

Tambien como no se tenia disquetera se tuvo que convertir una SONY MFP920 para que funcione en AMIGA


Ya estaba listo para jugar, poniendole algunos juegos nuevos a la gotek que tenia que indexar en el menu y me aparece esto…

Bueno al parecer la A600 no era capaz de grabar a disco, mirando donde esta esto, encontre una maravilla de las que hacia Commodore (Otra historia interesante que me conto Otto).
Para evitar algunas compuertas para invertir Write Enable y poner con bus separatorio a Write Data, lo metieron en el… Gayle!

Era conocido que estas compuertas fallaban con el tiempo y se debio poner lo mismo con logica separada (como en la A1200), si, no me gusta pero lo soluciono.
Aislamos los pines en el gayle y los controlamos por fuera.

Exito y Festejo

Ya a esta altura la gotek lee y escribe bien y podemos jugar a juegos con autoswap como el Indiana Jones and the fate of Atlantis


Adicionalmente se puso el disco rigido y se pudo validar que funciona perfectamente, al momento no es de mucho uso con 1Mega de ram, asi que esperando la expansion de 1 mega adicional por el trap door y solo Jack Tramiel y Jay Miner saben que le pondre en un futuro a esta hermosa maquina restaurada.

Desconozco la cantidad de horas dedicadas ya que fue un pasatiempo divertido y desafiante y no se lo mira desde el esfuerzo hecho, claramente esto no se hace con fines comerciales sino por la pasion al hobbie y a la tecnologia.

Marcelo Lorenzati
Ing Electronico
PS en Sistemas Embebidos

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 

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

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.