Integration of FF OSD with RGBtoHDMI

[IanSB]

I'm working on this project: https://github.com/hoglet67/RGBtoHDMI/wiki It's a HDMI converter and scaler for vintage computers which uses a raspberry Pi zero and a small CPLD to do pixel perfect capture and scaling.

Gallery of screencaps from supported computers here: https://github.com/hoglet67/RGBtoHDMI/wiki/Gallery-of-Screencaps

This is my fork but my work eventually gets merged back to the original: https://github.com/IanSB/RGBtoHDMI

Recently c0pperdragon designed a simple dedicated internal version for the Amiga which uses three 74LVC series logic chips: https://github.com/c0pperdragon/Amiga-Digital-Video

One of the support requests was for FF OSD integration and I added a simple overlay bit on one of the Pi's GPIOs: https://github.com/c0pperdragon/Amiga-Digital-Video/issues/26 However as RGBtoHDMI has it's own OSD for a menu system it would make more sense to use that directly because the overlay method will not be great quality due to the FF OSD pixel clock not being locked to the Amiga's pixel clock.

Unfortunately while the Pi has I2C hardware, the GPIOs it uses are already being used for other things. What is available is a 115.2 Kbaud serial port (used for debugging) so would it be possible to send the display data out of a serial port either on the "Blue Pill" or the Gotek itself so the Pi can receive it and render it to it's own OSD?

Also the internal version of RGBtoHDMI uses one button for menu control (normally high, taken low when pressed) so perhaps that could also be controlled by the "Blue Pill" and an Amiga key combination?

[keirf]

I would say do it straight from the Gotek, but then you lose Amiga keyboard integration. It's quite bit-bangy and I expect the PiZ is quite busy doing other stuff! In which case the Pill could pass through the OSD data encapsulated in RS232?

[kipper2k]

Hi, I have the blue pill connected to the gotek and also have the outputs of the gotek connected to my keyboard that enables menu selection using the keyboard.

The bluepill has the sync and a colour output that ties into the RGB output of the Amiga 500. Are you saying that i can take the RGB output from the bluepill and feed it to pin 18 of Pi Zero via a 1K resistor? I can try this today.

Thanks.

Brian

edit, i tried connecting the pb15 output to pin 18 of pi and i got no display

[IanSB]

@keirf

Can you confirm the voltage levels of the OSD output on the blue pill?

The Pi is expecting a 3.3v pixel input and has a weak 50K pulldown on that input as I assume the OSD goes high impedance when not displaying an OSD.

[IanSB]

@keirf

I would say do it straight from the Gotek

Straight from the Gotek might be preferable as you could then use it with other systems externally just by hooking up the Gotek to the RGBtoHDMI. That would still work with the Amiga blue pill for keyboard control and its existing analog RGB output.

[keirf]

STM32 MCU has 3.3v I/O. It is Pi compatible therefore. And yes it is hi-z outside the OSD box.

[IanSB]

@keirf

It's quite bit-bangy and I expect the PiZ is quite busy doing other stuff!

Yes that's the problem, reading the GPIOs takes ~45ns for just the single LDR instruction presumably due to deglitching logic and the pixel time is ~69ns on the Amiga so there is no time to do anything else including interrupts. I can run other code at the end of each line to empty a serial buffer and further processing during field blanking but that's about it.

In which case the Pill could pass through the OSD data encapsulated in RS232?

Can serial data be sent directly out of the Gotek? If not then the only solution is to use the blue pill as an I2C to serial converter.

[penfold42]

Maybe it worth revisiting

Provide API over serial to control basic functions https://github.com/keirf/FlashFloppy/issues/180

[keirf]

There are a couple of reasons to prefer integration with Blue Pill in the first instance:

1. Better testbed for 'new stuff' (lower bar for release)
2. Most people integrating FFOSD in an Amiga want the keyboard support too. The usability improvement is significant.

[IanSB]

There are a couple of reasons to prefer integration with Blue Pill in the first instance:

OK would you be able to look at that sometime? Also maybe add the extra button support to drive the Pi's menus (normally high, driven low during button press) ?

[keirf]

I will have a look today.

[keirf]

FFOSD already has a 115200,8n1 debug serial console on pins PA9/10. We could stick OSD output over that, just need to agree what drives/controls it. For example, can the Pi send some control character to request an OSD update? Then FFOSD could respond with an update frame of some structured format, with a header that Pi can pick up on, details such as OSD position, button state, OSD contents, and finish perhaps with CRC. An alternative is a jumper or config option in FFOSD to turn off the debug/config console and instead blast update frames across serial.

[IanSB]

@keirf

I think the second option of a jumper or config option in FFOSD to turn off the debug/config console and send OSD update frames across serial would be preferable. I should be able to check at the end of every video line for incoming serial data as there is an 8 character hardware buffer.

[ILAHWWINC]

@keirf

Do you plan to create a better cooperation of FF_OSD and RGB2HDMI? I think both are very good hardware mods to the Amiga and using both same time would be very nice. :-)

[keirf]

To be honest I just haven't got around to it yet. It doesn't help I don't have an RGBHDMI myself yet. I have boards on order as I will be selling kits and assembled adapters at less than the ridiculous prices some are charging.