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

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