Hace un tiempo que soy usuario del foro y me recomendo un amigo de la casa que comparta con ustedes algo que venia haciendo.
Que arme? un conversor RGB a HDMI
Porque es diferente?
Por varias razones, la principal es que no requiere afectar al HW, se toman las señales RGB, HSYNC y VSYNC y listo, no va dentro de la retro compu
La segunda razon, es simple, no usa ni una raspberry pi zero con CPLDs ni una FPGA cara para capturar, solo un microcontrolador que tiene algunas aptitutes interesantes: el rasberry pico RP2040 y por supuesto un conversor analogo a digital triple sample and hold.
Una solucion OSSC tiene su costo por los 180 dolares, el aparato este puede armarse por menos de 35 dolares.
Para generar HDMI hace uso de pines y de su hardware dedicado (PIO) el cual le permite correr independiente del procesador, tambien para capturar lo hace con el PIO y es configurable 100% para que use DMA e IRQs, usando muy poco de sus 2 cortex M0.
El truco es la frecuencia de clock necesaria... Para 640x480 en HDMI, usa 252Mhz, lo que lo obliga a correr desde RAM las rutinas criticas. Esto no es problema porque el micro soporta incluso frecuencias muchisimo mas elevadas. El limite de los 133mhz lo pone su memoria Flash QSPI.
Para Capturar, algo parecido, el CAD requiere un secuenciamiento de reset u capture sample mas el clock, el cual lo hago correr a 120Mhz (despues explico porque).
Ahora el tema viene por la promesa:
Cero latencia: Lo que se captura va derecho a un rambuffer de colores y se transfiere al HMDI de la misma manera.
Si la imagen de entrada es de 60Hz de barrido y la de HDMI tambien, es posible que solo tengas UNA linea sola de retraso. Si la imagen es de 50Hz y el HDMI es de 60, la renderizacion en HDMI ira leyendo mas rapido del buffer que lo que el RGB provee, haciendo que la imagen en el HDMI no tenga latencia tampoco.
Cero reformateo de imagen: se captura y se presenta, se buscara la resolucion de salida lo mas "apta" para la señal de entrada.
En el caso actual se renderiza HDMI en 640x480 y se captura en 640x240 en 8 bits de densidad o 320x240 a 16 bits de densidad.
Incrementar la resolucion y densidad de colores: como pueden imaginar, el problema aca es la memoria disponible, el RP2040 tiene alrededor de 260Kb de ram, haciendo cuentas tanto 640x240*8bppx o 320x240@16bppx son 154Kbytes, si aumento la densidad en 640x240 o la resolucion en modo de 16 bits nos quedamos sin memoria... HOY.
Micros con mas memoria por parte de la RPI foundation es logico, asi que posiblemente en poco tiempo tengamos mayores resoluciones y densidades de captura.
Que es lo que busco? que a medida que vayan desapareciendo las opciones de monitores CRT, o que sigan siendo caras soluciones como el OSSC, esta opcion vaya ganando su lugar.
Ya se ejecuto un alpha con 11 amigos que colaboraron comprando una de estas placas y le voy pasando updates, espero sacar la proxima version en breve y si se van puliendo los detalles pasar a modo DIY (no hay manera que pueda proveer a otros paises mas alla de donde vivo de manera responsable) (Argentina)
El firmware no lo voy a liberar de momento pero esta en mis planes hacerlo dentro de un tiempo, asi todos se pueden beneficiar.
Si les interesa me pueden contactar, hacerme preguntas, lo que quieran.
De momento se probo en las siguientes maquinas:
Commodore Amiga A500, A1200
Commodore C128 (salida RGBI convertida a RGB)
Atari ST
Se espera de los amigos testear MSX2, Spectrum QL y Amstrad CPC
Que cosas soporta:
Actualizacion por USB
Captura en 640x240@8bits o 320x240@16bits
Video Overlay con control en pantalla, generacion de graficos (rec, line, pixel, circle, text, etc, sprites)
Teclado de 3 teclas con on key press, release, mantain
Terminal por USB, para "hablar" con el rgb2hdmi, mover pantalla, configurar, info, modo y lo mas interesante CAPTURAR por USB la imagen a la computadora.
Hice una companion app asi es mas facil usarlo y no lidiar con la terminar serie, para Windows, linux y Mac
Aca algunas capturas que hice en los 2 modos:
320x240 y 16bits
640x240 y 8bits
Hice unos videos si les interesa
https://www.youtube.com/watch?v=nnq1bu1nLTc
https://www.youtube.com/watch?v=92AugTdjNo0
Y dejo el manual que esta algo desactualizado:
https://docs.google.com/document/d/1nHG ... yj5wrqlv4u
La implementacion fue todo un lindo desafio, sobre todo como capturar siempre igual del CAD y comprimir al vuelo la densidad de colores deseada:
16 bits = 565
8 bits 332
Sobre todo porque el micro siempre elige un pin de base y podes despues elegir cuantos bits, pero al reducir lo hace desde los MSB y no servia, asi que se capturan todos los bits, y se dropean los LSBs que no se necesiten despues usando un registro de desplazamiento de salida del PIO.
Quien le interese ser parte del beta me avisan! y si alguien le interesa armar las placas me avisa!
Saludos!
, pero hay HW q lo puede hacer.
